easy-coding-harness 0.10.0-beta.3 → 0.10.0-beta.5

package/CHANGELOG.md

@@ -6,6 +6,48 @@
 - `y`：常规功能升级
 - `z`：日常 bug 修复
 
+## 0.10.0-beta.5
+
+- 兼容新版 `easy-dev-spec/v1` 共享执行区：同步设计/整文双摘要与 execution 投影协议，新增
+  单一共享 writer，将 Canonical Task、Step 和 dependency 的实施、验证、完成与取消结果
+  写回原 Spec；本地 `execution.jsonl` 继续保存完整门禁证据。
+- Canonical 绑定改为 `design_sha256 + document_sha256 + execution_revision`：执行进度更新不再
+  误判为方案漂移；CAS 冲突只在设计未变时自动重试一次，稳定幂等键避免重复事件，pending
+  写回可通过 `reconcile-spec-execution` 对账，revision 回退会被硬拦截。
+- 支持用户显式选择项目外 Spec 绝对路径，并提供身份严格校验的 `rebind-spec-source`；静态
+  设计调整必须 revision 恰好 +1、重新 READY 并调用 `sync-spec-design`，受影响任务及后继
+  状态重置后回到 ANALYSIS，禁止手工编辑 `EDS:EXECUTION`。
+- ANALYSIS→IMPLEMENT 只启动依赖已满足的来源任务；IMPLEMENT 按通过的本地测试证据回写
+  Step/implemented，REVIEW 写回阻塞，VERIFICATION 写回 verified，MEMORY→COMPLETE 自动
+  写回 completed，关闭任务写回 cancelled。共享写回与 Git 提交/推送保持相互独立。
+- 共享事件统一记录为 `easy-coding / <Agent> with Easy Coding`；单槽 pending 禁止被不同动作
+  覆盖，可重试 CAS 冲突保留现场，旧设计动作、幂等键载荷冲突和确定性状态错误会清槽解锁。
+  result 只消费当前 `in_progress` 尝试之后的 dispatch/严格成功证据，repair 只重开 blocked
+  来源任务；设计同步同时淘汰受影响依赖证据和旧实现指纹，本地 task.json 使用原子替换。
+
+- 将日常任务记忆与架构维护解耦：每个代码任务只生成不可变短期记忆；仅当长期记忆触发
+  `distill` 时才执行独立架构评估，并默认选择 `no-op`，避免为了更新而更新。
+- MEMORY 状态 API 新增冻结式架构评估契约和 `memory-architecture-assessment` 命令，记录
+  `action / trigger / reason / evidence / affected_sections`，并用 ABSTRACT 与架构 CHANGELOG
+  指纹校验 `no-op / backfill / update` 的实际文件结果；评估失败时不得消费短期候选。
+- 架构更新只接受模块边界、职责/依赖方向、核心流程、技术栈/运行基础设施或现有 ABSTRACT
+  与稳定事实冲突等证据；普通 Bug 修复、字段/DTO 调整、局部重构、临时方案和例行依赖升级
+  不触发更新。稳定编码约定只沉淀为 RULES 更新候选，不静默改写知识约束。
+- 初创项目首个实质任务若缺失 ABSTRACT，可通过 `missing-abstract` 例外在未触发长期蒸馏时
+  完成一次 `backfill`；0.10.0-beta.5 前已冻结的 MEMORY 指令及旧 MEMORY_LONG 恢复路径保持兼容。
+
+## 0.10.0-beta.4
+
+- ANALYSIS 完成后不再向会话回贴整份 `dev-spec.md`，改为展示核心方案、验收摘要、
+  Workflow Mode 与主要风险，并在客户端支持时提供完整 Dev-Spec 的绝对 Markdown 文件链接，
+  不支持本地链接时保留可复制的绝对路径。
+- Dev-Spec 新增结构化“决策闭环”章节；技术路线、接口、模型、状态、范围或验收存在未决问题时，
+  Agent 必须停留在 ANALYSIS 逐项问答并回填结论。状态 API 要求唯一的
+  `decision_status: closed` 标记，未闭合方案不能进入 IMPLEMENT。
+- `ec-implementing` 新增注释交付门禁：作者署名必须使用当前宿主 Agent 与 Easy Coding 的组合，
+  例如 `Codex with Easy Coding`；新增数据模型字段、枚举成员和常量必须逐项说明语义及适用的
+  单位、格式、取值、空值或兼容约束。
+
 ## 0.10.0-beta.3
 
 - TDD 业务任务的 `VERIFICATION` 门禁收口为本地证据：每个仓库（Canonical 场景下每个

package/README.md

@@ -86,6 +86,9 @@ any stage --[user abort via ec-task-close]--> CLOSED
   ANALYSIS → IMPLEMENT 确认一次，随后各阶段在质量门禁通过后自动推进，`auto` 从开始即
   自动推进。
 - 工作流模式优先级为 session 覆盖 > 项目 `behavior.workflow_mode` > `adaptive`。Adaptive 在 ANALYSIS 结束时根据风险解析、展示并冻结为 `fast`、`standard` 或 `strict`，用户可在风险下限之上调整。
