easy-coding-harness 0.10.0-beta.7 → 0.10.0-beta.8

package/package.json

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

package/templates/common/bundled-skills/ec-meta/references/local-architecture/README.md

@@ -49,11 +49,15 @@ automatic edges. A validated read-only `doc` / `analysis` / `report` task also a
 from IMPLEMENT after its full deliverable is shown, without REVIEW, VERIFICATION, MEMORY, or
 task memory. Approval mode controls non-mechanical edge waiting: approve confirms each edge,
 guard confirms two critical gates, confirm waits only at ANALYSIS -> IMPLEMENT, and auto
-advances every legal edge after mechanical gates.
+advances every legal edge after mechanical gates. After green VERIFICATION, Harness freezes an
+acceptance checkpoint. A later code diff temporarily pauses every mode so the exact digest can be
+accepted; unchanged `confirm`/`auto` tasks remain automatic.
 Workflow mode is independently configured as adaptive/fast/standard/strict; ANALYSIS freezes
 adaptive to a concrete mode, and every new code task still enters REVIEW. REVIEW evidence is
 bound to the final implementation fingerprint, VERIFICATION evidence is bound to implementation
-and config fingerprints, and MEMORY keeps the conditional long-memory threshold gate.
+and config fingerprints, and an accepted post-checkpoint diff records its authorization plus
+carry-forward/targeted/waived policy without forcing a second REVIEW. MEMORY keeps the conditional
+long-memory threshold gate.
 
 Java TDD is a third independent, default-off control managed by `ec-config`. Session overrides
 project configuration; ANALYSIS freezes enabled state and the 1..100 changed-line threshold
@@ -78,7 +82,7 @@ stage in `task.json`; no data is lost. Each task folder is self-contained.
 Each task is a folder. `task.json` is metadata, including the current stage, workflow proposal,
 frozen concrete mode, and any `pending_transition`; `dev-spec.md` is the human-readable plan;
 `execution.jsonl` is an append-only plan-and-log (one `plan` record, then `dispatch`/`result`
-/`review`/`verify`/`handoff` records). Because plan and log live on disk, not in an agent's
+/`review`/`verify`/`acceptance`/`handoff` records). Because plan and log live on disk, not in an agent's
 context window, a task survives session end and agent switches with zero information loss.
 
 ## Canonical Spec integration
@@ -98,7 +102,9 @@ and integration dependencies block end-to-end completion until evidence is recor
 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.
+allowed and rebind only by exact Canonical identity. Source tasks stay `implemented` after local
+checks and become `verified` only when VERIFICATION -> MEMORY is applied under explicit or
+standing approval-mode authorization; the shared event includes the acceptance digest.
 
 ## Memory system
 

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

@@ -33,6 +33,12 @@ Explain precedence as `session override > project config > defaults`. Defaults a
 task freezes its effective TDD values when ANALYSIS advances to IMPLEMENT; later project/session
 changes affect future tasks and ANALYSIS only.
 
+Approval semantics stay independent from verification depth: `approve` waits at each
+non-mechanical edge, `guard` waits at ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY, `confirm`
+waits only for the plan, and `auto` advances legal green edges immediately. Every mode temporarily
+pauses only when code changes after the frozen VERIFICATION checkpoint, because the user must see
+and accept that exact new diff; this exception does not convert `auto` into `guard`.
+
 ## Project configuration
 
 Use `easy-coding config` for project settings. The CLI confirms one atomic update of Approval,

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

@@ -35,6 +35,13 @@ Name it `{memory_id}_{YYYYMMDD}_{smart_name}.md` and set
 `.easy-coding/memory/short/`, then register it with
 `memory-short-complete`. Never invent test results or commit hashes.
 
+Copy the final `acceptance` record from `execution.jsonl` into the checkpoint as a concise
+decision fact: authorization source, decision summary, `diff_sha256`, review policy, verification
+policy, changed files, and any Canonical source tasks that required targeted verification.
+`memory-short-complete` rejects a checkpoint that omits any of those decision fields. This records
+the user's accepted exception without re-reviewing or re-analyzing the code. Canonical writeback
+already carries the same digest and authorization as shared `acceptance` evidence.
+
 When frozen TDD is enabled, add its threshold, lifecycle evidence, passed local unit-test result,
 and local changed-line result to the short memory's execution evidence. Remote CI status is not
 part of Harness acceptance or task memory. When TDD is off, omit TDD fields entirely so ordinary

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

