easy-coding-harness 0.5.3 → 0.6.1

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

@@ -5,9 +5,10 @@ description: REVIEW-stage skill. Use when ec-workflow enters REVIEW. Reviews cha
 
 # ec-reviewing — graded, evidence-backed review
 
-ec-workflow dispatches you when IMPLEMENT finishes. You judge the change set and return a
-verdict that drives the next transition. Inputs: the changed files (from execution.jsonl
-`result` records), `dev-spec.md`, `.easy-coding/RULES.md`, `test-strategy.md`.
+ec-workflow dispatches you when code IMPLEMENT finishes. Read-only `doc` / `analysis` / `report`
+tasks auto-complete from IMPLEMENT and never enter REVIEW. You judge the code change set and
+return a verdict that drives the next transition. Inputs: the changed files (from
+execution.jsonl `result` records), `dev-spec.md`, `.easy-coding/RULES.md`, `test-strategy.md`.
 
 Communicate with the user in the user's language.
 
@@ -30,9 +31,9 @@ result. No finding without a location.
 
 ## Verdict (exactly one)
 
-- `accept` — all dimensions pass. Advance to VERIFICATION.
+- `accept` — all dimensions pass. Request REVIEW -> VERIFICATION.
 - `fix` — problems found, fixable within the current plan. Auto-fix via sub-agents (see below).
-- `replan` — the plan itself is flawed (wrong approach, missing design). Return to ANALYSIS.
+- `replan` — the plan itself is flawed (wrong approach, missing design). Request REVIEW -> ANALYSIS.
 - `blocked` — external blocker (missing dependency, environment). Pause and report.
 
 ## Auto-fix flow (on `fix` verdict)
@@ -46,7 +47,7 @@ defects, not design decisions.
 ONLY escalate to the user when:
 - The fix requires a DESIGN CHOICE (two equally valid approaches, ambiguous requirement)
 - The fix would change the public API contract beyond what the dev-spec specifies
-- The finding contradicts something the user explicitly stated during WAITING_CONFIRM
+- The finding contradicts something the user explicitly confirmed at a stage boundary
 </HARD-GATE>
 
 Fix dispatch flow:
@@ -88,3 +89,6 @@ Platform spawn rule: {{platform_spawn_instruction}}
 Append `review` records to execution.jsonl, one per dimension:
 `{"type":"review","dimension":"correctness","findings":[{"file":"...","line":42,"issue":"...","severity":"warn"}]}`.
 Then state the verdict and hand back to ec-workflow.
+For `accept` or `replan`, ec-workflow records the corresponding pending transition and presents
+the standard confirmation/handoff/Other gate. A `fix` round stays inside REVIEW and therefore
+does not create a status transition unless the outcome changes.

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

@@ -24,7 +24,7 @@ when you recognize abandonment intent in the user's message.
    clears session `current_task` so the next hook injection returns to Ready.
    Use the returned `status_context` as the authoritative status source for the rest of the
    current turn.
-4. **No memory flow.** Do not run MEMORY_SHORT/LONG. An incomplete task's memory is dirty data.
+4. **No memory flow.** Do not run MEMORY. An incomplete task's memory is dirty data.
 5. **Linked tasks.** If the task has `spawned_from` or `spawned_tasks`, note the closure fact
    on the relation so a future agent understands the chain.
 6. Optionally append a closure note to `execution.jsonl` if there is context worth keeping for

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

@@ -52,7 +52,7 @@ unless ec-workflow is explicitly invoked or the agent environment routes into it
 ### Create a task
 
 Create through the state API, never by hand-editing `task.json` or session files:
