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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "0.9.1",
+  "version": "0.10.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,6 +85,9 @@ 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.
 - **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 +157,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
@@ -73,6 +80,21 @@ frozen concrete mode, and any `pending_transition`; `dev-spec.md` is the human-r
 /`review`/`verify`/`handoff` records). Because plan and log live on disk, not in an agent's
 context window, a task survives session end and agent switches with zero information loss.
 
+## Canonical Spec integration
+
+An `easy-dev-spec/v1` Canonical Spec is a read-only design source, not progress storage.
+`inspect-dev-spec` validates the document with the protocol implementation pinned from
+`easy-dev-spec@7eb9b64`; after explicit task selection, `select-dev-spec-scope` returns one
+deterministic producer-compatible closure per repository, and `create-task-from-spec` creates one
+Harness task with the source ID/revision/SHA, selected task IDs, portable repository bindings,
+baseline classifications, and dependency evidence.
+
+ANALYSIS derives local `dev-spec.md`, `execution.jsonl`, and `test-strategy.md` for the selected
+consumption closure. Canonical-backed units keep repository, source task/steps, files, symbols,
+and test commands. Hard dependencies shape the Unit DAG, READY contracts can run in parallel,
+and integration dependencies block end-to-end completion until evidence is recorded. The source
+Canonical Spec is never rewritten with Harness runtime state.
+
 ## Memory system
 
 Short memory: one schema-v2 file per task, sliding window (max 10, keep 5). Long memory:
@@ -93,9 +115,10 @@ demand.
 continues. All platform-agnostic artifacts (dev-spec, execution.jsonl, task.json, memory)
 make cross-agent handoff lossless. `task.json.last_agent` records the last owner so a new
 agent knows a task was handed off rather than self-interrupted.
-Owner identities use platform namespaces. Codex collaboration paths such as `/root` and
-`/root/...` normalize to `codex`, so internal Codex delegation is not mistaken for a cross-agent
-handoff; existing task files with those paths remain compatible without migration.
+Owner identities use platform namespaces. Codex root identities such as `root`, `/root`, and
+their collaboration subpaths normalize to `codex`, so internal Codex delegation is not mistaken
+for a cross-agent handoff; existing task files with those identities remain compatible without
+migration.
 
 Handoff is target-less. The leaving agent writes a `handoff` record with `from`, `stage`,
 `summary`, and `timestamp`, then releases its session pointer. It does not know or record 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 14 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

@@ -21,6 +21,24 @@ Communicate with the user in the user's language.
 4. Inspect concrete code paths and tests. Expand context only when evidence reveals another
    dependency or risk.
 
+For a task with `task.json.spec_source`, re-run `inspect-dev-spec` against the stored source and
+every stored `task.repo_paths` repository binding. The schema, spec ID, revision, and SHA-256
+must still match. Then call the read-only selector for the exact stored selection:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py inspect-dev-spec \
+  --spec <stored-source> --repo-path <repo-id>=<stored-path> [--repo-path <repo-id>=<stored-path>]...
+
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py select-dev-spec-scope \
+  --spec <stored-source> --spec-task <selected-task-id> [--spec-task <selected-task-id>]...
+```
+
+Load only the returned per-repository consumption closures: manifest/global context, selected
+task and repository sections, related contracts, direct dependency summaries, selected
+changes/steps/tests, and relevant integration rows. Never replace the selector with a whole-file
+read. `scope-drifted` requires current-code conflict analysis before confirmation;
+`baseline-unavailable` or unresolved repository identity remains blocked in ANALYSIS.
+
 ## Analysis artifacts
 
 Copy `.easy-coding/templates/dev-spec-skeleton.md` first, then replace every `[[EC_TODO:...]]`.
@@ -43,16 +61,68 @@ Execution plan records use:
     "acceptance_criteria": ["observable result"],
     "test_points": ["targeted check"],
     "contracts": ["input/output/invariant or none"],
-    "risks": ["known risk or none"]
+    "risks": ["known risk or none"],
+    "repo_id": "R1",
+    "source_task_id": "R1-T1",
+    "source_step_ids": ["S1"],
+    "symbols": ["Class#method"],
+    "test_commands": ["exact source test command", "optional local command"]
   }]
 }
 ```
 
+The five source fields are mandatory only for Canonical-backed code units. Default to one unit
+per selected Spec task. A split may cover only one `repo_id` and one `source_task_id`, and all
+units together must cover every source step exactly once. Map selected hard dependencies into
+`depends_on`, contract dependencies into `contracts`, and dependency levels into
+`parallel_groups`.
+
+Canonical-backed `dev-spec.md`, `execution.jsonl`, and `test-strategy.md` are runtime-derived
+evidence, not a second maintained Spec. Record the source path/ID/revision/SHA, selected tasks
+and repositories, baseline/conflict result, Unit mapping, source test mapping, and pending
+integration edges.
+
+Every source test command remains mandatory. Additional commands from the current repository are
+allowed only when `test-strategy.md` records why the Canonical command alone is insufficient.
+For every selected source test, `test-strategy.md` must spell out its Test ID, source task ID,
+owning Unit ID, repository-relative test file, and exact Canonical command; the state gate checks
+these markers mechanically.
+
 Prefer one coherent unit over artificial file-level splitting. Use parallel only for truly
 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.
