easy-coding-harness 0.10.0-beta.9 → 1.0.0-beta.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "0.10.0-beta.9",
+  "version": "1.0.0-beta.0",
   "description": "CLI scaffold for installing Easy Coding harness files into agent-native directories.",
   "repository": {
     "type": "git",

package/templates/claude/agents/ec-implementer.md

@@ -9,8 +9,6 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
 ## Hard constraints
 
 - Modify only the files listed in the task card's "Editable scope". Touch nothing else.
-- If the editable scope is `NONE — read-only deliverable`, modify nothing and return the full
-  requested result in `deliverable`.
 - Do not call any Skill tool.
 - Do not read `.claude/skills/`, `.agents/skills/`, `.qoder/skills/`, or any `.easy-coding/`
   file. All context you need is already in the task card.
@@ -19,25 +17,26 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
 - Follow the task card's `Local Baseline`: match nearby naming, control flow, null/error handling,
   layering, object modeling, method granularity, literal usage, and comment style unless a stated
   correctness, security, requirement, or hard-rule reason requires a deviation.
-- Treat the task card's `Code Comments` author value and field/member/constant rules as mandatory.
+- Treat the task card's `Code Comments` author value and field rules as mandatory.
 - Do not add generic defensive null checks, speculative abstractions/layers, fragmented one-use
   micro-methods, or a constant that exists only to hold one getter return.
 - Local, obvious magic values are allowed when they match surrounding code; create constants for
   reuse, stable domain/config/protocol semantics, or established project convention.
 - Every method and field in a new core Java class, and every added or materially modified method
-  or field in an existing core Java class, must have meaningful Javadoc; comment complex logic
-  where intent or constraints are not obvious.
+  or field in an existing core Java class, must have meaningful multiline Javadoc; use `//` for
+  ordinary one-line notes and comment complex logic where intent or constraints are not obvious.
+- Do not change unrelated comments, formatting, imports, names, or code. Keep one blank line
+  between coherent logic sections and revert formatter spillover outside the requested scope.
 - Treat acceptance criteria, test points, contracts, and risks in the card as required inputs.
-- Run the exact targeted checks requested by the card and report their real outcome.
+- Do not run quality commands unless the card explicitly marks TDD lifecycle execution required.
 - Preserve each existing file's original encoding; never silently convert.
 
 ## Output (return exactly this)
 
 - `changed_files`: the files you actually modified
 - `summary`: one line describing what you did
-- `deliverable`: full no-code result, or `null` for a code unit
 - `issues`: problems you hit (empty array if none)
 - `needs_attention`: anything the main agent must decide (empty array if none)
-- `checks`: commands run with pass/fail outcomes
+- `checks`: TDD lifecycle commands actually run, otherwise an empty array
 
 Do not claim a file is verified unless the card asked you to run a check and you ran it.

package/templates/claude/agents/ec-reviewer.md

@@ -19,8 +19,12 @@ dimension named in your task card. Your reply IS the return value.
 - Do not request defensive null checks, abstraction, constant extraction, or legacy-wide comment
   cleanup solely as generic best practice. Flag unjustified local-style deviations, speculative
   layers, fragmented one-use micro-methods, constants created only for a getter return, and
-  missing Javadoc on any method/field in a new core Java class or any added/materially modified
-  method/field in an existing core Java class.
+  missing multiline Javadoc on any method/field in a new core Java class or any added/materially
+  modified method/field in an existing core Java class.
+- Treat unrelated comment, formatting, import, naming, or refactor changes as minimum-diff
+  violations. Do not ask to clean up untouched legacy code.
+- On the first pass, report the complete in-scope finding set. On a repair pass, review only the
+  repair delta and direct interactions; do not introduce unrelated style findings.
 - `error` means a demonstrated acceptance, contract, security, or build failure. Use `warning`
   for a credible risk and `info` for non-blocking maintainability advice.
 
@@ -33,5 +37,13 @@ dimension named in your task card. Your reply IS the return value.
 ## Output (return exactly this)
 
 - `dimension`: your assigned dimension
+- `passed`: true only when there are no `error` findings
+- `implementation_fingerprint`: copy unchanged from the task card
+- `quality_attempt`: copy unchanged from the task card
+- `failure_classes`: array of code-defect | test-defect | contract-ambiguity | environment for
+  blocking findings; empty when passed
+- `reviewer`: your canonical Agent identity
+- `timestamp`: current ISO timestamp with timezone
+- `repo_id` and `source_task_id`: copy unchanged when present in the task card
 - `findings`: array of `{file, line, issue, severity}` (`severity`: info | warning | error)
 - `suggestion`: optional fix direction per finding

package/templates/claude/agents/ec-verifier.md

@@ -20,13 +20,22 @@ not pass.
 
 ## Hard constraints
 
-- Run only the requested check. Do not fix code, do not run other checks, do not edit files.
+- Run only the requested check. Do not fix code, do not run other checks, and do not edit files.
+  Keep the exact task-card candidate fingerprints; never combine another candidate's output.
+- Distinguish environment/tooling failures from code or test failures in `failures`.
 - Do not call any Skill tool. Do not make stage decisions.
 
 ## Output (return exactly this)
 
-- `check_type`: lint | typecheck | test | build
+- `check_type`: lint | typecheck | test | build | coverage
+- `check`: copy unchanged from the task card
+- `command`: the exact command that was run
 - `passed`: true | false (from the real exit status)
+- `quality_attempt`: copy unchanged from the task card
+- `failure_classes`: array of code-defect | test-defect | contract-ambiguity | environment;
+  empty when passed
+- `timestamp`: current ISO timestamp with timezone
+- `repo_id` and `source_task_id`: copy unchanged when present in the task card
 - `failures`: array of failure messages (empty if passed)
 - `command_output`: the relevant tail of stdout/stderr
 - `implementation_fingerprint`: copy unchanged from the task card

package/templates/codex/agents/ec-implementer.toml

@@ -8,8 +8,6 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
 
 Hard constraints:
 - Modify only the files listed in the task card's "Editable scope". Touch nothing else.
-- If the editable scope is NONE — read-only deliverable, modify nothing and return the full
-  requested result in deliverable.
 - Do not call any Skill tool.
 - Do not read .agents/skills/, .codex/, or any .easy-coding/ file. All needed context is in
   the card.
@@ -18,25 +16,26 @@ Hard constraints:
 - Follow the task card's "Local Baseline": match nearby naming, control flow, null/error handling,
   layering, object modeling, method granularity, literal usage, and comment style unless a stated
   correctness, security, requirement, or hard-rule reason requires a deviation.
-- Treat the task card's "Code Comments" author value and field/member/constant rules as mandatory.
+- Treat the task card's "Code Comments" author value and field rules as mandatory.
 - Do not add generic defensive null checks, speculative abstractions/layers, fragmented one-use
   micro-methods, or a constant that exists only to hold one getter return.
 - Local, obvious magic values are allowed when they match surrounding code; create constants for
   reuse, stable domain/config/protocol semantics, or established project convention.
 - Every method and field in a new core Java class, and every added or materially modified method
-  or field in an existing core Java class, must have meaningful Javadoc; comment complex logic
-  where intent or constraints are not obvious.
+  or field in an existing core Java class, must have meaningful multiline Javadoc; use // for
+  ordinary one-line notes and comment complex logic where intent or constraints are not obvious.
+- Do not change unrelated comments, formatting, imports, names, or code. Keep one blank line
+  between coherent logic sections and revert formatter spillover outside the requested scope.
 - Treat acceptance criteria, test points, contracts, and risks in the card as required inputs.
-- Run the exact targeted checks requested by the card and report their real outcome.
+- Do not run quality commands unless the card explicitly marks TDD lifecycle execution required.
 - Preserve each existing file's original encoding; never silently convert.
 
 Output (return exactly this):
 - changed_files: the files you actually modified
 - summary: one line describing what you did
-- deliverable: full no-code result, or null for a code unit
 - issues: problems you hit (empty array if none)
 - needs_attention: anything the main agent must decide (empty array if none)
-- checks: commands run with pass/fail outcomes
+- checks: TDD lifecycle commands actually run, otherwise an empty array
 
 Do not claim a file is verified unless the card asked you to run a check and you ran it.
 """

package/templates/codex/agents/ec-reviewer.toml

@@ -18,8 +18,12 @@ Stance:
 - Do not request defensive null checks, abstraction, constant extraction, or legacy-wide comment
   cleanup solely as generic best practice. Flag unjustified local-style deviations, speculative
   layers, fragmented one-use micro-methods, constants created only for a getter return, and
-  missing Javadoc on any method/field in a new core Java class or any added/materially modified
-  method/field in an existing core Java class.
+  missing multiline Javadoc on any method/field in a new core Java class or any added/materially
+  modified method/field in an existing core Java class.
+- Treat unrelated comment, formatting, import, naming, or refactor changes as minimum-diff
+  violations. Do not ask to clean up untouched legacy code.
+- On the first pass, report the complete in-scope finding set. On a repair pass, review only the
+  repair delta and direct interactions; do not introduce unrelated style findings.
 - error means a demonstrated acceptance, contract, security, or build failure. Use warning
   for a credible risk and info for non-blocking maintainability advice.
 
@@ -30,6 +34,14 @@ Hard constraints:
 
 Output (return exactly this):
 - dimension: your assigned dimension
+- passed: true only when there are no error findings
+- implementation_fingerprint: copy unchanged from the task card
+- quality_attempt: copy unchanged from the task card
+- failure_classes: array of code-defect | test-defect | contract-ambiguity | environment for
+  blocking findings; empty when passed
+- reviewer: your canonical Agent identity
+- timestamp: current ISO timestamp with timezone
+- repo_id and source_task_id: copy unchanged when present in the task card
 - findings: array of {file, line, issue, severity} (severity: info | warning | error)
 - suggestion: optional fix direction per finding
 """

package/templates/codex/agents/ec-verifier.toml

@@ -16,12 +16,21 @@ What to do:
 - Capture the real exit status and output.
 
 Hard constraints:
-- Run only the requested check. Do not fix code, run other checks, or edit files.
+- Run only the requested check. Do not fix code, run other checks, or edit files. Keep the exact
+  task-card candidate fingerprints; never combine another candidate's output.
+- Distinguish environment/tooling failures from code or test failures in failures.
 - Do not call any Skill tool. Do not make stage decisions.
 
 Output (return exactly this):
-- check_type: lint | typecheck | test | build
+- check_type: lint | typecheck | test | build | coverage
+- check: copy unchanged from the task card
+- command: the exact command that was run
 - passed: true | false (from the real exit status)
+- quality_attempt: copy unchanged from the task card
+- failure_classes: array of code-defect | test-defect | contract-ambiguity | environment;
+  empty when passed
+- timestamp: current ISO timestamp with timezone
+- repo_id and source_task_id: copy unchanged when present in the task card
 - failures: array of failure messages (empty if passed)
 - command_output: the relevant tail of stdout/stderr
 - implementation_fingerprint: copy unchanged from the task card

package/templates/common/bundled-skills/ec-init/SKILL.md

@@ -210,7 +210,7 @@ agent must be able to see what was generated and on what evidence.
 - Every claim grounded in observed evidence — file paths and configs you actually read.
   No filler like "follow best practices".
 - SOUL stays short. RULES and ABSTRACT run as long as the evidence supports, in named
-  sections. TEST_STRATEGY must be concrete enough that ec-verification can derive runnable
+  sections. TEST_STRATEGY must be concrete enough that QUALITY's Verification Gate can derive runnable
   commands from it.
 
 ## Boundaries

package/templates/common/bundled-skills/ec-meta/references/local-architecture/README.md

@@ -42,23 +42,27 @@ analysis, workflow operation). The CLI never analyzes the project.
 
 ## Workflow state machine
 
