easy-coding-harness 0.6.0 → 0.7.0

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 evidence gate between implementation/review and archive. Runs lint/typecheck/test in parallel, verifies coverage against test-strategy, then follows the effective confirm mode for archive or repair.
 ---
 
 # 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.
 
@@ -18,10 +19,10 @@ NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
 - A previous round's result does not count.
 - "should pass" / "looks correct" is not evidence.
 
-NO AUTO-ARCHIVE WITHOUT USER ACCEPTANCE
-- Verification passing does not complete the task.
-- The memory flow is part of archive; it runs only after the user accepts.
-- An unaccepted task's memory is dirty data.
+NO ARCHIVE WITHOUT A GREEN GATE
+- Verification passing evidence is mandatory in every confirm mode.
+- approve/guard require user acceptance before MEMORY; auto advances after the green gate.
+- Confirmation mode never turns failed or missing evidence into acceptance.
 ```
 
 ## 1. Run the gate (parallel, always sub-agents)
@@ -52,10 +53,10 @@ Append one `verify` record per check:
 
 ## 3. Gate decision
 
-- 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, request
-  VERIFICATION -> IMPLEMENT, and wait at the standard confirmation/handoff/Other gate.
+- All three pass AND coverage satisfied → present the verification result; approve/guard wait
+  for user acceptance, while auto hands the green result to ec-workflow for automatic MEMORY.
+- Any failure → append the failing `verify` record, summarize failures, select
+  VERIFICATION -> IMPLEMENT, and follow the effective confirm mode.
 
 ## 4. User acceptance and repair loop
 
@@ -63,25 +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"** → request VERIFICATION -> MEMORY and present the standard boundary gate.
+- **"accepted"** (approve/guard) → request VERIFICATION -> MEMORY and present the standard boundary gate.
 - **"problem here"** → scope judgment against the dev-spec:
-  - in scope → request VERIFICATION -> IMPLEMENT, then re-REVIEW → re-VERIFICATION after
-    the user confirms each stage edge.
+  - in scope → select VERIFICATION -> IMPLEMENT and follow the effective confirm mode; after
+    repair, approve presents the IMPLEMENT choice while guard/auto default to REVIEW.
   - 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.
+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)
+## 5. Archive entry
 
-Acceptance does not mutate the stage directly. Hand control to ec-workflow to call
-`request-transition --stage MEMORY`, then present:
+In approve/guard, 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.
+In auto, hand the green gate directly to ec-workflow for `auto-transition --stage 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.
+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

@@ -14,6 +14,10 @@ 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.
@@ -59,36 +63,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 -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY -> COMPLETE
-          ^            ^          |             |
-          +-- replan ---+          +--- fix -----+
-                       ^                         |
-                       +------- repair ----------+
-every edge --[explicit user confirmation by default]--> target stage
+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 / 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; 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 |
+| 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 | code defaults to REVIEW when automatic; approve may choose VERIFICATION |
+| 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
 
@@ -101,35 +112,54 @@ 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
-  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
+- **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 `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.
+  - `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. No mode bypasses dev-spec,
+  execution, review, verification, or memory checkpoints.
+- **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 first (hard requirement).** When the effective mode requires confirmation,
+  call `request-transition`. After it 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 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
+- **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.
@@ -137,18 +167,28 @@ routing matches, and switching happens again.
   (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).
-- **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):
+- **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/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.
@@ -164,28 +204,30 @@ routing matches, and switching happens again.
   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 requests
-  VERIFICATION -> IMPLEMENT and waits at the standard confirmation gate before re-walking
-  REVIEW -> VERIFICATION.
+  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.
 - **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.
-  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`,
+- **Archive only after the configured acceptance gate.** VERIFICATION passing does not complete
+  the task. A green gate requests VERIFICATION -> MEMORY in approve/guard, 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. 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).
+  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:handoff-from:Z]`,
+`[easy-coding:session-file:P]`, `[easy-coding:confirm-mode:M]`,
+`[easy-coding:handoff-from:Z]`,
 `[easy-coding:init-required]`.
 
 Resuming an active task (whether from session restart, claim, handoff, or task switch):
@@ -194,14 +236,20 @@ 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. 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.
+4. If `pending_transition` exists, do not rerun the completed stage action. Compare the stored
+   edge with `effective_confirm_mode`. If the edge is now automatic, call `auto-transition` for
+   its stored target; otherwise re-present the confirmation/handoff/Other choices. 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 pending stage edge includes the standard handoff option. On that
+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>"`.
 

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

