knowledge-vault/work/internal/强哥的思想宇宙/作废的一轮/2026-06-19提取QPI模型9-Codex.md

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需要的：

不需要全仓。让 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 当前只写了：

"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 里包含了：

"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) 重新核对后，结果是：

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.