-`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py create-task --session-file <P> --task-id <MM-DD-short-name> --type <feature|bugfix|refactor|perf> --title "<one-line summary>" --agent <agent-id> --no-set-current`.
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py create-task --session-file <P> --task-id <MM-DD-short-name> --type <feature|bugfix|refactor|perf|doc|analysis|report|workflow> --title "<one-line summary>" --agent <agent-id> --no-set-current`.
 
 If the user explicitly wants to start the task now, omit `--no-set-current`; otherwise leave
 the current workflow pointer untouched and tell them to run `{{skill_trigger}}ec-workflow`

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

@@ -1,12 +1,13 @@
 ---
 name: ec-verification
-description: VERIFICATION-stage skill — the hard gate between REVIEW and archive. Use when ec-workflow enters VERIFICATION. Runs lint/typecheck/test in parallel, verifies coverage against test-strategy, gates on fresh evidence, then drives the user-acceptance and repair loop. Archive never happens without explicit user acceptance.
+description: VERIFICATION-stage skill — the hard gate between implementation/review and archive. Use when ec-workflow enters VERIFICATION. Runs lint/typecheck/test in parallel, verifies coverage against test-strategy, gates on fresh evidence, then drives the user-acceptance and repair loop. Archive never happens without explicit user acceptance.
 ---
 
 # ec-verification — the hard gate
 
-ec-workflow dispatches you when REVIEW returns `accept`. You are the last gate before
-archive. Nothing passes on assumption.
+ec-workflow dispatches you when REVIEW returns `accept` or the user explicitly skips REVIEW
+after code IMPLEMENT. Read-only tasks auto-complete from IMPLEMENT and never enter this stage.
+You are the last gate before code-task archive. Nothing passes on assumption.
 
 Communicate with the user in the user's language.
 
@@ -54,7 +55,8 @@ Append one `verify` record per check:
 
 - All three pass AND coverage satisfied → present the verification result; wait for user
   acceptance. Do NOT archive yet.
-- Any failure → append the failing `verify` record, summarize failures, return to IMPLEMENT.
+- Any failure → append the failing `verify` record, summarize failures, request
+  VERIFICATION -> IMPLEMENT, and wait at the standard confirmation/handoff/Other gate.
 
 ## 4. User acceptance and repair loop
 
@@ -62,31 +64,28 @@ After a green gate, present an acceptance summary: what changed (files + summari
 verification results (lint/type/test), and the coverage status. Then the user takes time to
 test manually. Their response routes:
 
-- **"accepted"** → trigger the archive flow (section 5).
+- **"accepted"** → request VERIFICATION -> MEMORY and present the standard boundary gate.
 - **"problem here"** → scope judgment against the dev-spec:
-  - in scope → return to IMPLEMENT to fix → re-REVIEW → re-VERIFICATION.
+  - in scope → request VERIFICATION -> IMPLEMENT and wait for the user to confirm the return;
+    after repair, the IMPLEMENT completion choice decides whether REVIEW runs again or
+    VERIFICATION resumes directly.
   - out of scope → propose a new task (`spawned_from` = current task id); the current task
     may archive now (if already satisfactory) or stay suspended.
 - **"cancel"** → ec-task-close.
 
 Repair sizing: a trivial tweak is fixed and re-verified inside VERIFICATION; a logic/structure
-change formally returns to IMPLEMENT and re-walks REVIEW → VERIFICATION.
-
-## 5. Archive flow (only after acceptance)
-
-Runs automatically once the user accepts:
-1. MEMORY_SHORT — call
-   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py transition --session-file <P> --stage MEMORY_SHORT --agent <agent-id>`,
-   use the returned `status_context` as the latest status source, then hand control to
-   ec-memory to write the short memory entry.
-2. MEMORY_LONG — after MEMORY_SHORT returns, call
-   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py transition --session-file <P> --stage MEMORY_LONG --agent <agent-id>`,
-   use the returned `status_context` and `memory_long` object as authoritative, then hand
-   control to ec-memory to distill long memory or perform its no-op gate.
-3. COMPLETE — after MEMORY_LONG returns, call
-   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py transition --session-file <P> --stage COMPLETE --agent <agent-id>`,
-   which clears session `current_task` for the completed task. Use the returned
-   `status_context`, then output the task summary (what was done, files changed, key
-   decisions).
-
-Hand control back to ec-workflow at each transition; ec-workflow owns the stage writes.
+change formally returns to IMPLEMENT. After repair, present the standard IMPLEMENT completion
+choice again so the user may enter REVIEW or skip directly to VERIFICATION.
+
+## 5. Archive entry (only after acceptance)
+
+Acceptance does not mutate the stage directly. Hand control to ec-workflow to call
+`request-transition --stage MEMORY`, then present:
+1. Confirm entering MEMORY
+2. Hand off to another agent
+3. Other (native free-form Other, or the third text option)
+
+Only after confirmation may ec-workflow consume the pending edge and dispatch ec-memory.
+ec-memory owns both short-memory creation and the conditional long-memory gate inside the
+single MEMORY stage. After memory processing completes, MEMORY -> COMPLETE advances
+automatically without another confirmation or handoff gate.

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

