easy-coding-harness 1.0.1 → 1.1.0-beta.1

package/package.json

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

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

@@ -48,3 +48,7 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
 - `checks`: TDD lifecycle commands actually run, otherwise an empty array
 
 Do not claim a file is verified unless the card asked you to run a check and you ran it.
+
+- Use only the current correction/diff and direct dependencies. Preserve unrelated progress.
+- Do not add repeated validation, fallback, retries, compatibility branches, idempotency
+  changes or defensive copies without an explicit requirement or demonstrated defect.

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

@@ -53,3 +53,9 @@ dimension named in your task card. Your reply IS the return value.
 - `repo_id` and `source_task_id`: copy unchanged when present in the task card
 - `findings`: array of `{file, line, issue, severity}` (`severity`: info | warning | error)
 - `suggestion`: optional fix direction per finding
+
+- Use only the current correction/diff and direct dependencies. Preserve unrelated progress.
+- Do not add repeated validation, fallback, retries, compatibility branches, idempotency
+  changes or defensive copies without an explicit requirement or demonstrated defect.
+- Review code and test behavior only. Do not reconstruct fingerprints or inspect workflow
+  history. Passed work stays passed until relevant inputs change; suggestions do not block.

package/templates/codex/agents/ec-implementer.toml

@@ -45,4 +45,8 @@ Output (return exactly this):
 - checks: TDD lifecycle commands actually run, otherwise an empty array
 
 Do not claim a file is verified unless the card asked you to run a check and you ran it.
+
+- Use only the current correction/diff and direct dependencies. Preserve unrelated progress.
+- Do not add repeated validation, fallback, retries, compatibility branches, idempotency
+  changes or defensive copies without an explicit requirement or demonstrated defect.
 """

package/templates/codex/agents/ec-reviewer.toml

@@ -50,4 +50,10 @@ Output (return exactly this):
 - repo_id and source_task_id: copy unchanged when present in the task card
 - findings: array of {file, line, issue, severity} (severity: info | warning | error)
 - suggestion: optional fix direction per finding
+
+- Use only the current correction/diff and direct dependencies. Preserve unrelated progress.
+- Do not add repeated validation, fallback, retries, compatibility branches, idempotency
+  changes or defensive copies without an explicit requirement or demonstrated defect.
+- Review code and test behavior only. Do not reconstruct fingerprints or inspect workflow
+  history. Passed work stays passed until relevant inputs change; suggestions do not block.
 """

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

@@ -21,12 +21,8 @@ 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.
+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
 `selected_spec_tasks`, and only their stored `task.repo_paths` bindings. Schema, Spec ID, design
@@ -73,7 +69,8 @@ when local evidence conflicts or a deviation can change the contract, risk, or a
 
 ## Analysis artifacts
 
-Copy `.easy-coding/templates/dev-spec-skeleton.md` first, then replace every `[[EC_TODO:...]]`.
+For a non-TDD Fast task use the compact form below. Otherwise copy
+`.easy-coding/templates/dev-spec-skeleton.md` first, then replace every `[[EC_TODO:...]]`.
 Keep every mandatory section. The `### 决策闭环` (Decision Closure) and `### Workflow Mode`
 sections are required. The decision section must contain exactly one standalone
 `decision_status: closed` marker, and no other `decision_status` marker may appear elsewhere in
@@ -153,108 +150,63 @@ line count, or create many one-use helpers, merely to make the plan look modular
 clear semantic boundary, reuse point, or independently testable responsibility. Use parallel only
 for truly independent write scopes. Better unit contracts reduce later QUALITY rework.
 
-Every Harness task is a repository-mutation task and requires `test-strategy.md`. Pure read-only
+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; design tests
-  toward 100% while treating the threshold as the mechanical minimum;
-- 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
 
