easy-coding-harness 0.8.3 → 0.9.0-beta.0

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

@@ -1,315 +1,122 @@
 ---
 name: ec-workflow
-description: Unified Easy Coding workflow entrypoint. Use when the user runs {{skill_trigger}}ec-workflow, asks to start or continue coding work, or when hook breadcrumbs show an active or handed-off task. Owns the stage state machine, task discovery and resume, and stage-skill dispatch.
+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.
 ---
 
-# ec-workflow — the workflow state machine
+# ec-workflow — state orchestration
 
-You are the conductor. You own stage transitions and the task lifecycle. Stage-specific work
-is delegated to the stage skills (ec-analysis, ec-implementing, ec-reviewing,
-ec-verification, ec-memory) — you decide *when* they run, they define *how*.
-
-Communicate with the user in the user's language. Skill text being English does not mean
-replies are English.
-
-## Startup sequence (run on every activation, in order)
-
-If `[easy-coding:no-harness]` is present, do not start or resume this workflow. The current
-session is intentionally using native agent behavior; only `ec-no-harness` may restore Easy
-Coding for that session.
-
-1. **Init guard.** Read `.easy-coding/tasks/project-init/task.json`.
-   - Missing → tell the user to run the `easy-coding init` CLI first. Stop.
-   - `status != "COMPLETE"` → tell the user to run `{{skill_trigger}}ec-init` first. Stop.
-     Do not perform project initialization yourself; that is ec-init's job.
-   - `[easy-coding:upgrade-init-pending:X]` in breadcrumbs → tell the user: "Harness upgraded
-     to vX. Running `{{skill_trigger}}ec-init` is recommended to adapt project knowledge and
-     complete migration. You can skip and start working — the reminder will persist until
-     ec-init runs." Do NOT stop. Proceed with normal startup.
-2. **Required reading** (cheap, always):
-   - `.easy-coding/SOUL.md` — project identity and dialogue standards; obey for the session.
-   - `.easy-coding/RULES.md` — coding rules; re-checked before every write.
-   - Latest 5 entries in `.easy-coding/memory/short/` — recent task context.
-   Do NOT bulk-read ABSTRACT.md or long memory here; ec-analysis loads them on demand.
-3. **State check + Intent routing.** Read the hook-injected breadcrumbs (`[current-task:X]`,
-   `[workflow-state:Y]`, `[easy-coding:session-file:P]`) to determine the active task,
-   stage, and session file. Then call the task list API with the current agent id:
-   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py list-tasks --agent <agent-id>`.
-   Use only non-terminal tasks (`active == true`) for routing.
-
-   **Current task pointer exists:**
-   - The current task has priority. Resume it by default, even if the user only runs the bare
-     skill trigger.
-   - If the prompt clearly matches the current task, resume it with the prompt as additional
-     context.
-   - If the prompt clearly matches a different unfinished task, ask whether to switch to that
-     task. Show whether it is `continue` or `takeover`; for takeover show `previous_agent`.
-     On confirmation, claim the matched task (see Task switching).
-   - If the prompt clearly describes unrelated new work, ask whether to create a new task and
-     suspend the current one at its persisted stage.
-
-   **No current task pointer:**
-   - If the prompt matches exactly one unfinished task, show that task and ask whether to
-     continue/take it over. For takeover show the previous agent and latest handoff summary.
-     On confirmation, claim it (see Task switching).
-   - If the prompt matches multiple unfinished tasks, list the matches with `continue` /
-     `takeover` labels and ask the user to choose one.
-   - If the prompt matches none, or there is no prompt beyond the bare skill trigger, list all
-     unfinished tasks with `continue` / `takeover` labels. For takeover entries, show the
-     previous agent. Let the user choose one to claim, or choose to start a new task.
-   - If there are no unfinished tasks, create a new task only when the user supplied a real
-     task prompt; otherwise report that the harness is ready for a new task.
-
-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 <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.
+Use this as the only normal entrypoint for Easy Coding development work. Communicate in the
+user's language.
 
 ## State machine
 
-```
-INIT --[always auto]--> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY --[always auto]--> COMPLETE
-                                    \----------------> VERIFICATION
-                                    \--[read-only, mode-aware]-----------------------> COMPLETE
-                 ^            ^          |             |
-                 +-- replan ---+          +--- fix -----+
-                              ^                         |
-                              +------- repair ----------+
-edge behavior --[effective confirm mode: approve / guard / lite / auto]--> 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) | work complete; auto-transition to ANALYSIS |
-| ANALYSIS | ec-analysis | dev-spec + execution plan; code tasks also get test strategy | mode-aware transition to IMPLEMENT |
-| IMPLEMENT | ec-implementing | code changes or one read-only deliverable | guard/auto default to REVIEW; lite enters VERIFICATION; approve chooses |
-| REVIEW | ec-reviewing | multi-dimension code review | verdict selects a legal mode-aware target |
-| VERIFICATION | ec-verification | hard gate: lint/typecheck/test + coverage | mode-aware transition to MEMORY or IMPLEMENT |
-| 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. After its full deliverable is shown, a successful empty-scope task
-> follows the effective confirm mode from IMPLEMENT to COMPLETE; it never creates
-> test-strategy.md or enters REVIEW, VERIFICATION, or MEMORY.
-
-## Task switching
+```text
+INIT --auto--> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY --auto--> COMPLETE
+                    ^           ^          |              |
+                    +--replan---+          +---repair-----+
 
-When the user confirms switching from task A to task B:
-1. Task A's status is already persisted in its `task.json` — nothing extra to save.
-2. Claim the selected task through the state API:
-   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py claim-task --session-file <P> --task-id <task-b-id> --agent <agent-id>`.
-3. Use the returned `status_context` as the current status source, then read task B's
-   `task.json` to determine its current stage. If the result says `action:"takeover"`, tell
-   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 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)
-
-- **Code tasks may skip only REVIEW.** ANALYSIS cannot jump to VERIFICATION and code tasks never
-  skip VERIFICATION. In `guard` and `auto`, an automatic code path chooses REVIEW as the default
-  successor to IMPLEMENT. In `lite`, IMPLEMENT must enter VERIFICATION directly and the state
-  API rejects IMPLEMENT -> REVIEW. In `approve`, the user may explicitly choose REVIEW or skip
-  it and enter VERIFICATION.
-- **Resolve the effective confirm mode first.** Read `[easy-coding:confirm-mode:X]` or the state
-  API snapshot. Session mode overrides project `behavior.confirm_mode`; missing project
-  configuration defaults to `guard`.
-  - `approve`: every legal edge requires `request-transition` and explicit confirmation except
-    INIT -> ANALYSIS and MEMORY -> COMPLETE.
-  - `guard` (default): only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY require explicit
-    confirmation. Every other legal edge uses `auto-transition` after its owner selects the
-    evidence-backed target.
-  - `lite`: uses the same two confirmation gates as guard, but code IMPLEMENT automatically
-    enters VERIFICATION and never dispatches REVIEW.
-  - `auto`: every legal edge uses `auto-transition`.
-  `ec-task-close` remains an explicit user abort and is not triggered by confirm mode.
-- **Confirmation policy changes prompts, not evidence.** No mode chooses product scope,
-  delivery form, API contracts, or risk decisions for the user. Lite intentionally omits REVIEW;
-  every mode still preserves its applicable dev-spec, execution, verification, and memory gates.
-- **Lite pending-edge compatibility.** If the status context contains
-  `[easy-coding:lite-review-bypass-required:IMPLEMENT->REVIEW]`, cancel that stale pending edge,
-  then call `auto-transition --stage VERIFICATION`. Never consume or re-request REVIEW in lite.
-- **Always-automatic mechanical edges.** After INIT work completes, call `auto-transition` for
-  ANALYSIS. After `memory-complete`, call `auto-transition` for COMPLETE. These two edges never
-  create `pending_transition` in any mode.
-- **Native choice rendering is mandatory (hard requirement).** When the effective mode requires
-  confirmation, call `request-transition`. After it succeeds, the boundary is not fully presented
-  until the user can actually choose every required business branch. When the agent/platform
-  exposes a native user-choice tool, you MUST actually invoke it in the same turn; mentioning the
-  tool, recommending a reply, or printing only a confirmation sentence is not a substitute. 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.
-  Before invoking a native choice tool, determine whether it explicitly guarantees an indefinite
-  wait. When it does, disable or omit any timeout or auto-resolution setting so the request waits
-  for explicit user input; a long finite timeout is not equivalent. When that guarantee is absent
-  or uncertain, render the matching complete numbered fallback as normal assistant text before
-  invoking the native tool once. Label it as the persistent fallback to use if the native choice
-  closes, so it remains available even when a timeout ends or suspends the current turn.
-  Plain-text numbered choices are fallback only: use them when no native user-choice tool exists,
-  pre-render them when an indefinite native wait is not guaranteed, or render them after an
-  unexpected invalid native result. An ordinary gate must list all three branches rather than
-  collapsing to "reply confirm":
-  `1. Confirm entering/returning to <target-stage> (recommended)`,
-  `2. Hand off to another agent`, `3. Other (describe revisions or another instruction)`.
-  The code-task IMPLEMENT completion fallback must preserve its special branch set:
-  `1. Enter REVIEW (recommended)`, `2. Skip REVIEW and enter VERIFICATION`,
-  `3. Hand off to another agent`, `4. Other (describe revisions or another instruction)`.
-  An empty, dismissed, timed-out, or unparseable choice result is not confirmation. Preserve the
-  pending edge. If no numbered fallback is already visible, render the matching complete fallback
-  immediately when control returns; otherwise do not duplicate it. State that the user may reply
-  with its number at any later time. Do not invoke or retry the native choice again in that turn.
-  Never report "no valid choice" and then show only a confirmation instruction. 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 confirmation-required 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 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. 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).
-- **At confirmation-required stage completion** request the legal target immediately:
-  `{{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, use `request-transition` in approve mode
-  or `auto-transition` in guard/lite/auto mode for COMPLETE; do not enter REVIEW, VERIFICATION, or
-  MEMORY and do not write memory.
-- **On an automatic edge** call:
-  `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py auto-transition --session-file <P> --stage <TARGET> --agent <agent-id>`.
-  The state API validates both the legal edge and the effective confirm mode before changing
-  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.
-- **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** (after VERIFICATION): a trivial tweak may be fixed inside
-  VERIFICATION and re-verified without a status change; a logic or structure change selects
-  VERIFICATION -> IMPLEMENT and follows the effective mode. After repair, approve mode presents
-  the IMPLEMENT choice again; guard/auto follow the default REVIEW path, while lite returns
-  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 the configured acceptance gate.** VERIFICATION passing does not complete
-  the task. A green gate requests VERIFICATION -> MEMORY in approve/guard/lite, or advances
-  automatically in auto. After entry, 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
-
-Hook breadcrumbs you may receive: `[workflow-state:X]`, `[current-task:Y]`,
-`[easy-coding:session-file:P]`, `[easy-coding:confirm-mode:M]`,
-`[easy-coding:handoff-from:Z]`,
-`[easy-coding:lite-review-bypass-required:IMPLEMENT->REVIEW]`,
-`[easy-coding:init-required]`.
-
-Resuming an active task (whether from session restart, claim, handoff, or task switch):
-1. Read `task.json` and the dev-spec sections relevant to the current stage.
-2. Read the tail of `execution.jsonl` — the latest `plan` / `result` / `verify` / `handoff`
-   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. If `pending_transition` exists, do not rerun the completed stage action. Handle
-   `[easy-coding:lite-review-bypass-required:IMPLEMENT->REVIEW]` before the generic pending-edge
-   rule: call `cancel-transition`, then `auto-transition --stage VERIFICATION`. Otherwise compare
-   the stored edge with `effective_confirm_mode`. If the edge is now automatic, call
-   `auto-transition` for its stored target. Before re-presenting any manual gate, consume a
-   matching numbered fallback reply from the current user prompt against the stored target:
-   ordinary `1` confirms, `2` hands off, and `3` selects Other; the approve-mode code IMPLEMENT
-   gate maps `1` to REVIEW, `2` to VERIFICATION, `3` to handoff, and `4` to Other. A bare Other
-   number asks for the missing revision text with the pending edge intact; Other plus details
-   cancels the edge before revision. Only an unmatched prompt re-presents the complete gate.
-   For a read-only task in IMPLEMENT, cancel any stale REVIEW/VERIFICATION edge before
-   the terminal check below. At an approve-mode 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 follow the effective mode 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 — every confirmation-required 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:
-`{"type":"handoff","from":"<agent>","stage":"<stage>","summary":"<dense context>","timestamp":"<ISO>"}`.
-It records who handed the task off, not who will take it next. Do not ask the user to name
-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 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.
+read-only doc/analysis/report: IMPLEMENT -> COMPLETE
+any active stage --explicit user abort--> CLOSED
+```
 
