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

package/package.json

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

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

@@ -16,7 +16,17 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
   file. All context you need is already in the task card.
 - Make no workflow stage-transition decisions. You do not know the state machine exists.
 - Follow the coding rules and architecture context embedded in the card.
+- 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/claude/agents/ec-reviewer.md

@@ -15,7 +15,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/codex/agents/ec-implementer.toml

@@ -15,7 +15,17 @@ Hard constraints:
   the card.
 - Make no workflow stage-transition decisions; you do not know the state machine exists.
 - Follow the coding rules and architecture context embedded in the card.
+- 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/codex/agents/ec-reviewer.toml

@@ -14,7 +14,12 @@ Stance:
   - 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/common/bundled-skills/ec-init/SKILL.md

@@ -147,7 +147,14 @@ agent must be able to see what was generated and on what evidence.
    - Naming conventions actually in use (scan representative files)
    - Comment language: if more than 70% of existing comments are Chinese, the rule is
      "comments in Chinese"; same logic for English; mixed → follow each file's dominant language
-   - Error handling style, import ordering, formatter/linter in use (read their configs)
+   - Null/empty handling and error-handling style, including where the project intentionally
+     relies on upstream contracts instead of adding defensive checks
+   - Existing class/method extraction granularity and architecture boundaries; do not turn a
+     preference for single responsibility into a generic demand for many one-use helpers
+   - Literal and constant conventions, including when local magic values are accepted and when
+     a stable domain/config/protocol value is promoted to a named constant
+   - Javadoc/doc-comment coverage for core code and the inline-comment style used for complex logic
+   - Import ordering and formatter/linter in use (read their configs)
    Structure as one section per language plus a General section. Every rule must be
    mechanically checkable — "be clean" is not a rule; "exported functions carry explicit
    return types" is.

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-analysis/SKILL.md

@@ -21,6 +21,13 @@ 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.
 
+Apply a progressive cost budget while doing this work. A likely Fast task reads only the nearest
+comparable implementation, its direct contracts, and targeted tests. Standard reads the affected
+module closure. Expand into cross-module or repository-wide context only after concrete evidence
+shows the compound high-risk and complexity signals required for Strict. Do not scan unrelated
+repositories, the full Spec, broad Git history, or every architecture section merely to prove
+that a bounded task might be complicated.
+
 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
@@ -56,6 +63,19 @@ Use shared execution dependency status directly. Do not inspect another local Ha
 history to re-prove a completed hard dependency, and do not repeat dependency or baseline
 explanations after the selected inspection has recorded them.
 
+## Local implementation baseline
+
+For every code unit, inspect the nearest same-module, same-role implementation before planning.
+Record a concise `local_baseline` covering only evidenced conventions that affect this change:
+naming and control flow, null/empty and error handling, layering and dependency direction, object
+modeling, method extraction granularity, literal/constant usage, and comments/Javadoc. Prefer the
+closest comparable code over a repository-wide average. Explicit requirements, correctness,
+security, and project hard rules still take precedence; otherwise do not replace safe local
+conventions with generic best practices.
+
+Do not ask the user to choose a style already answered consistently by comparable code. Ask only
+when local evidence conflicts or a deviation can change the contract, risk, or acceptance result.
+
 ## Analysis artifacts
 
 Copy `.easy-coding/templates/dev-spec-skeleton.md` first, then replace every `[[EC_TODO:...]]`.
@@ -101,6 +121,7 @@ Execution plan records use:
     "test_points": ["targeted check"],
     "contracts": ["input/output/invariant or none"],
     "risks": ["known risk or none"],
+    "local_baseline": ["evidenced local convention and source path"],
     "repo_id": "R1",
     "source_task_id": "R1-T1",
     "source_step_ids": ["S1"],
@@ -132,8 +153,10 @@ For every selected source test, `test-strategy.md` must spell out its Test ID, s
 owning Unit ID, repository-relative test file, and exact Canonical command; the state gate checks
 these markers mechanically.
 
