easy-coding-harness 0.6.0 → 0.6.1

package/CHANGELOG.md

@@ -6,6 +6,22 @@
 - `y`：常规功能升级
 - `z`：日常 bug 修复
 
+## 0.6.1
+
+- 状态迁移按是否需要用户决策分层：`INIT → ANALYSIS` 在 INIT 工作完成后自动流转，`MEMORY → COMPLETE` 在记忆处理检查点完成后自动流转；这两条机械边不再创建 `pending_transition`，也不再展示确认或交接选项。
+- 新增受限的 `auto-transition` 状态 API，只允许上述两条自动边；其他前进、修复和重规划边继续通过 `request-transition` / `confirm-transition` 显式确认，Hook 仍保持只读。
+- IMPLEMENT 完成后允许用户选择进入 REVIEW，或明确跳过 REVIEW 直接进入 VERIFICATION；交接和 free-form Other 仍保留，跳过 REVIEW 不能绕过 VERIFICATION 硬门控。
+- ANALYSIS 改为先原样落盘无阶段标签的 dev-spec 骨架，再在分析过程中即时询问并解决技术路线、接口、范围等决策问题，最后才填充完整方案；最终报告不再包含“待用户决策”章节。
+- `ANALYSIS → IMPLEMENT` 在申请和确认迁移时都会校验完整 dev-spec 和最新有效 execution plan；代码任务还必须提供非空 test strategy，只读任务则禁止生成 `test-strategy.md`。必填章节正文、实施单元任务卡字段和并行分组均需完整，原始骨架、空章节、无界单元或缺失产物不能进入实施。
+- dev-spec 骨架使用专用 `[[EC_TODO:...]]` 占位标记，既能可靠拦截未填字段，也不会把方案中合法的 `{title}`、`{type}` 等模板文本误判为残留占位符。
+- execution plan 门禁校验依赖图无环及并行层级顺序；`doc` / `analysis` / `report` 显式无代码任务允许受限空文件范围并通过 `deliverable` 返回只读结果，代码任务仍禁止无界实施。
+- 无代码 IMPLEMENT 单元必须返回非空 `deliverable` 且不得修改文件；主 Agent 在展示摘要或迁移选项前必须向用户原样输出完整 deliverable，避免结果只留在执行日志中。
+- 无代码任务展示完整 deliverable 后直接通过受限 `IMPLEMENT → COMPLETE` 自动边结束；状态 API 会校验 single 空文件计划、匹配的 dispatch/result、零文件改动、非空 deliverable 和无遗留问题，不生成 `test-strategy.md`，不进入 REVIEW、VERIFICATION、MEMORY，也不写任务记忆。
+- 介绍页展示版本与 `package.json` 保持一致，并由版本元数据测试防止后续发布再次漂移。
+- 升级遗留的自动 `pending_transition` 在状态上下文中标记为 `auto-transition-ready`，不再错误注入用户确认提示。
+- `single` / `sequential` / `parallel` 三种执行策略统一派发子代理，仅编排形态不同；技术方案骨架不再生成“主 Agent 直接执行”的冲突指令。
+- 工作流 skills、主约束、README、设计/介绍/使用文档和状态 API 测试统一对齐新的自动边与可选 REVIEW 语义。
+
 ## 0.6.0
 
 - 状态机移除无实际工作内容的 `WAITING_CONFIRM`；阶段完成后通过 `task.json.pending_transition` 记录待确认边，状态仍停留在当前阶段，直到用户明确确认。

package/README.md

@@ -69,16 +69,20 @@ easy-coding init --submodules packages/a,packages/b
 ## 工作流
 
 ```text
-INIT -> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY -> COMPLETE
-          ^            ^          |             |
-          +-- replan ---+          +--- fix -----+
-                       ^                         |
-                       +------- repair ----------+
-every edge --[user confirmation by default]--> target stage
+INIT --[auto]--> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY --[auto]--> COMPLETE
+                                    \----------------> VERIFICATION
+                                    \--[read-only auto]------------------------------> COMPLETE
+                 ^            ^          |             |
+                 +-- replan ---+          +--- fix -----+
+                              ^                         |
+                              +------- repair ----------+
+user-decision edge --[confirm / handoff / Other]--> target stage
 any stage --[user abort via ec-task-close]--> CLOSED
 ```
 
-- 每个阶段完成后先记录 `pending_transition`，默认必须由用户确认才进入目标阶段；优先通过智能体原生选项功能选择确认、交接给其他智能体或使用 free-form Other，纯文本编号仅作回退。
+- `INIT → ANALYSIS` 与完成记忆处理后的 `MEMORY → COMPLETE` 自动流转，不生成 `pending_transition`，也不展示确认或交接。
+- 其余用户关联边通过 `pending_transition` 等待明确确认；代码 IMPLEMENT 完成后可选择进入 REVIEW、跳过 REVIEW 直接进入 VERIFICATION，或交接给其他智能体。
+- 显式 `doc` / `analysis` / `report` 只读任务不生成 `test-strategy.md`；IMPLEMENT 留下匹配的 dispatch/result 并展示完整报告后自动进入 COMPLETE，不执行 REVIEW、VERIFICATION 或 MEMORY，也不写任务记忆。
 - `VERIFICATION` 是验证硬门控，未实际运行的 lint、typecheck、test 不算通过。
 - `MEMORY` 先写入本次任务短期记忆，再执行长期记忆阈值门禁；未超过阈值时长期沉淀为 no-op。
 
