easy-coding-harness 0.10.0-beta.4 → 0.10.0-beta.6

package/CHANGELOG.md

@@ -6,6 +6,52 @@
 - `y`：常规功能升级
 - `z`：日常 bug 修复
 
+## 0.10.0-beta.6
+
+- Canonical Spec 首次路由新增 `inspect-dev-spec --manifest-only`：只通过 normalized remote
+  识别当前 worktree、展示任务目录和共享 execution 状态，不再为未选仓库解析本地路径或
+  为任何未选任务计算 baseline；`path_hint` 明确降级为提示信息。
+- 用户选定 task 后，`inspect-dev-spec --spec-task ...` 只检查所选任务所属仓库及其
+  change/test 范围；当前 worktree remote 唯一匹配时无需手工传 `--repo-path`，即使旧
+  `path_hint` 指向仍存在的原 checkout，也优先绑定当前 worktree。
+- `ec-workflow` 不再在路由阶段提前读取消费闭包；`ec-analysis` 负责唯一一次精确 selector
+  调用，并对 `exact` / `scope-unchanged` 使用快速投影，对 `scope-drifted` 只分析所选任务
+  的漂移文件和符号，派生 dev-spec 不再被解释为第二轮 Spec 创作。
+- 共享 `EDS:EXECUTION` 固化为依赖事实来源：已完成 hard task 或已满足依赖边直接放行；
+  禁止通过另一个本地 Harness task、Git 历史或 Agent 推断重复考古完成状态。
+- 保持项目外原始 Spec absolute locator、身份校验 rebind、共享 writer/CAS 及旧版全量
+  `inspect-dev-spec` 调用兼容；新增 worktree、未选仓库隔离和三平台安装产物回归测试。
+
+## 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`，改为展示核心方案、验收摘要、

package/README.md

@@ -101,18 +101,26 @@ 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，不创建任务。
-2. 用户明确选择一个或多个 Spec task；`select-dev-spec-scope` 按仓库提取确定性消费
-   闭包，Harness 不默认导入整份 Spec，也不会读取未选任务正文。
-3. 一次选择创建一个 Harness task；ANALYSIS 使用最终 producer READY 门禁，并将
-   selected task 映射为带 `repo_id`、`source_task_id`、source steps、文件、符号和测试
-   命令的 Unit。
-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 继续走原有整文分析流程。
+1. `ec-workflow` 先用 `inspect-dev-spec --manifest-only` 只读校验 manifest，通过 normalized
+   remote 识别当前 worktree，并展示任务 DAG 与共享 execution；不会解析未选仓库路径，也
+   不在选择前计算任何任务的 baseline。旧 Spec 仍可只读检查，但成为可执行任务前必须
+   初始化共享执行区。
+2. 用户明确选择一个或多个 Spec task 后，Harness 用 `--spec-task` 只检查所选任务仓库和
+   change/test 范围。当前 worktree remote 唯一匹配时无需手工路径；`path_hint` 不一致只会
+   形成一次运行时映射提示，不会复制或修复原 Spec。
+3. 一次选择创建一个 Harness task；ANALYSIS 唯一一次调用 `select-dev-spec-scope` 提取确定性
+   消费闭包。`exact` / `scope-unchanged` 直接快速投影为 Unit、测试策略和派生 dev-spec，
+   `scope-drifted` 才读取所选范围内的漂移文件与符号；未选任务正文始终不进入上下文。
+4. `EDS:EXECUTION` 是依赖事实来源：`hard` 依赖决定执行顺序，冻结的 `contract` 依赖允许
+   并行编码，`integration` 依赖在证据闭合前阻止全链路完成；不会再从本地任务或 Git 历史
+   重复推断共享状态。
+
+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 模型
 

package/package.json

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

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

@@ -21,13 +21,18 @@ Communicate with the user in the user's language.
 4. Inspect concrete code paths and tests. Expand context only when evidence reveals another
    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:
