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

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.
 
@@ -168,9 +167,18 @@ choice set before invoking the platform's native choice UI:
 Preserve `pending_transition` on cancellation, timeout, or invalid UI output. A later ordinary
 reply may consume it. Use `confirm-transition` only for a matching stored edge.
 
+Text emitted before a later tool call is a non-durable process presentation because the host may
+group or collapse it. For ANALYSIS -> IMPLEMENT, preserve the compact proposal receipt produced by
+`ec-analysis`. After a native choice returns or a matching transition call completes, the last
+assistant response in that turn must repeat the receipt and full Dev-Spec link/path even if they
+were already visible. When the edge remains pending, include the complete numbered fallback;
+when confirmed, name the accepted branch and target stage. An empty, cancelled, timed-out, or
+invalid native result is not grounds to omit this final receipt.
+
 Use `auto-transition` only when the state API says the edge is automatic. Mechanical gates
 (analysis artifacts and proposal, review fingerprint, verification fingerprint, memory
-completion) apply in every approval mode.
+completion) apply in every approval mode. An automatic ANALYSIS -> IMPLEMENT edge must not pause;
+carry its full Dev-Spec link/path into the next durable final response in the same turn.
 
 `[easy-coding:acceptance-drift-confirmation-required]` is a narrow exception to automatic-edge
 handling. Call `inspect-transition-drift`, present every returned patch/binary/mode change and the
@@ -178,23 +186,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 +207,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,53 +61,63 @@ 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,
   so timeout cannot remove the user's path forward. Empty, dismissed, timed-out, or unparseable
-  native results preserve the pending edge; show the fallback when control returns only if it is
-  not already visible, and never retry native choice in that turn. On resume, consume a matching
+  native results preserve the pending edge; never retry native choice in that turn. On resume,
+  consume a matching
   numbered reply against the stored edge before re-presenting the gate. Never degrade to only
-  "reply confirm".
+  "reply confirm". Text shown before a later tool call is non-durable because the
+  host may group or collapse it. For ANALYSIS -> IMPLEMENT, the last assistant response after a
+  native choice or transition call must repeat a compact core-solution, acceptance, workflow,
+  and risk receipt plus the full Dev-Spec link/path, even if already visible. Repeat the complete
+  fallback while the edge is pending; after confirmation, identify the accepted branch and target
+  stage. Auto adds no pause and carries the Dev-Spec link/path into the next durable final response.
 - 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
   each confirmed answer and its evidence in `### 决策闭环`. Only after all material decisions are
   resolved may the agent set the single `decision_status: closed`, finalize the artifacts, and
   propose IMPLEMENT. The session presentation is a concise core-solution, acceptance, 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
+  and risk receipt with an absolute local link/path to the full dev-spec.md; repeat that durable
+  receipt after a later native choice or transition call instead of relying on collapsible process
+  text; never paste the full artifact by default. The final artifact contains neither
+  `[阶段：ANALYSIS]` nor a `待用户决策` section.
+- 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 +135,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,53 +59,63 @@ 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,
   so timeout cannot remove the user's path forward. Empty, dismissed, timed-out, or unparseable
-  native results preserve the pending edge; show the fallback when control returns only if it is
-  not already visible, and never retry native choice in that turn. On resume, consume a matching
+  native results preserve the pending edge; never retry native choice in that turn. On resume,
+  consume a matching
   numbered reply against the stored edge before re-presenting the gate. Never degrade to only
-  "reply confirm".
+  "reply confirm". Text shown before a later tool call is non-durable because the
+  host may group or collapse it. For ANALYSIS -> IMPLEMENT, the last assistant response after a
+  native choice or transition call must repeat a compact core-solution, acceptance, workflow,
+  and risk receipt plus the full Dev-Spec link/path, even if already visible. Repeat the complete
+  fallback while the edge is pending; after confirmation, identify the accepted branch and target
+  stage. Auto adds no pause and carries the Dev-Spec link/path into the next durable final response.
 - 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
   each confirmed answer and its evidence in `### 决策闭环`. Only after all material decisions are
   resolved may the agent set the single `decision_status: closed`, finalize the artifacts, and
   propose IMPLEMENT. The session presentation is a concise core-solution, acceptance, 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
+  and risk receipt with an absolute local link/path to the full dev-spec.md; repeat that durable
+  receipt after a later native choice or transition call instead of relying on collapsible process
+  text; never paste the full artifact by default. The final artifact contains neither
+  `[阶段：ANALYSIS]` nor a `待用户决策` section.
+- 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 +130,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.