git:20260730.6ee304a to git:20260829.ef3a006

---

name: spec-governance

description: 规范治理生命周期 — 意图驱动记录、RecordRouter 分流、SCV 规范变更验证；规范吸纳执行细节由 spec-absorption 承接

---

# Spec Governance Skill

## 定位

本 Skill 是规范治理生命周期的集中规则源，负责把“记录规范问题”和“规范变更验证”收口为统一链路；规范吸纳的候选扫描、通用性证明、消费者证明和实施执行由 `spec-absorption` 承接：

```text

发现 -> Intent Detection -> Ambiguity Guard -> RecordRouter -> Ledger Write -> Upgrade Check -> Verification

```

原则：

- AI 负责语义判断、上下文归因、多意图拆分和模糊表达澄清。

- 规则负责安全底线、CP 状态、台账格式、路径落点和 SCV 阶段要求。

- 工具负责文件存在、测试结果、部署同步、active-root 泄漏和 validate 探针。

## 记录意图识别

`PostAssessmentGovernanceIntakeGate`：每条非空用户消息都先登记一个**中性的待评估候选**，但候选不等于治理命中。AI 必须在完成合理性评估、项目现实扩展和上下文归因后，才判断是否存在治理记录意图；关键词、固定短语或正则只能帮助定位证据，不能作为候选分类、写台账或跳过评估的权威依据。普通问答也必须形成 `record.none` 的受控评估结果，而不是靠“未命中关键词”静默绕过。

| 规范化意图 | 触发含义 | 默认目标 |

|------------|----------|----------|

| `record.violation` | 已有明确规则，但 AI 未执行或执行错 | `data/violations.md` |

| `record.spec-defect` | 规范缺失、冲突、过窄、外部假设失效或拦截滞后 | `data/pending-fixes.md` |

| `record.process-improvement` | 用户提出更优执行策略，AI 验证后可泛化 | `data/process-improvements.md`（优化清单，PI） |

| `record.pending-issue` | 已确认但不阻断当前任务，适合后续批次治理 | `data/pending-issues.md` |

| `record.audit-gap` | 审计/validate/Hook 未发现本该发现的问题 | `data/gap-registry.md` |

| `record.none` | 普通解释、需求整理、报告整理，不是治理记录 | 不写台账 |

| `record.ambiguous` | 指代不清或可能误写台账 | 先澄清 |

## 置信度规则

| 置信度 | 条件 | 处理 |

|--------|------|------|

| 高 | 用户表达明确，且上下文证据支持唯一分类 | 直接分流并说明依据 |

| 中 | 主意图明确，但存在副意图或升级可能 | 先处理主意图，列出副意图 |

| 低 | “记录这个”等指代不清，或目标台账不唯一 | 不写台账，先澄清 |

每次候选评估必须输出结构化 `GovernanceIntakeDecision`：`候选锚点`、`评估结论`、`泛化范围`、`现有规范状态`、`规范化意图`、`置信度`、`依据`、`目标台账`、`写入要求`、`写入证据`、`skipEvidence`。未适用字段必须显式写 `N/A + reason`，不能省略后让 Hook 猜测。

### ContextualCandidateSet

- 候选集合按消息锚点持久化，至少保存 `id/sourceDigest/phase/verificationState`；新一轮消息不得覆盖上一轮未终结候选。

- 主阶段必须保留 `detected → assessed → generalized → routed → write-observed → acknowledged` 的有序历史；`record.none` 可在 challenge 通过后由 routed 进入 acknowledged，`uncertain/record.ambiguous` 必须停在 assessed，缺写入证据的实质意图必须停在 routed。禁止省略中间语义/证据阶段直接终结。

- 每个实质 intent state 必须保存 `targetLedger/claimedIds/observationIds/status`；复合候选逐项验证，不能只在 candidate 顶层保留一个总状态。

- 同一未终结消息重复送达时按 digest 去重并增加 `seenCount`；已终结消息再次出现时允许创建新候选，避免历史结论覆盖新上下文。

- Hook 只向 AI 暴露候选 ID、阶段、次数和最小消息锚点，不回显完整 prompt；多个未终结候选并存时，决策必须引用精确候选 ID。

- 旧版单候选状态必须迁移为 v2 candidate set；reset、项目目标切换和压缩恢复都不得丢失未终结候选。

### CompoundRecordRouterGate

同一候选可同时命中多个 `record.*` 意图，例如“更优策略 + 规范缺口 + 原有探针漏检”可形成 `record.process-improvement + record.spec-defect + record.audit-gap`。复合意图必须逐项给出目标台账、写入要求、证据 ID 与验证状态；全部必需意图都完成后候选才可终结。禁止只记录第一个命中项、用一个台账 ID 代替其余意图，或把 `record.none` / `record.ambiguous` 与实质写入意图混合。

