easy-coding-harness 0.6.0 → 0.6.1

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

@@ -59,36 +59,43 @@ replies are English.
 4. **New task.** When creating a task (from step 3), create
    the task through the state API, which creates `task.json`, sets `status:"INIT"`, writes
    `stage_history`, and sets the session `current_task`:
-   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py create-task --session-file <P> --task-id <MM-DD-task-slug> --type <type> --title "<one-line summary>" --agent <agent-id>`.
+   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py create-task --session-file <P> --task-id <MM-DD-task-slug> --type <feature|bugfix|refactor|perf|doc|analysis|report|workflow> --title "<one-line summary>" --agent <agent-id>`.
    Use the returned `status_context` as the current status source. Then enter INIT.
 
 ## State machine
 
 ```
-INIT -> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY -> COMPLETE
-          ^            ^          |             |
-          +-- replan ---+          +--- fix -----+
-                       ^                         |
-                       +------- repair ----------+
-every edge --[explicit user confirmation by default]--> target stage
+INIT --[auto]--> ANALYSIS -> IMPLEMENT -> REVIEW -> VERIFICATION -> MEMORY --[auto]--> COMPLETE
+                                    \----------------> VERIFICATION
+                                    \--[read-only auto]------------------------------> COMPLETE
+                 ^            ^          |             |
+                 +-- replan ---+          +--- fix -----+
+                              ^                         |
+                              +------- repair ----------+
+user-decision edge --[explicit confirmation / handoff / Other]--> target stage
 any stage --[user abort via ec-task-close]--> CLOSED
 ```
 
 | Stage | Owner skill | What happens | Exit condition |
 |---|---|---|---|
-| INIT | ec-workflow | collect context, settle scope AND delivery form (change code vs. produce a document) | work complete; request ANALYSIS |
-| ANALYSIS | ec-analysis | dev-spec + execution plan + test strategy | analysis presented; request IMPLEMENT |
-| IMPLEMENT | ec-implementing | code changes per confirmed plan | all units done; request REVIEW |
+| INIT | ec-workflow | collect context, settle scope AND delivery form (change code vs. produce a document) | work complete; auto-transition to ANALYSIS |
+| ANALYSIS | ec-analysis | dev-spec + execution plan; code tasks also get test strategy | analysis presented; request IMPLEMENT |
+| IMPLEMENT | ec-implementing | code changes or one read-only deliverable | code: choose REVIEW or VERIFICATION; read-only: auto-complete after delivery |
 | REVIEW | ec-reviewing | multi-dimension code review | verdict selects a legal target; request it |
 | VERIFICATION | ec-verification | hard gate: lint/typecheck/test + coverage | result selects MEMORY or IMPLEMENT; request it |
-| MEMORY | ec-memory | write short memory, then run the conditional long-memory gate | memory work complete; request COMPLETE |
-| COMPLETE | ec-workflow | clear current_task, set task status, summary | terminal after user confirms entry |
+| MEMORY | ec-memory | write short memory, then run the conditional long-memory gate | memory work complete; auto-transition to COMPLETE |
+| COMPLETE | ec-workflow | clear current_task, set task status, summary | automatic terminal after MEMORY or validated read-only IMPLEMENT |
 | CLOSED | ec-task-close | user abort; no memory flow | terminal |
 
 > **INIT delivery-form rule.** When creating the task, `type` and `title` must faithfully
 > reflect the delivery form implied by the user's request. A refactor/fix/feature is a CODE
 > task; do not record it as an analysis/report task. Do not let ANALYSIS later re-interpret a
 > code task into a documentation-only task — that is a downgrade (see ec-analysis HARD RULE 5).
+> Use `doc`, `analysis`, or `report` only when the user's original request explicitly asks for
+> a no-code deliverable. Those task types may carry execution units with an empty file scope;
+> code task types may not. A successful empty-scope task ends automatically from IMPLEMENT to
+> COMPLETE after its full deliverable is shown; it never creates test-strategy.md or enters
+> REVIEW, VERIFICATION, or MEMORY.
 
 ## Task switching
 
@@ -101,20 +108,27 @@ When the user confirms switching from task A to task B:
    the user which previous agent owned the task.
 4. Resume task B's stage via the appropriate stage skill.
 
