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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "1.1.0-beta.0",
+  "version": "1.1.0-beta.1",
   "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

@@ -153,47 +153,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, Workflow, and Java unit test strategies.
 ---
 
 # ec-config — mode configuration
@@ -10,68 +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`;
-- the mechanically calculated workflow mode (read-only);
-- `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,
-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 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

@@ -15,12 +15,13 @@ 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
+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}

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

@@ -69,10 +69,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
 

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, unit test strategy, or the shared coverage threshold, route there and do not mutate those fields here.
 
 ## Task actions
 

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.

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

@@ -30,20 +30,20 @@ Pure conversation, explanation, analysis, and read-only review stay Ready and cr
   edge. The only additional pause is an exceptional code diff detected after the frozen
   QUALITY acceptance checkpoint; accepting that exact diff does not change the mode.
 - `workflow_mode = adaptive|fast|standard|strict` controls execution cost and assurance depth.
-- `tdd_enabled` independently activates Java TDD and changed-line coverage. It defaults off;
-  `tdd_coverage_threshold` defaults to 90 and accepts integers from 1 to 100.
+- `unit_test_mode` independently selects `none`, `ut`, or `tdd`. It defaults to `none`;
+  `ut_coverage_threshold` defaults to 90 and accepts integers from 1 to 100.
 
-Approval and TDD retain session-over-project precedence. Execution depth is always the
+Approval and unit test strategy retain session-over-project precedence. Execution depth is always the
 mechanically calculated minimum for the current change. Do not recommend, select a higher mode,
 or inherit an old task mode. Persist it once with `propose-workflow-mode --agent <agent-id>
 --session-file <P>`; the runtime calculates and freezes the value.
 
-TDD resolves with the same session-over-project precedence and freezes its enabled flag and
-threshold on ANALYSIS -> IMPLEMENT. It may be enabled only after `ec-tdd-init` readiness passes;
-there is no enabled-but-pending-initialization state. A dedicated `tdd-init` task always freezes
-TDD off so it can create or repair the required infrastructure without circular gating. When off,
-ordinary tasks add no CI scan, artifacts, commands, coverage work, or stronger acceptance. Use
-`ec-config` for all mode configuration.
+Unit test strategy uses the same session-over-project precedence and freezes its mode and
+`ut_coverage_threshold` on ANALYSIS -> IMPLEMENT. UT and TDD share passed local unit tests and
+changed-line coverage, and reuse `ec-tdd-init` readiness. Only TDD requires test-first lifecycle
+and its review dimension. UT keeps ordinary review and compact Fast planning. The `tdd-init`
+task itself freezes strategy `none`; `none` adds no infrastructure scan or coverage gate.
+Both strategies reuse input-bound results and do not raise workflow depth.
 
 `confirm` and `auto` do not hide the proposal: show it in the plan. Confirm waits for that one
 plan decision; Auto continues immediately. Both remove later waiting, not quality gates.

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

@@ -13,8 +13,8 @@ then a blank line. Do not render the machine breadcrumbs to the user.
 
 `{approval-mode}` is the effective approval mode and `{workflow-mode}` is the configured or
 task-frozen execution mode; session overrides take precedence over project settings.
-When effective/frozen TDD is enabled, insert `· **TDD**` immediately after Workflow. When it is
-disabled, omit the TDD segment entirely and preserve the existing status-line format.
+When effective/frozen unit_test_mode is `ut` or `tdd`, insert `· **UT**` or `· **TDD**`
+immediately after Workflow. For `none`, omit this segment and preserve the status-line format.
 
 - Ready: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, `ec-task-management` to manage tasks, or `ec-config` to inspect or change modes
 - Waiting init: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Waiting init · Use `ec-init` to initialize
@@ -34,7 +34,7 @@ Trigger Easy Coding skills with your platform prefix — Codex: `$ec-*`, Qoder:
 - `ec-brainstorming` — design exploration before building (hard design gate)
 - `ec-analysis` `ec-implementing` `ec-quality` — workflow stages
 - `ec-memory` — short/long memory archive
-- `ec-task-management` — task lifecycle panel · `ec-config` — Approval/Workflow/TDD settings · `ec-tdd-init` — Java changed-line gate initialization · `ec-task-close` — interrupt a task
+- `ec-task-management` — task lifecycle panel · `ec-config` — Approval/Workflow/unit-test settings · `ec-tdd-init` — Java changed-line gate initialization · `ec-task-close` — interrupt a task
 - `ec-no-harness` — bypass only Easy Coding for the current session
 - `ec-lite` — user-controlled direct mode with one proposal confirmation and no task/QUALITY/MEMORY
 - `ec-git` — git discipline · `ec-meta` — understand/customize the harness
