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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "0.10.0-beta.1",
+  "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,9 +85,11 @@ initialization standard. Check each item:
   and non-empty?
 - **Project profile**: `project.yaml` exists with `mode` and `test` fields (ec-init owns it;
   `config.yaml` is CLI-owned — not ec-init's concern)?
-- **TDD runtime contract**: CLI-owned `config.yaml` has schema 4 TDD defaults and
-  `.easy-coding/tools/easy_coding_java_coverage.py` exists? Missing fields or tool mean
-  `easy-coding upgrade` is required; ec-init must not repair them directly.
+- **TDD runtime contract**: CLI-owned `config.yaml` has schema 5 TDD defaults and both
+  `.easy-coding/tools/easy_coding_java_coverage.py` and
+  `.easy-coding/tools/easy_coding_tdd_readiness.py` exist? Missing fields or tools mean
+  `easy-coding upgrade` is required; ec-init must not repair them directly. Project-specific
+  JaCoCo/GitLab readiness remains owned by `ec-tdd-init`, not `ec-init`.
 - **Platform hook config freshness**: for each installed platform in `.easy-coding/config.yaml`,
   read the platform hook config and verify managed Easy Coding hook commands use the portable
   relative hook launcher bound to this project root's `project.id`. If `project.id` is missing,
@@ -145,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.
@@ -159,7 +168,8 @@ agent must be able to see what was generated and on what evidence.
    you verified exist (read package.json scripts or equivalent — do not guess).
    If effective TDD is disabled, do not inspect JaCoCo or GitLab and do not add TDD-specific
    requirements. If it is enabled for Java, additionally document JUnit/JaCoCo commands,
-   production/test source roots, XML report paths, and the existing GitLab TEST-stage gate.
+   production/test source roots, XML report paths, the local acceptance gate, and the generated
+   GitLab TEST-stage job as non-blocking automation infrastructure.
 5. **Memory migration probe** — Check for old-format memory files:
    - `.easy-coding/memory/long/MEMORY.md` exists but lacks `memory_schema: 2` frontmatter
    - `.easy-coding/memory/long/BUSINESS.md` or `TECHNICAL.md` missing
@@ -188,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,17 +49,22 @@ 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.
+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, and the same JaCoCo diff gate locally and in
-GitLab TEST-stage CI.
+TDD adds lifecycle evidence, a TDD review dimension, passed local unit-test evidence, and a local
+JaCoCo diff gate. `ec-tdd-init` still generates the equivalent GitLab TEST-stage job, but remote
+pipeline execution and status are not Harness acceptance dependencies.
 
 The active task pointer lives in `sessions/{agent}-{session-id}.json` (with an agent-prefixed PPID fallback only
 when a hook payload has no logical session ID);
@@ -77,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 14 skills are
+Each skill is installed as `{skills-dir}/ec-{name}/SKILL.md`. The 15 skills are
 platform-agnostic — one template, resolved per platform at write time. The agent's native
 discovery surfaces them under `/ec-` or `$ec-`.
 

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

@@ -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,26 +138,39 @@ 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.
+extra tests, and do not strengthen the selected Workflow Mode's ordinary acceptance depth. This
+zero-cost rule applies to ordinary tasks, not the explicit `tdd-init` infrastructure task above.
 
 When TDD is enabled for a Java code task, make `test-strategy.md` record:
 
@@ -107,18 +180,24 @@ When TDD is enabled for a Java code task, make `test-strategy.md` record:
   toward 100% while treating the threshold as the mechanical minimum;
 - feature/bug RED -> GREEN -> REFACTOR evidence, or for pure refactors a pre-change
   characterization GREEN -> post-change GREEN sequence without inventing a RED failure;
-- `.gitlab-ci.yml` and included configuration, the TEST-stage job, JUnit/JaCoCo artifacts, and an
-  equivalent changed-line gate. Reuse a gate only when its threshold is at least the configured
-  value; otherwise include the CI change in the confirmed implementation scope.
+- the local unit-test command and local changed-line acceptance command. Record that
+  `ec-tdd-init` generated the GitLab TEST-stage job, but remote execution, pipeline identity, and
+  status are non-blocking and never require an intermediate commit or push. Include these exact,
+  language-independent contract markers: `local_test_gate: required` and
+  `remote_ci_acceptance: non-blocking`.
+- current `tdd_readiness_status=ready`; if missing or drifted, stop before IMPLEMENT and route to
+  `ec-tdd-init`. Never plan to initialize CI inside an already-enabled TDD feature task.
 
 The state API mechanically freezes current Git `HEAD` per repository into `task.tdd_baselines`
-when ANALYSIS advances to IMPLEMENT. Plan both local and GitLab commands with that exact SHA and
-the frozen threshold; never use a mutable `HEAD` fallback at verification time. Non-Canonical TDD
-is limited to one Git repository; multi-repository TDD must use Canonical repository bindings.
+when ANALYSIS advances to IMPLEMENT. Plan the local command with that exact SHA and the frozen
+threshold. The generated GitLab job remains parameterized for infrastructure parity, but the
+Harness acceptance plan never waits for remote CI. Never use a mutable `HEAD` fallback at
+verification time. Non-Canonical TDD is limited to one Git repository; multi-repository TDD must
+use Canonical repository bindings.
 
 Also append a `### TDD Mode` section to `dev-spec.md` with enabled state, frozen threshold,
-baseline, local gate, GitLab TEST gate, and lifecycle evidence. Do not add this section when TDD
-is disabled.
+baseline, local unit-test gate, local coverage gate, generated GitLab job as non-blocking
+infrastructure, and lifecycle evidence. Do not add this section when TDD is disabled.
 
 If the task is not a Java project, explain that Java-only TDD cannot be activated and obtain a
 mode decision before advancing. The CLI never installs JaCoCo or edits CI automatically.
@@ -140,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:
 
@@ -171,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.
@@ -189,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

@@ -18,17 +18,32 @@ Call `snapshot` and show project, session, effective, and frozen task values for
 
 Use the returned fields directly, including `project_tdd_enabled`, `session_tdd_enabled`,
 `effective_tdd_enabled`, their threshold counterparts, `task_tdd_enabled`, and the task's
-per-repository `task_tdd_baselines` frozen state.
+per-repository `task_tdd_baselines` frozen state. When `tdd_readiness_status=not_checked` because
+TDD is off, explicitly run the read-only readiness command below before showing readiness:
+
+```bash
+python3 .easy-coding/tools/easy_coding_tdd_readiness.py --cwd . check
+```
+
+This explicit configuration-panel check is the only disabled-mode readiness scan; ordinary hooks
+must not inspect build or CI files while TDD is off.
 
 Explain precedence as `session override > project config > defaults`. Defaults are Approval
 `guard`, Workflow `adaptive`, TDD disabled, and TDD changed-line coverage threshold 90%. An active
 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
 
@@ -51,4 +66,11 @@ After explicit user selection, use the current logical session file:
 Turning TDD off must preserve the existing Fast/Standard/Strict test depth exactly: do not inspect
 CI, request JaCoCo, add TDD artifacts, run coverage commands, or strengthen acceptance criteria.
 When TDD is on, explain that it applies only to Java code tasks and activates RED/GREEN/REFACTOR,
-TDD review, local changed-line JaCoCo coverage, and GitLab TEST-stage gate planning.
+TDD review, a passed local unit-test gate, and local changed-line JaCoCo coverage. `ec-tdd-init`
+still generates the GitLab TEST-stage job, but Harness does not wait for or record remote pipeline
+results as acceptance evidence.
+
+Before any project/session enable action, require `tdd_readiness_status=ready`. If it is not ready,
+offer only `ec-tdd-init` or cancellation; never offer or persist "enable now, initialize later".
+Readiness means infrastructure can measure future changed production lines. It does not certify
+repository-wide coverage and does not require tests for unchanged historical code.

package/templates/common/skills/ec-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.