# 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.