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

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

@@ -9,6 +9,16 @@ Use only after ANALYSIS has frozen `task.json.workflow_mode` to `fast`, `standar
 `strict`. Read `dev-spec.md`, the latest `plan` record in `execution.jsonl`, relevant RULES
 and ABSTRACT sections, and `test-strategy.md` for code tasks.
 
+If frozen `task.tdd_enabled` is not `true`, preserve the existing shift-left behavior exactly;
+do not load the Java coverage tool, require RED/GREEN/REFACTOR, inspect CI, or run extra test
+commands. TDD is an independent opt-in mode, not an implicit consequence of strict workflow.
+
+When frozen TDD is enabled, every feature/bug unit must capture a meaningful failing unit test
+before production code (RED), the smallest passing implementation (GREEN), and a green refactor.
+Pure refactors instead capture a passing characterization test before the change and rerun it
+afterward. Never fake RED evidence. Keep tests deterministic, boundary-focused, and minimally
+mocked, and design changed production code toward 100% unit coverage.
+
 Communicate with the user in the user's language.
 
 ## Non-negotiable gates
@@ -26,6 +36,37 @@ Communicate with the user in the user's language.
    enters REVIEW.
 7. Read-only `doc` / `analysis` / `report` tasks remain `single` with `files:[]`, make no writes,
    return a non-empty `deliverable`, then follow the mode-aware IMPLEMENT -> COMPLETE edge.
+8. When a project template, local convention, or new source header uses author attribution, the
+   author value must be `<Current Agent Name> with Easy Coding`, for example
+   `Codex with Easy Coding`. `Current Agent Name` means the user-facing host Agent (for example,
+   Codex, Claude, or Qoder), never an implementation sub-agent role such as `ec-implementer`.
+   This value is display attribution only: never pass it to the workflow state API's `--agent`,
+   which accepts only `claude-code`, `codex`, or `qoder`. Never copy a previous human or Agent name
+   into newly authored code.
+9. Every newly added field in a data-bearing model must have a meaningful field-level comment.
+   This includes new or extended entity/DO/DTO/VO/BO, request/response, configuration, and similar
+   model types. Every new enum member and every new declared constant requires the same treatment.
+   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
 
@@ -59,6 +100,7 @@ Sub-agents never dispatch other sub-agents or read `.easy-coding` workflow asset
 # Task Card
 ## Identity       Easy Coding implementation unit
 ## Workflow Mode  {fast|standard|strict}
+## TDD            {off | on, frozen changed-line threshold N%}
 ## Task           {unit description}
 ## Source Spec    {spec_id@revision + sha256 | NONE}
 ## Source Task    {source_task_id | NONE}
@@ -70,26 +112,49 @@ 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}
 ## Output
 status:"completed", repo_id|null, source_task_id|null, changed_files[], summary,
-deliverable|null, issues:[], needs_attention:[]
+deliverable|null, checks:[{command,passed,failures:[]}], issues:[], needs_attention:[]
 ```
 
 ## Dispatch and result loop
 
 1. Append a `dispatch` record before work begins. Canonical-backed records include `repo_id` and
    `source_task_id`; resolve every file relative to `task.repo_paths[repo_id]` before dispatch.
+   Before dispatching a selected task that is not already `in_progress`, call
+   `writeback-spec-task --status in_progress` with a key stable for that dispatch/recovery
+   attempt but distinct from any earlier accepted `in_progress` event. Do this only after its
+   hard/contract dependencies are ready; do not batch-start dependent tasks at the initial
+   IMPLEMENT boundary.
+   Populate `Code Comments` on every code task card with the resolved user-facing host Agent
+   author value, 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, 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.
+   For Canonical-backed success, write each owned source Step `completed` through
+   `writeback-spec-step`, with passed evidence for every bound Canonical Test ID and a stable key.
+   After every source Step for that task is complete, write the task `implemented`. On failure,
+   write the affected Step `failed`; the shared writer moves its task to `blocked`. Local evidence
+   is appended first, shared projection second, and the returned acknowledgment last.
 5. If a result changes a cross-unit contract, stop dependent units and return to ANALYSIS.
 6. For parallel units, detect overlapping writes before advancing.
 7. If implementation needs a file, symbol, repository, or source step outside the mapped
    Canonical change set, stop and return to ANALYSIS instead of expanding scope implicitly.
