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

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

@@ -0,0 +1,153 @@
+---
+name: ec-quality
+description: QUALITY-stage skill. Freezes one candidate, runs independent Review and Verification gates at the selected workflow depth, and aggregates one repair decision.
+---
+
+# ec-quality — one candidate, two read-only gates
+
+Use only while the current task is in `QUALITY`. Communicate in the user's language. QUALITY
+does not modify source, tests, configuration, plans, or task scope.
+
+## Candidate freeze
+
+Call `evidence-fingerprints` once and use the returned implementation/config fingerprints for
+the whole attempt. It also returns the runtime-owned `quality_attempt` number, start time, evidence
+boundary, and repair count. Every Review and Verification record in this attempt must carry that
+same candidate fingerprint and `quality_attempt` number. If the candidate changes, return to
+IMPLEMENT; the state API finalizes the old attempt as `cancelled` before the transition. Never mix
+evidence from two candidates.
+
+`execution.jsonl` is append-only. Do not write `type:"quality"` yourself. The state API appends
+exactly one fingerprint-bound finalized record when QUALITY passes, leaves for repair/replan, or is
+cancelled by candidate drift, rework, or task closure. Retries reuse that record instead of
+duplicating it. An incomplete, duplicate, or out-of-sequence quality record blocks the transition.
+
+Review Gate and Verification Gate are independent and may run in parallel. Review never executes
+commands. Verification never edits files. If a hard blocker makes remaining work meaningless,
+cancel the other checks explicitly and record the cancellation; do not start repair while a gate
+is still running or unacknowledged.
+
+## Workflow depth
+
+### Fast
+
+- Main Agent performs one focused self-review of the exact diff, contract, local style, Javadoc,
+  and minimum-change boundary.
+- Run the smallest deterministic targeted verification that can prove the changed behavior.
+- Do not dispatch an independent reviewer unless a concrete risk appears.
+
+### Standard
+
+- Dispatch one independent reviewer.
+- Run affected lint/typecheck/test plus every must-test command from `test-strategy.md`.
+- Run Review and Verification in parallel when their inputs are already frozen.
+
+### Strict
+
+- Dispatch at least two independent review dimensions, normally correctness and compliance.
+- For each actually modified repository, run all applicable lint, typecheck, test, and build
+  checks. A repository merely mentioned by a Spec, dependency, supermodule, or path map is not in
+  scope.
+- When frozen TDD is enabled, include the required TDD review dimension, local unit test, and
+  changed-production-line coverage. Record one coverage result with `coverage_scope:"local"`;
+  GitLab coverage is informative, not a task acceptance gate. Reuse current-fingerprint GREEN
+  evidence from IMPLEMENT instead of rerunning an identical command.
+
+## Review Gate
+
+Review only the confirmed diff and its direct interactions. Check acceptance behavior, contract
+compatibility, security/correctness, test design, nearest local style, required core Java
+Javadoc, logical blank-line grouping, and minimum modification.
+
+Do not demand defensive null checks, constant extraction, abstractions, method splitting,
+comments, formatting, or cleanup solely as generic best practice. Do not report unrelated legacy
+issues as task findings. The first review must report the complete in-scope finding set; after a
+repair, review only the repair delta and directly affected interactions, without introducing new
+unrelated style findings.
+
+Each review record uses the existing `type:"review"` contract and includes the active
+`quality_attempt`. `error` is blocking; `warning` is a credible risk; `info` is non-blocking. Fast
+self-review still writes a record with reviewer set to the current canonical Agent identity. A
+blocking record also carries a `failure_classes` array; do not defer classification to prose.
+
+## Verification Gate
+
+Run only the commands selected by the mode and `test-strategy.md`. Record real exit status and
+current implementation/config fingerprints plus the active `quality_attempt` using the existing
+`type:"verify"` contract. Do not run a command inside Review Gate, and do not fix a failure inside
+Verification Gate. A failed applicable check also carries its structured `failure_classes` array.
+
+Classify an unavailable tool, dependency outage, or other environmental failure as
+`environment`. Keep the task in QUALITY and retry that check when possible; environmental retry
+does not invalidate a passed Review Gate.
+
+## One repair bundle
+
+Wait for both gates, then aggregate all blocking results once. Classify each item as:
+
+- `code-defect`
+- `test-defect`
+- `contract-ambiguity`
+- `environment`
+- `suggestion`
+
+If code or tests need edits, create one concise Repair Bundle containing every in-scope blocking
+item, affected files, required verification, and evidence that may be reused. After both Gates are
+terminal, finalize the decision before transitioning once to IMPLEMENT:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py finalize-quality \
+  --outcome repair --review-gate failed --verification-gate cancelled \
+  --failure-class code-defect \
+  --summary "<aggregated repair decision>" \
+  --agent <agent-id> --session-file <P>
+```
+
+Use one `--failure-class` per class. A failed Gate requires blocking evidence in the active attempt;
+a Gate stopped after another hard blocker must be explicitly `cancelled`. Contract ambiguity has
+routing priority: finalize `--outcome replan --failure-class contract-ambiguity`, preserve every
+code/test class found in the same attempt, and return once to ANALYSIS. Environment failures are not
+finalized as repair or replan: keep the attempt in QUALITY and retry the affected check. Suggestions
+do not block.
+
+For a Canonical-backed task, group the bundle by `source_task_id`. Append every failed local
+review/verify record first, then write each affected source task `blocked` through
+`writeback-spec-task`. For attempt `<A>`, candidate `<F>`, Harness task `<H>`, and source task `<S>`,
+use the exact idempotency key `<H>:<S>:<F>:quality-<A>:blocked`. Add one failed evidence object for
+each affected Gate kind with ref
+`execution.jsonl#quality-attempt=<A>;implementation=<F>;source-task=<S>;kind=review|verify`.
+Only after every blocked writeback is acknowledged may the task return to IMPLEMENT; the state API
+rejects a writeback from another run, attempt, fingerprint, or evidence window. Entering IMPLEMENT
+reopens only those blocked source tasks as a new `in_progress` attempt, while unaffected implemented
+tasks keep their shared conclusion.
+
+After repair, choose the minimum honest evidence refresh:
+
+- comment/format-only: carry semantic review; rerun affected lint;
+- test-only: review the test delta; rerun the affected test;
+- localized business code: delta review plus impacted tests;
+- contract/config/plan/shared behavior: rerun all applicable gates for the affected scope.
+
+When uncertain, rerun rather than infer. On the next attempt, the state API emits an append-only
+`quality-carry-forward` record only for Canonical repositories whose plan and repository content
+fingerprints are unchanged and whose sources are not hard/contract downstream of a changed source;
+it references the exact passed evidence indices from the consumed repair attempt. Never copy or
+relabel old evidence yourself. Strict may consume that state-owned record for independent,
+unaffected repositories, but must rerun every affected or dependency-invalidated repository gate.
+
+## Acceptance boundary
+
+When both gates pass, call:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py quality-checkpoint \
+  --agent <agent-id> --session-file <P>
+```
+
+Request or auto-apply `QUALITY -> MEMORY` according to Approval mode. If the checkpoint detects a
+later user edit, call `inspect-transition-drift`, display the exact diff, and honor the user's
+decision. An accepted diff may use carry-forward, targeted, or waived verification as recorded by
+the state API; do not rerun Review after the user explicitly accepts the displayed change.
+
+Canonical-backed tasks write selected tasks `verified` only when `QUALITY -> MEMORY` is actually
+applied. Pending integration evidence blocks that transition before MEMORY begins.

package/templates/common/skills/ec-task-management/SKILL.md

@@ -14,7 +14,7 @@ Call the state API snapshot and show:
 
 - current task, stage, last Agent, and pending transition;
 - task `concrete_workflow_mode` and frozen TDD state when present;
-- harness enabled/disabled state;
+- harness enabled/disabled and Lite Direct state;
 - active and resumable tasks.
 - for Canonical-backed tasks: source locator/path mode, Spec ID/design revision/design digest,
   document digest, execution revision, writeback status, selected task IDs, repository
@@ -29,10 +29,14 @@ Support listing, creating, selecting, claiming, handing off, and closing tasks t
 state API. Preserve pending transitions when inspecting tasks. Never infer user
 acceptance from opening this panel.
 
-When creating from a Canonical Spec, call `inspect-dev-spec`, display the complete task and
-dependency selection, then call `select-dev-spec-scope` and `create-task-from-spec` only after
-explicit user selection. Multiple selected Spec tasks still create one Harness task, while the
-selector returns one deterministic consumption closure per selected repository.
+Create tasks only for explicit repository mutations. Pure analysis, explanation, reporting, and
+read-only review stay Ready and are answered directly. If Lite Direct is enabled, route task
+selection or creation to `ec-lite` so the user can exit it first.
+
+When creating from a Canonical Spec, call `inspect-dev-spec --manifest-only`, display the complete
+task and dependency selection, then call `create-task-from-spec` only after explicit user
+selection. Multiple selected Spec tasks still create one Harness task. Do not call
+`select-dev-spec-scope` during routing; ANALYSIS owns the single consumption-closure read.
 Initialize missing shared execution before creation. Support `rebind-spec-source` only when the
 new file matches schema + spec_id + design revision + design_sha256 and does not roll execution
 revision backward. A pending writeback is repaired with `reconcile-spec-execution`, never by

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

@@ -71,7 +71,7 @@ evidence only, and never wait for a pipeline URL, job identity, or remote succes
 ## Readiness receipt and verification
 
 At the end of IMPLEMENT, after the infrastructure files are stable, record their fingerprints.
-The receipt is part of the implementation and must exist before REVIEW so review/verification
+The receipt is part of the implementation and must exist before QUALITY so Review/Verification
 fingerprints do not change after review. The recorder automatically includes the harness-managed
 `.easy-coding/tools/easy_coding_java_coverage.py` fingerprint:
 
@@ -84,7 +84,8 @@ python3 .easy-coding/tools/easy_coding_tdd_readiness.py --cwd . record \
   --agent <agent-id>
 ```
 
