# B站认证扩展标准托管加载 V005：不可变审计节锚点修订

创建人员：dev.developer.project.secondary / infodev-2
事项：`DEV-PROJECT-INFO-BILI-AUTHENTICATED-SESSION-DOWNLOAD-20260805-001`
需求：`REQ-BILI-DYNAMIC-COLLECTOR-20260804-001`
唯一审核员：`dev.reviewer.project / inforev`
基础合同：V003 `17715/1EC7F6D8D6CD6AA9BEE5F5696D1CB578514CA3C61ADA838777093C8EFEF2C2F1` + V004 `21074/6E2B2AEDD2A432889ACD5314B5AD1C93B923D937E628434AE952A303A2BE8486`
触发审核：`DEV-AUDIT-PROJECT-INFO-BILI-AUTHENTICATED-EXTENSION-MANAGED-LOAD-CANDIDATE-PACKAGE-REVIEW-20260810-001`，结论 `HOLD/1`。

本文件只修订 source approval 对实现审核的生命周期绑定。V003+V004 的 Web Store、exact-nine payload、扩展 ID、秘密边界、policy 事务、安装恢复和所有真实动作门禁继续冻结；发生文字冲突时仅本 V005 的 source approval schema 与审计锚点规则优先。

## 1. 问题与冻结前像

现有 schema 1 `implementation_review={audit_id,audit_path,audit_bytes,audit_sha256,verdict}` 把批准绑定到整份 append-only `dev-doc/开发审计报告.md`。候选包审核必须追加新审计节，导致 whole-file bytes/SHA 合法变化，builder 与 installer 随即 `E_BUILD_CONTRACT`。候选 ZIP 本身的9项身份、CRC、扩展 ID、哈希和秘密边界均已通过，但批准链不可继续消费。

冻结历史，不作修改、覆盖或复用：

- 候选 ZIP：`20072/96A7FA513EA136A63A15AC1654D4918F368B3D2CD195F381536C1A6B138D2E91`
- 候选 receipt：`2165/4D90F74D7FE0DBDF197499AC48040733D1C4A885262C7B6734BC2A7F1284596F`
- 历史 source approval：`2261/F54924D29A1390538C7BBB1BB30A5F2E2FC4A7AFB7F935E1184B8C6D91D22ED0`

V005 设计 PASS 前，builder、installer、contract、README、测试和候选输出全部冻结；不得创建新候选。

## 2. 唯一修复路径

### 2.1 source approval schema 2

新 source approval 顶层 exact keys 沿用 V004，但 `schema` 必须为 `2`。旧 schema 1 在 builder 与 installer 的任何业务输出、copy、registry、pending 或 receipt 前失败关闭，不能自动迁移或 fallback。

`implementation_review` exact keys 改为：

```text
audit_id
audit_path
audit_section_format
audit_section_bytes
audit_section_sha256
verdict
```

固定值与格式：

- `audit_path=dev-doc/开发审计报告.md`
- `audit_section_format=mbx-markdown-level2-section-lf-v1`
- `audit_id` 必须匹配生产前缀 `DEV-AUDIT-PROJECT-INFO-BILI-AUTHENTICATED-EXTENSION-MANAGED-LOAD-`；测试仅内部 adapter 可用 `DEV-AUDIT-TEST-MANAGED-LOAD-`
- `audit_section_bytes` 为正整数
- `audit_section_sha256` 为64位大写十六进制
- `verdict=PASS`

schema 2 不再出现或接受 `audit_bytes`、`audit_sha256`，产品代码和合同也不得比较整份审计文件的长度或 SHA-256。approval 外层 path/bytes/SHA、reviewer role/scope/status、contract、原 source manifest、managed source tree 和 exact-nine payload 绑定继续不变。

### 2.2 规范审计节算法

builder 与 installer 必须消费 `managed-load-contract.json` 中同一份 `implementation_audit_section_contract`，不得各自冻结不同常量。算法固定如下：

1. 对 `audit_path` 及父链做 lexical/no-reparse 检查；目标必须是普通文件。
2. 严格 UTF-8 解码；拒绝 BOM、NUL、CR 和无效 UTF-8。本合同只接受 LF 行尾。
3. 审计节起始行必须是唯一的 exact `## {audit_id}`；0次或多次均失败。
4. 节范围从该标题行开始，到下一个行首 exact `## ` 二级标题之前，若没有后续标题则到 EOF。
5. 仅移除节尾连续空行；其余字符、空格和行序保持不变。把剩余各行用单个 LF 连接，并追加恰好一个最终 LF，得到 canonical section bytes。
6. 复算 canonical bytes 长度和 SHA-256，与 approval 的 `audit_section_bytes/audit_section_sha256` exact 比较。
7. canonical section 中必须各有一行 exact `- verdict=PASS/0`、`- blocking_findings=0`，并包含本 task ID 和当前 `managed_load_source_tree.tree_sha256`。