+- ANALYSIS 会先通过问答闭合影响技术路线、接口、模型、状态、范围或验收的实质性问题，
+  并在 Dev-Spec 中记录唯一的 `decision_status: closed`。会话只展示核心方案、验收摘要、
+  Workflow Mode 与主要风险；完整 `dev-spec.md` 通过绝对本地链接或路径按需查看。
 - Java TDD 默认关闭；优先级为 session 覆盖 > 项目配置 > `false/90%`。首次开启前必须运行 `ec-tdd-init`，只建设 JUnit/JaCoCo/GitLab 增量覆盖率基础设施，不补存量业务单测；readiness 通过后才允许显式开启。开启后在 ANALYSIS → IMPLEMENT 冻结开关、baseline 与阈值，只验收本任务新增/修改生产代码行，执行 RED/GREEN/REFACTOR（纯重构使用 characterization GREEN → GREEN），并要求本地单测通过、本地差异覆盖率达到冻结阈值。GitLab TEST-stage job 仍会生成，但远程 pipeline 结果不属于 Harness 验收证据，也不会触发中间提交推送。关闭时普通任务不扫描 CI/JaCoCo、不增加命令或提高原工作流验收深度。
 - 所有新代码任务都完整进入 REVIEW；不同工作流模式只调整各状态内部的上下文加载、执行主体、审查独立性、验证范围和记忆深度，不绕过状态或证据门禁。
 - 显式 `doc` / `analysis` / `report` 只读任务不生成 `test-strategy.md`；展示完整报告后按生效模式进入 COMPLETE，不执行 REVIEW、VERIFICATION 或 MEMORY，也不写任务记忆。
@@ -98,7 +101,8 @@ any stage --[user abort via ec-task-close]--> CLOSED
 
 Harness 可选择性消费 easy-dev-spec 生成的单文件 `easy-dev-spec/v1` Canonical Spec：
 
-1. `ec-workflow` 先只读检查 manifest、仓库、任务 DAG、依赖和 baseline，不创建任务。
+1. `ec-workflow` 先只读检查 manifest、仓库、任务 DAG、依赖、baseline 与共享 execution；
+   旧 Spec 仍可只读检查，但成为可执行任务前必须初始化共享执行区。
 2. 用户明确选择一个或多个 Spec task；`select-dev-spec-scope` 按仓库提取确定性消费
    闭包，Harness 不默认导入整份 Spec，也不会读取未选任务正文。
 3. 一次选择创建一个 Harness task；ANALYSIS 使用最终 producer READY 门禁，并将
@@ -107,9 +111,12 @@ Harness 可选择性消费 easy-dev-spec 生成的单文件 `easy-dev-spec/v1` C
 4. `hard` 依赖决定执行顺序，冻结的 `contract` 依赖允许并行编码，`integration` 依赖
    在证据闭合前阻止全链路完成。
 
-Canonical Spec 是只读设计源；`.easy-coding/tasks/<task-id>/` 下的 `dev-spec.md`、
-`execution.jsonl` 和 `test-strategy.md` 是绑定来源 SHA-256 的运行时派生物，不会把开发
-进度写回源 Spec。无 Canonical manifest 的历史 Dev-Spec 继续走原有整文分析流程。
+Canonical Spec 的静态设计由 design revision + `design_sha256` 冻结；共享
+`EDS:EXECUTION` 则接收 Harness 的 Task/Step/dependency 投影。写回使用
+`execution_revision` CAS、幂等键和断点对账，执行区变化不会使本地 plan/review/verify
+指纹失效，设计变化或 revision 回滚仍会阻塞。显式项目外路径受支持，迁移后只能通过
+身份一致的 rebind 修复定位。静态设计调整必须 revision +1、READY 并执行 `sync-design`；
+机器执行区禁止手工编辑。无 Canonical manifest 的历史 Dev-Spec 继续走原有整文分析流程。
 
 ## Supermodule 模型
 
@@ -192,7 +199,8 @@ session 临时覆盖统一通过 `ec-config` 对话修改。升级到 0.10.0-bet
 5；未完成 `ec-tdd-init` readiness 的项目/session TDD 请求迁移为关闭并保留阈值，同时
 部署共享 Java 差异覆盖率与 readiness 工具。0.10.0-beta.3 起，TDD 业务任务只依赖本地
 单测与本地差异覆盖率，历史远程 CI 证据保留但不再参与验收。已经冻结的活动任务合同
-不会被静默改写。
+不会被静默改写。0.10.0-beta.4 起，仍停在 ANALYSIS 的旧任务必须补齐决策闭环后才能
+进入 IMPLEMENT；已经进入后续阶段的任务不受影响。
 
 若当前会话不希望 Harness 接管，显式调用 `/ec-no-harness`（Codex 使用
 `$ec-no-harness`）。它只旁路 Easy Coding，不关闭其他 hooks，也不忽略其他 skills；

