技能介绍

为什么需要它

当发布进入 go/no-go 节点，证据往往散落在计划、声明、投放、执行日志和事后数据里。若把不同阶段混在一起，得到的是一个看似精细、实则不可解释的分数。发布就绪审计只处理一次发布、一次生命周期读数：preflight 评估就绪度与资产，外加政策与埋点红线；execution 只评估观察到的窗口执行；outcome 在声明滞后期后评估实际结果与复盘。不做跨时间合成，不平均三段分数。

如何工作

声明 profile（preflight|execution|outcome）、目标发布、类型、市场、访问模型、观察日期与证据窗口。
按读数取证据：阶段/访问、叙事/声明、运营/规则、埋点、执行、结果各自对应 launch-registry 记录、官方平台规则、已验证事件/UTM、带时间戳的操作与事故证据、自有分析/CRM/商店数据。
按档案计分：preflight 评 R1–R10、A1–A10、计划项 M1 与 P1；execution 只评观察到的 M1–M10；outcome 在滞后期后评 P2–P10，不得用预测目标回填实际值。
核验红线否决项：RAMP-R1 阶段/访问矛盾、RAMP-A1 重大声明/披露失败、RAMP-M1 操纵/ embargo/平台违规、RAMP-P1 参与面埋点明显损坏。
运行 rubric-score.py score 得到状态与结论；缺失证据记为 Unknown，目录授权的条件项可记 N/A 并给原因。

边界与注意

只读冻结证据：不执行发布、不提交商店、不改注册表、不动投放；preflight=SHIP 也不等于可对外动作，仍需执行前明确批准。
计分器、校验器与类型化目录不可用时，返回 score_state: NOT_SCORED / score_confidence: not_scored，不出门槛结论、不落盘。
隐私受限的建模测量可标 Partial；必填埋点损坏才是 P1 Fail；发布堆叠/容量是 M10 发现而非自动否决。
持久化只在显式授权后写入 memory/audits/launch/YYYY-MM-DD-.md，用 validate-audit-artifact.py 全量校验，且不同生命周期读数分文件、按发布 ID 关联。