-REVIEW includes the receipt and its declared infrastructure boundary. VERIFICATION runs the
+QUALITY Review Gate includes the receipt and its declared infrastructure boundary. Its
+Verification Gate runs the
 frozen Workflow Mode's applicable build/test/CI syntax checks, then performs only the read-only
 readiness check:
 
@@ -92,9 +93,9 @@ readiness check:
 python3 .easy-coding/tools/easy_coding_tdd_readiness.py --cwd . check
 ```
 
-The `VERIFICATION -> MEMORY` gate requires the final check to return `ready`. If any recorded
+The `QUALITY -> MEMORY` gate requires the final check to return `ready`. If any recorded
 build or CI file changes after the receipt was created, readiness becomes `needs_init`; return to
-IMPLEMENT, refresh the receipt, and repeat REVIEW before verifying again. Rerun this skill when
+IMPLEMENT, refresh the receipt, and repeat QUALITY. Rerun this skill when
 the same drift occurs after task completion.
 
 After completion, tell the user that TDD remains off and provide the explicit project/session

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

@@ -1,6 +1,6 @@
 ---
 name: ec-workflow
-description: Main Easy Coding entrypoint. Creates or resumes a task, orchestrates the unchanged state machine, separates approval from execution depth, and dispatches the stage skill for the current state.
+description: Main Easy Coding entrypoint. Creates or resumes a task, orchestrates the unified state machine, separates approval from execution depth, and dispatches the stage skill for the current state.
 ---
 
 # ec-workflow — state orchestration
@@ -11,26 +11,24 @@ user's language.
 ## State machine
 
 ```text