@@ -59,39 +59,43 @@ replies are English.
 4. **New task.** When creating a task (from step 3), create
    the task through the state API, which creates `task.json`, sets `status:"INIT"`, writes
    `stage_history`, and sets the session `current_task`:
-   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py create-task --session-file <P> --task-id <MM-DD-task-slug> --type <type> --title "<one-line summary>" --agent <agent-id>`.
+   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py create-task --session-file <P> --task-id <MM-DD-task-slug> --type <feature|bugfix|refactor|perf|doc|analysis|report|workflow> --title "<one-line summary>" --agent <agent-id>`.
    Use the returned `status_context` as the current status source. Then enter INIT.
 
 ## State machine
 
 ```
-INIT -> ANALYSIS -> WAITING_CONFIRM -> IMPLEMENT -> REVIEW -> VERIFICATION
-                          ^                ^                      |
-                          |                +---- repair loop -----+
-                          +--- revision ---+                      |
-                                                        [user acceptance]
-                                                                  |
-                                          MEMORY_SHORT -> MEMORY_LONG -> COMPLETE
+INIT --[auto]--> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY --[auto]--> COMPLETE
+                                    \----------------> VERIFICATION
+                                    \--[read-only auto]------------------------------> COMPLETE
+                 ^            ^          |             |
+                 +-- replan ---+          +--- fix -----+
+                              ^                         |
+                              +------- repair ----------+
+user-decision edge --[explicit confirmation / handoff / Other]--> target stage
 any stage --[user abort via ec-task-close]--> CLOSED
 ```
 
 | Stage | Owner skill | What happens | Exit condition |
 |---|---|---|---|
-| INIT | ec-workflow | collect context, settle scope AND delivery form (change code vs. produce a document) | task understood |
-| ANALYSIS | ec-analysis | dev-spec + execution plan + test strategy | analysis presented |
-| WAITING_CONFIRM | ec-workflow | blocking gate; user reviews the plan | explicit user confirmation |
-| IMPLEMENT | ec-implementing | code changes per confirmed plan | all units done |
-| REVIEW | ec-reviewing | multi-dimension code review | verdict = accept |
-| VERIFICATION | ec-verification | hard gate: lint/typecheck/test + coverage | all pass AND user accepts |
-| MEMORY_SHORT | ec-memory | archive: short memory entry | written |
-| MEMORY_LONG | ec-memory | archive: long memory distillation (conditional — no-op when short memory is under threshold) | state API `memory_long` instruction handled |
-| COMPLETE | ec-workflow | clear current_task, set task status, summary | terminal |
+| INIT | ec-workflow | collect context, settle scope AND delivery form (change code vs. produce a document) | work complete; auto-transition to ANALYSIS |
+| ANALYSIS | ec-analysis | dev-spec + execution plan; code tasks also get test strategy | analysis presented; request IMPLEMENT |
+| IMPLEMENT | ec-implementing | code changes or one read-only deliverable | code: choose REVIEW or VERIFICATION; read-only: auto-complete after delivery |
+| REVIEW | ec-reviewing | multi-dimension code review | verdict selects a legal target; request it |
+| VERIFICATION | ec-verification | hard gate: lint/typecheck/test + coverage | result selects MEMORY or IMPLEMENT; request it |
+| MEMORY | ec-memory | write short memory, then run the conditional long-memory gate | memory work complete; auto-transition to COMPLETE |
+| COMPLETE | ec-workflow | clear current_task, set task status, summary | automatic terminal after MEMORY or validated read-only IMPLEMENT |
 | CLOSED | ec-task-close | user abort; no memory flow | terminal |
 
 > **INIT delivery-form rule.** When creating the task, `type` and `title` must faithfully
 > reflect the delivery form implied by the user's request. A refactor/fix/feature is a CODE
 > task; do not record it as an analysis/report task. Do not let ANALYSIS later re-interpret a
 > code task into a documentation-only task — that is a downgrade (see ec-analysis HARD RULE 5).
