easy-coding-harness 0.10.0-beta.1 → 0.10.0-beta.10

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

@@ -28,7 +28,9 @@ lite semantics or an already-persisted edge, permits one IMPLEMENT -> VERIFICATI
 
 - `approval_mode = approve|guard|confirm|auto` controls whether a legal transition waits for a
   user. `confirm` waits only at ANALYSIS -> IMPLEMENT; after that, green REVIEW, VERIFICATION,
-  MEMORY, and COMPLETE transitions advance automatically.
+  MEMORY, and COMPLETE transitions advance automatically. `auto` advances every legal green
+  edge. The only additional pause is an exceptional code diff detected after the frozen
+  VERIFICATION acceptance checkpoint; accepting that exact diff does not change the mode.
 - `workflow_mode = adaptive|fast|standard|strict` controls execution cost and assurance depth.
 - `tdd_enabled` independently activates Java TDD and changed-line coverage. It defaults off;
   `tdd_coverage_threshold` defaults to 90 and accepts integers from 1 to 100.
@@ -39,14 +41,20 @@ selection and reasons, allows the user to change it within the risk floor, and f
 ANALYSIS -> IMPLEMENT is applied.
 
 TDD resolves with the same session-over-project precedence and freezes its enabled flag and
-threshold on ANALYSIS -> IMPLEMENT. When off, it must add no CI scan, artifacts, commands,
-coverage work, or stronger acceptance. Use `ec-config` for all mode configuration.
+threshold on ANALYSIS -> IMPLEMENT. It may be enabled only after `ec-tdd-init` readiness passes;
+there is no enabled-but-pending-initialization state. A dedicated `tdd-init` task always freezes
+TDD off so it can create or repair the required infrastructure without circular gating. When off,
+ordinary tasks add no CI scan, artifacts, commands, coverage work, or stronger acceptance. Use
+`ec-config` for all mode configuration.
 
 `confirm` and `auto` do not hide the proposal: show it in the plan. Confirm waits for that one
 plan decision; Auto continues immediately. Both remove later waiting, not quality gates.
 
 ## Startup
 
+Throughout this skill, `<agent-id>` is the canonical workflow owner ID: `claude-code`, `codex`,
+or `qoder`. Never use a display or source-author attribution such as `Codex with Easy Coding`.
+
 1. Read the injected state breadcrumbs or call:
 
    ```bash
@@ -58,36 +66,63 @@ 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 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 select-dev-spec-scope \
-     --spec <path> --spec-task <task-id> [--spec-task <task-id>]...
+   {{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>`.
-4. Match the user's intent against `current_task` and the active task list before resuming.
+   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.
+5. Match the user's intent against `current_task` and the active task list before resuming.
    If the user names or clearly matches another task, confirm the switch and call
    `claim-task --task-id <id> --agent <agent-id> --session-file <P>`. Do not execute task A
    under task B's request.
@@ -99,10 +134,10 @@ plan decision; Auto continues immediately. Both remove later waiting, not qualit
      to the requested deliverable. Feature, bugfix, refactor, performance, and workflow changes
      are code tasks. Use `doc`, `analysis`, or `report` only when the user explicitly requested
      a no-code deliverable; never downgrade a code request to the read-only completion path.
-5. Resume the matched/current task, then load only state-relevant assets. Do not read five full
+6. Resume the matched/current task, then load only state-relevant assets. Do not read five full
    memories at every startup; ANALYSIS searches memory metadata and opens relevant entries on
    demand.
-6. If another Agent last owned the task, summarize the stored handoff before continuing.
+7. If another Agent last owned the task, summarize the stored handoff before continuing.
 
 ## Stage dispatch
 
@@ -110,10 +145,17 @@ plan decision; Auto continues immediately. Both remove later waiting, not qualit
 - `ANALYSIS`: dispatch `ec-analysis`; it produces artifacts and a workflow proposal.
 - `IMPLEMENT`: dispatch `ec-implementing` using the frozen concrete mode.
 - `REVIEW`: dispatch `ec-reviewing`; the transition requires current fingerprint evidence.