-Prefer one coherent unit over artificial file-level splitting. Use parallel only for truly
-independent write scopes. Better unit contracts reduce later REVIEW rework.
+Prefer one coherent unit over artificial file-level splitting. Do not split a class or method by
+line count, or create many one-use helpers, merely to make the plan look modular. Extract only a
+clear semantic boundary, reuse point, or independently testable responsibility. Use parallel only
+for truly independent write scopes. Better unit contracts reduce later REVIEW rework.
 
 Code tasks require `test-strategy.md`; explicit `doc`, `analysis`, and `report` tasks do not.
 
@@ -196,19 +219,30 @@ Use its `minimum_mode` and `reasons` as the proposal floor. You may raise this r
 uncertainty or user preference requires more rigor, but never lower or replace it with a
 self-reported floor. The state API rechecks the floor when the proposal is saved and frozen.
 
-The calculation classifies:
-
-- `fast`: one low-risk unit, local behavior, no public contract/schema/security/concurrency or
-  migration impact, targeted test available.
-- `standard`: ordinary multi-file feature/fix, bounded contract impact, existing patterns and
-  impacted tests available.
-- `strict`: state machine, configuration/schema migration, security/payment/data-loss risk,
-  public or cross-repository contract, broad concurrency, platform generators, or uncertain
-  blast radius.
+The calculation is intentionally Standard-centered:
+
+- `fast`: one coherent, non-parallel unit in one actually modified repository, at most five
+  changed files, no explicit high-risk signal, and no public or cross-repository contract impact.
+  Small parameter changes, bounded field/mapping edits, and a few ordinary model files should
+  normally remain Fast.
+- `standard`: the default for ordinary business work. Multiple units/files, bounded compatibility
+  work, actual but contained multi-repository changes, broad low-risk work, and bounded high-risk
+  work remain Standard.
+- `strict`: requires both an explicit high-risk signal and concrete complexity/blast-radius
+  evidence. Complexity means actual multi-repository edits, at least four units, at least ten
+  changed files, or a public/cross-repository contract. Parallel execution is a Standard signal
+  by itself. Generic domain words in a risk description, title, file path, Spec repository
+  catalog, or unselected task are never sufficient evidence of high risk.
+
+Repository count comes only from repositories that own files in current plan units. Canonical
+Spec metadata, unselected tasks, dependency summaries, unused `repo_paths`, and supermodule child
+registrations do not raise the mode. A real multi-repository change is a Standard signal by
+itself and reaches Strict only when an explicit high-risk signal is also present.
 
 If configuration is concrete, it is also a floor. The selected mode may be raised by the user
-but never placed below either floor. Explain the decision and state-specific effects in the
-dev-spec.
+but never placed below either floor. The Agent must not raise an adaptive proposal to Strict from
+vague uncertainty or a domain keyword; cite both the explicit risk and the concrete complexity
+signal. Explain the decision and state-specific effects in the dev-spec.
 
 Persist the proposal before requesting ANALYSIS -> IMPLEMENT:
 

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-implementing/SKILL.md

@@ -47,6 +47,24 @@ Communicate with the user in the user's language.
    Describe the semantic meaning and, when relevant, units, format, allowed values, nullability,
    default behavior, or compatibility constraints. A type-level comment does not replace comments
    on its fields or members; do not add low-value comments to ordinary local variables.
+10. Treat the task card's `Local Baseline` as the default implementation shape. Match the nearest
+    comparable code's naming, control flow, null/empty and error handling, layering, object model,
+    and extraction granularity unless correctness, security, an explicit requirement, or a hard
+    project rule requires a deviation. Do not add defensive null checks solely because they are a
+    generic best practice when the evidenced local contract intentionally omits them.
+11. Implement the smallest coherent design. Do not add speculative abstractions, wrappers,
+    factories, layers, or extension points, and do not fragment one readable flow into many
+    single-use micro-methods. Extract code only for a clear semantic boundary, real reuse,
+    independent testability, or a material reduction in complexity.
+12. Literals and magic values are allowed when they are obvious, local, and consistent with the
+    surrounding code. Introduce a constant for repeated use, stable domain/config/protocol
+    semantics, or an established project convention—not merely to hold the single return value of
+    a getter.
+13. In a newly added core Java class, every method and field requires meaningful Javadoc. In an
+    existing core Java class, every added or materially modified method and field requires it.
+    Add focused inline comments to core or complex logic to explain intent, constraints, or
+    non-obvious tradeoffs. Do not mass-retrofit untouched legacy code, and for non-Java code
+    follow the language's doc-comment form plus the evidenced project convention.
 
 ## Choose the execution owner
 