+8. If a static Canonical change is confirmed, revise the original design by exactly one revision
+   and use `sync-spec-design`; never edit the machine-owned execution block. If a writeback was
+   interrupted, run `reconcile-spec-execution` with the stored idempotent pending action.
+   Reconciliation only consumes dispatch/result evidence created after the current `in_progress`
+   acknowledgment; it never opens a new repair attempt or reuses an earlier attempt's result.
 
 Do not emit a progress message for every trivial edit. Report at unit boundaries to reduce
 conversation overhead while keeping work observable.
@@ -108,4 +173,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

@@ -3,10 +3,17 @@ name: ec-memory
 description: MEMORY-stage skill. Creates a workflow-mode-aware schema-v2 checkpoint from existing task evidence and performs conditional long-memory distillation.
 ---
 
-# ec-memory — evidence-derived checkpoint
+# ec-memory — evidence-derived checkpoint and knowledge governance
 
-MEMORY remains mandatory for code tasks. It must not re-analyze the repository or repeat the
-entire conversation. Generate from `task.json`, `dev-spec.md`, and `execution.jsonl`.
+MEMORY remains mandatory for code tasks. Daily task processing and architecture maintenance are
+separate responsibilities: every completed code task produces one immutable short-memory fact;
+only a long-memory distillation, or the explicit missing-ABSTRACT startup exception, may open an
+architecture assessment. Never update architecture merely because MEMORY was entered.
+
+The short-memory checkpoint must not re-analyze the repository or repeat the entire conversation.
+Generate it only from the verified evidence already stored in `task.json`, `dev-spec.md`, and
+`execution.jsonl`. The bounded repository reads described below belong only to a required
+`backfill` or `update` architecture assessment.
 
 ## Depth by workflow mode
 
@@ -28,9 +35,76 @@ 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
+tasks incur no additional memory work.
+
 Ask the state API for `memory-instruction`. Distill only when it returns `action:distill`;
 otherwise record `no-op`. Long memory receives reusable facts only, not file dumps, transient
 logs, routine command output, or speculation.
 
+## Architecture assessment
+
+Read the frozen `architecture_assessment` contract returned by `memory-instruction`.
+
+- `required:false`: do not read the repository for architecture purposes and do not modify
+  `.easy-coding/ABSTRACT.md` or `.easy-coding/CHANGELOG.md`.
+- `trigger:distillation`: finish classifying the frozen `candidate_files`, then assess whether
+  their stable, reusable facts make the current architecture cognition stale. Default to
+  `no-op`.
+- `trigger:missing-abstract`: use `backfill` after the first substantive startup task even when
+  long-memory action is `no-op`. This is the only non-distillation architecture exception.
+
+An architecture `update` is justified only by evidence of at least one of these changes:
+
+- a module was added, removed, split, or merged;
+- module responsibility, ownership, or dependency direction changed;
+- a core request, data, state, or event flow changed;
+- the technology stack, runtime, build, or deployment infrastructure changed;
+- the existing ABSTRACT conflicts with verified current facts.
+
+Do not update for a bug fix, local implementation detail, DTO/field-only change, local refactor,
+temporary workaround, routine dependency patch, or the mere fact that distillation ran. Stable
+new coding conventions belong in `TECHNICAL.md` as explicit RULES update candidates; never
+silently edit `RULES.md`, `SOUL.md`, or `TEST_STRATEGY.md` from MEMORY.
+
+For `no-op`, use only the frozen memory evidence and give a concrete reason. For `backfill` or
+`update`, read only candidate-related modules, entrypoints, dependencies, and affected ABSTRACT
+sections. Do not perform an unbounded repository re-analysis. Create or edit only the affected
+sections of `.easy-coding/ABSTRACT.md`, and create or append `.easy-coding/CHANGELOG.md`; never
+regenerate the whole ABSTRACT when a bounded edit is sufficient.
+
+Whenever `required:true`, record the decision through the command below. For distillation this
+must succeed before deleting any candidate; for `missing-abstract` it must succeed before the
+`no-op` long-memory action can complete:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py memory-architecture-assessment \
+  --session-file <P> --action <no-op|backfill|update> --reason <reason> \
+  --evidence <frozen-memory-file> [--evidence <frozen-memory-file> ...] \
+  [--affected-section <section> ...] --agent <agent-id>
+```
+
+`backfill` and `update` require affected sections; `no-op` must not declare them. Evidence must
+come from the frozen candidate set, or from the current checkpoint for the missing-ABSTRACT
+exception. If assessment or architecture-file validation fails, keep every candidate file and
+remain in MEMORY.
+
+After the assessment succeeds, a distillation may delete all frozen `candidate_files` while
+preserving every `kept_file`. Then call `memory-complete`. The state API rechecks that no-op
+assets stayed unchanged, changed assets still match the recorded assessment, all candidates were
+consumed, and all retained memories still exist.
+
 Complete processing with `memory-complete`. When the state API reports
 `memory_progress.completed:true`, call `auto-transition --stage COMPLETE`.
+For Canonical-backed tasks this automatic edge first writes every verified selected source task
+to shared `completed`; pending integration dependencies or failed writeback keep the task in
+MEMORY. Do not claim COMPLETE from local memory state alone.

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

@@ -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
@@ -21,6 +31,14 @@ a blocking correctness finding. Every Canonical review record includes its `repo
 `source_task_id`; emit at least one current-fingerprint record per selected task and required
 review dimension. A global record without source ownership cannot satisfy the gate.
 
