发布前最难处理的情况，往往不是找到某个孤立错误，而是几位开发人员分别修复了权限、资源、签名和产物问题，却无法回答交付包究竟引用哪次配置、哪些问题已经关闭、还缺少什么核对。一个只显示红绿图标的看板无法支撑后续复盘。ReleaseGuard此前把配置模型、构建产物、隐私用途、多语言资源、签名引用和问题闭环拆成六种检查对象，现在需要把这些对象串成一份可以追溯到版本快照的审计索引。

工程基线仍为com.example.releaseguard、产品default、1.2.3 / 1000203，候选为1.2.4 / 1000204。上一章定义了schema=2到schema=3的迁移规则及受控快照；当前候选文件两项，摘要完成0/2，五个门禁中配置检查为CONFIG_PASS，其他为MANIFEST_PENDING、PRIVACY_REVIEW、RESOURCE_REVIEW、SIGNING_REVIEW。问题台账保存四项开放、一项关闭。最终交付决策必须继续保持HOLD，不能用“迁移规则可用”替换发布检查结论。

一、每个结论都应回到对应的版本快照

审计索引的主键不能只用自然语言标题。相同的“资源缺失”可能在多个候选版本出现，若按标题归并，容易把新问题误认成已关闭的旧问题。可使用bundleName + product + candidateCode + checkType + issueKey组合为稳定索引，再把产生检查结果的输入摘要、规则版本和完成时间保存到记录。一次检查的“通过”只对对应的输入有效；如果打包配置或资源文件后来修改，就应重新关联新版本的检查结果。

华为开发者联盟Hvigor实践说明介绍了通过构建插件上下文处理app.json5及相关配置的方式，构建模式说明区分了产品、构建模式与对应选项。ReleaseGuard把bundleName、versionCode、versionName、product和构建模式分开登记，这样才能识别相同版本号下不同配置组合带来的产物差异。工作台只保存必要的配置快照和引用索引，签名材料的口令与私钥始终留在受控区域。

审计清单中的evidenceRef应指向受控的检查结果或文件摘要，不宜直接存放临时目录的绝对路径。路径可能随开发环境移动而改变，业务索引却应能稳定引用到对应的产物和规则。保存时先核对引用的版本，再标记证据是否齐全；某项证据缺失时使用明确的PENDING，不能以空字符串代替“已通过”。

const release = {
  bundleName: 'com.example.releaseguard', product: 'default',
  baseline: { name: '1.2.3', code: 1000203 },
  candidate: { name: '1.2.4', code: 1000204 },
  dataSchema: 3, sourceSchema: 2, artifacts: 2, digested: 0
};
function issueKey(kind, detail, snapshot) {
  return [snapshot.bundleName, snapshot.product,
    snapshot.candidate.code, kind, detail].join('|');
}
const id = issueKey('resource', 'release_version', release);
console.log(id, release.dataSchema);

二、将问题台账与五道门禁拆开计算

上一章迁移后，问题主键保持四项开放和一项关闭。开放项分别为产物摘要manifest:digest、隐私用途privacy:purpose、多语言占位符resource:release_version以及签名关联signing:relation。已关闭的resource:privacy_retention_notice继续留在历史记录中，它的关闭不意味着其他资源问题同步关闭。每个问题应有负责人、目标版本、最近状态和证据引用；但负责人不是唯一权限验证手段，状态改变仍需要规则检查或有依据的人工核对。

五道门禁与问题数量也不是一回事。配置门禁已经通过，产物门禁因两项文件摘要尚未完成而等待；隐私、资源、签名分别保留各自的复核状态。一个问题可能关联多个门禁，而一个门禁也可能受多项问题影响，故不能直接以“开放问题数等于未通过门禁数”代替实际计算。工作台应在聚合前先检查每个门禁读取到的版本快照是否一致，任何来源版本缺失都需使总决策停留在HOLD。

const gates = {
  config: 'CONFIG_PASS', manifest: 'MANIFEST_PENDING',
  privacy: 'PRIVACY_REVIEW', resource: 'RESOURCE_REVIEW',
  signing: 'SIGNING_REVIEW'
};
const expected = { config:'CONFIG_PASS', manifest:'MANIFEST_PASS',
  privacy:'PRIVACY_PASS', resource:'RESOURCE_PASS',
  signing:'SIGNING_PASS' };
function auditGate(items, requirements) {
  const blocked = Object.keys(requirements)
    .filter(key => items[key] !== requirements[key]);
  return { state: blocked.length ? 'HOLD' : 'READY',
    passed: Object.keys(requirements).length - blocked.length,
    blocked };
}
console.log(auditGate(gates, expected));

此处聚合函数直接接收上游结果，保留blocked数组以解释当前决策。实际工程中需要再加入产物摘要范围、检查规则版本与输入时间等标识，但不能为了生成漂亮的列表把待复核项自动转为通过。对于暂时与产品无关的检查项，要在规则配置中显式标记不适用条件，并保留选择原因，而不是把该项从报表中直接删除。

三、审计快照要同时保护数据迁移链