### LedgerWriteEvidenceGate

- `写入要求=required` 时，只有成功的 `PostToolUse` 对**当前 active-root 的精确目标台账路径**形成观察，且本次工具输入和工具完成后的真实文件都包含相同、前缀正确的 ledger ID，才算 `verified`。PreToolUse、失败结果、只在回复中声称编号、只写错误项目/root、只在 patch 内容提到路径、目标文件不存在或宿主未暴露结果，都保持 `unverified`。

- `写入要求=already-recorded` 只适用于当前候选复用已存在记录的情况；必须在当前 active-root 的正确台账文件中重新读取并找到精确 ID，不能引用历史报告、错误 root 或仅凭记忆通过。

- 意图—台账—前缀固定映射：violation→`violations.md/VL-`、spec-defect→`pending-fixes.md/PF-`、process-improvement→`process-improvements.md/PI-`、pending-issue→`pending-issues.md/ISSUE-`、audit-gap→`gap-registry.md/GR-`。复合意图对每一项执行 all-of；任何一项未验证，候选都不能进入 `acknowledged`。

- Hook 只观察和验证写入证据，不自动创建台账条目；无法观察时明确保留 `unverified`，由 instruction-fallback 的报告/会话产物记录人工复证证据。

### RecordNoneChallengeGate

`record.none` 是需要证明的终结决策，不是默认兜底。它必须独占规范化意图，并同时提供 `评估结论=no-governance-impact`、合法泛化范围、`现有规范状态=exists-complete|not-applicable`、置信度、独立的具体依据、`写入要求=none` 与具体 `skipEvidence`；不得携带台账路径或 ID。范围为 `project-local|none` 时必须证明局部性/不可泛化；范围更广时只能由 `exists-complete` 及精确既有规则证据关闭。缺字段、可泛化改进仍未被完整规则覆盖、规范状态为 missing/partial/conflicting、与写入意图混合、依据和 skipEvidence 空泛或相互复制时，候选保持 `pending-none-challenge`。`record.ambiguous` 或 `评估结论=uncertain` 始终停在 assessed、保持未终结并先澄清。

## Improvement Intake（优化清单）

在所有模式下，除了处理“记录一下”这类显式记录请求，每条用户消息在完成合理性评估后，还必须执行一次主动 Improvement Intake：

- 若用户建议经验证**更优且可泛化**，即使没有说“记录一下”，也应主动写 PI。

- 若用户建议同时暴露了**规范未定义、过窄或不完整**，应同步写 PF。

- 若只是这次执行没有遵守已存在规则，应写 VL，而不是误写 PI/PF。

- 若只是业务项目的一次性偏好、局部临时安排或不可泛化做法，应判为 `record.none`。

### Intake 分流矩阵

| 场景 | 目标 |

|------|------|

| 更优策略，可泛化 | `PI` |

| 规范缺口 / 规范不完整 | `PF` |

| 更优策略 + 规范缺口同时成立 | `PI + PF` |

| 已有规则未执行 | `VL` |

| 一次性偏好 / 不可泛化 / 普通讨论 | `none` |

所有模式下，主动 Intake 完成后必须显式回执：`已记录 PI-xxx`、`已记录 PF-xxx` 或 `已记录 PI-xxx / PF-xxx`。

宿主 runtime 若标记 `governanceIntakeCandidate`，只能作为“可能需要 RecordRouter”的收尾提醒；AI 仍必须输出规范化意图、置信度、依据和目标台账，或明确 `record.none + skipReason`。禁止仅凭关键词由 Hook 自动写台账。

## InFlightIssueRequirementBindingGate（在途缺陷绑定当前需求）

当 dev/fix 任务已有当前需求或问题真相源且尚未闭环，在 CP2 前、实施中或验证阶段新发现/复现缺陷时，必须先判断它是否与当前目标、验收标准、实现路径、控制面或验证路线相关。相关缺陷不得只登记 PI/PF/ISSUE 后留待未来处理。

| 分类 | 必须动作 |

|------|----------|

| `blocking-related` | 立即暂停原计划的后续 mutation；把现象、证据、根因边界、影响、修复目标和回归条件写入当前需求/问题确认；用户面提醒是否一并纳入。用户已明确要求“一并处理/必须先处理”或有效 Auto 已授权时，记录 authority 后直接修订并优先修复，不重复索要确认 |

| `nonblocking-related` | 在继续实施前写入当前需求的纳入候选与验收影响；提醒用户决定 `include/defer`，确认 include 后同步技术方案、实施计划和 TestRoute |