@@ -115,7 +119,7 @@ any stage --[user abort via ec-task-close]--> CLOSED
 | `ec-workflow` | 统一入口，负责任务创建、恢复、阶段流转和 stage skill 调度 |
 | `ec-brainstorming` | 实现前的设计探索和方案发散 |
 | `ec-analysis` | 生成 dev-spec、执行计划和测试策略 |
-| `ec-implementing` | 按确认后的计划执行代码实现 |
+| `ec-implementing` | 按确认后的计划执行代码实现或显式无代码只读交付 |
 | `ec-reviewing` | 多维度代码审查，输出 accept / fix / replan / blocked 结论 |
 | `ec-verification` | 执行 lint、typecheck、test 等验证硬门控，并处理验收修复循环 |
 | `ec-memory` | 写短期记忆，并在超过阈值时沉淀长期记忆 |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "0.6.0",
+  "version": "0.6.1",
   "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,24 +23,33 @@ 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
+   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 "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.
@@ -49,7 +58,8 @@ Communicate with the user in the user's language.
    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
 
@@ -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. It records
+  IMPLEMENT -> REVIEW as the recommended pending edge, then presents: (1) enter REVIEW,
+  (2) skip REVIEW and enter VERIFICATION, (3) hand off, plus native free-form Other.
+- **No-code read-only task:** after recording the successful result and showing the complete
+  deliverable, call `auto-transition --stage COMPLETE` through ec-workflow. Do not request or
+  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, request IMPLEMENT -> ANALYSIS and wait at
+the standard gate 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 automatic completion?
+- [ ] For a no-code task: IMPLEMENT -> COMPLETE was automatic, with no REVIEW, VERIFICATION,
+      MEMORY, or memory write?

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

@@ -1,6 +1,6 @@
 ---
 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 — part of the archive flow, triggered only after user acceptance and a confirmed stage edge. 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
@@ -8,6 +8,8 @@ description: MEMORY-stage skill — part of the archive flow, triggered only aft
 ec-workflow dispatches you during MEMORY, which runs only after the user accepts the task and
 confirms entry. Inputs: the task's `dev-spec.md`, `execution.jsonl` (the `result` and
 `verify` records are precise source material), the changed-files list, existing memory files.
+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-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.
 

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

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

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

@@ -1,12 +1,13 @@
 ---
 name: ec-verification
-description: VERIFICATION-stage skill — the hard gate between REVIEW and archive. Use when ec-workflow enters VERIFICATION. Runs lint/typecheck/test in parallel, verifies coverage against test-strategy, gates on fresh evidence, then drives the user-acceptance and repair loop. Archive never happens without explicit user acceptance.
+description: VERIFICATION-stage skill — the hard gate between implementation/review and archive. Use when ec-workflow enters VERIFICATION. Runs lint/typecheck/test in parallel, verifies coverage against test-strategy, gates on fresh evidence, then drives the user-acceptance and repair loop. Archive never happens without explicit user acceptance.
 ---
 
 # ec-verification — the hard gate
 
-ec-workflow dispatches you when REVIEW returns `accept`. You are the last gate before
-archive. Nothing passes on assumption.
+ec-workflow dispatches you when REVIEW returns `accept` or the user explicitly skips REVIEW
+after code IMPLEMENT. Read-only tasks auto-complete from IMPLEMENT and never enter this stage.
+You are the last gate before code-task archive. Nothing passes on assumption.
 
 Communicate with the user in the user's language.
 
@@ -65,14 +66,16 @@ test manually. Their response routes:
 
 - **"accepted"** → 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 → request VERIFICATION -> IMPLEMENT and wait for the user to confirm the return;
+    after repair, the IMPLEMENT completion choice decides whether REVIEW runs again or
+    VERIFICATION resumes directly.
   - out of scope → propose a new task (`spawned_from` = current task id); the current task
     may archive now (if already satisfactory) or stay suspended.
 - **"cancel"** → ec-task-close.
 
 Repair sizing: a trivial tweak is fixed and re-verified inside VERIFICATION; a logic/structure
-change formally returns to IMPLEMENT and re-walks REVIEW → VERIFICATION.
+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)
 
@@ -84,4 +87,5 @@ Acceptance does not mutate the stage directly. Hand control to ec-workflow to ca
 
 Only after confirmation may ec-workflow consume the pending edge and dispatch ec-memory.
 ec-memory owns both short-memory creation and the conditional long-memory gate inside the
-single MEMORY stage. It later requests MEMORY -> COMPLETE and waits for a separate confirmation.
+single MEMORY stage. After memory processing completes, MEMORY -> COMPLETE advances
+automatically without another confirmation or handoff gate.