easy-coding-harness 0.10.0-beta.5 → 0.10.0-beta.7

package/CHANGELOG.md

@@ -6,6 +6,39 @@
 - `y`：常规功能升级
 - `z`：日常 bug 修复
 
+## 0.10.0-beta.7
+
+- Workflow floor 改为 Standard 居中的复合判定：单仓、单 Unit、非并行且最多 5 个文件的
+  低风险局部修改优先 Fast；普通业务、多 Unit/文件、闭合的跨仓修改默认 Standard；只有
+  明确高风险与真实复杂度/大影响面同时存在才进入 Strict。
+- 仓库数量只统计 execution plan 中实际修改文件所属的 Git root。Canonical Spec 的未选
+  task、依赖摘要、未使用 `repo_paths`，以及 supermodule 已登记但未修改的子项目不再抬高
+  Workflow；风险描述、标题或文件路径中仅出现 `payment` / `schema` 等普通领域词也不再
+  单独触发 Strict，并行执行本身也只作为 Standard 信号。
+- ANALYSIS 新增渐进成本预算和 `Local Baseline`：只读取当前变更需要的最近邻同类代码、
+  合同和测试，按证据继承命名、空值/异常处理、分层、方法粒度、常量与注释习惯，避免
+  无关全仓扫描、投机性抽象和碎片化小方法。
+- IMPLEMENT/REVIEW 与三平台子代理统一克制设计合同：允许符合局部惯例的直观魔法值，
+  禁止为单个 getter return 创建常量；新增核心 Java 类的全部方法/字段、已有核心类中新增或
+  实质修改的方法/字段必须有 Javadoc，核心或复杂逻辑补充必要意图/约束注释，且不批量改造
+  未触碰历史代码。
+
+## 0.10.0-beta.6
+
+- Canonical Spec 首次路由新增 `inspect-dev-spec --manifest-only`：只通过 normalized remote
+  识别当前 worktree、展示任务目录和共享 execution 状态，不再为未选仓库解析本地路径或
+  为任何未选任务计算 baseline；`path_hint` 明确降级为提示信息。
+- 用户选定 task 后，`inspect-dev-spec --spec-task ...` 只检查所选任务所属仓库及其
+  change/test 范围；当前 worktree remote 唯一匹配时无需手工传 `--repo-path`，即使旧
+  `path_hint` 指向仍存在的原 checkout，也优先绑定当前 worktree。
+- `ec-workflow` 不再在路由阶段提前读取消费闭包；`ec-analysis` 负责唯一一次精确 selector
+  调用，并对 `exact` / `scope-unchanged` 使用快速投影，对 `scope-drifted` 只分析所选任务
+  的漂移文件和符号，派生 dev-spec 不再被解释为第二轮 Spec 创作。
+- 共享 `EDS:EXECUTION` 固化为依赖事实来源：已完成 hard task 或已满足依赖边直接放行；
+  禁止通过另一个本地 Harness task、Git 历史或 Agent 推断重复考古完成状态。
+- 保持项目外原始 Spec absolute locator、身份校验 rebind、共享 writer/CAS 及旧版全量
+  `inspect-dev-spec` 调用兼容；新增 worktree、未选仓库隔离和三平台安装产物回归测试。
+
 ## 0.10.0-beta.5
 
 - 兼容新版 `easy-dev-spec/v1` 共享执行区：同步设计/整文双摘要与 execution 投影协议，新增

package/README.md

@@ -85,7 +85,10 @@ any stage --[user abort via ec-task-close]--> CLOSED
   逐边确认，`guard` 确认 ANALYSIS → IMPLEMENT 与 VERIFICATION → MEMORY，`confirm` 只在
   ANALYSIS → IMPLEMENT 确认一次，随后各阶段在质量门禁通过后自动推进，`auto` 从开始即
   自动推进。