| `unrelated` | 保持当前需求范围不变，按 RecordRouter 写相应台账或独立需求，并记录不纳入依据 |

最低记录字段为：`issueId / discoveredAt / reproductionEvidence / relation / severity / includeDecision / decisionAuthority / requirementPatch / solutionImpact / testImpact / priority`。`includeDecision=pending` 时不得把相关缺陷从当前需求上下文中移除；确认 `include` 后，必须在源码修复前完成需求、技术方案、验收和测试映射同步。阻断项的优先级高于原需求后续阶段，修复并通过定向回归后方可恢复原计划。

以下均不构成完成：只写 PI/PF、只在报告提到、只在记忆留 TODO、只回复用户“已记录”、或等待任务结束后再补需求。若缺陷是在复审/验证中复现，复现证据本身即为绑定触发，不得以“此前未在需求中”为由排除。

## LayeredAbsorptionGate（分层吸纳归属判定）

`LayeredAbsorptionGate` 是 Improvement Intake 之后、规范源实施之前的强制架构门禁。`SkillFirstAbsorptionGate` / `CapabilityToSkillPromotionGate` 保留为 Skill 层兼容子门禁。任何可泛化 PI / PF / GAP / ISSUE 或用户确认值得吸纳的策略，都不能默认追加到 `CrossProjectLearnedGuards`、`LatestAbsorptionGuards` 或通用 instructions 长列表，也不能只做“通用规范 / Skill”二选一；必须先判断归属并列出所有消费层。

> 执行归属：本节只定义治理层门禁与输出字段。候选来自 `.devcodex/*/data`、“最新可吸纳 / 仍需吸纳 / 开始吸纳”时，必须读取 `spec-absorption`，先执行 `CommonNormGeneralizationGate` 与 `AbsorptionCandidateConsumerProofGate`，证明通用价值和 DevCodex 当前消费者；项目独有规则只能作为 `project-local` 或 `case-evidence-only`，不得进入通用规范。

### 归属分类

| 分类 | 含义 | 处理 |

|------|------|------|

| `global-invariant` | 安全底线、入口加载、优先级、路由或全模式硬约束 | 写入 instructions / safety / common，Skill 只引用 |

| `existing-skill-subgate` | 属于既有 Skill 的子门禁或执行步骤 | 并入目标 Skill，并同步 TestRoute / report / validate |

| `new-skill-required` | 已形成独立能力入口 | 新建或规划独立 Skill，通用规范只保留触发和路由 |

| `docs-only` | 仅是说明、历史镜像或用户文档补充 | 写 README / website / changelog，不作为执行门禁 |

### 新 Skill 判定条件

满足任一条件应优先判为 `new-skill-required`：

1. 需要 3 条以上相关子门禁或一组稳定执行步骤。

2. 需要独立产物、状态文件、模板、清单或证据矩阵。

3. 跨 dev / fix / audit / release / report 多个工作流复用。

4. 用户会用自然语言直接点名该能力，例如“用户使用文档”“复审清单”“发布前审查”。

5. 只放在通用规范会导致触发条件模糊、提示词膨胀、职责边界不清或验证只能检查文本存在。

### LayeredAbsorptionDecision 输出

每次吸纳实施前，CP2 / 技术方案 / 报告至少记录：

| 字段 | 说明 |

|------|------|

| `candidateId` | PI / PF / GAP / ISSUE / 用户确认项 |

| `classification` | `global-invariant` / `existing-skill-subgate` / `new-skill-required` / `docs-only` |

| `targetSkill` | 既有 Skill 或新 Skill 名；N/A 时说明原因 |

| `triggerTerms` | 用户自然语言触发词或工作流触发场景 |

| `ownedArtifacts` | 该 Skill 负责的文档、清单、模板、状态或验证产物 |

| `layerChecks` | 分层同步检查，至少覆盖 `commonInstruction`、`skill`、`promptTemplate`、`executionConsumer`、`validationProbe`、`publicDocs`、`deployCopy` |

| `validationRoute` | validate 编号、targeted test、SCV 或人工证据 |

| `consumerSync` | instructions、skills、prompts、README、website、Profile、部署副本同步范围 |

`SkillAbsorptionDecision` 是 `LayeredAbsorptionDecision` 的 Skill 层兼容字段，不能替代完整分层决策。若判定为 `new-skill-required`，不得只把规则追加到通用守门清单后宣告吸纳完成；必须在同批创建 Skill，或把未创建原因写入 PF / ISSUE，并在后续批次优先处理。任何层级判定为 N/A 都必须写 `skipReason`。