@@ -51,17 +51,18 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   checkpoint is the only exceptional pause across all modes: show the exact diff, bind acceptance
   to its digest, and continue without rereview when the user accepts.
   Every mutation task runs QUALITY; no mode changes scope, delivery form, or evidence gates.
-- TDD is session override > project `behavior.tdd_enabled` > `false`; its changed-line threshold
-  is session override > project `behavior.tdd_coverage_threshold` > `90`. ANALYSIS -> IMPLEMENT
-  freezes both. TDD may be enabled only after `ec-tdd-init` records valid infrastructure readiness;
-  build version/content changes require fresh task evidence, not reinitialization. Repair missing
-  local entries without resetting TDD; CLI upgrades preserve project/session/frozen task settings;
-  there is no enable-now/init-later state. The dedicated `tdd-init` task always freezes TDD off and
-  initializes only changed-line coverage infrastructure, never historical business-test coverage.
-  Disabled TDD adds no CI scan, JaCoCo work, commands, artifacts, or stronger gates. Enabled TDD
-  applies only to Java code tasks and requires lifecycle, review, passed local unit tests, and
-  local coverage for production lines changed since the task baseline. `ec-tdd-init` still
-  generates GitLab TEST-stage automation, but remote CI status is not Harness acceptance evidence.
+- Unit test strategy is session override > project `behavior.unit_test_mode` > `none`.
+  Values are `none`, `ut`, and `tdd`; both enabled strategies share `ut_coverage_threshold`
+  (session > project > 90, integer 1..100). ANALYSIS -> IMPLEMENT freezes strategy, threshold,
+  and repository baselines. `none` adds no coverage work and retains ordinary task verification.
+  UT requires passed local unit tests and changed-production-line coverage, without test-first
+  ordering, RED/GREEN artifacts, or a separate TDD review. TDD additionally requires its lifecycle
+  and review dimension. Assertions remain part of ordinary review in UT.
+  Both currently support Java and reuse `ec-tdd-init` readiness, JaCoCo, and existing evidence
+  reuse. One test execution supplies tests plus coverage. No new stages or workflow escalation.
+  The dedicated `tdd-init` task freezes strategy `none`; readiness failure reports repair rather
+  than resetting configuration. CLI upgrades migrate old fields and preserve frozen task progress.
+  GitLab automation is infrastructure, not remote acceptance evidence.
 - Confirmation-required edges use `pending_transition`; automatic edges use the restricted
   `auto-transition` API. Pure read-only conversation stays Ready and creates no task. Any
   repository write, including documentation or configuration, uses the full state machine.

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

@@ -13,8 +13,8 @@ then a blank line. Do not render the machine breadcrumbs to the user.
 
 `{approval-mode}` is the effective approval mode and `{workflow-mode}` is the configured or
 task-frozen execution mode; session overrides take precedence over project settings.
-When effective/frozen TDD is enabled, insert `· **TDD**` immediately after Workflow. When it is
-disabled, omit the TDD segment entirely and preserve the existing status-line format.
+When effective/frozen unit_test_mode is `ut` or `tdd`, insert `· **UT**` or `· **TDD**`
+immediately after Workflow. For `none`, omit this segment and preserve the status-line format.
 
 - Ready: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, `ec-task-management` to manage tasks, or `ec-config` to inspect or change modes
 - Waiting init: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Waiting init · Use `ec-init` to initialize
@@ -32,7 +32,7 @@ platform prefixes such as `/` or `$`. If no status line is injected, do not inve
 - `/ec-brainstorming` — design exploration before building (hard design gate)
 - `/ec-analysis` `/ec-implementing` `/ec-quality` — workflow stages
 - `/ec-memory` — short/long memory archive
-- `/ec-task-management` — task lifecycle panel · `/ec-config` — Approval/Workflow/TDD settings · `/ec-tdd-init` — Java changed-line gate initialization · `/ec-task-close` — interrupt a task
+- `/ec-task-management` — task lifecycle panel · `/ec-config` — Approval/Workflow/unit-test settings · `/ec-tdd-init` — Java changed-line gate initialization · `/ec-task-close` — interrupt a task
 - `/ec-no-harness` — bypass only Easy Coding for the current session
 - `/ec-lite` — user-controlled direct mode with one proposal confirmation and no task/QUALITY/MEMORY
 - `/ec-git` — git discipline · `/ec-meta` — understand/customize the harness