package/package.json

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

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

@@ -16,6 +16,7 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
   file. All context you need is already in the task card.
 - Make no workflow stage-transition decisions. You do not know the state machine exists.
 - Follow the coding rules and architecture context embedded in the card.
+- Treat the task card's `Code Comments` author value and field/member/constant rules as mandatory.
 - Treat acceptance criteria, test points, contracts, and risks in the card as required inputs.
 - Run the exact targeted checks requested by the card and report their real outcome.
 - Preserve each existing file's original encoding; never silently convert.

package/templates/codex/agents/ec-implementer.toml

@@ -15,6 +15,7 @@ Hard constraints:
   the card.
 - Make no workflow stage-transition decisions; you do not know the state machine exists.
 - Follow the coding rules and architecture context embedded in the card.
+- Treat the task card's "Code Comments" author value and field/member/constant rules as mandatory.
 - Treat acceptance criteria, test points, contracts, and risks in the card as required inputs.
 - Run the exact targeted checks requested by the card and report their real outcome.
 - Preserve each existing file's original encoding; never silently convert.

package/templates/common/bundled-skills/ec-init/SKILL.md

@@ -191,7 +191,9 @@ 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 and generates it from the then-current code.)
+   detects the missing file during MEMORY and uses the explicit `missing-abstract` assessment
+   exception to generate it from the then-current code. This one-time backfill does not enable
+   routine per-task architecture updates.)
 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

@@ -83,30 +83,38 @@ context window, a task survives session end and agent switches with zero informa
 
 ## Canonical Spec integration
 
-An `easy-dev-spec/v1` Canonical Spec is a read-only design source, not progress storage.
+An `easy-dev-spec/v1` Canonical Spec separates frozen static design from a shared execution ledger.
 `inspect-dev-spec` validates the document with the protocol implementation pinned from
 `easy-dev-spec@7eb9b64`; after explicit task selection, `select-dev-spec-scope` returns one
 deterministic producer-compatible closure per repository, and `create-task-from-spec` creates one
-Harness task with the source ID/revision/SHA, selected task IDs, portable repository bindings,
+Harness task with source locator mode, ID/design revision and digest, document digest, execution
+revision, selected task IDs, repository bindings,
 baseline classifications, and dependency evidence.
 
 ANALYSIS derives local `dev-spec.md`, `execution.jsonl`, and `test-strategy.md` for the selected
 consumption closure. Canonical-backed units keep repository, source task/steps, files, symbols,
 and test commands. Hard dependencies shape the Unit DAG, READY contracts can run in parallel,
-and integration dependencies block end-to-end completion until evidence is recorded. The source
-Canonical Spec is never rewritten with Harness runtime state.
+and integration dependencies block end-to-end completion until evidence is recorded. Harness
+keeps detailed evidence locally and projects cross-application Task/Step/dependency outcomes into
+`EDS:EXECUTION` through one CAS/idempotent writer. Static changes use revision + READY +
+`sync-spec-design`; agents never hand-edit the machine ledger. Explicit external locators are
+allowed and rebind only by exact Canonical identity.
 
 ## Memory system
 
 Short memory: one schema-v2 file per task, sliding window (max 10, keep 5). Long memory:
 three files (index + business + technical), distilled from out-of-window short memories with
-explicit conflict resolution. ABSTRACT.md is backfilled/updated when memory distillation
-detects an architecture change.
+explicit conflict resolution. Daily tasks only produce facts. When distillation runs, MEMORY
+performs a separate, default-no-op architecture assessment and updates only affected ABSTRACT
+sections when frozen evidence proves the architecture cognition is stale. A missing ABSTRACT
+after the first substantive startup task is the only non-distillation backfill exception.
 
 ## Project knowledge — four layers
 
 Identity (SOUL, rarely changes) · Constraints (RULES, stable) · Cognition (ABSTRACT, updated
-on architecture change) · Memory (short + long, updated every task). ec-workflow always reads
+only after evidence-backed architecture assessment) · Memory (short every task, long only on
+distillation). Stable convention changes become RULES candidates in technical memory, never
+silent RULES edits. ec-workflow always reads
 SOUL + RULES + recent short memory; ec-analysis loads ABSTRACT and matching long memory on
 demand.
 

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

@@ -22,8 +22,10 @@ Communicate with the user in the user's language.
    dependency or risk.
 
 For a task with `task.json.spec_source`, re-run `inspect-dev-spec` against the stored source and
