easy-coding-harness 0.5.3 → 0.6.0

package/package.json

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

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

@@ -162,7 +162,7 @@ agent must be able to see what was generated and on what evidence.
    - TEST_STRATEGY.md (skeleton for the chosen framework)
 3. **Skip ABSTRACT.md** — no architecture exists yet. Note in init_log:
    "ABSTRACT pending; ec-memory backfills after the first substantive task." (ec-memory
-   detects the missing file during MEMORY_LONG and generates it from the then-current code.)
+   detects the missing file during MEMORY and generates it from the then-current code.)
 4. Memory migration probe and memory init, same as iterative steps 5-7.
 5. Recommend: design first with `{{skill_trigger}}ec-brainstorming`, then build via
    `{{skill_trigger}}ec-workflow`.

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

@@ -42,10 +42,12 @@ analysis, workflow operation). The CLI never analyzes the project.
 
 ## Workflow state machine
 
-8 stages + 2 terminals, owned by ec-workflow:
-`INIT → ANALYSIS → WAITING_CONFIRM → IMPLEMENT → REVIEW → VERIFICATION → MEMORY_SHORT →
-MEMORY_LONG → COMPLETE`, plus `CLOSED` (user abort, no memory flow). WAITING_CONFIRM and
-VERIFICATION are hard gates. The active task pointer lives in `sessions/{ppid}.json`;
+6 work stages + 2 terminals, owned by ec-workflow:
+`INIT → ANALYSIS → IMPLEMENT → REVIEW → VERIFICATION → MEMORY → COMPLETE`, plus `CLOSED`
+(user abort, no memory flow). Every legal stage edge records `task.json.pending_transition`
+and requires explicit user confirmation by default. VERIFICATION remains the fresh-evidence
+hard gate, and MEMORY keeps the conditional long-memory threshold gate. The active task
+pointer lives in `sessions/{ppid}.json`;
 when the task reaches `COMPLETE` or `CLOSED`, the state API clears `current_task` so the
 session returns to Ready. Each task's stage persists in its `task.json`. Hooks inject the
 session and task state as breadcrumbs so every reply can render the status line.
@@ -57,7 +59,8 @@ stage in `task.json`; no data is lost. Each task folder is self-contained.
 
 ## Task persistence
 
-Each task is a folder. `task.json` is metadata; `dev-spec.md` is the human-readable plan;
+Each task is a folder. `task.json` is metadata, including the current stage and any
+`pending_transition`; `dev-spec.md` is the human-readable plan;
 `execution.jsonl` is an append-only plan-and-log (one `plan` record, then `dispatch`/`result`
 /`review`/`verify`/`handoff` records). Because plan and log live on disk, not in an agent's
 context window, a task survives session end and agent switches with zero information loss.

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

@@ -1,6 +1,6 @@
 ---
 name: ec-analysis
-description: ANALYSIS-stage skill. Use when ec-workflow enters ANALYSIS. Creates the dev-spec skeleton FIRST (template-first), then fills incrementally — producing the narrative plan, execution plan (execution.jsonl), and test strategy. Ends in WAITING_CONFIRM. Grounds every conclusion in real code, never restates the requirement.
+description: ANALYSIS-stage skill. Use when ec-workflow enters ANALYSIS. Creates the dev-spec skeleton FIRST (template-first), then fills incrementally — producing the narrative plan, execution plan (execution.jsonl), and test strategy. Ends by requesting the confirmed edge to IMPLEMENT. Grounds every conclusion in real code, never restates the requirement.
 ---
 
 > **SKELETON FIRST — your first two tool calls MUST be: (1) Read `.easy-coding/templates/dev-spec-skeleton.md`, (2) Write its EXACT content to the task's dev-spec.md. No exceptions. Do not analyze or think before the skeleton file exists on disk.**
@@ -42,8 +42,8 @@ Communicate with the user in the user's language.
    which subset this round?" as an explicit item in 待用户决策 for the user to decide. Never
    make a scope-narrowing decision yourself and present it as settled. Never fabricate a
    premise such as "the user already fixed scope X in INIT" or "auto_mode already selected Y"
-   to justify narrowing — `auto_mode` only waives the WAITING_CONFIRM confirmation step and
-   carries NO scope or delivery-form decision whatsoever.
+   to justify narrowing — `auto_mode` only waives stage-boundary prompts under an explicit
+   autonomous user request and carries NO scope or delivery-form decision whatsoever.
 6. **改动范围 lists ONLY real project code.** The 改动范围 table carries only changes to real
    project source/config files. Any harness artifact under `.easy-coding/` (dev-spec.md,
    execution.jsonl, test-strategy.md, memory files, generated reports, etc.) is FORBIDDEN in