-No data is lost — task A's dev-spec, execution.jsonl, and test-strategy.md stay intact on
-disk. To return to task A later, the same intent routing applies: the user mentions it,
-routing matches, and switching happens again.
+No data is lost — task A's dev-spec and execution.jsonl stay intact, as does test-strategy.md
+for a code task. To return to task A later, the same intent routing applies: the user mentions
+it, routing matches, and switching happens again.
 
 ## Transition rules (hard)
 
-- **Never skip a stage.** ANALYSIS cannot jump to VERIFICATION; IMPLEMENT cannot start before
-  the ANALYSIS -> IMPLEMENT confirmation gate passes. No exception for "simple" tasks —
-  simple tasks have short analyses, not skipped ones.
-- **Every stage edge is a confirmation gate by default.** Stage completion does NOT change
-  `task.json.status`. It records a `pending_transition` through the state API, presents the
-  standard choices below, and stops. This applies to forward edges, repair/replan edges, and
-  MEMORY -> COMPLETE. Task creation entering INIT and the separately confirmed ec-task-close
-  flow do not add a redundant second prompt.
+- **Code tasks may skip only REVIEW.** ANALYSIS cannot jump to VERIFICATION; IMPLEMENT cannot
+  start before the ANALYSIS -> IMPLEMENT confirmation gate passes. After code implementation,
+  the user may enter REVIEW or skip it and enter VERIFICATION; code tasks never skip
+  VERIFICATION. Explicit read-only tasks are the separate terminal exception below.
+- **User-decision edges are confirmation gates.** Stage completion on those edges does NOT
+  change `task.json.status`. It records a `pending_transition` through the state API, presents
+  the choices below, and stops. This applies to forward edges, repair/replan edges, and the
+  IMPLEMENT review choice. Task creation entering INIT and the separately confirmed
+  ec-task-close flow do not add a redundant second prompt.
+- **Mechanical edges are automatic.** After INIT work completes, call `auto-transition`
+  for ANALYSIS and dispatch ec-analysis in the same flow. After `memory-complete`, call
+  `auto-transition` for COMPLETE and emit the closeout summary. A successful explicit read-only
+  task also calls `auto-transition` from IMPLEMENT to COMPLETE immediately after displaying the
+  full deliverable. These edges do not create `pending_transition`, do not offer handoff, and
+  never wait for user confirmation.
 - **Native choice first (hard requirement).** After `request-transition` succeeds, you MUST
   prefer the agent/platform's native user-choice tool whenever one is available. Do not render
   a plain-text numbered list on a platform that can present selectable options and a free-form
@@ -122,14 +136,20 @@ routing matches, and switching happens again.
   1. Confirm entering/returning to `<target-stage>` (recommended)
   2. Hand off to another agent
   3. Other — use the native tool's built-in free-form Other input.
+  Code-task IMPLEMENT completion is the one special gate: offer (1) enter REVIEW (recommended),
+  (2) skip REVIEW and enter VERIFICATION, and (3) hand off; use the native free-form Other
+  input for revisions. Record REVIEW as the recommended pending edge first. If the user chooses
+  VERIFICATION, cancel that edge, request IMPLEMENT -> VERIFICATION, and immediately confirm it
+  because that selection is explicit confirmation of the alternate target.
   Plain-text numbered choices are fallback only: use them only when no native user-choice tool
   exists. The runtime hook never mutates workflow state from user-prompt text. Native choice
   results, numbered fallback replies, and every natural-language reply must be interpreted by
   you against the current task and stored target before calling `confirm-transition` explicitly.
   On Other feedback, cancel the pending edge before revising work or requesting a different
   legal target. Never interpret silence, enthusiasm, or topic changes as confirmation.
-- **State before action.** Every confirmed stage advance is a two-step protocol: first consume
-  the pending edge through `confirm-transition`, then run that stage's real work. Do not start
+- **State before action.** Every user-confirmed stage advance is a two-step protocol: first
+  consume the pending edge through `confirm-transition`, then run that stage's real work. The
+  automatic edges use `auto-transition` instead. Do not start
   analysis, implementation, review, verification, memory writing, or closeout while
   `task.json.status` still names the previous stage. After every state API call, treat the
   returned snapshot/read-after-write state as authoritative for the next action and status line.