+> Use `doc`, `analysis`, or `report` only when the user's original request explicitly asks for
+> a no-code deliverable. Those task types may carry execution units with an empty file scope;
+> code task types may not. A successful empty-scope task ends automatically from IMPLEMENT to
+> COMPLETE after its full deliverable is shown; it never creates test-strategy.md or enters
+> REVIEW, VERIFICATION, or MEMORY.
 
 ## Task switching
 
@@ -104,75 +108,114 @@ When the user confirms switching from task A to task B:
    the user which previous agent owned the task.
 4. Resume task B's stage via the appropriate stage skill.
 
-No data is lost — task A's dev-spec, execution.jsonl, and test-strategy.md stay intact on
-disk. To return to task A later, the same intent routing applies: the user mentions it,
-routing matches, and switching happens again.
+No data is lost — task A's dev-spec and execution.jsonl stay intact, as does test-strategy.md
+for a code task. To return to task A later, the same intent routing applies: the user mentions
+it, routing matches, and switching happens again.
 
 ## Transition rules (hard)
 
-- **Never skip a stage.** ANALYSIS cannot jump to VERIFICATION; IMPLEMENT cannot start before
-  WAITING_CONFIRM passes. No exception for "simple" tasks — simple tasks have short analyses,
-  not skipped ones.
-- **State before action.** Every stage advance is a two-step protocol: first persist the
-  next stage through the state API, then run that stage's real work. Do not start analysis,
-  implementation, review, verification, memory writing, closeout, or task switching while
+- **Code tasks may skip only REVIEW.** ANALYSIS cannot jump to VERIFICATION; IMPLEMENT cannot
+  start before the ANALYSIS -> IMPLEMENT confirmation gate passes. After code implementation,
+  the user may enter REVIEW or skip it and enter VERIFICATION; code tasks never skip
+  VERIFICATION. Explicit read-only tasks are the separate terminal exception below.
+- **User-decision edges are confirmation gates.** Stage completion on those edges does NOT
+  change `task.json.status`. It records a `pending_transition` through the state API, presents
+  the choices below, and stops. This applies to forward edges, repair/replan edges, and the
+  IMPLEMENT review choice. Task creation entering INIT and the separately confirmed
+  ec-task-close flow do not add a redundant second prompt.
+- **Mechanical edges are automatic.** After INIT work completes, call `auto-transition`
+  for ANALYSIS and dispatch ec-analysis in the same flow. After `memory-complete`, call
+  `auto-transition` for COMPLETE and emit the closeout summary. A successful explicit read-only
+  task also calls `auto-transition` from IMPLEMENT to COMPLETE immediately after displaying the
+  full deliverable. These edges do not create `pending_transition`, do not offer handoff, and
+  never wait for user confirmation.
+- **Native choice first (hard requirement).** After `request-transition` succeeds, you MUST
+  prefer the agent/platform's native user-choice tool whenever one is available. Do not render
+  a plain-text numbered list on a platform that can present selectable options and a free-form
+  Other input. Offer exactly these business branches through that native UI:
+  1. Confirm entering/returning to `<target-stage>` (recommended)
+  2. Hand off to another agent
+  3. Other — use the native tool's built-in free-form Other input.
+  Code-task IMPLEMENT completion is the one special gate: offer (1) enter REVIEW (recommended),
+  (2) skip REVIEW and enter VERIFICATION, and (3) hand off; use the native free-form Other
+  input for revisions. Record REVIEW as the recommended pending edge first. If the user chooses
+  VERIFICATION, cancel that edge, request IMPLEMENT -> VERIFICATION, and immediately confirm it
+  because that selection is explicit confirmation of the alternate target.
+  Plain-text numbered choices are fallback only: use them only when no native user-choice tool
+  exists. The runtime hook never mutates workflow state from user-prompt text. Native choice
+  results, numbered fallback replies, and every natural-language reply must be interpreted by
+  you against the current task and stored target before calling `confirm-transition` explicitly.
+  On Other feedback, cancel the pending edge before revising work or requesting a different
+  legal target. Never interpret silence, enthusiasm, or topic changes as confirmation.
+- **State before action.** Every user-confirmed stage advance is a two-step protocol: first
+  consume the pending edge through `confirm-transition`, then run that stage's real work. The
+  automatic edges use `auto-transition` instead. Do not start
+  analysis, implementation, review, verification, memory writing, or closeout while
   `task.json.status` still names the previous stage. After every state API call, treat the
