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

package/package.json

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

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

@@ -16,6 +16,17 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
   file. All context you need is already in the task card.
 - Make no workflow stage-transition decisions. You do not know the state machine exists.
 - Follow the coding rules and architecture context embedded in the card.
+- Follow the task card's `Local Baseline`: match nearby naming, control flow, null/error handling,
+  layering, object modeling, method granularity, literal usage, and comment style unless a stated
+  correctness, security, requirement, or hard-rule reason requires a deviation.
+- Treat the task card's `Code Comments` author value and field/member/constant rules as mandatory.
+- Do not add generic defensive null checks, speculative abstractions/layers, fragmented one-use
+  micro-methods, or a constant that exists only to hold one getter return.
+- Local, obvious magic values are allowed when they match surrounding code; create constants for
+  reuse, stable domain/config/protocol semantics, or established project convention.
+- Every method and field in a new core Java class, and every added or materially modified method
+  or field in an existing core Java class, must have meaningful Javadoc; comment complex logic
+  where intent or constraints are not obvious.
 - Treat acceptance criteria, test points, contracts, and risks in the card as required inputs.
 - Run the exact targeted checks requested by the card and report their real outcome.
 - Preserve each existing file's original encoding; never silently convert.

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

@@ -15,7 +15,12 @@ dimension named in your task card. Your reply IS the return value.
   - correctness → does the implementation match the dev-spec requirement? edge cases,
     null/empty handling, races, off-by-one.
   - compliance → does the code obey the RULES sections in the card? naming, format, comment
-    language, error handling.
+    language, error handling, and the evidenced Local Baseline.
+- Do not request defensive null checks, abstraction, constant extraction, or legacy-wide comment
+  cleanup solely as generic best practice. Flag unjustified local-style deviations, speculative
+  layers, fragmented one-use micro-methods, constants created only for a getter return, and
+  missing Javadoc on any method/field in a new core Java class or any added/materially modified
+  method/field in an existing core Java class.
 - `error` means a demonstrated acceptance, contract, security, or build failure. Use `warning`
   for a credible risk and `info` for non-blocking maintainability advice.
 

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

@@ -15,6 +15,17 @@ Hard constraints:
   the card.
 - Make no workflow stage-transition decisions; you do not know the state machine exists.
 - Follow the coding rules and architecture context embedded in the card.
+- Follow the task card's "Local Baseline": match nearby naming, control flow, null/error handling,
+  layering, object modeling, method granularity, literal usage, and comment style unless a stated
+  correctness, security, requirement, or hard-rule reason requires a deviation.
+- Treat the task card's "Code Comments" author value and field/member/constant rules as mandatory.
+- Do not add generic defensive null checks, speculative abstractions/layers, fragmented one-use
+  micro-methods, or a constant that exists only to hold one getter return.
+- Local, obvious magic values are allowed when they match surrounding code; create constants for
+  reuse, stable domain/config/protocol semantics, or established project convention.
+- Every method and field in a new core Java class, and every added or materially modified method
+  or field in an existing core Java class, must have meaningful Javadoc; comment complex logic
+  where intent or constraints are not obvious.
 - Treat acceptance criteria, test points, contracts, and risks in the card as required inputs.
 - Run the exact targeted checks requested by the card and report their real outcome.
 - Preserve each existing file's original encoding; never silently convert.

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

@@ -14,7 +14,12 @@ Stance:
   - correctness -> does the implementation match the dev-spec requirement? edge cases,
     null/empty handling, races, off-by-one.
   - compliance -> does the code obey the RULES sections in the card? naming, format, comment
