考古与审计档案
四悬案完整故事 + 134-session 审计 + 既有信件逐字摘录
本页是「考古与审计档案」：四个用户 2026-07-19 点名的悬案完整故事（背景→在优化什么→已决+依据→未决+选项+推荐→当前状态→遗留）+ 134-session 完成度审计档案 + 两封既有信件的逐字摘录。读完不需要打开任何仓内文件。
悬案一：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 观测运维族顺手清，不阻塞任何波次。
当前状态（as of 2026-07-19）
已裁决未实施 主体已闭环（timeout 30s + deliver-then-persist + 孤儿守卫一层）；残差：HL-1 ChatGPT.app 量化未做、HL-2 第二层兜底 OPEN、HL-5 对策 1-4 待对应波次。07-19 新活案例：全局 cursor 兜底劫持 2 个并发 session（已 decline 解绑，根修未做）。
双轨：主体（超时修复+孤儿守卫一层）已闭环并在跑，徽章「已裁决未实施」只针对残差层（HL-1 量化/HL-2 二层兜底/HL-5 对策/cursor 根修）——非整案未实施。
现在状态取值：OPEN_PROBLEMS HL-1/HL-2/HL-5 状态行 + 文末 append（07-19 13:5x/14:2x 两段）（adhoc_jobs/context_infra_migration_20260709/design/OPEN_PROBLEMS.md，as of 2026-07-19）
遗留事项
- 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 恢复后，观察窗验证要不要收口？（已恢复 live，非「要不要恢复」）
背景：它是「幽灵 staged 删除」的自动回收器，cron 曾自 06-22 因 BUG-016 过热连带 PAUSED。代码前置修复（避让检测改通用负载阀门）落地后，cron 已于 07-19 恢复 live（config/CRONTAB.md 45 4 * * * 实测在场），当日 10515 文件幻影删除即由它修复、load-yield 门实测正确 skip。所以现状不是「要不要恢复」，而是新阀门已在真实负载下跑了一轮，剩一个「确认观察窗结论、把这条从待办清掉」的收尾。
选项：确认观察窗一轮生效即关此项 / 若要更长观察窗再挂几日。
推荐：已恢复且实测生效——确认观察窗一轮结论即可关；无需再「先跑观察窗再恢复」（那是过时口径）。
stash@{0} 备份删除还是归档？
背景：557 文件的恢复备份在取证时仍持有。取证报告意见是「待用户确认无需再取证后删除」；至今未找到用户对此的逐字裁定。
选项：转 tag 长期归档后删 stash（保审计链）/ 直接删（恢复已验证零残留）/ 继续持有。
推荐：转 tag 归档后删除：成本一条命令，消除「工作树里一直躺着一颗全仓 WIP 快照」的误触面。
T3793 任务单要不要关？
背景：其描述的技术修复（解释器墙）已在 BUG_TRACKER 标记 FIXED 且回归全绿，但 todo 系统里这条实测仍是 pending。这是「代码说 FIXED、状态面说 pending」的状态面分叉实例。
选项：关单（技术面已闭环）/ 保留（等 GIT-4 ②③ 残差清完再关）。
推荐：关单并新开一条挂 GIT-4 ②③：让任务状态面与代码修复面对齐，残差单独追踪。
当前状态（as of 2026-07-19）
已在跑 BUG-021/022/023 全部 FIXED；GIT-1 reconcile cron 已于 07-19 恢复 live（当日 10515 文件幻影删除已修，load-yield 门实测正确 skip）。结构债 GIT-2（三处清单收敛）、GIT-3（干净基线工具化）、GIT-4 ②③ 仍 OPEN。
GIT-1 cron 本身已在跑；结构债子项（GIT-2/GIT-3/GIT-4②③）仍为已裁决未实施/OPEN，卡片内需分述，不可整卡笼统标一个徽章。
07-19 快照过期值已纠正：collect 快照未反映 GIT-1 cron 当日恢复的事实，本字段使用 OPEN_PROBLEMS.md 现值。
现在状态取值：OPEN_PROBLEMS GIT 族各状态行 + tools/git/BUG_TRACKER.md BUG-021/022/023（adhoc_jobs/context_infra_migration_20260709/design/OPEN_PROBLEMS.md，as of 2026-07-19）
遗留事项
- GIT-2 三份平行清单结构性收敛（方案未设计）
- GIT-3 干净基线正路配方（如 scratch_baseline.sh 走 git worktree add --detach）
- GIT-4 ②③ 裸 python3 清扫 + phase_runtime 顶层 import 惰性化
- reconcile cron 已于 07-19 恢复 live（剩观察窗收口，见决策台账 GIT-1）
- 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（每日提取/每周综合/每月健康）07-20 已装 live（用户全面授权后，config/CRONTAB.md 在场）——三动作里 cron 已解，剩 commit 与回写两动作。
选项：三动作是明确执行项：commit + 裁决回填北极星 + crontab 手装三行。
推荐：裁决包一并在本页决策台账收口后执行：先裁 12 题（决定写回什么），再 commit 与装 cron。
渐进式披露与 Clean Context 要不要升格为独立元原则？（候选 Q13，本次复盘新发现）
背景：两个概念是全部语料里证据最扎实的设计直觉（渐进式披露 42 次命中、Clean Context 60 次命中，均标最高置信档），但总纲的七条元原则遴选标准是「跨维收敛」，它们主要集中在单一维度内部，被系统性并入维度摘要 bullet，从未获得独立编号，总纲也从未正面论证为何降级。这是十二题之外、本次复盘新发现的真实缺口，不在 Q1–Q12 任何一题的题面里。
选项：升格为 MP8/MP9（承认其独立哲学支柱地位）/ 维持现状（作为支撑性机制）/ 并入 Q8 一起裁。
推荐：并入 Q8 裁决时一并表态：两者是注入维度上同一个交叉点的两面，分开裁容易再次错配。
当前状态（as of 2026-07-19）
已裁决未实施 四层分开裁决：内容提取=完成且经复算（60,363 轮→七元原则，数字零虚报）；真源整合=live 零字节（rules/ 零引用，属设计内人门，停在 12 题包前）；pipeline=PARTIAL（脚本绿、crontab 零哲学行）；真实自动运行=零次。12 题（先 Q1）+ Q13 候选=置顶决策 NOW-1/NOW-2。
campaign 07-17 自宣 CLOSED-BOUNDED 的次日，仍被列为悬案——这个断层正是本站存在的理由之一
现在状态取值：审计 §七（四层逐条）+ A3 dossier（contexts/survey_sessions/context_infra_recent_refactor_session_completion_audit_20260719_manual.md，as of 2026-07-19）
遗留事项
- 12 题裁决（挂用户，推荐答案齐备）
- 总纲 commit 进 git
- 北极星 30/32 + N1-N9 回写（依赖裁决结果）
- 常驻管线 cron 三行——07-20 已装 live（不再是待办）
- 候选 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 无消费者静默失能是已知失败模式，缓装不宜跨周。
当前状态（as of 2026-07-19）
已裁决未实施 11-tier 链 live；七层裁决：配置/路由可达=完成，真实命中=部分 provider 有实录，fallback=PARTIAL（07-17 当日 26 次替代、Kimi 接盘 18 次，receipts 侧 is_substitute 字段不存在——双账本未统一），quota-health=PARTIAL，cron=PARTIAL（2/7 假阴性），human gate 3 条挂用户；D1 SSOT 设计 armed·未实施。
双轨：11-tier 降级链本身已 live 在跑（配置/路由/S1 首切片已落地），徽章「已裁决未实施」只针对 D1 SSOT 文档收敛 armed 段 + fallback 双账本统一等残差——非整案未实施。
现在状态取值：审计 §八 + A4 dossier + D1_FINAL.md（contexts/survey_sessions/context_infra_recent_refactor_session_completion_audit_20260719_manual.md，as of 2026-07-19）
遗留事项
- 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
134-session 完成度审计档案
内容与诊断层的工作绝大多数真实完成且数字经得起复算，断层集中在『机制装上了但没有持续跑』这一层
审计 §一（contexts/survey_sessions/context_infra_recent_refactor_session_completion_audit_20260719_manual.md）
📄 审计报告全文 →（逐字真源投影，仅隐私清洗）
五问五答（一句话版）
- Q1 重构前最后一次优化是哪个 session，分析还是改了 live？
Codex 019f3ef0（07-08），改 live 非分析，约 70 commits。 审计 §四 - Q2 状态绘图链负责链是什么，图后更新有没有被吸收？
d4ff966c→c736c471→170dbcc4；07-13 全量复查后判据未机制化，冻结时点 25/25 图组按机械判据全部再次漂移。 审计 §五 - Q3 bug session 哪些四层全通，哪些只到某一层？
四层（诊断/修复/回归测试/真实运行）全通 4 例：regulator 解析、模型 IO、stash INC-1、Git 追踪 rc=126。典型半通案例：session_inventory cron 14 天零运行。 审计 §六 - Q4 哲学提取做出了什么，整合与管线到哪一层？
四层分开裁决——详见本页悬案三卡片。 （另见 悬案三：设计哲学提炼（全量 campaign）） 审计 §七 - Q5 provider 调整改了什么，七层各到哪？
七层裁决——详见本页悬案四卡片。 （另见 悬案四：Codex→Kimi 额度切换 + provider 文档唯一真源） 审计 §八
口径盒（防误读）
- 134 身份全枚举
- 进分母 106
- UNVERIFIABLE 45 ≠ 失败（有收口文档与 git 血统，未逐项独立核验）
- 义务级聚合计数不作机械承诺
UNVERIFIABLE（45）不等于失败：绝大多数是 buildout/测试系统各轮与信息收集链的会话，它们有收口文档与 git 血统，但本轮审计没有逐项独立核验，按纪律不给完成认证（审计 §二）
取证债（6 条，不展开）
- 019f3ef0 的 sandbox 指令去向
- 45 个 UNVERIFIABLE 会话（即 claim-only 全集）
- Codex Pro 服务器端模型身份仅记忆自报
- receipts 台账 07-12 才开始（此前会话少一路证据）
- P2 抽取层漏记一例已被交叉核验抓出（8b7976ff L249，P6 复核同类）
- INC-1 数字口径（记忆 557=被扫数、证据 470=恢复数，两个度量）
provenance：contexts/survey_sessions/context_infra_recent_refactor_session_completion_audit_20260719_manual.md
既有信件逐字摘录
06-10《致等天黑》是全仓十路盘点后的总信；07-12 是 32 天后针对『为什么难以落地』的专题复核信。两版并列上站、各任其职、互不取代；07-19 审计是同一谱系的第三时点（最新证据层）。
2026-06-10 · 致仓库的信（全仓盘点）
最重要的判断只有一句话：这套系统已经活了，但它至今只消化过它自己；按你自己建立的理论，一个只以自身为负载的系统拿不到真正的误差信号，而你的梦想项目，恰好就是它缺的那个外部世界。
我把这些日期排在一起，意思你看得出来：阵地在高速建设，而阵地名义上要保卫的东西，全部在城墙外面过冬。
所以对这条链的总裁定是：六环第一次全部以机制形态存在，并且从 06-09 起真的会自动运转，这是这个仓库建立以来的最大单点进展；它欠的东西不是第七个环节，是流量。
每一件单看都小，合起来是同一个病：只生不灭。
32 天后的专题复核见 07-12 信｜全文（仓库内）：adhoc_jobs/letter_to_user_20260610/LETTER.md
2026-07-12 · 复核信（为什么难以落地）
Context-infra 的核心问题不是设计烂，而是「最后一步综合征」。你的系统在设计层面是完整的（14 域 448 条需求、237 条已 landed），在基础设施层面也是活的（37 条 cron、54,615 条 receipt、git 自动化正常运行）。但这些能力停在了「造好并注册」的状态，没有完成从「机制存在」到「默认路径上自动产生效果」的最后接线。
一句话版本：你建了一座结构完整的工厂，装了生产线，贴了操作手册，但多数机器的电源线没接上车间总开关。少数接上的（cron、git、todo）真的在转。
06-08 的审计已经给了最精确的诊断：三重绑定。40 天后复查，绑定依然成立。
绑定 1：真实落地没有执行者能闭合的完成信号。
绑定 2：权限边界没被跨。
绑定 3：落地努力递归生产更多机器。
问题在于：系统擅长诊断自己的问题，但诊断之后的行动是再造一个更精确的诊断机器，而不是接线让东西跑起来。
上一时点的全仓盘点见 06-10 信；最新证据层见 07-19 审计档案卡｜全文（仓库内）：adhoc_jobs/letter_to_user_20260610/followup_20260712_context_infra_audit/LETTER.md
dashboard data: generated 2026-07-20T08:24:39.151Z from 5 SSOT files