@@ -137,8 +157,11 @@ routing matches, and switching happens again.
   (1) Read `.easy-coding/templates/dev-spec-skeleton.md`, then (2) Write its exact content
   to the task's dev-spec.md. This is a mechanical copy, not a generation task. Do not read
   code, load memory, or analyze before the skeleton is on disk. This is ec-analysis
-  HARD RULE 1 — violating it means the analysis has failed. Your reply to the user must
-  be the complete dev-spec.md content, not a summary or custom format.
+  HARD RULE 1 — violating it means the analysis has failed. After the skeleton is written,
+  inspect the required evidence without editing it. Ask and resolve every user decision during
+  ANALYSIS before filling any section; the final report must not contain a `待用户决策` section
+  or `[阶段：ANALYSIS]`. Once decisions are resolved, your plan reply must be the complete
+  dev-spec.md content, not a summary or custom format.
   Additionally, ANALYSIS must stay faithful to the user's delivery form — it may NOT downgrade
   a code task to a report-only task — and the 改动范围 table must list only real project code,
   never `.easy-coding/` harness artifacts (ec-analysis HARD RULES 5 and 6).
@@ -146,9 +169,19 @@ routing matches, and switching happens again.
   waives stage-boundary prompts when the user explicitly requested autonomous execution.
   It carries NO scope or delivery-form decision. Never cite `auto_mode` to narrow scope,
   downgrade a code task, or bypass a blocker that needs a real user decision.
