120 lines
5.2 KiB
Markdown
120 lines
5.2 KiB
Markdown
# 1
|
||
|
||
检查一下，什么原因造成`round-06.1_2026-06-19_selector-support-scoped-patch` 里面出现了这么多文件。
|
||
|
||
因为是web上传，这么多文件没法上传。
|
||
|
||
检查结果：`round-06.1_2026-06-19_selector-support-scoped-patch` 文件多，不是因为 selector patch 本身改了很多源码，而是因为这个目录被组成了“完整审查证据包”。
|
||
|
||
关键原因：
|
||
|
||
- `WEB_BUNDLE_MANIFEST_06.1.json` 明确把 7 个 evidence 目录列进 bundle：`post_patch_evidence`、`selector_behavior_diff`、`independent_routing_diff`、`validation_gates`、`lifecycle_scan`、`raw_changed_files`、`audit`。
|
||
- `BUNDLE_FILE_MANIFEST_06.1.md` 自己记录了 audit 发现 `49` 个文件，且 `optional_raw_changed_files_06.1.zip` 又包含 `35` 个源相对路径文件。
|
||
- 实际 tracked 源码改动只有 5 个文件，另有 2 个新增实现/测试文件；其余主要是验证日志、行为 diff、生命周期扫描、bundle audit、raw changed files 的复制件。
|
||
- 这个形态沿用了上一轮 `round-05.1` 的完整 Web CCRA bundle 模式；`round-05.1` 也有 48 个文件，所以这里是组包策略延续，不是本轮异常膨胀。
|
||
- `raw_file_list_06.1.txt` 还把 `reports/round06_1_*`、验证日志、生命周期扫描结果，以及上一轮 Round 06 的 `11_ROUND06_1_SELECTOR_SUPPORT_PATCH_PLANNING.md` 都纳入 optional raw zip 了。
|
||
|
||
所以根因是：**把“本地可审计/可复现证据包”和“Web 上传最小包”混成了同一个目录**。
|
||
|
||
Web 上传建议只传这 6 个主审查文件：
|
||
|
||
1. `00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF_06.1.md`
|
||
2. `01_SCOPE_AND_OWNER_DECISION_06.1.md`
|
||
3. `02_SELECTOR_BEHAVIOR_DIFF_06.1.md`
|
||
4. `03_VALIDATION_LIFECYCLE_REGRESSION_06.1.md`
|
||
5. `04_REVIEW_QUESTIONS_FOR_WEB_CCRA_06.1.md`
|
||
6. `05_EVIDENCE_INDEX_06.1.md`
|
||
|
||
需要原始证据时，再单独传 `optional_raw_changed_files_06.1.zip`，不要把 evidence 目录里的 49 个文件逐个上传。
|
||
|
||
我没有改动文件，只做了检查。
|
||
|
||
# 2
|
||
|
||
这是GPT需要的：
|
||
|
||
```md
|
||
不需要全仓。让 Codex 打一个 Round 06.1 external review bundle，至少包含这些：
|
||
|
||
reports/round06_1_post_patch/01_ROUND06_1_POST_PATCH_CLOSEOUT.md
|
||
reports/round06_1_selector_patch_audit/round06_1_behavior_diff.md
|
||
reports/round06_1_selector_patch_audit/round06_1_behavior_diff.json
|
||
reports/round06_1_selector_patch_audit/before_selector_behavior.json
|
||
reports/round06_1_selector_patch_audit/after_selector_behavior.json
|
||
scripts/run_selector_demo.py
|
||
scripts/run_round06_1_selector_patch_audit.py
|
||
tests/test_round06_1_selector_patch_audit.py，如果确实新增了
|
||
docs/DECISIONS.md 中 Decision 024 相关段落
|
||
validation / unit test / lifecycle guard 的输出报告或命令日志
|
||
```
|
||
|
||
能否对6.1的目录进行一个清理，只留下web上传用的。
|
||
本地检查的目录不在`round-06.1_2026-06-19_selector-support-scoped-patch`这里。
|
||
|
||
|
||
# 3
|
||
|
||
我检查了6.1的目录
|
||
|
||
### 问题 A：`owner_confirmed_qpi` 没有被实现为 trusted source
|
||
|
||
Round 06 contract 明确说，`system_generated_qpi` 和 `owner_confirmed_qpi` 都可以在 required fields 和 validity scope 通过时 skip QPI，而 `user_claimed_qpi` 不可以。
|
||
|
||
但 zip 里的 `selector/selector_rules.json` 当前只写了：
|
||
|
||
```json
|
||
"trusted_sources": [
|
||
"system_generated_qpi"
|
||
]
|
||
```
|
||
|
||
这意味着 `owner_confirmed_qpi` 会被挡回 QPI。
|
||
|
||
这不是安全风险，因为它是**保守误拒**，不是 IA 误放行；但它是合同实现缺口。建议在后续 6.1.1 或 6.2 里明确：要么补上 `owner_confirmed_qpi`，要么正式把它 defer。
|
||
|
||
### 问题 B：`qpi_version` / `original_input_ref` 被当成 runtime required 了
|
||
|
||
Round 06 contract 已经把字段分成 runtime required 和 audit recommended。`qpi_version`、`original_input_ref` 是 audit recommended，缺失不应单独阻止 MVP runtime evaluation。
|
||
|
||
但当前 `selector_rules.json` 的 `required_prior_qpi_fields` 里包含了：
|
||
|
||
```json
|
||
"qpi_version",
|
||
"original_input_ref"
|
||
```
|
||
|
||
这会让系统比合同更严格：没有这两个审计字段时，即使其他 runtime 条件满足，也不能 skip QPI。
|
||
|
||
同样，这不是危险误放行，而是保守误拒；但如果不处理，后面会出现“文档说可跳过，selector 实际不跳过”的歧义。
|
||
|
||
## 3. 一个审计方法小问题
|
||
|
||
`round06_1_behavior_diff.json` 自身报告的是 **245 cases**，因为 audit script 用 `case_id` 做 key，遇到不同 source 下相同 `case_id` 会折叠。
|
||
|
||
但 before / after snapshot 实际各有 **327 records**。我用 `(source, case_id)` 重新核对后，结果是：
|
||
|
||
```text
|
||
327 compared
|
||
9 changed
|
||
9 targeted
|
||
0 non-target
|
||
0 missing
|
||
```
|
||
|
||
所以结果可信，但建议后续把 audit script 的 diff key 改成 `(source, case_id)`，否则以后 source 间同名 case 可能掩盖变化。
|
||
|
||
## 结论
|
||
|
||
Accept Round 06.1 as implementation_complete_external_review_passed_with_followups.
|
||
|
||
No lifecycle promotion.
|
||
No regression additions.
|
||
No model card or model spec edits.
|
||
No calibration JSON expansion in this closeout.
|
||
|
||
Required follow-ups:
|
||
1. Decide whether owner_confirmed_qpi should be supported as trusted source.
|
||
2. Align runtime_required fields with the Round 06 contract, especially qpi_version and original_input_ref.
|
||
3. Update future audit diff key to source-qualified identity: source + case_id.
|
||
|