+When frozen TDD is enabled, add a passed review dimension named exactly `tdd` for each source
+task. Review whether RED/GREEN/REFACTOR (or characterization GREEN for pure refactors) is genuine,
+tests exercise changed behavior and boundaries, mocks do not merely mirror implementation, and
+the local unit-test command genuinely passes while the changed-line coverage command uses the
+frozen baseline and threshold. Generated CI configuration may be reviewed when it changed, but
+remote CI status is never a review or acceptance dependency. When TDD is off, do not add this
+dimension or raise the ordinary review depth.
+
 ## Depth by workflow mode
 
 - `fast`: main Agent performs one final-diff self-review across correctness, scope, tests, and
@@ -61,6 +79,12 @@ Verdict:
 In-scope defects are fixed automatically. Ask the user only for a new design choice, changed
 public contract, or contradiction with a confirmed decision.
 
+For Canonical-backed review, append the local review record first. Any blocking finding then
+writes the owning source task `blocked` through `writeback-spec-task`, referencing the local
+record. A passed review does not change shared task status. A `replan` verdict returns to ANALYSIS;
+confirmed static Spec changes use revision + READY + `sync-spec-design` rather than edits to the
+derived plan or machine execution block.
+
 ## Evidence record
 
 Append one final record per executed dimension for the current implementation fingerprint.

package/templates/common/skills/ec-task-close/SKILL.md

@@ -22,6 +22,9 @@ when you recognize abandonment intent in the user's message.
    `{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py close-current --session-file <P> --reason "<reason>" --agent <agent-id>`.
    This sets `task.json.status` to `CLOSED`, records `closed_reason`, updates history, and
    clears session `current_task` so the next hook injection returns to Ready.
+   For Canonical-backed work, the same command first projects every unfinished selected task to
+   shared `cancelled` (using an intermediate `blocked` transition when required). A shared writer
+   failure leaves the Harness task open; never close only the local side.
    Use the returned `status_context` as the authoritative status source for the rest of the
    current turn.
 4. **No memory flow.** Do not run MEMORY. An incomplete task's memory is dirty data.
@@ -34,6 +37,7 @@ when you recognize abandonment intent in the user's message.
 
 - Never delete task folders — CLOSED tasks stay as a record.
 - Never run the memory/archive flow.
+- Never hand-edit the Canonical execution region to force cancellation.
 - This skill closes the `current_task`. If the user wants to close a different (suspended)
   task, they should first switch to it via ec-workflow, then invoke ec-task-close.
 - Division of labor: ec-task-management lists/creates (read-only panel), ec-workflow runs the

