svharness 0.14.1 → 0.14.2

package/dist/core/state.js

@@ -43,11 +43,25 @@ function buildInitialState(input) {
         };
     }
     // S20_collect_inputs: collect related inputs (requirements/references/optional extra skills & rules)
-    phases.S20_collect_inputs = { status: 'PENDING', manual_required: true };
+    phases.S20_collect_inputs = {
+        status: 'PENDING',
+        manual_required: true,
+        task_list_file: 'task_list.md',
+    };
     // S30_convert_docs: convert non-md raw docs to markdown for downstream entry-ization
     phases.S30_convert_docs = { status: 'PENDING', requires_agent: true };
-    phases.S40_extract_requirements = { status: 'PENDING', requires_agent: true };
-    phases.S50_generate_specs = { status: 'PENDING', requires_agent: true };
+    phases.S40_extract_requirements = {
+        status: 'PENDING',
+        requires_agent: true,
+        coverage_report: 'requirements/coverage-report.yaml',
+        coverage_ratio: null,
+    };
+    phases.S50_generate_specs = {
+        status: 'PENDING',
+        requires_agent: true,
+        spec_coverage_report: 'specs/coverage-report.yaml',
+        spec_coverage_ratio: null,
+    };
     // S60: references convert + structured indexing
     phases.S60_process_references = { status: 'PENDING', requires_agent: true };
     // S61: explicitly confirm whether baseline auto-extraction (skills/rules) is enabled
@@ -72,13 +86,17 @@ function buildInitialState(input) {
         status: 'PENDING',
         requires_agent: true,
         doctor_required: true,
+        review_report_path: 'HARNESS-REVIEW-REPORT.md',
+        depth_review_required: true,
+        min_depth_score: 5.0,
+        min_depth_grade: 'C',
     };
     phases.S90_finalize = { status: 'PENDING' };
     // current_phase starts at S10_wiki (if present) or S20_collect_inputs (if no baseline)
     const startPhase = wp !== 'none' ? 'S10_wiki' : 'S20_collect_inputs';
     const startAction = wp !== 'none'
         ? '请先构建 baseline wiki（项目经验底座），完成后进入 S20 输入文件收集。'
