| name | compliance |
| description | 执行入口检查与 FC/SC/RC/T 合规校验。PC0~PC10 入口检查所有模式启用；仅 dev 模式执行全量合规校验，prod 模式不执行（规范已验证）。chat 豁免合规块。 |
§0 模式判断（前置，优先执行）
读取由 load-profile Skill 注入的 ENV_MODE（参见 01-common §ENV_MODE 行为总表）：
⛔ S01~S06 安全底线不受 ENV_MODE 影响，无论 dev/prod 均强制执行；S07 在 instruction-fallback 模式下要求全模式入口检查（致命自修正）。
⚠️ 入口检查（PC0~PC10）所有模式启用，收到用户消息后立即执行；dev 模式额外执行 PC4 完整规范雷达，非 dev 模式 PC4 标注 N/A，详见 17-compliance.instructions.md §入口检查。
🔴 S07 时序：用户首次可见 PC0~PC10 先于实质正文与产物 mutation（报告/记忆/台账）；禁止最终文首补 PC 冒充已先输出。Hook 可报告 s07OrderStatus（ok/late/missing/unverified）。
🔴 PC0 单源语义（ABS-07）：用户可见 PC0 必须写 ContextReadPlan + 必要来源回执；instructions.md、17-compliance、precheck-status.prompt 同源。禁止「Profile ✅ 已加载」单字段冒充上下文完整；PC7 使用 memory_status + 有界 query 回执一致表述。
ℹ️ ENV_MODE 未注入（profile 未加载）时，默认按 prod（不执行合规检查）。
§0.1 SpecRadarSubgate（PC4 规范雷达承接）
SpecRadarSubgate 是 PC4 的执行承接层：instructions/18-spec-radar.instructions.md 只负责入口提示和用户可见摘要，具体 Gate 分组、触发判断、ownerSkill、验证路线和 N/A 理由必须引用 spec-governance 的 GovernanceGateRegistry。
dev 模式 PC4 至少输出：
| 字段 | 要求 |
|---|
mode | dev / prod / unknown；非 dev 时 PC4 可写 N/A + skipReason |
triggeredGateGroups | 命中的 gateGroup 列表，例如 absorption-layering、review-checklist、frontend-runtime、release-parity |
ownerSkills | 每个 gateGroup 的 owner Skill；不得把执行细节继续堆回 PC4 文案 |
requiredArtifacts | 本轮需要的清单、报告、证据、探针或部署同步 |
validationRoute | targeted test、validate 编号、SCV、人工证据或 N/A + skipReason |
当 PC4 命中新规范吸纳、历史长清单迁移、复审遗漏、用户文档、发布或前端运行态相关 gateGroup 时，后续报告必须引用对应 owner Skill 的证据，而不是只写“已检查规范雷达”。
🔴 合规执行 vs 用户面可见（UserVisibleNoisePolicyV1 · chat 豁免完成块）
| 层 | 要求 |
|---|
| 执行 | dev 模式仍须在内部完成 FC/SC/RC/T；证据写入报告/记忆 |
| 用户面默认 | 未宣称完成 → 不贴完成检查/FVS/产物全表（只保留入口检查 + 正文） |
| 宣称完成且全绿 | 贴 短 FVS（见 shared validation-summary）；不默认 FC 全表 |
| 失败/缺口/用户要详情 | 展开失败项 + 全量 FVS / 相关产物 |
⛔ 宣称完成却只有“全绿/详见报告” → DevModeCompletionCheckDetailGate 未通过。
⛔ 未宣称完成时 不得 为过 Stop 而硬贴长完成检查（Stop 以 workDoneClaimed 为准）。
ℹ️ 六宿主同源：user-visible-output-contract · UserVisibleReplyLayoutV1 + UserVisibleNoisePolicyV1。
⚠️ FC5 填写规则：触发 user-visible-output-contract。ArtifactDeliveryManifestV1 必须 planned=observed=internalDelivered，UserFacingArtifactSetV1 必须 required hidden=0 且 listed+remaining=total；session/daily/SUMMARY/task/checkpoint/raw ledger 默认 internal-only 但仍参与 ECR。持久化投影使用 LinkCapabilityDecisionV1，用户面使用 HostLinkCapabilityDecisionV2 + ArtifactDeliveryAttemptV1；只有 action 与 readback 均成功才可写 opened，其他情况使用 ready 或 absolute fallback。Hook 未观察 payload 时只能 unverified，legacy 格式最多 unverified-legacy。
⚠️ HostPermissionAuthorityInvariant：PreToolUse/PermissionRequest 的文件、命令、删除和工具操作权限仅由宿主决定。DevCodex 可以记录 advisory/workflow-invalid，但输出及宿主 adapter 不得含 allow/deny/ask/block/continue:false 操作权限载荷；负向测试必须覆盖六宿主遗留载荷剥离。
ℹ️ prod 模式不执行合规检查，不输出状态块。
ℹ️ chat 工作流豁免此输出。
EnforcementHonesty（全宿主完成态 · R5 / R11）
完成态 / 被 Stop 续跑后的收尾，用户可见回复或正式报告须披露拦截与流程诚实摘要（诚实=披露缺口，不是关能力）。Hook 状态字段：state.enforcementHonesty（EnforcementHonestyV1）。
### 拦截与流程诚实摘要（EnforcementHonesty）
| 项 | 值 |
|----|-----|
| host | grok / codex / claude / … |
| hard 事件启用 | PreToolUse, Stop（宿主能力矩阵） |
| 本轮 PreTool deny | 0 / N（摘要） |
| 本轮 Stop | block→续跑 / allow / unverified（无正文） |
| 未能硬拦 | 如：纯文本无 tool；safety-only 下 CP 写控制面 |
| 流程缺口 | 如：entry-check / pr1-skipped / cp2-unconfirmed-write / final-validation-summary |
| evidenceMode | path-observable+stop-conditional / host-native |
| processGaps 枚举（R11 规范名） | 含义 |
|---|
entry-check-missing | 缺 PC0~PC10 / 入口检查块 |
completion-check-missing | 缺 ### DevCodex · 完成检查（或 envelope completion-check） |
final-validation-summary | 宣称完成但 FVS 短矩阵不完整 / thin-green |
report-missing / memory-missing | mutation 后未写报告/记忆（可用 SimpleTask / N/A+skipReason 豁免） |
pr1-skipped | 请求确认 CP2 但无 强 PR-1 通过证据（zero-blocker / PR-1 ✅） |
cp2-unconfirmed-write | safety-only 下控制面/源码写在 CP2 未确认时被放行（strict 为 deny） |
stop-continuation-exhausted | 达 softCap 后 fail-open |
Grok：条件 Stop 硬续（有 lastAssistantMessage 可 decision:block；无正文 unverified；平台/softCap 后 fail-open）。控制面写路径建议 DEVCODEX_HOOK_ENFORCEMENT=strict，否则 Honesty 必须披露「未硬拦」。
GovernanceIntakeClosureGate（全模式语义项）
本项不受 dev/prod 后置合规块开关影响：每条非空用户消息都必须有中性 candidate，并在合理性评估后形成 GovernanceIntakeDecision。收尾前检查 candidate ID、评估结论、泛化范围、现有规范状态、复合意图、目标台账、写入要求与证据；required 写入必须满足 LedgerWriteEvidenceGate，record.none 必须满足 RecordNoneChallengeGate，record.ambiguous 保持未终结。Hook 证据不可观察时只能标 unverified，不能把回复中的自报编号当作落账成功；instruction-fallback 必须在报告/记忆保留相同字段与人工复证路线。
TimeToFirstValueGate + WorkspaceRootScanHygiene（C16 / PI-20260724-01 · 全模式防复发）
🔴 与 ENV_MODE 无关：非 chat 任务不得用「准备过重」制造假卡住。Owner 细节见 skill-gap-analysis；机器探针见 classifyTtfvOmissionSample / classifyWorkspaceRootScanSample（host-parity-scorecard.js）与 ProgressReportFastPath classifyProgressReportFastPathSample。
| 门禁 | 通过条件 | 失败处置 |
|---|
| TTFV | PC0~PC10 + 最小 ContextReadPlan 之后，同一用户可见回复含：范围卡 或 首批 finding/结论 或 明确阻断+恢复 | 本轮不得宣称「已启动审查/分析完成准备」；下一 tool 轮必须先交付 |
| ProgressReportFastPath | 进度/发版状态查询：绑定项目 → 固定真相源顺序 → 首轮进度卡；禁止根 inventory 抢跑 | 同 TTFV 违约；progress-fail |
| WorkspaceRootScanAdvisory | 未绑定唯一项目前不递归 workspace 根；项目可知时用直达路径；inventory 排除 node_modules/dist | 改用有界命令；Hook 只提示成本与范围，是否执行由宿主权限策略决定 |
| Skill 最小充分 | 只加载当前意图强制 bundle + 本批所需 Skill，禁止首轮通读全部 audit 子 Skill 百科 | 记 WARN；不作为「已审查」证据 |
chat / 纯确认短答：TTFV 可 N/A + skipReason=chat-or-ack。
全自动模式差异
显式 @devcodex-auto、全局默认 @rocky、Profile extensions.devcodex.autoAliases 替换别名或明确自然语言 auto 授权模式下：
仅在 hook-enforced 宿主 + 白名单路径下，FC/SC 失败时自动修正（不暂停等待用户），但 S01~S06 仍阻断。Auto/白名单不创建正式任务、CP confirmation、fenced owner 或 mutation lease；任何修正都必须先完成对应标准流程与 V5 prewrite。
instruction-fallback 宿主（如 JetBrains / Cursor）仅保留 auto 规则语义，不承诺 runtime 级自动行为；支持 Hook 的宿主默认采用 safety-only，非白名单路径在正式 workflow authority 已满足后输出提醒并放行，strict 模式下才按白名单执行 runtime 硬拦截，因此其“自动”更多体现为路径受限的 hook 提醒/门禁策略。
§1 输出验证（每条建议/方案/问题必须附）
| 验证项 | 说明 |
|---|
| 合理性 | 为什么要这样做？依据是什么？ |
| 可实施性 | 能否落地执行？是否有前置条件？ |
| 收益 | 执行后带来什么改善？ |
附加标注（每条还须标注）：
| 属性 | 说明 |
|---|
| 验证状态 | ✅已验证（实际读取了源文件确认；运行时/探针/测试结论还须满足下方 MeasuredVerificationStandard）或 ⚠️待验证（基于推测/上下文推断/非权威实验） |
| 影响范围 | 涉及哪些文件/模块（一句话描述） |
MeasuredVerificationStandard（SC14 承接 · 全工作流运行时结论）
凡报告或用户面将测试、探针、validate、性能数字、命令输出标为 ✅已验证：
| 规则 | 要求 |
|---|
| 权威入口 | 必须执行生产入口命令，例如 node scripts/test-spec-governance.js、npm run test:core / node scripts/validate.js、需要 full 时用 npm test；并记录命令与 exitCode |
| 非权威实验 | 自写隔离 harness、裸 fs.read + includes、未复用 validate.js 同款 createCanonicalAwareReader/ROOT/上下文 的脚本 → 只能标 非权威实验 或 ⚠️待验证(生产路径)，不得写成 V# 失败/通过或「今日验收不通过/通过」 |
| 等价条件 | 隔离脚本若宣称与某 V# / suite 等价，必须复用生产 read 路径与上下文，并在报告写 parity 证据 |
| 历史数字 | SUMMARY / 记忆 / 旧报告中的数字不得直接冒充本轮 ✅已验证 |
若报告或用户面输出包含多个可执行建议、多个后续路径、方案对比或决策点，必须额外给出 推荐结论 / 推荐方案，且推荐理由可追溯到五项验证；无后续动作时写明 推荐：无后续动作。
UniqueNextStepRecommendationGate（FC7 / SC5 完成态扩展 · PF-172）
凡用户可见 完成态 / 收口 / 台账批次结束 的「下一步 / 后续建议 / 推荐结论」：
| 规则 | 要求 |
|---|
| 唯一主动作 | 有且仅有 1 条可执行主动作（一句可验收）；禁止把 ≥2 条可执行路径写成同级推荐 |
| 禁止「或」并列 | 禁止用「或 / 或者」在推荐主面上连接两条可执行路径（如「对齐 VL 表或挑 PF 链路」）；机器分类见 classifyNextStepOrForkSample → or-fork 即失败 |
| 备选降级 | 非推荐路径只能放在「不推荐 / 明确劣于推荐」小节，并写清为何不选；不得与推荐同级 |
| 无动作 | 无后续时写 推荐：无后续动作，不得硬凑二选一 |
| 与 CP 前门禁关系 | CP 确认前的 A/B/C 仍由 UniqueRecommendationBeforeConfirmGate / NoPreferenceMenuAfterConvergenceGate 覆盖；本门禁补 free-text 完成态 缺口（VL-077 / PI-151） |
ControlPlaneDisciplineProbeBundle（PF-138/139/140 · 2026-07-21 吸纳）
| 分类器 | 失败码 | 覆盖 |
|---|
classifyPreferenceMenuAfterConvergenceSample | preference-menu | 收敛后希望哪种 / A/B/C |
classifyCpArtifactBeforeConfirmSample | missing-cp-artifact | 确认 CP 无产物路径 |
classifyCodeTruthMatrixAtCpSample | missing-code-truth-matrix | 控制面定稿无 CodeTruth 矩阵 |
classifyControlPlaneDigestSample | missing-digest | 控制面确认无 sha/digest |
classifyAuthorSelfReviewBoundarySample | author-self-review-as-independent | 作者自审冒充独立审查 |
classifyNextStepOrForkSample | or-fork | 完成态「或」双主动作 |
生产入口：npm run test:discipline-execution。Owner：cp-gate + compliance + dev-plan-review + expert-output-quality。
§2 形式合规（FC）— 不通过立即修正后重检
| # | 检查项 |
|---|
| FC1 | 记忆文件完整（必填字段齐全，状态 🔄/✅；📨 对话记录必须为四列表格格式：轮次 | 👤 用户消息 | 🤖 AI执行 | 状态，三列或项目符号格式不通过） |
| FC2 | 报告文件已写入（chat 豁免） |
| FC3 | CP 按序执行（dev/fix；其他 N/A） |
| FC4 | 文件名/路径合规（NN-- 双横杠开头） |
| FC5 | ArtifactDeliveryManifestV1 完整对账；UserFacingArtifactSetV1 required hidden=0、计数守恒；semantic name/action/order、LinkCapabilityDecisionV1 持久化投影、HostLinkCapabilityDecisionV2 renderer 与逐目标 ArtifactDeliveryAttemptV1 action/readback/fallback 有效 |
| FC6 | 新增 DevCodex 规范资产 .md 行数检查（instructions / skills / prompts / templates / 规范源等超 500 行须按 C13 拆分；业务项目需求、技术方案、报告和正式项目文档不因 C13 强制拆分） |
| FC7 | 用户决策选项与报告决策点必带推荐 + 理由：所有 AskUserQuestion / 多选项呈现 / CP 选项 / 方案对比 / analyze-audit 报告决策点必须有且仅有 1 个推荐项，推荐项置首且说明推荐理由；完成态「下一步/后续建议」适用 UniqueNextStepRecommendationGate（禁止「或」并列双主动作）；无后续动作时写明 推荐：无后续动作 |
§3 实质合规（SC）— 🔴 阻塞性
| # | 检查项 | 适用范围 |
|---|
| SC1 | 报告验证列完整（合理性 + 可实施性 + 收益 + 验证状态 + 影响范围五项） | 全工作流 |
| SC2 | 代码已诊断（无未处理 error） | dev/fix 🔴；其他 N/A |
| SC3 | 修复已全局扫描（三步扫描：同类全局+数据联动+grep零残留） | fix 🔴；dev(重构) 🔴 |
| SC4 | 关联文件已同步 | dev/fix/self-fix 🔴 |
| SC5 | 后续建议与推荐结论已输出（报告含 ## 后续建议 / ## 推荐结论 / ## 推荐方案 或等效内容；有且仅有 1 条主动作；禁止完成态用「或/或者」并列 ≥2 条可执行路径；备选须标「不推荐」+ 理由；无待跟进时显式标注“推荐：无后续动作”即通过；探针 classifyNextStepOrForkSample） | 全工作流 |
| SC6 | Agent SUMMARY 已更新（.memory/clients/<agent>/SUMMARY.md） | 全工作流 🔴 |
| SC7 | 全局 SUMMARY 关键决策已追加（仅规范变更/架构决策/P0修复） | 有关键决策时 🔴 |
| SC8 | 上次待跟进已查阅（首次会话 N/A） | 全工作流 🔴 |
| SC9 | C08 Token 防护状态（>10轮关注 / >13轮预警 / >15轮防护） | 全工作流 |
| SC10 | C07 并发策略合规：只读/隔离验证并发需符合 ConcurrencyPolicy，写共享状态、同一 audit session 或 package boundary 竞争写视为阻断 | 涉及 Agent 调用或并发任务 🔴 |
| SC11 | C14 多任务拆分检查（≥5任务需建议拆分会话） | 任务≥5时 🔴 |
| SC12 | C14 多任务进度快照验证（每完成子任务有 T{N}进度 标记） | 任务≥2时 🔴 |
| SC13 | C15 架构质量自检（dev plan-review 三维评估；fix CP2 三维评估） | dev/fix 🔴 |
| SC14 | analyze/audit（及任何宣称探针/测试结果的工作流）中，所有标注 ✅已验证 的运行时结论须满足 MeasuredVerificationStandard：本轮执行并记录 exitCode；隔离 harness / 非生产 reader 不得写成 V# 成败；SUMMARY/记忆历史数字必须降级为 ⚠️待验证 |
§4 恢复性检查（RC）— 非阻塞
豁免：chat 豁免全部合规检查；analyze 豁免 RC 层（只读工作流，多轮收敛但每轮不写恢复性记忆）。
| # | 检查项 |
|---|
| RC1 | 记忆文件是否足以让下一个 Agent 恢复上下文；跨会话/多批次/summary/compact/handoff 场景是否已有 ContextHandoffCard |
| RC2 | 已产出文件是否自洽完整 |
| RC3 | 🔄 标记任务是否提供了足够恢复线索 |
| RC4 | 关联需求的 .memory/sessions.md 是否已创建 |
§5 报告二次验证（报告写入后执行）
🔴 阻塞性验证
| # | 检查项 |
|---|
| V1 | 每条问题有文件来源（文件名+行号/章节） |
| V2 | 验证列+标注完整（回读报告文件确认） |
| V3 | ✅已验证 的问题确实读取了对应文件 |
| V4 | 纯推测性问题已标注 ⚠️待验证 |
| V5 | 每条 🔴 级问题通过反向质疑三问（不修复的具体后果/是否有意设计/风险可否接受） |
V5 反向质疑三问
逐条对 🔴 级问题执行：
- 不修复会导致什么具体的功能异常？→ 答不出 → 降级
- 是否可能是有意的设计选择？→ 有可能 → 验证意图后再定级
- 不修复的风险是否可接受？→ 可接受 → 降级为 🟡 或 💡
🟡 改进性验证
| # | 检查项 |
|---|
| V6 | 🔴 级占总问题数超 1/3 时，触发"分级标准是否过严"自检 |
§6 任务完成验证
| alias | canonical ID | 检查项 |
|---|
| T1 | requirements.coverage | ✅ 需求覆盖（用户所有需求点已处理） |
| T2 | delivery.report | ✅ 报告存在（chat 豁免） |
| T3 | delivery.memory | ✅ 记忆完整（任务摘要+对话记录+关联报告） |
| T4 | confirmation.cp | ✅ CP 完整（dev/fix；其他 N/A） |
| T5 | governance.compliance | ✅ 合规通过（FC+SC 全通过） |
| T6 | constraints.and-sync | ✅ 约束遵守（C01~C22 + 关联文件已同步 + GovernanceIntakeClosureGate 已终结或明确 unverified/ambiguous） |
| T7 | workflow.verification | ✅ 工作流验证（dev/fix: 扫描/验证 + ECR 已执行；audit/analyze: PCV 与推荐结论已执行） |
| T8 | continuity.summary | ✅ SUMMARY 已更新；若触发上下文交接，daily tasks 或报告已写 ContextHandoffCard；若主动建议新会话，同回复已交付 NewSessionContinuationCard |
| T9 | delivery.manifest | ✅ internal manifest 与用户可见交付均完成；默认隐藏内部记录仍已写入、验证并纳入 ECR |
| T10 | long-task.timing-and-coverage | ✅ 条件：长任务是否记录 SessionTimingCard（或 N/A+skipReason）；确认类清单是否含 CoverageMatrix 或 residual 声明（ABS-17/18） |
| T11 | long-task.budget-and-authorization | ✅ 条件：长任务/Auto/多批次是否具备 ExecutionBudget + LongTaskAuthorization（或 N/A+skipReason）；有等待面时是否分列 external wait（PI-118/PF-137） |
| T12 | deployment.and-completion-evidence | ✅ 条件：触及部署消费者时是否输出 WorkspaceSyncStatus；dev/fix/self-fix 宣称完成时是否通过 CompletionEvidenceGate（ECR + 同步/验证/dirty 证据） |
| T13 | post-delivery.self-check | ✅ 条件：长任务收口 / 宣称完成 / 用户质疑慢漏时是否执行 PostDeliverySelfCheck（或 N/A+skipReason）；不得用自评刷 PI |
机器消费者必须使用 canonical ID；T1~T13 只用于现有文档、人工清单与兼容投影，不得作为新状态键。
§7 自修复触发
| 触发条件 | 处理方式 |
|---|
| FC/SC 检查不通过 | 立即修正后重检（FC+SC 累计修正 ≥5 次仍未全通过 → 停止循环，输出剩余失败项摘要标 ⚠️，写入记忆后交由用户决策） |
| 连续 2 次同类偏差 | 升级分析（追加记忆 ⚠️连续违规 + 报告增加「规范偏差分析」章节）；不自动进入 self-fix（防递归） |
文件路径不符合 02-output-paths.instructions.md | 立即停止创建，迁移到正确路径 |
| 规范文件修改后引用未同步 | 交叉验证后修正 |