@@ -29,27 +29,34 @@ Trigger Easy Coding skills with your platform prefix — Codex: `$ec-*`, Qoder:
 - `ec-analysis` `ec-implementing` `ec-reviewing` `ec-verification` — workflow stages
 - `ec-memory` — short/long memory archive
 - `ec-task-management` — list/create tasks · `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
 
 First run `ec-init`; daily work goes through `ec-workflow`.
 
 ## Workflow discipline
 
-- 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.
+- Effective confirm mode is session override > project `behavior.confirm_mode` > `guard`.
+  `approve` confirms every legal edge except INIT -> ANALYSIS and MEMORY -> COMPLETE; `guard`
+  confirms only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY; `auto` confirms none.
+  Automatic code flow chooses IMPLEMENT -> REVIEW. Confirmation mode never changes scope,
+  delivery form, evidence gates, or the legal transition graph.
+- 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.
+- When `[easy-coding:no-harness]` is injected, do not emit an Easy Coding status line and ignore
+  only Easy Coding workflow/stage orchestration for this session. Continue honoring every
+  non-Easy-Coding skill, hook, and instruction. Do not clear or mutate the suspended task.
 - 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.
-- 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.
+  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. Entry follows the
+  effective confirmation mode; 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.,

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

@@ -27,27 +27,34 @@ platform prefixes such as `/` or `$`. If no status line is injected, do not inve
 - `/ec-analysis` `/ec-implementing` `/ec-reviewing` `/ec-verification` — workflow stages
 - `/ec-memory` — short/long memory archive
 - `/ec-task-management` — list/create tasks · `/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
 
 First run `/ec-init`; daily work goes through `/ec-workflow`.
 
 ## Workflow discipline
 
-- 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.
+- Effective confirm mode is session override > project `behavior.confirm_mode` > `guard`.
+  `approve` confirms every legal edge except INIT -> ANALYSIS and MEMORY -> COMPLETE; `guard`
+  confirms only ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY; `auto` confirms none.
+  Automatic code flow chooses IMPLEMENT -> REVIEW. Confirmation mode never changes scope,
+  delivery form, evidence gates, or the legal transition graph.
+- 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.
+- When `[easy-coding:no-harness]` is injected, do not emit an Easy Coding status line and ignore
+  only Easy Coding workflow/stage orchestration for this session. Continue honoring every
+  non-Easy-Coding skill, hook, and instruction. Do not clear or mutate the suspended task.
 - 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.
-- 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.
+  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. Entry follows the
+  effective confirmation mode; 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.,

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/templates/dev-spec-skeleton.md

@@ -1,80 +1,75 @@
-[阶段：ANALYSIS]
-
-## 技术方案：{任务标题}
+## 技术方案：[[EC_TODO:任务标题]]
 
 ### 项目模式
-{初创项目/迭代项目}
+[[EC_TODO:初创项目/迭代项目]]
 
 ### 任务类型
-{新功能 / Bug 修复 / 重构 / 性能优化 / 前端设计实现}
+[[EC_TODO:新功能 / Bug 修复 / 重构 / 性能优化 / 前端设计实现]]
 
 ### 需求解析
-- **目标**：{待填写 — 真正要解决的问题}
-- **输入**：{待填写 — 用户输入 / 系统输入 / 触发条件}
-- **输出**：{待填写 — 先声明交付形态（改代码 / 出文档），再写最终交付结果。交付形态须忠于用户原始需求，不得擅自降级}
-- **边界**：{待填写 — 明确不做什么}
+- **目标**：[[EC_TODO:真正要解决的问题]]
+- **输入**：[[EC_TODO:用户输入 / 系统输入 / 触发条件]]
+- **输出**：[[EC_TODO:先声明交付形态（改代码 / 出文档），再写最终交付结果。交付形态须忠于用户原始需求，不得擅自降级]]
+- **边界**：[[EC_TODO:明确不做什么]]
 
 ### 现状
-- **相关代码 / 页面 / 接口 / 模块**：{待填写 — 基于实际文件与代码的现状说明}
-- **当前实现方式**：{待填写 — 现在是如何工作的}
-- **现有问题 / 缺口**：{待填写 — 为什么需要改}
-- **证据**：{待填写 — 引用的关键文件、类、页面、接口，含 file:line}
+- **相关代码 / 页面 / 接口 / 模块**：[[EC_TODO:基于实际文件与代码的现状说明]]
+- **当前实现方式**：[[EC_TODO:现在是如何工作的]]
+- **现有问题 / 缺口**：[[EC_TODO:为什么需要改]]
+- **证据**：[[EC_TODO:引用的关键文件、类、页面、接口，含 file:line]]
 
 ### 冲突摘要
-- 需求 vs RULES：{待填写 或 "无冲突"}
-- 需求 vs ABSTRACT：{待填写 或 "无冲突"}
-- 需求 vs 现有代码：{待填写 或 "无冲突"}
-- Dev-Spec vs 现有代码：{待填写 或 "无冲突"}
-
-### 待用户决策
-- {待填写 — 影响技术路线、接口、改动范围的问题逐条列出；任何"本次不做全部 / 分批落地 / 范围或交付形态收窄"必须列入此处交由用户拍板，不得自行决定并假托既定；若无则写"无"}
+- 需求 vs RULES：[[EC_TODO:填写结果或“无冲突”]]
+- 需求 vs ABSTRACT：[[EC_TODO:填写结果或“无冲突”]]
+- 需求 vs 现有代码：[[EC_TODO:填写结果或“无冲突”]]
+- Dev-Spec vs 现有代码：[[EC_TODO:填写结果或“无冲突”]]
 
 ### 影响面分析
