easy-coding-harness 0.6.0 → 0.7.0

package/package.json

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

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

@@ -9,6 +9,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 `.claude/skills/`, `.agents/skills/`, `.qoder/skills/`, or any `.easy-coding/`
   file. All context you need is already in the task card.
@@ -20,6 +22,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/codex/agents/ec-implementer.toml

@@ -8,6 +8,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 .agents/skills/, .codex/, or any .easy-coding/ file. All needed context is in
   the card.
@@ -18,6 +20,7 @@ Hard constraints:
 Output (return exactly this):
 - 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/common/bundled-skills/ec-meta/references/local-architecture/README.md

@@ -44,9 +44,13 @@ analysis, workflow operation). The CLI never analyzes the project.
 
 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
+(user abort, no memory flow). INIT → ANALYSIS and completed MEMORY → COMPLETE are restricted
+automatic edges. A validated read-only `doc` / `analysis` / `report` task also auto-completes
+from IMPLEMENT after its full deliverable is shown, without REVIEW, VERIFICATION, MEMORY, or
+task memory. Other stage edges record `task.json.pending_transition` and require explicit user
+confirmation; code tasks may skip REVIEW and enter VERIFICATION directly. VERIFICATION remains
+the code-task 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

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 by requesting the confirmed edge to IMPLEMENT. 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, resolves user decisions during analysis, then fills the final plan and execution plan; code tasks also receive a standalone test strategy, while read-only tasks do not. 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.**
@@ -23,33 +23,43 @@ Communicate with the user in the user's language.
    If dev-spec.md does not exist with the correct template after your second tool call,
    you have already failed. Do not read code, think aloud, or analyze before the skeleton
    is on disk.
-2. **All subsequent analysis** fills sections of this file via edits. You do NOT hold analysis
-   in your head and dump it at the end — you write each section into the file as you go.
-3. **Your chat output to the user IS dev-spec.md, verbatim.** After dev-spec.md is complete,
-   use the Read tool to read it back, then output exactly what you read as your reply — this
+2. **Resolve decisions before filling.** After the exact skeleton is on disk, load the required
+   inputs and inspect source code without editing dev-spec.md. As soon as analysis reveals a
+   decision that affects technical direction, API, scope, delivery form, state flow, encoding,
+   or acceptance, ask the user immediately and stop. Prefer the platform's native user-choice
+   tool when available. Keep dev-spec.md as the untouched skeleton until every decision is
+   resolved; never write an unresolved question or an assumed answer into the final plan.
+3. **Decision questions are the only pre-plan chat exception.** While the decision gate is
+   unresolved, ask only the evidence-backed question needed to continue; do not present a draft
+   report. After all decisions are resolved and dev-spec.md is complete, your chat output to the
+   user IS dev-spec.md verbatim. Use the Read tool to read it back, then output exactly what you
+   read as your reply — this
    is a copy operation, not a re-narration. Do NOT reconstruct it from memory, do NOT
    abbreviate, do NOT invent a different format. No "执行计划" summary tables, no bullet-point
    plans, no freestyle answers. The template IS the format. If your reply does not contain
    every mandatory section header from the template, you have failed.
-4. **Three files must exist** in `.easy-coding/tasks/{task-id}/` when you finish:
-   `dev-spec.md`, `execution.jsonl` (plan record), `test-strategy.md`. Missing any one = failed.
+4. **Required artifacts depend on delivery mode.** Code tasks require `dev-spec.md`,
+   `execution.jsonl` (plan record), and `test-strategy.md`. Read-only `doc` / `analysis` /
+   `report` tasks require only `dev-spec.md` and `execution.jsonl`; they MUST NOT create
+   `test-strategy.md` because they never enter VERIFICATION.
 5. **Stay faithful to the user's delivery form (anti-downgrade).** The delivery form —
    change real code vs. produce a document — is set by the user's original request, NOT by
    you. If the user asked to refactor / fix / add a feature (a CODE task), you MUST plan real
    code changes. You may NOT downgrade it to "produce a report / audit / inventory only" or
    "defer all changes to follow-up sub-tasks." A large change surface is NOT a reason to