## CapabilitySurfaceDecisionGate（能力载体中央决策）

新增或升级规则、Skill、Prompt、Resource、Tool、task-augmented Tool、CLI、Hook 或结构化

状态能力时，在 `LayeredAbsorptionDecision` 之后、创建/修改具体载体之前，必须执行 registry

group `capability-surface-decision`。本 Gate 解决“直接写规则还是设计 MCP/CLI/Hook”，

不替代 platform/Agent architecture 的 primitive、宿主与权限证据。

### 唯一真相源与责任边界

| field | contract |

|---|---|

| decision owner | `spec-governance` |

| canonical schema | `skills/spec-governance/capability-surface-decision.v1.schema.json` |

| deterministic validator | `scripts/lib/capability-surface-decision.js` |

| canonical record | `<active-root>/<kind>/<task>/capability-surface-decisions/<decisionRef>.json` |

| writer | 当前 workflow 的 `workflow-single-writer` |

| evidence providers | `platform-ecosystem-architecture`、`ai-agent-system-architecture` |

| readers | CP2/CP3、spec absorption、Skill lifecycle、TestRoute、report、source-consumer-sync、SCV |

| domain Skill | 仅保存局部能力元数据和 `decisionRef`；不得复制中央 surface/权限/宿主矩阵 |

中央 Gate 不是 MCP server，不持有领域 runtime state，也不改变宿主能力。被选中 surface 的

既有 owner 继续负责 runtime/state/transaction；新增 server 仍须独立比较 owner、事务、

信任/故障域、消费者、迁移和回滚。

### 决策路线

| capability reality | preferred surface |

|---|---|

| 开放式、非确定性语义判断 | `rule-skill` |

| 用户主动调用的可复用模板 | `prompt` |

| 有界只读内容或参数化内容 | `resource` / `resource-template` |

| 有界、确定性查询或受控操作 | `tool` |

| 已协商、可取消且有 TTL/轮询/fallback 的长任务 | `task-augmented-tool` |

| 宿主 lifecycle/event | `hook` |

| 低频 operator 运维或复杂本地流程 | `cli` |

选择 `tool` 或 `task-augmented-tool` 后必须继续判断 `read/write/execute`、

control party、runtime/state/transaction owner、scope、confirmation、allowlist、

idempotency、timeout/cancel、receipt/audit。Tasks 未在 client/server 双侧协商时，

不得启用 task surface，必须回退同步 Tool 或 CLI。

### CapabilitySurfaceDecisionV1

最低字段由 canonical schema 唯一定义，包含：

`decisionRef / capabilityId / capabilityKind / semanticJudgement / contentDelivery /

determinism / invocationFrequency / preferredSurface / controlParty / readWriteExecute /

decisionOwner / runtimeOwner / stateOwner / transactionBoundary / hostMatrix / fallback /

consumers / validationRoute / decisionEvidence / canonicalRecordPath / writer / readers /

identity / invalidationTriggers / truthBoundary / status`。

条件字段：

- write/execute → `authority`；

- Prompt/Resource/Tool/task surface → `mcpContract`；

- task surface → `taskContract`，且 negotiated capabilities 必含 `tasks`；

- Resource/Resource Template → `resourceContract` 的 payload/freshness/URI bound。

状态为 `draft / validated / frozen / stale / blocked`。`validated/frozen` 必须通过 schema、

surface-specific invariants、identity 与负向 fixture；`stale/blocked` 不得被 CP、报告或

生命周期消费者当作可实施证据。

### Freshness 与失效

`identity` 绑定 `schemaDigest/sourceHead/checkedAt/evidenceDigest`。schema、source、

evidence、host、protocol、consumer 或 runtime owner 任一变化即重新验证；只更新时间不能

恢复 freshness。validator receipt 必须暴露 classification、issues、openBlockers、

decision/schema digest 与 freshness reasons。

### 必要负向探针

- 开放式语义判断被强制做成 Tool；

- 无界内容作为 MCP payload；

- write/execute 缺 authority/confirmation/allowlist/idempotency/cancel/receipt；

- Tasks 未协商仍启用或 fallback 递归；

- 新 server 无 owner/consumer/migration/rollback；

- 领域 Skill 复制中央字段或出现第二 writer；

- decisionRef/path 重复、identity stale、host/decision evidence 为 BLOCK；

- 只有 `preferredSurface` 字段但没有可重放的完整 decision record。

## HistoricalCommonNormLayeringGate（历史通用规范分层迁移）

当用户要求“之前吸纳的规范重新分层”“全面逐个文件审查”“不要都堆在通用规范里”，或复审发现通用 instructions / prompt / report 模板持续承载大段执行正文时，必须执行 `HistoricalCommonNormLayeringGate`。