-Resolve configured mode from the state snapshot:
+Execution mode equals the mechanical minimum for the actual current scope. Do not propose a
+higher mode or ask the user to select one. Old configured/frozen modes do not raise the minimum.
+Use `propose-workflow-mode --agent <agent-id> --session-file <P>` once after the plan exists;
+it returns the calculated mode and reasons, so a separate floor/proposal round is unnecessary.
 
-`session.workflow_mode > project behavior.workflow_mode > adaptive`
+For a non-TDD Fast task, dev-spec.md may use the compact form:
 
-After writing the execution plan, ask the state API to calculate the mechanical minimum:
-
-```bash
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py workflow-floor \
-  --agent <agent-id> --session-file <P>
-```
-
-Use its `minimum_mode` and `reasons` as the proposal floor. You may raise this result when
-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 is intentionally Standard-centered:
-
-- `fast`: up to three coherent low-risk units in one actually modified repository, at most eight
-  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. Four or more units, more than eight 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 five units, at least fifteen
-  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. 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:
-
-```bash
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py propose-workflow-mode \
-  --configured <adaptive|fast|standard|strict> \
-  --selected <fast|standard|strict> \
-  --minimum <fast|standard|strict> \
-  --source <project|session|adaptive|user> \
-  --reason "<reason>" \
-  --agent <agent-id> --session-file <P>
+```markdown
+<!-- easy-coding:compact -->
+decision_status: closed
+Goal: <confirmed behavior>
+Scope: <exact files and preservation boundary>
+Acceptance: <observable outcome and minimum check>
 ```
 
-Repeat `--reason` for distinct material risks. Re-running the command replaces the proposal
-while still in ANALYSIS.
+Record Unit `input_files` for the known additional direct inputs (an empty list means the
+Unit files are self-contained). Include shared helpers, fixtures, schemas and configuration
+actually consumed by its checks. Without a declared closure, checks cover the owning module.
+Build commands still include their module compilation inputs. Do not infer a whole-program call graph. Keep Unit contracts and test points in the existing execution plan. Do not duplicate them across
+full template chapters or create a separate test strategy for this compact form. Canonical work
+consumes the selected source closure; it does not redesign unrelated selected tasks.
 
 ## User presentation and transition
 
@@ -263,9 +215,9 @@ pasting the full `dev-spec.md`. The receipt must contain:
 
 - the core solution and affected scope/units;
 - acceptance and test-strategy highlights;
-- configured, minimum, and selected workflow modes with reasons;
+- the computed minimum workflow mode and its concrete reasons;
 - the material risks and explicit acceptance boundaries;
-- explicit user ability to request a higher mode or a permitted lower mode.
+- the computed minimum mode as an execution fact, without offering mode choices.
 
 End the summary with the absolute path to
 `.easy-coding/tasks/<task-id>/dev-spec.md`. When the current client supports local-file Markdown
@@ -305,6 +257,6 @@ If evidence requires changing Canonical task boundaries, contracts, files, symbo
 or dependencies, obtain confirmation and run `begin-spec-change --affected-task <id> --summary
 <confirmed-change> --agent <agent-id> --session-file <P>` before editing. This persists the
 intent across handoffs and blocks implementation/acceptance until synchronization. Update the original static design with revision +1,
-restore READY, and call `sync-spec-design --affected-task ...`. This invalidates the old local
-plan. Run `resume-spec-context` after synchronization, then refresh derived artifacts. Never
+restore READY, and call `sync-spec-design --affected-task ...`. For bounded corrections this refreshes only affected Unit mappings; other design changes
+invalidate the old local plan. Run `resume-spec-context` after synchronization, then refresh derived artifacts. Never
 substitute edits to the derived `dev-spec.md`, and never edit `EDS:EXECUTION` by hand.

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, Workflow, and Java unit test strategies.
 ---
 
 # ec-config — mode configuration
@@ -10,69 +10,59 @@ 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`,
+the mechanically calculated workflow mode (read-only), `unit_test_mode`, and `ut_coverage_threshold`.
+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.
 