-6 work stages + 2 terminals, owned by ec-workflow:
-`INIT → ANALYSIS → IMPLEMENT → REVIEW → VERIFICATION → MEMORY → COMPLETE`, plus `CLOSED`
+5 work stages + 2 terminals, owned by ec-workflow:
+`INIT → ANALYSIS → IMPLEMENT → QUALITY → MEMORY → COMPLETE`, plus `CLOSED`
 (user abort, no memory flow). INIT → ANALYSIS and completed MEMORY → COMPLETE are restricted
-automatic edges. A validated read-only `doc` / `analysis` / `report` task also auto-completes
-from IMPLEMENT after its full deliverable is shown, without REVIEW, VERIFICATION, MEMORY, or
-task memory. Approval mode controls non-mechanical edge waiting: approve confirms each edge,
+automatic edges. Pure read-only conversation stays Ready and creates no task; repository writes,
+including documentation and configuration, use the full graph. Approval mode controls edge waiting: approve confirms each edge,
 guard confirms two critical gates, confirm waits only at ANALYSIS -> IMPLEMENT, and auto
-advances every legal edge after mechanical gates. After green VERIFICATION, Harness freezes an
+advances every legal edge after mechanical gates. After green QUALITY, Harness freezes an
 acceptance checkpoint. A later code diff temporarily pauses every mode so the exact digest can be
 accepted; unchanged `confirm`/`auto` tasks remain automatic.
 Workflow mode is independently configured as adaptive/fast/standard/strict; ANALYSIS freezes