### 逐文件审查矩阵

迁移前先创建并冻结逐文件审查矩阵，至少包含：

| 字段 | 说明 |

|------|------|

| `file` | 当前文件或历史镜像范围 |

| `currentRole` | 当前角色：source、consumer、prompt-template、validate-probe、public-doc、deploy-copy、historical-mirror |

| `matchedRules` | 命中的 Gate / 规则族 / 用户确认项 |

| `targetLayer` | `commonInstruction`、`skill`、`promptTemplate`、`executionConsumer`、`validationProbe`、`publicDocs`、`deployCopy`、`historicalMirror` |

| `targetOwner` | 目标 Skill、prompt、脚本、文档或部署副本 |

| `action` | `retain-index`、`move-detail-to-skill`、`add-probe`、`sync-docs`、`historical-skip`、`legacy-index-retained` |

| `semanticStrength` | `same-or-stronger`、`weaker-needs-confirmation` |

| `validation` | targeted test、validate 编号、SCV、构建、部署同步或人工证据 |

| `skipReason` | 历史镜像、无当前消费者、N/A 原因 |

### 迁移规则

- 通用 instructions 只保留安全底线、全局不变量、触发索引、跨 Skill 路由和历史兼容锚点；不得继续成为新 Gate 正文的默认容器。

- 具体执行步骤、证据字段、测试路线、发布门禁、用户文档写作、复审清单、Profile 同步和自我进化控制面必须进入对应 Skill、Prompt/Report 模板、执行消费者和 validate 探针。

- 已在通用层存在但尚未找到同等强度承接方的历史规则，不得直接删除；标记为 `legacy-index-retained`，保留 Gate 名 grep 锚点，并把补迁移项写入矩阵 / PF / ISSUE。

- Prompt 和 report 只能承载字段与输出结构，不复制完整 Gate 长清单；需要全量执行的内容由目标 Skill 读取。

- 历史 release / version / requirement 镜像默认按 `historicalMirror` 处理，不回写当前架构口径；当前 README、website guide、active version、changelog、Profile 和部署副本必须同步。

- 新增或补强该迁移能力时必须更新 V74 或后续 validate 探针，检查 `HistoricalCommonNormLayeringGate`、逐文件矩阵、目标 Skill、Prompt/Report、public docs 与 deploy copy。

### PromptLongGateListDriftProbe

`PromptLongGateListDriftProbe` 是历史长清单迁移后的防回流探针。当前 README、website guide、拆分 instructions、technical-design / implementation-plan / report prompts 等消费者只能写 `GovernanceGateRegistry`、`gateGroup`、ownerSkill、validationRoute、skipReason 和少量代表锚点；不得重新复制 `CrossProjectLearnedGuards`、`LatestAbsorptionGuards` 或 `ConfirmedAbsorptionCompletenessGates` 的完整 Gate 长清单。

探针必须包含 SCV 负向样例：用旧版跨项目长清单、完整吸纳长清单和最新吸纳长清单构造样例，确认检测逻辑会失败；同时用分组 registry 摘要构造正向样例，确认不会误伤。若复审发现 prompt、report、README 或 website 又出现跨组大清单，应先记录逃逸原因，再补 `GovernanceGateRegistry` / gateGroup 引用和目标 Skill 承接方。

### 分层检查面

| 层级 | 必查内容 |

|------|----------|

| `commonInstruction` | S/C/公共治理、拆分 instructions、CrossProject 索引是否需要同步 |

| `skill` | 既有 Skill 子门禁、新 Skill、Skill frontmatter、plugin 注册和路由是否需要同步 |

| `promptTemplate` | 技术方案、实施计划、报告、需求/审查等 prompt/template 是否需要同步 |

| `executionConsumer` | TestRoute、report、document-sync、release/audit/dev/fix 执行消费者是否需要同步 |

| `validationProbe` | validate、targeted test、SCV、负向用例或人工证据是否需要同步 |

| `publicDocs` | README、website、changelog、用户可见版本文档是否需要同步 |

| `deployCopy` | `.github`、`.claude`、`AGENTS.md`、`.agents`、`.codex` 或 Profile 部署副本是否需要同步 |

## GovernanceGateRegistry（治理 Gate 分组注册表）

`GovernanceGateRegistry` 是 PC4、技术方案、实施计划、报告模板和 validate 探针共同引用的 Gate 分组索引。通用 instructions 或 prompts 不应复制完整 Gate 长清单；它们只记录 `gateGroup / ownerSkill / trigger / requiredEvidence / validationRoute / skipReason`。