-        : '请先完成 S20 输入文件收集：requirements/raw、references/raw，并确认是否有额外 skills/rules。';
+        : '请先完成 S20 输入文件收集：requirements/raw、references/raw，并按 task_list.md 执行阶段门禁。';
     const state = {
         project: input.name,
         arch: input.arch,

package/dist/utils/yaml-safe-path.js

@@ -0,0 +1,33 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.toYamlSafePath = toYamlSafePath;
+exports.preprocessHarnessYamlText = preprocessHarnessYamlText;
+/**
+ * Normalize filesystem paths for safe embedding in YAML double-quoted strings.
+ * Windows backslashes break YAML parsing (`\u`, `\n`, etc.).
+ */
+function toYamlSafePath(absPath) {
+    if (!absPath)
+        return '';
+    let s = absPath.replace(/\\/g, '/');
+    // Collapse duplicate slashes (keep leading // for UNC if present).
+    if (s.startsWith('//')) {
+        s = '//' + s.slice(2).replace(/\/+/g, '/');
+    }
+    else {
+        s = s.replace(/\/+/g, '/');
+    }
+    return s;
+}
+/**
+ * Preprocess harness.yaml text before js-yaml load (comments + legacy Windows paths).
+ */
+function preprocessHarnessYamlText(raw) {
+    let body = raw.replace(/^\s*#.*$/gm, '');
+    body = body.replace(/"([^"\\]*(?:\\.[^"\\]*)*)"/g, (match, inner) => {
+        if (!inner.includes('\\'))
+            return match;
+        return `"${toYamlSafePath(inner)}"`;
+    });
+    return body;
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "svharness",
-  "version": "0.14.1",
+  "version": "0.14.2",
   "description": "CLI scaffolder for SDD-Driven Agent-Agnostic Coding Framework (harness)",
   "bin": {
     "svharness": "./bin/cli.js",
@@ -45,7 +45,6 @@
     "picocolors": "^1.1.1",
     "prompts": "^2.4.2",
     "repomix": "^1.14.0",
-    "svharnessbuild": "^0.7.0",
     "tar": "^7.5.15"
   },
   "devDependencies": {

package/templates/_shared/build-rules/harness-build-rule-convert-check.md

@@ -19,6 +19,12 @@ Agent 在进入 S30_convert_docs 阶段后必须逐一检查以下两个目录
 4. **判断是否需要转换**：仅当 `md/` 中缺少同基名文件时才转换；**`raw/` 中仍保留 pdf/docx 不代表未转换**（源文件不得删除）。
 5. **常见误判**：勿将 `raw/` 内已是 `.md` 的文件计入待转换；勿忽略 `md/` 已有文件；若产物在 `raw/**/converted_md/`，应移至对应 `md/` 后再判定。
 
+## 与 S40 的衔接约束
+
+- `S30_convert_docs` 的职责是保证「可读中间层可用」，**不是**直接判定「可条目化」。
+- 即使 convert 成功，S40 仍必须根据文档质量选择 `extraction_strategy`（`md_primary` / `raw_primary` / `hybrid` / `manual_assisted`）。
+- 当 `md/` 中出现明显结构损失（如大量 `NaN`、表头错位、锚点缺失）时，S40 必须切换 `raw_primary` 或 `hybrid`，不得硬用 `md_primary`。
+
 ## 转换方式（按优先级）
 
 1. **优先调用 CLI**：若运行环境支持，直接调用 `svharness convert --input <raw文件或目录> --output __HARNESS_ROOT__ --type requirements` 或 `--type references` 完成转换。

package/templates/_shared/build-rules/harness-build-rule-orchestrator-flow.md

@@ -12,8 +12,14 @@
   - 2.4 类型确认约束：若有规则或未知类型资源，必须在 S65 依据 `agent-env/_incoming/manifest.yaml` 完成分流确认后再写入最终目录。
    准入：四类目标目录存在；退出：`requirements/raw/` 至少 1 份真实文档，且其余三项已完成"已提供/无新增"确认。
 3. **S30_convert_docs** — 将 `requirements/raw/` 和 `references/raw/` 中的非 Markdown 原始文档统一转为 Markdown，产物落到对应 `md/` 目录。准入：S20_collect_inputs DONE；退出：每份源文档在对应 `md/` 目录中有同基名的 `.md` 文件。
-4. **S40_extract_requirements** — 由 `harness-build-skill-spec-builder` 将 raw 条目化到 `requirements/yaml/`。退出：每条需求有稳定 id 与归属域。
-5. **S50_generate_specs** — 生成 `specs/{signals,ui,behavior,interfaces}/*.yaml`。退出：全部通过 `specs/*/schema.json` 校验。
+4. **S40_extract_requirements** — 由 `harness-build-skill-spec-builder` 将 raw 条目化到 `requirements/yaml/`。退出：
+   - 已生成 `requirements/coverage-report.yaml`；
+   - `unmapped` 为空，或已全部完成 waiver 与用户确认；
+   - 每条需求具备稳定 id 与可追溯锚点（允许有备案聚合，但不得无依据粗化）。
+5. **S50_generate_specs** — 生成 `specs/{signals,ui,behavior,interfaces}/*.yaml`。退出：
+   - 全部通过 `specs/*/schema.json` 校验；
+   - 已产出 spec 覆盖率结果（建议 `specs/coverage-report.yaml`）；
+   - 每条 REQ 有 spec 映射或显式 N/A 理由。
 6. **S60_process_references**（阶段叙事：**references 处理**）— 对 S20 中的 references 执行处理与结构化：
    - 必须执行 `svharness convert`，不得跳过转换直接抽取；
    - 必须产出结构化索引（规制约束 / skills 候选 / signals / manuals，缺项需显式标注）；
@@ -33,13 +39,17 @@
    语义约束：skills 是执行 task 的能力积木，task 是可复用的流程模板。
    退出：每 skill 有 SKILL.md，tasks 覆盖三类典型场景。
 10. **S80_seed_memory** — 播种 `agent-env/memory/categories/` 初始分类。退出：inbox 流转规则已落地。
-11. **S85_pre_seal_validation** — 封存前完整性校验。
+11. **S85_pre_seal_validation** — 封存前校验（doctor + 合并 Agent 审查）。
    - 必须先执行 `svharness doctor --harness <harness根目录> --mode pre-seal`（exit code 0）；
-   - 再由 `harness-build-skill-pre-seal-review` 完成全面语义审查并经用户表单确认；
-   - 建议将 `doctor-report.json` 路径与通过时间写入 `phases.S85_pre_seal_validation`。
-   准入：S80_seed_memory DONE；退出：doctor 零 error + 审查报告已确认 + 本阶段 DONE。
+   - 再由 **`harness-build-skill-pre-seal-review`（v2）** 产出 `HARNESS-REVIEW-REPORT.md`（Part A 完整性 + Part B 深度评分，frontmatter `gate_pass`）；
+   - 深度门禁：`overall_score >= 5.0`、`critical_count == 0`、`review_gate_pass: true`，用户表单确认。
+   准入：S80_seed_memory DONE；退出：
+   - doctor 零 error；
+   - `HARNESS-REVIEW-REPORT.md` 已确认且 `gate_pass: true`；
+   - state 含 `review_report_path`、`depth_review_score`、`review_gate_pass`；
+   - 本阶段 DONE。
 12. **S90_finalize** — 翻转 `specs.bootstrap_mode = false`，版本 bump、CHANGELOG、归档。
-   准入：**S85_pre_seal_validation DONE**；退出：bootstrap_mode 已 false，封板记录完整。
+   准入：**S85.review_gate_pass === true** 且 status DONE；退出：bootstrap_mode 已 false，封板记录完整。
 
 ## 硬约束
 
@@ -47,6 +57,7 @@
 - 遇到 `BLOCKED` 阶段必须显式报出阻塞原因，不得静默跳过。
 - 阶段状态流转仅允许 `PENDING → IN_PROGRESS → DONE/FAILED/BLOCKED`。
 - 任一阶段退出条件未满足，`current_phase` 不得推进。
+- S40/S50/S85 推进时，必须同步更新 `task_list.md` 对应门禁清单；若与 state 冲突，以 state 为准并回写 task_list。
 - **S10_wiki 仅在项目有 baseline 时出现**；无 baseline 时该阶段不存在，不在 state 中写入，流程从 S20_collect_inputs 开始。
 - **S20_collect_inputs 退出前必须确认 `requirements/raw/` 中存在用户放入的真实文档**，Agent 不得自行生成占位文件。
 - **S20_collect_inputs 必须对 references/skills/rules 三项完成显式征询**（已提供 / 暂无新增 / 稍后补充）。

package/templates/_shared/build-rules/harness-build-rule-pre-seal-review.md

@@ -9,31 +9,51 @@
 - **仅以进程 exit code 0 视为通过**；禁止在未运行命令的情况下声称 doctor 已通过。
 - doctor 报告中的 **error** 必须修复后重跑；**warning** 须在审查报告中说明保留理由或已修复。
 
-## S85 全面审查（Agent，doctor 无法覆盖）
+## S85 全面审查（Agent，单一 skill：pre-seal-review v2）
 
-`harness-build-skill-pre-seal-review` 必须逐项确认：
+**唯一入口**：`harness-build-skill-pre-seal-review`（已合并原 `harness-build-harness-data-review` / `harness-build-final-review`）。
 
-1. **需求可追溯**：`requirements/yaml/` 每条需求在 specs 四域有对应条目，或显式标注 N/A 及原因。
-2. **描述完整性**：specs / skills / tasks 中无「待补充」「TBD」「placeholder」类占位语义。
-3. **references 一致**：`references/yaml/index.yaml` 与 S60 落地策略一致；`apply-skills-registry.yaml`（若存在）条目可解析。
-4. **wiki 可回溯**（有 baseline 时）：wiki 关键结论可指向 `baseline/code/` 具体路径。
-5. **流程合规**：构建期无未经用户表单确认的流程或内容修改（对照 `harness-build-rule-user-interaction`）。
-6. **中文与 agent-agnostic**：对照 `harness-build-rule-chinese-only`、`harness-build-rule-agent-agnostic`（doctor 启发式未覆盖处须人工扫尾）。
+须产出 **`HARNESS-REVIEW-REPORT.md`**（harness 根目录），含 YAML frontmatter：`overall_score`、`overall_grade`、`critical_count`、`gate_pass`。
+
+### Part A — 完整性（arch-agnostic）
+
+从 `harness.yaml` 发现 `requirements` / `specs.layers` / `references` / `baseline` / `agent_env` / `tasks` 等待审路径；逐项 PASS/WARN/FAIL/N/A。
+
+1. **需求可追溯**（若存在 requirements/yaml）：每条在已声明 spec 层有映射或 waiver。
+2. **覆盖率完整**：`requirements/coverage-report.yaml` 与（若存在）`specs/coverage-report.yaml` 可解析；`unmapped` 闭环。
+3. **描述完整性**：无 TBD/placeholder 占位语义。
+4. **references / wiki / agent-env**（若目录存在）：与 S60、baseline 策略一致。
+5. **流程合规**、**中文与 agent-agnostic** 扫尾。
+
+### Part B — 深度质量（按 specs.layers 启用）
+
+- 加载 `agent-env/review-profiles/<arch>.yaml` 或 `_default.yaml`。
+- 对已启用层执行定量/信号/行为/接口/UI/源数据/阶段 G 审查并 **10 分制评分**。
+- **不得**将某一业务域（如某 OEM 信号命名）写死为所有 harness 的默认逻辑；专有启发式仅出现在 arch profile。
+
+### S85 深度门禁（硬约束）
+
+- `overall_score >= 5.0`（C 级，可由 profile 覆写 `min_depth_score`）
+- `critical_count == 0`（差距表 severity=Critical 须清零或经用户 waiver 表单备案）
+- 阶段 G 判定覆盖率虚假时：`gate_pass` 必须为 false（总分上限 D）
+- **用户表单确认**「审查通过，可进入 S90 封板」
 
 ## S85 退出
 
 - `svharness doctor` exit code 0
-- 已输出「封存前审查报告」（中文）并经用户表单确认
-- `.harness-build-state.yaml` 中 `phases.S85_pre_seal_validation.status: DONE`
+- 已输出 `HARNESS-REVIEW-REPORT.md` 且 frontmatter `gate_pass: true`
+- `phases.S85_pre_seal_validation` 含：`review_report_path`、`depth_review_score`、`depth_review_grade`、`critical_gaps: 0`、`review_gate_pass: true`
+- `status: DONE` 且用户已表单确认
+- 若 `unmapped` 未闭环且无有效 waiver → 不通过
 
 ## S90 准入
 
-- **仅当 S85 为 DONE** 方可将 `current_phase` 设为 `S90_finalize` 并完成封板。
+- **仅当** `phases.S85_pre_seal_validation.review_gate_pass === true`（且 status DONE）方可进入 S90。
 - 封板动作：VERSION bump、`CHANGELOG.md` 更新、`harness.yaml` 中 `specs.bootstrap_mode: false`。
 
 ## 旧状态文件迁移
 
 若 `.harness-build-state.yaml` 无 `S85_pre_seal_validation` 且 `S80_seed_memory` 为 DONE、`S90_finalize` 为 PENDING：
 
-- 最小补丁插入 `S85_pre_seal_validation: { status: PENDING, requires_agent: true, doctor_required: true }`
+- 最小补丁插入 `S85_pre_seal_validation`（含 `doctor_required: true`、`depth_review_required: true`、`review_report_path: HARNESS-REVIEW-REPORT.md`）
 - 将 `current_phase` 设为 `S85_pre_seal_validation`

package/templates/_shared/build-rules/harness-build-rule-requirements-extraction.md

@@ -0,0 +1,43 @@
+# harness-build-rule-requirements-extraction — requirements 提取与完整性门禁
+
+本规则约束 S40 阶段的需求提取行为，目标是避免粗粒度聚合导致 requirements/specs 不完整。
+
+## 核心原则
+
+1. **输入策略必须显式声明**
+   - S40 前必须声明 `intake_profile.extraction_strategy`：
+     - `md_primary`
+     - `raw_primary`
+     - `hybrid`
+     - `manual_assisted`
+   - 禁止默认「MD 一定可机械条目化」。
+   - 禁止默认「MD 一律不可用」。
+
+2. **细不能粗**
+   - 存在可追踪锚点（如 `SyRD-*`、`REQ-*`、章节行号）时，默认 `1 anchor = 1 requirement item`。
+   - 禁止用通配符（如 `01-05-*`）替代多个独立条目。
+
+3. **聚合必须显式备案**
+   - 仅在确有必要时允许聚合，且必须同时满足：
+     - `aggregates: [...]`
+     - `aggregation_reason`
+     - 用户表单确认
+
+4. **覆盖率报告是 S40 必备产物**
+   - 必须生成 `requirements/coverage-report.yaml`。
+   - 报告至少包含：
+     - `extraction_strategy`
+     - `sources[].anchors_total / anchors_mapped / anchors_waived / coverage_ratio`
+     - `waived[]`
+     - `unmapped[]`
+
+## 门禁条件（与 orchestrator 联动）
+
+- 出现 `unmapped` 且未完成 waiver 闭环，不得将 `S40_extract_requirements` 标记为 DONE。
+- 只有在 coverage-report 完整且门禁满足后，才允许推进到 S50。
+
+## 禁止事项
+
+- 禁止跳过源清点（inventory）直接写 `requirements/yaml`。
+- 禁止仅凭少量摘要条目宣称「提取完成」。
+- 禁止在未说明依据的情况下选择提取策略。

package/templates/_shared/build-rules/harness-build-rule-specs-schema.md

@@ -20,6 +20,20 @@ specs/
 - 字段增减/重命名时，`schema.json` 与对应 yaml 必须**同一提交**更新，不得分两步。
 - yaml 中不得出现任何具体 agent 名（qoder/codechat/cursor/claude-code/opencode 等）— 违反 agent-agnostic 铁律。
 
+## requirements 追溯字段建议（S40/S50 配套）
+
+为提升 requirements/specs 完整性，`requirements/yaml/*.requirements.yaml` 的条目建议包含：
+
+- `source_anchor`: 可追踪源锚点（如 `SyRD-*`、章节+行号）
+- `source_file`: 源文件路径（通常在 `requirements/raw/`）
+- `source_section`: 源章节或表格区域
+- `aggregates`: 聚合锚点列表（仅在显式聚合时）
+- `aggregation_reason`: 聚合原因（聚合时必填）
+- `waived`: 是否作为门禁豁免项
+- `waived_reason`: 豁免原因（waived 为 true 时必填）
+
+以上为推荐字段，不改变四域 specs 的 schema 强约束。
+
 ## 校验节点
 
 - S50_generate_specs 退出前：所有 yaml 逐一过 schema 校验，失败则阶段状态置 FAILED。

package/templates/_shared/build-rules/harness-build-rule-user-interaction.md

@@ -25,6 +25,7 @@
 - 阶段产出审查："S50_generate_specs 已生成 4 个模块的 YAML，是否通过校验？"
 - 关键决策点："是否要调整 schema？/ 是否跳过该需求？"
 - 流程变更征询："是否要将该规则纳入 S61_confirm_baseline_extraction / S65_customize_agent_env？"
+- 覆盖率门禁确认："S40/S50 的 gap、waiver、N/A 是否确认放行？"
 
 **禁止的做法**：
 - 在终端输出一段文字后直接继续执行下一阶段
@@ -57,6 +58,13 @@ Agent **不得**在以下行为上自行决定，**必须**先征求用户同意
 
 禁止：检测冲突后直接覆盖、静默跳过且不告知用户。
 
+## 红线五：S40 / S50 覆盖率门禁必须走表单确认
+
+- 在 `S40_extract_requirements` 标记 DONE 前，必须展示覆盖率门禁表（至少含：`源 ID`、`REQ ID`、`状态(mapped/waived/gap)`）。
+- 若存在 `gap` 且无有效 waiver，禁止标记 DONE。
+- 在 `S50_generate_specs` 标记 DONE 前，必须确认 REQ→spec 映射完整；N/A 项必须给出理由并经用户确认。
+- 上述确认结论必须同步到 `.harness-build-state.yaml` 与 `task_list.md`。
+
 **允许的自主行为**（无需额外确认）：
 - 按 `harness-build-rule-orchestrator-flow` 规则正常推进阶段状态
 - 在 specs 目录下生成符合 schema 的 YAML 文件

package/templates/_shared/build-skills/harness-build-harness-data-review.md

@@ -0,0 +1,16 @@
+---
+name: harness-build-harness-data-review
+aliases:
+  - harness-build-final-review
+description: >
+  已合并至 harness-build-skill-pre-seal-review（S85 v2）。
+  请使用「封存前审查」「S85 全面检查」「深度审查」触发合并 skill。
+---
+
+# harness-build-harness-data-review（重定向）
+
+本 skill 职责已并入 **`harness-build-skill-pre-seal-review`**（Part A 完整性 + Part B 深度质量 + `HARNESS-REVIEW-REPORT.md` + C 级门禁）。
+
+请直接加载并执行：`harness-build-skill-pre-seal-review`。
+
+报告文件名由 `SPECS-REVIEW-REPORT.md` 统一为 **`HARNESS-REVIEW-REPORT.md`**。

package/templates/_shared/build-skills/harness-build-skill-orchestrator.md

@@ -25,6 +25,8 @@ description: >
    - 阶段 id + 一句话说明
    - 预期产物（哪些目录下的哪些文件）
    - 是否需要人工（`manual_required: true`）或需要 Agent 工作（`requires_agent: true`）
+   - 覆盖率门禁状态（若为 S40/S50/S85：`coverage_ratio` / `spec_coverage_ratio` / 审查结论）
+   - `task_list.md` 同步状态（是否已勾选本阶段门禁项）
    - 推荐下一步调用哪个 skill
 4. **必须以表单确认方式**询问用户是否继续，未经用户确认不得自行推进：
   - **S10_wiki** — 读取 state 中该 phase 的语义字段决定行为：
@@ -49,24 +51,32 @@ description: >
      3. **状态卡片写法**：`已完成` 只写已配对的 requirements/references 项；`待处理` **只列** md 仍缺失的源文件。禁止把“raw 里有多少个非 md 文件”直接等同于待转换数量。
      4. 对待处理项：优先调用 `svharness convert`（或表单提示用户运行 CLI）；若 `md/` 已有同基名 `.md` 则**跳过转换**。
      5. 全部配对完成后标记 DONE 并推进到 S40_extract_requirements。
-  - **S40_extract_requirements** — 委派给 `harness-build-skill-spec-builder`（需求条目化提取到 `__HARNESS_ROOT__requirements/yaml/`）。
-  - **S50_generate_specs** — 委派给 `harness-build-skill-spec-builder`（生成受 schema 校验的 YAML）。
+  - **S40_extract_requirements** — 委派给 `harness-build-skill-spec-builder`（需求条目化提取到 `__HARNESS_ROOT__requirements/yaml/`），并强制检查：
+    - `__HARNESS_ROOT__requirements/coverage-report.yaml` 已存在；
+    - `unmapped` 已清零或已 waiver 且用户确认；
+    - 否则不得标记 DONE。
+  - **S50_generate_specs** — 委派给 `harness-build-skill-spec-builder`（生成受 schema 校验的 YAML），并强制检查：
+    - schema 校验通过；
+    - REQ→spec 覆盖结果齐全（含 N/A 理由）；
+    - 否则不得标记 DONE。
   - **S60_process_references**（references 处理）— 仅处理 references：执行 `svharness convert`，产出结构化索引（规制约束 / skills 候选 / signals / manuals），并通过表单确认落地策略；委派给 `harness-build-skill-references-intake`。
   - **S61_confirm_baseline_extraction**（baseline 自动提取确认）— 以表单确认是否允许后续阶段自动从 `__HARNESS_ROOT__baseline/code/` 提取 skills/rules；未确认不得自动提取；确认结果建议写入 `phases.S61_confirm_baseline_extraction.baseline_auto_extract`；委派给 `harness-build-skill-agent-env-merge`。
   - **S65_customize_agent_env**（agent-env 定制）— 处理 extra-skills / extra-rules 合并写入（来源可来自单入口 `--extra-skills` 的 `_incoming/manifest.yaml` 清单）。遇到冲突时必须执行"先给修改建议 → 用户表单确认 → 再写入"；委派给 `harness-build-skill-agent-env-merge`。
   - **S70_runtime_assets** — 委派给 `harness-build-skill-knowledge-builder`（`__HARNESS_ROOT__agent-env/skills/` + `__HARNESS_ROOT__tasks/templates/`）。语义上 skill 是执行 task 的能力单元，task 是流程模板。
    - **S80_seed_memory** — 以表单请用户播种 `__HARNESS_ROOT__agent-env/memory/categories/` 初始分类；Agent 可建议草稿。
    - **S85_pre_seal_validation**（封存前校验）—
-     1. 在项目根或 harness 所在环境执行：`svharness doctor --harness __HARNESS_ROOT__ --mode pre-seal --format json --report __HARNESS_ROOT__doctor-report.json`（须 exit code 0）；
-     2. 委派 `harness-build-skill-pre-seal-review` 做全面语义审查并经表单确认；
-     3. 通过后最小补丁写入 `phases.S85_pre_seal_validation`（`status: DONE`、`doctor_passed_at`、`doctor_report_path`）。
-     **不得**在 doctor 未通过或审查未确认时标 DONE。
+     1. 执行：`svharness doctor --harness __HARNESS_ROOT__ --mode pre-seal --format json --report __HARNESS_ROOT__doctor-report.json`（须 exit code 0）；
+     2. 委派 **`harness-build-skill-pre-seal-review`（v2 合并审查）**：Part A 完整性 + Part B 深度评分，产出 `__HARNESS_ROOT__HARNESS-REVIEW-REPORT.md`（frontmatter 含 `gate_pass`）；
+     3. **深度门禁**：`overall_score >= 5.0`（C 级）、`critical_count == 0`、`gate_pass: true`，并经用户表单确认；
+     4. 通过后最小补丁写入 `phases.S85_pre_seal_validation`：`status: DONE`、`doctor_passed_at`、`doctor_report_path`、`review_report_path: HARNESS-REVIEW-REPORT.md`、`depth_review_score`、`depth_review_grade`、`critical_gaps: 0`、`review_gate_pass: true`。
+    **不得**在 doctor 未通过、`gate_pass: false` 或审查未确认时标 DONE。旧别名 `harness-build-harness-data-review` 已重定向至本 skill。
    - **S90_finalize** — **仅当 S85 为 DONE**。执行版本 bump、CHANGELOG、`specs.bootstrap_mode: false` 与归档；须遵守 `harness-build-rule-pre-seal-review` 封板清单。
 5. 每次完成后，**最小增量补丁**更新 `__HARNESS_ROOT__.harness-build-state.yaml`：
    - 已完成阶段标记 `status: DONE`，填写 `completed_at`
    - 将 `current_phase` 推进到下一个 PENDING 阶段
    - 用一句具体可执行的建议更新 `next_action`
    - 顶层 `updated_at` 刷新为当前 ISO8601 时间
+   - 同步更新 `__HARNESS_ROOT__task_list.md` 对应阶段勾选（若冲突，以 state 为准并回写）
 
 ## 输出格式
 

package/templates/_shared/build-skills/harness-build-skill-pre-seal-review.md

@@ -1,46 +1,208 @@
 ---
 name: harness-build-skill-pre-seal-review
+aliases:
+  - harness-build-final-review
+  - harness-build-harness-data-review
 description: >
-  封存前全面审查。在 svharness doctor 硬检查通过后，核对需求-specs 可追溯性、文档语义完整性、
-  references/wiki 一致性，并输出封存前审查报告。当用户说"封存前审查"、"pre-seal review"、
-  "doctor 通过后审查"、"S85 全面检查" 时触发。
+  S85 封存前唯一 Agent 语义审查：doctor 通过后执行 Part A（harness 完整性，arch-agnostic）
+  与 Part B（按 specs 层启用的深度质量评分）。产出 HARNESS-REVIEW-REPORT.md；
+  门禁要求 overall_score≥5.0（C 级）、critical_count=0、用户表单确认。
+  触发词：封存前审查、pre-seal review、S85 全面检查、.harness 质量审查、深度审查、差距分析。
+argument-hint: "[harness 根路径，默认为绑定元数据中的 harness_root_rel]"
 ---
 
-# harness-build-skill-pre-seal-review（封存前全面审查）
+# harness-build-skill-pre-seal-review（S85 合并审查 v2）
 
-你在 **S85_pre_seal_validation** 阶段工作。硬检查由 CLI 完成；你负责 **语义层全面审查** 与用户确认。
+你在 **S85_pre_seal_validation** 阶段工作。**硬检查**由 `svharness doctor` 完成；本 skill 负责 **完整性 + 深度质量** 双层语义审查，并写入统一报告。
+
+> 禁止写死具体项目目录名（如 `.he-harness`）或业务域术语作为默认逻辑；一切路径从 **`__HARNESS_ROOT__`**、`harness.yaml`、`.harness-build-state.yaml` 解析。
 
 ## 前置条件
 
-- 已执行 `svharness doctor --harness __HARNESS_ROOT__ --mode pre-seal --format json --report __HARNESS_ROOT__doctor-report.json`
-- 命令 **exit code 为 0**（若不为 0，先根据 `doctor-report.json` 修复后重跑，不得进入本 skill）
-
-## 算法
-
-1. 读取 `__HARNESS_ROOT__doctor-report.json`，在状态卡片中汇总 error/warning 数量。
-2. 若存在 warning，逐条说明：已修复 / 保留理由（须具体）。
-3. 执行 **全面审查清单**（须逐项打勾，不得跳过）：
-   - **需求可追溯**：遍历 `requirements/yaml/*.yaml`，核对 specs 四域是否有对应实现或显式 N/A。
-   - **描述完整性**：抽检 specs、agent-env/skills、tasks/templates 中描述字段，拒绝占位语义。
-   - **references**：核对 `references/yaml/index.yaml` 与 `references/apply-skills-registry.yaml`（若存在）。
-   - **wiki**（有 baseline 时）：抽检 `baseline/wiki/` 页面是否可回溯到 `baseline/code/`。
-   - **流程合规**：回顾构建期是否有未经表单确认的修改。
-   - **策略扫尾**：对 doctor 未覆盖文件执行 agent-agnostic / 中文抽检。
-4. 输出 **《封存前审查报告》**（中文），结构：
-   - doctor 结果摘要
-   - 审查清单逐项结论
-   - 待用户确认的风险项（若有）
-5. **必须以表单确认**「审查通过，可进入 S90 封板」；未经确认不得建议 orchestrator 将 S85 标为 DONE。
-6. 用户确认后，提示 orchestrator 最小补丁更新 state：
-   - `phases.S85_pre_seal_validation.status: DONE`
-   - `doctor_passed_at`（ISO8601）
-   - `doctor_report_path: doctor-report.json`
+1. 已执行：`svharness doctor --harness __HARNESS_ROOT__ --mode pre-seal --format json --report __HARNESS_ROOT__doctor-report.json`
+2. 命令 **exit code = 0**（否则只输出修复建议，不得进入评分与 gate_pass）
+3. 已读取 `__HARNESS_ROOT__harness.yaml` 与 `__HARNESS_ROOT__.harness-build-state.yaml`
+
+## Profile 加载（Part B）
+
+按 `harness.yaml` 的 `arch` 字段加载审查 profile（先深后浅）：
+
+1. `__HARNESS_ROOT__agent-env/review-profiles/<arch>.yaml`（若存在）
+2. `__HARNESS_ROOT__agent-env/review-profiles/_default.yaml`
+
+profile 提供：`min_depth_score`、`dimension_weights`、`critical_patterns`、可选 `oem_signal_name_patterns`（仅 arch profile）。
+
+## 算法总览
+
+```
+1. 读取 doctor-report.json → 摘要
+2. Part A：资产发现 + 完整性清单（必做）
+3. Part B：按 specs.layers 启用维度 → 评分 + 差距模式
+4. 阶段 G：覆盖率 quantity vs depth 自洽
+5. 计算 overall_score / grade / critical_count / gate_pass
+6. 写入 __HARNESS_ROOT__HARNESS-REVIEW-REPORT.md（含 YAML frontmatter）
+7. 表单确认；仅 gate_pass 且用户确认后建议 S85 DONE
+```
+
+---
+
+## Part A — Harness 完整性审查（必做，不计入加权分但可产生 Critical）
+
+从 `harness.yaml` **发现**资产（目录不存在记 N/A，非自动 FAIL）：
+
+| 发现项 | 配置键（harness.yaml） | 检查要点 |
+|--------|------------------------|----------|
+| 需求 | `requirements` | yaml/ 条目、coverage-report、traces_to |
+| 规格层 | `specs.layers[]` | 各层目录存在且有 YAML + schema.json |
+| 参考 | `references` | index.yaml、apply-skills-registry（若存在） |
+| 基线 | `baseline` | code/、wiki/（若有 baseline） |
+| Agent 环境 | `agent_env` | rules/、skills/、memory/ |
+| 任务 | `tasks.templates_dir` | 模板非空 |
+
+**阶段合规**：对照 `.harness-build-state.yaml`，S00–S80 在封存前应 DONE（S10_wiki 若不存在则跳过）。
+
+**可追溯**：若存在 `requirements/yaml/*.yaml`，每条需求须在已声明 spec 层有映射、`aggregates` 或合法 `waived`。
+
+**其它**：references/wiki 一致性；构建期表单确认（`harness-build-rule-user-interaction`）；中文与 agent-agnostic 扫尾。
+
+Part A 结论写入报告「Part A 清单」章节，逐项 PASS/WARN/FAIL/N/A。
+
+---
+
+## Part B — 深度质量审查（按层启用，10 分制加权）
+
+仅对 **harness.yaml 已声明且目录存在** 的 spec 层启用对应维度；权重从 profile 读取，**未启用层的权重按比例归一化**。
+
+### 维度 1：定量覆盖（默认启用，若存在 requirements + specs）
+
+对比精确计数（使用 `^- id:` / `^- name:` 等与实际 YAML 缩进一致的 pattern）：
+
+- requirements 条目数
+- 各 spec 层条目数（signals/ui/interfaces/behavior 等）
+
+判定：各层 ≥ requirements 为 PASS；否则 FAIL。
+
+### 维度 2：signals 深度（仅当存在 specs/signals）
+
+**通用启发式（不依赖 OEM 命名）**：
+
+- 索引式 ID 占比（如 `CMDID_<模块>_<编号>` 且无 `enum_values`/`can_msg_id`）
+- 方向分布：仅 `car2hmi` 无 `hmi2car` → WARN/FAIL
+- 字段深度：仅 id/name/direction/type/traces_to → 索引式
+
+**若 profile 提供 `oem_signal_name_patterns`**：计算 OEM 名占比；`< threshold` → 索引式规格（模式 P1，可 Critical）。
+
+### 维度 3：behavior 状态机（仅当存在 specs/behavior）
+
+- `req_count / state_count` > profile 阈值 → 严重不足（P4）
+- `transitions < states * 1.5` → WARN
+
+### 维度 4：interfaces 契约（仅当存在 specs/interfaces）
+
+- `methods:` 为空比例 > 90% → 索引式接口（P5）
+
+### 维度 5：ui 真实性（仅当存在 specs/ui）
+
+- `bound_signal` / `bound_*` 与 signals 中 ID 交叉校验（P7 Critical）
+- condition 明显截断（短于源 MD 同锚点 50%）→ P6
+
+### 维度 6：源数据完整性（仅当存在 requirements/md）
+
+- NaN 残留计数（> profile 阈值 → P8）
+- 用 profile `md_section_discovery` 正则定位大表区段；表行数 vs spec 信号条目数悬殊 → P3 Critical
+
+### 阶段 G：覆盖率报告真实性（若存在 coverage-report.yaml）
+
+- `coverage_ratio: 1.0` 但 Part B 有显著定性差距 → **P9 Critical**，**总分上限 4.0（D）**
+
+### 评分与等级
+
+| 总分 | 等级 |
+|------|------|
+| 9.0–10.0 | A |
+| 7.0–8.9 | B |
+| 5.0–6.9 | C |
+| 3.0–4.9 | D |
+| 0–2.9 | F |
+
+**gate_pass 计算**：
+
+```
+gate_pass = (doctor_exit_0)
+          AND (overall_score >= profile.min_depth_score，默认 5.0)
+          AND (critical_count == 0)
+```
+
+---
+
+## 报告产出：`HARNESS-REVIEW-REPORT.md`
+
+路径：`__HARNESS_ROOT__HARNESS-REVIEW-REPORT.md`（**只读审查**：不得修改 requirements/、specs/、coverage-report.yaml 源文件）。
+
+**文件开头必须为 YAML frontmatter**（doctor 可解析）：
+
+```yaml
+---
+review_version: "1.0"
+harness_version: "<harness.yaml version>"
+arch: "<harness.yaml arch>"
+doctor_passed: true
+overall_score: 6.2
+overall_grade: C
+critical_count: 0
+gate_pass: true
+quantity_coverage_ratio: 1.0
+depth_metrics: {}
+---
+```
+
+正文必含章节：
+
+1. 执行摘要（总分、等级、gate_pass、一句话判断）
+2. doctor 结果摘要
+3. Part A 完整性清单
+4. Part B 评分卡与逐维度证据（含文件路径与计数）
+5. 阶段 G 覆盖率真实性判定
+6. 差距汇总表（severity: Critical/High/Medium/Low）
+7. Top-5 修复建议
+8. 门禁结论（通过/不通过及原因）
+
+聊天中附简短摘要：总分、等级、Critical 数、Top-3 修复。
+
+---
+
+## S85 退出与 state 更新
+
+**仅当** `gate_pass: true` **且** 用户经表单确认「审查通过，可进入 S90 封板」后，提示 orchestrator 最小补丁：
+
+```yaml
+phases.S85_pre_seal_validation:
+  status: DONE
+  doctor_passed_at: <ISO8601>
+  doctor_report_path: doctor-report.json
+  review_report_path: HARNESS-REVIEW-REPORT.md
+  depth_review_required: true
+  min_depth_score: 5.0
+  min_depth_grade: C
+  depth_review_score: <overall_score>
+  depth_review_grade: <grade>
+  critical_gaps: 0
+  review_gate_pass: true
+  completed_at: <ISO8601>
+```
+
+若 `gate_pass: false` 或存在 Critical 未 waiver：报告结论为 **不通过**，不得建议 S90。
+
+若 `unmapped` 未闭环且无合法 waiver：Part A 即为不通过。
+
+---
 
 ## 守则
 
-- 不得替代 `svharness doctor` 做硬检查结论。
-- 不得在 doctor 失败时输出「审查通过」。
-- 所有面向用户的输出使用中文。
+- 不得替代 `svharness doctor` 宣称通过。
+- 不得在 doctor 失败时设 `gate_pass: true`。
+- 所有计数使用精确数字；扣分须引用路径与证据。
+- 面向用户说明使用中文；字段名/路径保留英文。
 
 ## 必须遵守的规则