+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.
+
+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.
+
+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:
@@ -120,3 +190,5 @@ controls waiting; it never changes the selected execution depth.
 - No code task with an empty change scope.
 - No unit without acceptance criteria, test points, contracts, and risks.
 - No transition without a valid workflow proposal.
+- No Canonical-backed transition with changed source SHA, unresolved repository identity,
+  incomplete selected-task coverage, or an open Unit/Step/File/Symbol/Test traceability gap.

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

@@ -0,0 +1,54 @@
+---
+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.
+
+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.
+
+## 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.

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

@@ -44,6 +44,9 @@ with `.easy-coding/sessions/` always excluded. The CLI already added it to `.git
    `repo_paths`), the commit/push covers every involved repo. Read `repo_paths` from the
    current task state to locate each checkout, check changes, and commit/push them as one
    coherent change set — do not leave a sub-repo behind.
+   For Canonical-backed tasks, this set is exactly the repositories referenced by
+   `selected_spec_tasks` and resolved in `spec_repositories`; unselected Spec repositories stay
+   out of scope.
 5. **Supermodule two-step commits.** If the current repo has `.gitmodules`, or the current
    task touches a git submodule path, treat each submodule as an independent git boundary:
    commit and push child repos first, then commit and push the parent gitlink update. If a
@@ -59,6 +62,7 @@ with `.easy-coding/sessions/` always excluded. The CLI already added it to `.git
 - Do not commit `spec/dev/` unless the user explicitly asks.
 - Do not omit managed `easy-coding upgrade` changes merely because they were created outside
   the current agent turn.
+- Never modify or stage the source Canonical Spec merely to record Harness execution progress.
 - In a supermodule task launched from the parent root, parent `.easy-coding/` belongs to the
   parent git. Child `.easy-coding/memory/` changes created by memory archive belong to the
   owning child git and must be committed before the parent gitlink update.

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,7 +69,13 @@ 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}
+## Repository     {repo_id + resolved repository root | current project}
+## Source Steps   {source_step_ids | NONE}
+## Symbols        {symbols | confirmed local symbols}
 ## Editable Scope {unit.files | NONE — read-only}
 ## Acceptance     {unit.acceptance_criteria}
 ## Test Points    {unit.test_points and exact targeted commands}
@@ -68,17 +84,23 @@ Sub-agents never dispatch other sub-agents or read `.easy-coding` workflow asset
 ## Coding Rules   {pre-digested RULES sections}
 ## Architecture   {pre-digested ABSTRACT sections}
 ## Output
-changed_files[], summary, deliverable|null, issues[], needs_attention[]
+status:"completed", repo_id|null, source_task_id|null, changed_files[], summary,
+deliverable|null, issues:[], needs_attention:[]
 ```
 
 ## Dispatch and result loop
 
-1. Append a `dispatch` record before work begins.
+1. Append a `dispatch` record before work begins. Canonical-backed records include `repo_id` and
+   `source_task_id`; resolve every file relative to `task.repo_paths[repo_id]` before dispatch.
 2. Execute according to dependency order and selected owner.
 3. Run targeted unit tests and self-audit scope, contracts, TODOs, and introduced warnings.
-4. Append one `result` record. Include unresolved issues rather than hiding them.
+4. Append one `result` record. Only a successful unit uses `status:"completed"`; include
+   unresolved issues rather than hiding them, and do not advance while `issues` or
+   `needs_attention` is non-empty.
 5. If a result changes a cross-unit contract, stop dependent units and return to ANALYSIS.
 6. For parallel units, detect overlapping writes before advancing.
+7. If implementation needs a file, symbol, repository, or source step outside the mapped
+   Canonical change set, stop and return to ANALYSIS instead of expanding scope implicitly.
 
 Do not emit a progress message for every trivial edit. Report at unit boundaries to reduce
 conversation overhead while keeping work observable.

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

@@ -14,6 +14,19 @@ Every new code task enters REVIEW. Read-only tasks do not. Obtain the current fi
 Review the final diff against `dev-spec.md`, RULES, unit acceptance criteria, tests, contracts,
 and obvious security risks. Every finding cites `file:line`.
 
+For Canonical-backed tasks, group evidence by `repo_id` and `source_task_id`. Every selected
+Spec task needs an implementation result and source test evidence; file references remain
+repo-relative within the owning repository. Missing or expanded source change/step coverage is
+a blocking correctness finding. Every Canonical review record includes its `repo_id` and
+`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
@@ -67,6 +80,8 @@ Fast and Standard normally use `combined`; Strict uses at least two distinct dim
   "reviewer": "main-or-independent-agent",
   "implementation_fingerprint": "<state-api value>",
   "timestamp": "<ISO-8601>",