-    language, error handling.
+    language, error handling, and the evidenced Local Baseline.
+- Do not request defensive null checks, abstraction, constant extraction, or legacy-wide comment
+  cleanup solely as generic best practice. Flag unjustified local-style deviations, speculative
+  layers, fragmented one-use micro-methods, constants created only for a getter return, and
+  missing Javadoc on any method/field in a new core Java class or any added/materially modified
+  method/field in an existing core Java class.
 - error means a demonstrated acceptance, contract, security, or build failure. Use warning
   for a credible risk and info for non-blocking maintainability advice.
 

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,
@@ -142,7 +147,14 @@ agent must be able to see what was generated and on what evidence.
    - Naming conventions actually in use (scan representative files)
    - Comment language: if more than 70% of existing comments are Chinese, the rule is
      "comments in Chinese"; same logic for English; mixed → follow each file's dominant language
-   - Error handling style, import ordering, formatter/linter in use (read their configs)
+   - Null/empty handling and error-handling style, including where the project intentionally
+     relies on upstream contracts instead of adding defensive checks
+   - Existing class/method extraction granularity and architecture boundaries; do not turn a
+     preference for single responsibility into a generic demand for many one-use helpers
+   - Literal and constant conventions, including when local magic values are accepted and when
+     a stable domain/config/protocol value is promoted to a named constant
+   - Javadoc/doc-comment coverage for core code and the inline-comment style used for complex logic
+   - Import ordering and formatter/linter in use (read their configs)
    Structure as one section per language plus a General section. Every rule must be
    mechanically checkable — "be clean" is not a rule; "exported functions carry explicit
    return types" is.
@@ -154,6 +166,10 @@ 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, 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
@@ -182,7 +198,9 @@ agent must be able to see what was generated and on what evidence.
    - TEST_STRATEGY.md (skeleton for the chosen framework)
 3. **Skip ABSTRACT.md** — no architecture exists yet. Note in init_log:
    "ABSTRACT pending; ec-memory backfills after the first substantive task." (ec-memory
-   detects the missing file during MEMORY and generates it from the then-current code.)
+   detects the missing file during MEMORY and uses the explicit `missing-abstract` assessment
+   exception to generate it from the then-current code. This one-time backfill does not enable
+   routine per-task architecture updates.)
 4. Memory migration probe and memory init, same as iterative steps 5-7.
 5. Recommend: design first with `{{skill_trigger}}ec-brainstorming`, then build via
    `{{skill_trigger}}ec-workflow`.

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

@@ -49,12 +49,24 @@ automatic edges. A validated read-only `doc` / `analysis` / `report` task also a
 from IMPLEMENT after its full deliverable is shown, without REVIEW, VERIFICATION, MEMORY, or
 task memory. Approval mode controls non-mechanical edge waiting: approve confirms each edge,
 guard confirms two critical gates, confirm waits only at ANALYSIS -> IMPLEMENT, and auto
-advances every legal edge after mechanical gates.
+advances every legal edge after mechanical gates. After green VERIFICATION, Harness freezes an
+acceptance checkpoint. A later code diff temporarily pauses every mode so the exact digest can be
+accepted; unchanged `confirm`/`auto` tasks remain automatic.
 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 an accepted post-checkpoint diff records its authorization plus
+carry-forward/targeted/waived policy without forcing a second REVIEW. 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, 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);
 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
@@ -70,35 +82,45 @@ stage in `task.json`; no data is lost. Each task folder is self-contained.
 Each task is a folder. `task.json` is metadata, including the current stage, workflow proposal,
 frozen concrete mode, and any `pending_transition`; `dev-spec.md` is the human-readable plan;
 `execution.jsonl` is an append-only plan-and-log (one `plan` record, then `dispatch`/`result`
-/`review`/`verify`/`handoff` records). Because plan and log live on disk, not in an agent's
+/`review`/`verify`/`acceptance`/`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.
+An `easy-dev-spec/v1` Canonical Spec separates frozen static design from a shared execution ledger.
 `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,