-adaptive to a concrete mode, and every new code task still enters REVIEW. REVIEW evidence is
-bound to the final implementation fingerprint, VERIFICATION evidence is bound to implementation
+adaptive to a concrete mode, and every mutation task still enters QUALITY. Its Review Gate is
+bound to the final implementation fingerprint; Verification Gate evidence is bound to implementation
 and config fingerprints, and an accepted post-checkpoint diff records its authorization plus
-carry-forward/targeted/waived policy without forcing a second REVIEW. MEMORY keeps the conditional
+carry-forward/targeted/waived policy without forcing a second review. MEMORY keeps the conditional
 long-memory threshold gate.
 
+`ec-lite` is an explicit session mode outside this graph. It offers one compact proposal and user
+confirmation before a minimal mutation, creates no task/QUALITY/MEMORY artifacts, and remains on
+until the user invokes it again. If a task is active, the user chooses whether to cancel startup,
+close the task, or clear only the session task pointer before Lite starts.
+
 Java TDD is a third independent, default-off control managed by `ec-config`. Session overrides
 project configuration; ANALYSIS freezes enabled state and the 1..100 changed-line threshold
 (default 90) on entry to IMPLEMENT. Disabled TDD changes no ordinary workflow test depth. Enabled
@@ -82,7 +86,7 @@ stage in `task.json`; no data is lost. Each task folder is self-contained.
 Each task is a folder. `task.json` is metadata, including the current stage, workflow proposal,
 frozen concrete mode, and any `pending_transition`; `dev-spec.md` is the human-readable plan;
 `execution.jsonl` is an append-only plan-and-log (one `plan` record, then `dispatch`/`result`
-/`review`/`verify`/`acceptance`/`handoff` records). Because plan and log live on disk, not in an agent's
+/`quality`/`review`/`verify`/`acceptance`/`handoff` records). Because plan and log live on disk, not in an agent's
 context window, a task survives session end and agent switches with zero information loss.
 
 ## Canonical Spec integration
