easy-coding-harness 0.10.0-beta.1 → 0.10.0-beta.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "0.10.0-beta.1",
+  "version": "0.10.0-beta.3",
   "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,9 +85,11 @@ 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 4 TDD defaults and
-  `.easy-coding/tools/easy_coding_java_coverage.py` exists? Missing fields or tool mean
-  `easy-coding upgrade` is required; ec-init must not repair them directly.
+- **TDD runtime contract**: CLI-owned `config.yaml` has schema 5 TDD 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
+  JaCoCo/GitLab readiness remains owned by `ec-tdd-init`, not `ec-init`.
 - **Platform hook config freshness**: for each installed platform in `.easy-coding/config.yaml`,
   read the platform hook config and verify managed Easy Coding hook commands use the portable
   relative hook launcher bound to this project root's `project.id`. If `project.id` is missing,
@@ -159,7 +161,8 @@ agent must be able to see what was generated and on what evidence.
    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
    requirements. If it is enabled for Java, additionally document JUnit/JaCoCo commands,
-   production/test source roots, XML report paths, and the existing GitLab TEST-stage gate.
+   production/test source roots, XML report paths, the local acceptance gate, and the generated
+   GitLab TEST-stage job as non-blocking automation infrastructure.
 5. **Memory migration probe** — Check for old-format memory files:
    - `.easy-coding/memory/long/MEMORY.md` exists but lacks `memory_schema: 2` frontmatter
    - `.easy-coding/memory/long/BUSINESS.md` or `TECHNICAL.md` missing

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

@@ -58,8 +58,9 @@ and config fingerprints, and MEMORY keeps the conditional long-memory threshold
 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, and the same JaCoCo diff gate locally and in
-GitLab TEST-stage CI.
+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.
 
 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/bundled-skills/ec-meta/references/platform-files/README.md

@@ -14,7 +14,7 @@ What lives in each platform directory and how the three platforms differ.
 | Sub-agent defs | `.claude/agents/*.md` | `.codex/agents/*.toml` | `.qoder/agents/*.md` |
 | CN variant | — | — | `.qodercn/` |
 
-Each skill is installed as `{skills-dir}/ec-{name}/SKILL.md`. The 14 skills are
+Each skill is installed as `{skills-dir}/ec-{name}/SKILL.md`. The 15 skills are
 platform-agnostic — one template, resolved per platform at write time. The agent's native
 discovery surfaces them under `/ec-` or `$ec-`.
 

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

@@ -96,8 +96,14 @@ Code tasks require `test-strategy.md`; explicit `doc`, `analysis`, and `report`
 ## 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.
+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:
 
@@ -107,18 +113,24 @@ When TDD is enabled for a Java code task, make `test-strategy.md` record:
   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;