+Harness task with source locator mode, ID/design revision and digest, document digest, execution
+revision, selected task IDs, 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.
+and integration dependencies block end-to-end completion until evidence is recorded. Harness
+keeps detailed evidence locally and projects cross-application Task/Step/dependency outcomes into
+`EDS:EXECUTION` through one CAS/idempotent writer. Static changes use revision + READY +
+`sync-spec-design`; agents never hand-edit the machine ledger. Explicit external locators are
+allowed and rebind only by exact Canonical identity. Source tasks stay `implemented` after local
+checks and become `verified` only when VERIFICATION -> MEMORY is applied under explicit or
+standing approval-mode authorization; the shared event includes the acceptance digest.
 
 ## Memory system
 
 Short memory: one schema-v2 file per task, sliding window (max 10, keep 5). Long memory:
 three files (index + business + technical), distilled from out-of-window short memories with
-explicit conflict resolution. ABSTRACT.md is backfilled/updated when memory distillation
-detects an architecture change.
+explicit conflict resolution. Daily tasks only produce facts. When distillation runs, MEMORY
+performs a separate, default-no-op architecture assessment and updates only affected ABSTRACT
+sections when frozen evidence proves the architecture cognition is stale. A missing ABSTRACT
+after the first substantive startup task is the only non-distillation backfill exception.
 
 ## Project knowledge — four layers
 
 Identity (SOUL, rarely changes) · Constraints (RULES, stable) · Cognition (ABSTRACT, updated
-on architecture change) · Memory (short + long, updated every task). ec-workflow always reads
+only after evidence-backed architecture assessment) · Memory (short every task, long only on
+distillation). Stable convention changes become RULES candidates in technical memory, never
+silent RULES edits. ec-workflow always reads
 SOUL + RULES + recent short memory; ec-analysis loads ABSTRACT and matching long memory on
 demand.
 

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

@@ -21,13 +21,25 @@ 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:
+Apply a progressive cost budget while doing this work. A likely Fast task reads only the nearest
+comparable implementation, its direct contracts, and targeted tests. Standard reads the affected
+module closure. Expand into cross-module or repository-wide context only after concrete evidence
+shows the compound high-risk and complexity signals required for Strict. Do not scan unrelated
+repositories, the full Spec, broad Git history, or every architecture section merely to prove
+that a bounded task might be complicated.
+
+For a task with `task.json.spec_source`, re-run `inspect-dev-spec` against the stored source, exact
+`selected_spec_tasks`, and only their stored `task.repo_paths` bindings. Schema, Spec ID, design
+revision, and `design_sha256` must still match. A changed `document_sha256` with the same design is
+normal shared progress; refresh `execution_revision` without invalidating plan/review/verify
+evidence. An execution revision rollback is blocking. Then call the selector once for the exact
+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>]...
+  --spec <stored-source> \
+  --spec-task <selected-task-id> [--spec-task <selected-task-id>]... \
+  [--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>]...
@@ -36,19 +48,66 @@ must still match. Then call the read-only selector for the exact stored selectio
 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.
+read. Treat the Canonical closure as frozen design, not as a prompt to design the task again:
+
+- `exact` and `scope-unchanged` use the fast projection path. Confirm the selected paths, symbols,
+  and test entry points, then map the closure into Units, `test-strategy.md`, and the derived
+  `dev-spec.md` in one pass. Do not reselect interfaces, fields, task boundaries, Steps, or Tests,
+  and do not ask questions already answered by the source Spec.
+- `scope-drifted` reads and analyzes only changed files and symbols in the selected task scope.
+  Escalate to a static design revision only when that evidence changes a frozen contract or task
+  boundary; unrelated repository or completed-task changes are background, not current drift.
+- `baseline-unavailable` or unresolved selected-repository identity remains blocked in ANALYSIS.
+
+Use shared execution dependency status directly. Do not inspect another local Harness task or Git
+history to re-prove a completed hard dependency, and do not repeat dependency or baseline
+explanations after the selected inspection has recorded them.
+
+## Local implementation baseline
+
+For every code unit, inspect the nearest same-module, same-role implementation before planning.
+Record a concise `local_baseline` covering only evidenced conventions that affect this change:
+naming and control flow, null/empty and error handling, layering and dependency direction, object
+modeling, method extraction granularity, literal/constant usage, and comments/Javadoc. Prefer the
+closest comparable code over a repository-wide average. Explicit requirements, correctness,
+security, and project hard rules still take precedence; otherwise do not replace safe local
+conventions with generic best practices.
+
+Do not ask the user to choose a style already answered consistently by comparable code. Ask only
+when local evidence conflicts or a deviation can change the contract, risk, or acceptance result.
 
 ## Analysis artifacts
 
 Copy `.easy-coding/templates/dev-spec-skeleton.md` first, then replace every `[[EC_TODO:...]]`.