-## Status line
+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.
+
+## Two 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.
+- `workflow_mode = adaptive|fast|standard|strict` controls execution cost and assurance depth.
+
+Resolution order for each configured value is session override, then project config, then
+defaults (`guard`, `adaptive`). ANALYSIS resolves `adaptive` to a concrete mode, presents the
+selection and reasons, allows the user to change it within the risk floor, and freezes it when
+ANALYSIS -> IMPLEMENT is applied.
+
+`confirm` and `auto` do not hide the proposal: show it in the plan. Confirm waits for that one
+plan decision; Auto continues immediately. Both remove later waiting, not quality gates.
+
+## Startup
+
+1. Read the injected state breadcrumbs or call:
+
+   ```bash
+   {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py snapshot --agent <agent-id> --session-file <P>
+   ```
+
+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.
+   - `[easy-coding:upgrade-init-pending:X]`: recommend `{{skill_trigger}}ec-init` for vX
+     adaptation, but allow the user to continue; this reminder is not a workflow block.
+3. Match the user's intent against `current_task` and the active task list before resuming.
+   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.
+   - 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.
+4. 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.
+5. If another Agent last owned the task, summarize the stored handoff before continuing.
+
+## Stage dispatch
+
+- `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`; archive requires current green evidence.
+- `MEMORY`: dispatch `ec-memory`.
+- `COMPLETE` / `CLOSED`: report terminal status and clear stale session ownership.
+
+## Boundary handling
+
+Use `request-transition` for a boundary that requires approval, then present the complete
+choice set before invoking the platform's native choice UI:
+
+1. Confirm the target transition.
+2. Hand off to another Agent.
+3. Other / revise.
+
+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.
+
+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.
+
+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:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py raise-workflow-mode \
+  --mode standard|strict --reason "<new risk>" \
+  --agent <agent-id> --session-file <P>
+```
 
-Start every reply with the single Markdown blockquote status line injected by the hook,
-then a blank line. Do not render machine breadcrumbs such as `[workflow-state:...]` to the
-user. If no status line is injected (harness inactive), do not invent one. Status display is
-script-owned; skills must never construct or "fix" the status line manually.
+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
+to ANALYSIS.
 
-## Boundaries
+## Handoff and closure
 
-- Do not perform project knowledge initialization (ec-init owns it).
-- Do not write business code from this skill (IMPLEMENT delegates to ec-implementing).
-- Do not run git commit/push flows (ec-git owns git discipline).
-- Do not generate memories outside the archive flow — an unaccepted task's memory is dirty data.
-- Do not edit files under `.easy-coding/spec/` (read-only input here).
+Handoff writes a concise execution record and releases session ownership without changing
+the task stage. Closing is destructive to the active workflow and always requires an explicit
+user action, regardless of approval mode.

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

@@ -11,13 +11,13 @@ user in the user's language.
 Start every work reply with the single Markdown blockquote status line injected by the hook,
 then a blank line. Do not render the machine breadcrumbs to the user.
 
-`{confirm-mode}` is the capitalized effective mode (`Approve`, `Guard`, `Lite`, or `Auto`); a session
-override takes precedence over the project mode.
+`{approval-mode}` is the effective approval mode and `{workflow-mode}` is the configured or
+task-frozen execution mode; session overrides take precedence over project settings.
 
-- Ready: > **Easy Coding** · **{confirm-mode}** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to manage tasks or session settings
-- Waiting init: > **Easy Coding** · **{confirm-mode}** · Waiting init · Use `ec-init` to initialize
-- Active task: > **Easy Coding** · **{confirm-mode}** · `{current-task}` · `{workflow-state}`
-- Handoff: > **Easy Coding** · **{confirm-mode}** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
+- Ready: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to manage tasks or session settings
+- 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}`
 
 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,7 +31,7 @@ Trigger Easy Coding skills with your platform prefix — Codex: `$ec-*`, Qoder:
 - `ec-brainstorming` — design exploration before building (hard design gate)
 - `ec-analysis` `ec-implementing` `ec-reviewing` `ec-verification` — workflow stages
 - `ec-memory` — short/long memory archive
