/compliance

name: compliance
description: 执行入口检查与 FC/SC/RC/T 合规校验。PC0~PC10 入口检查所有模式启用；仅 dev 模式执行全量合规校验，prod 模式不执行（规范已验证）。chat 豁免合规块。

§0 模式判断（前置，优先执行）

读取由 [`load-profile`](../load-profile/SKILL.md) Skill 注入的 ENV_MODE（参见 [`01-common`](../../instructions/01-common.instructions.md) §ENV_MODE 行为总表）：

<!-- devcodex:include shared/compliance/env-mode-table.md -->

> ⛔ **[S01~S06](../../instructions/00-safety.instructions.md) 安全底线不受 ENV_MODE 影响**，无论 dev/prod 均强制执行；**[S07](../../instructions/00-safety.instructions.md)** 在 instruction-fallback 模式下要求全模式入口检查（致命自修正）。 > > ⚠️ **入口检查（PC0~PC10）所有模式启用**，收到用户消息后立即执行；dev 模式额外执行 PC4 完整规范雷达，非 dev 模式 PC4 标注 N/A，详见 [`17-compliance.instructions.md`](../../instructions/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 / 相关产物 |

<!-- devcodex:include shared/compliance/validation-summary.md -->

> ⛔ 宣称完成却只有“全绿/详见报告” → `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.