技能介绍

审计协调里真正缺的是什么

多份 PBC、Owner 口头更新、门户上传回执和 reviewer 邮件混在一起时，团队往往搞不清：哪条请求对应哪个包版本、v1 被退回后 v2 是否已提交、以及「已上传」和「已接受」是不是一回事。本技能只做一件事：在你给定材料上产出静态协调快照，把请求项、包版本和可定位事件串起来，并标出期间/回执/reviewer 结论等缺口。

技能如何组织信息

核心是一套五层身份与事件原子事实：

请求 / 请求项 / 包ID / 包版本 / 事件ID 分开登记；新版提交不覆盖旧版历史。
主状态从事件链派生（如 已提交待接收、已退回待补交），每项只保留一个主状态；截止已过、扩展待批、期间不匹配 等作为可重叠标签另计。
覆盖核对只比较请求字段与包元数据（期间、格式、样本范围等），输出匹配/不匹配/未知，不判断证据是否充分、控制是否有效。
工作流上依次：锁定统计时点与时区 → 建立身份与事件账 → 派生主状态 → 核对覆盖与时间 → 最小化敏感信息后形成复核包。

典型用法示例：「把 PBC 清单、上传回执和审计方反馈整理成摘要，分开提交、接收、接受和退回。」

边界与常见误区

本技能不生成、修改、脱敏或上传证据，不操作审计门户，不催办、分派或写回状态，也不把 reviewer 接受等同于控制有效或项目关闭。Owner 说「已发」只能记角色陈述，须有可定位发送/上传事件才能标 已提交；门户 uploaded 不等于 已接受。与 security-questionnaire-draft（逐题答题）、approval-queue-digest（审批 SLA）、access-review-checklist（权限复核草案）不同，本技能固定跟踪证据请求—包—版本—reviewer 生命周期。