-- `approval_mode`;
-- `workflow_mode`;
-- `tdd_enabled` and `tdd_coverage_threshold`.
+Precedence is `session override > project config > defaults`. Defaults are Approval `guard`,
+Workflow `adaptive`, unit test strategy `none`, and shared changed-line coverage threshold 90%.
+The strategies are:
 
-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:
+- `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.
 
-```bash
-python3 .easy-coding/tools/easy_coding_tdd_readiness.py --cwd . check
-```
-
-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.
-
-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.
+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 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`.
+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.
 
 ## Project configuration
 
-Use `easy-coding config` for project settings. The CLI confirms one atomic update of Approval,
-Workflow, TDD, and (when enabled) the threshold. 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>
 
-# 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>
-
-# 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 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.
+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

@@ -15,23 +15,33 @@ or claim. On session resume or after design sync, call `resume-spec-context --ag
 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
-before production code (RED), the smallest passing implementation (GREEN), and a green refactor.
+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
 afterward. Never fake RED evidence. Keep tests deterministic, boundary-focused, and minimally
-mocked, and design changed production code toward 100% unit coverage.
+mocked, and meet the confirmed changed-line threshold without expanding scope for extra coverage.
 
 Communicate with the user in the user's language.
 
+For a bounded correction already routed by `begin-correction`, use the existing plan and the
+returned file scope. Restoring known behavior needs the affected regression checks, not an
+artificial RED/REFACTOR cycle. Preserve all unrelated Unit progress. A correction of generated
+tracking metadata is handled once; do not reopen design or rewrite the complete plan for it.
+
+When a lifecycle check is necessary, call `prepare-check` before running it and `record-check`
+afterward as documented in ec-quality. QUALITY reuses these input-bound results.
+
 ## Non-negotiable gates
 
-1. Modify only files in the confirmed change-scope table. A new file requirement returns the
-   task to ANALYSIS.
+1. Modify only confirmed files. Return to ANALYSIS only for a substantive scope/contract
+   expansion; restoring a previously mapped file uses the correction scope.
 2. Preserve existing encoding and project comment conventions.
 3. Each unit must carry `acceptance_criteria`, `test_points`, `contracts`, and `risks`.
    Missing unit context is an analysis defect; do not make the implementer rediscover it.
@@ -88,6 +98,11 @@ Communicate with the user in the user's language.
 14. Use one blank line between coherent logic sections. Do not create noisy blank-line gaps or
     compress unrelated steps into an unreadable block.
 
+Keep validation at its responsible boundary. Do not repeat internal null/state checks already
+covered by the contract. Without an explicit requirement or demonstrated defect, add no fallback,
+retry, compatibility branch, idempotency change, defensive copy, or speculative error handling.
+An added validation needs a concrete triggering input and the failure it prevents.
+
 ## Choose the execution owner
 
 `strategy` defines dependency shape; `workflow_mode` defines assurance depth.
@@ -120,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}
@@ -176,7 +191,8 @@ checks:[], issues:[], needs_attention:[]
 8. If a static Canonical change is confirmed, first persist it with `begin-spec-change
    --affected-task <id> --summary <confirmed-change> --agent <agent-id> --session-file <P>`.
    Revise the original design by exactly one revision, validate READY and use `sync-spec-design`;
-   then `resume-spec-context` and rebuild the local plan in ANALYSIS. Never edit the
+   then `resume-spec-context`. A bounded correction preserves the plan and continues IMPLEMENT;
+   substantive expansion returns to ANALYSIS. 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`
@@ -188,8 +204,8 @@ conversation overhead while keeping work observable.
 ## End state
 
 - After all units are implemented, hand control to ec-workflow for IMPLEMENT -> QUALITY.
-- New risk above the frozen mode: call `raise-workflow-mode`; modes may rise but never silently
-  fall after ANALYSIS.
+- A concrete new risk changes the calculated minimum: update its Unit risk and call
+  `raise-workflow-mode` to recalculate. The argument cannot inflate the mechanical result.
 
 ## Self-check
 

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