@@ -103,7 +107,7 @@ keeps detailed evidence locally and projects cross-application Task/Step/depende
 `EDS:EXECUTION` through one CAS/idempotent writer. Static changes use revision + READY +
 `sync-spec-design`; agents never hand-edit the machine ledger. Explicit external locators are
 allowed and rebind only by exact Canonical identity. Source tasks stay `implemented` after local
-checks and become `verified` only when VERIFICATION -> MEMORY is applied under explicit or
+checks and become `verified` only when QUALITY -> MEMORY is applied under explicit or
 standing approval-mode authorization; the shared event includes the acceptance digest.
 
 ## Memory system

package/templates/common/skills/ec-analysis/SKILL.md

@@ -31,7 +31,7 @@ that a bounded task might be complicated.
 For a task with `task.json.spec_source`, re-run `inspect-dev-spec` against the stored source, exact
 `selected_spec_tasks`, and only their stored `task.repo_paths` bindings. Schema, Spec ID, design
 revision, and `design_sha256` must still match. A changed `document_sha256` with the same design is
-normal shared progress; refresh `execution_revision` without invalidating plan/review/verify
+normal shared progress; refresh `execution_revision` without invalidating plan/QUALITY
 evidence. An execution revision rollback is blocking. Then call the selector once for the exact
 selection:
 
@@ -156,9 +156,10 @@ these markers mechanically.
 Prefer one coherent unit over artificial file-level splitting. Do not split a class or method by
 line count, or create many one-use helpers, merely to make the plan look modular. Extract only a
 clear semantic boundary, reuse point, or independently testable responsibility. Use parallel only
-for truly independent write scopes. Better unit contracts reduce later REVIEW rework.
+for truly independent write scopes. Better unit contracts reduce later QUALITY rework.
 
-Code tasks require `test-strategy.md`; explicit `doc`, `analysis`, and `report` tasks do not.
+Every Harness task is a repository-mutation task and requires `test-strategy.md`. Pure read-only
+conversation never enters ANALYSIS and creates no task.
 
 ## Optional Java TDD analysis
 