package/templates/common/skills/ec-task-management/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: ec-task-management
-description: View and manage Easy Coding tasks plus project/session approval and workflow-mode settings.
+description: View and manage Easy Coding task lifecycle, ownership, handoff, and closure.
 ---
 
-# ec-task-management — tasks and session modes
+# ec-task-management — task lifecycle
 
 Communicate with the user in the user's language. A bare invocation is read-only: show the
 panel and available actions, but do not mutate a session without an explicit choice.
@@ -13,47 +13,28 @@ panel and available actions, but do not mutate a session without an explicit cho
 Call the state API snapshot and show:
 
 - current task, stage, last Agent, and pending transition;
-- `project_approval_mode`, `session_approval_mode`, `effective_approval_mode`;
-- `project_workflow_mode`, `session_workflow_mode`, `configured_workflow_mode`;
-- task `concrete_workflow_mode` or ANALYSIS proposal when present;
+- task `concrete_workflow_mode` and frozen TDD state when present;
 - harness enabled/disabled state;
 - active and resumable tasks.
-- for Canonical-backed tasks: source Spec ID/revision/SHA, selected task IDs, repository
+- for Canonical-backed tasks: source locator/path mode, Spec ID/design revision/design digest,
+  document digest, execution revision, writeback status, selected task IDs, repository
   bindings/baseline status, and pending dependency evidence.
 
-Explain precedence:
-
-`session override > project config > approval:guard / workflow:adaptive`
-
-## Session settings
-
-After explicit user selection:
-
-```bash
-# approval
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-approval-mode --mode approve|guard|confirm|auto --agent <agent-id> --session-file <P>
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-approval-mode --agent <agent-id> --session-file <P>
-
-# workflow
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-workflow-mode --mode adaptive|fast|standard|strict --agent <agent-id> --session-file <P>
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-workflow-mode --agent <agent-id> --session-file <P>
-```
-
-Changing a session setting affects future ANALYSIS proposals. It does not silently rewrite a
-mode already frozen on an active task. During ANALYSIS, regenerate and show the proposal. During
-IMPLEMENT or REVIEW, use `raise-workflow-mode` for a justified increase; lowering is forbidden.
-From VERIFICATION, return to IMPLEMENT first so the raised mode receives fresh REVIEW evidence.
-
-Project settings are changed with `easy-coding config`, which edits both dimensions in one
-confirmed interaction.
+Mode inspection and configuration belongs to `ec-config`. If the user asks to change Approval,
+Workflow, TDD, or the TDD coverage threshold, route there and do not mutate those fields here.
 
 ## Task actions
 
 Support listing, creating, selecting, claiming, handing off, and closing tasks through the
-state API. Preserve pending transitions when merely changing approval mode. Never infer user
+state API. Preserve pending transitions when inspecting tasks. Never infer user
 acceptance from opening this panel.
 
 When creating from a Canonical Spec, call `inspect-dev-spec`, display the complete task and
 dependency selection, then call `select-dev-spec-scope` and `create-task-from-spec` only after
 explicit user selection. Multiple selected Spec tasks still create one Harness task, while the
 selector returns one deterministic consumption closure per selected repository.
+Initialize missing shared execution before creation. Support `rebind-spec-source` only when the
+new file matches schema + spec_id + design revision + design_sha256 and does not roll execution
+revision backward. A pending writeback is repaired with `reconcile-spec-execution`, never by
+editing the execution JSON block or starting a different writeback. A deterministic rejected
+action is cleared with `status:error`; correct its input instead of replaying it.