-- 工作流模式优先级为 session 覆盖 > 项目 `behavior.workflow_mode` > `adaptive`。Adaptive 在 ANALYSIS 结束时根据风险解析、展示并冻结为 `fast`、`standard` 或 `strict`，用户可在风险下限之上调整。
+- 工作流模式优先级为 session 覆盖 > 项目 `behavior.workflow_mode` > `adaptive`。Adaptive
+  以 Standard 作为普通业务默认：单仓单 Unit、非并行且不超过 5 个文件的低风险局部修改
+  优先 Fast；只有明确高风险与真实复杂度/大影响面同时存在才进入 Strict。仓库数只按当前
+  execution plan 实际修改的 Git root 计算，用户可在机械风险下限之上调整。
 - ANALYSIS 会先通过问答闭合影响技术路线、接口、模型、状态、范围或验收的实质性问题，
   并在 Dev-Spec 中记录唯一的 `decision_status: closed`。会话只展示核心方案、验收摘要、
   Workflow Mode 与主要风险；完整 `dev-spec.md` 通过绝对本地链接或路径按需查看。
@@ -101,15 +104,19 @@ any stage --[user abort via ec-task-close]--> CLOSED
 
 Harness 可选择性消费 easy-dev-spec 生成的单文件 `easy-dev-spec/v1` Canonical Spec：
 
-1. `ec-workflow` 先只读检查 manifest、仓库、任务 DAG、依赖、baseline 与共享 execution；
-   旧 Spec 仍可只读检查，但成为可执行任务前必须初始化共享执行区。
-2. 用户明确选择一个或多个 Spec task；`select-dev-spec-scope` 按仓库提取确定性消费
-   闭包，Harness 不默认导入整份 Spec，也不会读取未选任务正文。
-3. 一次选择创建一个 Harness task；ANALYSIS 使用最终 producer READY 门禁，并将
-   selected task 映射为带 `repo_id`、`source_task_id`、source steps、文件、符号和测试
-   命令的 Unit。
-4. `hard` 依赖决定执行顺序，冻结的 `contract` 依赖允许并行编码，`integration` 依赖
-   在证据闭合前阻止全链路完成。
+1. `ec-workflow` 先用 `inspect-dev-spec --manifest-only` 只读校验 manifest，通过 normalized
+   remote 识别当前 worktree，并展示任务 DAG 与共享 execution；不会解析未选仓库路径，也
+   不在选择前计算任何任务的 baseline。旧 Spec 仍可只读检查，但成为可执行任务前必须
+   初始化共享执行区。
+2. 用户明确选择一个或多个 Spec task 后，Harness 用 `--spec-task` 只检查所选任务仓库和
+   change/test 范围。当前 worktree remote 唯一匹配时无需手工路径；`path_hint` 不一致只会
+   形成一次运行时映射提示，不会复制或修复原 Spec。
+3. 一次选择创建一个 Harness task；ANALYSIS 唯一一次调用 `select-dev-spec-scope` 提取确定性
+   消费闭包。`exact` / `scope-unchanged` 直接快速投影为 Unit、测试策略和派生 dev-spec，
+   `scope-drifted` 才读取所选范围内的漂移文件与符号；未选任务正文始终不进入上下文。
+4. `EDS:EXECUTION` 是依赖事实来源：`hard` 依赖决定执行顺序，冻结的 `contract` 依赖允许
+   并行编码，`integration` 依赖在证据闭合前阻止全链路完成；不会再从本地任务或 Git 历史
+   重复推断共享状态。
 
 Canonical Spec 的静态设计由 design revision + `design_sha256` 冻结；共享
 `EDS:EXECUTION` 则接收 Harness 的 Task/Step/dependency 投影。写回使用

package/package.json

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

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

@@ -16,7 +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,7 +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

@@ -147,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.

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

@@ -21,15 +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. 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 for the exact 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>]...
@@ -38,8 +48,33 @@ An execution revision rollback is blocking. Then call the selector for the exact
 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
 
@@ -86,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"],
@@ -107,14 +143,20 @@ digest, current document digest/execution revision/writeback status, selected ta
 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.
 
@@ -177,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:
 

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

@@ -47,6 +47,24 @@ Communicate with the user in the user's language.
    Describe the semantic meaning and, when relevant, units, format, allowed values, nullability,
    default behavior, or compatibility constraints. A type-level comment does not replace comments
    on its fields or members; do not add low-value comments to ordinary local variables.