-- **涉及模块**：{待填写}
-- **核心类 / 页面 / 接口**：{待填写}
-- **数据库变更**：{有/无}
-- **接口变更**：{有/无}
-- **关联历史任务**：{待填写 — 相关短期记忆序号；无则"无"}
+- **涉及模块**：[[EC_TODO:涉及模块]]
+- **核心类 / 页面 / 接口**：[[EC_TODO:核心类 / 页面 / 接口]]
+- **数据库变更**：[[EC_TODO:有/无]]
+- **接口变更**：[[EC_TODO:有/无]]
+- **关联历史任务**：[[EC_TODO:相关短期记忆序号；无则“无”]]
 
 ### 改动范围
 > 只列真实项目源码/配置文件的改动。禁止把 `.easy-coding/` 下的 harness 产物（dev-spec / execution.jsonl / test-strategy / 记忆 / 报告等）当作改动对象。本表为空仅允许用于"用户明确要求的无代码交付形态"；代码类任务（重构/修复/功能）若此表为空，即为自我降级。
 
 | 改动文件 | 改动类型 | 文件编码 | 改动核心内容 |
 |----------|---------|---------|-------------|
-| `{文件路径}` | 新增 | 项目编码 {X}，依据：{xxx} | {核心改动} |
-| `{文件路径}` | 修改 | 保持原编码 {X} | {核心改动} |
-| `{文件路径}` | 删除 | — | {删除原因} |
+| `[[EC_TODO:文件路径]]` | 新增 | 项目编码 [[EC_TODO:编码]]，依据：[[EC_TODO:编码依据]] | [[EC_TODO:核心改动]] |
+| `[[EC_TODO:文件路径]]` | 修改 | 保持原编码 [[EC_TODO:编码]] | [[EC_TODO:核心改动]] |
+| `[[EC_TODO:文件路径]]` | 删除 | — | [[EC_TODO:删除原因]] |
 
 ### 修改方案
-- **总体改法**：{待填写 — 一句话说清改哪里、怎么改}
-- **后端改动**：{待填写；不涉及则写"不涉及"}
-- **前端改动**：{待填写；不涉及则写"不涉及"}
-- **兼容处理**：{待填写 — 旧逻辑如何迁移、保留或替换}
-- **风险点**：{待填写 — 最容易出问题的位置}
+- **总体改法**：[[EC_TODO:一句话说清改哪里、怎么改]]
+- **后端改动**：[[EC_TODO:填写改动；不涉及则写“不涉及”]]
+- **前端改动**：[[EC_TODO:填写改动；不涉及则写“不涉及”]]
+- **兼容处理**：[[EC_TODO:旧逻辑如何迁移、保留或替换]]
+- **风险点**：[[EC_TODO:最容易出问题的位置]]
 
 ### 实施拆解
 
 | 单元 | 说明 | 类型 | 涉及文件 | 依赖 |
 |------|------|------|---------|------|
-| U1 | {title} | {backend/frontend/test/...} | {files} | — |
-| U2 | {title} | {type} | {files} | — |
-| U3 | {title} | {type} | {files} | U1, U2 |
+| U1 | [[EC_TODO:单元标题]] | [[EC_TODO:backend/frontend/test/...]] | [[EC_TODO:涉及文件]] | — |
+| U2 | [[EC_TODO:单元标题]] | [[EC_TODO:单元类型]] | [[EC_TODO:涉及文件]] | — |
+| U3 | [[EC_TODO:单元标题]] | [[EC_TODO:单元类型]] | [[EC_TODO:涉及文件]] | U1, U2 |
 
-**执行策略**：{parallel / sequential / single}
-- 第一批（并行）：U1 {title} ｜ U2 {title}
-- 第二批（等待第一批）：U3 {title}
-（若 single：单一实施单元，主 agent 直接执行）
+**执行策略**：[[EC_TODO:parallel / sequential / single]]
+- 第一批（并行）：U1 [[EC_TODO:单元标题]] ｜ U2 [[EC_TODO:单元标题]]
+- 第二批（等待第一批）：U3 [[EC_TODO:单元标题]]
+（若 single：单一实施单元，派发 1 个子代理执行）
 
 ### 测试策略
 
 | 测试点 | 级别 | 归属单元 | 方式 | 验证命令 |
 |--------|------|---------|------|---------|
-| {描述} | 必测 | U1 | 单测 | `npm test -- --filter=xxx` |
-| {描述} | 应测 | U2 | 快照 | `npm test -- --snapshot` |
+| [[EC_TODO:测试点描述]] | 必测 | U1 | 单测 | `npm test -- --filter=xxx` |
+| [[EC_TODO:测试点描述]] | 应测 | U2 | 快照 | `npm test -- --snapshot` |
 
-- **人工验收**：{待填写 — 用户需要检查的关键行为}
-- **无法验证项**：{待填写 — 无 / 说明缺失环境、数据或权限}
+- **人工验收**：[[EC_TODO:用户需要检查的关键行为]]
+- **无法验证项**：[[EC_TODO:无 / 说明缺失环境、数据或权限]]
 
 ### 风险与注意事项
-- {风险 1}
-- {风险 2}
+- [[EC_TODO:风险 1]]
+- [[EC_TODO:风险 2]]