-  returned snapshot/read-after-write state as authoritative for the next action and for the
-  status line.
+  returned snapshot/read-after-write state as authoritative for the next action and status line.
 - **ANALYSIS entry gate.** When entering ANALYSIS, your FIRST TWO tool calls must be:
   (1) Read `.easy-coding/templates/dev-spec-skeleton.md`, then (2) Write its exact content
   to the task's dev-spec.md. This is a mechanical copy, not a generation task. Do not read
   code, load memory, or analyze before the skeleton is on disk. This is ec-analysis
-  HARD RULE 1 — violating it means the analysis has failed. Your reply to the user must
-  be the complete dev-spec.md content, not a summary or custom format.
+  HARD RULE 1 — violating it means the analysis has failed. After the skeleton is written,
+  inspect the required evidence without editing it. Ask and resolve every user decision during
+  ANALYSIS before filling any section; the final report must not contain a `待用户决策` section
+  or `[阶段：ANALYSIS]`. Once decisions are resolved, your plan reply must be the complete
+  dev-spec.md content, not a summary or custom format.
   Additionally, ANALYSIS must stay faithful to the user's delivery form — it may NOT downgrade
   a code task to a report-only task — and the 改动范围 table must list only real project code,
   never `.easy-coding/` harness artifacts (ec-analysis HARD RULES 5 and 6).