-- `VERIFICATION`: dispatch `ec-verification`; archive requires current green evidence.
+- `VERIFICATION`: dispatch `ec-verification`; the MEMORY boundary requires green evidence and an
+  unchanged or explicitly accepted verification checkpoint.
 - `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
@@ -130,6 +172,23 @@ Use `auto-transition` only when the state API says the edge is automatic. Mechan
 (analysis artifacts and proposal, review fingerprint, verification fingerprint, memory
 completion) apply in every approval mode.
 
+`[easy-coding:acceptance-drift-confirmation-required]` is a narrow exception to automatic-edge
+handling. Call `inspect-transition-drift`, present every returned patch/binary/mode change and the
+current `diff_sha256`, then use the platform's native choice UI for these branches:
+
+1. Accept this exact diff and continue to MEMORY (recommended only with the stated verification
+   policy).
+2. Return to IMPLEMENT because the change needs normal repair/review.
+3. Hand off to another Agent.
+4. Other / revise.
+
+Never call `auto-transition` repeatedly to hide this pause. If the user accepts, preserve the
+existing REVIEW conclusion and call `confirm-transition` with the exact digest,
+`--verification-policy carry-forward|targeted|waived`, and a decision summary. `targeted` needs a
+passed current-fingerprint targeted check first. If the digest changes, inspect and present the
+new diff. Config, plan, workflow, Canonical-design, or nested-repository drift is not an
+acceptance-diff choice and returns to the stage required by the state API.
+
 For a migrated pre-0.9 Lite task, the breadcrumb
 `[easy-coding:lite-review-bypass-required:IMPLEMENT->REVIEW]` means the stored REVIEW edge is
 stale. Call `cancel-transition`, then immediately call `auto-transition --stage VERIFICATION`.

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

@@ -33,7 +33,7 @@ Trigger Easy Coding skills with your platform prefix — Codex: `$ec-*`, Qoder:
 - `ec-brainstorming` — design exploration before building (hard design gate)
 - `ec-analysis` `ec-implementing` `ec-reviewing` `ec-verification` — workflow stages
 - `ec-memory` — short/long memory archive
-- `ec-task-management` — task lifecycle panel · `ec-config` — Approval/Workflow/TDD settings · `ec-task-close` — interrupt a task
+- `ec-task-management` — task lifecycle panel · `ec-config` — Approval/Workflow/TDD settings · `ec-tdd-init` — Java changed-line gate initialization · `ec-task-close` — interrupt a task
 - `ec-no-harness` — bypass only Easy Coding for the current session
 - `ec-git` — git discipline · `ec-meta` — understand/customize the harness
 
@@ -45,13 +45,19 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   is session override > project `behavior.workflow_mode` > `adaptive`. Approval controls waiting;
   workflow controls execution depth. ANALYSIS shows and freezes adaptive to fast/standard/strict.
   Confirm approval waits only at ANALYSIS -> IMPLEMENT, then advances green later stages
-  automatically. Every new code task runs REVIEW; no mode changes scope, delivery form, or
-  evidence gates.
+  automatically; Auto advances all legal green edges. A new code diff after the VERIFICATION
+  checkpoint is the only exceptional pause across all modes: show the exact diff, bind acceptance
+  to its digest, and continue without rereview when the user accepts.
+  Every new code task runs REVIEW; no mode changes scope, delivery form, or evidence gates.
 - TDD is session override > project `behavior.tdd_enabled` > `false`; its changed-line threshold
   is session override > project `behavior.tdd_coverage_threshold` > `90`. ANALYSIS -> IMPLEMENT
-  freezes both. Disabled TDD adds no CI scan, JaCoCo work, commands, artifacts, or stronger gates.
-  Enabled TDD applies only to Java code tasks and requires lifecycle, review, local coverage, and
-  GitLab TEST-stage gate evidence.
+  freezes both. TDD may be enabled only after `ec-tdd-init` records valid infrastructure readiness;
+  there is no enable-now/init-later state. The dedicated `tdd-init` task always freezes TDD off and
+  initializes only changed-line coverage infrastructure, never historical business-test coverage.
+  Disabled TDD adds no CI scan, JaCoCo work, commands, artifacts, or stronger gates. Enabled TDD
+  applies only to Java code tasks and requires lifecycle, review, passed local unit tests, and
+  local coverage for production lines changed since the task baseline. `ec-tdd-init` still
+  generates GitLab TEST-stage automation, but remote CI status is not Harness acceptance evidence.
 - Confirmation-required edges use `pending_transition`; automatic edges use the restricted
   `auto-transition` API. A read-only task creates no test-strategy.md, never enters REVIEW,
   VERIFICATION, or MEMORY, and writes no task memory.
@@ -72,15 +78,35 @@ 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.
+  Freeze a verification checkpoint after green checks. Unchanged checkpoints follow approval
+  mode normally; post-checkpoint code drift requires exact digest acceptance and
+  carry-forward/targeted/waived verification policy, but never an automatic second REVIEW.
+- 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`.
+  Selected source tasks remain `implemented` through local VERIFICATION and become `verified`
+  only when the accepted VERIFICATION -> MEMORY boundary is actually applied.
+- 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.
+  effective confirmation mode; its checkpoint records any accepted post-verification diff digest
+  and decision. Once memory processing completes, COMPLETE is automatic.
 - NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
 - All cross-platform modules (skills, hooks, references) must use universal agent protocols.
   Do not rely on any specific agent's proprietary conventions unless the module is explicitly
