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

package/package.json

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

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

@@ -85,6 +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 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,
@@ -154,6 +159,9 @@ 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
+   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.
 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

@@ -53,8 +53,15 @@ advances every legal edge after mechanical gates.
 Workflow mode is independently configured as adaptive/fast/standard/strict; ANALYSIS freezes
 adaptive to a concrete mode, and every new code task still enters REVIEW. REVIEW evidence is
 bound to the final implementation fingerprint, VERIFICATION evidence is bound to implementation
-and config fingerprints, and MEMORY keeps the conditional long-memory threshold gate. The active task
-pointer lives in `sessions/{agent}-{session-id}.json` (with an agent-prefixed PPID fallback only
+and config fingerprints, and MEMORY keeps the conditional long-memory threshold gate.
+
+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.
+
+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);
 when the task reaches `COMPLETE` or `CLOSED`, the state API clears `current_task` so the
 session returns to Ready. Each task's stage persists in its `task.json`. Hooks inject the

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 12 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

@@ -93,6 +93,44 @@ independent write scopes. Better unit contracts reduce later REVIEW rework.
 
 Code tasks require `test-strategy.md`; explicit `doc`, `analysis`, and `report` tasks do not.
 
+## 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;
+- `.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.
+- 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.
+
+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.
+
+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.
+
 ## Workflow mode calculation
 
 Resolve configured mode from the state snapshot:

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

@@ -0,0 +1,68 @@
+---
+name: ec-config
+description: Inspect and configure Easy Coding project/session Approval, Workflow, and Java TDD modes.
+---
+
+# ec-config — mode configuration
+
+Communicate in the user's language. A bare invocation is read-only: show the configuration panel
+and available actions. Never mutate project or session settings without an explicit user choice.
+
+## Configuration panel
+
+Call `snapshot` and show project, session, effective, and frozen task values for:
+
+- `approval_mode`;
+- `workflow_mode`;
+- `tdd_enabled` and `tdd_coverage_threshold`.
+
+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:
+
+```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.
+
+## 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`.
+
+## 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>
+```
+
+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.
+
+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-implementing/SKILL.md

@@ -9,6 +9,16 @@ Use only after ANALYSIS has frozen `task.json.workflow_mode` to `fast`, `standar
 `strict`. Read `dev-spec.md`, the latest `plan` record in `execution.jsonl`, relevant RULES
 and ABSTRACT sections, and `test-strategy.md` for code tasks.
 
+If frozen `task.tdd_enabled` is not `true`, preserve the existing shift-left behavior exactly;
+do not load the Java coverage tool, require RED/GREEN/REFACTOR, inspect CI, or run extra test
+commands. TDD is an independent opt-in mode, not an implicit consequence of strict workflow.
+
+When frozen TDD is enabled, every feature/bug unit must capture a meaningful failing unit test
+before production code (RED), the smallest passing implementation (GREEN), and a green refactor.
+Pure refactors instead capture a passing characterization test before the change and rerun it
+afterward. Never fake RED evidence. Keep tests deterministic, boundary-focused, and minimally
+mocked, and design changed production code toward 100% unit coverage.
+
 Communicate with the user in the user's language.
 
 ## Non-negotiable gates
@@ -59,6 +69,7 @@ Sub-agents never dispatch other sub-agents or read `.easy-coding` workflow asset
 # Task Card
 ## Identity       Easy Coding implementation unit
 ## Workflow Mode  {fast|standard|strict}
+## TDD            {off | on, frozen changed-line threshold N%}
 ## Task           {unit description}
 ## Source Spec    {spec_id@revision + sha256 | NONE}
 ## Source Task    {source_task_id | NONE}

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

@@ -28,6 +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.
+
 Ask the state API for `memory-instruction`. Distill only when it returns `action:distill`;
 otherwise record `no-op`. Long memory receives reusable facts only, not file dumps, transient
 logs, routine command output, or speculation.

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