-   downgrade: decompose it into batches/units in 实施拆解, and surface "split into batches? /
-   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 stage-boundary prompts under an explicit
-   autonomous user request and carries NO scope or delivery-form decision whatsoever.
+   downgrade: during the pre-fill decision gate, ask "split into batches? / which subset this
+   round?" and wait 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 "confirm_mode already selected Y"
+   to justify narrowing — confirmation mode controls stage-boundary prompts only 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
    this table — those are process outputs, not "changes." The table MAY be empty, but ONLY
    when the user explicitly asked for a no-code delivery form (e.g. a pure documentation
-   request); in that case declare the deliverable in 需求解析 > 输出. If the task type is a
+   request) and `task.json.type` is `doc`, `analysis`, or `report`; in that case declare the
+   deliverable in 需求解析 > 输出. If the task type is a
    code task (重构 / Bug 修复 / 新功能 / 性能优化) yet 改动范围 is empty, you have downgraded
    the task — this is a failed analysis.
 
@@ -82,22 +92,31 @@ You MUST execute these steps in exact order. Do not rearrange, skip, or combine
 1. **Write skeleton** — FIRST TWO tool calls:
    - Read `.easy-coding/templates/dev-spec-skeleton.md` (the template file).
    - Write its exact content to `.easy-coding/tasks/{task-id}/dev-spec.md`.
-   This is a copy operation, not a generation task. Every section header and every `{待填写}`
-   placeholder in the template must appear in the written file unchanged.
-2. **Fill 项目模式 + 任务类型** — edit dev-spec.md in place.
-3. **Fill 需求解析** — edit dev-spec.md: 目标 / 输入 / 输出 / 边界.
-4. **Read source code, fill 现状** — read the actual files, then edit dev-spec.md with
-   evidence. Every claim must cite file:line. No file references = invalid section.
-5. **Fill 冲突摘要 + 待用户决策** — edit dev-spec.md.
-6. **Fill 影响面分析 + 改动范围** — edit dev-spec.md, fill the table with encoding evidence.
-7. **Fill 修改方案 + 实施拆解** — edit dev-spec.md, design approach and decompose units.
-8. **Fill 测试策略 + 风险与注意事项** — edit dev-spec.md.
-9. **Fill conditional sections** — edit dev-spec.md: 背景数据应用 / 核心改动明细 /
+   This is a copy operation, not a generation task. Every section header and every
+   `[[EC_TODO:...]]` marker in the template must appear in the written file unchanged.
+2. **Inspect before filling** — load the required inputs in the order above and read the actual
+   source files. Do not edit dev-spec.md yet. Collect evidence and identify every decision that
+   could change technical direction, API, scope, delivery form, state flow, encoding, or
+   acceptance.
+3. **Resolve the decision gate** — if any decision exists, ask it during ANALYSIS immediately,
+   using the native user-choice tool when available, then stop and wait. After the user answers,
+   repeat the evidence check and ask any newly exposed decision. Do not fill dev-spec.md,
+   execution.jsonl, or (for code tasks) test-strategy.md until the decision set is empty.
+4. **Fill 项目模式 + 任务类型** — edit dev-spec.md in place only after the decision gate clears.
+5. **Fill 需求解析** — edit dev-spec.md: 目标 / 输入 / 输出 / 边界.
+6. **Fill 现状 + 冲突摘要** — write evidence-backed conclusions. Every current-state claim
+   must cite file:line. No file references = invalid section.
+7. **Fill 影响面分析 + 改动范围** — edit dev-spec.md, fill the table with encoding evidence.
+8. **Fill 修改方案 + 实施拆解** — edit dev-spec.md, design approach and decompose units.
+9. **Fill 测试策略 + 风险与注意事项** — edit dev-spec.md.
+10. **Fill conditional sections** — edit dev-spec.md: 背景数据应用 / 核心改动明细 /
    前端实现映射 only if applicable. Remove inapplicable conditional sections entirely.