+  "repo_id": "<canonical repo-id; omit for non-Canonical tasks>",
+  "source_task_id": "<canonical task-id; omit for non-Canonical tasks>",
   "findings": []
 }
 ```

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,40 +13,22 @@ 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
+dependency selection, then call `select-dev-spec-scope` and `create-task-from-spec` only after
+explicit user selection. Multiple selected Spec tasks still create one Harness task, while the
+selector returns one deterministic consumption closure per selected repository.

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

@@ -25,6 +25,27 @@ 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.
+
+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}}
@@ -42,11 +63,13 @@ Append one record per executed check:
   "passed": true,
   "implementation_fingerprint": "<state-api value>",
   "config_fingerprint": "<state-api value>",
-  "timestamp": "<ISO-8601>"
+  "timestamp": "<ISO-8601>",
+  "repo_id": "<canonical repo-id; omit for non-Canonical tasks>",
+  "source_task_id": "<canonical task-id; omit for non-Canonical tasks>"
 }
 ```
 
-`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.
@@ -56,6 +79,29 @@ 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.
+
 - 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.
@@ -64,5 +110,26 @@ do not append a later synthetic pass without rerunning the failed command.
   user wait.
 - A reported in-scope problem returns to IMPLEMENT; out-of-scope work becomes a separate task.
 
+For Canonical-backed tasks, run each repository's commands from `task.repo_paths[repo_id]` and
+cover every selected task's source test IDs. Report pending integration edges separately from
+local green checks. They do not block local implementation evidence, but the state API blocks
+`VERIFICATION -> MEMORY` until evidence is recorded with `satisfy-spec-dependency`. Never claim
+end-to-end completion while an integration edge remains pending. Every Canonical verify record
+includes the owning `repo_id` and `source_task_id`; duplicate check names in different source
+tasks remain separate evidence records. In `strict`, every involved repository independently
+records all four check types; a repository-specific non-applicable record still needs its reason
+and source ownership.
+
+Record the exact integration edge only after its evidence exists:
+
+```bash
+{{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py satisfy-spec-dependency \
+  --task-id <harness-task-id> \
+  --source-task <source-spec-task-id> \
+  --spec-task <target-spec-task-id> \
+  --evidence "<verifiable evidence>" \
+  --agent <agent>
+```
+
 The state API rejects VERIFICATION -> MEMORY unless all evidence for the current implementation
 and config fingerprints is green.

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

@@ -24,18 +24,24 @@ 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. When off, it must 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.
 
@@ -52,7 +58,36 @@ plan decision; Auto continues immediately. Both remove later waiting, not qualit
    - Present with `status != "COMPLETE"`: invoke `{{skill_trigger}}ec-init`, then stop.
    - `[easy-coding:upgrade-init-pending:X]`: recommend `{{skill_trigger}}ec-init` for vX
      adaptation, but allow the user to continue; this reminder is not a workflow block.
-3. Match the user's intent against `current_task` and the active task list before resuming.
+3. When the user explicitly references a Dev-Spec, run the read-only `inspect-dev-spec` command
+   before ordinary task creation. For `protocol=canonical-v1`, show every task ID, repository,
+   title, dependency, and baseline status; never select all tasks by default. After the user
+   chooses one or more tasks and resolves repository paths or omitted hard-dependency evidence,
+   call `create-task-from-spec` once for the complete selection. A document without a Canonical
+   manifest remains a legacy ANALYSIS input for an ordinary task. A malformed, DRAFT, or otherwise
+   non-READY Canonical Spec stays blocked and must never be downgraded to the legacy route. Never
+   edit the source Spec.
+
+   ```bash
+   {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py inspect-dev-spec \
+     --spec <path> [--repo-path <repo-id>=<path>]...
+
+   {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py select-dev-spec-scope \
+     --spec <path> --spec-task <task-id> [--spec-task <task-id>]...
+
+   {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py create-task-from-spec \
+     --spec <path> --spec-task <task-id> [--spec-task <task-id>]... \
+     --task-id <harness-task-id> --type <type> --title <title> \
+     --repo-path <repo-id>=<path> [--dependency-evidence <dependency-id>=<evidence>]... \
+     --agent <agent-id> --session-file <P>
+   ```
+
+   `select-dev-spec-scope` is read-only and may run only after explicit task selection. Its
+   per-repository payload is the authoritative ANALYSIS context; do not load unselected task
+   bodies from the source document.
+
+   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.
    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.
@@ -64,10 +99,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.
-4. Resume the matched/current task, then load only state-relevant assets. Do not read five full
+5. 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.
-5. If another Agent last owned the task, summarize the stored handoff before continuing.
+6. If another Agent last owned the task, summarize the stored handoff before continuing.
 
 ## Stage dispatch