-INIT --auto--> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY --auto--> COMPLETE
-                    ^           ^          |              |
+INIT --auto--> ANALYSIS -> IMPLEMENT -> QUALITY -> MEMORY --auto--> COMPLETE
+                    ^           ^          |
                     +--replan---+          +---repair-----+
 
-read-only doc/analysis/report: IMPLEMENT -> COMPLETE
 any active stage --explicit user abort--> CLOSED
 ```
 
-New code tasks never skip REVIEW. `workflow_mode` changes execution depth inside stages, not
-the stage graph. Pre-0.9 in-flight tasks may carry `workflow_mode_legacy:true` for proposal or
-review-evidence compatibility. Only `workflow_mode_legacy_direct_edge:true`, created from old
-lite semantics or an already-persisted edge, permits one IMPLEMENT -> VERIFICATION transition.
+Every repository-mutation task uses this graph. QUALITY owns two independent read-only gates:
+Review Gate and Verification Gate. `workflow_mode` changes their evidence depth, not the graph.
+Pure conversation, explanation, analysis, and read-only review stay Ready and create no task.
 
 ## Independent controls
 
 - `approval_mode = approve|guard|confirm|auto` controls whether a legal transition waits for a
-  user. `confirm` waits only at ANALYSIS -> IMPLEMENT; after that, green REVIEW, VERIFICATION,
-  MEMORY, and COMPLETE transitions advance automatically. `auto` advances every legal green
+  user. `confirm` waits only at ANALYSIS -> IMPLEMENT; after that, green QUALITY, MEMORY, and
+  COMPLETE transitions advance automatically. `auto` advances every legal green
   edge. The only additional pause is an exceptional code diff detected after the frozen
-  VERIFICATION acceptance checkpoint; accepting that exact diff does not change the mode.
+  QUALITY acceptance checkpoint; accepting that exact diff does not change the mode.
 - `workflow_mode = adaptive|fast|standard|strict` controls execution cost and assurance depth.
 - `tdd_enabled` independently activates Java TDD and changed-line coverage. It defaults off;
   `tdd_coverage_threshold` defaults to 90 and accepts integers from 1 to 100.
@@ -61,6 +59,9 @@ or `qoder`. Never use a display or source-author attribution such as `Codex with
    {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py snapshot --agent <agent-id> --session-file <P>
    ```
 
+   When `[easy-coding:lite-direct]` is present, route only to `ec-lite`. Do not create, resume,
+   inspect, or transition a normal Harness task until Lite is explicitly exited.
+
 2. Check `.easy-coding/tasks/project-init/task.json` before routing work.
    - Missing: tell the user to run `easy-coding init` to install or repair the harness, then stop.
    - Present with `status != "COMPLETE"`: invoke `{{skill_trigger}}ec-init`, then stop.
@@ -126,14 +127,13 @@ or `qoder`. Never use a display or source-author attribution such as `Codex with
    If the user names or clearly matches another task, confirm the switch and call
    `claim-task --task-id <id> --agent <agent-id> --session-file <P>`. Do not execute task A
    under task B's request.
-   - With no concrete task request, show resumable tasks or report readiness; never create an
-     empty task from a bare workflow invocation.
+   - With no explicit repository-mutation request, stay Ready and answer normally. Ambiguous
+     intent remains Ready until conversation establishes a concrete mutation.
    - For concrete unrelated work while another task is current, confirm creating the new task
      and suspending the current pointer before changing ownership.
    - Create a new task only after routing is settled, using a safe unique ID and a type faithful
-     to the requested deliverable. Feature, bugfix, refactor, performance, and workflow changes
-     are code tasks. Use `doc`, `analysis`, or `report` only when the user explicitly requested
-     a no-code deliverable; never downgrade a code request to the read-only completion path.
+     to the requested repository mutation. A document, config, or report file write is still a
+     mutation task. Never create `doc`, `analysis`, or `report` tasks for a chat-only result.
 6. Resume the matched/current task, then load only state-relevant assets. Do not read five full
    memories at every startup; ANALYSIS searches memory metadata and opens relevant entries on
    demand.
@@ -144,9 +144,8 @@ or `qoder`. Never use a display or source-author attribution such as `Codex with
 - `INIT`: call `auto-transition --stage ANALYSIS`.
 - `ANALYSIS`: dispatch `ec-analysis`; it produces artifacts and a workflow proposal.
 - `IMPLEMENT`: dispatch `ec-implementing` using the frozen concrete mode.
-- `REVIEW`: dispatch `ec-reviewing`; the transition requires current fingerprint evidence.
-- `VERIFICATION`: dispatch `ec-verification`; the MEMORY boundary requires green evidence and an
-  unchanged or explicitly accepted verification checkpoint.
+- `QUALITY`: dispatch `ec-quality`; it freezes one candidate, runs Review and Verification Gates,
+  aggregates one repair bundle, and requires an unchanged or explicitly accepted checkpoint.
 - `MEMORY`: dispatch `ec-memory`.
 - `COMPLETE` / `CLOSED`: report terminal status and clear stale session ownership.
 
@@ -178,23 +177,17 @@ current `diff_sha256`, then use the platform's native choice UI for these branch
 
 1. Accept this exact diff and continue to MEMORY (recommended only with the stated verification
    policy).
-2. Return to IMPLEMENT because the change needs normal repair/review.
+2. Return to IMPLEMENT because the change needs normal repair/quality checks.
 3. Hand off to another Agent.
 4. Other / revise.
 
 Never call `auto-transition` repeatedly to hide this pause. If the user accepts, preserve the
-existing REVIEW conclusion and call `confirm-transition` with the exact digest,
+existing Review Gate conclusion and call `confirm-transition` with the exact digest,
 `--verification-policy carry-forward|targeted|waived`, and a decision summary. `targeted` needs a
 passed current-fingerprint targeted check first. If the digest changes, inspect and present the
 new diff. Config, plan, workflow, Canonical-design, or nested-repository drift is not an
 acceptance-diff choice and returns to the stage required by the state API.
 
-For a migrated pre-0.9 Lite task, the breadcrumb
-`[easy-coding:lite-review-bypass-required:IMPLEMENT->REVIEW]` means the stored REVIEW edge is
-stale. Call `cancel-transition`, then immediately call `auto-transition --stage VERIFICATION`.
-Do not consume, confirm, or recreate the REVIEW edge; the state API will consume the task's
-one-time `workflow_mode_legacy_direct_edge` compatibility marker on the direct transition.
-
 ## Mode escalation
 
 When implementation reveals a higher risk, call:
@@ -205,8 +198,8 @@ When implementation reveals a higher risk, call:
   --agent <agent-id> --session-file <P>
 ```
 
-Only upward changes are legal after ANALYSIS. During VERIFICATION, return to IMPLEMENT before
-raising the mode so the task re-enters REVIEW with fresh evidence. Scope or design changes return
+Only upward changes are legal after ANALYSIS. During QUALITY, return to IMPLEMENT before
+raising the mode so the task re-enters QUALITY with fresh evidence. Scope or design changes return
 to ANALYSIS.
 
 ## Handoff and closure

package/templates/main-constraint/AGENTS.md.tpl

@@ -20,6 +20,7 @@ disabled, omit the TDD segment entirely and preserve the existing status-line fo
 - Waiting init: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Waiting init · Use `ec-init` to initialize
 - Active task: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · `{current-task}` · `{workflow-state}`
 - Handoff: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
+- Lite: > **Easy Coding** · **Lite Direct** · `{Ready|Awaiting Confirmation}` · No Task / Quality / Memory · Use `ec-lite` to exit
 
 Skill names in the status line are bare names (`ec-init`, `ec-workflow`) and never include
 platform prefixes such as `/` or `$`. If no status line is injected, do not invent one.
@@ -31,10 +32,11 @@ Trigger Easy Coding skills with your platform prefix — Codex: `$ec-*`, Qoder:
 - `ec-init` — one-time project knowledge init (run once after install)
 - `ec-workflow` — daily entrypoint: the workflow state machine and task resume
 - `ec-brainstorming` — design exploration before building (hard design gate)
-- `ec-analysis` `ec-implementing` `ec-reviewing` `ec-verification` — workflow stages
+- `ec-analysis` `ec-implementing` `ec-quality` — workflow stages
 - `ec-memory` — short/long memory archive
 - `ec-task-management` — task lifecycle panel · `ec-config` — Approval/Workflow/TDD settings · `ec-tdd-init` — Java changed-line gate initialization · `ec-task-close` — interrupt a task
 - `ec-no-harness` — bypass only Easy Coding for the current session
+- `ec-lite` — user-controlled direct mode with one proposal confirmation and no task/QUALITY/MEMORY
 - `ec-git` — git discipline · `ec-meta` — understand/customize the harness
 
 First run `ec-init`; daily work goes through `ec-workflow`.
@@ -45,10 +47,10 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   is session override > project `behavior.workflow_mode` > `adaptive`. Approval controls waiting;
   workflow controls execution depth. ANALYSIS shows and freezes adaptive to fast/standard/strict.
   Confirm approval waits only at ANALYSIS -> IMPLEMENT, then advances green later stages
-  automatically; Auto advances all legal green edges. A new code diff after the VERIFICATION
+  automatically; Auto advances all legal green edges. A new code diff after the QUALITY
   checkpoint is the only exceptional pause across all modes: show the exact diff, bind acceptance
   to its digest, and continue without rereview when the user accepts.
-  Every new code task runs REVIEW; no mode changes scope, delivery form, or evidence gates.
+  Every mutation task runs QUALITY; no mode changes scope, delivery form, or evidence gates.
 - TDD is session override > project `behavior.tdd_enabled` > `false`; its changed-line threshold
   is session override > project `behavior.tdd_coverage_threshold` > `90`. ANALYSIS -> IMPLEMENT
   freezes both. TDD may be enabled only after `ec-tdd-init` records valid infrastructure readiness;
@@ -59,13 +61,13 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   local coverage for production lines changed since the task baseline. `ec-tdd-init` still
   generates GitLab TEST-stage automation, but remote CI status is not Harness acceptance evidence.
 - Confirmation-required edges use `pending_transition`; automatic edges use the restricted
-  `auto-transition` API. A read-only task creates no test-strategy.md, never enters REVIEW,
-  VERIFICATION, or MEMORY, and writes no task memory.
+  `auto-transition` API. Pure read-only conversation stays Ready and creates no task. Any
+  repository write, including documentation or configuration, uses the full state machine.
 - A confirmation-required boundary is not fully presented until the user can choose its complete
   business branches. When a native user-choice tool is available, invoke it in the same turn with
   the complete gate. An ordinary gate offers "confirm entering/returning to the target stage"
   (recommended) and "hand off to another agent", with free-form Other for revisions. The special
-  code IMPLEMENT gate must preserve enter REVIEW and handoff, with free-form Other. Use a native
+  IMPLEMENT gate must preserve enter QUALITY and handoff, with free-form Other. Use a native
   choice without a text pre-fallback only when the tool
   explicitly guarantees an indefinite wait; disable or omit automatic timeout/resolution in that
   case. Otherwise pre-render the matching numbered fallback before invoking native choice once,
@@ -77,6 +79,10 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 - When `[easy-coding:no-harness]` is injected, do not emit an Easy Coding status line and ignore
   only Easy Coding workflow/stage orchestration for this session. Continue honoring every
   non-Easy-Coding skill, hook, and instruction. Do not clear or mutate the suspended task.
+- When `[easy-coding:lite-direct]` is injected, use only `ec-lite`. Lite is enabled or disabled
+  solely by explicit user invocation, creates no task or evidence artifacts, and requires one
+  confirmed compact proposal before each mutation. With an active task, present cancel startup,
+  close-and-start, and clear-pointer-and-start; never choose for the user.
 - ANALYSIS must follow template-first: read `.easy-coding/templates/dev-spec-skeleton.md` then
   write its exact content to the task's dev-spec.md as the FIRST tool calls. Next inspect evidence,
   set `decision_status: open`, ask every unresolved material decision, and progressively record
@@ -86,26 +92,26 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   and risk summary with an absolute local link/path to the full dev-spec.md; never paste the full
   artifact by default. The final artifact contains neither `[阶段：ANALYSIS]` nor a
   `待用户决策` section.
-- REVIEW and VERIFICATION are fingerprinted hard gates. Review evidence must match the final
+- QUALITY contains fingerprinted Review and Verification Gates. Review evidence must match the final
   implementation; verification evidence must match final implementation and config. The frozen
   workflow mode selects targeted, impacted, or full commands without weakening the green gate.
-  Freeze a verification checkpoint after green checks. Unchanged checkpoints follow approval
+  Freeze a quality checkpoint after green checks. Unchanged checkpoints follow approval
   mode normally; post-checkpoint code drift requires exact digest acceptance and
-  carry-forward/targeted/waived verification policy, but never an automatic second REVIEW.
+  carry-forward/targeted/waived verification policy, but never an automatic second Review Gate.
 - Canonical-backed tasks bind static validity to design revision + `design_sha256`, while
   `document_sha256` and `execution_revision` may advance through shared writer commands. Project-
   external explicit Spec paths are allowed and may be repaired only with identity-checked rebind.
   Runtime progress must use the shared writer with CAS/idempotency and reconciliation; static
   design changes require revision + READY + `sync-spec-design`. Never hand-edit `EDS:EXECUTION`.
-  Selected source tasks remain `implemented` through local VERIFICATION and become `verified`
-  only when the accepted VERIFICATION -> MEMORY boundary is actually applied.
+  Selected source tasks remain `implemented` through local QUALITY and become `verified`
+  only when the accepted QUALITY -> MEMORY boundary is actually applied.
 - Canonical routing is two-pass: first use manifest-only discovery for the current worktree, then
   inspect only the explicitly selected task IDs and repositories. A remote-confirmed worktree
   overrides a stale `path_hint`; never mirror the source Spec or re-check unselected repositories.
   ANALYSIS reads the selected consumption closure once and treats exact/scope-unchanged as a fast
   projection, while shared execution is the dependency fact source.
 - MEMORY combines short-memory creation and the conditional long-memory gate. Entry follows the
-  effective confirmation mode; its checkpoint records any accepted post-verification diff digest
+  effective confirmation mode; its checkpoint records any accepted post-quality diff digest
   and decision. Once memory processing completes, COMPLETE is automatic.
 - NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
 - All cross-platform modules (skills, hooks, references) must use universal agent protocols.
@@ -123,7 +129,7 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   a workflow identity. The installed script's embedded platform identity, canonical owner, and
   injected session namespace must agree. Do not hand-edit session files, `current_task`, task
   `status`, `stage_history`,
-  `pending_transition`, `verification_checkpoint`, workflow/TDD proposal or freeze fields,
+  `pending_transition`, `quality_checkpoint`, `lite_mode`, `lite_proposal`, workflow/TDD proposal or freeze fields,
   `memory_progress`, or `last_agent`.
 - The hook injects `[easy-coding:session-file:P]`; pass that path to the state script with
   `--session-file <P>` when changing the current task or stage.

package/templates/main-constraint/CLAUDE.md.tpl

@@ -20,6 +20,7 @@ disabled, omit the TDD segment entirely and preserve the existing status-line fo
 - Waiting init: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Waiting init · Use `ec-init` to initialize
 - Active task: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · `{current-task}` · `{workflow-state}`
 - Handoff: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
+- Lite: > **Easy Coding** · **Lite Direct** · `{Ready|Awaiting Confirmation}` · No Task / Quality / Memory · Use `ec-lite` to exit
 
 Skill names in the status line are bare names (`ec-init`, `ec-workflow`) and never include
 platform prefixes such as `/` or `$`. If no status line is injected, do not invent one.
@@ -29,10 +30,11 @@ platform prefixes such as `/` or `$`. If no status line is injected, do not inve
 - `/ec-init` — one-time project knowledge init (run once after install)
 - `/ec-workflow` — daily entrypoint: the workflow state machine and task resume
 - `/ec-brainstorming` — design exploration before building (hard design gate)
-- `/ec-analysis` `/ec-implementing` `/ec-reviewing` `/ec-verification` — workflow stages
+- `/ec-analysis` `/ec-implementing` `/ec-quality` — workflow stages
 - `/ec-memory` — short/long memory archive
 - `/ec-task-management` — task lifecycle panel · `/ec-config` — Approval/Workflow/TDD settings · `/ec-tdd-init` — Java changed-line gate initialization · `/ec-task-close` — interrupt a task
 - `/ec-no-harness` — bypass only Easy Coding for the current session
+- `/ec-lite` — user-controlled direct mode with one proposal confirmation and no task/QUALITY/MEMORY
 - `/ec-git` — git discipline · `/ec-meta` — understand/customize the harness
 
 First run `/ec-init`; daily work goes through `/ec-workflow`.
@@ -43,10 +45,10 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   is session override > project `behavior.workflow_mode` > `adaptive`. Approval controls waiting;
   workflow controls execution depth. ANALYSIS shows and freezes adaptive to fast/standard/strict.
   Confirm approval waits only at ANALYSIS -> IMPLEMENT, then advances green later stages
-  automatically; Auto advances all legal green edges. A new code diff after the VERIFICATION
+  automatically; Auto advances all legal green edges. A new code diff after the QUALITY
   checkpoint is the only exceptional pause across all modes: show the exact diff, bind acceptance
   to its digest, and continue without rereview when the user accepts.
-  Every new code task runs REVIEW; no mode changes scope, delivery form, or evidence gates.
+  Every mutation task runs QUALITY; no mode changes scope, delivery form, or evidence gates.
 - TDD is session override > project `behavior.tdd_enabled` > `false`; its changed-line threshold
   is session override > project `behavior.tdd_coverage_threshold` > `90`. ANALYSIS -> IMPLEMENT
   freezes both. TDD may be enabled only after `ec-tdd-init` records valid infrastructure readiness;
@@ -57,13 +59,13 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   local coverage for production lines changed since the task baseline. `ec-tdd-init` still
   generates GitLab TEST-stage automation, but remote CI status is not Harness acceptance evidence.
 - Confirmation-required edges use `pending_transition`; automatic edges use the restricted
-  `auto-transition` API. A read-only task creates no test-strategy.md, never enters REVIEW,
-  VERIFICATION, or MEMORY, and writes no task memory.
+  `auto-transition` API. Pure read-only conversation stays Ready and creates no task. Any
+  repository write, including documentation or configuration, uses the full state machine.
 - A confirmation-required boundary is not fully presented until the user can choose its complete
   business branches. When a native user-choice tool is available, invoke it in the same turn with
   the complete gate. An ordinary gate offers "confirm entering/returning to the target stage"
   (recommended) and "hand off to another agent", with free-form Other for revisions. The special
-  code IMPLEMENT gate must preserve enter REVIEW and handoff, with free-form Other. Use a native
+  IMPLEMENT gate must preserve enter QUALITY and handoff, with free-form Other. Use a native
   choice without a text pre-fallback only when the tool
   explicitly guarantees an indefinite wait; disable or omit automatic timeout/resolution in that
   case. Otherwise pre-render the matching numbered fallback before invoking native choice once,
@@ -75,6 +77,10 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 - When `[easy-coding:no-harness]` is injected, do not emit an Easy Coding status line and ignore
   only Easy Coding workflow/stage orchestration for this session. Continue honoring every
   non-Easy-Coding skill, hook, and instruction. Do not clear or mutate the suspended task.
+- When `[easy-coding:lite-direct]` is injected, use only `ec-lite`. Lite is enabled or disabled
+  solely by explicit user invocation, creates no task or evidence artifacts, and requires one
+  confirmed compact proposal before each mutation. With an active task, present cancel startup,
+  close-and-start, and clear-pointer-and-start; never choose for the user.
 - ANALYSIS must follow template-first: read `.easy-coding/templates/dev-spec-skeleton.md` then
   write its exact content to the task's dev-spec.md as the FIRST tool calls. Next inspect evidence,
   set `decision_status: open`, ask every unresolved material decision, and progressively record
@@ -84,26 +90,26 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   and risk summary with an absolute local link/path to the full dev-spec.md; never paste the full
   artifact by default. The final artifact contains neither `[阶段：ANALYSIS]` nor a
   `待用户决策` section.
-- REVIEW and VERIFICATION are fingerprinted hard gates. Review evidence must match the final
+- QUALITY contains fingerprinted Review and Verification Gates. Review evidence must match the final
   implementation; verification evidence must match final implementation and config. The frozen
   workflow mode selects targeted, impacted, or full commands without weakening the green gate.
-  Freeze a verification checkpoint after green checks. Unchanged checkpoints follow approval
+  Freeze a quality checkpoint after green checks. Unchanged checkpoints follow approval
   mode normally; post-checkpoint code drift requires exact digest acceptance and
-  carry-forward/targeted/waived verification policy, but never an automatic second REVIEW.
+  carry-forward/targeted/waived verification policy, but never an automatic second Review Gate.
 - Canonical-backed tasks bind static validity to design revision + `design_sha256`, while
   `document_sha256` and `execution_revision` may advance through shared writer commands. Project-
   external explicit Spec paths are allowed and may be repaired only with identity-checked rebind.
   Runtime progress must use the shared writer with CAS/idempotency and reconciliation; static
   design changes require revision + READY + `sync-spec-design`. Never hand-edit `EDS:EXECUTION`.
-  Selected source tasks remain `implemented` through local VERIFICATION and become `verified`
-  only when the accepted VERIFICATION -> MEMORY boundary is actually applied.
+  Selected source tasks remain `implemented` through local QUALITY and become `verified`
+  only when the accepted QUALITY -> MEMORY boundary is actually applied.
 - Canonical routing is two-pass: first use manifest-only discovery for the current worktree, then
   inspect only the explicitly selected task IDs and repositories. A remote-confirmed worktree
   overrides a stale `path_hint`; never mirror the source Spec or re-check unselected repositories.
   ANALYSIS reads the selected consumption closure once and treats exact/scope-unchanged as a fast
   projection, while shared execution is the dependency fact source.
 - MEMORY combines short-memory creation and the conditional long-memory gate. Entry follows the
-  effective confirmation mode; its checkpoint records any accepted post-verification diff digest
+  effective confirmation mode; its checkpoint records any accepted post-quality diff digest
   and decision. Once memory processing completes, COMPLETE is automatic.
 - NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
 - All cross-platform modules (skills, hooks, references) must use universal agent protocols.
@@ -118,7 +124,7 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   `Claude with Easy Coding` is not a workflow identity. The installed script's embedded platform
   identity, canonical owner, and injected session namespace must agree. Do not hand-edit session
   files, `current_task`, task `status`, `stage_history`,
-  `pending_transition`, `verification_checkpoint`, workflow/TDD proposal or freeze fields,
+  `pending_transition`, `quality_checkpoint`, `lite_mode`, `lite_proposal`, workflow/TDD proposal or freeze fields,
   `memory_progress`, or `last_agent`.
 - The hook injects `[easy-coding:session-file:P]`; pass that path to the state script with
   `--session-file <P>` when changing the current task or stage.

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

@@ -11,8 +11,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 `.qoder/skills/`, `.agents/skills/`, or any `.easy-coding/` file. All needed
   context is in the card.
@@ -21,25 +19,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/qoder/agents/ec-reviewer.md

@@ -21,8 +21,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.
 
@@ -35,5 +39,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