机器可读唯一索引为同目录 `gate-registry.json`。本节保留 Owner 执行语义和少量人读说明；group ID、Owner、证据字段和验证路线的完整性由 `scripts/lib/control-plane-contracts.js` 校验，新增或修改分组必须先更新 JSON，再同步 Owner Skill。

完整的 group ID、Owner、触发、证据字段、验证路线和 legacy anchors 只维护在 `gate-registry.json`。下表不再作为事实源；本节仅保留职责域摘要。

| 稳定职责域 | 代表 gateGroup | Owner 入口 |

|---|---|---|

| 修复与复审 | `repair-collaboration`、`repair-prevention-assessment`、`review-checklist`、`review-escape`、`rework-prevention` | execution-contract / active repair-prevention-assessment / review-checklist；长期效果才路由 gray rework-prevention-engineering |

| 规范吸纳 | `absorption-layering`、`historical-common-layering`、`confirmed-completeness` | spec-absorption / spec-governance |

| 基座准入 | `base-admission-governance` | spec-absorption / skill-lifecycle-governance / test-router；记录 `BaseImpactAssessmentV1`、`ComplexityDeltaBudgetV1` 与未受影响意图回归 |

| 交付与运行态 | `frontend-runtime`、`public-surface`、`release-parity`、`interactive-semantics` | 对应领域 Owner + test-router |

| Profile 与规模 | `profile-service`、`memory-bootstrap`、`artifact-scale-skill-gap`、`skill-lifecycle` | load-profile / memory / skill-gap-analysis / skill-lifecycle-governance |

| 演进与跨仓 | `evolution-control-plane`、`consumer-validation`、`module-performance-maintenance` | evolution-governance / consumer-validation-engineering / performance-engineering |

| 文档与专家质量 | `user-manual`、`docs-ia-readability`、`expert-output-quality`、`expert-owner-skills` | user-manual-authoring / expert-output-quality / 各专家 Owner |

V85 的专家 Owner 集合、A1~A10 对应分组以及 `feature-inventory-batch-evidence` 已作为 registry entry 和 legacyAnchors 登记；不得在本文件继续追加版本批次表。

新增 Gate 时必须先登记或复用 gateGroup，再同步 owner Skill、prompt/report 字段、TestRoute、validate 探针、README/website/changelog 和部署副本。无法归入现有 gateGroup 时，优先判断是否应新增独立 Skill，而不是把正文追加到通用长清单。

A1~A10 最新吸纳执行包默认复用上述 `docs-semantics-examples`、`derived-consumer-runtime`、`feature-inventory-batch-evidence`、`profile-service` 与 `absorption-layering` 分组；报告只写分组、ownerSkill、validationRoute 和代表锚点，不复制完整长清单。

### ProactiveBetterAlternativeGate

处理用户建议、确认、规范吸纳、CP2 方案或复审清单冻结前，必须主动比较用户方案与至少一种项目现实可行的替代路径。若存在更低风险、更完整、更易维护或更易验证的路径，应先提出建议、收益、代价和影响范围，再进入确认或实施；不得只因用户提出方向就顺从式记录。若用户方案已是当前最优，记录依据，例如真相源证据、消费者范围、验证成本、迁移风险或用户明确约束。

`AcceptedSuggestionRootCauseGate`：当用户提出更优方案、纠正命名 / IA / 验证路线 / 范围边界，且 AI 采纳该方案时，最终回复和报告必须说明为什么前序检查没发现、采纳依据、写入或关闭的 VL / PI / PF / GAP 编号，以及下次防复发动作。若只是一次性偏好或业务局部调整，写 `record.none + skipReason`；若暴露规范缺口，按 RecordRouter 写台账并进入 LayeredAbsorptionGate。

## ConfirmedAbsorptionCompletenessGates

当用户确认“未完整吸纳 / 还要一起吸纳 / 刚才这些都要补上”或复审发现只有概念覆盖、缺独立 Gate、缺 Skill、缺 Prompt、缺探针或缺部署副本时，必须把该批规则作为 `ConfirmedAbsorptionCompletenessGates` 处理。执行路线：

1. 先读取 `spec-absorption`，复核候选是否仍有价值，并通过 `CommonNormGeneralizationGate` 剔除已完整吸纳、不适合泛化或属于项目独有的项。

2. 为每项输出 `LayeredAbsorptionDecision`，标明 `global-invariant / existing-skill-subgate / new-skill-required / docs-only`。

3. 对每项执行 `AbsorptionCandidateConsumerProofGate`，证明 DevCodex 当前消费者和目标 owner。

4. 对每个 `layerChecks` 逐层同步：`commonInstruction / skill / promptTemplate / executionConsumer / validationProbe / publicDocs / deployCopy`。

