四悬案复盘
每个悬案一个完整故事，自包含
四个悬案是用户 2026-07-19 点名的复盘对象。每个悬案按同一结构完整呈现：背景（它为什么成为问题）→ 在优化什么 → 关键决策点（已决的：决了什么+依据；未决的：背景+选项+推荐答案）→ 当前状态 → 遗留事项。读完不需要打开任何仓内文件。
悬案一：hook 超时优化 主体已修复 · 残差轻量未清
悬案二：Git 异常删除排查（INC-1/INC-2 事故簇） 修复全绿 · 三项待用户裁定
悬案三：设计哲学提炼（全量 campaign） 提炼已交付 · 落地半程空转
悬案四：Codex→Kimi 额度切换 + provider 文档唯一真源 功能全自动 · 文档 SSOT 落地中
悬案一：hook 超时优化 主体已修复 · 残差轻量未清
背景：它为什么成为问题
2026-07-16，用户报告 Claude Code 反复弹出 UserPromptSubmit hook timed out after 10s — output discarded，且此前已多次出现。这个 hook（route_on_prompt.py）是注入系统的咽喉：每条用户消息进入时，它负责判断该给 agent 注入哪些 skill 引导。它超时，不只是弹个错误，而是整条注入链静默失效。
当时重构 program 正在推进，用户明确要求：不靠单纯延时糊弄，优先保证实现效率；可以延时，但预期的 hook 工作必须正常进行；同时评估修复对迁移 program 的影响。
在优化什么
表面在消除一个超时报错，实际挖出了两层根因和一层比报错更严重的隐性代价。
根因一（07-16 判定）：机器负载风暴，不是代码回归。 hook 自身 CPU 开销恒定约 0.2 秒（643 样本台账锚定），但当时机器 loadavg 峰值 583–619（8 核），负载风暴把这个 0.2s 的进程拖过了 10 秒墙钟死线。这是环境资源争用，不是 hook 变慢了。
隐性代价（比报错更重）：状态先消费、输出后送达。 旧实现把「消费型状态写」（dedup 标记、correction 清除、receipts）放在输出之前执行。超时被杀时，输出被 Claude Code 丢弃，但状态已被消费：该 session 的道 skill 注入被 dedup 判为「已注入」而永久丢失，pending correction 被无声吞掉。报错看得见，注入丢失看不见。
根因二（07-04 独立取证，后被坐实已修）：receipt ledger 全量扫描。 更早一次独立调查发现同一 hook 的另一条根因：record() 每次追加前对整个 append-only 回执账本（当时 126MB）做全量扫描，单次追加 3.5–5.5 秒。这条根因与负载风暴在同一调用链上叠加、互不排斥。后经代码核实，它已经 commit b0ee5c5e2d 修复（O(1) 序号旁路 + 账本轮转 cron），修复恰落在 07-04 与 07-16 之间，所以 07-16 观测到的「hook CPU 恒 0.2s」与 07-04 的「3.5–5.5s」不矛盾：它们是同一路径修复前后的两个正确观测。
关键决策点 · 已决（决了什么 + 依据）
| 已决 | 依据 |
|---|---|
| 修复方式 = deliver-then-persist，非纯延时。main() 先收集全部消费型状态写，stdout flush 之后才执行；超时被杀最多丢一次输出，不再丢注入。 | route_on_prompt.py:139-163（_run_or_defer）与 :935-1139 调用链，07-19 代码核实仍在位。 |
| hook timeout 全局 10s → 30s（Stop 维持 60s），共 17 处全局 settings + 2 处项目 settings。 | 07-19 实测仓内 .claude/settings.json 全部 timeout 为 30/60，零残留 10。 |
| 本次修改属迁移冻结期（P-011）的用户当次授权例外，边界严格划定：只覆盖本记录变更清单，不构成对冻结约束的一般性放松。 | interim RECORD.md:16 + r012 FINAL_REPORT 尾部 addendum 回写确认。 |
| 07-04 发现的 ledger 全扫根因已经修复：record() 改走 O(1) 序号 sidecar + 账本轮转（100MB/10 万行）+ 每日 04:30 轮转 cron。修复前后 P95 从 3.5–5.5s 降到 0.263s。 | commit b0ee5c5e2d + receipt.py:218-278 代码亲核。这是对早期 dossier「仅提案未实施」判定的更正：函数存在不等于热路径在用。 |
| 同批延伸（07-17 P-014 授权的五项持续优化）：Stop hook 孤儿守卫第一层落地（用 timeout 包住 commit wrapper，45s 有界失败）；Codex.app 过热断路器退役（8 天零击杀）；codebase-explorer MCP 双注册点摘除（22 个常驻实例清零）。 | OPEN_PROBLEMS.md HL-1/HL-2/HL-3 节 + stop_hook.sh:820-827 代码亲核。 |
关键决策点 · 未决（背景 + 选项 + 推荐）
Stop hook 孤儿进程的第二层全兜底要不要装？
背景：第一层（用 timeout 包住 wrapper）已落地，覆盖「CC 在守卫触发前杀掉 stop_hook」的窗口。第二层是给 commit_wrapper 自身加自杀式 deadline，覆盖更早的窗口（Ctrl-C、CC 崩溃）。设计已就绪，未实施。
选项：实施（设计现成，需配套 e2e 回归）或继续挂起（第一层已挡住主路径）。
推荐：挂波次 1 附加件实施：成本低，补上的是真实暴露过的故障窗口。
HL-5 高负载对策体系何时点火？
背景：负载风暴被判定为「唯一完全可控的超时风暴源」：fleet 派发加负载哨兵（loadavg 超阈值时拒绝/排队新 worker）+ worker 优先级隔离。体系方案已定，对策 1/2 挂波次 1、3/4 挂波次 3，均尚未开工。
选项：按既定挂点随波次实施，或提前单独立项。
推荐：维持挂波次 1（dispatch 底座新根化同批），单独立项的收益不抵又开一条线。
HL-6 三条轻量残差何时清？
背景：账本轮转阈值漂移（代码默认 100MB vs CRONTAB 注释写 200MB，live 账本已 102MB 未轮转）、序号 sidecar 字节量级膨胀（1.54 亿 vs 实际约 50 万行，cosmetic）、修复后缺少对 record() 单独计时的真实热路径回执。
选项：统一阈值数字（建议以代码为准改注释）+ 跑一次计时回执 + 低优先校正 sidecar。
推荐：随波次 3 观测运维族顺手清，不阻塞任何波次。
当前状态
修复主线全部在位且经 07-19 独立核实：deliver-then-persist 未被回滚、settings 零残留 10s、孤儿守卫第一层在代码里、ledger 全扫修复在位。未见任何由本次修复引入的后续回归（07-18 的 GIT 族三起事故根因是解释器墙与候选面缺口，与本修复无因果关联，已在排查中显式排除）。
一个结构性后果值得知道：本次修复加重了 #ISO-FENCE 隔离单元的必要性而非减轻。timeout 从 10s 拉到 30s 意味着负载风暴窗内旧根 hook 对新根 session 的最长阻塞也变长了，所以 #ISO-FENCE 实施前必须以修改后的文件重新锚定。
遗留事项
- HL-2 第二层全兜底（设计就绪待实施）
- HL-5 对策 1-4（挂波次 1/3，未开工）
- HL-6 三条轻量残差（阈值漂移 / seq 膨胀 / post-fix 计时）
- route_hint.py 两个同族残差（claim-before-emit、风暴窗全量 digest 校验，建议挂 #ISO-FENCE 附加件）
- 存量测试 invariant_stop_hook.sh 4 个 FAIL（四月存量，判定与本次无关，未修）
provenance：adhoc_jobs/context_infra_migration_20260709/runs/interim_20260716_hook_timeout_fix/RECORD.md adhoc_jobs/context_infra_migration_20260709/design/OPEN_PROBLEMS.md（HL 族） tools/skill_router_hook/route_on_prompt.py tools/tool_receipts/receipt.py
悬案二：Git 异常删除排查（INC-1/INC-2 事故簇） 修复全绿 · 三项待用户裁定
背景：它为什么成为问题
2026-07-18 凌晨 01:07–01:57，共享 checkout（多个 agent session 并发写同一棵工作树，这是本仓库的架构选择）上一夜发生三起独立事故：
事故 A（01:07）：一个 07-10 挂起的陈旧 session，其 Stop hook 把 1407 条「相对陈旧 baseline 看似被删」的路径 git rm --cached 进主索引，随后 commit wrapper 以 rc=126 崩溃，1407 条 staged 删除成为孤儿（1358 条幽灵 + 49 条真删）。
事故 B（01:23）：另一个 session 的 worker（cursor-integrator）为做「干净基线」测试，跑了无范围 git stash && pytest; git stash pop，全仓未提交改动被整体扫入 stash。
事故 C（01:46）：25 分钟后，第三个 session 的 worker（w-todo-export）为同一目的（干净基线回归对比）独立复发同一反模式，两轮无范围 stash 后 pop 冲突失败，557 个文件、约 5.7 万行改动的全仓 WIP 滞留 stash@{0}。
数据零永久损失：主编排 session 在无人值守状态下自主发现异常、自主派取证、按「工作树==HEAD 才恢复」判据从 stash 批量恢复 470 个文件。用户次日 10:05 下达排查指令，10:59 下达底层工具修复的一般性授权。
在优化什么
这不是优化单一功能，而是把三条独立故障链坐实并止血，外加一个行为模式判定。
BUG-021：Python 3.9 解释器墙。 守卫的危险分类器 import 链用了 3.10+ 语法，但解释器绑定硬编码 /usr/bin/python3（3.9.6），分类器连续多日 ImportError，守卫 79 次 fail-open 放行（GUARD_FAILURE_ALLOW），即危险操作连续多日零正常分类。
BUG-022：stash 不在守卫候选面。 git 守卫的预过滤危险候选集只有 reset/push/clean/filter-repo/checkout/restore，stash 全家族纯静默放行，即使分类器健康也拦不住。
BUG-023：rc=126 的真凶是 E2BIG，不是解释器墙。 commit_wrapper 把 session 累积的路径清单塞进环境变量传子进程，长命 session 越过 macOS ARG_MAX（实测约 1.1MB），execve 直接失败。关键证伪实验：同一 session 内换绑新解释器前后 rc=126 全部复现，如果根因是解释器版本，换绑后不应复发。这条最初被误判进 BUG-021，晚间独立复现后拆分为独立条目。
行为模式判定：「拿 stash 当干净基线」这个反模式在 25 分钟内被两个不同 session 的 worker 独立复发。这说明它是行为模式，不是个体失误：口头禁令覆盖不住，必须给一条 sanctioned 的正路，并把 stash 纳入确定层守卫。
关键决策点 · 已决（决了什么 + 依据）
| 已决 | 依据 |
|---|---|
| stash 三态分类落地：read 放行 / scoped_push（带明确路径）= 档 B 打 safety tag / sweep（无范围）在共享 checkout 内 = 档 C HUMAN_GATE 硬拒。 | git_guard.sh:389-393 + danger_op_audit.py 新增共享检出上下文；回归 58/58+17/17+24/24 全绿。 |
| 恢复原则立法：工作树==HEAD 才恢复，用 git restore --source 不用 pop。写入 git_safety.md §1（条款正文注明 2026-07-18 INC-1 后新增）。 | 事发当晚按此判据执行，470 文件零残留。 |
| 四处解释器绑定改道：守卫与 stop_hook/commit_wrapper 统一改为探测 ≥3.10 的解析函数，import 失败走 importlib 直载兜底。 | git_guard.sh:29-45（代码注释直接引用 T3793/INC-1）。 |
| commit_wrapper 改走 mktemp 临时文件传参，辅助步骤失败非致命化（WARN+跳过，不再吞 stderr）。修复后用一次性 probe ref 复现：修前 RC=126、修后 RC=0 落真实 commit。 | commit_wrapper.sh:334-347 + 验证 commit 6614c502。 |
| 守卫上线 37 分钟内即在生产环境真实拦下一次 stash 尝试（HUMAN_GATE 记录，07-18T11:45Z）。此后到审计日志最新一条，fail-open 零复发。 | danger_op_audit.jsonl 全量 80 条逐条时间戳核对。 |
关键决策点 · 未决（背景 + 选项 + 推荐）
main_index_reconcile 的 cron 要不要恢复？
背景：它是「幽灵 staged 删除」的自动回收器，但 cron 自 06-22 因 BUG-016 过热连带 PAUSED，清理者停了 26 天而制造漂移的 Stop hook 还在跑（事故 A 的直接温床）。代码前置修复（避让检测改成通用负载阀门）已落地，但 cron 行实测仍 PAUSED。
选项：恢复（前置=HL-1 量化任务产出，或至少一次观察窗口验证新负载阀门生效）/ 维持暂停。
推荐：先跑一次观察窗口验证新阀门，再恢复 cron；两个动作都轻量，挂波次 3 观测族同批。
stash@{0} 备份删除还是归档？
背景：557 文件的恢复备份在取证时仍持有。取证报告意见是「待用户确认无需再取证后删除」；至今未找到用户对此的逐字裁定。
选项：转 tag 长期归档后删 stash（保审计链）/ 直接删（恢复已验证零残留）/ 继续持有。
推荐：转 tag 归档后删除：成本一条命令，消除「工作树里一直躺着一颗全仓 WIP 快照」的误触面。
T3793 任务单要不要关？
背景：其描述的技术修复（解释器墙）已在 BUG_TRACKER 标记 FIXED 且回归全绿，但 todo 系统里这条实测仍是 pending。这是「代码说 FIXED、状态面说 pending」的状态面分叉实例。
选项：关单（技术面已闭环）/ 保留（等 GIT-4 ②③ 残差清完再关）。
推荐：关单并新开一条挂 GIT-4 ②③：让任务状态面与代码修复面对齐，残差单独追踪。
当前状态
三条 bug 全部 FIXED 且回归全绿；守卫对 stash 家族已有生产环境真实拦截记录；git_safety.md 完成事故驱动立法。仍开着的口子：三份危险操作平行清单（候选面预过滤 / tier 判定 / fail-closed 兜底）需手工同步的结构性风险未消除（GIT-2，本次 stash 是三处手工补齐的）；「干净基线测试」仍缺 sanctioned 工具化配方（GIT-3，目前只有文档层提示）；仓库级裸 python3 清扫与 phase_runtime 惰性化未开工（GIT-4 ②③）。
遗留事项
- GIT-2 三份平行清单结构性收敛（方案未设计）
- GIT-3 干净基线正路配方（如 scratch_baseline.sh 走 git worktree add --detach）
- GIT-4 ②③ 裸 python3 清扫 + phase_runtime 顶层 import 惰性化
- reconcile cron 恢复（待裁定，见决策台账）
- stash@{0} 去留（待裁定）
- T3793 关单（待裁定）
provenance：contexts/survey_sessions/git_tracking_anomaly_forensics_20260718_manual.md tools/git/BUG_TRACKER.md（BUG-021/022/023） adhoc_jobs/context_infra_migration_20260709/design/OPEN_PROBLEMS.md（GIT 族） rules/git_safety.md §1/§1.1
悬案三：设计哲学提炼（全量 campaign） 提炼已交付 · 落地半程空转
背景：它为什么成为问题
2026-07-16，用户下达 DPD-01/DPD-02 需求：对 context-infra 全部设计哲学做一次全量且完整的提炼。追溯创始至今全部 session（CC + Codex），覆盖 Base Tooling 14 域与已建全部系统，用确定层与语义层驱动的方式多维度提炼成总领性哲学文档；并把它设计成类比 Observation/Refactor 的每日/每周常驻运行机制。
语料窗口是 2026-03-05 至 2026-07-15 的 60,363 个用户轮。全部 campaign 活动发生在一个长驻协调 session 内，17 个分维综合席都是它派发的 clean sub-agent。
在优化什么
七阶段管线全部走完：机械枚举 60,363 用户轮 → 两版分类器（v1 因召回灾难被 Fable 亲自否决重做，v2 污染率 1.8%）→ 方法论 v1（五路模型对抗批评定稿）→ 917 个 chunk 全量两遍 seed-blind 提取 → 汇聚 5,358 条 observation、584 簇 → 17 席分维综合 → clean Fable 亲写总纲 → 常驻管线三脚本降级试跑通过。
三份核心产出：
总纲（601 行 v1.0）：七条元原则 MP1–MP7（生成根是 MP1 信任条件公理：任务目标清晰且 context 不饱和时，模型产出完全可以信任）、十五条设计时刻决策协议 C1–C15、十六维摘要、十二条冲突解决优先级。引文机械核验 94–100%。
北极星对账：对 rules/HARNESS_NORTH_STAR.md 的 32 条分解项逐条判词（confirmed/revised/new/drift_suspect），30/32 anchored，加 9 条新候选原则。
十二题裁决包：把提炼中发现的七条钦定张力与约二十条维度移交项压缩成十二道待用户裁决的题，每题附推荐答案。
关键决策点 · 已决（决了什么 + 依据）
| 已决 | 依据 |
|---|---|
| 方法论 v1 定稿：五路深思模型（Sol Max/Sol Pro/GLM/Kimi/DeepSeek）独立 critique 后，Fable 亲判 50 条处置 + 4 项席位间分歧裁定。 | campaign STATE.md:22 + V1_DISPOSAL_TABLE.md。 |
| P1 分类精度退回重做：v1 census 把协调者原话误判为派发的 worker（召回灾难），被 Fable 否决重派 v2，8/8 锚点回归通过。 | campaign STATE.md:24-26。 |
| P4/P5 执行席位钦定：综合层必须派 clean Fable sub-agent 或 5.6 SOL 模型，不用采集工人档、不在长 session 内综合（用户 07-16 23:55 逐字追加指令的直接后果）。 | campaign STATE.md:55 起。 |
| campaign 收官状态 CLOSED-BOUNDED：P0-P6 全部完成，claim 上限 bounded，挂用户动作未回填。 | campaign STATE.md:68。 |
关键决策点 · 未决（背景 + 选项 + 推荐）
十二题裁决包（Q1–Q12）全部未裁
背景：全部十二题截至 07-19 无任何裁决证据（git log / git status / 文件 mtime 三类机械信号一致指向零回填）。每题附推荐答案，用户可整包回复「按推荐」或逐题改判。呈报建议：只看一题看 Q1（Harness 的核心该说是语义引导、创建确定层、还是确定性总领驱动，三处用户原话对象不同；推荐=分层读法：方向判断在语义层、运行推进在确定层、「总领驱动」指前者服务后者的耦合方式）；其次 Q8（注入该全量还是少给，用户自己指出过这两句话逻辑冲突；推荐=按对象分层：恒定注入集=道层原则+全量资源目录小而稳定，术层正文按 role/phase 精准披露）。Q8 直接对应本次复盘的渐进式披露主题。
选项：整包「按推荐」/ 逐题改判 / 先裁 Q1+Q2+Q8 三题高杠杆项。
推荐：先裁 Q1 与 Q8：Q1 定核心措辞，Q8 直接决定正在运行的注入面形态；其余十题可整包按推荐。
哲学产物落地三动作何时执行？
背景：总纲从未 commit 进 git（git log 该文件为空）；北极星对账的 30/32 anchored 与 9 条新候选零条写回（北极星文件自 07-08 后零改动）；常驻管线三行 cron（每日提取/每周综合/每月健康）代码已具备、降级试跑全绿，但未装。
选项：三动作是明确执行项：commit + 裁决回填北极星 + crontab 手装三行。
推荐：裁决包一并在本页决策台账收口后执行：先裁 12 题（决定写回什么），再 commit 与装 cron。
渐进式披露与 Clean Context 要不要升格为独立元原则？（候选 Q13，本次复盘新发现）
背景：两个概念是全部语料里证据最扎实的设计直觉（渐进式披露 42 次命中、Clean Context 60 次命中，均标最高置信档），但总纲的七条元原则遴选标准是「跨维收敛」，它们主要集中在单一维度内部，被系统性并入维度摘要 bullet，从未获得独立编号，总纲也从未正面论证为何降级。这是十二题之外、本次复盘新发现的真实缺口，不在 Q1–Q12 任何一题的题面里。
选项：升格为 MP8/MP9（承认其独立哲学支柱地位）/ 维持现状（作为支撑性机制）/ 并入 Q8 一起裁。
推荐：并入 Q8 裁决时一并表态：两者是注入维度上同一个交叉点的两面，分开裁容易再次错配。
当前状态
从「提炼」到「总纲文档存在」这半程走完且质量把关严格；从「总纲文档」到「实际改变系统设计决策」这半程完全空转。总纲目前只是 adhoc_jobs 下一份高质量但未接线的静态文档：任何设计任务目前都不会自动看到它，除非 agent 主动去找。pipeline 三脚本已具备常驻能力，但 DPD-02 要求的「每日、每周持续运行」机制未激活。
本次复盘 campaign 把这条断裂本身列为元发现①：「下游状态/产物滞后于上游真实变更」是本仓库反复出现的结构性模式，哲学未落地只是它在治理层的一个实例。
遗留事项
- 12 题裁决（挂用户，推荐答案齐备）
- 总纲 commit 进 git
- 北极星 30/32 + N1-N9 回写（依赖裁决结果）
- 常驻管线 cron 三行手装
- 候选 Q13（渐进式披露/Clean Context 升格）随 Q8 一并表态
- 总纲设计入口卡补「要不要分层披露/要不要 clean isolation」检索行（升格若通过）
provenance：adhoc_jobs/design_philosophy_distillation_20260716/synthesis/HARNESS_DESIGN_PHILOSOPHY.md adhoc_jobs/design_philosophy_distillation_20260716/synthesis/USER_ADJUDICATION_QUESTIONS.md adhoc_jobs/design_philosophy_distillation_20260716/synthesis/NORTH_STAR_DELTA.md adhoc_jobs/design_philosophy_distillation_20260716/STATE.md
悬案四：Codex→Kimi 额度切换 + provider 文档唯一真源 功能全自动 · 文档 SSOT 落地中
背景：它为什么成为问题
这个悬案是交织在一起的两件事。
功能面：Codex 额度耗尽后，系统能否自动切到 Kimi 继续干活。这是 provider 降级链的核心场景。
架构面：07-18 晚用户审计 provider 相关文档时发现「过多不完全信息的召回」：同一份信息（默认链档位、Kimi 双轨规则、Codex context 数值）被复制到 5–18 个文件，且副本已实测漂移（真源 11 档链，三份派生文档停在 9 档零 Cursor；真源 Codex 300K，两份文档仍写 272K）。用户判定这暴露的是唯一真源（SSOT）缺失的架构问题，并给了三层披露模型：普通使用者只要知道怎么用（stable 的引导）、配置开发者看详细配置、处理 provider 底层逻辑时才读 conf 与官网。
在优化什么
功能现状（逐环节核实）：额度耗尽识别自动（router 用 rate limit 正则解析返回文本）；failover 自动级联，但 Kimi 在 11 档链里排第 6/7 位，GLM 和 Cursor 在其前（用户 07-18 明确指示「Kimi 稳定性降级，挪到 GLM 之后」）；Kimi 内部双轨已修正：k3 = 独立 1M context 模型，kimi-for-coding = K2.7 Coding 线（256K），两者不是同一物，「别名自动滚动」的说法已被用户当场更正撤回；恢复检测半自动（被动记账，真实流量触发才推进）；健康巡检 cron 已装（raw 模式零生成 token，每 2 天跑一次，7/7 目标全部 ok）；完整链真实派发验证保持手动（用户明确要求严禁任何 System Prompt、尽量减频）。
结论：Codex→Kimi 的额度切换是全自动级联的一部分，无需人工介入；「链路是否健康」的主动巡检已 cron 化；「全链真实验证」是手动触发。
架构面：针对文档漂移，产出了三候选设计：方案 A（生成器读 providers.conf 渲染 md 段，注入各文件 GENERATED 区 + gate diff 拦漂移）、方案 B（Diátaxis include 工具链）、方案 C（纯手工去重换指针）。推荐 A：它是唯一同时满足「贴用户哲学 + 根治漂移 + 不引入重工具链」的方案，也是单一文件原则在正式治理文档的首次真落地。
关键决策点 · 已决（决了什么 + 依据）
| 已决 | 依据 |
|---|---|
| 链序：Kimi 排在 GLM 与 Cursor 之后（用户 07-18 明确指示降级）。 | providers.conf 头部注释链定义 + provider job README 决策 D1/D2。 |
| Kimi 双轨命名口径：k3 = 1M 独立模型 ID；kimi-for-coding = K2.7/256K Coding 线，不自动滚动升级。 | providers.conf 条件默认注释块 + live 验证。 |
| Codex context 上限 272K → 300K；MiniMax 整体清除；ZAI 计费口径更正为订阅制。 | provider job README 决策 D4/D5/D6。 |
| 文档 SSOT 选方案 A（生成器 + GENERATED 区 + sync gate），主 agent 按用户 SSOT+渐进披露哲学裁定，不重开 A/B/C。 | DOC_ARCHITECTURE_REDESIGN.md + D1_FINAL.md 裁决表。 |
| S1 首切片 07-19 已落地：provider_info.py（llm info 三档查询）+ CLAUDE/AGENTS 双 GENERATED 区 + sync gate 脚本，均实跑 PASS；gate 还当场抓到 PROVIDERS.md:90 一处真漂移（已修）。 | campaign STATE.md 行 33/36 + llm info 三档实跑记录。 |
关键决策点 · 未决（背景 + 选项 + 推荐）
CALLING_MODELS.md 等召回污染文件群何时收敛？
背景：用户逐字点名「calling models 完全不需要作为一个单独的文件存在」。S1 已把一跳用法搬进 GENERATED 区，但 CALLING_MODELS.md 本体（15.5KB，自称「第一站」）与 LLM_PROVIDER_GUIDE.md 等多真源文件仍在，收敛步骤（S3/S4）处于 armed 未接线状态。
选项：按 D1 处置表执行：CALLING_MODELS 归档（错误表并入 PROVIDER_KNOWN_ISSUES）、GUIDE 归并、PROVIDERS 瘦身、RUNTIME_MAP 升为唯一枢纽。
推荐：下一个工作窗执行 S3/S4：这是用户逐字要求的直接对象，不宜停在 armed 无期。
CLAUDE.md 与 AGENTS.md 非 provider 段分叉保哪份？
背景：两文件 9 个节标题完全相同但全文 36 行差异。provider 段的漂移已由 GENERATED 双注入点构造性消除（「哪份为准」问题消失），但非 provider 段是内容分歧不是滞后：sub-agent 并行数量 CLAUDE 写「10-20 个」vs AGENTS 写「最多 100 个」；phase/skill/trace 段 AGENTS 保留完整三段、CLAUDE 已精简为一行。只有用户知对错。
选项：推荐答案：并行数保 AGENTS「最多 100」（上限更高不误导）；phase/skill/trace 保 AGENTS 三段（信息量更大）。
推荐：按上述答案对齐；属内容裁定，挂用户一票。
gate enforcement 何时接线？
背景：sync gate 脚本已实跑且工作正常（当场抓到真漂移），但接线（pre-commit 阻断 + fs_patrol 日检）处于 armed 状态缓装，理由是夜间不动可阻断全量 commit 的面。缓装期间漂移无人拦。
选项：按 S1_ARMED_WIRING.md 两步接线（pre-commit 段 + fs_patrol 委托）。
推荐：下一个工作窗接线：gate 无消费者静默失能是已知失败模式，缓装不宜跨周。
当前状态
功能面全自动且经 07-19 实跑验证；文档面 S1 安全面已落地（查询工具 + GENERATED 区 + gate 脚本），用户 21:15 的三层披露原话已进入候选 A 设计。剩余是收敛与接线两段 armed 工作。
对悬案本身的元回答（用户晨间曾问「为什么会有 OpenCode 额度等待刷新的说法」）：额度是 provider scope 的，不是传输通道的；同一订阅经 wrapper 端点与 OpenCode 通道同时可用，所以「OpenCode 额度尽」的准确含义是「该 scope 正在冷却，且恰好多个走 OpenCode 传输的 tier 同时命中」，标签把 scope 冷却投影到了通道上。
遗留事项
- S3/S4 文件群收敛（armed，推荐下一工作窗）
- gate enforcement 接线（armed 两步）
- CLAUDE/AGENTS 非 provider 段分叉对齐（挂用户，带推荐答案）
- RUNTIME_MAP 升唯一枢纽的收尾（D1 裁定，留用户一票可改回）
provenance：adhoc_jobs/context_infra_base_tooling_buildout_20260615/provider_chain_optimization_20260718/design/DOC_ARCHITECTURE_REDESIGN.md adhoc_jobs/context_infra_base_tooling_buildout_20260615/reflection_decisions_visibility_20260719/design/D1_FINAL.md tools/llm_runtime/providers.conf tools/llm_runtime/provider_info.py
dashboard data: generated 2026-07-19T14:05:10.073Z from 5 SSOT files