因此，在原节之后合法追加一个或多个新的 `## ...` 审计节不会改变 canonical bytes；对原节的修改、删除、截断、同 ID 复制、在原节内部无标题插入内容、ID/hash/bytes 漂移都会失败关闭。

## 3. 模块改动边界

只允许修改：

1. `build_webstore_upload.ps1`：共享语义的审计节提取/校验；schema 2 source approval；删除 whole-file identity gate。
2. `install_managed_extension_policy.ps1`：实现与 builder 等价的同合同校验，且仍在 copy/HKCU/pending 前执行。
3. `managed-load-contract.json`：schema 2、审计节格式/标题/规范算法/required lines；source approval exact child keys。
4. `test_managed_load.py`：仅聚焦本修复及既有回归。
5. `README.md`、实现证据、worklog 和 append-only 开发账本：纠正生命周期说明和测试证据。

不得修改冻结的 `bili_authenticated_extension/` 17文件、bridge、worker/runtime、历史候选和 reviewer 私有批准。developer 不得创建正式 source approval。

## 4. 验收矩阵

所有反例均在 `TemporaryDirectory` 的受控复制树内执行，生产 CLI 不暴露测试注入参数。

### 4.1 两个消费者的非真空正例

对 builder `-ValidateOnly` 与 installer `-ValidateOnly` 分别证明：

1. schema 2 approval 绑定唯一 PASS 审计节时通过。
2. approval 生成后，在审计文件尾部追加一个和多个无关 `## ...` 节，原 approval 仍通过。
3. 通过时 builder 不创建输出；installer 不 copy、不建 pending/receipt、不写 registry。

### 4.2 两个消费者的失败关闭反例

至少参数化覆盖：

- 原审计节任一字符修改、删除、截断；
- 原审计 ID 标题复制；
- approval 的 ID、section bytes、section SHA、format、verdict 漂移；
- 审计节缺 required line、task ID 或 source tree hash；
- stale schema 1 / stale source tree / cross-source approval；
- CRLF、BOM、NUL、无效 UTF-8、audit path 或父链 reparse；
- 在原节尾部但下一个二级标题之前插入未绑定内容。

断言均为 `SAFETY_STOP/exit 3` 和固定 `E_BUILD_CONTRACT`；builder output absent，installer copy/HKCU/pending/receipt 全部 absent，错误输出不包含外部正文或秘密值。

### 4.3 静态与回归

- 产品代码、contract、README 和正式 schema 中 `audit_bytes/audit_sha256` 整文件绑定匹配数为0；测试可保留历史负例字面量。
- PowerShell parser、strict JSON、UTF-8/no BOM/no trailing whitespace PASS。
- 当前目标测试、项目回归与 governance `OK/projects1/warnings0`。
- 历史候选4个核心文件 bytes/SHA 在 Stage A 前后不变；新候选数量仍为0。

## 5. 审核与两阶段门禁

1. V005 先沿原 inforev 链做 audit-anchor-only 设计复审。PASS 前不得改产品代码。
2. 设计 PASS 后实施本文件第3节，运行第4节离线测试，再提交同链 source/implementation 复审。
3. 只有实现 `PASS/0` 且 reviewer 在源码/测试/输出树外创建一个绑定新 schema 2、new source tree 和 canonical implementation-audit section 的 source approval，Stage A 才结束。
4. Stage B 只有在上述门禁满足且 project.admin 后续调度一个此前不存在的输出根后，才允许构建恰好一个新候选；当前 HOLD 候选不得复用或发布。
5. 新候选仍须同链 hash-only package identity/release-gate 审核。正式 Web Store release approval 只能在未来受权上传/发布证据存在后形成，本阶段不得创建。

## 6. 零动作边界

设计、实现、测试和 source 审核全过程：Web Store upload/publish、release approval、policy/HKCU、安装/启用、Chrome/Cookie/session、network/download、真实媒体、`F:\video`、formal `ana-data`、转写和 `BV1HA3o6oEJJ` runtime 均为0。不得新建任务、owner、reviewer 或审核链。