5. 若某项已经在正文中出现，但没有 Gate 名、触发条件、报告字段或 validate 探针，不得判定为完整吸纳。

本批能力域与 legacy 名称统一从 `gate-registry.json` 查询：按触发事实选择 `gateGroup`，再根据 `ownerSkills / requiredEvidence / route / legacyAnchors` 完成分层同步。控制面能力必须交给 registry 指定的独立 Owner，不能因为本节负责 intake 就留在 `spec-governance` 内实现。

## Backlog Intake 真相复核

当新的需求、bug、批次计划或尾项治理**直接来源于 `data/*.md` 的 open/partial 条目**时，不能把这些编号直接视为本轮真实 open。进入 CP1 / 问题确认或批次实施前，必须先做 Backlog Intake 真相复核：

| 分类 | 含义 | 处理 |

|------|------|------|

| `pure-open` | 主体尚未实施，仍是当前真实 open | 直接纳入本轮 |

| `residual-tail` | 主体已修，只剩尾项/补强/探针/文书 | 缩减为尾项治理 |

| `already-fixed` | 代码/产物已修，仅状态没回写 | 先回写台账并从本轮范围剔除 |

| `misclassified` | 台账分类、描述、归属或计数错误 | 先修正台账与统计口径，再决定是否继续纳入 |

最小复核动作：

1. 对照源码、运行时台账、最新报告/进度、测试结果和记忆索引。

2. 为每个候选编号给出上述分类之一。

3. 非 `pure-open` 项必须先回写台账，再修正 CP1/CP2/CP3 的范围、统计与实施计划。

4. 用户面至少说明：候选编号、分类结果、是否缩减本轮范围。

## 台账落点与关闭证据

- `data/*.md` 是运行时逻辑台账路径，实际写入必须先解析 active-root。

- 旧布局写 `<项目根>/.devcodex/data/`；workspace-namespace 单项目写 `<工作区根>/.devcodex/<project>/data/`；全工作区写 `<工作区根>/.devcodex/workspace/data/`。

- `WorkspaceDataAbsorptionScopeGate`：当用户要求“检查 data 目录、最新可吸纳问题、仍需吸纳清单、开始吸纳”时，候选扫描范围必须是工作区 `.devcodex/*/data/` 全部命名空间；不能只扫描源码项目、当前 sticky activeProject 或某一个 runtime active-root。输出至少包含命名空间、台账文件、候选编号、归属判断、跳过原因与最终纳入范围。

- DevCodex 规范自身、Hook、Skill、模板、validate 或宿主适配链路问题归属当前 DevCodex 源仓或规范维护项目的 active-root；在 `workspace-namespace` 下应解析为承载 DevCodex 源码或规范资产的项目命名空间，不得因当时正在处理业务项目而写入业务项目台账。

- `data/process-improvements.md` 在本 Skill 中也可称“优化清单（PI）”；当建议针对 DevCodex 规范自身时，PI/PF 的 active-root 归属同样遵循上条，不得写入业务项目台账。

- VL/PF 关闭前必须具备修复方案、修复时间、验证状态、验证时间、验证证据与关闭时间；仅“已登记”不得视为“已验证关闭”。

- VL/PF 关闭链的时间顺序必须满足 `登记时间 ≤ 修复时间 ≤ 验证时间/关闭时间`；不得写入未来时间或让关闭/验证早于登记。若只能确定日期而非分钟，先保留 `—` 并在证据中说明来源，禁止倒填一个看似精确但破坏时间线的值。

- 若实施、复审或范围收紧改变了 VL/PF/PI/ISSUE/GAP 的真实状态，必须执行**台账状态回写闭环**：回写状态、验证证据、验证时间、关闭时间或部分完成说明，并在批次完成前做 1 轮 target ledger rescan，确认 open 计数、进度、报告和 SUMMARY 已同步。

## RuntimeStateTransitionProjectionGate

运行态索引必须把 append-only 历史与当前投影分开：每个物理 source 的最后已知状态形成 `sourceProjections`，同源先后状态形成 `historicalTransitions`；合法 `open/partial/deferred/closed` 迁移不能仅因出现多个历史值而报警。

当前状态按 `canonical ledger > Agent SUMMARY > cross-ledger reference > daily task > global SUMMARY` 选择。只有最高合格权威层的多个当前投影不一致时才输出 `CONFLICTING_CURRENT_STATE`；低权威消费者滞后写入 `consumerDrifts`，用于修复同步但不冒充 strict conflict。索引必须保持只读，并同时公开 `observedStatuses`、`currentProjection`、历史迁移数、consumer drift 数和精确 alert。