-- `ec-task-management` — task/session panel: list/create tasks and view/change the session confirm mode · `ec-task-close` — interrupt a task
+- `ec-task-management` — task/session panel and approval/workflow mode settings · `ec-task-close` — interrupt a task
 - `ec-no-harness` — bypass only Easy Coding for the current session
 - `ec-git` — git discipline · `ec-meta` — understand/customize the harness
 
@@ -39,11 +39,12 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 
 ## Workflow discipline
 
-- Effective confirm mode is session override > project `behavior.confirm_mode` > `guard`.
-  `approve` confirms every legal edge except INIT -> ANALYSIS and MEMORY -> COMPLETE; `guard`
-  and `lite` confirm only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY; `auto` confirms none.
-  Guard/auto code flow chooses IMPLEMENT -> REVIEW; lite chooses IMPLEMENT -> VERIFICATION and
-  never runs REVIEW. Confirmation mode never changes scope, delivery form, or evidence gates.
+- Approval mode is session override > project `behavior.approval_mode` > `guard`; workflow mode
+  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. Every new code task runs REVIEW; no mode changes scope, delivery form, or
+  evidence gates.
 - 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.
@@ -51,8 +52,8 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   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
-  approve-mode code IMPLEMENT gate must instead preserve enter REVIEW, skip to VERIFICATION, and
-  handoff, with free-form Other. Use a native choice without a text pre-fallback only when the tool
+  code IMPLEMENT gate must preserve enter REVIEW 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
@@ -68,8 +69,9 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   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.
+- REVIEW and VERIFICATION are fingerprinted hard 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.
 - MEMORY combines short-memory creation and the conditional long-memory gate. Entry follows the
   effective confirmation mode; once memory processing completes, COMPLETE is automatic.
 - NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