-Keep every mandatory section. `### Workflow Mode` is required.
+Keep every mandatory section. The `### 决策闭环` (Decision Closure) and `### Workflow Mode`
+sections are required. The decision section must contain exactly one standalone
+`decision_status: closed` marker, and no other `decision_status` marker may appear elsewhere in
+the document. Record every material question and its resolved conclusion in that section, or
+record that no extra decision was needed.
+
+## Decision closure before implementation
+
+Treat uncertainty that can change the technical route, public or internal contract, data model,
+state flow, edit scope, compatibility behavior, or acceptance criteria as a material open
+question. While any such question remains:
+
+1. stay in ANALYSIS and ask the user focused questions, preferably one decision at a time;
+2. do not present a final analysis summary, propose the final Workflow Mode, request
+   ANALYSIS -> IMPLEMENT, or suggest that implementation can begin;
+3. update the Dev-Spec with each confirmed answer and its evidence;
+4. use `decision_status: open` while the artifact is still being developed, then replace it with
+   the single `decision_status: closed` marker only after every material question is resolved.
+
+Risks, integration work that is intentionally deferred by a frozen Spec, and environmental
+verification limits are not automatically open questions. Describe them as risks or explicit
+acceptance boundaries. Never use `closed` to hide a decision that still needs the user.
 
 Execution plan records use:
 
 ```json
 {
   "type": "plan",
+  "spec_design_sha256": "<Canonical design digest; omit for ordinary tasks>",
   "strategy": "single|sequential|parallel",
   "units": [{
     "id": "U1",
@@ -62,6 +121,7 @@ Execution plan records use:
     "test_points": ["targeted check"],
     "contracts": ["input/output/invariant or none"],
     "risks": ["known risk or none"],
+    "local_baseline": ["evidenced local convention and source path"],
     "repo_id": "R1",
     "source_task_id": "R1-T1",
     "source_step_ids": ["S1"],
@@ -78,21 +138,70 @@ units together must cover every source step exactly once. Map selected hard depe
 `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
+evidence, not a second maintained Spec. Record the source path/path mode/ID/design revision and
+digest, current document digest/execution revision/writeback status, selected tasks
 and repositories, baseline/conflict result, Unit mapping, source test mapping, and pending
 integration edges.
 
+The required skeleton is a mechanical artifact schema. For a Canonical-backed task it is filled
+from the selected closure and current-code delta; it must never become a second round of Spec
+authoring.
+
 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.