## RecordRouter

RecordRouter 只在记录意图识别后执行。

| 输入 | 判定 | 目标 |

|------|------|------|

| AI 明确违反已有规范 | 有规则但未执行 | VL |

| 用户指出 AI 漏做流程、错用规范、误判完成或误写台账 | 已有规则未执行时记 VL；规则缺失/不清时升级 PF/GAP | VL / PF / GAP |

| 规范本身缺失、冲突、滞后 | 规则需要修复 | PF |

| 用户提出更优策略并被采纳 | 过程策略优化 | PI |

| 已确认但不阻断当前任务 | 可排期治理 | ISSUE |

| 检查体系存在盲区 | 检测能力缺口 | GAP |

升级规则：

1. 重复 VL 不得只追加违规，应判断是否升级 PF 或 GAP。

2. PF 经用户确认且可排期时，可转 ISSUE。

3. PI 只有在策略可泛化且不破坏现有规则时才写入。

4. GAP 必须包含“为什么原检查没有发现”和“建议探针”。

5. 实施完成复审、ECR 或审计复审发现新问题时，必须执行 `ReviewEscapeRecordGate`：在复审清单中记录 `escapedItem`、`previousChecklistGap`、`whyMissed`、`missingDimensionOrProbe`、`prevention`、`checklistPatch`、`rerunEvidence`，再判断是否升级 VL/PF/GAP。

## SCV 规范变更验证

当修改规范源、Skill、Hook、CLI、MCP、模板、部署副本、website specs、路径规则或 validate 语义时，必须执行 SCV。

### Concept Sync Map

控制面或模板-示例-校验链任务在进入 SCV-2 前，必须先建立 Concept Sync Map；推荐直接调用 `source-consumer-sync`：

| 字段 | 说明 |

|------|------|

| `sourceOfTruth` | 当前事实源 |

| `currentConsumers` | 本轮必须同步的当前消费者 |

| `historicalMirrors` | 仅作历史归档的镜像 |

| `validateProbes` | `validate` 编号、targeted tests、replay 或其他探针 |

| `deployCopies` | `.github/`、`.claude/`、`AGENTS.md`、`.agents/`、`.codex/` 等部署副本 |

| `yellowDeviationBoundary` | 允许按黄色偏离一并纳入的当前消费者/探针 |

| 阶段 | 目标 | 最小动作 |

|------|------|----------|

| SCV-0 | 变更分类 | 判断文字、语义、控制面、宿主适配、路径存储、文档镜像 |

| SCV-1 | Concept Sync Map | 列出 `sourceOfTruth`、`currentConsumers`、`historicalMirrors`、`validateProbes`、`deployCopies`、`yellowDeviationBoundary` |

| SCV-2 | CRS 双向联查 | 正向 grep 关键词，反向推导应同步但缺失的当前消费者和探针 |

| SCV-3 | 可执行验证 | 运行 `node scripts\validate.js` 与相关 targeted tests |

| SCV-4 | 行为回放 | 回放 Hook/MCP/CLI 场景，验证宿主契约、visible reply 证据与路径行为 |

| SCV-5 | 部署副本同步 | 执行并验证部署副本同步或明确 N/A |

| SCV-6 | 产物边界扫描 | 检查 workspace root、legacy `.devcodex`、错误 `.tmp`、报告/记忆落点 |

| SCV-7 | 完成判定 | 报告、memory、SUMMARY、dirty 边界、推荐结论一致 |

完成规则：

- SCV 结果必须写入报告，不能只写“已验证”。

- 黄色偏离必须写明为什么仍在 `yellowDeviationBoundary` 内，且不能把当前消费者伪装成历史镜像。

- SCV 失败时不得宣告任务完成。

- 控制面任务的 ECR-7 必须引用 SCV 证据。

## AI 与确定性边界

| 交给 AI | 交给规则/工具 |

|---------|---------------|

| 自然语言意图、上下文指代、多意图拆分 | 删除/危险命令/用户与项目敏感信息策略 |

| 判断违规 vs 规范缺口 | active-root、workspace-namespace 路径 |

| 判断建议是否可泛化 | CP 状态、台账编号、模板字段 |

| 判断是否需要澄清 | 测试、lint、validate 实际结果 |

| 判断重复违规是否应升级 | 部署副本 hash、文件存在性、SCV 完成状态 |

禁止：

- 禁止仅凭关键词把“记录一下”写成 VL。

- 禁止低置信度下静默写台账。

- 禁止用 AI 主观判断替代测试和 validate 结果。

- 禁止用户指定错误台账时盲从，必须做合理性复核。