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

package/CHANGELOG.md

@@ -6,6 +6,36 @@
 - `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`，改为展示核心方案、验收摘要、

package/README.md

@@ -101,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 门禁，并将
@@ -110,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 模型
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "0.10.0-beta.4",
+  "version": "0.10.0-beta.5",
   "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

@@ -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 \
@@ -70,6 +72,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,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.
 
@@ -233,5 +237,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

@@ -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

@@ -87,6 +87,11 @@ 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`.
 - 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 +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 ═══ -->

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

@@ -85,6 +85,11 @@ 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`.
 - 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 +109,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/runtime/templates/dev-spec-skeleton.md

@@ -30,7 +30,9 @@ decision_status: [[EC_TODO:仅当所有实质性问题均已解决并回填后
 - **确认依据**：[[EC_TODO:用户答复、冻结 Spec、现有代码证据或“无额外决策”]]
 
 ### Canonical Spec 来源
-- **来源**：[[EC_TODO:非 Canonical 任务写“无”；否则填写 repo-relative path、spec_id、revision、SHA-256]]
+- **来源定位**：[[EC_TODO:非 Canonical 任务写“无”；否则填写 path、path_mode、spec_id 与 design revision]]
+- **设计 / 文档摘要**：[[EC_TODO:非 Canonical 任务写“无”；否则填写 design_sha256、document_sha256]]
+- **共享执行状态**：[[EC_TODO:非 Canonical 任务写“无”；否则填写 execution_revision、writeback 状态及是否需要 reconcile]]
 - **选择任务 / 仓库**：[[EC_TODO:非 Canonical 任务写“无”；否则填写 selected task IDs 与 repo IDs]]
 - **消费闭包**：[[EC_TODO:非 Canonical 任务写“无”；否则填写 contracts、direct dependencies、changes、steps、tests 摘要]]
 - **基线与冲突**：[[EC_TODO:非 Canonical 任务写“无”；否则逐仓填写 exact/scope-unchanged/scope-drifted/baseline-unavailable 及处理结论]]