+Prefer one coherent unit over artificial file-level splitting. Do not split a class or method by
+line count, or create many one-use helpers, merely to make the plan look modular. Extract only a
+clear semantic boundary, reuse point, or independently testable responsibility. 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.
+For a `type=tdd-init` task, treat frozen TDD as off even if the project/session requests it. That
+task is the sole exception allowed to inspect and plan build/CI coverage infrastructure while TDD
+is off. Its scope is infrastructure only: never plan historical business-test backfill or a
+repository-wide coverage target, and explicitly record `coverage scope: changed production lines`.
+
+When TDD is disabled, stop here: do not inspect GitLab CI or JaCoCo, do not add TDD fields or
+extra tests, and do not strengthen the selected Workflow Mode's ordinary acceptance depth. This
+zero-cost rule applies to ordinary tasks, not the explicit `tdd-init` infrastructure task above.
+
+When TDD is enabled for a Java code task, make `test-strategy.md` record:
+
+- detected Java/JUnit build system, exact unit-test command, production/test source roots, and
+  JaCoCo XML paths;
+- immutable Git baseline SHA and the configured changed-production-line threshold; design tests
+  toward 100% while treating the threshold as the mechanical minimum;
+- feature/bug RED -> GREEN -> REFACTOR evidence, or for pure refactors a pre-change
+  characterization GREEN -> post-change GREEN sequence without inventing a RED failure;
+- the local unit-test command and local changed-line acceptance command. Record that
+  `ec-tdd-init` generated the GitLab TEST-stage job, but remote execution, pipeline identity, and
+  status are non-blocking and never require an intermediate commit or push. Include these exact,
+  language-independent contract markers: `local_test_gate: required` and
+  `remote_ci_acceptance: non-blocking`.
+- current `tdd_readiness_status=ready`; 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 the local command with that exact SHA and the frozen
+threshold. The generated GitLab job remains parameterized for infrastructure parity, but the
+Harness acceptance plan never waits for remote CI. Never use a mutable `HEAD` fallback at
+verification time. Non-Canonical TDD is limited to one Git repository; multi-repository TDD must
+use Canonical repository bindings.
+
+Also append a `### TDD Mode` section to `dev-spec.md` with enabled state, frozen threshold,
+baseline, local unit-test gate, local coverage gate, generated GitLab job as non-blocking
+infrastructure, and lifecycle evidence. Do not add this section when TDD is disabled.
+
+If the task is not a Java project, explain that Java-only TDD cannot be activated and obtain a
+mode decision before advancing. The CLI never installs JaCoCo or edits CI automatically.
+
 ## Workflow mode calculation
 
 Resolve configured mode from the state snapshot:
@@ -110,19 +219,30 @@ Use its `minimum_mode` and `reasons` as the proposal floor. You may raise this r
 uncertainty or user preference requires more rigor, but never lower or replace it with a
 self-reported floor. The state API rechecks the floor when the proposal is saved and frozen.
 
-The calculation classifies:
-
-- `fast`: one low-risk unit, local behavior, no public contract/schema/security/concurrency or
-  migration impact, targeted test available.
-- `standard`: ordinary multi-file feature/fix, bounded contract impact, existing patterns and
-  impacted tests available.
-- `strict`: state machine, configuration/schema migration, security/payment/data-loss risk,
-  public or cross-repository contract, broad concurrency, platform generators, or uncertain
-  blast radius.
+The calculation is intentionally Standard-centered:
+
+- `fast`: one coherent, non-parallel unit in one actually modified repository, at most five
+  changed files, no explicit high-risk signal, and no public or cross-repository contract impact.
+  Small parameter changes, bounded field/mapping edits, and a few ordinary model files should
+  normally remain Fast.
+- `standard`: the default for ordinary business work. Multiple units/files, bounded compatibility
+  work, actual but contained multi-repository changes, broad low-risk work, and bounded high-risk
+  work remain Standard.
+- `strict`: requires both an explicit high-risk signal and concrete complexity/blast-radius
+  evidence. Complexity means actual multi-repository edits, at least four units, at least ten
+  changed files, or a public/cross-repository contract. Parallel execution is a Standard signal
+  by itself. Generic domain words in a risk description, title, file path, Spec repository
+  catalog, or unselected task are never sufficient evidence of high risk.
+
+Repository count comes only from repositories that own files in current plan units. Canonical
+Spec metadata, unselected tasks, dependency summaries, unused `repo_paths`, and supermodule child
+registrations do not raise the mode. A real multi-repository change is a Standard signal by
+itself and reaches Strict only when an explicit high-risk signal is also present.
 
 If configuration is concrete, it is also a floor. The selected mode may be raised by the user