+For a task with `task.json.spec_source`, re-run `inspect-dev-spec` against the stored source, exact
+`selected_spec_tasks`, and only their stored `task.repo_paths` bindings. 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 once for the exact
+selection:
 
 ```bash
 {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py inspect-dev-spec \
-  --spec <stored-source> --repo-path <repo-id>=<stored-path> [--repo-path <repo-id>=<stored-path>]...
+  --spec <stored-source> \
+  --spec-task <selected-task-id> [--spec-task <selected-task-id>]... \
+  [--repo-path <repo-id>=<stored-path>]...
 
 {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py select-dev-spec-scope \
   --spec <stored-source> --spec-task <selected-task-id> [--spec-task <selected-task-id>]...
@@ -36,8 +41,20 @@ must still match. Then call the read-only selector for the exact stored selectio
 Load only the returned per-repository consumption closures: manifest/global context, selected
 task and repository sections, related contracts, direct dependency summaries, selected
 changes/steps/tests, and relevant integration rows. Never replace the selector with a whole-file
-read. `scope-drifted` requires current-code conflict analysis before confirmation;
-`baseline-unavailable` or unresolved repository identity remains blocked in ANALYSIS.
+read. Treat the Canonical closure as frozen design, not as a prompt to design the task again:
+
+- `exact` and `scope-unchanged` use the fast projection path. Confirm the selected paths, symbols,
+  and test entry points, then map the closure into Units, `test-strategy.md`, and the derived
+  `dev-spec.md` in one pass. Do not reselect interfaces, fields, task boundaries, Steps, or Tests,
+  and do not ask questions already answered by the source Spec.
+- `scope-drifted` reads and analyzes only changed files and symbols in the selected task scope.
+  Escalate to a static design revision only when that evidence changes a frozen contract or task
+  boundary; unrelated repository or completed-task changes are background, not current drift.
+- `baseline-unavailable` or unresolved selected-repository identity remains blocked in ANALYSIS.
+
+Use shared execution dependency status directly. Do not inspect another local Harness task or Git
+history to re-prove a completed hard dependency, and do not repeat dependency or baseline
+explanations after the selected inspection has recorded them.
 
 ## Analysis artifacts
 
@@ -70,6 +87,7 @@ Execution plan records use:
 ```json
 {
   "type": "plan",
+  "spec_design_sha256": "<Canonical design digest; omit for ordinary tasks>",
   "strategy": "single|sequential|parallel",
   "units": [{
     "id": "U1",
@@ -99,10 +117,15 @@ 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.
 
+The required skeleton is a mechanical artifact schema. For a Canonical-backed task it is filled
+from the selected closure and current-code delta; it must never become a second round of Spec
+authoring.
+
 Every source test command remains mandatory. Additional commands from the current repository are
 allowed only when `test-strategy.md` records why the Canonical command alone is insufficient.
 For every selected source test, `test-strategy.md` must spell out its Test ID, source task ID,
@@ -233,5 +256,11 @@ controls waiting; it never changes the selected execution depth.
 - 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

@@ -97,13 +97,18 @@ Sub-agents never dispatch other sub-agents or read `.easy-coding` workflow asset
 ## 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.
@@ -113,10 +118,20 @@ deliverable|null, issues:[], needs_attention:[]
 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.

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

@@ -61,35 +61,59 @@ plan decision; Auto continues immediately. Both remove later waiting, not qualit
    - Present with `status != "COMPLETE"`: invoke `{{skill_trigger}}ec-init`, then stop.
    - `[easy-coding:upgrade-init-pending:X]`: recommend `{{skill_trigger}}ec-init` for vX
      adaptation, but allow the user to continue; this reminder is not a workflow block.
-3. When the user explicitly references a Dev-Spec, run the read-only `inspect-dev-spec` command
-   before ordinary task creation. For `protocol=canonical-v1`, show every task ID, repository,
-   title, dependency, and baseline status; never select all tasks by default. After the user
-   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.
+3. When the user explicitly references a Dev-Spec, first run read-only `inspect-dev-spec
+   --manifest-only`. This routing pass validates the document, identifies the current worktree by
+   normalized remote, and returns the task catalog without resolving unrelated repositories. For
+   `protocol=canonical-v1`, show every task ID, repository, title, static status, actual execution
+   status, and dependency; never select all tasks by default and never calculate baseline drift
+   before selection.
+
+   After the user chooses one or more tasks, run one selected inspection with repeated
+   `--spec-task`. Resolve paths only for repositories that own selected tasks. The current
+   worktree needs no explicit mapping when its normalized remote matches uniquely; pass
+   `--repo-path` only for an additional selected repository or to confirm an ambiguous current
+   match. A differing `path_hint` is a one-time runtime mapping notice, not a Spec portability
+   failure: never copy, mirror, or rewrite the source Spec because of it.
+
+   Then call `create-task-from-spec` once for the complete selection. Do not call
+   `select-dev-spec-scope` during routing; `ec-analysis` owns the single consumption-closure read
+   after task creation. 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. 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>]...
+     --spec <path> --manifest-only
 
-   {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py select-dev-spec-scope \
-     --spec <path> --spec-task <task-id> [--spec-task <task-id>]...
+   {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py inspect-dev-spec \
+     --spec <path> --spec-task <task-id> [--spec-task <task-id>]... \
+     [--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 create-task-from-spec \
      --spec <path> --spec-task <task-id> [--spec-task <task-id>]... \
      --task-id <harness-task-id> --type <type> --title <title> \
-     --repo-path <repo-id>=<path> [--dependency-evidence <dependency-id>=<evidence>]... \
+     [--repo-path <repo-id>=<path>]... \
+     [--dependency-evidence <dependency-id>=<evidence>]... \
      --agent <agent-id> --session-file <P>
    ```
 
-   `select-dev-spec-scope` is read-only and may run only after explicit task selection. Its
-   per-repository payload is the authoritative ANALYSIS context; do not load unselected task
-   bodies from the source document.
+   Shared `EDS:EXECUTION` is the dependency fact source. Accept a completed hard dependency or a
+   satisfied edge directly from that snapshot. Only accept manual dependency evidence when the
+   shared edge is still pending and the user explicitly supplies independently verifiable
+   evidence; never reconstruct completion from another local Harness task, Git history, or an
+   agent's inference.
 
    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 +144,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

@@ -87,6 +87,16 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 - 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`.
+- Canonical routing is two-pass: first use manifest-only discovery for the current worktree, then
+  inspect only the explicitly selected task IDs and repositories. A remote-confirmed worktree
+  overrides a stale `path_hint`; never mirror the source Spec or re-check unselected repositories.
+  ANALYSIS reads the selected consumption closure once and treats exact/scope-unchanged as a fast
+  projection, while shared execution is the dependency fact source.
 - 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.
@@ -106,6 +116,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 ═══ -->

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

@@ -85,6 +85,16 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 - 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`.
+- Canonical routing is two-pass: first use manifest-only discovery for the current worktree, then
+  inspect only the explicitly selected task IDs and repositories. A remote-confirmed worktree
+  overrides a stale `path_hint`; never mirror the source Spec or re-check unselected repositories.
+  ANALYSIS reads the selected consumption closure once and treats exact/scope-unchanged as a fast
+  projection, while shared execution is the dependency fact source.
 - 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.
@@ -104,6 +114,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 ═══ -->