easy-coding-harness 0.5.3 → 0.6.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "0.5.3",
+  "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-init/SKILL.md

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

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

@@ -42,10 +42,16 @@ analysis, workflow operation). The CLI never analyzes the project.
 
 ## Workflow state machine
 
-8 stages + 2 terminals, owned by ec-workflow:
-`INIT → ANALYSIS → WAITING_CONFIRM → IMPLEMENT → REVIEW → VERIFICATION → MEMORY_SHORT →
-MEMORY_LONG → COMPLETE`, plus `CLOSED` (user abort, no memory flow). WAITING_CONFIRM and
-VERIFICATION are hard gates. The active task pointer lives in `sessions/{ppid}.json`;
+6 work stages + 2 terminals, owned by ec-workflow:
+`INIT → ANALYSIS → IMPLEMENT → REVIEW → VERIFICATION → MEMORY → COMPLETE`, plus `CLOSED`
+(user abort, no memory flow). 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
 session and task state as breadcrumbs so every reply can render the status line.
@@ -57,7 +63,8 @@ stage in `task.json`; no data is lost. Each task folder is self-contained.
 
 ## Task persistence
 
-Each task is a folder. `task.json` is metadata; `dev-spec.md` is the human-readable plan;
+Each task is a folder. `task.json` is metadata, including the current stage and any
+`pending_transition`; `dev-spec.md` is the human-readable plan;
 `execution.jsonl` is an append-only plan-and-log (one `plan` record, then `dispatch`/`result`
 /`review`/`verify`/`handoff` records). Because plan and log live on disk, not in an agent's
 context window, a task survives session end and agent switches with zero information loss.

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

@@ -1,6 +1,6 @@
 ---
 name: ec-analysis
-description: ANALYSIS-stage skill. Use when ec-workflow enters ANALYSIS. Creates the dev-spec skeleton FIRST (template-first), then fills incrementally — producing the narrative plan, execution plan (execution.jsonl), and test strategy. Ends in WAITING_CONFIRM. Grounds every conclusion in real code, never restates the requirement.
+description: ANALYSIS-stage skill. Use when ec-workflow enters ANALYSIS. Creates the dev-spec skeleton FIRST, 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
+   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 the WAITING_CONFIRM confirmation step and
-   carries NO scope or delivery-form decision whatsoever.
+   to justify narrowing — `auto_mode` only waives stage-boundary prompts under an explicit
+   autonomous user request and carries NO scope or delivery-form decision whatsoever.
 6. **改动范围 lists ONLY real project code.** The 改动范围 table carries only changes to real
    project source/config files. Any harness artifact under `.easy-coding/` (dev-spec.md,
    execution.jsonl, test-strategy.md, memory files, generated reports, etc.) is FORBIDDEN in
    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,32 +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 request at WAITING_CONFIRM, do NOT reply with only a change summary.
+On user revision or Other feedback while ANALYSIS has a pending transition, first cancel the
+pending edge. 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
@@ -226,12 +261,13 @@ 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.
-5. Re-enter WAITING_CONFIRM and wait for explicit user confirmation.
+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
 
 Read dev-spec.md back from disk and output the COMPLETE content as your reply to the user —
-not a summary, not a different format, not a table you invented. Then set stage to
-WAITING_CONFIRM and hand control back to ec-workflow. Never start implementing from this
-skill.
+not a summary, not a different format, not a table you invented. Then ask ec-workflow to
+record `pending_transition: ANALYSIS -> IMPLEMENT`, present the standard boundary choices,
+and stop. Never start implementing from this skill.

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

@@ -66,7 +66,8 @@ After saving the design doc, ask the user: "Design confirmed. Start a task based
 design now?" Offer two options:
 
 1. **Start task now** — invoke `{{skill_trigger}}ec-workflow` with the design topic as the