+10. Treat the task card's `Local Baseline` as the default implementation shape. Match the nearest
+    comparable code's naming, control flow, null/empty and error handling, layering, object model,
+    and extraction granularity unless correctness, security, an explicit requirement, or a hard
+    project rule requires a deviation. Do not add defensive null checks solely because they are a
+    generic best practice when the evidenced local contract intentionally omits them.
+11. Implement the smallest coherent design. Do not add speculative abstractions, wrappers,
+    factories, layers, or extension points, and do not fragment one readable flow into many
+    single-use micro-methods. Extract code only for a clear semantic boundary, real reuse,
+    independent testability, or a material reduction in complexity.
+12. Literals and magic values are allowed when they are obvious, local, and consistent with the
+    surrounding code. Introduce a constant for repeated use, stable domain/config/protocol
+    semantics, or an established project convention—not merely to hold the single return value of
+    a getter.
+13. In a newly added core Java class, every method and field requires meaningful Javadoc. In an
+    existing core Java class, every added or materially modified method and field requires it.
+    Add focused inline comments to core or complex logic to explain intent, constraints, or
+    non-obvious tradeoffs. Do not mass-retrofit untouched legacy code, and for non-Java code
+    follow the language's doc-comment form plus the evidenced project convention.
 
 ## Choose the execution owner
 
@@ -92,6 +110,7 @@ Sub-agents never dispatch other sub-agents or read `.easy-coding` workflow asset
 ## Test Points    {unit.test_points and exact targeted commands}
 ## Contracts      {inputs, outputs, invariants shared with other units}
 ## Risks          {known edge cases and compatibility risks}
+## Local Baseline {nearest comparable code conventions and evidence paths}
 ## Code Comments  {resolved host Agent author value; model-field, enum-member, and constant rules}
 ## Coding Rules   {pre-digested RULES sections}
 ## Architecture   {pre-digested ABSTRACT sections}
@@ -110,11 +129,13 @@ deliverable|null, checks:[{command,passed,failures:[]}], issues:[], needs_attent
    hard/contract dependencies are ready; do not batch-start dependent tasks at the initial
    IMPLEMENT boundary.
    Populate `Code Comments` on every code task card with the resolved user-facing host Agent
-   author value and the field/member/constant rules above; sub-agents do not read this Skill.
+   author value, the field/member/constant rules, and the core Java Javadoc rule above. Populate
+   `Local Baseline` from the Unit's analyzed evidence; sub-agents do not read this Skill.
 2. Execute according to dependency order and selected owner.
 3. Run targeted unit tests and self-audit scope, contracts, TODOs, and introduced warnings.
    Also audit new author attributions and every new model field, enum member, and constant against
-   the comment requirements above before recording success.
+   the comment requirements above, then check local-style deviations, unnecessary abstractions,
+   one-use constant extraction, and affected core Java Javadoc before recording success.
 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.
@@ -150,6 +171,10 @@ conversation overhead while keeping work observable.
 - [ ] Every unit has a dispatch/result pair and satisfied its acceptance criteria.
 - [ ] Targeted tests ran or a concrete blocker is recorded.
 - [ ] Cross-unit contracts still match.
+- [ ] The implementation follows the evidenced Local Baseline or records a required deviation.
+- [ ] No speculative layer, fragmented micro-method set, or single-use getter constant was added.
 - [ ] New author attributions use the user-facing host `<Current Agent Name> with Easy Coding`.
 - [ ] Every new model field, enum member, and constant has a meaningful field-level comment.
+- [ ] Every method/field in a new core Java class, and every added or materially modified one in
+      an existing core Java class, has Javadoc.
 - [ ] Code tasks enter REVIEW, regardless of workflow mode.

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