从schema=2迁移到schema=3只改变质量台账的组织形式，不修改已登记的发布门禁事实。来源快照、转换规则和目标快照应通过摘要关联，便于后续排查究竟在哪个环节引入了字段差异。快照中的开放问题主键顺序可以保持确定性排序，避免仅因数组顺序变化导致摘要不同；对于含时间戳的记录，则应明确哪些字段参与摘要，哪些字段仅用于展示。敏感内容不应写入供外部流转的审计摘要明细。

当迁移失败、候选文件发生变化或有人撤销了已关闭问题的处理结论，原有快照仍应可读取。回滚业务配置与重新提交安装包是不同操作，审计记录需要独立描述其影响。以当前ReleaseGuard为例，稳定发布基线仍保留为1.2.3 / 1000203，1.2.4 / 1000204只是待评估候选。即使结构迁移保持幂等，仍然有四项开放问题，不能因为schema=3格式完整就改变总门禁。

四、为阻塞原因生成可交接的处理清单

一份可使用的交付报告不仅告诉团队“还有四项”，还需要说明每项如何关闭。产物摘要问题应当核对两项候选文件的实际路径、摘要对象和对应候选版本，完成后才能由MANIFEST_PENDING推进下一状态。隐私用途问题需要让权限声明、功能触发位置和页面披露内容互相对应；资源占位符问题要让各语言文件对同一个资源键采用兼容的参数结构；签名关联则要确认.p12、.cer、.p7b的应用标识及引用关系。

这些问题的处理顺序不由颜色决定，而由证据依赖决定。若产物重新构建，先前针对旧包的摘要应重新取得；若签名引用更新，应复查与构建配置的对应关系；若资源文件修改，旧资源核对记录需标注适用版本。发布质量门禁要求的是同一候选快照上的一致结果，不能从不同版本各挑一条绿色记录凑成一份“全通过”的报告。

const open = [
  'manifest:digest', 'privacy:purpose',
  'resource:release_version', 'signing:relation'
];
const closed = ['resource:privacy_retention_notice'];
function retrospective(items, done, gateStatus) {
  const duplicates = items.filter((id, i) => items.indexOf(id) !== i);
  const overlap = items.filter(id => done.includes(id));
  return {open: items.length, closed: done.length,
    duplicates, overlap, decision: gateStatus,
    followUps: items.map(id => ({id, status:'OPEN'}))};
}
console.log(retrospective(open, closed, 'HOLD'));

五、复盘应记录防再发措施，而不只是责任人

对于前期频繁出现的占位符差异，可以在合并资源前检查同名资源中的占位符集合；对于签名材料关联，可建立不含密钥内容的配置引用表；对于产物摘要缺失，应明确生成产物清单与计算摘要属于同一交付阶段，并在任何输入修改后重新计算。这些措施的价值在于提前暴露不一致，而不是把发现问题的环节再往后推。

复盘记录可以包括问题的首次发现阶段、触发条件、修复原则、阻断位置和后续观察指标。指标口径要清晰：例如“每个候选发布快照中的缺失证据数”“已关闭问题再次打开的比例”，而不是把未定义的数字写成团队真实交付效率。问题还可能来自规则自身缺陷，因此需要为检查规则建立版本记录，允许团队比较规则调整前后的差异，并追踪是否产生新的误判。

六、让外层索引与正文工程数据相互指向

交付素材应将配置快照、门禁汇总、开放问题、关闭记录和输入摘要放在可查询的索引中。项目说明文档可以展示当前策略和处理顺序，但具体结论要由对应版本的数据记录支撑。HAP与APP的候选清单、权限用途、资源多语言、签名引用都通过稳定的业务标识汇入审计索引；任何检查项缺少证据，都记录为待处理，而不是悄悄漏出列表。

ReleaseGuard无需在界面上输出所有原始字段。顶部展示基线1.2.3、候选1.2.4、迁移schema 2 → 3以及HOLD；中间展示一项通过、四项仍待处理的门禁；下方为四项开放问题与一项已关闭问题。敏感签名文件只显示材料类型与引用状态，业务日志避免记录用户资料、密钥及文件绝对路径。界面刷新后若读取到的候选代码发生变化，应让旧检查记录显示为历史快照，避免误把旧证据挂到新候选上。

七、以真实阻塞事项结束发布治理主线

这套连载从版本配置、构建产物、隐私权限、多语言资源、签名引用到问题闭环，再延伸到数据迁移与审计索引，形成了明确的工程质量入口。当前的结论没有歧义：配置检查通过，四项仍需补充或复核；两个候选文件的摘要完成数为零，四项问题保持开放，已关闭的一项继续保留记录，候选1.2.4 / 1000204的发布决策仍为HOLD。稳定基线继续可用，审计收口完成的是问题和证据的组织，不是候选发布许可。

以后每当团队推进下一候选，都可以复用这套快照标识、门禁聚合及问题追踪模型，重新取得该版本自己的检查结果。让每一个“通过”都能指向输入、规则和复核记录，让每一个“待处理”都有准确的关闭条件，比在发布临近时临时拼接检查表更可靠。