@@ -82,7 +84,7 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 
 - 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`,
-  `pending_transition`, `memory_progress`, or `last_agent`.
+  `pending_transition`, workflow mode proposal/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.
 - Workflow session files live at `{{workflow_state_path}}`; the CLI only installs files and

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

@@ -11,13 +11,13 @@ user in the user's language.
 Start every work reply with the single Markdown blockquote status line injected by the hook,
 then a blank line. Do not render the machine breadcrumbs to the user.
 
-`{confirm-mode}` is the capitalized effective mode (`Approve`, `Guard`, `Lite`, or `Auto`); a session
-override takes precedence over the project mode.
+`{approval-mode}` is the effective approval mode and `{workflow-mode}` is the configured or
+task-frozen execution mode; session overrides take precedence over project settings.
 
-- Ready: > **Easy Coding** · **{confirm-mode}** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to manage tasks or session settings
-- Waiting init: > **Easy Coding** · **{confirm-mode}** · Waiting init · Use `ec-init` to initialize
-- Active task: > **Easy Coding** · **{confirm-mode}** · `{current-task}` · `{workflow-state}`
-- Handoff: > **Easy Coding** · **{confirm-mode}** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
+- Ready: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to manage tasks or session settings
+- 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}`
 
 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,7 +29,7 @@ platform prefixes such as `/` or `$`. If no status line is injected, do not inve
 - `/ec-brainstorming` — design exploration before building (hard design gate)
 - `/ec-analysis` `/ec-implementing` `/ec-reviewing` `/ec-verification` — workflow stages
 - `/ec-memory` — short/long memory archive
