القائمة
规范治理生命周期 — 意图驱动记录、RecordRouter 分流、SCV 规范变更验证；规范吸纳执行细节由 spec-absorption 承接
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/devcodex-labs/devcodex --skill spec-governanceيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
| name | spec-governance |
| description | 规范治理生命周期 — 意图驱动记录、RecordRouter 分流、SCV 规范变更验证；规范吸纳执行细节由 spec-absorption 承接 |
本 Skill 是规范治理生命周期的集中规则源，负责把“记录规范问题”和“规范变更验证”收口为统一链路；规范吸纳的候选扫描、通用性证明、消费者证明和实施执行由 spec-absorption 承接：
发现 -> Intent Detection -> Ambiguity Guard -> RecordRouter -> Ledger Write -> Upgrade Check -> Verification
原则：
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 猜测。
id/sourceDigest/phase/verificationState；新一轮消息不得覆盖上一轮未终结候选。detected → assessed → generalized → routed → write-observed → acknowledged 的有序历史；record.none 可在 challenge 通过后由 routed 进入 acknowledged，uncertain/record.ambiguous 必须停在 assessed，缺写入证据的实质意图必须停在 routed。禁止省略中间语义/证据阶段直接终结。targetLedger/claimedIds/observationIds/status；复合候选逐项验证，不能只在 candidate 顶层保留一个总状态。seenCount；已终结消息再次出现时允许创建新候选，避免历史结论覆盖新上下文。同一候选可同时命中多个 record.* 意图，例如“更优策略 + 规范缺口 + 原有探针漏检”可形成 record.process-improvement + record.spec-defect + record.audit-gap。复合意图必须逐项给出目标台账、写入要求、证据 ID 与验证状态；全部必需意图都完成后候选才可终结。禁止只记录第一个命中项、用一个台账 ID 代替其余意图，或把 record.none / record.ambiguous 与实质写入意图混合。
写入要求=required 时，只有成功的 PostToolUse 对当前 active-root 的精确目标台账路径形成观察，且本次工具输入和工具完成后的真实文件都包含相同、前缀正确的 ledger ID，才算 verified。PreToolUse、失败结果、只在回复中声称编号、只写错误项目/root、只在 patch 内容提到路径、目标文件不存在或宿主未暴露结果，都保持 unverified。写入要求=already-recorded 只适用于当前候选复用已存在记录的情况；必须在当前 active-root 的正确台账文件中重新读取并找到精确 ID，不能引用历史报告、错误 root 或仅凭记忆通过。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。unverified，由 instruction-fallback 的报告/会话产物记录人工复证证据。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：
record.none。| 场景 | 目标 |
|---|---|
| 更优策略，可泛化 | PI |
| 规范缺口 / 规范不完整 | PF |
| 更优策略 + 规范缺口同时成立 | PI + PF |
| 已有规则未执行 | VL |
| 一次性偏好 / 不可泛化 / 普通讨论 | none |
所有模式下，主动 Intake 完成后必须显式回执：已记录 PI-xxx、已记录 PF-xxx 或 已记录 PI-xxx / PF-xxx。
宿主 runtime 若标记 governanceIntakeCandidate，只能作为“可能需要 RecordRouter”的收尾提醒；AI 仍必须输出规范化意图、置信度、依据和目标台账，或明确 record.none + skipReason。禁止仅凭关键词由 Hook 自动写台账。
当 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 是 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，不作为执行门禁 |
满足任一条件应优先判为 new-skill-required：
每次吸纳实施前，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。
新增或升级规则、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。
最低字段由 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。
条件字段：
authority；mcpContract；taskContract，且 negotiated capabilities 必含 tasks；resourceContract 的 payload/freshness/URI bound。状态为 draft / validated / frozen / stale / blocked。validated/frozen 必须通过 schema、
surface-specific invariants、identity 与负向 fixture；stale/blocked 不得被 CP、报告或
生命周期消费者当作可实施证据。
identity 绑定 schemaDigest/sourceHead/checkedAt/evidenceDigest。schema、source、
evidence、host、protocol、consumer 或 runtime owner 任一变化即重新验证；只更新时间不能
恢复 freshness。validator receipt 必须暴露 classification、issues、openBlockers、
decision/schema digest 与 freshness reasons。
preferredSurface 字段但没有可重放的完整 decision record。当用户要求“之前吸纳的规范重新分层”“全面逐个文件审查”“不要都堆在通用规范里”，或复审发现通用 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 原因 |
legacy-index-retained，保留 Gate 名 grep 锚点，并把补迁移项写入矩阵 / PF / ISSUE。historicalMirror 处理，不回写当前架构口径；当前 README、website guide、active version、changelog、Profile 和部署副本必须同步。HistoricalCommonNormLayeringGate、逐文件矩阵、目标 Skill、Prompt/Report、public docs 与 deploy copy。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 是 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 和代表锚点，不复制完整长清单。
处理用户建议、确认、规范吸纳、CP2 方案或复审清单冻结前，必须主动比较用户方案与至少一种项目现实可行的替代路径。若存在更低风险、更完整、更易维护或更易验证的路径，应先提出建议、收益、代价和影响范围，再进入确认或实施；不得只因用户提出方向就顺从式记录。若用户方案已是当前最优，记录依据，例如真相源证据、消费者范围、验证成本、迁移风险或用户明确约束。
AcceptedSuggestionRootCauseGate：当用户提出更优方案、纠正命名 / IA / 验证路线 / 范围边界，且 AI 采纳该方案时，最终回复和报告必须说明为什么前序检查没发现、采纳依据、写入或关闭的 VL / PI / PF / GAP 编号，以及下次防复发动作。若只是一次性偏好或业务局部调整，写 record.none + skipReason；若暴露规范缺口，按 RecordRouter 写台账并进入 LayeredAbsorptionGate。
当用户确认“未完整吸纳 / 还要一起吸纳 / 刚才这些都要补上”或复审发现只有概念覆盖、缺独立 Gate、缺 Skill、缺 Prompt、缺探针或缺部署副本时，必须把该批规则作为 ConfirmedAbsorptionCompletenessGates 处理。执行路线：
spec-absorption，复核候选是否仍有价值，并通过 CommonNormGeneralizationGate 剔除已完整吸纳、不适合泛化或属于项目独有的项。LayeredAbsorptionDecision，标明 global-invariant / existing-skill-subgate / new-skill-required / docs-only。AbsorptionCandidateConsumerProofGate，证明 DevCodex 当前消费者和目标 owner。layerChecks 逐层同步：commonInstruction / skill / promptTemplate / executionConsumer / validationProbe / publicDocs / deployCopy。本批能力域与 legacy 名称统一从 gate-registry.json 查询：按触发事实选择 gateGroup，再根据 ownerSkills / requiredEvidence / route / legacyAnchors 完成分层同步。控制面能力必须交给 registry 指定的独立 Owner，不能因为本节负责 intake 就留在 spec-governance 内实现。
当新的需求、bug、批次计划或尾项治理直接来源于 data/*.md 的 open/partial 条目时，不能把这些编号直接视为本轮真实 open。进入 CP1 / 问题确认或批次实施前，必须先做 Backlog Intake 真相复核：
| 分类 | 含义 | 处理 |
|---|---|---|
pure-open | 主体尚未实施，仍是当前真实 open | 直接纳入本轮 |
residual-tail | 主体已修，只剩尾项/补强/探针/文书 | 缩减为尾项治理 |
already-fixed | 代码/产物已修，仅状态没回写 | 先回写台账并从本轮范围剔除 |
misclassified | 台账分类、描述、归属或计数错误 | 先修正台账与统计口径，再决定是否继续纳入 |
最小复核动作：
pure-open 项必须先回写台账，再修正 CP1/CP2/CP3 的范围、统计与实施计划。data/*.md 是运行时逻辑台账路径，实际写入必须先解析 active-root。<项目根>/.devcodex/data/；workspace-namespace 单项目写 <工作区根>/.devcodex/<project>/data/；全工作区写 <工作区根>/.devcodex/workspace/data/。PI/PF/VL/GR/ISSUE 的 reader、validator、runtime index 与 Governance Intake 必须通过共享 resolver 读取 manifest 声明的 active + immutable shards；active 文件始终是唯一普通写入目标。
GovernanceLedgerManifestV1 是 ledger family、文档摘要、reopened overlay 与 nextSequence 的 canonical 真相源；.memory/indexes/governance-ledgers.json 仅为可重建派生索引，不得反向写回台账。
manifest 缺失时只允许 legacy 单文件读取兼容；首次分配新编号或写入前必须先执行零搬迁初始化。新 ID 必须在 manifest 锁内原子递增 nextSequence，禁止扫描 max(existing)+1。
manifest 一旦存在，缺失或摘要漂移的 shard、重复 primary ID、无合法 active overlay 的重复历史记录、序列回退或 migration transaction 残留都必须 fail closed，禁止静默回退 legacy 路径。
archive shard 创建后 immutable；记录重新打开时在 active 文件写当前 overlay，并由 manifest 精确引用其 historical shard。普通 writer 不得追加或改写 archive。
分片迁移必须逐 family、bounded、默认 dry-run；apply/rollback 绑定精确 plan digest、source digest 与 manifest digest。GR 试点只迁移日期与 terminal status 明确且不包含其他 primary ID 的自包含 H2 记录。
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 已同步。
运行态索引必须把 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 只在记录意图识别后执行。
| 输入 | 判定 | 目标 |
|---|---|---|
| AI 明确违反已有规范 | 有规则但未执行 | VL |
| 用户指出 AI 漏做流程、错用规范、误判完成或误写台账 | 已有规则未执行时记 VL；规则缺失/不清时升级 PF/GAP | VL / PF / GAP |
| 规范本身缺失、冲突、滞后 | 规则需要修复 | PF |
| 用户提出更优策略并被采纳 | 过程策略优化 | PI |
| 已确认但不阻断当前任务 | 可排期治理 | ISSUE |
| 检查体系存在盲区 | 检测能力缺口 | GAP |
升级规则：
ReviewEscapeRecordGate：在复审清单中记录 escapedItem、previousChecklistGap、whyMissed、missingDimensionOrProbe、prevention、checklistPatch、rerunEvidence，再判断是否升级 VL/PF/GAP。当修改规范源、Skill、Hook、CLI、MCP、模板、部署副本、website specs、路径规则或 validate 语义时，必须执行 SCV。
控制面或模板-示例-校验链任务在进入 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 边界、推荐结论一致 |
完成规则：
yellowDeviationBoundary 内，且不能把当前消费者伪装成历史镜像。| 交给 AI | 交给规则/工具 |
|---|---|
| 自然语言意图、上下文指代、多意图拆分 | 删除/危险命令/用户与项目敏感信息策略 |
| 判断违规 vs 规范缺口 | active-root、workspace-namespace 路径 |
| 判断建议是否可泛化 | CP 状态、台账编号、模板字段 |
| 判断是否需要澄清 | 测试、lint、validate 实际结果 |
| 判断重复违规是否应升级 | 部署副本 hash、文件存在性、SCV 完成状态 |
禁止：