-10. **Write execution.jsonl** — append the plan record (see section below).
-11. **Write test-strategy.md** — write the testability table (see section below).
-12. **Self-check** — run the gates below. Fix any failure in the files.
-13. **Present to user** — Read dev-spec.md back from disk and output exactly what you read as
+11. **Write execution.jsonl** — append the plan record (see section below).
+12. **Write test-strategy.md for code tasks only** — write the testability table (see section
+    below). For a read-only task, do not create this file; fill the dev-spec `测试策略` section
+    with `不适用：只读报告任务不进入 VERIFICATION`.
+13. **Self-check** — run the gates below. Fix any failure in the files.
+14. **Present to user** — Read dev-spec.md back from disk and output exactly what you read as
     your reply. Do not summarize, abbreviate, reformat, or reconstruct from memory. The
     dev-spec.md content on disk IS your reply.
 
@@ -114,7 +133,7 @@ If the hook injects `[easy-coding:analysis-template-drift:missing:...]`, you hav
 from the template. Re-read the template file, compare it against your dev-spec.md, and fix
 any missing or renamed section headers immediately.
 
-**Mandatory section headers** (all 13 must be present in the skeleton — the hook validates these):
+**Mandatory section headers** (all 12 must be present in the skeleton — the hook validates these):
 
 1. `## 技术方案`
 2. `### 项目模式`
@@ -122,13 +141,12 @@ any missing or renamed section headers immediately.
 4. `### 需求解析`
 5. `### 现状`
 6. `### 冲突摘要`
-7. `### 待用户决策`
-8. `### 影响面分析`
-9. `### 改动范围`
-10. `### 修改方案`
-11. `### 实施拆解`
-12. `### 测试策略`
-13. `### 风险与注意事项`
+7. `### 影响面分析`
+8. `### 改动范围`
+9. `### 修改方案`
+10. `### 实施拆解`
+11. `### 测试策略`
+12. `### 风险与注意事项`
 
 > **Encoding rule**: modified files keep their original encoding; new files declare the
 > project encoding with evidence; conflicting or unknown encoding → mark "需用户确认".
@@ -146,6 +164,7 @@ any missing or renamed section headers immediately.
 - Restating requirements without citing code evidence.
 - Listing "loaded information" without a concrete implementation approach.
 - Including conditional sections that are irrelevant to the current task.
+- Including `[阶段：ANALYSIS]`, a `待用户决策` section, or any unresolved decision in the report.
 
 ## Implementation units → execution.jsonl
 