-every stored `task.repo_paths` repository binding. The schema, spec ID, revision, and SHA-256
-must still match. Then call the read-only selector for the exact stored selection:
+every stored `task.repo_paths` repository binding. Schema, Spec ID, design revision, and
+`design_sha256` must still match. A changed `document_sha256` with the same design is normal
+shared progress; refresh `execution_revision` without invalidating plan/review/verify evidence.
+An execution revision rollback is blocking. Then call the selector for the exact selection:
 
 ```bash
 {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py inspect-dev-spec \
@@ -42,13 +44,35 @@ read. `scope-drifted` requires current-code conflict analysis before confirmatio
 ## Analysis artifacts
 
 Copy `.easy-coding/templates/dev-spec-skeleton.md` first, then replace every `[[EC_TODO:...]]`.
-Keep every mandatory section. `### Workflow Mode` is required.
+Keep every mandatory section. The `### 决策闭环` (Decision Closure) and `### Workflow Mode`
+sections are required. The decision section must contain exactly one standalone
+`decision_status: closed` marker, and no other `decision_status` marker may appear elsewhere in
+the document. Record every material question and its resolved conclusion in that section, or
+record that no extra decision was needed.
+
+## Decision closure before implementation
+
+Treat uncertainty that can change the technical route, public or internal contract, data model,
+state flow, edit scope, compatibility behavior, or acceptance criteria as a material open
+question. While any such question remains:
+
+1. stay in ANALYSIS and ask the user focused questions, preferably one decision at a time;
+2. do not present a final analysis summary, propose the final Workflow Mode, request
+   ANALYSIS -> IMPLEMENT, or suggest that implementation can begin;
+3. update the Dev-Spec with each confirmed answer and its evidence;
+4. use `decision_status: open` while the artifact is still being developed, then replace it with
+   the single `decision_status: closed` marker only after every material question is resolved.
+
+Risks, integration work that is intentionally deferred by a frozen Spec, and environmental
+verification limits are not automatically open questions. Describe them as risks or explicit
+acceptance boundaries. Never use `closed` to hide a decision that still needs the user.
 
 Execution plan records use:
 
 ```json
 {
   "type": "plan",
+  "spec_design_sha256": "<Canonical design digest; omit for ordinary tasks>",
   "strategy": "single|sequential|parallel",
   "units": [{
     "id": "U1",
@@ -78,7 +102,8 @@ units together must cover every source step exactly once. Map selected hard depe
 `parallel_groups`.
 
 Canonical-backed `dev-spec.md`, `execution.jsonl`, and `test-strategy.md` are runtime-derived
-evidence, not a second maintained Spec. Record the source path/ID/revision/SHA, selected tasks
+evidence, not a second maintained Spec. Record the source path/path mode/ID/design revision and
+digest, current document digest/execution revision/writeback status, selected tasks
 and repositories, baseline/conflict result, Unit mapping, source test mapping, and pending
 integration edges.
 
@@ -183,14 +208,22 @@ while still in ANALYSIS.
 
 ## User presentation and transition
 
-Before the boundary, present:
+After decision closure and before the boundary, present a concise session summary instead of
+pasting the full `dev-spec.md`. The summary must contain:
 
-- proposed scope and units;
-- acceptance and test strategy;
+- the core solution and affected scope/units;
+- acceptance and test-strategy highlights;
 - configured, minimum, and selected workflow modes with reasons;
-- how IMPLEMENT, REVIEW, VERIFICATION, and MEMORY will run;
+- the material risks and explicit acceptance boundaries;
 - explicit user ability to request a higher mode or a permitted lower mode.
 
+End the summary with the absolute path to
+`.easy-coding/tasks/<task-id>/dev-spec.md`. When the current client supports local-file Markdown
+links, render `[View full Dev-Spec](</absolute/path/to/dev-spec.md>)`; otherwise print the
+copyable absolute path. Do not dump the full artifact merely because the client cannot link it.
+If the user asks to inspect the full plan, open or read that stored file on demand using the
+current Agent's supported file capability.
+
 Then request or auto-apply ANALYSIS -> IMPLEMENT according to `effective_approval_mode`.
 The state API atomically freezes the proposal when the transition is applied. `approval_mode`
 controls waiting; it never changes the selected execution depth.
@@ -201,6 +234,14 @@ controls waiting; it never changes the selected execution depth.
 - No unresolved skeleton placeholders.
 - No code task with an empty change scope.
 - No unit without acceptance criteria, test points, contracts, and risks.
+- No final summary, workflow proposal, or transition while a material decision is unresolved.
+- No transition without exactly one `decision_status: closed` marker in `dev-spec.md`.
 - No transition without a valid workflow proposal.
-- No Canonical-backed transition with changed source SHA, unresolved repository identity,
+- No Canonical-backed transition with changed design revision/digest, a backward execution
+  revision, pending/conflicted writeback, unresolved repository identity,
   incomplete selected-task coverage, or an open Unit/Step/File/Symbol/Test traceability gap.
+
+If evidence requires changing Canonical task boundaries, contracts, files, symbols, Steps, Tests,
+or dependencies, remain/return to ANALYSIS, update the original static design with revision +1,
+restore READY, and call `sync-spec-design --affected-task ...`. This invalidates the old local
+plan. Never substitute edits to the derived `dev-spec.md`, and never edit `EDS:EXECUTION` by hand.

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

@@ -62,7 +62,13 @@ with `.easy-coding/sessions/` always excluded. The CLI already added it to `.git
 - Do not commit `spec/dev/` unless the user explicitly asks.
 - Do not omit managed `easy-coding upgrade` changes merely because they were created outside
   the current agent turn.