-   task prompt. ec-workflow will create the task (step 4) and enter INIT → ANALYSIS.
+   task prompt. ec-workflow will create the task and enter INIT. After INIT completes, it
+   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
 
@@ -46,8 +52,8 @@ EVERY STRATEGY = MANDATORY SUB-AGENT DISPATCH. NO EXCEPTIONS.
 
 You MUST dispatch sub-agents using {{sub_agent_dispatch}} for every unit, whatever the
 strategy. You are FORBIDDEN from implementing any unit yourself in the main agent. Doing the
-work inline instead of dispatching is a protocol violation equivalent to skipping
-WAITING_CONFIRM.
+work inline instead of dispatching is a protocol violation equivalent to bypassing the
+ANALYSIS -> IMPLEMENT confirmation gate.
 
 Self-check before writing ANY implementation code:
 - Am I about to write implementation code in the main agent? → STOP. Dispatch a sub-agent.
@@ -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,8 +121,19 @@ let sub-agents re-dispatch each other.
 
 ## End state
 
-All units done and self-audited → hand back to ec-workflow to advance to REVIEW. If you
-hit something that invalidates the plan, return to ANALYSIS instead of improvising.
+- **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)
 
@@ -117,3 +142,7 @@ hit something that invalidates the plan, return to ANALYSIS instead of improvisi
 - [ ] 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,18 +1,20 @@
 ---
 name: ec-memory
-description: MEMORY_SHORT and MEMORY_LONG stage skill — part of the archive flow, triggered only after user acceptance. Use when ec-workflow enters the memory stages. Writes schema-v2 short memory with a sliding window, distills long memory into BUSINESS/TECHNICAL with conflict resolution, and backfills ABSTRACT on architecture changes.
+description: MEMORY-stage skill — part of the archive flow, triggered only after user acceptance and a confirmed stage edge. Writes one schema-v2 short memory, 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_SHORT and MEMORY_LONG, which run only after the
-user accepts the task. Inputs: the task's `dev-spec.md`, `execution.jsonl` (the `result` and
+ec-workflow dispatches you during MEMORY, which runs only after the user accepts the task and
+confirms entry. Inputs: the task's `dev-spec.md`, `execution.jsonl` (the `result` and
 `verify` records are precise source material), the changed-files list, existing memory files.
+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.
 
-## MEMORY_SHORT — write one short memory entry
+## Step 1 — write one short memory entry
 
 Create one file under `.easy-coding/memory/short/` following the format in
 `.easy-coding/memory/SHORT_MEMORY_TEMPLATE.md`. File naming convention:
@@ -23,6 +25,7 @@ Frontmatter (all fields required):
 ---
 memory_schema: 2
 id: SM-{YYYYMMDD}-{NN}
+source_task: {current task id, exact}
 date: {YYYY-MM-DD}
 task_type: {feature | bugfix | refactor | perf | doc | workflow}
 project_mode: {startup | iteration}
@@ -45,6 +48,13 @@ conversation. Refer to SHORT_MEMORY_TEMPLATE.md for the complete section format.
 
 If the task was cross-repo, record the repo names involved and the collaboration reason.
 
