548 lines
24 KiB
Markdown
548 lines
24 KiB
Markdown
# 1
|
||
|
||
现在进入了第6轮。你看下相关的文档。
|
||
|
||
我觉得现在可以授权进入6.1的执行了。
|
||
|
||
你的意见呢？
|
||
|
||
根据 2026-06-19 的 Round 06 / 06.1 文档，我的意见是：
|
||
|
||
**可以授权进入 6.1 执行，但不能按“完全放开 patch”授权。应该授权一个窄范围的 6.1 selector-support patch。**
|
||
|
||
原因是：当前文件状态明确写着 **6.1 planning 已完成，但 selector-support patch 尚未授权**，Codex 应在 Owner / CCRA 明确批准前停止。 这说明现在不是“文档已经自动允许执行”，而是到了你可以下达正式执行授权的节点。
|
||
|
||
我建议你授权，但加 8 条硬边界。
|
||
|
||
### 我的判断
|
||
|
||
**1. Round 06 可以关闭为 document-only。**
|
||
GPT review disposition 已经把 Round 06 标成 `document_only_close_ready`，并说明 contract review materials 已更新，但 selector patch、regression additions、lifecycle promotion 仍未授权。
|
||
|
||
**2. 6.1 可以进入执行，但执行范围必须是 selector-support patch，不是 selector 重写。**
|
||
6.1 patch 目标可以包括：识别结构化 `qpi_context_provided`、处理 `prior_qpi_result.source`、校验 runtime required fields、校验 same-object / same-frame、阻断 `user_claimed_qpi` 跳过 QPI、仅在 direct IA gates 全部通过时给 IA 例外标签。
|
||
|
||
**3. 不建议同时授权 regression 扩张或生命周期升级。**
|
||
Round 06/06.1 多处都在防止“顺手扩大范围”：不引入第三模型、不升级 QPI / 思想考古学生命周期、不做 LLM selector、不做 RAG / 前后端、不允许自然语言 prior-QPI 绕过。
|
||
|
||
**4. direct IA 这部分要更保守。**
|
||
`direct_ia_exception_material_sufficient` 还需要新的 exact text；现有 `R04-BI-026/027/038` 更适合继续作为边界样例，而不是直接放开 IA-only。
|
||
|
||
### 我建议你给 Codex 的授权口径
|
||
|
||
可以这样授权：
|
||
|
||
> Owner 授权进入 Round 06.1 selector-support patch execution。
|
||
> Round 06 先关闭为 document-only。
|
||
> 本轮只实现结构化 prior-QPI handoff 与 direct IA exception 的窄范围 selector 支持。
|
||
> 不授权第三模型、LLM selector、RAG、前后端、模型卡修改、模型 spec 修改、生命周期升级。
|
||
> calibration JSON 只允许加入 Owner / CCRA 明确接受的 fixture。
|
||
> regression 不默认新增；如新增，必须逐条列出 guardrail 理由。
|
||
> 所有 selector 行为变化必须生成 before / after diff；所有 non-target behavior change 必须给出 Owner / CCRA accept / reject / defer disposition。
|
||
> changed-file allowlist 以 `11_ROUND06_1_SELECTOR_SUPPORT_PATCH_PLANNING.md` 第 7 节为准，超出文件必须另行授权。
|
||
|
||
### 我不建议的授权方式
|
||
|
||
不要说“授权 Codex 进入 6.1 执行，按文档自行处理”。
|
||
这会留下三个风险：
|
||
|
||
第一，fixture 还不是全部 approved，尤其 direct IA material-sufficient exact case 还没定。
|
||
第二，calibration / regression 的边界容易被 Codex 顺手扩大。
|
||
第三，selector patch 如果没有 before / after diff，后续很难判断非目标行为是否被破坏。
|
||
|
||
### 最终意见
|
||
|
||
**我支持你现在授权 6.1 执行。**
|
||
|
||
但准确说，是授权：
|
||
|
||
**Round 06.1-A：窄范围 selector-support patch execution。**
|
||
|
||
不是授权：
|
||
|
||
**Round 06.1：开放式 selector 改造 / regression 扩张 / direct IA 默认化 / 模型生命周期升级。**
|
||
|
||
# 2
|
||
|
||
Codex的回复：
|
||
|
||
```md
|
||
|
||
Round 06.1 scoped patch 已完成，性质是 `implementation_complete_pending_external_review`，不是生命周期升级。
|
||
|
||
主要产物：
|
||
- [run_selector_demo.py](C:/Users/wangq/Documents/Codex/work-projects/the-mindscape-of-bro-tsong/scripts/run_selector_demo.py:173)：新增结构化 prior-QPI handoff、自然语言 prior-QPI lightweight QPI review、direct IA 窄例外。
|
||
- [run_round06_1_selector_patch_audit.py](C:/Users/wangq/Documents/Codex/work-projects/the-mindscape-of-bro-tsong/scripts/run_round06_1_selector_patch_audit.py:13)：生成 before/after snapshot、behavior diff、Skill 审计输入。
|
||
- [01_ROUND06_1_POST_PATCH_CLOSEOUT.md](C:/Users/wangq/Documents/Codex/work-projects/the-mindscape-of-bro-tsong/reports/round06_1_post_patch/01_ROUND06_1_POST_PATCH_CLOSEOUT.md:1)：Round 06.1 closeout。
|
||
- [DECISIONS.md](C:/Users/wangq/Documents/Codex/work-projects/the-mindscape-of-bro-tsong/docs/DECISIONS.md:395)：记录 Decision 024。
|
||
|
||
结果：
|
||
- Project audit diff：PASS，245 cases，9 targeted changes，0 non-target changes。
|
||
- External routing diff Skill：PASS，327 source-qualified cases，9 targeted changes，0 non-target changes。
|
||
- Validation 全部通过：unit tests 33/33、index check、model library validation、selector regression、card contract、model/card sync。
|
||
- Lifecycle guard scan：PASS，11 files，0 blocking，0 warnings。
|
||
|
||
未修改：
|
||
- `selector/selector_calibration_inputs.json`
|
||
- regression JSON
|
||
- model cards
|
||
- model specs
|
||
- QPI / IA lifecycle status
|
||
|
||
未解决问题只剩审查层面的判断：是否把 Round 06.1 fixture 以后转 regression，以及 legacy `QPI 已判断...` pipeline 行为是否留待后续 product-contract 讨论。
|
||
|
||
```
|
||
|
||
这个你需要审核么？你需要什么文件来判断么？
|
||
|
||
我们下一步是否可以继续。
|
||
|
||
|
||
根据 2026-06-19 的文档判断：**需要审核，但只需要轻量审核，不需要重审全仓。**
|
||
|
||
我的意见是：
|
||
|
||
**Codex 这份回复看起来是合格的 6.1 执行完成汇报，但还不能仅凭这段文字直接判定 PASS。**
|
||
因为 Round 06.1 原本要求：patch 后必须有 changed files、target / non-target behavior changes、validation results、regression impact、lifecycle guard result、unresolved decisions 等 closeout 证据。 同时，6.1 patch 也必须有 before / after diff，列出 target changes、non-target changes 和缺失 case 解释。
|
||
|
||
### 我需要的文件
|
||
|
||
不需要全仓。让 Codex 打一个 **Round 06.1 external review bundle**，至少包含这些：
|
||
|
||
1. `reports/round06_1_post_patch/01_ROUND06_1_POST_PATCH_CLOSEOUT.md`
|
||
2. `reports/round06_1_selector_patch_audit/round06_1_behavior_diff.md`
|
||
3. `reports/round06_1_selector_patch_audit/round06_1_behavior_diff.json`
|
||
4. `reports/round06_1_selector_patch_audit/before_selector_behavior.json`
|
||
5. `reports/round06_1_selector_patch_audit/after_selector_behavior.json`
|
||
6. `scripts/run_selector_demo.py`
|
||
7. `scripts/run_round06_1_selector_patch_audit.py`
|
||
8. `tests/test_round06_1_selector_patch_audit.py`，如果确实新增了
|
||
9. `docs/DECISIONS.md` 中 Decision 024 相关段落
|
||
10. validation / unit test / lifecycle guard 的输出报告或命令日志
|
||
|
||
如果 Codex 已经生成了 `ccra_review_bundle/round-06.1_*/*`，直接上传这个 bundle 最好。6.1 planning 里允许 post-patch evidence 出现后再创建 review bundle。
|
||
|
||
### 我会审核什么
|
||
|
||
我不会重做代码审查，而是查 5 件事：
|
||
|
||
第一，**范围是否越界**：是否只做了结构化 prior-QPI handoff、source trust gate、runtime field check、context continuity、`user_claimed_qpi` 阻断、direct IA 窄例外。这个范围和 6.1 目标一致。
|
||
|
||
第二，**改动文件是否在 allowlist 内**：6.1 明确允许 selector、audit script、audit test、README、DECISIONS、reports、review bundle；同时明确禁止改 model cards、model specs、regression JSON、source records、lifecycle status。
|
||
|
||
第三，**9 个 targeted changes 是否真的都是 target changes**，尤其 direct IA 是否只在 material sufficient + gate 全通过时发生，不是因为“底层 / 机制 / 结构”等词触发。6.1 原本要求 direct IA 不能变成 broad selector rewrite。
|
||
|
||
第四，**0 non-target changes 是否可信**：需要看 diff JSON / MD，而不是只看 Codex 摘要。
|
||
|
||
第五，**未解决问题是否被正确留在审查层**：fixture 是否转 regression，要按高风险 guardrail 标准另判，不应在 6.1 顺手加入；文档也明确说 broad exploratory examples 应留在 calibration，不应直接进 regression。
|
||
|
||
### 下一步是否可以继续
|
||
|
||
可以继续，但我建议这样分两步：
|
||
|
||
**下一步不是直接进 6.2，而是进入：Round 06.1 external review / acceptance。**
|
||
|
||
如果上传的 evidence bundle 通过，我会建议你做这个 Owner decision：
|
||
|
||
> Accept Round 06.1 as `implementation_complete_external_review_passed`。
|
||
> No lifecycle promotion。
|
||
> No regression additions for now。
|
||
> Keep legacy `QPI 已判断...` pipeline behavior as deferred product-contract discussion。
|
||
> Authorize next round as planning only.
|
||
|
||
通过后，再进入下一轮。下一轮我倾向于不是继续加 selector 功能，而是处理 **6.2：post-selector contract consolidation**，也就是把这次新增行为沉淀成稳定契约、fixture 分层、是否转 regression 的决策，而不是马上扩模型或做更复杂路由。
|
||
|
||
可以通过，但我建议标记为：
|
||
|
||
**Round 06.1：external review PASS with follow-up items**
|
||
不要标成“完整合同实现无缺口”，也不要触发生命周期升级。
|
||
|
||
我解压并检查了你上传的 6.1 zip。我的审核结论如下。
|
||
|
||
## 1. 主结论
|
||
|
||
**6.1 scoped selector-support patch 可以通过。**
|
||
|
||
通过理由：
|
||
|
||
1. evidence bundle 基本完整：有 closeout、before / after snapshot、behavior diff、validation gates、lifecycle guard scan、Decision 024、核心改动文件。
|
||
2. 我重新按 source-qualified pair 检查了 `before_selector_behavior.json` 和 `after_selector_behavior.json`：
|
||
**327 个 source-qualified cases，9 个变化，9 个 targeted，0 个 non-target，0 个 missing before / after。**
|
||
3. 目标行为符合 6.1 主方向：
|
||
|
||
* 自然语言 `QPI 已经判断...` 从 `IA+QPI` 收敛为 `QPI`；
|
||
* 有效结构化 prior-QPI handoff 可以进入 IA；
|
||
* missing field / user claimed / low confidence / scope false / continuity unclear 都回到 QPI；
|
||
* direct IA 只有一个窄 material-sufficient fixture 放行；
|
||
* `R04-BI-026/027/038` 仍保持 QPI-first；
|
||
* `R04-BI-030` 仍 no-call。
|
||
4. 没有发现 regression JSON、model cards、model specs、模型生命周期状态被改动。这个符合 6.1 的边界；6.1 本来要求不得引入第三模型、LLM selector、RAG、前后端、生命周期升级，也要求 selector patch 保留 before / after diff。
|
||
|
||
## 2. 不阻塞通过，但必须记录的两个问题
|
||
|
||
### 问题 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 可能掩盖变化。
|
||
|
||
## 4. 是否可以继续
|
||
|
||
可以继续。
|
||
|
||
我建议 Owner 决策写成：
|
||
|
||
```text
|
||
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.
|
||
```
|
||
|
||
下一步我建议进入：
|
||
|
||
**Round 06.2：contract consolidation / fixture-to-regression decision planning**
|
||
|
||
而不是立刻扩 selector 功能。6.2 的核心任务应该是决定：哪些 6.1 fixture 值得转 regression，哪些只留 calibration，哪些合同字段需要修正或显式 defer。
|
||
|
||
# 3
|
||
|
||
上述6.1相关内容已经发送给Codex。
|
||
那么6.2的相关任务如何展开？
|
||
|
||
根据 2026-06-19 的相关文档，**6.2 不应该展开成“继续加 selector 功能”的执行轮，而应该定义为：6.1 后的合同收敛与 regression 取舍轮。**
|
||
|
||
我理解 6.2 可以一句话定义为：
|
||
|
||
> **Round 06.2：把 6.1 selector-support patch 的实现结果，转化为稳定产品合同、fixture 分层、regression 决策和后续 patch 边界。**
|
||
|
||
## 1. 6.2 的核心判断
|
||
|
||
6.1 已经完成的是 **scoped selector-support patch**。它验证了结构化 `prior_qpi_result` / `qpi_context_provided` handoff 和 direct IA 窄例外能否进入 selector。6.2 不应该继续顺手扩大 selector，而应该处理三个问题：
|
||
|
||
1. **合同与实现是否完全对齐**；
|
||
2. **哪些 6.1 fixture 应该转成 regression，哪些只保留 calibration**；
|
||
3. **后续是否需要一个很小的 6.2.1 修复 patch**。
|
||
|
||
这个方向符合原本的边界：6.1 patch 不应变成开放式 selector redesign，也不应顺手做 regression、model card、model spec 或 lifecycle 变更。
|
||
|
||
## 2. 6.2 的任务分层
|
||
|
||
我建议把 6.2 拆成 **6.2-A 到 6.2-E** 五个任务包。
|
||
|
||
### 6.2-A：正式记录 6.1 接受结论
|
||
|
||
目标不是再审一遍代码，而是把 Owner / CCRA 的接受状态写清楚。
|
||
|
||
建议 Codex 产出：
|
||
|
||
```text
|
||
reports/round06_2_contract_consolidation/01_ROUND06_2_OPEN_REVIEW_BRIEF.md
|
||
reports/round06_2_contract_consolidation/02_ROUND06_1_ACCEPTANCE_RECORD.md
|
||
docs/DECISIONS.md 追加 Decision 025
|
||
```
|
||
|
||
Decision 025 建议写成：
|
||
|
||
```text
|
||
Accept Round 06.1 as implementation_complete_external_review_passed_with_followups.
|
||
|
||
No lifecycle promotion.
|
||
No regression additions by default.
|
||
No model card or model spec edits.
|
||
No third model.
|
||
No LLM selector.
|
||
No RAG / frontend / backend.
|
||
Proceed to Round 06.2 contract consolidation.
|
||
```
|
||
|
||
这里要特别强调：**selector demo、validation pass、schema pass 都不能构成生命周期升级证据**；QPI 和思想考古学仍应保持 draft / B 级，后续升级需要 evidence review、content review、regression review、selector review、Owner / CCRA review。
|
||
|
||
## 3. 6.2-B：处理 6.1 外部审核留下的 3 个 follow-up
|
||
|
||
这里是 6.2 的重点。
|
||
|
||
### Follow-up 1：`owner_confirmed_qpi` 是否补为 trusted source
|
||
|
||
Round 06 contract 里，`system_generated_qpi` 和 `owner_confirmed_qpi` 都可以在 required fields 和 validity scope 满足时 skip QPI；`user_claimed_qpi` 不可以。
|
||
|
||
6.1 实现目前如果只支持 `system_generated_qpi`，那属于**保守误拒**，不是安全漏洞。但 6.2 必须决策：
|
||
|
||
```text
|
||
accept：6.2.1 补上 owner_confirmed_qpi；
|
||
defer：暂不支持 owner_confirmed_qpi，但在合同里标记 implementation_deferred；
|
||
reject：取消 owner_confirmed_qpi 作为 trusted source。
|
||
```
|
||
|
||
我的建议：**accept，但放到 6.2.1 小 patch，不在 6.2 文档轮直接改 selector。**
|
||
|
||
### Follow-up 2：`qpi_version` / `original_input_ref` 是否从 runtime required 移出
|
||
|
||
Round 06 contract 已经把字段分为 runtime required 和 audit recommended；`qpi_version`、`original_input_ref` 是 audit recommended，缺失不应单独阻止 MVP runtime evaluation。
|
||
|
||
6.2 要明确：
|
||
|
||
```text
|
||
runtime_required:
|
||
- source
|
||
- classification
|
||
- classification_confidence
|
||
- dominant_scarcity
|
||
- evidence_gap
|
||
- misclassification_risk
|
||
- next_model_candidates
|
||
- validity_scope.applies_to_current_input
|
||
|
||
audit_recommended:
|
||
- qpi_version
|
||
- original_input_ref
|
||
- recommended_next_step
|
||
- scarcity_profile
|
||
- validity_scope.scope_note
|
||
```
|
||
|
||
我的建议：**6.2 标记为 implementation alignment gap；6.2.1 再修 selector_rules。**
|
||
|
||
### Follow-up 3：audit diff key 改成 `source + case_id`
|
||
|
||
这个不影响 6.1 通过，但影响后续审计可信度。6.1 planning 原本要求 before / after diff 能列出 target changes、non-target changes 和 missing cases。
|
||
|
||
6.2 应要求：
|
||
|
||
```text
|
||
future audit identity = source_collection + case_id
|
||
not case_id only
|
||
```
|
||
|
||
我的建议：**进入 6.2.1 小 patch，一并修 audit script。**
|
||
|
||
## 4. 6.2-C：fixture 分层，不要把所有 fixture 都转 regression
|
||
|
||
这是 6.2 最容易失控的地方。
|
||
|
||
Round 06 已经规定：一个 case 只有同时满足“合同边界已批准、高风险 guardrail、期望行为稳定、 exact input / object 固定、未来 selector 可能破坏它”时，才应该转 regression；普通探索样例应留在 calibration。
|
||
|
||
我建议 6.2 做一个 fixture disposition table：
|
||
|
||
| fixture / case | 建议归类 | 理由 |
|
||
| ------------------------------------- | -------------------------------- | ---------------------------------- |
|
||
| `R04-BI-025` 自然语言 QPI 已判断 | **转 regression 候选** | 结构化 prior-QPI 已实现后，这是高风险绕过边界 |
|
||
| valid `qpi_context_provided` | **转 regression 候选** | 这是新 handoff 正例合同 |
|
||
| missing runtime field | **转 regression 候选** | 防止字段缺失也跳过 QPI |
|
||
| `user_claimed_qpi` structured variant | **转 regression 候选** | 防止用户声明伪装成系统 handoff |
|
||
| low confidence | calibration 或 regression 候选 | 重要，但可先看是否已有覆盖 |
|
||
| scope false / continuity false | regression 候选 | 防止 stale context 被继承 |
|
||
| direct IA material sufficient | **先 calibration，不急转 regression** | direct IA 正例太敏感，exact text 和边界还要稳定 |
|
||
| `R04-BI-026/027/038` | calibration / boundary examples | 保持 QPI-first，不急着全进 regression |
|
||
| `R04-BI-030` | 可作为 guardrail 候选 | 低上下文 no-call 边界重要，但若已有保护可 defer |
|
||
|
||
我的建议是：**6.2 最多批准 3–5 条 regression，不要一次把 9 个 target 全部转进去。**
|
||
|
||
优先级可以是：
|
||
|
||
```text
|
||
P0:
|
||
1. natural-language prior-QPI claim must not skip QPI
|
||
2. valid structured prior-QPI handoff may allow IA
|
||
3. user_claimed_qpi must not skip QPI
|
||
4. missing runtime field must not skip QPI
|
||
|
||
P1:
|
||
5. continuity false / unclear must not skip QPI
|
||
6. low-context prior reference remains no-call / clarify
|
||
|
||
Defer:
|
||
7. direct IA material sufficient positive regression
|
||
8. broad R04 direct IA candidates
|
||
```
|
||
|
||
## 5. 6.2-D：合同文档收敛
|
||
|
||
6.2 应该把 6.1 的执行结果沉淀成一个稳定的 contract consolidation 文档，而不是只留在 round report 里。
|
||
|
||
建议新增：
|
||
|
||
```text
|
||
docs/ROUND06_STRUCTURED_QPI_HANDOFF_AND_DIRECT_IA_CONTRACT.md
|
||
```
|
||
|
||
或者如果你不想增加长期 docs，可以先放：
|
||
|
||
```text
|
||
reports/round06_2_contract_consolidation/03_CONTRACT_ALIGNMENT_MATRIX.md
|
||
```
|
||
|
||
这份 matrix 至少包含：
|
||
|
||
1. contract requirement；
|
||
2. current implementation；
|
||
3. status：aligned / conservative_mismatch / overreach_risk / deferred；
|
||
4. required follow-up；
|
||
5. target file；
|
||
6. 是否需要 6.2.1 patch。
|
||
|
||
重点记录这三类：
|
||
|
||
```text
|
||
aligned:
|
||
- user_claimed_qpi cannot skip QPI
|
||
- continuity false / unclear cannot skip QPI
|
||
- direct IA not triggered by deep words alone
|
||
|
||
conservative_mismatch:
|
||
- owner_confirmed_qpi not yet trusted
|
||
- qpi_version / original_input_ref treated too strictly
|
||
|
||
audit gap:
|
||
- diff key should be source + case_id
|
||
```
|
||
|
||
## 6. 6.2-E：决定是否授权 6.2.1 小修 patch
|
||
|
||
6.2 本身建议先作为 **planning / contract consolidation**。
|
||
如果 6.2 文档完成并且你接受，我建议再授权一个非常小的：
|
||
|
||
> **Round 06.2.1：contract-alignment micro patch**
|
||
|
||
允许改动范围只包括：
|
||
|
||
```text
|
||
selector/selector_rules.json
|
||
scripts/run_round06_1_selector_patch_audit.py
|
||
tests/test_round06_1_selector_patch_audit.py
|
||
docs/DECISIONS.md
|
||
reports/round06_2_1_contract_alignment_patch/*
|
||
ccra_review_bundle/round-06.2.1_*/*
|
||
```
|
||
|
||
6.2.1 只做三件事：
|
||
|
||
1. 加入 `owner_confirmed_qpi` trusted source；
|
||
2. 把 `qpi_version` / `original_input_ref` 从 runtime required 移到 audit recommended；
|
||
3. audit diff key 改为 `source + case_id`。
|
||
|
||
不要在 6.2.1 做 direct IA 扩张、第三模型、模型卡修改、regression 大扩张或 lifecycle promotion。
|
||
|
||
## 7. 给 Codex 的建议任务指令
|
||
|
||
你可以把下面这段直接发给 Codex：
|
||
|
||
```md
|
||
进入 Round 06.2：contract consolidation / fixture-to-regression decision planning。
|
||
|
||
本轮不是 selector 功能扩张，也不是 lifecycle promotion。
|
||
|
||
目标：
|
||
1. 记录 Round 06.1 external review acceptance：implementation_complete_external_review_passed_with_followups。
|
||
2. 建立 Round 06.1 implementation vs Round 06 contract alignment matrix。
|
||
3. 对三个 follow-up 做决策准备：
|
||
- owner_confirmed_qpi 是否作为 trusted source 补入；
|
||
- qpi_version / original_input_ref 是否从 runtime required 移出；
|
||
- audit diff key 是否改为 source + case_id。
|
||
4. 对 Round 06.1 fixtures 做 disposition：
|
||
- regression now；
|
||
- calibration only；
|
||
- defer；
|
||
- reject。
|
||
5. 不允许默认新增 regression。只有被 Owner / CCRA 明确标记为 high-risk guardrail 且 exact input/object 固定的 case 才能进入 regression proposal。
|
||
6. 不修改 model cards、model specs、source records、lifecycle status。
|
||
7. 不引入第三模型、LLM selector、RAG、前端、后端。
|
||
8. 输出 Round 06.2 review bundle，供 CCRA / GPT 审核。
|
||
|
||
建议产物：
|
||
- reports/round06_2_contract_consolidation/01_OPEN_REVIEW_BRIEF.md
|
||
- reports/round06_2_contract_consolidation/02_ROUND06_1_ACCEPTANCE_RECORD.md
|
||
- reports/round06_2_contract_consolidation/03_CONTRACT_ALIGNMENT_MATRIX.md
|
||
- reports/round06_2_contract_consolidation/04_FIXTURE_REGRESSION_DISPOSITION.md
|
||
- reports/round06_2_contract_consolidation/05_ROUND06_2_DECISION_QUESTIONS.md
|
||
- docs/DECISIONS.md 追加 Decision 025 draft
|
||
- ccra_review_bundle/round-06.2_2026-06-19_contract-consolidation/*
|
||
```
|
||
|
||
## 8. 我的最终建议
|
||
|
||
**下一步可以继续，但继续方式应该是：**
|
||
|
||
```text
|
||
Round 06.2 = 文档收敛 + 决策准备
|
||
Round 06.2.1 = 如有必要，再做极小 contract-alignment patch
|
||
```
|
||
|
||
不要直接进入：
|
||
|
||
```text
|
||
selector v0.3
|
||
更多 direct IA
|
||
更多模型
|
||
更复杂 regression
|
||
生命周期升级
|
||
```
|
||
|
||
现在这个项目最大的风险不是能力不够，而是 selector 边界刚稳定一点，又被新功能扩张冲散。6.2 的价值就是把 6.1 的成果钉牢。
|
||
|
||
# 4
|
||
|
||
那么我现在的问题是：
|
||
|
||
QPI已经跑了6轮，每轮里面有若干小回合。
|
||
距离我准备开始做产品已经过去了4、5天，每天消耗Token少的4、5000，多的1个亿。
|
||
QPI还没有结束。
|
||
类似问题，我前天问过，基于你当时的回复，我抽成了`09_数据治理与模型调用机制说明`。
|
||
|
||
我们这个一共有几轮？每轮都在做什么？
|
||
后续新的模型进来，是否都要经历这个完整的轮次？
|
||
现在做的事情，很多，我认为ROI相当低。
|
||
比如，没有LLM语义参与的Selector，不准，还在这里调优；QPI只是入口模型，根本不参与后续的问题处理，IA也只是模型之一，还有其他重要的模型。
|
||
|
||
对以上问题，你怎么考虑？
|
||
|
||
|