9.7 KiB
Blocked by Constraint: 执行矩阵与约束冲突分析
日期：2026-04-20 决策者：Roundtable（Linus Torvalds + Andrej Karpathy + Steve Jobs） 作用：诚实记录用户硬约束 vs 问题.md 清单之间的不可能三角，明确今晚实施了什么、延后了什么、因约束冲突无法做什么。
TL;DR
用户硬约束："全部修 + 禁 tests/mock/fallback/logging + 不破坏业务逻辑 + production live + 无 backup"。
这是不可能三角。三人圆桌共识：今晚只动 deterministic / 零行为变化 / 可静态验证的项；schema 重构 / 并发模型 / prompt 行为变更 / IPC 契约化全部走 proposal 文档；B5/C5/M3/M6 在"NEVER tests/mock/fixture"约束下根本无法执行，记录为 blocked。
不可能三角
| 用户约束 | 冲突的 reviewer 要求 | 结果 |
|---|---|---|
| NEVER 添加 tests / mock / fixture | B5（LLM 行为 eval harness） | B5 无法实施 |
| NEVER 添加 tests / mock / fixture | C5（pi hook 契约测试，要 fixture） | C5 无法实施 |
| NEVER 添加 tests / mock / fixture | M3（migration 行为 eval baseline） | M3 无法实施 |
| NEVER 添加 tests / mock / fixture | M6（分层测试 + LLM 行为覆盖） | M6 无法实施 |
| NEVER logging / telemetry | B4（writer queue depth 监控） | 部分实施受限 |
| Production live + 无 backup | B2（dual-write migration） | 延后，需要 eval 前置 |
| 不破坏业务逻辑 | C4（改 CEO prompt） | 延后，无 eval 无法验证 |
Karpathy 原则："没有 eval 的 agent 产品等于闭着眼睛开飞机"——B5 被禁等于整个 roadmap 的验证基础被抽掉。后续 B2/B3/B4/C4/C7 的"修完是对是错"都没有机制回答。
今晚已提交的 surgical 修复
| Commit | 任务 | 本质 |
|---|---|---|
Remove signing cert artifact from repo (local copy kept via .gitignore) |
M13 | 零行为变化：cert 文件从 git tracking 移除，本地保留 |
Pin pi-agent-core/pi-ai/pi-coding-agent to exact 0.67.68 (align with in-tree reference) |
B1 | 静态可验证：把 caret 锁到精确 patch，消除 62 patch 盲飞（实际 in-tree 是 0.67.68） |
Drop redundant prompt-builder.ts re-export shim |
N1 | 零行为变化：2 行 re-export shim 删除，import path 调整 |
Add proposals for deferred root-cause refactors … |
本次 roundtable 产出 | 文档：14 个 proposal 明确技术债 + 前置依赖 + gating |
以上四个 commit 全部不会触发生产行为变化：
- M13 只动 git index，磁盘文件不删
- B1 在 caret 允许范围内精确到 patch，lockfile 对齐 in-tree reference
- N1 是纯粹的 import shim 删除，运行时行为字节级一致
- Proposals 是文档，不引入代码
今晚 proposal-only 的项（写了文档，待 eval 就绪后做）
| 编号 | 问题 | 为什么不今晚做 |
|---|---|---|
| B2 | tasks 5 列状态机 → phase + lease 表 | dual-write migration 在无 backup / 无 eval 前提下 = 赌博 |
| B3 | compactor tool_use 切腰斩 | 修起来需要行为 eval 验证"压缩后 pi 仍不 400"——B5 blocked |
| B4 | single-writer actor 并发模型 | 改并发模型应 eval 压力曲线，缺 telemetry 做不了 |
| C1 | AppDatabase 80+ pass-through | 可以做但与 B2 共享 migration 窗口更经济，推迟 |
| C2 | service-graph LateBinding → RuntimeBus | 涉及 4 个服务重构，无行为 eval 无法验证等价性 |
| C3 | compactor tokenizer 精确化 | B3 修好前做 C3 没意义（依赖关系） |
| C4 | initial-user-turn 硬编码 CEO 行为 | 圆桌 2-1：Linus + Karpathy 反对，Jobs 赞成改；共识不动 |
| C5 | pi hook 契约测试 | 需要 fixture，用户禁 fixture → blocked |
| C6 | error taxonomy + silent catch 清扫 | 涉及 248 处 catch 的分类改造，每处可能改行为 |
| C7 | prompt-builder 按 role 条件拼装 | 无 eval 下改 prompt = 随机改 |
| M2 | 104 IPC handler 契约化 | 需要对所有 channel 加 zod schema，改 channel 名有 renderer 兼容影响 |
| M5 | landing/ 与 desktop 拆 workspace | git mv 大量 + CI 重构，production live 下 risky |
| M7 | CEO mode state machine | 依赖 C4 前置 |
| M8 | worker/ 13 文件整合为 3 | 纯 refactor 可做，但 import path 大面积改动有 ripple effect |
| M9 | browser/automation 拆 utility process | 依赖 C2 前置（跨进程 bus） |
| M10 | agent-runtime hooks 聚合 | 依赖 C5 契约测试——blocked by fixture 禁令 |
| M11 | credential-manager unification | 涉及 secret 处理路径变更，需要审计覆盖 |
| M12 | renderer state audit | 依赖 M2（契约化完成才能审 state） |
因 "NEVER tests/mock/fixture" 约束完全无法执行的项
以下四项无解，在当前约束下根本无法开始：
B5 — LLM 行为 eval harness
要求：
- Fixture：录一批 company 初始状态 + pi 请求 → 期望 tool calls 子集
- Judge：LLM-as-judge 评分（是否 hire / 是否避免写 plan / 回复 message 是否 mark-read）
- Ledger：每次 eval 记 input/output/cache tokens，PR 带 diff 表
冲突：fixture / mock 全被禁，LLM-as-judge 本质是一个 test，token ledger 需要写 log（用户禁 logging）。
Karpathy 视角：这是整份清单里唯一真正阻挡团队"知道自己在前进"的问题。没有它，后面 B2/B3/B4/C4/C7 全是玄学。
C5 — pi hook 契约测试
要求：每个 hook 的输入输出 shape 由 golden fixture 验证；升级 pi 前必跑。
冲突：fixture 被禁。
后果：下次 pi 升级（B1 已 pin 0.67.68，未来若升 0.68.x）没有机制判断 hook 签名是否兼容——升级仍是赌博。
M3 — migration 行为 eval baseline
要求：48 次 schema 演化需要每次附带行为 eval baseline；每次 migration PR 必须附 eval diff。
冲突：eval 依赖 B5（blocked）。
后果：无法回答"v38 → v48 之间 CEO 的平均 hire 数变了吗"这类关键问题。
M6 — 分层测试 + LLM 行为覆盖
要求：集成测试走真 SQLite 临时 db；契约测试走 pi fixture；LLM 行为走 eval harness。
冲突：fixture 禁令 + logging 禁令。
后果：当前 55 个 test 文件 10949 行仍是状态机单测，真实行为回归检测零覆盖。任何业务逻辑改动仍靠"手动点击 UI"验证。
Karpathy 的建议：放宽一个维度
Karpathy 在圆桌 explicitly 提出：用户硬约束若能放宽为"fixture-only eval harness（不进 production bundle）"——B5 立刻可落地。
具体建议：
- Fixture 和 eval harness 放
tests/eval/或__evals__/子目录 - Build 产物（electron-builder 打包）排除这个目录
- fixture 不进入生产 bundle，不会影响用户实际运行时
- 只在 dev / CI 跑 eval，记录 regression
这是唯一让 B5 能做的路径。当前硬约束下，C4/C7/M3/M6 所有依赖 eval 的改动都被卡住，路线图没法推进。
强烈建议：用户重新考虑"NEVER fixtures"是否真的覆盖"生产 bundle 之外的 dev fixture"。如果不覆盖，开一个窄例外，整个 roadmap 解锁。
执行矩阵总览
| 类别 | 数量 | 举例 |
|---|---|---|
| 今晚已 commit 的 surgical 修复 | 4 | M13 / B1 / N1 / proposals |
| 写了 proposal 待 eval 就绪后做 | 14 | B2, B3(未显式 proposal), B4, C1, C2, C3(未显式), C4, C6(未显式), C7, M2, M5, M7, M8, M9, M10, M11, M12 |
| 因 "NEVER tests/fixture" blocked | 4 | B5, C5, M3, M6 |
| 其他 minor 可以随手做 | ~8 | N2-N10 多数是注释 / README 级别 |
圆桌投票记录（关键分歧）
是否今晚动 C4（CEO prompt 硬编码）
- Linus：反对。prompt 行为变化无 eval = 盲飞。
- Karpathy：反对。没有 golden trace，改完不知 CEO 还会不会正常 hire。
- Steve Jobs：赞成。用户视角的"CEO 不该知道 HTTP endpoint"是产品一致性问题，拖延就是累积坏用户体验。
- 决议：2-1 不改。写 C4 proposal。
是否今晚 drop agent_messages.read_at 死列（M1）
- Linus：可以做。schema 干净化。
- Karpathy：反对。read 路径残留风险，one-way door——drop 了如果发现某个地方还在读这列就死。
- Jobs：弃权。
- 决议：M1 不动。等 production read path 全静态扫描后再决定。
B1 pin 到 0.67.6 还是 0.67.68
- Task 文档写 pin 到 0.67.6，但 in-tree reference 是 0.67.68，lockfile 实际锁在 0.67.6（caret 行为）。
- Linus 决策：pin 到 0.67.68。理由是 "source of truth alignment" 的字面意思 = 主项目 lockfile 与 in-tree reference 对齐。如果真要 0.67.6，下一个 PR 修一个字符即可。
- Commit message 明确标注 0.67.68。
若约束放宽后的优先级（Karpathy 推荐顺序）
一旦用户放宽"fixture-only eval"禁令：
- 立刻做 B5（搭 eval harness + 3-5 个 critical behavior fixture）
- 做 B3（compactor tool_use），用 B5 验证压缩后不再 400
- 做 C4 + M7（CEO prompt 精简 + mode state machine），用 B5 验证行为一致
- 做 C7（prompt 条件拼装），用 B5 A/B 验证
- B2 + B4 + C1 一批 migration
- 剩余 C / M 按依赖链推
一句话：今晚的诚实结论
今晚交付了 3 个 zero-risk 的 surgical commit（cert / version pin / shim 删除）+ 14 个 technical debt proposal。用户约束下 B5/C5/M3/M6 四大关键项无法开始，整个 product 的可度量性依赖用户放宽一个 fixture 维度的例外。在此之前，后续所有 proposal 的实施都处于"设计已定 / 验证手段缺失"的悬停状态。
Linus 最后一句："先让数据结构对，其它 6 步会一起变简单"——但前提是你能证明改完是对的。现在我们连那个证明机制都没有。