@@ -12,7 +12,17 @@ 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`.
+the Unit's Local Baseline, and obvious security risks. Every finding cites `file:line`.
+
+Review local fit before recommending generic cleanup. Flag an implementation when it departs from
+the nearest comparable naming, control flow, null/error handling, layering, modeling, or method
+granularity without a correctness, security, requirement, or hard-rule reason. Also flag
+speculative layers, fragmented one-use micro-methods, constants created only for one getter
+return, and missing Javadoc in core Java code: check every method/field in a new core class and
+each added or materially modified one in an existing core class. Do not demand defensive null
+checks, abstraction, constant extraction, or legacy-wide comment retrofits merely because they
+are generic best practices. A violation of an explicit task-card coding/comment contract is a
+contract defect, not optional stylistic advice.
 
 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

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

@@ -61,36 +61,52 @@ 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. 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. A
-   READY Canonical Spec without shared execution remains readable, but run
-   `initialize-spec-execution` before selection can become an executable Harness task.
+3. When the user explicitly references a Dev-Spec, first run read-only `inspect-dev-spec
+   --manifest-only`. This routing pass validates the document, identifies the current worktree by
+   normalized remote, and returns the task catalog without resolving unrelated repositories. For
+   `protocol=canonical-v1`, show every task ID, repository, title, static status, actual execution
+   status, and dependency; never select all tasks by default and never calculate baseline drift
+   before selection.
+
+   After the user chooses one or more tasks, run one selected inspection with repeated
+   `--spec-task`. Resolve paths only for repositories that own selected tasks. The current
+   worktree needs no explicit mapping when its normalized remote matches uniquely; pass
+   `--repo-path` only for an additional selected repository or to confirm an ambiguous current
+   match. A differing `path_hint` is a one-time runtime mapping notice, not a Spec portability
+   failure: never copy, mirror, or rewrite the source Spec because of it.
+
+   Then call `create-task-from-spec` once for the complete selection. Do not call
+   `select-dev-spec-scope` during routing; `ec-analysis` owns the single consumption-closure read
+   after task creation. 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. A READY Canonical Spec without shared
+   execution remains readable, but run `initialize-spec-execution` before selection can become an
+   executable Harness task.
 
    ```bash
    {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py inspect-dev-spec \
-     --spec <path> [--repo-path <repo-id>=<path>]...
+     --spec <path> --manifest-only
+
+   {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py inspect-dev-spec \
+     --spec <path> --spec-task <task-id> [--spec-task <task-id>]... \
+     [--repo-path <repo-id>=<path>]...
 
    {{PYTHON_CMD}} {{platform_config_dir}}/hooks/easy_coding_state.py initialize-spec-execution \
      --spec <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>]... \
+     [--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.
+   Shared `EDS:EXECUTION` is the dependency fact source. Accept a completed hard dependency or a
+   satisfied edge directly from that snapshot. Only accept manual dependency evidence when the
+   shared edge is still pending and the user explicitly supplies independently verifiable
+   evidence; never reconstruct completion from another local Harness task, Git history, or an
+   agent's inference.
 
    When multiple selected tasks depend on the same target, disambiguate creation evidence with
    `<source-task-id>-><dependency-task-id>=<evidence>`.

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

@@ -92,6 +92,11 @@ First run `ec-init`; daily work goes through `ec-workflow`.
   external explicit Spec paths are allowed and may be repaired only with identity-checked rebind.
   Runtime progress must use the shared writer with CAS/idempotency and reconciliation; static
   design changes require revision + READY + `sync-spec-design`. Never hand-edit `EDS:EXECUTION`.
+- Canonical routing is two-pass: first use manifest-only discovery for the current worktree, then
+  inspect only the explicitly selected task IDs and repositories. A remote-confirmed worktree
+  overrides a stale `path_hint`; never mirror the source Spec or re-check unselected repositories.
+  ANALYSIS reads the selected consumption closure once and treats exact/scope-unchanged as a fast
+  projection, while shared execution is the dependency fact source.
 - MEMORY combines short-memory creation and the conditional long-memory gate. Entry follows the
   effective confirmation mode; once memory processing completes, COMPLETE is automatic.
 - NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.

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

@@ -90,6 +90,11 @@ First run `/ec-init`; daily work goes through `/ec-workflow`.
   external explicit Spec paths are allowed and may be repaired only with identity-checked rebind.
   Runtime progress must use the shared writer with CAS/idempotency and reconciliation; static
   design changes require revision + READY + `sync-spec-design`. Never hand-edit `EDS:EXECUTION`.
+- Canonical routing is two-pass: first use manifest-only discovery for the current worktree, then
+  inspect only the explicitly selected task IDs and repositories. A remote-confirmed worktree
+  overrides a stale `path_hint`; never mirror the source Spec or re-check unselected repositories.
+  ANALYSIS reads the selected consumption closure once and treats exact/scope-unchanged as a fast
+  projection, while shared execution is the dependency fact source.
 - MEMORY combines short-memory creation and the conditional long-memory gate. Entry follows the
   effective confirmation mode; once memory processing completes, COMPLETE is automatic.
 - NO CODE-TASK COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.

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

@@ -18,7 +18,17 @@ complete exactly that unit. Your reply IS the return value, not a message to a h
   context is in 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/qoder/agents/ec-reviewer.md

@@ -17,7 +17,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.