@@ -49,17 +49,18 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   checkpoint is the only exceptional pause across all modes: show the exact diff, bind acceptance
   to its digest, and continue without rereview when the user accepts.
   Every mutation task runs QUALITY; no mode changes scope, delivery form, or evidence gates.
-- TDD is session override > project `behavior.tdd_enabled` > `false`; its changed-line threshold
-  is session override > project `behavior.tdd_coverage_threshold` > `90`. ANALYSIS -> IMPLEMENT
-  freezes both. TDD may be enabled only after `ec-tdd-init` records valid infrastructure readiness;
-  build version/content changes require fresh task evidence, not reinitialization. Repair missing
-  local entries without resetting TDD; CLI upgrades preserve project/session/frozen task settings;
-  there is no enable-now/init-later state. The dedicated `tdd-init` task always freezes TDD off and
-  initializes only changed-line coverage infrastructure, never historical business-test coverage.
-  Disabled TDD adds no CI scan, JaCoCo work, commands, artifacts, or stronger gates. Enabled TDD
-  applies only to Java code tasks and requires lifecycle, review, passed local unit tests, and
-  local coverage for production lines changed since the task baseline. `ec-tdd-init` still
-  generates GitLab TEST-stage automation, but remote CI status is not Harness acceptance evidence.
+- Unit test strategy is session override > project `behavior.unit_test_mode` > `none`.
+  Values are `none`, `ut`, and `tdd`; both enabled strategies share `ut_coverage_threshold`
+  (session > project > 90, integer 1..100). ANALYSIS -> IMPLEMENT freezes strategy, threshold,
+  and repository baselines. `none` adds no coverage work and retains ordinary task verification.
+  UT requires passed local unit tests and changed-production-line coverage, without test-first
+  ordering, RED/GREEN artifacts, or a separate TDD review. TDD additionally requires its lifecycle
+  and review dimension. Assertions remain part of ordinary review in UT.
+  Both currently support Java and reuse `ec-tdd-init` readiness, JaCoCo, and existing evidence
+  reuse. One test execution supplies tests plus coverage. No new stages or workflow escalation.
+  The dedicated `tdd-init` task freezes strategy `none`; readiness failure reports repair rather
+  than resetting configuration. CLI upgrades migrate old fields and preserve frozen task progress.
+  GitLab automation is infrastructure, not remote acceptance evidence.
 - Confirmation-required edges use `pending_transition`; automatic edges use the restricted
   `auto-transition` API. Pure read-only conversation stays Ready and creates no task. Any
   repository write, including documentation or configuration, uses the full state machine.

package/templates/runtime/tools/easy_coding_java_coverage.py

@@ -191,16 +191,16 @@ def read_project_threshold(repo: Path) -> int:
                 schema_version = 0
             continue
         if (
-            schema_version >= 4
+            schema_version >= 6
             and in_behavior
-            and stripped.startswith("tdd_coverage_threshold:")
+            and stripped.startswith("ut_coverage_threshold:")
         ):
             try:
                 value = int(stripped.split(":", 1)[1].strip().strip("'\""))
             except ValueError as error:
-                raise CoverageError("Invalid behavior.tdd_coverage_threshold") from error
+                raise CoverageError("Invalid behavior.ut_coverage_threshold") from error
             if not 1 <= value <= 100:
-                raise CoverageError("TDD coverage threshold must be from 1 to 100")
+                raise CoverageError("Unit test coverage threshold must be from 1 to 100")
             return value
     return DEFAULT_THRESHOLD
 
@@ -294,7 +294,7 @@ def main() -> int:
             else read_project_threshold(repo)
         )
         if not 1 <= threshold <= 100:
-            raise CoverageError("TDD coverage threshold must be from 1 to 100")
+            raise CoverageError("Unit test coverage threshold must be from 1 to 100")
         reports = (
             sorted({Path(item).resolve() for item in args.report})
             if args.report

package/templates/shared-hooks/easy_coding_inputs.py

@@ -255,7 +255,7 @@ def input_spec(root, task, plan, check):
                            "tests" if builds_module else "tests/fixtures"):
                 if (base / config).is_dir():
                     paths.add(config)
-    if task.get("tdd_enabled") is True:
+    if task.get("unit_test_mode") in {"ut", "tdd"}:
         for directory in {str(root.resolve()), *repositories}:
             manifest = Path(directory) / ".easy-coding/tdd/readiness.json"
             if manifest.is_file():