@@ -218,7 +218,8 @@ VERIFICATION baseline).
 
 > 修订同样受 HARD RULE 5/6 约束：用户的修订诉求若是扩大或细化代码改动，不得借机把任务降级为"出报告"；范围收窄仍须作为 待用户决策 项由用户确认。
 
-On user revision request at WAITING_CONFIRM, do NOT reply with only a change summary.
+On user revision or Other feedback while ANALYSIS has a pending transition, first cancel the
+pending edge. Do NOT reply with only a change summary.
 Re-output the COMPLETE revised dev-spec.md:
 
 1. Prepend a `### 修订摘要` listing each user request and its impact on the plan. If the
@@ -227,11 +228,11 @@ Re-output the COMPLETE revised dev-spec.md:
    sections), incorporating all revisions.
 3. Overwrite the `plan` record in execution.jsonl with the new strategy.
 4. Update test-strategy.md if test scope changed.
-5. Re-enter WAITING_CONFIRM and wait for explicit user confirmation.
+5. Request ANALYSIS -> IMPLEMENT again and present the standard confirmation/handoff/Other gate.
 
 ## End state
 
 Read dev-spec.md back from disk and output the COMPLETE content as your reply to the user —
-not a summary, not a different format, not a table you invented. Then set stage to
-WAITING_CONFIRM and hand control back to ec-workflow. Never start implementing from this
-skill.
+not a summary, not a different format, not a table you invented. Then ask ec-workflow to
+record `pending_transition: ANALYSIS -> IMPLEMENT`, present the standard boundary choices,
+and stop. Never start implementing from this skill.

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

@@ -66,7 +66,8 @@ After saving the design doc, ask the user: "Design confirmed. Start a task based
 design now?" Offer two options:
 
 1. **Start task now** — invoke `{{skill_trigger}}ec-workflow` with the design topic as the
-   task prompt. ec-workflow will create the task (step 4) and enter INIT → ANALYSIS.
+   task prompt. ec-workflow will create the task and enter INIT. After INIT completes, it
+   presents the standard confirmation/handoff/Other gate before entering ANALYSIS.
    ec-analysis will discover the design doc in `.easy-coding/spec/` and use it as input.
 2. **Later** — tell the user the design is saved and they can run
    `{{skill_trigger}}ec-workflow` whenever ready.

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

@@ -46,8 +46,8 @@ EVERY STRATEGY = MANDATORY SUB-AGENT DISPATCH. NO EXCEPTIONS.
 
 You MUST dispatch sub-agents using {{sub_agent_dispatch}} for every unit, whatever the
 strategy. You are FORBIDDEN from implementing any unit yourself in the main agent. Doing the
-work inline instead of dispatching is a protocol violation equivalent to skipping
-WAITING_CONFIRM.
+work inline instead of dispatching is a protocol violation equivalent to bypassing the
+ANALYSIS -> IMPLEMENT confirmation gate.
 
 Self-check before writing ANY implementation code:
 - Am I about to write implementation code in the main agent? → STOP. Dispatch a sub-agent.
@@ -107,8 +107,9 @@ let sub-agents re-dispatch each other.
 
 ## End state
 
-All units done and self-audited → hand back to ec-workflow to advance to REVIEW. If you
-hit something that invalidates the plan, return to ANALYSIS instead of improvising.
+All units done and self-audited → hand back to ec-workflow to request IMPLEMENT -> REVIEW and
+wait at the standard confirmation/handoff/Other gate. If something invalidates the plan,
+request IMPLEMENT -> ANALYSIS and wait at the same gate instead of improvising.
 
 ## Self-check gates (before handing back)
 

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

@@ -1,18 +1,18 @@
 ---
 name: ec-memory
-description: MEMORY_SHORT and MEMORY_LONG stage skill — part of the archive flow, triggered only after user acceptance. Use when ec-workflow enters the memory stages. Writes schema-v2 short memory with a sliding window, distills long memory into BUSINESS/TECHNICAL with conflict resolution, and backfills ABSTRACT on architecture changes.
+description: MEMORY-stage skill — part of the archive flow, triggered only after user acceptance and a confirmed stage edge. Writes one schema-v2 short memory, then runs the authoritative conditional long-memory gate, performs optional distillation, and requests COMPLETE.
 ---
 
 # ec-memory — archive what was learned
 
-ec-workflow dispatches you during MEMORY_SHORT and MEMORY_LONG, which run only after the
-user accepts the task. Inputs: the task's `dev-spec.md`, `execution.jsonl` (the `result` and
+ec-workflow dispatches you during MEMORY, which runs only after the user accepts the task and
+confirms entry. Inputs: the task's `dev-spec.md`, `execution.jsonl` (the `result` and
 `verify` records are precise source material), the changed-files list, existing memory files.
 
 Communicate with the user in the user's language. Memory file content follows the project's
 recorded comment/doc language.
 
