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

package/CHANGELOG.md

@@ -6,6 +6,23 @@
 - `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

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` 通过绝对本地链接或路径按需查看。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "easy-coding-harness",
-  "version": "0.10.0-beta.6",
+  "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,6 +21,13 @@ 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.
 
+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
@@ -56,6 +63,19 @@ Use shared execution dependency status directly. Do not inspect another local Ha
 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:...]]`.
@@ -101,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"],
@@ -132,8 +153,10 @@ For every selected source test, `test-strategy.md` must spell out its Test ID, s
 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.
 
@@ -196,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/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.
 

package/templates/shared-hooks/easy_coding_state.py

@@ -87,10 +87,24 @@ WORKFLOW_MODES = {"fast", "standard", "strict"}
 WORKFLOW_MODE_RANK = {"fast": 0, "standard": 1, "strict": 2}
 STRICT_VERIFICATION_CHECK_TYPES = {"lint", "typecheck", "test", "build"}
 REVIEW_FINDING_SEVERITIES = {"error", "warning", "info"}
-STRICT_WORKFLOW_RISK_PATTERN = re.compile(
-    r"(migration|migrate|schema|state[-_ ]?machine|security|payment|data[-_ ]?loss|"
-    r"concurren|cross[-_ ]?repo|public[-_ ]?(api|contract)|迁移|状态机|安全|支付|"
-    r"数据丢失|并发|跨仓|公共接口|公共契约)",
+HIGH_WORKFLOW_RISK_PATTERN = re.compile(
+    r"(\bhigh[-_ ]?risk\b|\bcritical\b|\bsevere\b|\birreversible\b|"
+    r"\bdata[-_ ]?loss\b|\bfinancial[-_ ]?loss\b|"
+    r"\bsecurity[-_ ]?(boundary|breach)\b|\bprivilege[-_ ]?escalation\b|"
+    r"\bproduction[-_ ]?outage\b|"
+    r"高风险|严重|不可逆|数据丢失|资损|安全边界|安全事件|权限提升|生产故障)",
+    re.IGNORECASE,
+)
+NEGATED_HIGH_WORKFLOW_RISK_PATTERN = re.compile(
+    r"(\b(?:non[-_ ]?|not[-_ ]+|no[-_ ]+)(?:high[-_ ]?risk|critical|severe|irreversible)\b|"
+    r"\b(?:no|without)[-_ ]+(?:risk[-_ ]+of[-_ ]+)?(?:data[-_ ]?loss|"
+    r"financial[-_ ]?loss|security[-_ ]?breach|production[-_ ]?outage)\b|"
+    r"低风险|非高风险|不严重|(?<!不)可逆|无(?:数据丢失|资损|安全事件|生产故障)|"
+    r"不会导致(?:数据丢失|资损|安全事件|生产故障))",
+    re.IGNORECASE,
+)
+WIDE_WORKFLOW_CONTRACT_PATTERN = re.compile(
+    r"(cross[-_ ]?repo|public[-_ ]?(api|contract)|跨仓|公共接口|公共契约)",
     re.IGNORECASE,
 )
 DEFAULT_APPROVAL_MODE = "guard"
@@ -1589,7 +1603,7 @@ def is_valid_execution_plan(
             has_empty_file_scope = True
         if not is_string_list(unit.get("depends_on")):
             return False
-        for optional_list in ("rules_sections", "abstract_modules"):
+        for optional_list in ("rules_sections", "abstract_modules", "local_baseline"):
             if optional_list in unit and not is_string_list(unit.get(optional_list)):
                 return False
         if require_unit_contracts:
@@ -2279,6 +2293,42 @@ def task_repository_roots(root: Path, task: dict | None, plan: dict) -> list[Pat
     ]
 
 
+def workflow_plan_repository_roots(root: Path, task: dict, plan: dict) -> list[Path]:
+    """Resolve only repositories that own files in the current execution plan."""
+    repositories: set[Path] = set()
+    repo_paths = task.get("repo_paths")
+    canonical = isinstance(task.get("spec_source"), dict)
+
+    for unit in plan.get("units", []):
+        if not isinstance(unit, dict):
+            continue
+        if canonical:
+            repo_id = unit.get("repo_id")
+            if not is_non_empty_string(repo_id) or not isinstance(repo_paths, dict):
+                raise StateError("Canonical workflow Unit is missing its repository binding.")
+            raw_repo_path = repo_paths.get(str(repo_id))
+            if not is_non_empty_string(raw_repo_path):
+                raise StateError(f"Canonical workflow repository path is missing: {repo_id}")
+            candidate = Path(str(raw_repo_path))
+            resolved = (candidate if candidate.is_absolute() else root / candidate).resolve()
+            repository = git_repository_root(resolved)
+            if repository is None or repository.resolve() != resolved:
+                raise StateError(f"Canonical workflow repository binding is not a Git root: {repo_id}")
+            repositories.add(repository.resolve())
+            continue
+
+        for file_name in unit.get("files", []):
+            if not is_non_empty_string(file_name):
+                continue
+            candidate = Path(str(file_name))
+            resolved = (candidate if candidate.is_absolute() else root / candidate).resolve()
+            repository = git_repository_root(resolved)
+            if repository is not None:
+                repositories.add(repository.resolve())
+
+    return sorted(repositories, key=lambda item: item.as_posix())
+
+
 def tdd_repositories(root: Path, task: dict, plan: dict) -> dict[str, Path]:
     if isinstance(task.get("spec_source"), dict):
         repo_paths = task.get("repo_paths")
@@ -6083,54 +6133,65 @@ def calculate_workflow_floor(root: Path, task_id: str) -> tuple[str, list[str]]:
     if not plan:
         raise StateError("Cannot calculate workflow floor without a valid execution plan.")
     units = [unit for unit in plan.get("units", []) if isinstance(unit, dict)]
+    missing_local_baseline = [
+        str(unit.get("id") or "<unknown>")
+        for unit in units
+        if not is_string_list(unit.get("local_baseline"), allow_empty=False)
+    ]
+    if missing_local_baseline:
+        raise StateError(
+            "Workflow plan Units must record a non-empty local_baseline: "
+            + ", ".join(missing_local_baseline)
+        )
     files = {
         str(file_name)
         for unit in units
         for file_name in unit.get("files", [])
         if is_non_empty_string(file_name)
     }
-    repositories = task_repository_roots(root, task, plan)
-    repos = task.get("repos")
-    repo_paths = task.get("repo_paths")
-    metadata_repo_count = max(
-        len(repos) if isinstance(repos, list) else 0,
-        len(repo_paths) if isinstance(repo_paths, dict) else 0,
-    )
-    repo_count = max(len(repositories), metadata_repo_count)
-    risk_text = " ".join(
-        [
-            str(task.get("title") or ""),
-            task_type,
-            *files,
-            *[
-                str(item)
-                for unit in units
-                for field in ("risks", "contracts")
-                for item in unit.get(field, [])
-                if is_non_empty_string(item)
-                and str(item).strip().lower() not in {"none", "no", "n/a", "无", "无风险"}
-            ],
+    repositories = workflow_plan_repository_roots(root, task, plan)
+    ignored_values = {"none", "no", "n/a", "无", "无风险"}
+    risk_values = [
+        str(item)
+        for unit in units
+        for item in unit.get("risks", [])
+        if is_non_empty_string(item) and str(item).strip().lower() not in ignored_values
+    ]
+    contract_values = [
+        str(item)
+        for unit in units
+        for item in unit.get("contracts", [])
+        if is_non_empty_string(item) and str(item).strip().lower() not in ignored_values
+    ]
+    risk_text = NEGATED_HIGH_WORKFLOW_RISK_PATTERN.sub("", " ".join(risk_values))
+    high_risk = bool(HIGH_WORKFLOW_RISK_PATTERN.search(risk_text))
+
+    complexity_reasons: list[str] = []
+    if len(repositories) > 1:
+        complexity_reasons.append("cross-repository-change")
+    if len(units) >= 4 or len(files) >= 10:
+        complexity_reasons.append("broad-change-scope")
+    if WIDE_WORKFLOW_CONTRACT_PATTERN.search(" ".join(contract_values)):
+        complexity_reasons.append("wide-contract-impact")
+    if high_risk and complexity_reasons:
+        return "strict", [
+            "compound-high-risk-and-complexity",
+            "explicit-high-risk-signal",
+            *complexity_reasons,
         ]
-    )
-    strict_reasons: list[str] = []
-    if repo_count > 1:
-        strict_reasons.append("cross-repository-scope")
-    if len(units) >= 4 or len(files) >= 8:
-        strict_reasons.append("broad-change-scope")
-    if STRICT_WORKFLOW_RISK_PATTERN.search(risk_text):
-        strict_reasons.append("high-risk-contract-or-domain")
-    if strict_reasons:
-        return "strict", strict_reasons
 
     standard_reasons: list[str] = []
+    if high_risk:
+        standard_reasons.append("bounded-high-risk-change")
+    standard_reasons.extend(complexity_reasons)
     if len(units) > 1:
         standard_reasons.append("multiple-units")
-    if len(files) >= 3:
+    if len(files) > 5:
         standard_reasons.append("multi-file-impact")
     if plan.get("strategy") == "parallel":
         standard_reasons.append("parallel-execution")
     if standard_reasons:
-        return "standard", standard_reasons
+        return "standard", list(dict.fromkeys(standard_reasons))
     return "fast", ["single-bounded-unit"]