@@ -221,15 +222,15 @@ self-reported floor. The state API rechecks the floor when the proposal is saved
 
 The calculation is intentionally Standard-centered:
 
-- `fast`: one coherent, non-parallel unit in one actually modified repository, at most five
+- `fast`: up to three coherent low-risk units in one actually modified repository, at most eight
   changed files, no explicit high-risk signal, and no public or cross-repository contract impact.
   Small parameter changes, bounded field/mapping edits, and a few ordinary model files should
   normally remain Fast.
-- `standard`: the default for ordinary business work. Multiple units/files, bounded compatibility
-  work, actual but contained multi-repository changes, broad low-risk work, and bounded high-risk
-  work remain Standard.
+- `standard`: the default for ordinary business work. Four or more units, more than eight files,
+  bounded compatibility work, actual but contained multi-repository changes, broad low-risk work,
+  and bounded high-risk work remain Standard.
 - `strict`: requires both an explicit high-risk signal and concrete complexity/blast-radius
-  evidence. Complexity means actual multi-repository edits, at least four units, at least ten
+  evidence. Complexity means actual multi-repository edits, at least five units, at least fifteen
   changed files, or a public/cross-repository contract. Parallel execution is a Standard signal
   by itself. Generic domain words in a risk description, title, file path, Spec repository
   catalog, or unselected task are never sufficient evidence of high risk.

package/templates/common/skills/ec-config/SKILL.md

@@ -34,9 +34,9 @@ task freezes its effective TDD values when ANALYSIS advances to IMPLEMENT; later
 changes affect future tasks and ANALYSIS only.
 
 Approval semantics stay independent from verification depth: `approve` waits at each
-non-mechanical edge, `guard` waits at ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY, `confirm`
+non-mechanical edge, `guard` waits at ANALYSIS -> IMPLEMENT and QUALITY -> MEMORY, `confirm`
 waits only for the plan, and `auto` advances legal green edges immediately. Every mode temporarily
-pauses only when code changes after the frozen VERIFICATION checkpoint, because the user must see
+pauses only when code changes after the frozen QUALITY checkpoint, because the user must see
 and accept that exact new diff; this exception does not convert `auto` into `guard`.
 
 ## Project configuration

package/templates/common/skills/ec-implementing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ec-implementing
-description: IMPLEMENT-stage skill. Executes the confirmed plan with workflow-mode-aware orchestration, strict scope control, shift-left tests, and structured execution evidence.
+description: IMPLEMENT-stage skill. Executes the confirmed plan with workflow-mode-aware orchestration, strict scope control, minimal diffs, and structured execution evidence.
 ---
 
 # ec-implementing — execute the confirmed plan