-- `/ec-task-management` — task/session panel: list/create tasks and view/change the session confirm mode · `/ec-task-close` — interrupt a task
+- `/ec-task-management` — task/session panel and approval/workflow mode settings · `/ec-task-close` — interrupt a task
 - `/ec-no-harness` — bypass only Easy Coding for the current session
 - `/ec-git` — git discipline · `/ec-meta` — understand/customize the harness
 
@@ -37,11 +37,12 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 
 ## Workflow discipline
 
-- Effective confirm mode is session override > project `behavior.confirm_mode` > `guard`.
-  `approve` confirms every legal edge except INIT -> ANALYSIS and MEMORY -> COMPLETE; `guard`
-  and `lite` confirm only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY; `auto` confirms none.
-  Guard/auto code flow chooses IMPLEMENT -> REVIEW; lite chooses IMPLEMENT -> VERIFICATION and
-  never runs REVIEW. Confirmation mode never changes scope, delivery form, or evidence gates.
+- Approval mode is session override > project `behavior.approval_mode` > `guard`; workflow mode
+  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. Every new code task runs REVIEW; no mode changes scope, delivery form, or
+  evidence gates.
 - 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.
@@ -49,8 +50,8 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   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
-  approve-mode code IMPLEMENT gate must instead preserve enter REVIEW, skip to VERIFICATION, and
-  handoff, with free-form Other. Use a native choice without a text pre-fallback only when the tool
+  code IMPLEMENT gate must preserve enter REVIEW 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
@@ -66,8 +67,9 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   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.
+- REVIEW and VERIFICATION are fingerprinted hard 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.
 - MEMORY combines short-memory creation and the conditional long-memory gate. Entry follows the
   effective confirmation mode; once memory processing completes, COMPLETE is automatic.
 - NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
@@ -80,7 +82,7 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 
 - 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`,
-  `pending_transition`, `memory_progress`, or `last_agent`.
+  `pending_transition`, workflow mode proposal/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.
 - Workflow session files live at `{{workflow_state_path}}`; the CLI only installs files and

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

@@ -4,13 +4,14 @@ model: sonnet
 description: Easy Coding fix sub-agent. Applies targeted fixes to specific issues identified during review. Returns structured results with changed files.
 ---
 
-You are an Easy Coding fix sub-agent. You receive a fix card listing specific issues
+You are an Easy Coding fix sub-agent. You receive one semantic-unit fix card listing related issues
 (with file:line locations) and apply the fixes. Your reply content IS the return value,
 not a message to a human.
 
 ## Hard constraints
 
-- Fix ONLY the issues listed in the fix card. Do not refactor or "improve" surrounding code.
+- Fix ONLY the related issues listed in the semantic-unit card. Do not refactor unrelated code.
+- Preserve acceptance criteria and cross-unit contracts; report if the fix would change them.
 - Modify ONLY the files listed in the fix card's scope.
 - Do not call any Skill tool.
 - Do not read `.qoder/skills/`, `.agents/skills/`, or any `.easy-coding/` file.