-but never placed below either floor. Explain the decision and state-specific effects in the
-dev-spec.
+but never placed below either floor. The Agent must not raise an adaptive proposal to Strict from
+vague uncertainty or a domain keyword; cite both the explicit risk and the concrete complexity
+signal. Explain the decision and state-specific effects in the dev-spec.
 
 Persist the proposal before requesting ANALYSIS -> IMPLEMENT:
 
@@ -141,14 +261,22 @@ while still in ANALYSIS.
 
 ## User presentation and transition
 
-Before the boundary, present:
+After decision closure and before the boundary, present a concise session summary instead of
+pasting the full `dev-spec.md`. The summary must contain:
 
-- proposed scope and units;
-- acceptance and test strategy;
+- the core solution and affected scope/units;
+- acceptance and test-strategy highlights;
 - configured, minimum, and selected workflow modes with reasons;
-- how IMPLEMENT, REVIEW, VERIFICATION, and MEMORY will run;
+- the material risks and explicit acceptance boundaries;
 - explicit user ability to request a higher mode or a permitted lower mode.
 
+End the summary with the absolute path to
+`.easy-coding/tasks/<task-id>/dev-spec.md`. When the current client supports local-file Markdown
+links, render `[View full Dev-Spec](</absolute/path/to/dev-spec.md>)`; otherwise print the
+copyable absolute path. Do not dump the full artifact merely because the client cannot link it.
+If the user asks to inspect the full plan, open or read that stored file on demand using the
+current Agent's supported file capability.
+
 Then request or auto-apply ANALYSIS -> IMPLEMENT according to `effective_approval_mode`.
 The state API atomically freezes the proposal when the transition is applied. `approval_mode`
 controls waiting; it never changes the selected execution depth.
@@ -159,6 +287,14 @@ controls waiting; it never changes the selected execution depth.
 - No unresolved skeleton placeholders.
 - No code task with an empty change scope.
 - No unit without acceptance criteria, test points, contracts, and risks.
+- No final summary, workflow proposal, or transition while a material decision is unresolved.
+- No transition without exactly one `decision_status: closed` marker in `dev-spec.md`.
 - No transition without a valid workflow proposal.
-- No Canonical-backed transition with changed source SHA, unresolved repository identity,
+- No Canonical-backed transition with changed design revision/digest, a backward execution
+  revision, pending/conflicted writeback, unresolved repository identity,
   incomplete selected-task coverage, or an open Unit/Step/File/Symbol/Test traceability gap.
+
+If evidence requires changing Canonical task boundaries, contracts, files, symbols, Steps, Tests,
+or dependencies, remain/return to ANALYSIS, update the original static design with revision +1,
+restore READY, and call `sync-spec-design --affected-task ...`. This invalidates the old local
+plan. Never substitute edits to the derived `dev-spec.md`, and never edit `EDS:EXECUTION` by hand.

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

@@ -0,0 +1,76 @@
+---
+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.
+
+Approval semantics stay independent from verification depth: `approve` waits at each
+non-mechanical edge, `guard` waits at ANALYSIS -> IMPLEMENT and VERIFICATION -> MEMORY, `confirm`
+waits only for the plan, and `auto` advances legal green edges immediately. Every mode temporarily
+pauses only when code changes after the frozen VERIFICATION checkpoint, because the user must see
+and accept that exact new diff; this exception does not convert `auto` into `guard`.
+
+## 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, 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-git/SKILL.md

@@ -62,7 +62,13 @@ 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.
+- Shared Canonical execution writeback and Git delivery are independent facts. Do not stage or
+  commit a project-external Spec automatically. For a Spec inside a Git repository, include it
+  only when the user's requested commit scope and normal repository rules include it; never claim
+  shared writeback merely because Git succeeded, or Git delivery merely because writeback
+  succeeded.
+- Never hand-edit `EDS:EXECUTION`. Static Spec changes are valid only through design revision +
+  READY + `sync-spec-design`; runtime progress uses the shared writer commands.
 - 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.