-- `.gitlab-ci.yml` and included configuration, the TEST-stage job, JUnit/JaCoCo artifacts, and an
-  equivalent changed-line gate. Reuse a gate only when its threshold is at least the configured
-  value; otherwise include the CI change in the confirmed implementation scope.
+- 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`; if missing or drifted, stop before IMPLEMENT and route to
+  `ec-tdd-init`. Never plan to initialize CI inside an already-enabled TDD feature task.
 
 The state API mechanically freezes current Git `HEAD` per repository into `task.tdd_baselines`
-when ANALYSIS advances to IMPLEMENT. Plan both local and GitLab commands with that exact SHA and
-the frozen threshold; 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.
+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 gate, GitLab TEST gate, and lifecycle evidence. Do not add this section when TDD
-is disabled.
+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.

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

@@ -18,7 +18,15 @@ Call `snapshot` and show project, session, effective, and frozen task values for
 
 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.
+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:
+
+```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
@@ -29,6 +37,7 @@ changes affect future tasks and ANALYSIS only.
 
 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`.
 
 ## Session configuration
 
@@ -51,4 +60,11 @@ After explicit user selection, use the current logical session file:
 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, local changed-line JaCoCo coverage, and GitLab TEST-stage gate planning.
+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,
+offer only `ec-tdd-init` or cancellation; never offer or persist "enable now, initialize later".
+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.

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

@@ -28,9 +28,10 @@ Name it `{memory_id}_{YYYYMMDD}_{smart_name}.md` and set
 `.easy-coding/memory/short/`, then register it with
 `memory-short-complete`. Never invent test results or commit hashes.
 
-When frozen TDD is enabled, add its threshold, lifecycle evidence, local changed-line result,
-and remote CI status to the short memory's execution evidence. When TDD is off, omit TDD fields
-entirely so ordinary tasks incur no additional memory work.
+When frozen TDD is enabled, add its threshold, lifecycle evidence, passed local unit-test result,
+and local changed-line result to the short memory's execution evidence. Remote CI status is not
+part of Harness acceptance or task memory. When TDD is off, omit TDD fields entirely so ordinary
+tasks incur no additional memory work.
 
 Ask the state API for `memory-instruction`. Distill only when it returns `action:distill`;
 otherwise record `no-op`. Long memory receives reusable facts only, not file dumps, transient

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

@@ -24,8 +24,10 @@ review dimension. A global record without source ownership cannot satisfy the ga
 When frozen TDD is enabled, add a passed review dimension named exactly `tdd` for each source
 task. Review whether RED/GREEN/REFACTOR (or characterization GREEN for pure refactors) is genuine,
 tests exercise changed behavior and boundaries, mocks do not merely mirror implementation, and
-the local/CI changed-line coverage gates share the frozen threshold. When TDD is off, do not add
-this dimension or raise the ordinary review depth.
+the local unit-test command genuinely passes while the changed-line coverage command uses the
+frozen baseline and threshold. Generated CI configuration may be reviewed when it changed, but
+remote CI status is never a review or acceptance dependency. When TDD is off, do not add this
+dimension or raise the ordinary review depth.
 
 ## Depth by workflow mode
 

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

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

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

@@ -26,10 +26,12 @@ Read-only tasks never enter this stage. Obtain fresh fingerprints before running
 - `strict`: run the project's full applicable lint, typecheck, test, and build gates.
 
 These rules remain unchanged when frozen TDD is off: do not discover JaCoCo reports, run the
-coverage tool, inspect GitLab, or add a coverage record.
+coverage tool, inspect GitLab, or add a coverage record. The explicit `type=tdd-init` task is an
+infrastructure exception: run its planned build/CI syntax checks and readiness tool, but do not
+measure repository-wide coverage or append TDD coverage evidence for unchanged production code.
 
-When frozen TDD is on, first run the planned Java unit command and generate JaCoCo XML, then run
-the same deterministic gate intended for GitLab:
+When frozen TDD is on, first run the planned local Java unit command and generate JaCoCo XML,
+then run the deterministic local acceptance gate:
 
 ```bash
 python3 .easy-coding/tools/easy_coding_java_coverage.py check \
@@ -41,10 +43,10 @@ The tool measures covered added/modified production Java executable lines only.
 comment, blank, import, and test-source lines are excluded by diff/JaCoCo intersection. Missing
 or ambiguous source files and reports older than their modified source fail; zero modified
 executable lines is explicit N/A. Always regenerate JaCoCo XML after the final source change.
-Record CI as pending until the remote pipeline actually passes; local green is not remote green.
 Never substitute `HEAD`, a mutable ref, project defaults, or current session settings for the
-task-frozen baseline SHA and threshold. GitLab must invoke the tool with the same two frozen
-values; a session override therefore requires the CI command/variable for this task to match it.
+task-frozen baseline SHA and threshold. `ec-tdd-init` still generates a GitLab job that can run
+the same tool, but remote pipeline execution and status are outside Harness acceptance. Never
+request an intermediate commit or push merely to obtain CI evidence.
 
 The main Agent may run commands inline. Dispatch verifier sub-agents only when checks are
 independent and parallel execution materially saves time or isolates specialist environments.
@@ -84,23 +86,17 @@ For TDD coverage, copy the tool output into `coverage`: `baseline_sha`, `covered
 `applicable:false` plus the tool's reason only for zero executable modified lines. A percentage
 below the frozen threshold fails even when ordinary tests pass.
 
-Append two coverage records per repository (and per Canonical source task): one with
-`coverage_scope:"local"`, and one with `coverage_scope:"gitlab"`. The GitLab record may be
-appended only after the remote job succeeds and must also include:
-
-```json
-{
-  "ci": {
-    "provider": "gitlab",
-    "pipeline_url": "https://gitlab.example/.../pipelines/123",
-    "job_name": "changed-line-coverage",
-    "status": "success"
-  }
-}
-```
-
-Both records must preserve the same task-frozen baseline and threshold. A local-only result,
-pending/failed pipeline, missing job identity, or synthetic remote pass cannot satisfy MEMORY.
+Append one coverage record with `coverage_scope:"local"` per repository (and per Canonical
+source task). The state gate also requires a passed local `check_type:"test"` record for the same
+owner. The coverage record preserves the task-frozen baseline and threshold. Do not append or
+wait for GitLab pipeline evidence; historical remote coverage records are ignored by acceptance
+without modifying or deleting the stored records.
+
+For `type=tdd-init`, the infrastructure receipt must already have been recorded during IMPLEMENT
+and reviewed with the rest of the implementation. Run only `easy_coding_tdd_readiness.py check`
+here. If it reports drift, return to IMPLEMENT to refresh the receipt and repeat REVIEW; never
+rewrite it inside VERIFICATION. The state gate requires `ready` before MEMORY. This does not
+enable TDD; report the explicit `ec-config`/`easy-coding config` next step.
 
 - Every must-test item has an executed check.
 - Bug fixes include a regression test when project infrastructure exists.

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

@@ -39,8 +39,11 @@ selection and reasons, allows the user to change it within the risk floor, and f
 ANALYSIS -> IMPLEMENT is applied.
 
 TDD resolves with the same session-over-project precedence and freezes its enabled flag and
-threshold on ANALYSIS -> IMPLEMENT. When off, it must add no CI scan, artifacts, commands,
-coverage work, or stronger acceptance. Use `ec-config` for all mode configuration.
+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.
 
 `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.