@@ -15,7 +15,8 @@ Read-only tasks never enter this stage. Obtain fresh fingerprints before running
 
 - No completion claim without executed verification evidence.
 - Evidence is reusable only while both returned fingerprints remain unchanged.
-- Relevant code or config changes invalidate old evidence automatically.
+- Relevant code or config changes invalidate old evidence automatically unless the exact
+  post-verification code diff is explicitly accepted under the checkpoint protocol below.
 - Failed or missing evidence never becomes acceptance because of approval mode.
 
 ## Verification depth
@@ -109,6 +110,38 @@ enable TDD; report the explicit `ec-config`/`easy-coding config` next step.
   user wait.
 - A reported in-scope problem returns to IMPLEMENT; out-of-scope work becomes a separate task.
 
+After the final green evidence is recorded, freeze the acceptance baseline before presenting the
+result or applying the boundary:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py verification-checkpoint \
+  --agent <agent-id> --session-file <P>
+```
+
+Then request or auto-apply VERIFICATION -> MEMORY according to `approval_mode`. `auto` remains
+automatic when the checkpoint is unchanged. If any in-scope code changed after the checkpoint,
+the state API returns `action:"acceptance-drift"`, keeps the task in VERIFICATION, and includes
+the exact unified patches or binary/mode-change descriptions plus a stable `diff_sha256`. This
+exceptional drift pauses every approval mode, including `auto`; it does not permanently change
+the configured mode.
+
+Show the complete returned diff and ask whether to accept that exact digest. Do not re-enter
+IMPLEMENT or rerun REVIEW merely because this drift exists. On acceptance, call
+`confirm-transition --stage MEMORY --diff-sha256 <digest>` with exactly one policy:
+
+- `carry-forward`: only when every changed hunk is confidently non-executable and existing
+  verification remains applicable;
+- `targeted`: executable behavior changed; append passed current-fingerprint targeted verification
+  before confirming. Canonical tasks must cover every affected source task reported by the
+  acceptance record, without rerunning checks for unaffected source tasks;
+- `waived`: the user explicitly accepts the stated unverified risk.
+
+Include `--decision-summary` with the user's decision. A changed digest invalidates the pending
+confirmation and must be shown again. Behavior config, execution plan, workflow, Canonical
+design, or nested-repository metadata drift cannot use this shortcut; return to ANALYSIS or
+IMPLEMENT as reported by the state API. The acceptance record bridges only the accepted
+implementation fingerprints, so prior REVIEW evidence remains valid without a second REVIEW.
+
 For Canonical-backed tasks, run each repository's commands from `task.repo_paths[repo_id]` and
 cover every selected task's source test IDs. Report pending integration edges separately from
 local green checks. They do not block local implementation evidence, but the state API blocks
@@ -119,12 +152,15 @@ 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.
+After implementation and local checks, each selected Canonical source task remains
+`implemented`. Do not call `writeback-spec-task --status verified` from VERIFICATION. Applying
+VERIFICATION -> MEMORY is the authoritative acceptance boundary: the state API writes each
+still-implemented source task to `verified` through CAS/idempotent recoverable events with its
+accepted test evidence and acceptance digest, then enters MEMORY only after every write is
+confirmed. For `approve`/`guard`, that authority is the explicit boundary
+confirmation; for `confirm`/`auto`, it is the standing approval-mode authorization when no new
+drift exists. If writeback is interrupted, run `reconcile-spec-execution` before retrying the
+transition. Remote CI remains outside this acceptance gate.
 
 Record the exact integration edge only after its evidence exists:
 
@@ -137,5 +173,5 @@ Record the exact integration edge only after its evidence exists:
   --agent <agent>
 ```
 
-The state API rejects VERIFICATION -> MEMORY unless all evidence for the current implementation
-and config fingerprints is green.
+The state API rejects VERIFICATION -> MEMORY unless all effective evidence is green and the
+checkpoint is either unchanged or bound to an exact accepted diff.

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.
@@ -140,7 +142,8 @@ 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.
 
@@ -166,6 +169,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

@@ -45,8 +45,10 @@ 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. TDD may be enabled only after `ec-tdd-init` records valid infrastructure readiness;
@@ -87,18 +89,24 @@ 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.
+  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
@@ -109,7 +117,8 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 
 - 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`.
+  `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

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

@@ -43,8 +43,10 @@ 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. TDD may be enabled only after `ec-tdd-init` records valid infrastructure readiness;
@@ -85,18 +87,24 @@ 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.
+  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
@@ -107,7 +115,8 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 
 - 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`.
+  `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