-## MEMORY_SHORT — write one short memory entry
+## Step 1 — write one short memory entry
 
 Create one file under `.easy-coding/memory/short/` following the format in
 `.easy-coding/memory/SHORT_MEMORY_TEMPLATE.md`. File naming convention:
@@ -23,6 +23,7 @@ Frontmatter (all fields required):
 ---
 memory_schema: 2
 id: SM-{YYYYMMDD}-{NN}
+source_task: {current task id, exact}
 date: {YYYY-MM-DD}
 task_type: {feature | bugfix | refactor | perf | doc | workflow}
 project_mode: {startup | iteration}
@@ -45,6 +46,13 @@ conversation. Refer to SHORT_MEMORY_TEMPLATE.md for the complete section format.
 
 If the task was cross-repo, record the repo names involved and the collaboration reason.
 
+After the file is successfully written, record the checkpoint immediately:
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-short-complete --session-file <P> --file "<relative-short-memory-path>" --agent <agent-id>`.
+Use the returned `status_context` as authoritative. On resume, if `memory_progress` already
+shows `short_memory_written:true`, do not create a duplicate entry; continue from Step 2.
+The state API validates `memory_schema: 2`, requires `source_task` to equal the current task id,
+and fingerprints the file. Do not reuse an older task's memory file as this checkpoint.
+
 ## Supermodule memory routing
 
 If the current project config contains `supermodule.role: super-parent`, archive memory by
@@ -67,26 +75,27 @@ create a new one instead. Short memories serve as both a recent-detail sliding w
 distillation buffer for long-term memory.
 
 **Sliding window (informational):** The short memory directory has a soft cap defined by
-`memory.short_term_max` (default 10). MEMORY_SHORT only WRITES one entry per completed task
-— it never counts, trims, or triggers distillation. Trimming is exclusively MEMORY_LONG's
-responsibility and only runs when the threshold is exceeded.
+`memory.short_term_max` (default 10). Step 1 only writes and checkpoints one entry per
+completed task. It never decides whether to distill.
 
-## MEMORY_LONG — distill durable knowledge (CONDITIONAL)
+## Step 2 — run the long-memory gate (CONDITIONAL)
 
 <HARD-GATE>
-MEMORY_LONG IS CONTROLLED BY THE STATE API `memory_long` INSTRUCTION.
+LONG-MEMORY WORK IS CONTROLLED BY THE STATE API `memory` INSTRUCTION.
 
 Before performing ANY distillation work:
-1. Read the `memory_long` object returned by the state API transition to MEMORY_LONG.
-   If it is not visible in context, re-run the same transition command for MEMORY_LONG to
-   re-emit the snapshot, then use that `memory_long` object.
-2. Treat `memory_long.action` as authoritative. Do NOT recount short memories yourself and
+1. After Step 1 is checkpointed, call
+   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-instruction --session-file <P>`.
+   This ordering is mandatory: the current task's short entry must be counted first.
+   The first successful call is frozen in `memory_progress.instruction`; resumed work reuses
+   the same action and trim count even after consumed short files are deleted.
+2. Treat the returned `memory.action` as authoritative. Do NOT recount short memories yourself and
    do NOT override the state API instruction with prompt reasoning.
-3. If `action == "no-op"`: output "MEMORY_LONG: no-op (short memory count = {short_count},
-   threshold = {short_term_max})" and immediately hand back to ec-workflow to advance to
-   COMPLETE. Do NOT read long memory files, do NOT attempt distillation, do NOT modify any file.
-4. If `action == "distill"`: distill exactly the older `trim_count` short-memory entries
-   and keep the latest `short_term_keep` entries.
+3. If `action == "no-op"`: output "MEMORY: long-memory no-op (short memory count =
+   {short_count}, threshold = {short_term_max})". Do NOT read or modify long memory files.
+4. If `action == "distill"`: treat `memory.candidate_files` and `memory.kept_files` as the
+   frozen authoritative sets. Distill and delete exactly `candidate_files`; preserve every
+   `kept_files` entry. Do not rebuild either set from the live directory.
 
 This gate is absolute. Even a single short memory entry below threshold does NOT trigger
 long-term compression regardless of any other signal.
@@ -100,8 +109,8 @@ Three-file long memory:
 - `TECHNICAL.md` — architecture decisions, implementation patterns, gotchas.
 
 Distillation steps:
-1. Use `memory_long.short_term_keep` and `memory_long.trim_count`. Keep the latest
-   `short_term_keep` entries; the older `trim_count` entries become distillation candidates.
+1. Use `memory.candidate_files` and `memory.kept_files`; their sizes correspond to
+   `memory.trim_count` and the retained window calculated at instruction time.
 2. Read the `target_long` of candidate short memories; route to business/technical.
 3. **Progressive loading** — read only the existing long entries matching this round's
    domain/tags/related_files. No unbounded whole-repo memory scan.