@@ -9,9 +9,10 @@ Use only after ANALYSIS has frozen `task.json.workflow_mode` to `fast`, `standar
 `strict`. Read `dev-spec.md`, the latest `plan` record in `execution.jsonl`, relevant RULES
 and ABSTRACT sections, and `test-strategy.md` for code tasks.
 
-If frozen `task.tdd_enabled` is not `true`, preserve the existing shift-left behavior exactly;
-do not load the Java coverage tool, require RED/GREEN/REFACTOR, inspect CI, or run extra test
-commands. TDD is an independent opt-in mode, not an implicit consequence of strict workflow.
+If frozen `task.tdd_enabled` is not `true`, IMPLEMENT writes production and planned test code but
+does not run lint, typecheck, test, build, or coverage commands. Deterministic execution belongs
+to QUALITY's Verification Gate. TDD is the only exception because RED/GREEN/REFACTOR commands are
+part of the implementation method; current-fingerprint green evidence may be reused by QUALITY.
 
 When frozen TDD is enabled, every feature/bug unit must capture a meaningful failing unit test
 before production code (RED), the smallest passing implementation (GREEN), and a green refactor.
@@ -28,45 +29,49 @@ Communicate with the user in the user's language.
 2. Preserve existing encoding and project comment conventions.
 3. Each unit must carry `acceptance_criteria`, `test_points`, `contracts`, and `risks`.
    Missing unit context is an analysis defect; do not make the implementer rediscover it.
-4. Run the unit's cheapest meaningful test immediately after its implementation. Do not wait
-   until VERIFICATION to discover local contract mistakes.
+4. Do not execute quality commands in non-TDD IMPLEMENT. Preserve exact commands and test points
+   for the Verification Gate instead of duplicating them here.
 5. Append `dispatch` and `result` records for every unit, including main-agent execution.
    Main-agent execution uses `reason:"main-inline:<workflow_mode>"`.
-6. A code task never transitions directly from IMPLEMENT to VERIFICATION. Every new code task
-   enters REVIEW.
-7. Read-only `doc` / `analysis` / `report` tasks remain `single` with `files:[]`, make no writes,
-   return a non-empty `deliverable`, then follow the mode-aware IMPLEMENT -> COMPLETE edge.
-8. When a project template, local convention, or new source header uses author attribution, the
+6. Every Harness task transitions from IMPLEMENT to QUALITY.
+7. When a project template, local convention, or new source header uses author attribution, the
    author value must be `<Current Agent Name> with Easy Coding`, for example
    `Codex with Easy Coding`. `Current Agent Name` means the user-facing host Agent (for example,
    Codex, Claude, or Qoder), never an implementation sub-agent role such as `ec-implementer`.
    This value is display attribution only: never pass it to the workflow state API's `--agent`,
    which accepts only `claude-code`, `codex`, or `qoder`. Never copy a previous human or Agent name
    into newly authored code.
-9. Every newly added field in a data-bearing model must have a meaningful field-level comment.
+8. Every newly added field in a data-bearing model must have a meaningful field-level comment.
    This includes new or extended entity/DO/DTO/VO/BO, request/response, configuration, and similar
-   model types. Every new enum member and every new declared constant requires the same treatment.
+   model types. Document enum members and stable domain constants when the local style or
+   non-obvious semantics require it; do not extract a literal merely to create a documented name.
    Describe the semantic meaning and, when relevant, units, format, allowed values, nullability,
    default behavior, or compatibility constraints. A type-level comment does not replace comments
    on its fields or members; do not add low-value comments to ordinary local variables.
-10. Treat the task card's `Local Baseline` as the default implementation shape. Match the nearest
+9. Treat the task card's `Local Baseline` as the default implementation shape. Match the nearest
     comparable code's naming, control flow, null/empty and error handling, layering, object model,
     and extraction granularity unless correctness, security, an explicit requirement, or a hard
     project rule requires a deviation. Do not add defensive null checks solely because they are a
     generic best practice when the evidenced local contract intentionally omits them.
-11. Implement the smallest coherent design. Do not add speculative abstractions, wrappers,
+10. Implement the smallest coherent design. Do not add speculative abstractions, wrappers,
     factories, layers, or extension points, and do not fragment one readable flow into many
     single-use micro-methods. Extract code only for a clear semantic boundary, real reuse,
     independent testability, or a material reduction in complexity.
-12. Literals and magic values are allowed when they are obvious, local, and consistent with the
+11. Literals and magic values are allowed when they are obvious, local, and consistent with the
     surrounding code. Introduce a constant for repeated use, stable domain/config/protocol
     semantics, or an established project convention—not merely to hold the single return value of
     a getter.
-13. In a newly added core Java class, every method and field requires meaningful Javadoc. In an
+12. In a newly added core Java class, every method and field requires meaningful Javadoc. In an
     existing core Java class, every added or materially modified method and field requires it.
     Add focused inline comments to core or complex logic to explain intent, constraints, or
     non-obvious tradeoffs. Do not mass-retrofit untouched legacy code, and for non-Java code
-    follow the language's doc-comment form plus the evidenced project convention.
+    follow the language's doc-comment form plus the evidenced project convention. Java Javadoc
+    must use a multiline `/** ... */` block; use `//` for an ordinary one-line logic note.
+13. Apply the minimum-change rule to existing files. Do not reformat, rename, comment, reorder
+    imports, or refactor unrelated code. Revert formatter spillover outside the required diff;
+    report unrelated defects instead of fixing them without an approved scope change.
+14. Use one blank line between coherent logic sections. Do not create noisy blank-line gaps or
+    compress unrelated steps into an unreadable block.
 
 ## Choose the execution owner
 
@@ -88,7 +93,7 @@ Communicate with the user in the user's language.
 
 - Dispatch multi-unit or high-risk implementation to sub-agents using {{sub_agent_dispatch}}.
 - For a truly indivisible unit, the main Agent may implement only when dispatch adds no
-  independence; record why and require independent REVIEW later.
+  independence; record why and require independent Review Gate evidence in QUALITY.
 - Process dependency levels in order. Platform spawn rule: {{platform_spawn_instruction}}
 
 The main Agent owns orchestration, conflict resolution, evidence writing, and stage decisions.