package/templates/common/skills/ec-tdd-init/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: ec-tdd-init
+description: Initialize or refresh Java changed-line TDD coverage infrastructure before TDD can be enabled.
+---
+
+# ec-tdd-init — Java changed-line gate initialization
+
+Communicate in the user's language. This skill owns TDD infrastructure readiness, not historical
+test-debt cleanup. It must never bulk-generate tests for existing business code, require
+repository-wide coverage, or modify production behavior merely to raise coverage.
+
+## Non-circular ordering
+
+The only legal order is:
+
+```text
+TDD off -> initialize infrastructure -> readiness ready -> user explicitly enables TDD
+```
+
+Run this skill as a dedicated code task with `type=tdd-init`. The state API always freezes that
+task with `tdd_enabled=false`, even when a legacy project/session setting or a suspended task has
+TDD enabled. Never offer "enable now and initialize later". Never enable TDD automatically after
+initialization.
+
+## Read-only preflight
+
+First run:
+
+```bash
+python3 .easy-coding/tools/easy_coding_tdd_readiness.py --cwd . check
+```
+
+If it returns `ready`, report the recorded build/CI contract and stop without creating a task.
+The user may then use `ec-config` or `easy-coding config` to enable TDD.
+
+If it returns `needs_init`, inspect only the infrastructure needed to form a confirmed plan:
+
+- Maven/Gradle files and the existing JUnit runner;
+- JaCoCo XML generation configuration;
+- `.gitlab-ci.yml` and its repository-local include chain;
+- TEST-stage job, JUnit/JaCoCo artifacts, and invocation of
+  `.easy-coding/tools/easy_coding_java_coverage.py` with task-supplied baseline/threshold values.
+
+Do not measure current whole-project coverage. A project with no historical business tests may
+still become ready when the test runner, JaCoCo reporting, and parameterized changed-line gate
+are functional.
+
+## Initialization task
+
+After the user confirms the exact infrastructure scope, create one task and route it through the
+ordinary workflow:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py create-task \
+  --task-id <safe-unique-id> --type tdd-init \
+  --title "Initialize Java changed-line TDD infrastructure" \
+  --agent <agent-id> --session-file <P>
+```
+
+ANALYSIS may plan build files, GitLab CI files, common scripts, and the readiness receipt. It must
+state `historical coverage required: no` and `coverage scope: changed production lines since each
+future task baseline`. IMPLEMENT changes infrastructure only. It must not add tests whose sole
+purpose is to cover unchanged production code.
+
+The reusable GitLab job must consume a baseline SHA and threshold supplied for the future task;
+do not hardcode the initialization commit or the default 90% threshold. The same Python coverage
+tool must be usable locally and remotely. This generated job is remote automation infrastructure,
+not a Harness task acceptance dependency: later tasks require local unit-test and coverage
+evidence only, and never wait for a pipeline URL, job identity, or remote success status.
+
+## Readiness receipt and verification
+
+At the end of IMPLEMENT, after the infrastructure files are stable, record their fingerprints.
+The receipt is part of the implementation and must exist before REVIEW so review/verification
+fingerprints do not change after review. The recorder automatically includes the harness-managed
+`.easy-coding/tools/easy_coding_java_coverage.py` fingerprint:
+
+```bash
+python3 .easy-coding/tools/easy_coding_tdd_readiness.py --cwd . record \
+  --build-file <pom.xml-or-build.gradle> [--build-file <included-build-file>]... \
+  --ci-file .gitlab-ci.yml [--ci-file <repository-local-include>]... \
+  --coverage-report <jacoco-xml-pattern> [--coverage-report <pattern>]... \
+  --gate-command "python3 .easy-coding/tools/easy_coding_java_coverage.py check --base \$EASY_CODING_TDD_BASE_SHA --threshold \$EASY_CODING_TDD_THRESHOLD" \
+  --agent <agent-id>
+```
+
+REVIEW includes the receipt and its declared infrastructure boundary. VERIFICATION runs the
+frozen Workflow Mode's applicable build/test/CI syntax checks, then performs only the read-only
+readiness check:
+
+```bash
+python3 .easy-coding/tools/easy_coding_tdd_readiness.py --cwd . check
+```
+
+The `VERIFICATION -> MEMORY` gate requires the final check to return `ready`. If any recorded
+build or CI file changes after the receipt was created, readiness becomes `needs_init`; return to
+IMPLEMENT, refresh the receipt, and repeat REVIEW before verifying again. Rerun this skill when
+the same drift occurs after task completion.
+
+After completion, tell the user that TDD remains off and provide the explicit project/session
+enable route. Do not treat readiness as consent to enable it.

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
@@ -25,6 +26,29 @@ Read-only tasks never enter this stage. Obtain fresh fingerprints before running
 - `standard`: run impacted lint/typecheck/test scopes and every must-test item.
 - `strict`: run the project's full applicable lint, typecheck, test, and build gates.
 
+These rules remain unchanged when frozen TDD is off: do not discover JaCoCo reports, run the
+coverage tool, inspect GitLab, or add a coverage record. The explicit `type=tdd-init` task is an
+infrastructure exception: run its planned build/CI syntax checks and readiness tool, but do not
+measure repository-wide coverage or append TDD coverage evidence for unchanged production code.
+
+When frozen TDD is on, first run the planned local Java unit command and generate JaCoCo XML,
+then run the deterministic local acceptance gate:
+
+```bash
+python3 .easy-coding/tools/easy_coding_java_coverage.py check \
+  --base <task.tdd_baselines[repo-id-or-project]> \
+  --threshold <task.tdd_coverage_threshold> [--report <jacoco.xml>]...
+```
+
+The tool measures covered added/modified production Java executable lines only. Deleted,
+comment, blank, import, and test-source lines are excluded by diff/JaCoCo intersection. Missing
+or ambiguous source files and reports older than their modified source fail; zero modified
+executable lines is explicit N/A. Always regenerate JaCoCo XML after the final source change.
+Never substitute `HEAD`, a mutable ref, project defaults, or current session settings for the
+task-frozen baseline SHA and threshold. `ec-tdd-init` still generates a GitLab job that can run
+the same tool, but remote pipeline execution and status are outside Harness acceptance. Never
+request an intermediate commit or push merely to obtain CI evidence.
+
 The main Agent may run commands inline. Dispatch verifier sub-agents only when checks are
 independent and parallel execution materially saves time or isolates specialist environments.
 Platform spawn rule: {{platform_spawn_instruction}}
@@ -48,16 +72,36 @@ Append one record per executed check:
 }
 ```
 