-- **WAITING_CONFIRM is a real gate.** Proceed only on explicit user confirmation of BOTH the
-  analysis conclusion and the test strategy. Silence, enthusiasm, or a topic change is not
-  confirmation. Sole exception: `behavior.auto_mode: true` in `.easy-coding/config.yaml`
-  AND the user asked for autonomous execution. `auto_mode` ONLY waives this confirmation step;
-  it carries NO scope or delivery-form decision. Never cite `auto_mode` (or "the user already
-  decided in INIT") to justify narrowing scope or downgrading a code task to a report.
-  On confirmation, the harness hook may have already advanced the task to IMPLEMENT before
-  this reply is generated. If the breadcrumb/state is still WAITING_CONFIRM, call the state
-  API to transition to IMPLEMENT immediately; only after the read-after-write state says
-  IMPLEMENT may you dispatch ec-implementing.
-- **On every transition** call the state API immediately (not at turn end):
-  `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py transition --session-file <P> --stage <STAGE> --agent <agent-id>`.
+- **Autonomous exception.** `behavior.auto_mode: true` in `.easy-coding/config.yaml` only
+  waives stage-boundary prompts when the user explicitly requested autonomous execution.
+  It carries NO scope or delivery-form decision. Never cite `auto_mode` to narrow scope,
+  downgrade a code task, or bypass a blocker that needs a real user decision.
+- **At user-decision stage completion** request the legal target immediately (not at turn end):
+  `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py request-transition --session-file <P> --stage <STAGE> --agent <agent-id> --reason "<why this edge is ready>"`.
+  This writes only `pending_transition`; it does not change the stage.
+- **No-code IMPLEMENT delivery:** before completing the task, ec-implementing must
+  have output the successful unit's complete non-empty `deliverable` verbatim to the user.
+  A summary or execution.jsonl record is not a substitute; missing user-visible delivery keeps
+  the task in IMPLEMENT. The execution log must contain a matching `dispatch` immediately before
+  the accepted result for that unit. After delivery, call `auto-transition --stage COMPLETE`;
+  do not enter REVIEW, VERIFICATION, or MEMORY and do not write memory.
+- **On automatic completion** call:
+  `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py auto-transition --session-file <P> --stage <ANALYSIS|COMPLETE> --agent <agent-id>`.
+  The state API accepts INIT -> ANALYSIS, completed MEMORY -> COMPLETE, and a validated
+  read-only IMPLEMENT -> COMPLETE through this command.
+- **On user confirmation** read the current task's pending edge and call:
+  `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py confirm-transition --session-file <P> --stage <STAGE> --agent <agent-id>`.
+  Only after the read-after-write status names the target stage may its action start.
+- **On Other feedback or a changed outcome** call:
+  `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py cancel-transition --session-file <P> --agent <agent-id>`
+  before revising the current stage or requesting a different target.
   Do not hand-edit `status`, `stage_history`, `last_agent`, `current_task`, or session files.
   The command returns `status_line` and `status_context`; after any state-changing command,
   discard older hook-injected status text and use this returned context as the authoritative
   status source for the rest of the current turn.
-  If the target stage is already present because a hook preflight completed it, do not issue a
-  duplicate transition; use the latest snapshot and continue with the target stage's action.
 - **Hook enforcement.** The `inject-workflow-state` hook validates every stage transition
   against the state machine. If you see `[ILLEGAL-TRANSITION:...]` in the injected context,
   you MUST revert the task's status to the previous valid stage and explain why the
   transition was rejected. Do not proceed with an illegal stage.
-- **Repair loop sizing** (user acceptance window after VERIFICATION): a trivial tweak
-  (one-line style fix, copy text) is fixed inside VERIFICATION and re-verified; a logic or
-  structure change formally returns to IMPLEMENT and re-walks REVIEW → VERIFICATION.
+- **Repair loop sizing** (after VERIFICATION): a trivial tweak may be fixed inside
+  VERIFICATION and re-verified without a status change; a logic or structure change requests
+  VERIFICATION -> IMPLEMENT and waits at the standard confirmation gate. After repair, present
+  the IMPLEMENT completion choice again so the user may enter REVIEW or skip directly to
+  VERIFICATION.
 - **Scope guard** (repair loop): if the user's fix request falls outside the dev-spec scope
   (features or files absent from the change-scope table), say so explicitly and propose a
   new task with `spawned_from` set to the current task id. Never silently absorb scope creep.
 - **Task switching is allowed at any stage.** The suspended task retains its stage in
   task.json. Do not run memory flows for suspended tasks — only completed tasks get archived.
 - **Archive only after user acceptance.** VERIFICATION passing does not complete the task.
-  After the user accepts, call state API transitions in order:
-  MEMORY_SHORT → MEMORY_LONG → COMPLETE. Do not jump directly from VERIFICATION to COMPLETE.
-  For each archive step, transition first and run the corresponding action second:
-  after MEMORY_SHORT is persisted, write the short memory; after MEMORY_LONG is persisted,
-  handle the `memory_long` instruction; after COMPLETE is persisted, produce the final summary.
-  At each transition, use the state API's returned `status_context` as the latest status
-  source before running the next action.
-  When transitioning to MEMORY_LONG, pass the state API snapshot to ec-memory and treat its
-  `memory_long` object as authoritative: `action == "no-op"` advances to COMPLETE without
-  reading or writing long memory; `action == "distill"` runs distillation for `trim_count`
-  older short-memory entries.
-- **COMPLETE closeout:** call the state API with `--stage COMPLETE`. The state API clears
-  session `current_task` for terminal tasks, so the next hook injection returns to Ready.
-  Then output a summary (what was done, files changed, key decisions).
+  A green gate requests VERIFICATION -> MEMORY and presents the standard choices. After the
+  user confirms, MEMORY writes one short entry first, records it through `memory-short-complete`,
+  then asks the state API for the authoritative `memory` instruction. `action == "no-op"`
+  skips long-memory reads/writes; `action == "distill"` processes exactly `trim_count` older
+  entries. After `memory-complete`, ec-memory automatically advances MEMORY -> COMPLETE.
+- **COMPLETE closeout:** COMPLETE is automatic after successful memory processing, or directly
+  after a validated read-only deliverable. The state API clears session `current_task`, so the
+  next hook injection returns to Ready. Then output a summary; for read-only tasks, the full
+  report must already have appeared before this closeout.
 
 ## Resume and handoff
 
@@ -186,16 +229,22 @@ Resuming an active task (whether from session restart, claim, handoff, or task s
    records tell you exactly where work stopped.
 3. If the task was claimed from another agent, read the latest `handoff` record first for the
    fast summary and tell the user which previous agent handed it off.
-4. Tell the user what is being resumed and from which stage, then continue.
+4. If `pending_transition` exists, do not rerun the completed stage action. If its stored edge
+   is INIT -> ANALYSIS or MEMORY -> COMPLETE, treat it as an upgrade-era automatic edge: call
+   `auto-transition` for the stored target immediately, without confirmation or handoff. For
+   a read-only task in IMPLEMENT, cancel any stale pending REVIEW/VERIFICATION edge before the
+   terminal check below. For any other stored edge, re-present the standard
+   confirmation/handoff/Other choices. At an IMPLEMENT boundary for a code task, re-present the
+   special REVIEW / skip to VERIFICATION / handoff choices.
+5. If a read-only task resumes in IMPLEMENT with a valid successful result, output its complete
+   deliverable again and immediately auto-transition to COMPLETE. Otherwise tell the user what
+   is being resumed and from which stage, then continue.
 
 After a task switch, the same resume flow applies — the only difference is that `current_task`
 was just changed by the switching procedure rather than being loaded from a prior session.
 
-Offering handoff — at WAITING_CONFIRM, after presenting the plan, offer exactly:
-1. Start implementation
-2. Write handoff and stop
-3. Revise the plan
-On option 2, call:
+Offering handoff — every user-decision pending edge includes the handoff option. On that
+option, call:
 `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py handoff-task --session-file <P> --agent <agent-id> --summary "<dense context: plan shape, key decisions, user emphases>"`.
 
 The handoff record is target-less:
@@ -204,8 +253,9 @@ It records who handed the task off, not who will take it next. Do not ask the us
 the next agent, and do not invent or store a next-agent field. After writing handoff, stop
 owning the task; another agent can use ec-task-management or ec-workflow to claim it.
 
-Handoff is also legal at any other stage boundary on user request. The harness never switches
-agents by itself; the next agent claims the task explicitly.
+Handoff preserves `pending_transition`, so the next agent resumes the same completed boundary
+without rerunning stage work. The harness never switches agents by itself; the next agent
+claims the task explicitly.
 
 ## Status line
 

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

@@ -35,17 +35,25 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 
 ## Workflow discipline
 
-- Stages do not skip. WAITING_CONFIRM is a real gate — implement only after the user confirms
-  the plan and test strategy (unless `behavior.auto_mode` is on and the user asked for it).
+- Code tasks do not skip stages except when the user explicitly skips REVIEW after IMPLEMENT.
+  User-decision edges use `pending_transition`; offer the target and handoff, and offer
+  free-form Other through native UI when available. IMPLEMENT additionally offers direct entry
+  to VERIFICATION.
+  INIT -> ANALYSIS, completed MEMORY -> COMPLETE, and validated read-only
+  IMPLEMENT -> COMPLETE use restricted `auto-transition` without confirmation or handoff. A
+  read-only task creates no test-strategy.md, never enters REVIEW, VERIFICATION, or MEMORY, and
+  writes no task memory.
+  `auto_mode` only waives remaining prompts; it never changes scope or delivery form.
 - 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, then fill sections
-  incrementally via edits. Reply to the user with the complete dev-spec.md content — never a
-  summary table or custom format.
-- VERIFICATION is a hard gate: lint + typecheck + test must pass on fresh evidence, and
-  coverage must match the test strategy, before a task can complete.
-- Archive (memory flow) runs only after explicit user acceptance — an unaccepted task's
-  memory is dirty data.
-- NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
+  write its exact content to the task's dev-spec.md as the FIRST tool calls. Next inspect evidence
+  without editing the skeleton, ask every unresolved decision during analysis, and wait. Only
+  after all decisions are resolved may the agent fill the complete dev-spec.md. The final report
+  contains neither `[阶段：ANALYSIS]` nor a `待用户决策` section.
+- For code tasks, VERIFICATION is a hard gate: lint + typecheck + test must pass on fresh
+  evidence, and coverage must match the test strategy, before completion.
+- MEMORY combines short-memory creation and the conditional long-memory gate. Archive starts
+  only after explicit user acceptance; 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.
   Do not rely on any specific agent's proprietary conventions unless the module is explicitly
   a platform-specific compatibility layer. Reference files use descriptive filenames (e.g.,
@@ -54,8 +62,8 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 ## Runtime contract
 
 - Workflow state operations go through `{{platform_config_dir}}/hooks/easy_coding_state.py`;
-  do not hand-edit session files, `current_task`, task `status`, `stage_history`, or
-  `last_agent`.
+  do not hand-edit session files, `current_task`, task `status`, `stage_history`,
+  `pending_transition`, `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.
 - Workflow session files live at `{{workflow_state_path}}`; the CLI only installs files and

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

@@ -33,17 +33,25 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 
 ## Workflow discipline
 
-- Stages do not skip. WAITING_CONFIRM is a real gate — implement only after the user confirms
-  the plan and test strategy (unless `behavior.auto_mode` is on and the user asked for it).
+- Code tasks do not skip stages except when the user explicitly skips REVIEW after IMPLEMENT.
+  User-decision edges use `pending_transition`; offer the target and handoff, and offer
+  free-form Other through native UI when available. IMPLEMENT additionally offers direct entry
+  to VERIFICATION.
+  INIT -> ANALYSIS, completed MEMORY -> COMPLETE, and validated read-only
+  IMPLEMENT -> COMPLETE use restricted `auto-transition` without confirmation or handoff. A
+  read-only task creates no test-strategy.md, never enters REVIEW, VERIFICATION, or MEMORY, and
+  writes no task memory.
+  `auto_mode` only waives remaining prompts; it never changes scope or delivery form.
 - 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, then fill sections
-  incrementally via edits. Reply to the user with the complete dev-spec.md content — never a
-  summary table or custom format.
-- VERIFICATION is a hard gate: lint + typecheck + test must pass on fresh evidence, and
-  coverage must match the test strategy, before a task can complete.
-- Archive (memory flow) runs only after explicit user acceptance — an unaccepted task's
-  memory is dirty data.
-- NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
+  write its exact content to the task's dev-spec.md as the FIRST tool calls. Next inspect evidence
+  without editing the skeleton, ask every unresolved decision during analysis, and wait. Only
+  after all decisions are resolved may the agent fill the complete dev-spec.md. The final report
+  contains neither `[阶段：ANALYSIS]` nor a `待用户决策` section.
+- For code tasks, VERIFICATION is a hard gate: lint + typecheck + test must pass on fresh
+  evidence, and coverage must match the test strategy, before completion.
+- MEMORY combines short-memory creation and the conditional long-memory gate. Archive starts
+  only after explicit user acceptance; 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.
   Do not rely on any specific agent's proprietary conventions unless the module is explicitly
   a platform-specific compatibility layer. Reference files use descriptive filenames (e.g.,
@@ -52,8 +60,8 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 ## Runtime contract
 
 - Workflow state operations go through `{{platform_config_dir}}/hooks/easy_coding_state.py`;
-  do not hand-edit session files, `current_task`, task `status`, `stage_history`, or
-  `last_agent`.
+  do not hand-edit session files, `current_task`, task `status`, `stage_history`,
+  `pending_transition`, `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.
 - Workflow session files live at `{{workflow_state_path}}`; the CLI only installs files and

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

@@ -11,6 +11,8 @@ 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.
@@ -22,6 +24,7 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
 
 - `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)
 

package/templates/runtime/memory/SHORT_MEMORY_TEMPLATE.md

@@ -1,6 +1,7 @@
 ---
 memory_schema: 2
 id: SM-YYYYMMDD-001
+source_task: MM-DD-task-slug
 date: YYYY-MM-DD
 task_type: feature | bugfix | refactor | perf | doc | workflow
 project_mode: startup | iteration
@@ -20,6 +21,7 @@ target_long: BUSINESS | TECHNICAL | BOTH | NONE
 
 > This template defines the format for files under `.easy-coding/memory/short/`.
 > File naming convention: `{NNN}_{YYYYMMDD}_{smart_name}.md`
+> `source_task` must exactly match the current workflow task id from `task.json`.
 > Short memories are immutable after creation — they serve as a sliding window of recent
 > details and a buffer for long-term distillation candidates.
 > When short memories reach the threshold (default 10), the newest 5 are kept as recent