-- Never modify or stage the source Canonical Spec merely to record Harness execution progress.
+- Shared Canonical execution writeback and Git delivery are independent facts. Do not stage or
+  commit a project-external Spec automatically. For a Spec inside a Git repository, include it
+  only when the user's requested commit scope and normal repository rules include it; never claim
+  shared writeback merely because Git succeeded, or Git delivery merely because writeback
+  succeeded.
+- Never hand-edit `EDS:EXECUTION`. Static Spec changes are valid only through design revision +
+  READY + `sync-spec-design`; runtime progress uses the shared writer commands.
 - In a supermodule task launched from the parent root, parent `.easy-coding/` belongs to the
   parent git. Child `.easy-coding/memory/` changes created by memory archive belong to the
   owning child git and must be committed before the parent gitlink update.

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

@@ -36,6 +36,17 @@ Communicate with the user in the user's language.
    enters REVIEW.
 7. Read-only `doc` / `analysis` / `report` tasks remain `single` with `files:[]`, make no writes,
    return a non-empty `deliverable`, then follow the mode-aware IMPLEMENT -> COMPLETE edge.
+8. When a project template, local convention, or new source header uses author attribution, the
+   author value must be `<Current Agent Name> with Easy Coding`, for example
+   `Codex with Easy Coding`. `Current Agent Name` means the user-facing host Agent (for example,
+   Codex, Claude, or Qoder), never an implementation sub-agent role such as `ec-implementer`.
+   Never copy a previous human or Agent name into newly authored code.
+9. Every newly added field in a data-bearing model must have a meaningful field-level comment.
+   This includes new or extended entity/DO/DTO/VO/BO, request/response, configuration, and similar
+   model types. Every new enum member and every new declared constant requires the same treatment.
+   Describe the semantic meaning and, when relevant, units, format, allowed values, nullability,
+   default behavior, or compatibility constraints. A type-level comment does not replace comments
+   on its fields or members; do not add low-value comments to ordinary local variables.
 
 ## Choose the execution owner
 
@@ -81,26 +92,46 @@ Sub-agents never dispatch other sub-agents or read `.easy-coding` workflow asset
 ## Test Points    {unit.test_points and exact targeted commands}
 ## Contracts      {inputs, outputs, invariants shared with other units}
 ## Risks          {known edge cases and compatibility risks}
+## Code Comments  {resolved host Agent author value; model-field, enum-member, and constant rules}
 ## Coding Rules   {pre-digested RULES sections}
 ## Architecture   {pre-digested ABSTRACT sections}
 ## Output
 status:"completed", repo_id|null, source_task_id|null, changed_files[], summary,