@@ -116,6 +125,19 @@ Distillation steps:
    This is sliding-window consumption after successful distillation, not destructive
    deletion of durable long-term knowledge.
 
+After either branch succeeds, record completion with the same authoritative action:
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-complete --session-file <P> --action <no-op|distill> --agent <agent-id>`.
+The state API rejects an action that disagrees with the current threshold calculation.
+For `distill`, it also rejects completion while any frozen candidate still exists or any
+frozen retained file is missing. A candidate checkpoint may disappear only because it is
+explicitly listed in `candidate_files`.
+
+## Step 3 — request COMPLETE
+
+Only after `memory_progress.completed:true`, hand control to ec-workflow to request
+MEMORY -> COMPLETE. Present the standard confirmation/handoff/Other gate and stop. Do not
+mark the task COMPLETE automatically.
+
 ## ABSTRACT backfill / update
 
 While distilling technical memory, if you detect an architecture change — module added or

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

@@ -30,9 +30,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 +46,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 +88,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-verification/SKILL.md

@@ -54,7 +54,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,9 +63,10 @@ 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, then re-REVIEW → re-VERIFICATION after
+    the user confirms each stage edge.
   - 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.
@@ -72,21 +74,14 @@ test manually. Their response routes:
 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.
+## 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. It later requests MEMORY -> COMPLETE and waits for a separate confirmation.

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

@@ -65,27 +65,24 @@ replies are English.
 ## State machine
 
 ```
-INIT -> ANALYSIS -> WAITING_CONFIRM -> IMPLEMENT -> REVIEW -> VERIFICATION
-                          ^                ^                      |
-                          |                +---- repair loop -----+
-                          +--- revision ---+                      |
-                                                        [user acceptance]
-                                                                  |
-                                          MEMORY_SHORT -> MEMORY_LONG -> COMPLETE
+INIT -> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY -> COMPLETE
+          ^            ^          |             |
+          +-- replan ---+          +--- fix -----+
+                       ^                         |
+                       +------- repair ----------+
+every edge --[explicit user confirmation by default]--> 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; request ANALYSIS |
+| ANALYSIS | ec-analysis | dev-spec + execution plan + test strategy | analysis presented; request IMPLEMENT |
+| IMPLEMENT | ec-implementing | code changes per confirmed plan | all units done; request REVIEW |
+| 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; request COMPLETE |
+| COMPLETE | ec-workflow | clear current_task, set task status, summary | terminal after user confirms entry |
 | CLOSED | ec-task-close | user abort; no memory flow | terminal |
 
 > **INIT delivery-form rule.** When creating the task, `type` and `title` must faithfully
@@ -111,14 +108,31 @@ 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
+  the ANALYSIS -> IMPLEMENT confirmation gate passes. No exception for "simple" tasks —
+  simple tasks have short analyses, not skipped ones.
+- **Every stage edge is a confirmation gate by default.** Stage completion does NOT change
+  `task.json.status`. It records a `pending_transition` through the state API, presents the
+  standard choices below, and stops. This applies to forward edges, repair/replan edges, and
+  MEMORY -> COMPLETE. Task creation entering INIT and the separately confirmed ec-task-close
+  flow do not add a redundant second prompt.
+- **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.
+  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 confirmed stage advance is a two-step protocol: first consume
+  the pending edge through `confirm-transition`, then run that stage's real work. 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
@@ -128,51 +142,45 @@ routing matches, and switching happens again.
   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 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.
+- **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 before re-walking
+  REVIEW -> 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. Only after `memory-complete` may ec-memory request MEMORY -> COMPLETE.
+- **COMPLETE closeout:** COMPLETE is also a confirmed edge. Once the user confirms it, the
+  state API clears session `current_task`, so the next hook injection returns to Ready. Then
+  output a summary (what was done, files changed, key decisions).
 
 ## Resume and handoff
 
@@ -186,16 +194,15 @@ 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. Re-present the
+   standard confirmation/handoff/Other choices for its stored target.
+5. 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 pending stage edge includes the standard 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 +211,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,16 +35,20 @@ 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).
+- Stages do not skip. Every legal stage edge uses `pending_transition` and requires explicit
+  user confirmation by default. At each boundary, use the agent's native user-choice tool
+  whenever available to offer: confirm target stage, hand off to another agent, or its
+  free-form Other input. Plain-text numbered choices are fallback only. `auto_mode` only
+  waives prompts when configured and explicitly requested by the user; 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.
+- MEMORY combines short-memory creation and the conditional long-memory gate. Archive runs
+  only after explicit user acceptance — an unaccepted task's memory is dirty data.
 - NO 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
@@ -54,8 +58,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