@@ -153,7 +172,7 @@ Decompose the work into units, then append ONE `plan` record to
 `.easy-coding/tasks/{task-id}/execution.jsonl`:
 
 ```json
-{"type":"plan","strategy":"parallel","units":[{"id":"U1","title":"...","type":"backend","files":["..."],"depends_on":[],"rules_sections":["naming","error-handling"],"abstract_modules":["user-service"]}],"parallel_groups":[{"level":0,"units":["U1","U2"]},{"level":1,"units":["U3"]}]}
+{"type":"plan","strategy":"parallel","units":[{"id":"U1","title":"Implement service","type":"backend","files":["src/service.ts"],"depends_on":[],"rules_sections":["naming","error-handling"],"abstract_modules":["user-service"]},{"id":"U2","title":"Implement adapter","type":"backend","files":["src/adapter.ts"],"depends_on":[],"rules_sections":["naming"],"abstract_modules":["user-service"]},{"id":"U3","title":"Add integration tests","type":"test","files":["test/service.test.ts"],"depends_on":["U1","U2"],"rules_sections":["testing"],"abstract_modules":["user-service"]}],"parallel_groups":[{"level":0,"units":["U1","U2"]},{"level":1,"units":["U3"]}]}
 ```
 
 Strategy selection (drives ec-implementing's sub-agent orchestration shape — every strategy
@@ -168,7 +187,18 @@ Each unit carries `rules_sections` and `abstract_modules` so ec-implementing can
 precise task card without the sub-agent re-reading the whole repo. `depends_on` sets the
 parallel-group levels.
 
-## Test strategy (presented with the plan, saved for VERIFICATION)
+For an explicitly no-code `doc` / `analysis` / `report` task, use a `single` plan whose unit
+has `files:[]`. The state API permits an empty file scope only for those task types. The unit
+must still include `id`, `title`, `type`, `depends_on`, `rules_sections`, and
+`abstract_modules`; its sub-agent returns the full read-only result in `deliverable` and must
+not modify project files. After IMPLEMENT shows that full result, the task auto-completes without
+REVIEW, VERIFICATION, MEMORY, or a memory write. Never use an empty `files` list for
+feature/bugfix/refactor/perf code tasks.
+
+## Test strategy (code tasks only; presented with the plan, saved for VERIFICATION)
+
+Read-only `doc` / `analysis` / `report` tasks skip this entire standalone artifact. Do not
+create `test-strategy.md`; only mark the mandatory dev-spec `测试策略` section as not applicable.
 
 **1. Testability table** — classify every change:
 
@@ -193,33 +223,37 @@ owning unit and the verify command.
 **5. Cannot-verify items** — items that cannot be verified in the current environment,
 with reason (missing infra, data, credentials, or API contract).
 
-Write the confirmed strategy to `.easy-coding/tasks/{task-id}/test-strategy.md` (the
-VERIFICATION baseline).
+For a code task, write the confirmed strategy to
+`.easy-coding/tasks/{task-id}/test-strategy.md` (the VERIFICATION baseline).
 
 ## Self-check gates (ALL must pass — reject your own output if ANY fails)
 
 - [ ] `dev-spec.md` 文件是否已写入 `.easy-coding/tasks/{task-id}/`？
 - [ ] `execution.jsonl` 文件是否已写入？
-- [ ] `test-strategy.md` 文件是否已写入？
-- [ ] dev-spec.md 是否包含全部 13 个必填章节标题（参见上方清单）？
+- [ ] 代码任务是否已写入 `test-strategy.md`？只读任务是否确认该文件不存在？
+- [ ] dev-spec.md 是否包含全部 12 个必填章节标题（参见上方清单）？
 - [ ] 每个"现状"断言是否引用了真实文件/类/行号？
 - [ ] 是否有具体的修改方案，而非仅罗列"已加载的文件"？
 - [ ] 不适用的条件章节是否已完全省略（而非留空）？
 - [ ] 实施拆解的单元、依赖、策略是否与改动范围表一致？
 - [ ] 改动范围表中每行是否填写了文件编码及证据？
-- [ ] 所有 `{待填写}` 占位符是否已替换为实际内容？
+- [ ] 所有 `[[EC_TODO:...]]` 占位标记是否已替换为实际内容？
 - [ ] 回复给用户的内容是否是 dev-spec.md 的完整内容（而非自创的缩略格式）？
 - [ ] 交付形态是否忠于用户原始需求？代码类任务（重构/修复/功能）是否规划了真实代码改动，而非降级为"仅出报告/分析清单/留作后续子任务"？
 - [ ] 「改动范围」是否只含真实项目源码/配置，且不含任何 `.easy-coding/` 下的 harness 产物（dev-spec/execution/test-strategy/记忆/报告）？
 - [ ] 若「改动范围」为空，是否确为用户明确要求的无代码交付形态，而非 AI 自行降级的结果？
-- [ ] 任何"本次不做全部 / 分批落地 / 范围收窄"的决定，是否已列入「待用户决策」交由用户拍板，而非自行拍板并假托既定？
+- [ ] 若 unit.files 为空，task.json.type 是否为 `doc` / `analysis` / `report`，且计划是否为 single 只读交付？
+- [ ] 是否在填充方案前通过分析中的即时问答解决了全部用户决策项，且最终报告不含未决问题或 `[阶段：ANALYSIS]`？
+- [ ] 任何"本次不做全部 / 分批落地 / 范围收窄"的决定，是否已在填充方案前询问并获得用户确认，而非自行拍板并假托既定？
 
 ## Revision handling
 
-> 修订同样受 HARD RULE 5/6 约束：用户的修订诉求若是扩大或细化代码改动，不得借机把任务降级为"出报告"；范围收窄仍须作为 待用户决策 项由用户确认。
+> 修订同样受 HARD RULE 5/6 约束：用户的修订诉求若是扩大或细化代码改动，不得借机把任务降级为"出报告"；范围收窄必须在重写报告前即时询问并获得用户确认。
 
 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.
+pending edge. Re-run the pre-fill decision gate before editing the existing report. If the
+revision exposes an unresolved decision, ask it immediately and wait without writing a partial
+revision. 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,7 +261,8 @@ Re-output the COMPLETE revised dev-spec.md:
 2. Re-output the full plan following the template above (核心必填 + applicable conditional
    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.
+4. For code tasks, update test-strategy.md if test scope changed. For read-only tasks, keep the
+   file absent.
 5. Request ANALYSIS -> IMPLEMENT again and present the standard confirmation/handoff/Other gate.
 
 ## End state

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

@@ -67,7 +67,7 @@ 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 and enter INIT. After INIT completes, it
-   presents the standard confirmation/handoff/Other gate before entering ANALYSIS.
+   automatically enters ANALYSIS without a confirmation/handoff gate.
    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-git/SKILL.md

@@ -17,7 +17,7 @@ Communicate with the user in the user's language.
 |---|---|---|
 | `sessions/` | **never** | personal runtime state, differs per developer |
 | `config.yaml` | yes | shared team config |
-| `tasks/*/task.json` `dev-spec.md` `execution.jsonl` `test-strategy.md` | yes | per-task folders, no merge conflicts; team-readable decision record |
+| `tasks/*/task.json` `dev-spec.md` `execution.jsonl` and code-task `test-strategy.md` | yes | per-task folders, no merge conflicts; team-readable decision record |
 | `SOUL.md` `RULES.md` `ABSTRACT.md` `TEST_STRATEGY.md` `CHANGELOG.md` | yes | shared project knowledge |
 | `memory/` | yes | shared knowledge sinks |
 | `spec/` | yes | spec store |

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

@@ -1,13 +1,14 @@
 ---
 name: ec-implementing
-description: IMPLEMENT-stage skill. Use when ec-workflow enters IMPLEMENT with a confirmed plan. Executes execution.jsonl units under strict file-scope control, enforces RULES compliance and encoding preservation, writes tests per strategy, and dispatches sub-agents for every unit regardless of strategy.
+description: IMPLEMENT-stage skill. Use when ec-workflow enters IMPLEMENT with a confirmed plan. Executes code or explicit no-code execution.jsonl units under strict scope control, enforces RULES compliance and encoding preservation, writes code-task tests per strategy, and dispatches sub-agents for every unit regardless of strategy.
 ---
 
 # ec-implementing — execute the confirmed plan
 
-ec-workflow dispatches you when a confirmed task enters IMPLEMENT. You turn the plan into
-code without re-opening decisions. Inputs: `dev-spec.md` (confirmed), `execution.jsonl`
-(plan record), `.easy-coding/RULES.md`, `.easy-coding/ABSTRACT.md`, `test-strategy.md`.
+ec-workflow dispatches you when a confirmed task enters IMPLEMENT. You execute the confirmed
+delivery without re-opening decisions. Inputs: `task.json`, `dev-spec.md` (confirmed), `execution.jsonl`
+(plan record), `.easy-coding/RULES.md`, `.easy-coding/ABSTRACT.md`, and `test-strategy.md` for
+code tasks only. A read-only task has no test-strategy.md.
 
 Communicate with the user in the user's language.
 
@@ -28,8 +29,13 @@ Communicate with the user in the user's language.
 6. **Self-audit gate.** When the unit is done, audit: are all edits within scope? any
    undeclared dependency change? any leftover TODO/FIXME you introduced? Report failures;
    never skip silently.
-7. **Tests (soft rule).** Write tests for [must-test]/[should-test] items per
+7. **Tests (code tasks only, soft rule).** Write tests for [must-test]/[should-test] items per
    test-strategy.md. Soft means: no project test infra → not forced; infra exists → required.
+   Read-only tasks have no test-strategy.md and write no tests.
+8. **No-code delivery is explicit and read-only.** Only a task whose `task.json.type` is
+   `doc`, `analysis`, or `report` may have `unit.files:[]`. Dispatch it with editable scope
+   `NONE — read-only deliverable`; the sub-agent modifies nothing and returns the full result
+   in `deliverable`. An empty scope on any code task is a gate failure, not permission to roam.
 
 ## Sub-agent dispatch
 
@@ -47,7 +53,7 @@ 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 bypassing the
-ANALYSIS -> IMPLEMENT confirmation gate.
+ANALYSIS -> IMPLEMENT gate selected by the effective confirm mode.
 
 Self-check before writing ANY implementation code:
 - Am I about to write implementation code in the main agent? → STOP. Dispatch a sub-agent.
@@ -70,8 +76,14 @@ goes through a sub-agent — this isolates implementation context from the main
      await the level, then advance.
    Platform spawn rule: {{platform_spawn_instruction}}
 4. After each unit/level returns: check for file conflicts (two units touched the same file),
-   collect `issues` and `needs_attention`. Resolve conflicts before advancing.
-5. After all units/levels, summarize.
+   collect `issues` and `needs_attention`. Resolve conflicts before advancing. For a no-code
+   unit, additionally require `changed_files:[]` and a non-empty string `deliverable`; a missing
+   deliverable or any file modification is a unit failure and must be re-dispatched.
+5. After recording a successful no-code result, output the complete `deliverable` to the user
+   verbatim in the current response before any summary or completion action. Never replace,
+   truncate, or hide it behind the one-line `summary` or leave it only in execution.jsonl.
+6. After all units/levels, summarize. For no-code delivery, the summary is supplemental and
+   must appear after the full deliverable.
 
 ## Task card — the sub-agent contract
 
@@ -88,11 +100,13 @@ structured results. Reply content IS the return value, not a message to a human.
 - Modify only files in "Editable scope".
 - Make no stage-transition decisions.
 ## Task           {unit description extracted from dev-spec}
-## Editable scope {unit.files}
+## Delivery mode  {code | no-code read-only, derived from task.type and unit.files}
+## Editable scope {unit.files | NONE — read-only deliverable}
 ## Coding rules   {RULES.md sections selected by unit.rules_sections}
 ## Architecture   {ABSTRACT.md sections selected by unit.abstract_modules}
 ## Output format
-Return: changed_files[], summary (one line), issues[], needs_attention[].
+Return: changed_files[], summary (one line), deliverable (full no-code result or null),
+issues[], needs_attention[].
 ```
 
 This enforces the three-layer escape guard: task boundary (only its files), stage boundary
@@ -107,9 +121,19 @@ let sub-agents re-dispatch each other.
 
 ## End state
 
-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.
+- **Code task:** after all units are done and self-audited, hand back to ec-workflow. In approve
+  mode it records IMPLEMENT -> REVIEW as the recommended pending edge and presents REVIEW /
+  skip to VERIFICATION / handoff. In guard/auto it automatically enters REVIEW.
+- **No-code read-only task:** after recording the successful result and showing the complete
+  deliverable, request COMPLETE in approve mode or auto-transition in guard/auto. Do not
+  enter REVIEW, VERIFICATION, or MEMORY; do not write short or long memory. The state API only
+  accepts this terminal edge when the latest plan is `single` with `files:[]` and the latest
+  result has `changed_files:[]`, a non-empty `deliverable`, and no issues/needs_attention.
+  A matching `dispatch` record must immediately precede the accepted result among that unit's
+  execution records; an inline report without dispatch cannot complete.
+
+If something invalidates the plan before completion, select IMPLEMENT -> ANALYSIS and follow
+the effective confirm mode instead of improvising.
 
 ## Self-check gates (before handing back)
 
@@ -118,3 +142,7 @@ request IMPLEMENT -> ANALYSIS and wait at the same gate instead of improvising.
 - [ ] Each dispatched unit has a `dispatch` record in execution.jsonl?
 - [ ] Each returned unit has a `result` record?
 - [ ] No files modified outside the change-scope table?
+- [ ] For a no-code unit: changed_files is empty, deliverable is non-empty, and the full
+      deliverable was output verbatim to the user before completion?
+- [ ] For a no-code task: IMPLEMENT -> COMPLETE followed the effective confirm mode, with no
+      REVIEW, VERIFICATION, MEMORY, or memory write?

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

@@ -1,13 +1,15 @@
 ---
 name: ec-memory
-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.
+description: MEMORY-stage skill — archive flow entered after a green VERIFICATION gate according to the effective confirm mode. Writes one schema-v2 short memory, runs the authoritative conditional long-memory gate, performs optional distillation, and automatically completes the task.
 ---
 
 # ec-memory — archive what was learned
 
-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
+ec-workflow dispatches you during MEMORY after approve/guard acceptance or an auto-mode green
+VERIFICATION gate. 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.
+Read-only `doc` / `analysis` / `report` tasks auto-complete from IMPLEMENT and never enter
+MEMORY or write task memory.
 
 Communicate with the user in the user's language. Memory file content follows the project's
 recorded comment/doc language.
@@ -132,11 +134,13 @@ For `distill`, it also rejects completion while any frozen candidate still exist
 frozen retained file is missing. A candidate checkpoint may disappear only because it is
 explicitly listed in `candidate_files`.
 
-## Step 3 — request COMPLETE
+## Step 3 — automatically enter 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.
+Only after `memory_progress.completed:true`, hand control to ec-workflow to call:
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py auto-transition --session-file <P> --stage COMPLETE --agent <agent-id>`.
+MEMORY -> COMPLETE is a mechanical edge: do not create `pending_transition`, present another
+confirmation/handoff gate, or stop before closeout. Use the returned Ready status context and
+emit the final task summary.
 
 ## ABSTRACT backfill / update
 

package/templates/common/skills/ec-no-harness/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: ec-no-harness
+description: Disable Easy Coding Harness orchestration for the current agent session and use native agent behavior. Use only when the user explicitly invokes {{skill_trigger}}ec-no-harness or explicitly asks to restore Easy Coding after this bypass.
+---
+
+# ec-no-harness — current-session Easy Coding bypass
+
+This skill bypasses only Easy Coding Harness for the current session. It does not disable the
+platform's hook system, alter `EC_HOOKS`, or suppress non-Easy-Coding skills and instructions.
+
+Communicate with the user in the user's language.
+
+## Disable for this session
+
+Read `[easy-coding:session-file:P]` from the injected context, then call:
+
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py disable-harness --session-file <P> --agent <agent-id>`
+
+After the command succeeds:
+- Do not enter or resume ec-workflow in this session.
+- Do not emit an Easy Coding status line or apply Easy Coding stages, confirmation gates,
+  task artifacts, verification orchestration, or memory workflow.
+- Process the user's request with the platform's native agent behavior.
+- Continue honoring project/user/global instructions, explicitly requested non-Easy-Coding
+  skills, and every other hook.
+- Do not clear `current_task`, delete a pending transition, or modify task state. The task is
+  suspended intact and can resume after restoring Easy Coding or in a new session.
+
+If the invocation contains no request beyond enabling the bypass, briefly confirm that native
+mode is active for the current session.
+
+## Restore Easy Coding in the same session
+
+Only when the user explicitly asks to restore/resume Easy Coding, call:
+
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py enable-harness --session-file <P> --agent <agent-id>`
+
+Use the returned `status_context` as authoritative. Do not advance the task automatically;
+hand control back to ec-workflow routing semantics.

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

@@ -5,9 +5,10 @@ description: REVIEW-stage skill. Use when ec-workflow enters REVIEW. Reviews cha
 
 # ec-reviewing — graded, evidence-backed review
 
-ec-workflow dispatches you when IMPLEMENT finishes. You judge the change set and return a
-verdict that drives the next transition. Inputs: the changed files (from execution.jsonl
-`result` records), `dev-spec.md`, `.easy-coding/RULES.md`, `test-strategy.md`.
+ec-workflow dispatches you when code IMPLEMENT finishes. Read-only `doc` / `analysis` / `report`
+tasks auto-complete from IMPLEMENT and never enter REVIEW. You judge the code change set and
+return a verdict that drives the next transition. Inputs: the changed files (from
+execution.jsonl `result` records), `dev-spec.md`, `.easy-coding/RULES.md`, `test-strategy.md`.
 
 Communicate with the user in the user's language.
 
@@ -88,6 +89,6 @@ Platform spawn rule: {{platform_spawn_instruction}}
 Append `review` records to execution.jsonl, one per dimension:
 `{"type":"review","dimension":"correctness","findings":[{"file":"...","line":42,"issue":"...","severity":"warn"}]}`.
 Then state the verdict and hand back to ec-workflow.
-For `accept` or `replan`, ec-workflow records the corresponding pending transition and presents
-the standard confirmation/handoff/Other gate. A `fix` round stays inside REVIEW and therefore
+For `accept` or `replan`, ec-workflow follows the effective confirm mode for the corresponding
+transition. A `fix` round stays inside REVIEW and therefore
 does not create a status transition unless the outcome changes.

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

@@ -1,6 +1,6 @@
 ---
 name: ec-task-management
-description: Task panel for Easy Coding tasks. Use when the user runs {{skill_trigger}}ec-task-management, asks to see tasks, create a task, continue a task, or take over a task handed off by another agent.
+description: Task and session panel for Easy Coding. Use when the user runs {{skill_trigger}}ec-task-management, asks to see/create/continue/take over tasks, or asks to view or change the current session confirm mode.
 ---
 
 # ec-task-management — the task panel
@@ -52,7 +52,7 @@ unless ec-workflow is explicitly invoked or the agent environment routes into it
 ### Create a task
 
 Create through the state API, never by hand-editing `task.json` or session files:
-`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py create-task --session-file <P> --task-id <MM-DD-short-name> --type <feature|bugfix|refactor|perf> --title "<one-line summary>" --agent <agent-id> --no-set-current`.
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py create-task --session-file <P> --task-id <MM-DD-short-name> --type <feature|bugfix|refactor|perf|doc|analysis|report|workflow> --title "<one-line summary>" --agent <agent-id> --no-set-current`.
 
 If the user explicitly wants to start the task now, omit `--no-set-current`; otherwise leave
 the current workflow pointer untouched and tell them to run `{{skill_trigger}}ec-workflow`
@@ -62,6 +62,28 @@ The command returns `status_line` and `status_context`. If the command sets or c
 `current_task`, use the returned context as the authoritative status source for the rest of
 the current turn instead of older hook-injected status text.
 
+### View or change this session's confirm mode
+
+Call `snapshot --session-file <P>` and show:
+- `project_confirm_mode`
+- `session_confirm_mode` (`project default` when null)
+- `effective_confirm_mode`
+
+When the user asks to change the current session, use native choice UI when available and offer
+exactly `approve`, `guard` (recommended default), and `auto`. The native free-form Other input
+may receive `restore project default`; do not invent a fourth button when the UI is limited to
+three choices.
+
+Set an override through the state API, never by editing the session JSON:
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-confirm-mode --session-file <P> --mode <approve|guard|auto> --agent <agent-id>`.
+
+Restore project configuration through:
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-confirm-mode --session-file <P> --agent <agent-id>`.
+
+Use the returned snapshot as authoritative and report the effective mode. Preserve any existing
+`pending_transition`; when it becomes automatic, ec-workflow consumes its original target via
+`auto-transition` instead of losing the completed stage outcome.
+
 ## Boundaries
 
 - Do not close or cancel tasks — that is ec-task-close.