-deliverable|null, issues:[], needs_attention:[]
+deliverable|null, checks:[{command,passed,failures:[]}], issues:[], needs_attention:[]
 ```
 
 ## Dispatch and result loop
 
 1. Append a `dispatch` record before work begins. Canonical-backed records include `repo_id` and
    `source_task_id`; resolve every file relative to `task.repo_paths[repo_id]` before dispatch.
+   Before dispatching a selected task that is not already `in_progress`, call
+   `writeback-spec-task --status in_progress` with a key stable for that dispatch/recovery
+   attempt but distinct from any earlier accepted `in_progress` event. Do this only after its
+   hard/contract dependencies are ready; do not batch-start dependent tasks at the initial
+   IMPLEMENT boundary.
+   Populate `Code Comments` on every code task card with the resolved user-facing host Agent
+   author value and the field/member/constant rules above; sub-agents do not read this Skill.
 2. Execute according to dependency order and selected owner.
 3. Run targeted unit tests and self-audit scope, contracts, TODOs, and introduced warnings.
+   Also audit new author attributions and every new model field, enum member, and constant against
+   the comment requirements above before recording success.
 4. Append one `result` record. Only a successful unit uses `status:"completed"`; include
    unresolved issues rather than hiding them, and do not advance while `issues` or
    `needs_attention` is non-empty.
+   For Canonical-backed success, write each owned source Step `completed` through
+   `writeback-spec-step`, with passed evidence for every bound Canonical Test ID and a stable key.
+   After every source Step for that task is complete, write the task `implemented`. On failure,
+   write the affected Step `failed`; the shared writer moves its task to `blocked`. Local evidence
+   is appended first, shared projection second, and the returned acknowledgment last.
 5. If a result changes a cross-unit contract, stop dependent units and return to ANALYSIS.
 6. For parallel units, detect overlapping writes before advancing.
 7. If implementation needs a file, symbol, repository, or source step outside the mapped
    Canonical change set, stop and return to ANALYSIS instead of expanding scope implicitly.
+8. If a static Canonical change is confirmed, revise the original design by exactly one revision
+   and use `sync-spec-design`; never edit the machine-owned execution block. If a writeback was
+   interrupted, run `reconcile-spec-execution` with the stored idempotent pending action.
+   Reconciliation only consumes dispatch/result evidence created after the current `in_progress`
+   acknowledgment; it never opens a new repair attempt or reuses an earlier attempt's result.
 
 Do not emit a progress message for every trivial edit. Report at unit boundaries to reduce
 conversation overhead while keeping work observable.
@@ -119,4 +150,6 @@ conversation overhead while keeping work observable.
 - [ ] Every unit has a dispatch/result pair and satisfied its acceptance criteria.
 - [ ] Targeted tests ran or a concrete blocker is recorded.
 - [ ] Cross-unit contracts still match.
+- [ ] New author attributions use the user-facing host `<Current Agent Name> with Easy Coding`.
+- [ ] Every new model field, enum member, and constant has a meaningful field-level comment.
 - [ ] Code tasks enter REVIEW, regardless of workflow mode.

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

@@ -3,10 +3,17 @@ name: ec-memory
 description: MEMORY-stage skill. Creates a workflow-mode-aware schema-v2 checkpoint from existing task evidence and performs conditional long-memory distillation.
 ---
 
-# ec-memory — evidence-derived checkpoint
+# ec-memory — evidence-derived checkpoint and knowledge governance
 
-MEMORY remains mandatory for code tasks. It must not re-analyze the repository or repeat the
-entire conversation. Generate from `task.json`, `dev-spec.md`, and `execution.jsonl`.
+MEMORY remains mandatory for code tasks. Daily task processing and architecture maintenance are
+separate responsibilities: every completed code task produces one immutable short-memory fact;
+only a long-memory distillation, or the explicit missing-ABSTRACT startup exception, may open an
+architecture assessment. Never update architecture merely because MEMORY was entered.
+
+The short-memory checkpoint must not re-analyze the repository or repeat the entire conversation.
+Generate it only from the verified evidence already stored in `task.json`, `dev-spec.md`, and
+`execution.jsonl`. The bounded repository reads described below belong only to a required
+`backfill` or `update` architecture assessment.
 
 ## Depth by workflow mode
 
@@ -37,5 +44,60 @@ Ask the state API for `memory-instruction`. Distill only when it returns `action
 otherwise record `no-op`. Long memory receives reusable facts only, not file dumps, transient
 logs, routine command output, or speculation.
 