@@ -92,6 +110,7 @@ Sub-agents never dispatch other sub-agents or read `.easy-coding` workflow asset
 ## Test Points    {unit.test_points and exact targeted commands}
 ## Contracts      {inputs, outputs, invariants shared with other units}
 ## Risks          {known edge cases and compatibility risks}
+## Local Baseline {nearest comparable code conventions and evidence paths}
 ## Code Comments  {resolved host Agent author value; model-field, enum-member, and constant rules}
 ## Coding Rules   {pre-digested RULES sections}
 ## Architecture   {pre-digested ABSTRACT sections}
@@ -110,11 +129,13 @@ deliverable|null, checks:[{command,passed,failures:[]}], issues:[], needs_attent
    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.
+   author value, the field/member/constant rules, and the core Java Javadoc rule above. Populate
+   `Local Baseline` from the Unit's analyzed evidence; sub-agents do not read this Skill.
 2. Execute according to dependency order and selected owner.
 3. Run targeted unit tests and self-audit scope, contracts, TODOs, and introduced warnings.
    Also audit new author attributions and every new model field, enum member, and constant against
-   the comment requirements above before recording success.
+   the comment requirements above, then check local-style deviations, unnecessary abstractions,
+   one-use constant extraction, and affected core Java Javadoc before recording success.
 4. Append one `result` record. Only a successful unit uses `status:"completed"`; include
    unresolved issues rather than hiding them, and do not advance while `issues` or
    `needs_attention` is non-empty.
@@ -150,6 +171,10 @@ conversation overhead while keeping work observable.
 - [ ] Every unit has a dispatch/result pair and satisfied its acceptance criteria.
 - [ ] Targeted tests ran or a concrete blocker is recorded.
 - [ ] Cross-unit contracts still match.
+- [ ] The implementation follows the evidenced Local Baseline or records a required deviation.
+- [ ] No speculative layer, fragmented micro-method set, or single-use getter constant was added.
 - [ ] New author attributions use the user-facing host `<Current Agent Name> with Easy Coding`.
 - [ ] Every new model field, enum member, and constant has a meaningful field-level comment.
+- [ ] Every method/field in a new core Java class, and every added or materially modified one in
+      an existing core Java class, has Javadoc.
 - [ ] Code tasks enter REVIEW, regardless of workflow mode.

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-reviewing/SKILL.md

@@ -12,7 +12,17 @@ Every new code task enters REVIEW. Read-only tasks do not. Obtain the current fi
 ```
 
 Review the final diff against `dev-spec.md`, RULES, unit acceptance criteria, tests, contracts,
-and obvious security risks. Every finding cites `file:line`.
+the Unit's Local Baseline, and obvious security risks. Every finding cites `file:line`.
+
+Review local fit before recommending generic cleanup. Flag an implementation when it departs from
+the nearest comparable naming, control flow, null/error handling, layering, modeling, or method
+granularity without a correctness, security, requirement, or hard-rule reason. Also flag
+speculative layers, fragmented one-use micro-methods, constants created only for one getter
+return, and missing Javadoc in core Java code: check every method/field in a new core class and
+each added or materially modified one in an existing core class. Do not demand defensive null
+checks, abstraction, constant extraction, or legacy-wide comment retrofits merely because they
+are generic best practices. A violation of an explicit task-card coding/comment contract is a
+contract defect, not optional stylistic advice.
 
 For Canonical-backed tasks, group evidence by `repo_id` and `source_task_id`. Every selected
 Spec task needs an implementation result and source test evidence; file references remain

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

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

@@ -18,7 +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.