@@ -89,15 +115,24 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 
 ## Runtime contract
 
-- Workflow state operations go through `{{platform_config_dir}}/hooks/easy_coding_state.py`;
-  do not hand-edit session files, `current_task`, task `status`, `stage_history`,
-  `pending_transition`, workflow/TDD proposal or freeze fields, `memory_progress`, or `last_agent`.
+- Workflow state operations use the script installed for the active host: Codex uses
+  `.codex/hooks/easy_coding_state.py`, while Qoder uses its installed `.qoder/hooks/easy_coding_state.py`
+  or `.qodercn/hooks/easy_coding_state.py` variant.
+  Never substitute one platform's script for the other, and pass only the canonical owner ID
+  (`codex` or `qoder`) to `--agent`; display attribution such as `Codex with Easy Coding` is not
+  a workflow identity. The installed script's embedded platform identity, canonical owner, and
+  injected session namespace must agree. Do not hand-edit session files, `current_task`, task
+  `status`, `stage_history`,
+  `pending_transition`, `verification_checkpoint`, workflow/TDD proposal or freeze fields,
+  `memory_progress`, or `last_agent`.
 - The hook injects `[easy-coding:session-file:P]`; pass that path to the state script with
   `--session-file <P>` when changing the current task or stage.
 - Workflow session files live at `{{workflow_state_path}}`; the CLI only installs files and
   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

@@ -31,7 +31,7 @@ platform prefixes such as `/` or `$`. If no status line is injected, do not inve
 - `/ec-brainstorming` — design exploration before building (hard design gate)
 - `/ec-analysis` `/ec-implementing` `/ec-reviewing` `/ec-verification` — workflow stages
 - `/ec-memory` — short/long memory archive
-- `/ec-task-management` — task lifecycle panel · `/ec-config` — Approval/Workflow/TDD settings · `/ec-task-close` — interrupt a task
+- `/ec-task-management` — task lifecycle panel · `/ec-config` — Approval/Workflow/TDD settings · `/ec-tdd-init` — Java changed-line gate initialization · `/ec-task-close` — interrupt a task
 - `/ec-no-harness` — bypass only Easy Coding for the current session
 - `/ec-git` — git discipline · `/ec-meta` — understand/customize the harness
 
@@ -43,13 +43,19 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   is session override > project `behavior.workflow_mode` > `adaptive`. Approval controls waiting;
   workflow controls execution depth. ANALYSIS shows and freezes adaptive to fast/standard/strict.
   Confirm approval waits only at ANALYSIS -> IMPLEMENT, then advances green later stages
-  automatically. Every new code task runs REVIEW; no mode changes scope, delivery form, or
-  evidence gates.
+  automatically; Auto advances all legal green edges. A new code diff after the VERIFICATION
+  checkpoint is the only exceptional pause across all modes: show the exact diff, bind acceptance
+  to its digest, and continue without rereview when the user accepts.
+  Every new code task runs REVIEW; no mode changes scope, delivery form, or evidence gates.
 - TDD is session override > project `behavior.tdd_enabled` > `false`; its changed-line threshold
   is session override > project `behavior.tdd_coverage_threshold` > `90`. ANALYSIS -> IMPLEMENT
-  freezes both. Disabled TDD adds no CI scan, JaCoCo work, commands, artifacts, or stronger gates.
-  Enabled TDD applies only to Java code tasks and requires lifecycle, review, local coverage, and
-  GitLab TEST-stage gate evidence.
+  freezes both. TDD may be enabled only after `ec-tdd-init` records valid infrastructure readiness;
+  there is no enable-now/init-later state. The dedicated `tdd-init` task always freezes TDD off and
+  initializes only changed-line coverage infrastructure, never historical business-test coverage.
+  Disabled TDD adds no CI scan, JaCoCo work, commands, artifacts, or stronger gates. Enabled TDD
+  applies only to Java code tasks and requires lifecycle, review, passed local unit tests, and
+  local coverage for production lines changed since the task baseline. `ec-tdd-init` still
+  generates GitLab TEST-stage automation, but remote CI status is not Harness acceptance evidence.
 - Confirmation-required edges use `pending_transition`; automatic edges use the restricted
   `auto-transition` API. A read-only task creates no test-strategy.md, never enters REVIEW,
   VERIFICATION, or MEMORY, and writes no task memory.