+## Architecture assessment
+
+Read the frozen `architecture_assessment` contract returned by `memory-instruction`.
+
+- `required:false`: do not read the repository for architecture purposes and do not modify
+  `.easy-coding/ABSTRACT.md` or `.easy-coding/CHANGELOG.md`.
+- `trigger:distillation`: finish classifying the frozen `candidate_files`, then assess whether
+  their stable, reusable facts make the current architecture cognition stale. Default to
+  `no-op`.
+- `trigger:missing-abstract`: use `backfill` after the first substantive startup task even when
+  long-memory action is `no-op`. This is the only non-distillation architecture exception.
+
+An architecture `update` is justified only by evidence of at least one of these changes:
+
+- a module was added, removed, split, or merged;
+- module responsibility, ownership, or dependency direction changed;
+- a core request, data, state, or event flow changed;
+- the technology stack, runtime, build, or deployment infrastructure changed;
+- the existing ABSTRACT conflicts with verified current facts.
+
+Do not update for a bug fix, local implementation detail, DTO/field-only change, local refactor,
+temporary workaround, routine dependency patch, or the mere fact that distillation ran. Stable
+new coding conventions belong in `TECHNICAL.md` as explicit RULES update candidates; never
+silently edit `RULES.md`, `SOUL.md`, or `TEST_STRATEGY.md` from MEMORY.
+
+For `no-op`, use only the frozen memory evidence and give a concrete reason. For `backfill` or
+`update`, read only candidate-related modules, entrypoints, dependencies, and affected ABSTRACT
+sections. Do not perform an unbounded repository re-analysis. Create or edit only the affected
+sections of `.easy-coding/ABSTRACT.md`, and create or append `.easy-coding/CHANGELOG.md`; never
+regenerate the whole ABSTRACT when a bounded edit is sufficient.
+
+Whenever `required:true`, record the decision through the command below. For distillation this
+must succeed before deleting any candidate; for `missing-abstract` it must succeed before the
+`no-op` long-memory action can complete:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-architecture-assessment \
+  --session-file <P> --action <no-op|backfill|update> --reason <reason> \
+  --evidence <frozen-memory-file> [--evidence <frozen-memory-file> ...] \
+  [--affected-section <section> ...] --agent <agent-id>
+```
+
+`backfill` and `update` require affected sections; `no-op` must not declare them. Evidence must
+come from the frozen candidate set, or from the current checkpoint for the missing-ABSTRACT
+exception. If assessment or architecture-file validation fails, keep every candidate file and
+remain in MEMORY.
+
+After the assessment succeeds, a distillation may delete all frozen `candidate_files` while
+preserving every `kept_file`. Then call `memory-complete`. The state API rechecks that no-op
+assets stayed unchanged, changed assets still match the recorded assessment, all candidates were
+consumed, and all retained memories still exist.
+
 Complete processing with `memory-complete`. When the state API reports
 `memory_progress.completed:true`, call `auto-transition --stage COMPLETE`.
+For Canonical-backed tasks this automatic edge first writes every verified selected source task
+to shared `completed`; pending integration dependencies or failed writeback keep the task in
+MEMORY. Do not claim COMPLETE from local memory state alone.

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

@@ -69,6 +69,12 @@ Verdict:
 In-scope defects are fixed automatically. Ask the user only for a new design choice, changed
 public contract, or contradiction with a confirmed decision.
 
+For Canonical-backed review, append the local review record first. Any blocking finding then
+writes the owning source task `blocked` through `writeback-spec-task`, referencing the local
+record. A passed review does not change shared task status. A `replan` verdict returns to ANALYSIS;
+confirmed static Spec changes use revision + READY + `sync-spec-design` rather than edits to the
+derived plan or machine execution block.
+
 ## Evidence record
 
 Append one final record per executed dimension for the current implementation fingerprint.

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

@@ -22,6 +22,9 @@ when you recognize abandonment intent in the user's message.
    `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py close-current --session-file <P> --reason "<reason>" --agent <agent-id>`.
    This sets `task.json.status` to `CLOSED`, records `closed_reason`, updates history, and
    clears session `current_task` so the next hook injection returns to Ready.
+   For Canonical-backed work, the same command first projects every unfinished selected task to
+   shared `cancelled` (using an intermediate `blocked` transition when required). A shared writer
+   failure leaves the Harness task open; never close only the local side.
    Use the returned `status_context` as the authoritative status source for the rest of the
    current turn.
 4. **No memory flow.** Do not run MEMORY. An incomplete task's memory is dirty data.
@@ -34,6 +37,7 @@ when you recognize abandonment intent in the user's message.
 
 - Never delete task folders — CLOSED tasks stay as a record.
 - Never run the memory/archive flow.
+- Never hand-edit the Canonical execution region to force cancellation.
 - This skill closes the `current_task`. If the user wants to close a different (suspended)
   task, they should first switch to it via ec-workflow, then invoke ec-task-close.
 - Division of labor: ec-task-management lists/creates (read-only panel), ec-workflow runs the

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

@@ -16,7 +16,8 @@ Call the state API snapshot and show:
 - task `concrete_workflow_mode` and frozen TDD state when present;
 - harness enabled/disabled state;
 - active and resumable tasks.
-- for Canonical-backed tasks: source Spec ID/revision/SHA, selected task IDs, repository
+- for Canonical-backed tasks: source locator/path mode, Spec ID/design revision/design digest,
+  document digest, execution revision, writeback status, selected task IDs, repository
   bindings/baseline status, and pending dependency evidence.
 
 Mode inspection and configuration belongs to `ec-config`. If the user asks to change Approval,
@@ -32,3 +33,8 @@ When creating from a Canonical Spec, call `inspect-dev-spec`, display the comple
 dependency selection, then call `select-dev-spec-scope` and `create-task-from-spec` only after
 explicit user selection. Multiple selected Spec tasks still create one Harness task, while the
 selector returns one deterministic consumption closure per selected repository.
+Initialize missing shared execution before creation. Support `rebind-spec-source` only when the
+new file matches schema + spec_id + design revision + design_sha256 and does not roll execution
+revision backward. A pending writeback is repaired with `reconcile-spec-execution`, never by
+editing the execution JSON block or starting a different writeback. A deterministic rejected
+action is cleared with `status:error`; correct its input instead of replaying it.

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

@@ -77,7 +77,10 @@ and a non-empty `not_applicable_reason`; it does not count as the required appli
 check, and must not be represented by an invented successful command.
 
 Record failures in `failures[]`. If any current-fingerprint record fails, return to IMPLEMENT;
-do not append a later synthetic pass without rerunning the failed command.
+do not append a later synthetic pass without rerunning the failed command. For a Canonical-backed
+failure, append the local verify record first, then write the owning source task `blocked` with a
+concise reference to that record. The repair transition automatically reopens blocked source tasks
+only; unaffected implemented tasks retain their latest shared conclusion.
 
 ## Coverage and acceptance
 
@@ -116,6 +119,13 @@ tasks remain separate evidence records. In `strict`, every involved repository i
 records all four check types; a repository-specific non-applicable record still needs its reason
 and source ownership.
 
+After all current-fingerprint local checks pass for a Canonical source task, call
+`writeback-spec-task --status verified`. Include passed `kind:"test"` evidence for every bound
+Canonical Test ID plus concise references to local review/build/coverage records. The subsequent
+VERIFICATION -> MEMORY application requires every selected shared task to be `verified` or
+`completed`; remote CI remains outside this acceptance gate. If writeback is interrupted, run
+`reconcile-spec-execution` before requesting the transition.
+
 Record the exact integration edge only after its evidence exists:
 
 ```bash

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