@@ -21,6 +21,12 @@ a blocking correctness finding. Every Canonical review record includes its `repo
 `source_task_id`; emit at least one current-fingerprint record per selected task and required
 review dimension. A global record without source ownership cannot satisfy the gate.
 
+When frozen TDD is enabled, add a passed review dimension named exactly `tdd` for each source
+task. Review whether RED/GREEN/REFACTOR (or characterization GREEN for pure refactors) is genuine,
+tests exercise changed behavior and boundaries, mocks do not merely mirror implementation, and
+the local/CI changed-line coverage gates share the frozen threshold. When TDD is off, do not add
+this dimension or raise the ordinary review depth.
+
 ## Depth by workflow mode
 
 - `fast`: main Agent performs one final-diff self-review across correctness, scope, tests, and

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

@@ -1,9 +1,9 @@
 ---
 name: ec-task-management
-description: View and manage Easy Coding tasks plus project/session approval and workflow-mode settings.
+description: View and manage Easy Coding task lifecycle, ownership, handoff, and closure.
 ---
 
-# ec-task-management — tasks and session modes
+# ec-task-management — task lifecycle
 
 Communicate with the user in the user's language. A bare invocation is read-only: show the
 panel and available actions, but do not mutate a session without an explicit choice.
@@ -13,44 +13,19 @@ panel and available actions, but do not mutate a session without an explicit cho
 Call the state API snapshot and show:
 
 - current task, stage, last Agent, and pending transition;
-- `project_approval_mode`, `session_approval_mode`, `effective_approval_mode`;
-- `project_workflow_mode`, `session_workflow_mode`, `configured_workflow_mode`;
-- task `concrete_workflow_mode` or ANALYSIS proposal when present;
+- task `concrete_workflow_mode` and frozen TDD state when present;
 - harness enabled/disabled state;
 - active and resumable tasks.
 - for Canonical-backed tasks: source Spec ID/revision/SHA, selected task IDs, repository
   bindings/baseline status, and pending dependency evidence.
 
-Explain precedence:
-
-`session override > project config > approval:guard / workflow:adaptive`
-
-## Session settings
-
-After explicit user selection:
-
-```bash
-# approval
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-approval-mode --mode approve|guard|confirm|auto --agent <agent-id> --session-file <P>
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-approval-mode --agent <agent-id> --session-file <P>
-
-# workflow
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py set-workflow-mode --mode adaptive|fast|standard|strict --agent <agent-id> --session-file <P>
-{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py clear-workflow-mode --agent <agent-id> --session-file <P>
-```
-
-Changing a session setting affects future ANALYSIS proposals. It does not silently rewrite a
-mode already frozen on an active task. During ANALYSIS, regenerate and show the proposal. During
-IMPLEMENT or REVIEW, use `raise-workflow-mode` for a justified increase; lowering is forbidden.
-From VERIFICATION, return to IMPLEMENT first so the raised mode receives fresh REVIEW evidence.
-
-Project settings are changed with `easy-coding config`, which edits both dimensions in one
-confirmed interaction.
+Mode inspection and configuration belongs to `ec-config`. If the user asks to change Approval,
+Workflow, TDD, or the TDD coverage threshold, route there and do not mutate those fields here.
 
 ## Task actions
 
 Support listing, creating, selecting, claiming, handing off, and closing tasks through the
-state API. Preserve pending transitions when merely changing approval mode. Never infer user
+state API. Preserve pending transitions when inspecting tasks. Never infer user
 acceptance from opening this panel.
 
 When creating from a Canonical Spec, call `inspect-dev-spec`, display the complete task and

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

@@ -0,0 +1,99 @@
+---
+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 used locally and remotely.
+
+## 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

@@ -25,6 +25,29 @@ Read-only tasks never enter this stage. Obtain fresh fingerprints before running
 - `standard`: run impacted lint/typecheck/test scopes and every must-test item.
 - `strict`: run the project's full applicable lint, typecheck, test, and build gates.
 
+These rules remain unchanged when frozen TDD is off: do not discover JaCoCo reports, run the
+coverage tool, inspect GitLab, or add a coverage record. The explicit `type=tdd-init` task is an
+infrastructure exception: run its planned build/CI syntax checks and readiness tool, but do not
+measure repository-wide coverage or append TDD coverage evidence for unchanged production code.
+
+When frozen TDD is on, first run the planned Java unit command and generate JaCoCo XML, then run
+the same deterministic gate intended for GitLab:
+
+```bash
+python3 .easy-coding/tools/easy_coding_java_coverage.py check \
+  --base <task.tdd_baselines[repo-id-or-project]> \
+  --threshold <task.tdd_coverage_threshold> [--report <jacoco.xml>]...
+```
+
+The tool measures covered added/modified production Java executable lines only. Deleted,
+comment, blank, import, and test-source lines are excluded by diff/JaCoCo intersection. Missing
+or ambiguous source files and reports older than their modified source fail; zero modified
+executable lines is explicit N/A. Always regenerate JaCoCo XML after the final source change.
+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.
+
 The main Agent may run commands inline. Dispatch verifier sub-agents only when checks are
 independent and parallel execution materially saves time or isolates specialist environments.
 Platform spawn rule: {{platform_spawn_instruction}}
@@ -48,7 +71,7 @@ Append one record per executed check:
 }
 ```
 
-`check_type` is one of `lint`, `typecheck`, `test`, or `build`. In `strict`, append current
+`check_type` is one of `lint`, `typecheck`, `test`, `build`, or (TDD only) `coverage`. In `strict`, append current
 evidence for all four types. When a type genuinely does not apply, record `applicable: false`
 and a non-empty `not_applicable_reason`; it does not count as the required applicable executed
 check, and must not be represented by an invented successful command.
@@ -58,6 +81,35 @@ do not append a later synthetic pass without rerunning the failed command.
 
 ## Coverage and acceptance
 
+For TDD coverage, copy the tool output into `coverage`: `baseline_sha`, `covered_lines`,
+`total_lines`, `percentage`, frozen `threshold`, `report_paths`, and `report_sha256`. Set
+`applicable:false` plus the tool's reason only for zero executable modified lines. A percentage
+below the frozen threshold fails even when ordinary tests pass.
+
+Append 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.
+
+For `type=tdd-init`, the infrastructure receipt must already have been recorded during IMPLEMENT
+and reviewed with the rest of the implementation. Run only `easy_coding_tdd_readiness.py check`
+here. If it reports drift, return to IMPLEMENT to refresh the receipt and repeat REVIEW; never
+rewrite it inside VERIFICATION. The state gate requires `ready` before MEMORY. This does not
+enable TDD; report the explicit `ec-config`/`easy-coding config` next step.
+
 - Every must-test item has an executed check.
 - Bug fixes include a regression test when project infrastructure exists.
 - Present changed scope, commands, results, and unverified items.

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

@@ -24,18 +24,27 @@ the stage graph. Pre-0.9 in-flight tasks may carry `workflow_mode_legacy:true` f
 review-evidence compatibility. Only `workflow_mode_legacy_direct_edge:true`, created from old
 lite semantics or an already-persisted edge, permits one IMPLEMENT -> VERIFICATION transition.
 
-## Two independent controls
+## Independent controls
 
 - `approval_mode = approve|guard|confirm|auto` controls whether a legal transition waits for a
   user. `confirm` waits only at ANALYSIS -> IMPLEMENT; after that, green REVIEW, VERIFICATION,
   MEMORY, and COMPLETE transitions advance automatically.
 - `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.
 
 Resolution order for each configured value is session override, then project config, then
 defaults (`guard`, `adaptive`). ANALYSIS resolves `adaptive` to a concrete mode, presents the
 selection and reasons, allows the user to change it within the risk floor, and freezes it when
 ANALYSIS -> IMPLEMENT is applied.
 
+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.
+
 `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.
 
@@ -81,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.
@@ -93,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

@@ -13,8 +13,10 @@ 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.
 
-- Ready: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to manage tasks or session settings
+- 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
 - Active task: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · `{current-task}` · `{workflow-state}`
 - Handoff: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
@@ -31,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/session panel and approval/workflow mode 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
 
@@ -45,6 +47,14 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   Confirm approval waits only at ANALYSIS -> IMPLEMENT, then advances green later stages
   automatically. Every new code task runs REVIEW; 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;
+  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, local coverage, and GitLab
+  TEST-stage evidence for production lines changed since the task baseline.
 - 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.
@@ -84,7 +94,7 @@ First run `ec-init`; daily work goes through `ec-workflow`.
 
 - Workflow state operations go through `{{platform_config_dir}}/hooks/easy_coding_state.py`;
   do not hand-edit session files, `current_task`, task `status`, `stage_history`,
-  `pending_transition`, workflow mode proposal/freeze fields, `memory_progress`, or `last_agent`.
+  `pending_transition`, workflow/TDD proposal or freeze fields, `memory_progress`, or `last_agent`.
 - The hook injects `[easy-coding:session-file:P]`; pass that path to the state script with
   `--session-file <P>` when changing the current task or stage.
 - Workflow session files live at `{{workflow_state_path}}`; the CLI only installs files and

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

@@ -13,8 +13,10 @@ 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.
 
-- Ready: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · Ready · Use `ec-workflow` to start or resume a task, `ec-brainstorming` to brainstorm, or `ec-task-management` to manage tasks or session settings
+- 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
 - Active task: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · `{current-task}` · `{workflow-state}`
 - Handoff: > **Easy Coding** · **Approval: {approval-mode}** · **Workflow: {workflow-mode}** · `{current-task}` · `{workflow-state}` · Handoff -> `{source-agent}`
@@ -29,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/session panel and approval/workflow mode 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
 
@@ -43,6 +45,14 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   Confirm approval waits only at ANALYSIS -> IMPLEMENT, then advances green later stages
   automatically. Every new code task runs REVIEW; 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;
+  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, local coverage, and GitLab
+  TEST-stage evidence for production lines changed since the task baseline.
 - 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.
@@ -82,7 +92,7 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
 
 - Workflow state operations go through `{{platform_config_dir}}/hooks/easy_coding_state.py`;
   do not hand-edit session files, `current_task`, task `status`, `stage_history`,
-  `pending_transition`, workflow mode proposal/freeze fields, `memory_progress`, or `last_agent`.
+  `pending_transition`, workflow/TDD proposal or freeze fields, `memory_progress`, or `last_agent`.
 - The hook injects `[easy-coding:session-file:P]`; pass that path to the state script with
   `--session-file <P>` when changing the current task or stage.
 - Workflow session files live at `{{workflow_state_path}}`; the CLI only installs files and