@@ -70,15 +76,35 @@ 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.
+  Freeze a verification checkpoint after green checks. Unchanged checkpoints follow approval
+  mode normally; post-checkpoint code drift requires exact digest acceptance and
+  carry-forward/targeted/waived verification policy, but never an automatic second REVIEW.
+- 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`.
+  Selected source tasks remain `implemented` through local VERIFICATION and become `verified`
+  only when the accepted VERIFICATION -> MEMORY boundary is actually applied.
+- 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.
+  effective confirmation mode; its checkpoint records any accepted post-verification diff digest
+  and decision. Once memory processing completes, COMPLETE is automatic.
 - NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
 - All cross-platform modules (skills, hooks, references) must use universal agent protocols.
   Do not rely on any specific agent's proprietary conventions unless the module is explicitly
@@ -87,15 +113,21 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 
 ## Runtime contract
 
-- Workflow state operations go through `{{platform_config_dir}}/hooks/easy_coding_state.py`;
-  do not hand-edit session files, `current_task`, task `status`, `stage_history`,
-  `pending_transition`, workflow/TDD proposal or freeze fields, `memory_progress`, or `last_agent`.
+- Workflow state operations go through `{{platform_config_dir}}/hooks/easy_coding_state.py` and
+  pass only the canonical owner ID `claude-code` to `--agent`; display attribution such as
+  `Claude with Easy Coding` is not a workflow identity. The installed script's embedded platform
+  identity, canonical owner, and injected session namespace must agree. Do not hand-edit session
+  files, `current_task`, task `status`, `stage_history`,
+  `pending_transition`, `verification_checkpoint`, workflow/TDD proposal or freeze fields,
+  `memory_progress`, or `last_agent`.
 - The hook injects `[easy-coding:session-file:P]`; pass that path to the state script with
   `--session-file <P>` when changing the current task or stage.
 - Workflow session files live at `{{workflow_state_path}}`; the CLI only installs files and
   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/qoder/agents/ec-implementer.md

@@ -18,6 +18,17 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
   context is in 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.
+- Follow the task card's `Local Baseline`: match nearby naming, control flow, null/error handling,
+  layering, object modeling, method granularity, literal usage, and comment style unless a stated
+  correctness, security, requirement, or hard-rule reason requires a deviation.
+- Treat the task card's `Code Comments` author value and field/member/constant rules as mandatory.
+- Do not add generic defensive null checks, speculative abstractions/layers, fragmented one-use
+  micro-methods, or a constant that exists only to hold one getter return.
+- Local, obvious magic values are allowed when they match surrounding code; create constants for
+  reuse, stable domain/config/protocol semantics, or established project convention.
+- Every method and field in a new core Java class, and every added or materially modified method
+  or field in an existing core Java class, must have meaningful Javadoc; comment complex logic
+  where intent or constraints are not obvious.
 - 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/qoder/agents/ec-reviewer.md

@@ -17,7 +17,12 @@ dimension named in your task card. Your reply IS the return value.
   - correctness → does the implementation match the dev-spec requirement? edge cases,
     null/empty handling, races, off-by-one.
   - compliance → does the code obey the RULES sections in the card? naming, format, comment
-    language, error handling.
+    language, error handling, and the evidenced Local Baseline.
+- Do not request defensive null checks, abstraction, constant extraction, or legacy-wide comment
+  cleanup solely as generic best practice. Flag unjustified local-style deviations, speculative
+  layers, fragmented one-use micro-methods, constants created only for a getter return, and
+  missing Javadoc on any method/field in a new core Java class or any added/materially modified
+  method/field in an existing core Java class.
 - `error` means a demonstrated acceptance, contract, security, or build failure. Use `warning`
   for a credible risk and `info` for non-blocking maintainability advice.
 

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

@@ -24,8 +24,15 @@
 - 需求 vs 现有代码：[[EC_TODO:填写结果或“无冲突”]]
 - Dev-Spec vs 现有代码：[[EC_TODO:填写结果或“无冲突”]]
 
+### 决策闭环
+decision_status: [[EC_TODO:仅当所有实质性问题均已解决并回填后写 closed]]
+- **已解决问题与结论**：[[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 及处理结论]]