@@ -67,13 +67,17 @@ plan decision; Auto continues immediately. Both remove later waiting, not qualit
    chooses one or more tasks and resolves repository paths or omitted hard-dependency evidence,
    call `create-task-from-spec` once for the complete selection. A document without a Canonical
    manifest remains a legacy ANALYSIS input for an ordinary task. A malformed, DRAFT, or otherwise
-   non-READY Canonical Spec stays blocked and must never be downgraded to the legacy route. Never
-   edit the source Spec.
+   non-READY Canonical Spec stays blocked and must never be downgraded to the legacy route. A
+   READY Canonical Spec without shared execution remains readable, but run
+   `initialize-spec-execution` before selection can become an executable Harness task.
 
    ```bash
    {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py inspect-dev-spec \
      --spec <path> [--repo-path <repo-id>=<path>]...
 
+   {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py initialize-spec-execution \
+     --spec <path>
+
    {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py select-dev-spec-scope \
      --spec <path> --spec-task <task-id> [--spec-task <task-id>]...
 
@@ -90,6 +94,10 @@ plan decision; Auto continues immediately. Both remove later waiting, not qualit
 
    When multiple selected tasks depend on the same target, disambiguate creation evidence with
    `<source-task-id>-><dependency-task-id>=<evidence>`.
+   Explicit project-external Spec files are supported and stored as absolute locators. If that
+   locator moves, use `rebind-spec-source`; never guess by basename. Shared execution progress is
+   written only through state API writer commands. Static design edits require revision + READY +
+   `sync-spec-design`; never hand-edit the `EDS:EXECUTION` region.
 4. When the user explicitly invokes `ec-tdd-init`, let that skill own preflight and create a
    `type=tdd-init` code task only after scope confirmation. Do not reinterpret it as an ordinary
    TDD-enabled feature task and do not require readiness before creating it.
@@ -120,6 +128,12 @@ plan decision; Auto continues immediately. Both remove later waiting, not qualit
 - `MEMORY`: dispatch `ec-memory`.
 - `COMPLETE` / `CLOSED`: report terminal status and clear stale session ownership.
 
+For a Canonical-backed task whose snapshot reports pending writeback, call
+`reconcile-spec-execution` before dispatching the stage. Do not advance locally while shared
+writeback remains pending or conflicted. A deterministic writer rejection reports `error` and
+clears the pending action so the corrected action can proceed; never overwrite a different
+pending action.
+
 ## Boundary handling
 
 Use `request-transition` for a boundary that requires approval, then present the complete

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

@@ -76,13 +76,22 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   only Easy Coding workflow/stage orchestration for this session. Continue honoring every
   non-Easy-Coding skill, hook, and instruction. Do not clear or mutate the suspended task.
 - ANALYSIS must follow template-first: read `.easy-coding/templates/dev-spec-skeleton.md` then
-  write its exact content to the task's dev-spec.md as the FIRST tool calls. 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.
+  write its exact content to the task's dev-spec.md as the FIRST tool calls. Next inspect evidence,
+  set `decision_status: open`, ask every unresolved material decision, and progressively record
+  each confirmed answer and its evidence in `### 决策闭环`. Only after all material decisions are
+  resolved may the agent set the single `decision_status: closed`, finalize the artifacts, and
+  propose IMPLEMENT. The session presentation is a concise core-solution, acceptance, workflow,
+  and risk summary with an absolute local link/path to the full dev-spec.md; never paste the full
+  artifact by default. The final artifact contains neither `[阶段：ANALYSIS]` nor a
+  `待用户决策` section.
 - REVIEW and VERIFICATION are fingerprinted hard gates. Review evidence must match the final
   implementation; verification evidence must match final implementation and config. The frozen
   workflow mode selects targeted, impacted, or full commands without weakening the green gate.
+- Canonical-backed tasks bind static validity to design revision + `design_sha256`, while
+  `document_sha256` and `execution_revision` may advance through shared writer commands. Project-
+  external explicit Spec paths are allowed and may be repaired only with identity-checked rebind.
+  Runtime progress must use the shared writer with CAS/idempotency and reconciliation; static
+  design changes require revision + READY + `sync-spec-design`. Never hand-edit `EDS:EXECUTION`.
 - MEMORY combines short-memory creation and the conditional long-memory gate. Entry follows the
   effective confirmation mode; once memory processing completes, COMPLETE is automatic.
 - NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
@@ -102,6 +111,8 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   creates the project-init task — agent skills perform all project analysis.
 - Cross-repo references in git-tracked task artifacts use repo NAMES, never local paths.
   Cache local paths only through the state script so they land on the current task.
+- Shared Canonical writeback is a stage gate but not proof of Git commit/push, and Git delivery is
+  not proof of writeback. Keep those facts and scopes separate.
 {{supermodule_boundary}}
 
 <!-- ═══ end easy-coding-harness generated ═══ -->