easy-coding-harness 1.1.0-beta.0 → 1.1.0-beta.2

package/package.json

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

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

@@ -85,7 +85,7 @@ initialization standard. Check each item:
   and non-empty?
 - **Project profile**: `project.yaml` exists with `mode` and `test` fields (ec-init owns it;
   `config.yaml` is CLI-owned — not ec-init's concern)?
-- **TDD runtime contract**: CLI-owned `config.yaml` has schema 5 TDD defaults and both
+- **TDD runtime contract**: CLI-owned `config.yaml` has schema 6 unit test defaults and both
   `.easy-coding/tools/easy_coding_java_coverage.py` and
   `.easy-coding/tools/easy_coding_tdd_readiness.py` exist? Missing fields or tools mean
   `easy-coding upgrade` is required; ec-init must not repair them directly. Project-specific
@@ -169,7 +169,7 @@ agent must be able to see what was generated and on what evidence.
    tests live, naming conventions, coverage expectations, which classes of code this project
    tests vs skips. Also fill `project.yaml` `test.framework` and `test.command` with commands
    you verified exist (read package.json scripts or equivalent — do not guess).
-   If effective TDD is disabled, do not inspect JaCoCo or GitLab and do not add TDD-specific
+   If effective unit test strategy is `none`, do not inspect JaCoCo or GitLab and do not add TDD-specific
    requirements. If it is enabled for Java, additionally document JUnit/JaCoCo commands,
    production/test source roots, XML report paths, the local acceptance gate, and the generated
    GitLab TEST-stage job as non-blocking automation infrastructure.

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

@@ -63,12 +63,12 @@ confirmation before a minimal mutation, creates no task/QUALITY/MEMORY artifacts
 until the user invokes it again. If a task is active, the user chooses whether to cancel startup,
 close the task, or clear only the session task pointer before Lite starts.
 
-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
-(default 90) on entry to IMPLEMENT. Disabled TDD changes no ordinary workflow test depth. Enabled
-TDD adds lifecycle evidence, a TDD review dimension, passed local unit-test evidence, and a local
-JaCoCo diff gate. `ec-tdd-init` still generates the equivalent GitLab TEST-stage job, but remote
-pipeline execution and status are not Harness acceptance dependencies.
+Java unit tests use an independent `unit_test_mode: none|ut|tdd` managed by `ec-config`.
+Session values override project defaults. Both UT and TDD freeze the shared `ut_coverage_threshold`
+(default 90) and repository baseline on entry to IMPLEMENT, and require passed local unit tests
+plus JaCoCo changed-line coverage. UT has no test-first or separate TDD-review requirement; TDD
+adds lifecycle evidence and its review dimension. Both reuse `ec-tdd-init` infrastructure.
+Remote GitLab execution is not a task acceptance gate.
 
 The active task pointer lives in `sessions/{agent}-{session-id}.json` (with an agent-prefixed PPID fallback only
 when a hook payload has no logical session ID);

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

@@ -6,7 +6,8 @@ description: ANALYSIS-stage skill. Produces the confirmed dev-spec, execution pl
 # ec-analysis — progressive analysis and mode selection
 
 This stage is read-only for project source. Its outputs are task artifacts only:
-`dev-spec.md`, `execution.jsonl` plan, and `test-strategy.md` for code tasks.
+`dev-spec.md`, `execution.jsonl` plan, and `test-strategy.md` when required by the concrete mode.
+Compact Fast keeps checks in the existing plan.
 
 Communicate with the user in the user's language.
 
@@ -24,7 +25,8 @@ Communicate with the user in the user's language.
 Load context only for the current change and its direct dependencies. Reuse existing findings;
 without new evidence, do not repeat discovery or expand into unrelated modules.
 
-For a task with `task.json.spec_source`, use `resume-spec-context` against the stored source, exact
+For a task with `task.json.spec_source`, reuse the returned/current-session consumption closure.
+Only if missing or changed, use `resume-spec-context` 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
 normal shared progress; refresh `execution_revision` without invalidating plan/QUALITY
@@ -153,47 +155,36 @@ for truly independent write scopes. Better unit contracts reduce later QUALITY r
 Standard/Strict tasks require `test-strategy.md`; compact Fast tasks keep checks in the plan. Pure read-only
 conversation never enters ANALYSIS and creates no task.
 
-## Optional Java TDD analysis
-
-Read `effective_tdd_enabled` and `effective_tdd_coverage_threshold` from the state snapshot.
-For a `type=tdd-init` task, treat frozen TDD as off even if the project/session requests it. That
-task is the sole exception allowed to inspect and plan build/CI coverage infrastructure while TDD
-is off. Its scope is infrastructure only: never plan historical business-test backfill or a
-repository-wide coverage target, and explicitly record `coverage scope: changed production lines`.
-
-When TDD is disabled, stop here: do not inspect GitLab CI or JaCoCo, do not add TDD fields or
-extra tests, and do not strengthen the selected Workflow Mode's ordinary acceptance depth. This
-zero-cost rule applies to ordinary tasks, not the explicit `tdd-init` infrastructure task above.
-
-When TDD is enabled for a Java code task, make `test-strategy.md` record:
-
-- detected Java/JUnit build system, exact unit-test command, production/test source roots, and
-  JaCoCo XML paths;
-- immutable Git baseline SHA and the configured changed-production-line threshold; meet that threshold without adding assertions or tests solely to reach 100%;
-- feature/bug RED -> GREEN -> REFACTOR evidence, or for pure refactors a pre-change
-  characterization GREEN -> post-change GREEN sequence without inventing a RED failure;
-- the local unit-test command and local changed-line acceptance command. Record that
-  `ec-tdd-init` generated the GitLab TEST-stage job, but remote execution, pipeline identity, and
-  status are non-blocking and never require an intermediate commit or push. Include these exact,
-  language-independent contract markers: `local_test_gate: required` and
-  `remote_ci_acceptance: non-blocking`.
-- current `tdd_readiness_status=ready`; a missing receipt requires `ec-tdd-init`, while
-  `needs_repair` requires fixing the reported entry without resetting TDD configuration.
-  Build-file content changes use current task tests and coverage; they do not require reinit.
-
-The state API mechanically freezes current Git `HEAD` per repository into `task.tdd_baselines`
-when ANALYSIS advances to IMPLEMENT. Plan the local command with that exact SHA and the frozen
-threshold. The generated GitLab job remains parameterized for infrastructure parity, but the
-Harness acceptance plan never waits for remote CI. Never use a mutable `HEAD` fallback at
-verification time. Non-Canonical TDD is limited to one Git repository; multi-repository TDD must
-use Canonical repository bindings.
-
-Also append a `### TDD Mode` section to `dev-spec.md` with enabled state, frozen threshold,
-baseline, local unit-test gate, local coverage gate, generated GitLab job as non-blocking
-infrastructure, and lifecycle evidence. Do not add this section when TDD is disabled.
-
-If the task is not a Java project, explain that Java-only TDD cannot be activated and obtain a
-mode decision before advancing. The CLI never installs JaCoCo or edits CI automatically.
+## Optional Java unit test strategies
+
+Read `effective_unit_test_mode` and `effective_ut_coverage_threshold` from the snapshot. The
+strategy is independent of workflow depth. For `type=tdd-init`, freeze strategy `none` and only
+initialize the existing changed-line infrastructure; do not backfill historical business tests.
+
+With `none`, retain ordinary task-required verification and add no coverage scan, command, or
+artifact. With `ut` or `tdd`, reuse the existing Java/JUnit/JaCoCo readiness. Missing infrastructure
+uses `ec-tdd-init`; damaged local entries need only the reported repair. Build-file changes alone
+do not require reinitialization. GitLab execution is not an acceptance dependency.
+
+For UT, keep the normal compact Fast analysis when applicable. Record the related unit-test
+command with coverage collection and the changed-line gate command in the plan for compact Fast,
+or in the existing `test-strategy.md` for other tasks, using the
+confirmed `ut_coverage_threshold`. The state API freezes each repository's current Git HEAD in
+`task.tdd_baselines`; use that exact baseline at verification time. Do not duplicate these values
+across extra documents or add a UT Mode section. No RED/GREEN/REFACTOR evidence or TDD review is
+required. Existing tests may already satisfy the threshold; add tests only for relevant gaps.
+
+For TDD, also record the existing test-first contract in `test-strategy.md` and a `### TDD Mode`
+section in `dev-spec.md`: frozen threshold, immutable baseline per repository, local unit-test
+command, JaCoCo XML paths, and lifecycle evidence. Use RED -> GREEN -> REFACTOR for feature/bug
+units, or characterization GREEN -> post-change GREEN for pure refactors. Refactor only for a
+concrete improvement. Include `TDD`, `JaCoCo`, `baseline`, `local_test_gate: required`, and
+`remote_ci_acceptance: non-blocking` in the test strategy.
+
+Both strategies accept changed production lines at the configured threshold, without chasing
+100% or expanding to historical coverage. One grouped test execution supplies both test and
+coverage evidence. Non-Canonical coverage uses one Git repository; multi-repository coverage uses
+Canonical repository bindings. Preserve failed tests as failures even when coverage reaches target.
 
 ## Workflow mode calculation
 

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

@@ -1,6 +1,6 @@
 ---
 name: ec-config
-description: Inspect and configure Easy Coding project/session Approval, Workflow, and Java TDD modes.
+description: Inspect and configure Easy Coding project/session Approval, cooperation, and Java unit test strategies across session, local and project scopes.
 ---
 
 # ec-config — mode configuration
@@ -10,68 +10,87 @@ and available actions. Never mutate project or session settings without an expli
 
 ## Configuration panel
 
-Call `snapshot` and show project, session, effective, and frozen task values for:
+Call `snapshot` and show project, session, effective, and frozen task values for `approval_mode`, `cooperate_mode`,
+the mechanically calculated workflow mode (read-only), `unit_test_mode`, and `ut_coverage_threshold`.
+Show `behavior_sources`, `local_behavior`, and `effective_cooperate_mode` alongside the current
+task cooperation/continuation so a receiving Agent can distinguish its defaults from accepted work.
+Use `project_unit_test_mode`, `session_unit_test_mode`, `effective_unit_test_mode`, their threshold
+counterparts, `task_unit_test_mode`, `task_tdd_baselines`, and `unit_test_readiness_status` directly.
+When readiness is `not_checked`, report it as not checked; do not scan infrastructure merely to
+populate the panel. Inspect readiness when the user requests it or selects UT/TDD.
+
+Precedence is `session override > ~/.easy-coding/config.yaml > project config > defaults`, per field. Defaults are Approval `guard`,
+Workflow `adaptive`, cooperation `default`, unit test strategy `none`, and shared changed-line coverage threshold 90%.
+The strategies are:
+
+- `none`: ordinary task-required verification, with no additional coverage gate.
+- `ut`: passed local unit tests and changed-production-line JaCoCo coverage at the threshold.
+  No test-first order, RED/GREEN history, refactor cycle, or separate TDD review is required.
+- `tdd`: test-first development plus the same local test and coverage gates; retain TDD lifecycle
+  evidence and the TDD review dimension.
+
+UT/TDD currently apply to Java code tasks. Neither strategy raises the mechanical workflow depth.
+ANALYSIS -> IMPLEMENT freezes strategy, threshold, and repository baselines; later project/session
+changes affect future tasks and ANALYSIS only. `none` preserves the threshold for later use.
 
-- `approval_mode`;
-- the mechanically calculated workflow mode (read-only);
-- `tdd_enabled` and `tdd_coverage_threshold`.
+Approval semantics stay independent from verification depth: `approve` waits at each
+non-mechanical edge, `guard` waits at ANALYSIS -> IMPLEMENT and QUALITY -> MEMORY, `confirm`
+waits only for the plan, and `auto` advances legal green edges immediately. A new code diff after
+the QUALITY checkpoint requires acceptance of that exact diff without changing the approval mode.
 
-Use the returned fields directly, including `project_tdd_enabled`, `session_tdd_enabled`,
-`effective_tdd_enabled`, their threshold counterparts, `task_tdd_enabled`, and the task's
-per-repository `task_tdd_baselines` frozen state. When `tdd_readiness_status=not_checked` because
-TDD is off, explicitly run the read-only readiness command below before showing readiness:
+## Cooperation and configuration scopes
 
-```bash
-python3 .easy-coding/tools/easy_coding_tdd_readiness.py --cwd . check
-```
+`cooperate_mode: default | dispatch` selects stage-boundary handoff or manual implementation/repair
+handoff. In dispatch, the coordinator analyzes, verifies and writes memory; the user may choose
+current-Agent execution for any bounded change. Never launch or schedule another Agent.
+One decision approves the displayed scope and its executor. Dispatch requires this human decision
+even under Auto; Approve consumes it as the same approval, not a second dialog. Existing accepted
+handoffs and frozen UT/TDD contracts survive changes to defaults.
 
-This explicit configuration-panel check is the only disabled-mode readiness scan; ordinary hooks
-must not inspect build or CI files while TDD is off.
+The local file is optional. Read-only inspection and init/upgrade never create it. Save only explicit
+keys under `behavior`; resetting a key removes that override. Local settings are preferences across
+projects and platforms, so saving local UT/TDD does not scan or initialize the current project.
+Readiness is checked when a task actually enables that strategy.
 
-Explain precedence as `session override > project config > defaults`. Defaults are Approval
-`guard`, Workflow `adaptive`, TDD disabled, and TDD changed-line coverage threshold 90%. An active
-task freezes its effective TDD values when ANALYSIS advances to IMPLEMENT; later project/session
-changes affect future tasks and ANALYSIS only.
+After the user chooses scope and values, use these commands (the explicit choice authorizes `--yes`):
 
-Approval semantics stay independent from verification depth: `approve` waits at each
-non-mechanical edge, `guard` waits at ANALYSIS -> IMPLEMENT and QUALITY -> 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 QUALITY checkpoint, because the user must see
-and accept that exact new diff; this exception does not convert `auto` into `guard`.
+```bash
+easy-coding config --scope local --cooperate-mode dispatch --yes
+easy-coding config --scope project --cooperate-mode default --yes
+easy-coding config --scope local --reset cooperate_mode --yes
+```
+
+The same scopes support `--approval-mode`, `--unit-test-mode`, and `--ut-coverage-threshold`.
+For a session, call `set-cooperate-mode --mode default|dispatch` or `clear-cooperate-mode`
+with the current state API, agent and session file. Bare `ec-config` remains read-only.
 
 ## Project configuration
 
-Use `easy-coding config` for project settings. The CLI confirms one atomic update of Approval,
-TDD, and (when enabled) the threshold. Execution depth is calculated automatically. The threshold must be an integer from 1 to 100.
-Enabling TDD is rejected atomically unless `ec-tdd-init` readiness is currently `ready`.
+Use `easy-coding config`. The CLI confirms an atomic update of Approval, unit test strategy, and
+its shared threshold (integer 1..100). Execution depth remains calculated automatically.
 
 ## Session configuration
 
 After explicit user selection, use the current logical session file:
 
 ```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>
 
-# TDD; omitting threshold preserves an existing session threshold, otherwise project/default 90 applies
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-tdd --enabled true|false [--threshold 1..100] --agent <agent-id> --session-file <P>
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-tdd --agent <agent-id> --session-file <P>
+# Omitting threshold preserves the session threshold or inherits local/project/default 90.
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-unit-test-mode --mode none|ut|tdd [--threshold 1..100] --agent <agent-id> --session-file <P>
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-unit-test-mode --agent <agent-id> --session-file <P>
 ```
 
-Turning TDD off must preserve the existing Fast/Standard/Strict test depth exactly: do not inspect
-CI, request JaCoCo, add TDD artifacts, run coverage commands, or strengthen acceptance criteria.
-When TDD is on, explain that it applies only to Java code tasks and activates RED/GREEN/REFACTOR,
-TDD review, a passed local unit-test gate, and local changed-line JaCoCo coverage. `ec-tdd-init`
-still generates the GitLab TEST-stage job, but Harness does not wait for or record remote pipeline
-results as acceptance evidence.
-
-Before any project/session enable action, require `tdd_readiness_status=ready`. If it is not ready,
-route `needs_init` to `ec-tdd-init` and `needs_repair` to the reported repair. Preserve existing
-settings on failure; never offer or persist "enable now, initialize later". Normal build-file
-changes do not require initialization, and a CLI upgrade must preserve project/session TDD values.
-Readiness means infrastructure can measure future changed production lines. It does not certify
-repository-wide coverage and does not require tests for unchanged historical code.
-
-Execution depth always equals the current mechanical minimum. Legacy workflow_mode settings
-remain readable but do not raise it. Do not offer mode choices or recommend changing to Lite.
+Selecting UT/TDD requires ready infrastructure. Reuse `ec-tdd-init` and its existing readiness
+receipt for both strategies. Route `needs_init` to initialization and `needs_repair` to the reported
+repair, preserving existing settings. Normal build-file changes do not require reinitialization.
+The shared gate measures changed production lines, not historical repository-wide coverage.
+GitLab automation may reuse it, but remote pipelines are not Harness acceptance dependencies.
+
+Run related unit tests once with coverage collection, and reuse that execution for both test and
+coverage evidence. Inputs unchanged means reuse; only rerun affected checks after relevant changes.
+Test assertions stay in ordinary review for UT. Do not add a separate UT review or workflow stage.
+
+Execution depth always equals the current mechanical minimum. Legacy workflow settings do not
+raise it. Do not offer execution-depth choices or recommend changing to Lite.

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

@@ -7,20 +7,21 @@ description: IMPLEMENT-stage skill. Executes the confirmed plan with workflow-mo
 
 Use only after ANALYSIS has frozen `task.json.workflow_mode` to `fast`, `standard`, or
 `strict`. Read `dev-spec.md`, the latest `plan` record in `execution.jsonl`, relevant RULES
-and ABSTRACT sections, and `test-strategy.md` for code tasks.
+and ABSTRACT sections. Read `test-strategy.md` when required; compact Fast uses plan checks.
 
 For a Canonical-backed task, consume the ready `spec_context.consumption` returned on creation
-or claim. On session resume or after design sync, call `resume-spec-context --agent <agent-id>
+or claim. Reuse unchanged context on the same session; only if context is missing or design changed, call `resume-spec-context --agent <agent-id>
 --session-file <P>`. The bound source and selected changes/steps/tests govern the implementation;
 handoff summaries and derived plans cannot substitute for this context. A blocked context or
 pending `spec_change` stops implementation until the original source is repaired/synchronized.
 
-If frozen `task.tdd_enabled` is not `true`, IMPLEMENT writes production and planned test code but
+If frozen `task.unit_test_mode` is `none` or `ut`, IMPLEMENT writes production and planned test code but
 does not run lint, typecheck, test, build, or coverage commands. Deterministic execution belongs
 to QUALITY's Verification Gate. TDD is the only exception because RED/GREEN/REFACTOR commands are
 part of the implementation method; current-fingerprint green evidence may be reused by QUALITY.
+UT writes the necessary tests here and runs them once with coverage in QUALITY, with no TDD lifecycle.
 
-When frozen TDD is enabled, every feature/bug unit must capture a meaningful failing unit test
+When frozen `task.unit_test_mode` is `tdd`, every feature/bug unit must capture a meaningful failing unit test
 before production code (RED) and the smallest passing implementation (GREEN). Refactor only
 when a concrete improvement is needed; unchanged GREEN inputs do not require another run.
 Pure refactors instead capture a passing characterization test before the change and rerun it
@@ -134,7 +135,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%}
+## Unit Tests     {none | ut | tdd; shared changed-line threshold N%}
 ## Task           {unit description}
 ## Source Spec    {spec_id@revision + sha256 | NONE}
 ## Source Task    {source_task_id | NONE}
@@ -220,3 +221,11 @@ conversation overhead while keeping work observable.
       an existing core Java class, has Javadoc unless it qualifies for the documented-interface
       implementation exception.
 - [ ] The task enters QUALITY, regardless of workflow mode.
+
+## Manual implementation handoff
+
+When `continuation.next_action=implement`, execute only its approved Units. Reuse the original plan,
+commands and results. Honor `stop_after:IMPLEMENT`: record completion and hand back with
+`next_action:quality`, then stop. The receiving coordinator handles the existing stage boundary
+once under the approval policy; the executor never starts quality work by inertia. Users may
+instead choose current-Agent execution. No platform is permanently assigned either role.

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

@@ -77,5 +77,5 @@ For an explicit repository mutation:
    another file changed after confirmation, or Git HEAD moved. Re-present the proposal rather
    than bypassing that result. Lite remains enabled for the next request.
 
-Lite intentionally omits TDD, QUALITY, MEMORY, task history, and completion transitions. Use a
+Lite intentionally omits UT/TDD coverage gates, QUALITY, MEMORY, task history, and completion transitions. Use a
 normal Fast task instead when the user wants those guarantees.

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

@@ -42,10 +42,9 @@ policy, changed files, and any Canonical source tasks that required targeted ver
 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.
+For frozen UT/TDD, record the strategy, shared threshold, passed local unit-test result, and
+changed-line coverage result with its frozen baseline. Only TDD includes lifecycle evidence.
+Remote CI is not acceptance evidence. With `none`, omit coverage-specific fields.
 
 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

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

@@ -6,15 +6,17 @@ description: QUALITY-stage skill. Freezes one candidate, runs independent Review
 # ec-quality — one candidate, two read-only gates
 
 Use only while the current task is in `QUALITY`. Communicate in the user's language. QUALITY
-does not modify source, tests, configuration, plans, or task scope.
+keeps Review and Verification read-only while permitting approved bounded repairs between checks.
+Ordinary fixes stay in QUALITY; changed requirements/contracts or a replaced implementation plan
+return to ANALYSIS/IMPLEMENT. Bug severity or line count alone does not decide the route.
 
 ## Candidate freeze
 
 For Canonical-backed tasks, load the current session's bound selection through `resume-spec-context`
-when resuming. Pass that original consumption closure to both gates and compare selected contracts,
+only when the current session lacks that context or the design changed. Pass that original consumption closure to both gates and compare selected contracts,
 changes, Steps and Tests against the candidate. Pending `spec_change` blocks QUALITY acceptance
 until the source revision is synchronized. Bounded corrections refresh only their affected Unit
-mappings and continue IMPLEMENT; substantive expansion returns to ANALYSIS.
+mappings and retain the current stage; substantive expansion returns to ANALYSIS.
 
 Call `evidence-fingerprints` once to obtain the runtime-owned attempt and candidate. The runtime
 owns signatures and prior-evidence references. Never calculate historical fingerprints, import
@@ -59,7 +61,8 @@ meaningless remaining check when a concrete blocker is found. Aggregate the repa
 
 ### Standard
 
-- Dispatch one independent reviewer.
+- Use one independent reviewer. A coordinator who did not author the candidate can provide this
+  review after another Agent implemented it; do not launch a duplicate reviewer merely for form.
 - Run affected lint/typecheck/test plus every must-test command from `test-strategy.md`.
 - Run Review and Verification in parallel when their inputs are already frozen.
 
@@ -69,10 +72,15 @@ meaningless remaining check when a concrete blocker is found. Aggregate the repa
 - For each actually modified repository, run all applicable lint, typecheck, test, and build
   checks. A repository merely mentioned by a Spec, dependency, supermodule, or path map is not in
   scope.
-- When frozen TDD is enabled, include the required TDD review dimension, local unit test, and
-  changed-production-line coverage at the confirmed threshold. Record one coverage result with `coverage_scope:"local"`;
-  GitLab coverage is informative, not a task acceptance gate. Reuse current-fingerprint GREEN
-  evidence from IMPLEMENT instead of rerunning an identical command.
+
+### Unit test strategy (all depths)
+
+For frozen `unit_test_mode=ut|tdd` at any workflow depth, require passed local unit tests and
+changed-production-line coverage at `ut_coverage_threshold`. Run the related tests with coverage
+collection once and record both results from that execution (`coverage_scope:"local"`). Reuse
+unchanged input-bound evidence from IMPLEMENT or earlier attempts. Only `tdd` adds the TDD review
+dimension and lifecycle contract. UT reviews assertions within ordinary review and does not add a
+separate review. `none` adds no coverage gate. GitLab results are informative, not acceptance gates.
 
 ## Review Gate
 
@@ -103,7 +111,7 @@ blocking record also carries a `failure_classes` array; do not defer classificat
 
 ## Verification Gate
 
-Run only the commands selected by the mode and `test-strategy.md`. Record real exit status and
+Run only commands selected by the mode and the existing plan/test strategy. Record real exit status and
 current implementation/config fingerprints plus the active `quality_attempt` using the existing
 `type:"verify"` contract. Do not run a command inside Review Gate, and do not fix a failure inside
 Verification Gate. A failed applicable check also carries its structured `failure_classes` array.
@@ -124,7 +132,7 @@ Wait for both gates, then aggregate all blocking results once. Classify each ite
 
 If code or tests need edits, create one concise Repair Bundle containing every in-scope blocking
 item, affected files, required verification, and evidence that may be reused. After both Gates are
-terminal, finalize the decision before transitioning once to IMPLEMENT:
+terminal, finalize the decision, then prepare the bounded repair while remaining in QUALITY:
 
 ```bash
 {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py finalize-quality \
@@ -147,10 +155,39 @@ review/verify record first, then write each affected source task `blocked` throu
 use the exact idempotency key `<H>:<S>:<F>:quality-<A>:blocked`. Add one failed evidence object for
 each affected Gate kind with ref
 `execution.jsonl#quality-attempt=<A>;implementation=<F>;source-task=<S>;kind=review|verify`.
-Only after every blocked writeback is acknowledged may the task return to IMPLEMENT; the state API
-rejects a writeback from another run, attempt, fingerprint, or evidence window. Entering IMPLEMENT
-reopens only those blocked source tasks as a new `in_progress` attempt, while unaffected implemented
-tasks keep their shared conclusion.
+After blocked writeback is acknowledged, start the approved repair. The runtime reopens only those
+source tasks with a repair-specific idempotency key, keeping local status QUALITY and unaffected
+source progress. Record affected Step/result completion and source `implemented` before completing
+the repair. Reuse the existing writer and ledger, never copy a second implementation plan.
+
+Use `begin-correction --file <existing-unit-file> --summary <bundle>` to prepare one `quality_repair`.
+In dispatch mode, present this complete bundle once with choices: current Agent, another Agent,
+or defer/revise. This human dispatch decision remains under every approval mode; Approve shares
+the same decision. The user may explicitly authorize current-Agent execution. Default mode uses
+its existing approval policy for local repair, with no handoff inside the stage.
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py start-quality-repair \
+  --repair-id <id> --executor current|other [--confirmed] --agent <agent-id> --session-file <P>
+```
+
+Pass `--confirmed` only for a real user decision on this bundle. For other-Agent execution the call
+also writes the handoff. The recipient claims the task and directly repairs the approved files;
+it must not ask again or return to IMPLEMENT. Bounded code and necessary tests follow the existing
+unit test strategy, including TDD lifecycle checks only when TDD is frozen. The recipient finishes:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py complete-quality-repair \
+  --repair-id <id> --agent <agent-id> --session-file <P>
+```
+
+This returns other-Agent repairs to the coordinator for delta review/verification. No quality gate
+may pass while the repair is pending. Scope/contract changes must be resolved rather than silently
+included in the accepted bundle. Repeated starts/completions reuse the existing repair ID.
+
+`prepare-check --record` also accepts an array. `record-check --result` accepts an array of
+`{prepared_id,result}` to register the results of those prepared checks. Each check keeps its own
+inputs and real result; batching shares runtime reads, not unrelated evidence.
 
 After repair, choose the minimum honest evidence refresh:
 

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

@@ -13,7 +13,7 @@ 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;
-- task `concrete_workflow_mode` and frozen TDD state when present;
+- task `concrete_workflow_mode` and frozen unit test strategy when present;
 - harness enabled/disabled and Lite Direct state;
 - active and resumable tasks.
 - for Canonical-backed tasks: source locator/path mode, Spec ID/design revision/design digest,
@@ -22,7 +22,7 @@ Call the state API snapshot and show:
   pending confirmed Spec change.
 
 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.
+Workflow, cooperation, unit test strategy, or the shared coverage threshold, route there and do not mutate those fields here.
 
 ## Task actions
 
@@ -38,8 +38,8 @@ When creating from a Canonical Spec, call `inspect-dev-spec --manifest-only`, di
 task and dependency selection, then call `create-task-from-spec` only after explicit user
 selection. Multiple selected Spec tasks still create one Harness task. Do not call
 `select-dev-spec-scope` during discovery. Creation and claim return the selected consumption
-closure; consume it before stage work. On a resumed session, use `resume-spec-context` with
-the current agent/session. A blocked context allows repair/rebind/sync, but blocks advancement.
+closure; consume it before stage work. On the same session, reuse unchanged context; call `resume-spec-context` only if context is missing
+or invalidated. A new session must consume its selected closure. A blocked context allows repair/rebind/sync, but blocks advancement.
 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
@@ -49,3 +49,10 @@ action is cleared with `status:error`; correct its input instead of replaying it
 Confirmed requirement changes use `begin-spec-change` before editing the original source.
 Its summary and affected tasks survive handoff. Finish revision + READY + `sync-spec-design`,
 then reload context and refresh the plan in ANALYSIS. Do not clear a pending change manually.
+
+## Scoped continuation
+
+Display the task coordinator, continuation action/stop point and current repair bundle. A claim
+returns the existing approved work; do not request a second scope approval. The main Agent is not
+replaced by the coding executor. Handoff summaries reference existing plan Units and execution
+indices; never copy a new Spec or reconstruct old verification results.

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

@@ -1,11 +1,11 @@
 ---
 name: ec-tdd-init
-description: Initialize or refresh Java changed-line TDD coverage infrastructure before TDD can be enabled.
+description: Initialize or refresh Java changed-line TDD coverage infrastructure before UT or 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
+Communicate in the user's language. This skill owns shared UT/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.
 
@@ -14,12 +14,12 @@ repository-wide coverage, or modify production behavior merely to raise coverage
 The only legal order is:
 
 ```text
-TDD off -> initialize infrastructure -> readiness ready -> user explicitly enables TDD
+unit_test_mode=none -> initialize infrastructure -> readiness ready -> user selects UT or 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
+task with `unit_test_mode=none`, even when a legacy project/session setting or a suspended task has
+UT or TDD enabled. Never offer "enable now and initialize later". Never enable UT/TDD automatically after
 initialization.
 
 ## Read-only preflight
@@ -31,7 +31,7 @@ python3 .easy-coding/tools/easy_coding_tdd_readiness.py --cwd . check --include-
 ```
 
 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.
+The user may then use `ec-config` or `easy-coding config` to select UT or TDD.
 
 If it returns `needs_init` or `needs_repair`, inspect only the reported infrastructure needed
 to form a confirmed initialization or repair plan:
@@ -102,5 +102,5 @@ reinitialization. Daily `check` validates local entry points and task-variable c
 return `needs_init`; damaged receipts or required entries return `needs_repair`. Repair the
 reported entry, repeat applicable tests, and preserve the user's TDD settings.
 
-After completion, report the unchanged TDD setting and provide the explicit project/session
+After completion, report the unchanged unit test strategy and provide the explicit project/session
 enable route when it is off. Do not treat readiness as consent to change it.