Compliance

§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 至少输出：

当 PC4 命中新规范吸纳、历史长清单迁移、复审遗漏、用户文档、发布或前端运行态相关 gateGroup 时，后续报告必须引用对应 owner Skill 的证据，而不是只写“已检查规范雷达”。

🔴 合规执行 vs 用户面可见（UserVisibleNoisePolicyV1 · chat 豁免完成块）

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

markdownCopy code
### 拦截与流程诚实摘要（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 |

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。

chat / 纯确认短答：TTFV 可 N/A + skipReason=chat-or-ack。

全自动模式差异

显式 @devcodex-auto、全局默认 @rocky、Profile extensions.devcodex.autoAliases 替换别名或明确自然语言 auto 授权模式下：

在用户已授权的任务范围内，FC/SC 失败时继续修正；遵守 S01~S06 的宿主权限和工作流边界。Auto/白名单不创建正式任务、CP confirmation、fenced owner 或 mutation lease；任何修正都必须先完成对应标准流程与 V5 prewrite。

instruction-fallback 宿主（如 JetBrains / Cursor）仅保留 auto 规则语义，不承诺 runtime 级自动行为；hook-enforced 宿主校验当前语义决定和正式 workflow authority。路径分类仅作 advisory，safety-only 或 strict 均不得据此覆盖已有授权或要求额外确认。

§1 输出验证（每条建议/方案/问题必须附）

附加标注（每条还须标注）：

MeasuredVerificationStandard（SC14 承接 · 全工作流运行时结论）

凡报告或用户面将测试、探针、validate、性能数字、命令输出标为 ✅已验证：

若报告或用户面输出包含多个可执行建议、多个后续路径、方案对比或决策点，必须额外给出 推荐结论 / 推荐方案，且推荐理由可追溯到五项验证；无后续动作时写明 推荐：无后续动作。

UniqueNextStepRecommendationGate（FC7 / SC5 完成态扩展 · PF-172）

凡用户可见 完成态 / 收口 / 台账批次结束 的「下一步 / 后续建议 / 推荐结论」：

ControlPlaneDisciplineProbeBundle（PF-138/139/140 · 2026-07-21 吸纳）

生产入口：npm run test:discipline-execution。Owner：cp-gate + compliance + dev-plan-review + expert-output-quality。

§2 形式合规（FC）— 不通过立即修正后重检

§3 实质合规（SC）— 🔴 阻塞性

§4 恢复性检查（RC）— 非阻塞

豁免：chat 豁免全部合规检查；analyze 豁免 RC 层（只读工作流，多轮收敛但每轮不写恢复性记忆）。

§5 报告二次验证（报告写入后执行）

🔴 阻塞性验证

V5 反向质疑三问

逐条对 🔴 级问题执行：

1. 不修复会导致什么具体的功能异常？→ 答不出 → 降级
2. 是否可能是有意的设计选择？→ 有可能 → 验证意图后再定级
3. 不修复的风险是否可接受？→ 可接受 → 降级为 🟡 或 💡

🟡 改进性验证

§6 任务完成验证

正式任务的完成输入与关闭

task verify 返回 workflow-input-missing 表示作者证据输入尚未产出，应继续收尾；这不是独立的授权，也不默认交回用户。按 compliance/workflow-completion.schema.json 与 hooks/_runtime/lifecycle-workflow-completion.cjs 的 WorkflowCompletionInputV1 形成当前 candidate、plan、sourceRefs 和 rollout。可用 Owner 构造函数生成并校验对象；由当前 fenced owner 写入任务局部 .memory/workflow-completion-input.json，不得手改 V5 owner、机器回执、epoch 或终态。

每个 sourceRef 只绑定实际新鲜证据，作者自审与独立复核、执行与未验证必须分开；输入文件存在不等于通过。完成报告、记忆、产物清单及实际 ECR 后，公开执行 devcodex task verify --task <taskId> --project <namespace> --json，由 Owner 计算完成投影。适用项全部通过后，再按公开 memory_task_terminal_v1 的四证据与当前 CAS 关闭、读回撤权解绑，并自然 Stop。仅真实上游证据/权限仍缺失时保留 UNVERIFIED 与精确恢复点；不得因为作者输入尚未创建就停止，也不得为通过而构造不存在的测试、独立或终态事实。

机器消费者必须使用 canonical ID；T1~T13 只用于现有文档、人工清单与兼容投影，不得作为新状态键。

§7 自修复触发