@@ -87,7 +90,10 @@ plan decision; Auto continues immediately. Both remove later waiting, not qualit
 
    When multiple selected tasks depend on the same target, disambiguate creation evidence with
    `<source-task-id>-><dependency-task-id>=<evidence>`.
-4. Match the user's intent against `current_task` and the active task list before resuming.
+4. When the user explicitly invokes `ec-tdd-init`, let that skill own preflight and create a
+   `type=tdd-init` code task only after scope confirmation. Do not reinterpret it as an ordinary
+   TDD-enabled feature task and do not require readiness before creating it.
+5. Match the user's intent against `current_task` and the active task list before resuming.
    If the user names or clearly matches another task, confirm the switch and call
    `claim-task --task-id <id> --agent <agent-id> --session-file <P>`. Do not execute task A
    under task B's request.
@@ -99,10 +105,10 @@ plan decision; Auto continues immediately. Both remove later waiting, not qualit
      to the requested deliverable. Feature, bugfix, refactor, performance, and workflow changes
      are code tasks. Use `doc`, `analysis`, or `report` only when the user explicitly requested
      a no-code deliverable; never downgrade a code request to the read-only completion path.
-5. Resume the matched/current task, then load only state-relevant assets. Do not read five full
+6. Resume the matched/current task, then load only state-relevant assets. Do not read five full
    memories at every startup; ANALYSIS searches memory metadata and opens relevant entries on
    demand.
-6. If another Agent last owned the task, summarize the stored handoff before continuing.
+7. If another Agent last owned the task, summarize the stored handoff before continuing.
 
 ## Stage dispatch
 

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

@@ -33,7 +33,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-reviewing` `ec-verification` — workflow stages
 - `ec-memory` — short/long memory archive
-- `ec-task-management` — task lifecycle panel · `ec-config` — Approval/Workflow/TDD settings · `ec-task-close` — interrupt a task
+- `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-no-harness` — bypass only Easy Coding for the current session
 - `ec-git` — git discipline · `ec-meta` — understand/customize the harness
 
@@ -49,9 +49,13 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   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. 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, local coverage, and
-  GitLab TEST-stage gate evidence.
+  freezes both. TDD may be enabled only after `ec-tdd-init` records valid infrastructure readiness;
+  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.
 - Confirmation-required edges use `pending_transition`; automatic edges use the restricted
   `auto-transition` API. A read-only task creates no test-strategy.md, never enters REVIEW,
   VERIFICATION, or MEMORY, and writes no task memory.

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

@@ -31,7 +31,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-reviewing` `/ec-verification` — workflow stages
 - `/ec-memory` — short/long memory archive
-- `/ec-task-management` — task lifecycle panel · `/ec-config` — Approval/Workflow/TDD settings · `/ec-task-close` — interrupt a task
+- `/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-no-harness` — bypass only Easy Coding for the current session
 - `/ec-git` — git discipline · `/ec-meta` — understand/customize the harness
 
@@ -47,9 +47,13 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   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. 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, local coverage, and
-  GitLab TEST-stage gate evidence.
+  freezes both. TDD may be enabled only after `ec-tdd-init` records valid infrastructure readiness;
+  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.
 - Confirmation-required edges use `pending_transition`; automatic edges use the restricted
   `auto-transition` API. A read-only task creates no test-strategy.md, never enters REVIEW,
   VERIFICATION, or MEMORY, and writes no task memory.