@@ -107,7 +112,7 @@ Sub-agents never dispatch other sub-agents or read `.easy-coding` workflow asset
 ## Repository     {repo_id + resolved repository root | current project}
 ## Source Steps   {source_step_ids | NONE}
 ## Symbols        {symbols | confirmed local symbols}
-## Editable Scope {unit.files | NONE — read-only}
+## Editable Scope {unit.files}
 ## Acceptance     {unit.acceptance_criteria}
 ## Test Points    {unit.test_points and exact targeted commands}
 ## Contracts      {inputs, outputs, invariants shared with other units}
@@ -118,7 +123,7 @@ Sub-agents never dispatch other sub-agents or read `.easy-coding` workflow asset
 ## Architecture   {pre-digested ABSTRACT sections}
 ## Output
 status:"completed", repo_id|null, source_task_id|null, changed_files[], summary,
-deliverable|null, checks:[{command,passed,failures:[]}], issues:[], needs_attention:[]
+checks:[], issues:[], needs_attention:[]
 ```
 
 ## Dispatch and result loop
@@ -134,15 +139,17 @@ deliverable|null, checks:[{command,passed,failures:[]}], issues:[], needs_attent
    author value, the field/member/constant rules, and the core Java Javadoc rule above. Populate
    `Local Baseline` from the Unit's analyzed evidence; sub-agents do not read this Skill.
 2. Execute according to dependency order and selected owner.
-3. Run targeted unit tests and self-audit scope, contracts, TODOs, and introduced warnings.
-   Also audit new author attributions and every new model field, enum member, and constant against
+3. For non-TDD work, do not run tests; self-audit scope, contracts, TODOs, and introduced warnings.
+   For TDD, run only the lifecycle commands required by RED/GREEN/REFACTOR. Also audit new author
+   attributions and every new model field against
    the comment requirements above, then check local-style deviations, unnecessary abstractions,
    one-use constant extraction, and affected core Java Javadoc before recording success.
 4. Append one `result` record. Only a successful unit uses `status:"completed"`; include
    unresolved issues rather than hiding them, and do not advance while `issues` or
    `needs_attention` is non-empty.
    For Canonical-backed success, write each owned source Step `completed` through
-   `writeback-spec-step`, with passed evidence for every bound Canonical Test ID and a stable key.
+   `writeback-spec-step`, with implementation evidence and a stable key. Canonical Test evidence
+   is written by QUALITY after deterministic verification, not fabricated during implementation.
    After every source Step for that task is complete, write the task `implemented`. On failure,
    write the affected Step `failed`; the shared writer moves its task to `blocked`. Local evidence
    is appended first, shared projection second, and the returned acknowledgment last.
@@ -161,9 +168,7 @@ conversation overhead while keeping work observable.
 
 ## End state
 
-- Code task: after all units and targeted checks pass, hand control to ec-workflow for
-  IMPLEMENT -> REVIEW.
-- Read-only task: output the full deliverable, then request or auto-apply IMPLEMENT -> COMPLETE.
+- After all units are implemented, hand control to ec-workflow for IMPLEMENT -> QUALITY.
 - New risk above the frozen mode: call `raise-workflow-mode`; modes may rise but never silently
   fall after ANALYSIS.
 
@@ -171,12 +176,12 @@ conversation overhead while keeping work observable.
 
 - [ ] Every changed file is in scope and keeps its encoding.
 - [ ] Every unit has a dispatch/result pair and satisfied its acceptance criteria.
-- [ ] Targeted tests ran or a concrete blocker is recorded.
+- [ ] Non-TDD quality commands were deferred; required TDD lifecycle commands have real evidence.
 - [ ] Cross-unit contracts still match.
 - [ ] The implementation follows the evidenced Local Baseline or records a required deviation.
 - [ ] No speculative layer, fragmented micro-method set, or single-use getter constant was added.
 - [ ] New author attributions use the user-facing host `<Current Agent Name> with Easy Coding`.
-- [ ] Every new model field, enum member, and constant has a meaningful field-level comment.
+- [ ] Every new model field and every non-obvious documented member follows the local comment rule.
 - [ ] Every method/field in a new core Java class, and every added or materially modified one in
       an existing core Java class, has Javadoc.
-- [ ] Code tasks enter REVIEW, regardless of workflow mode.
+- [ ] The task enters QUALITY, regardless of workflow mode.

package/templates/common/skills/ec-lite/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: ec-lite
+description: Toggle and operate Easy Coding Lite Direct mode for explicit minimal repository changes without task, QUALITY, or MEMORY artifacts.
+---
+
+# ec-lite — explicit direct mode
+
+`ec-lite` is controlled only by the user. Never enable it automatically from task size, Workflow
+Mode, or inferred intent. Communicate in the user's language.
+
+## Toggle
+
+Read the current snapshot. If Lite is enabled, a repeated explicit invocation exits it:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py disable-lite \
+  --agent <agent-id> --session-file <P>
+```
+
+If Lite is disabled, call `enable-lite` without a policy. When there is no active task it enables
+immediately. When the API returns `lite-active-task-decision-required`, show the task ID, title,
+and stage, then use the native choice UI with exactly these actions:
+
+1. Cancel Lite startup: call `enable-lite --active-task-policy cancel`.
+2. Close the task and start Lite: call
+   `enable-lite --active-task-policy close --expected-task-id <shown-id>`; this preserves task
+   files/history and records `user-switched-to-lite`.
+3. Ignore the original task and start Lite: call
+   `enable-lite --active-task-policy ignore --expected-task-id <shown-id>`; this clears only the
+   current session task pointer and does not change the task or Canonical state.
+
+Never select a branch for the user. If the task ID changed while waiting, show the new decision
+instead of applying the old choice. Legacy `confirm_mode:lite` is only a migration alias for Guard
++ Fast and is unrelated to Lite Direct.
+
+## Lite behavior
+
+The status line must remain `Lite Direct` with `No Task / Quality / Memory`. Do not create task
+folders, Dev-Specs, plans, test strategies, execution records, QUALITY evidence, or memory.
+
+Pure read-only or ambiguous requests stay `Lite Direct · Ready` and use ordinary conversation.
+For an explicit repository mutation:
+
+1. Read only relevant EC rules, architecture, memory, nearest comparable code, and Git diff.
+2. Present one compact proposal: behavior, exact target files, minimum-change boundary, and any
+   necessary risk. Do not edit yet.
+3. Record the proposal and use its returned digest:
+
+   ```bash
+   {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-lite-proposal \
+     --summary "<safe compact summary>" [--target-file <path>]... \
+     --agent <agent-id> --session-file <P>
+   ```
+
+4. Ask the user to confirm the exact proposal. On confirmation call
+   `confirm-lite-proposal --digest <digest>`. The state API captures the current Git baseline when
+   the proposal is created and includes it in the digest; each proposal carries a fresh one-time
+   nonce, so even an identical replacement has a new digest and a confirmed digest cannot be
+   replayed or used with a rewritten baseline. Confirmation also requires the current Git state
+   to still match the captured baseline; otherwise replace and re-present the proposal;
+   target files must be 1..50 safe project-relative files in the current project repository.
+   Harness-owned `.easy-coding/sessions/` metadata is excluded from business change detection and
+   cannot be a target. Then implement only those files.
+5. If scope expands, stop, replace the proposal, and confirm again.
+6. Apply local style, core Java Javadoc, logical blank lines, and minimum modification exactly as
+   normal Easy Coding. Do not run tests by default; run only a command explicitly requested by
+   the user or mandated by a project/global hard rule.
+7. Report changed files and any command actually run, then call
+   `complete-lite-proposal --digest <digest>`. Completion fails if no confirmed target changed,
+   another file changed after confirmation, or Git HEAD moved. Re-present the proposal rather
+   than bypassing that result. Lite remains enabled for the next request.
+
+Lite intentionally omits TDD, QUALITY, MEMORY, task history, and completion transitions. Use a
+normal Fast task instead when the user wants those guarantees.

package/templates/common/skills/ec-no-harness/SKILL.md

@@ -25,6 +25,9 @@ After the command succeeds:
   skills, and every other hook.
 - Do not clear `current_task`, delete a pending transition, or modify task state. The task is
   suspended intact and can resume after restoring Easy Coding or in a new session.
+- Preserve `lite_mode` and any exact Lite proposal while bypassed. No-Harness has display and
+  routing priority; restoring Easy Coding resumes the same Lite state until the user explicitly
+  exits it through `ec-lite`.
 
 If the invocation contains no request beyond enabling the bypass, briefly confirm that native
 mode is active for the current session.