+After the file is successfully written, record the checkpoint immediately:
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-short-complete --session-file <P> --file "<relative-short-memory-path>" --agent <agent-id>`.
+Use the returned `status_context` as authoritative. On resume, if `memory_progress` already
+shows `short_memory_written:true`, do not create a duplicate entry; continue from Step 2.
+The state API validates `memory_schema: 2`, requires `source_task` to equal the current task id,
+and fingerprints the file. Do not reuse an older task's memory file as this checkpoint.
+
 ## Supermodule memory routing
 
 If the current project config contains `supermodule.role: super-parent`, archive memory by
@@ -67,26 +77,27 @@ create a new one instead. Short memories serve as both a recent-detail sliding w
 distillation buffer for long-term memory.
 
 **Sliding window (informational):** The short memory directory has a soft cap defined by
-`memory.short_term_max` (default 10). MEMORY_SHORT only WRITES one entry per completed task
-— it never counts, trims, or triggers distillation. Trimming is exclusively MEMORY_LONG's
-responsibility and only runs when the threshold is exceeded.
+`memory.short_term_max` (default 10). Step 1 only writes and checkpoints one entry per
+completed task. It never decides whether to distill.
 
-## MEMORY_LONG — distill durable knowledge (CONDITIONAL)
+## Step 2 — run the long-memory gate (CONDITIONAL)
 
 <HARD-GATE>
-MEMORY_LONG IS CONTROLLED BY THE STATE API `memory_long` INSTRUCTION.
+LONG-MEMORY WORK IS CONTROLLED BY THE STATE API `memory` INSTRUCTION.
 
 Before performing ANY distillation work:
-1. Read the `memory_long` object returned by the state API transition to MEMORY_LONG.
-   If it is not visible in context, re-run the same transition command for MEMORY_LONG to
-   re-emit the snapshot, then use that `memory_long` object.
-2. Treat `memory_long.action` as authoritative. Do NOT recount short memories yourself and
+1. After Step 1 is checkpointed, call
+   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-instruction --session-file <P>`.
+   This ordering is mandatory: the current task's short entry must be counted first.
+   The first successful call is frozen in `memory_progress.instruction`; resumed work reuses
+   the same action and trim count even after consumed short files are deleted.
+2. Treat the returned `memory.action` as authoritative. Do NOT recount short memories yourself and
    do NOT override the state API instruction with prompt reasoning.
-3. If `action == "no-op"`: output "MEMORY_LONG: no-op (short memory count = {short_count},
-   threshold = {short_term_max})" and immediately hand back to ec-workflow to advance to
-   COMPLETE. Do NOT read long memory files, do NOT attempt distillation, do NOT modify any file.
-4. If `action == "distill"`: distill exactly the older `trim_count` short-memory entries
-   and keep the latest `short_term_keep` entries.
+3. If `action == "no-op"`: output "MEMORY: long-memory no-op (short memory count =
+   {short_count}, threshold = {short_term_max})". Do NOT read or modify long memory files.
+4. If `action == "distill"`: treat `memory.candidate_files` and `memory.kept_files` as the
+   frozen authoritative sets. Distill and delete exactly `candidate_files`; preserve every
+   `kept_files` entry. Do not rebuild either set from the live directory.
 
 This gate is absolute. Even a single short memory entry below threshold does NOT trigger
 long-term compression regardless of any other signal.
@@ -100,8 +111,8 @@ Three-file long memory:
 - `TECHNICAL.md` — architecture decisions, implementation patterns, gotchas.
 
 Distillation steps:
-1. Use `memory_long.short_term_keep` and `memory_long.trim_count`. Keep the latest
-   `short_term_keep` entries; the older `trim_count` entries become distillation candidates.
+1. Use `memory.candidate_files` and `memory.kept_files`; their sizes correspond to
+   `memory.trim_count` and the retained window calculated at instruction time.
 2. Read the `target_long` of candidate short memories; route to business/technical.
 3. **Progressive loading** — read only the existing long entries matching this round's
    domain/tags/related_files. No unbounded whole-repo memory scan.
@@ -116,6 +127,21 @@ Distillation steps:
    This is sliding-window consumption after successful distillation, not destructive
    deletion of durable long-term knowledge.
 
+After either branch succeeds, record completion with the same authoritative action:
+`{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-complete --session-file <P> --action <no-op|distill> --agent <agent-id>`.
+The state API rejects an action that disagrees with the current threshold calculation.
+For `distill`, it also rejects completion while any frozen candidate still exists or any
+frozen retained file is missing. A candidate checkpoint may disappear only because it is
+explicitly listed in `candidate_files`.
+
+## Step 3 — automatically enter COMPLETE
+
+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
 
 While distilling technical memory, if you detect an architecture change — module added or