-`check_type` is one of `lint`, `typecheck`, `test`, or `build`. In `strict`, append current
+`check_type` is one of `lint`, `typecheck`, `test`, `build`, or (TDD only) `coverage`. In `strict`, append current
 evidence for all four types. When a type genuinely does not apply, record `applicable: false`
 and a non-empty `not_applicable_reason`; it does not count as the required applicable executed
 check, and must not be represented by an invented successful command.
 
 Record failures in `failures[]`. If any current-fingerprint record fails, return to IMPLEMENT;
-do not append a later synthetic pass without rerunning the failed command.
+do not append a later synthetic pass without rerunning the failed command. For a Canonical-backed
+failure, append the local verify record first, then write the owning source task `blocked` with a
+concise reference to that record. The repair transition automatically reopens blocked source tasks
+only; unaffected implemented tasks retain their latest shared conclusion.
 
 ## Coverage and acceptance
 
+For TDD coverage, copy the tool output into `coverage`: `baseline_sha`, `covered_lines`,
+`total_lines`, `percentage`, frozen `threshold`, `report_paths`, and `report_sha256`. Set
+`applicable:false` plus the tool's reason only for zero executable modified lines. A percentage
+below the frozen threshold fails even when ordinary tests pass.
+
+Append one coverage record with `coverage_scope:"local"` per repository (and per Canonical
+source task). The state gate also requires a passed local `check_type:"test"` record for the same
+owner. The coverage record preserves the task-frozen baseline and threshold. Do not append or
+wait for GitLab pipeline evidence; historical remote coverage records are ignored by acceptance
+without modifying or deleting the stored records.
+
+For `type=tdd-init`, the infrastructure receipt must already have been recorded during IMPLEMENT
+and reviewed with the rest of the implementation. Run only `easy_coding_tdd_readiness.py check`
+here. If it reports drift, return to IMPLEMENT to refresh the receipt and repeat REVIEW; never
+rewrite it inside VERIFICATION. The state gate requires `ready` before MEMORY. This does not
+enable TDD; report the explicit `ec-config`/`easy-coding config` next step.
+
 - Every must-test item has an executed check.
 - Bug fixes include a regression test when project infrastructure exists.
 - Present changed scope, commands, results, and unverified items.
@@ -66,6 +110,38 @@ do not append a later synthetic pass without rerunning the failed command.
   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
@@ -76,6 +152,16 @@ 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 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:
 
 ```bash
@@ -87,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.