-- **At stage completion** request the legal target immediately (not at turn end):
+- **At user-decision stage completion** request the legal target immediately (not at turn end):
   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py request-transition --session-file <P> --stage <STAGE> --agent <agent-id> --reason "<why this edge is ready>"`.
   This writes only `pending_transition`; it does not change the stage.
+- **No-code IMPLEMENT delivery:** before completing the task, ec-implementing must
+  have output the successful unit's complete non-empty `deliverable` verbatim to the user.
+  A summary or execution.jsonl record is not a substitute; missing user-visible delivery keeps
+  the task in IMPLEMENT. The execution log must contain a matching `dispatch` immediately before
+  the accepted result for that unit. After delivery, call `auto-transition --stage COMPLETE`;
+  do not enter REVIEW, VERIFICATION, or MEMORY and do not write memory.
+- **On automatic completion** call:
+  `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py auto-transition --session-file <P> --stage <ANALYSIS|COMPLETE> --agent <agent-id>`.
+  The state API accepts INIT -> ANALYSIS, completed MEMORY -> COMPLETE, and a validated
+  read-only IMPLEMENT -> COMPLETE through this command.
 - **On user confirmation** read the current task's pending edge and call:
   `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py confirm-transition --session-file <P> --stage <STAGE> --agent <agent-id>`.
   Only after the read-after-write status names the target stage may its action start.
@@ -165,8 +198,9 @@ routing matches, and switching happens again.
   transition was rejected. Do not proceed with an illegal stage.
 - **Repair loop sizing** (after VERIFICATION): a trivial tweak may be fixed inside
   VERIFICATION and re-verified without a status change; a logic or structure change requests
-  VERIFICATION -> IMPLEMENT and waits at the standard confirmation gate before re-walking
-  REVIEW -> VERIFICATION.
+  VERIFICATION -> IMPLEMENT and waits at the standard confirmation gate. After repair, present
+  the IMPLEMENT completion choice again so the user may enter REVIEW or skip directly to
+  VERIFICATION.
 - **Scope guard** (repair loop): if the user's fix request falls outside the dev-spec scope
   (features or files absent from the change-scope table), say so explicitly and propose a
   new task with `spawned_from` set to the current task id. Never silently absorb scope creep.
@@ -177,10 +211,11 @@ routing matches, and switching happens again.
   user confirms, MEMORY writes one short entry first, records it through `memory-short-complete`,
   then asks the state API for the authoritative `memory` instruction. `action == "no-op"`
   skips long-memory reads/writes; `action == "distill"` processes exactly `trim_count` older
-  entries. Only after `memory-complete` may ec-memory request MEMORY -> COMPLETE.
-- **COMPLETE closeout:** COMPLETE is also a confirmed edge. Once the user confirms it, the
-  state API clears session `current_task`, so the next hook injection returns to Ready. Then
-  output a summary (what was done, files changed, key decisions).
+  entries. After `memory-complete`, ec-memory automatically advances MEMORY -> COMPLETE.
+- **COMPLETE closeout:** COMPLETE is automatic after successful memory processing, or directly
+  after a validated read-only deliverable. The state API clears session `current_task`, so the
+  next hook injection returns to Ready. Then output a summary; for read-only tasks, the full
+  report must already have appeared before this closeout.
 
 ## Resume and handoff
 
@@ -194,14 +229,21 @@ Resuming an active task (whether from session restart, claim, handoff, or task s
    records tell you exactly where work stopped.
 3. If the task was claimed from another agent, read the latest `handoff` record first for the
    fast summary and tell the user which previous agent handed it off.
-4. If `pending_transition` exists, do not rerun the completed stage action. Re-present the
-   standard confirmation/handoff/Other choices for its stored target.
-5. Otherwise tell the user what is being resumed and from which stage, then continue.
+4. If `pending_transition` exists, do not rerun the completed stage action. If its stored edge
+   is INIT -> ANALYSIS or MEMORY -> COMPLETE, treat it as an upgrade-era automatic edge: call
+   `auto-transition` for the stored target immediately, without confirmation or handoff. For
+   a read-only task in IMPLEMENT, cancel any stale pending REVIEW/VERIFICATION edge before the
+   terminal check below. For any other stored edge, re-present the standard
+   confirmation/handoff/Other choices. At an IMPLEMENT boundary for a code task, re-present the
+   special REVIEW / skip to VERIFICATION / handoff choices.
+5. If a read-only task resumes in IMPLEMENT with a valid successful result, output its complete
+   deliverable again and immediately auto-transition to COMPLETE. Otherwise tell the user what
+   is being resumed and from which stage, then continue.
 
 After a task switch, the same resume flow applies — the only difference is that `current_task`
 was just changed by the switching procedure rather than being loaded from a prior session.
 
-Offering handoff — every pending stage edge includes the standard handoff option. On that
+Offering handoff — every user-decision pending edge includes the handoff option. On that
 option, call:
 `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py handoff-task --session-file <P> --agent <agent-id> --summary "<dense context: plan shape, key decisions, user emphases>"`.
 

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

@@ -35,21 +35,25 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 
 ## Workflow discipline
 
-- Stages do not skip. Every legal stage edge uses `pending_transition` and requires explicit
-  user confirmation by default. At each boundary, use the agent's native user-choice tool
-  whenever available to offer: confirm target stage, hand off to another agent, or its
-  free-form Other input. Plain-text numbered choices are fallback only. `auto_mode` only
-  waives prompts when configured and explicitly requested by the user; it never changes scope
-  or delivery form.
+- Code tasks do not skip stages except when the user explicitly skips REVIEW after IMPLEMENT.
+  User-decision edges use `pending_transition`; offer the target and handoff, and offer
+  free-form Other through native UI when available. IMPLEMENT additionally offers direct entry
+  to VERIFICATION.
+  INIT -> ANALYSIS, completed MEMORY -> COMPLETE, and validated read-only
+  IMPLEMENT -> COMPLETE use restricted `auto-transition` without confirmation or handoff. A
+  read-only task creates no test-strategy.md, never enters REVIEW, VERIFICATION, or MEMORY, and
+  writes no task memory.
+  `auto_mode` only waives remaining prompts; it never changes scope or delivery form.
 - ANALYSIS must follow template-first: read `.easy-coding/templates/dev-spec-skeleton.md` then
-  write its exact content to the task's dev-spec.md as the FIRST tool calls, then fill sections
-  incrementally via edits. Reply to the user with the complete dev-spec.md content — never a
-  summary table or custom format.
-- VERIFICATION is a hard gate: lint + typecheck + test must pass on fresh evidence, and
-  coverage must match the test strategy, before a task can complete.
-- MEMORY combines short-memory creation and the conditional long-memory gate. Archive runs
-  only after explicit user acceptance — an unaccepted task's memory is dirty data.
-- NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
+  write its exact content to the task's dev-spec.md as the FIRST tool calls. Next inspect evidence
+  without editing the skeleton, ask every unresolved decision during analysis, and wait. Only
+  after all decisions are resolved may the agent fill the complete dev-spec.md. The final report
+  contains neither `[阶段：ANALYSIS]` nor a `待用户决策` section.
+- For code tasks, VERIFICATION is a hard gate: lint + typecheck + test must pass on fresh
+  evidence, and coverage must match the test strategy, before completion.
+- MEMORY combines short-memory creation and the conditional long-memory gate. Archive starts
+  only after explicit user acceptance; once memory processing completes, COMPLETE is automatic.
+- NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
 - All cross-platform modules (skills, hooks, references) must use universal agent protocols.
   Do not rely on any specific agent's proprietary conventions unless the module is explicitly
   a platform-specific compatibility layer. Reference files use descriptive filenames (e.g.,

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

@@ -33,21 +33,25 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 
 ## Workflow discipline
 
-- Stages do not skip. Every legal stage edge uses `pending_transition` and requires explicit
-  user confirmation by default. At each boundary, use the agent's native user-choice tool
-  whenever available to offer: confirm target stage, hand off to another agent, or its
-  free-form Other input. Plain-text numbered choices are fallback only. `auto_mode` only
-  waives prompts when configured and explicitly requested by the user; it never changes scope
-  or delivery form.
+- Code tasks do not skip stages except when the user explicitly skips REVIEW after IMPLEMENT.
+  User-decision edges use `pending_transition`; offer the target and handoff, and offer
+  free-form Other through native UI when available. IMPLEMENT additionally offers direct entry
+  to VERIFICATION.
+  INIT -> ANALYSIS, completed MEMORY -> COMPLETE, and validated read-only
+  IMPLEMENT -> COMPLETE use restricted `auto-transition` without confirmation or handoff. A
+  read-only task creates no test-strategy.md, never enters REVIEW, VERIFICATION, or MEMORY, and
+  writes no task memory.
+  `auto_mode` only waives remaining prompts; it never changes scope or delivery form.
 - ANALYSIS must follow template-first: read `.easy-coding/templates/dev-spec-skeleton.md` then
-  write its exact content to the task's dev-spec.md as the FIRST tool calls, then fill sections
-  incrementally via edits. Reply to the user with the complete dev-spec.md content — never a
-  summary table or custom format.
-- VERIFICATION is a hard gate: lint + typecheck + test must pass on fresh evidence, and
-  coverage must match the test strategy, before a task can complete.
-- MEMORY combines short-memory creation and the conditional long-memory gate. Archive runs
-  only after explicit user acceptance — an unaccepted task's memory is dirty data.
-- NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
+  write its exact content to the task's dev-spec.md as the FIRST tool calls. Next inspect evidence
+  without editing the skeleton, ask every unresolved decision during analysis, and wait. Only
+  after all decisions are resolved may the agent fill the complete dev-spec.md. The final report
+  contains neither `[阶段：ANALYSIS]` nor a `待用户决策` section.
+- For code tasks, VERIFICATION is a hard gate: lint + typecheck + test must pass on fresh
+  evidence, and coverage must match the test strategy, before completion.
+- MEMORY combines short-memory creation and the conditional long-memory gate. Archive starts
+  only after explicit user acceptance; once memory processing completes, COMPLETE is automatic.
+- NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
 - All cross-platform modules (skills, hooks, references) must use universal agent protocols.
   Do not rely on any specific agent's proprietary conventions unless the module is explicitly
   a platform-specific compatibility layer. Reference files use descriptive filenames (e.g.,

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

@@ -11,6 +11,8 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
 ## Hard constraints
 
 - Modify only the files listed in the task card's "Editable scope". Touch nothing else.
+- If the editable scope is `NONE — read-only deliverable`, modify nothing and return the full
+  requested result in `deliverable`.
 - Do not call any Skill tool.
 - Do not read `.qoder/skills/`, `.agents/skills/`, or any `.easy-coding/` file. All needed
   context is in the card.
@@ -22,6 +24,7 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
 
 - `changed_files`: the files you actually modified
 - `summary`: one line describing what you did
+- `deliverable`: full no-code result, or `null` for a code unit
 - `issues`: problems you hit (empty array if none)
 - `needs_attention`: anything the main agent must decide (empty array if none)
 

package/templates/runtime/templates/dev-spec-skeleton.md

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