context-infra 检查与复盘候选版 · 全内容自包含呈现 · 生成于 2026-07-19 14:05 UTC

执行方案

D1–D4 四个设计方向：问题、方案、落地、下一步

四个设计方向是本次复盘 campaign 的设计轮产出：每个方向先由两家外部模型独立设计（Grok/Kimi/Codex/GLM/DeepSeek 五家真实参与），再由收口 agent 裁成一份终稿。下面的呈现是自包含的：问题背景、方案要点、已落地部分、下一步，全部直接展开。

D1 · Provider 文档唯一真源（SSOT）+ 渐进式披露 S1 已落地 · S3/S4 armed 待点火

要解决的问题（背景）

provider 信息（默认链、Kimi 双轨、Codex context 数值）被复制到 18 份文件且已实测漂移：真源 11 档链三份文档停在 9 档、真源 300K 两处写 272K。用户要求：消灭 CALLING_MODELS 这类文件；CLAUDE/AGENTS 稳定不常改、易变部分自动同步；新增 provider 必须能被强制检测同步；按三层渐进披露组织（使用者/配置开发者/底层处理者各看各的层）。

方案要点

  1. 层 0 真源：providers.conf 不动，数值的唯一住所。
  2. 层 1 生成器：provider_docs_render.py 读 conf 渲染 provider 一览段，注入 CLAUDE.md/AGENTS.md 的 GENERATED 区（手写区只留稳定陈述）。这是单一文件原则在正式治理文档的首次真落地。
  3. 层 2 分级入口：casual 层=CLAUDE/AGENTS 各一个 ≤15 行 GENERATED 紧凑表（只放 tier 名不放数值）+一行 llm info 指针；config 层=唯一枢纽 RUNTIME_MAP.md + llm info <tier> 三档查询；internals 层=conf 本体+官网链接，按需读零注入。
  4. 层 3 防漂移 gate：check_provider_docs_sync.py 五条机械判据（render-diff/链指纹/旧值 lint/查询 roundtrip/禁第二真源），接 pre-commit 阻断+fs_patrol 日检两个已有消费者的触发面。
  5. 验收判据（Fable 简单任务零加载）：简单任务 transcript 无 Read/Grep 命中任何 provider 文档；问「kimi 的 context 和额度窗口」必须调 llm info 才能答，注入面找不到答案。

已落地部分

S1 首切片 07-19 落地：provider_info.py + llm info 三档实跑 PASS；CLAUDE/AGENTS 双 GENERATED 区 live 且指纹与 STATE.md 一致；sync gate 实跑并当场抓到 PROVIDERS.md:90 一处真漂移（已修）。

下一步

关键裁定记录

provenance：adhoc_jobs/context_infra_base_tooling_buildout_20260615/reflection_decisions_visibility_20260719/design/D1_FINAL.md

D2 · 新根独立 OpenCode 栈（新旧物理隔离） 设计+ARMED PACKAGE 就绪 · 挂波次 1 点火

要解决的问题（背景）

重构要求新旧 context-infra 状态物理隔离，但现在的 hook 等工具因全局环境问题很难彻底隔离（F-1 悬空指针污染、旧根全局 hook 对新根 session 的波及都是实证）。用户的方案：在新根拉一份独立版本的 OpenCode（开源，可直接改其 hook 和工具），针对该文件夹建特定 cron，以此解决旧根面临的 Git 和 stop hook 审计问题。

方案要点

  1. 形态：混合，首期不 fork core。新根内放校验和锁定（SHA256 pin）的 OpenCode 1.17.18 独立发行物+独立 config/XDG/DB/plugin+per-root launcher，外层用 macOS sandbox-exec 建 OS 级写围栏。只有 held-out 负样本证明 plugin API 承接不了某条必要不变量时，才把最小 patch 升入 fork。
  2. 决定性机制：OS 沙箱把「彻底隔离」从事后核验变成运行时 OS 拒绝，这正是 #ISO-FENCE 单元的诉求（物理优先于纪律；口头禁令拦不住，GIT-3 已实证）。
  3. Git/stop 审计（关键裁定）：沿用新根 gateway+session-ref 语义，但须在 gateway 增 capture-session op：消费 plugin 生成的精确 touched-path manifest→private index 建 tree→更新 refs/sessions/oc-<sid>，全程不动 HEAD/main。旧 parity 曾因从脏 index 捕获卷入 549/98 文件，manifest 是硬要求。OpenCode 的 Stop 只做三短动作（封口 manifest/append request/立即返回），drain 在独立进程消费：HL-2 的孤儿持锁结构在构造上不存在。
  4. 隔离面矩阵：新根独享一切可变状态面（发行物/config/DB/receipts/cron/refs），共享只读的只有模型订阅/secret broker/OS git shell python。

已落地部分

设计终稿+ARMED PACKAGE（命令级五段：前置核查→执行序→每步验收→新根入库→回滚）已就绪。三项现场核实把 provisional 降为确定：隔离面环境变量真实存在（strings 实证）、sandbox-exec 在场、新根当前零 OpenCode 脚手架。今晚零执行，未下载/安装/启动任何 OpenCode。

下一步

关键裁定记录

provenance：adhoc_jobs/context_infra_base_tooling_buildout_20260615/reflection_decisions_visibility_20260719/design/D2_FINAL.md

D3 · State 机制（底层变更机械反馈顶层） v0 首切片已 live · 五面真源待接

要解决的问题（背景）

用户判断：「当底层 Provider 更新后，这种更新必须能反馈到顶层架构中」。实证链坐实了缺口：07-18 provider 链大改后，四处高可见顶层文件（SYSTEM_MAP、官方架构图、ROLLUP 运维汇总、cli_agent DOCS_MAP）全部未同步，唯一同步的是 tools/INDEX.md。诊断结论：表格/index 类资产跟得上、图形/叙事类资产必过时，新鲜度由生成方式决定而非内容重要性。

方案要点

  1. 机制形态：一个确定层探针每天扫一组可解析真源，把能机械派生的内容重生成到仓根独立文件 STATE.md 的 GENERATED 区（SYSTEM_MAP 只放一行指针）。表格类由探针直接确定性重生成；图形/叙事类只盖 as-of 指纹戳，不一致时经 session_dispatch 拉起 Clean Context refresh worker 重画。
  2. 七张表：provider 链 tier/14 域状态 rollup/门计数/cron 面/活跃决策（带 languishing 列）/过时资产+状态面分叉（代码:FIXED vs todo:pending 类）/真源新鲜度告警。
  3. 完成判定外移：探针复跑「真源指纹=视图 as-of」归零判定，零 LLM 判完成。核心闭环不依赖任何 LLM 维持新鲜，机制不会「忘记」。
  4. 八条守卫：语义内容哈希（注释改动不触发假过时）/重派生比哈希防手改/真源注册表自身被指纹/as-of 戳强制/禁「视图的视图」恰好两层/mismatch 进 scoreboard 停跑被抓/测试向量挡生成器逻辑错误/max_staleness_days 标真源停更。
  5. 决策台账贯通：OPEN_PROBLEMS 作为真源，决策关闭→状态行变→指纹变→探针 flag→重生成，全程无人工同步。这是「决策更新后同步 State 视图」的机械实现。

已落地部分

v0 首切片 07-19 落地并抽查 PASS：仓根 STATE.md（GENERATED 区+11 档链表+指纹）在位；staleness 探针实跑输出 2 个 mismatch，恰为两张故意盖旧戳的过时图（自证门生效，不是只证生成）；SYSTEM_MAP 加了一行指针；provider→顶层反馈链 live（conf 指纹→STATE.md→CLAUDE/AGENTS 三处同指纹）。

下一步

关键裁定记录

provenance：adhoc_jobs/context_infra_base_tooling_buildout_20260615/reflection_decisions_visibility_20260719/design/D3_FINAL.md STATE.md（仓根）

D4 · 决策披露站（本站所属方向） v0 已上线 · 四候选站决胜中

要解决的问题（背景）

决策点散落在各 run 报告、登记簿、session 里，每日 TODO 扫描力度不够。用户要求把决策完整呈现在网站上：各系统和 base tooling 的状态图、重构任务进展、重构的具体执行方案。v0 三页站上线后，用户新硬标准（2026-07-19）判它不合格：「不要再让我去打开任何其他文件来查看详细内容」，v0 那种只给一句话就让用户回仓翻 priority plan 的指针式呈现被点名否决。

方案要点

  1. 站点本质：三份 append-only 真源（决策台账/OPEN_PROBLEMS/波次计划）+ 状态层的只读投影。真源变更只改仓内 md，data/*.json 可删可重生，站点文案与真源冲突以仓内为准。
  2. 生成器：零依赖 Node（纯 node:fs/path，无 npm），内联 CSS、移动优先、无外部资源。fail-closed 隐私断言：命中黑名单（key/邮箱/电话/用户名绝对路径/session 原文）即构建失败。
  3. v0 已验证的机制：隐私断言真实拦截过一次路径泄漏并修复；三页 HTTP 200 上线 infra.guiming.net；95 条决策条目投影。
  4. 本候选轮：v0 的「列表行→展开拿锚→回 repo 读背景」模式被新硬标准否决后，改由四个独立建站者各建一版全量自包含候选站（你正在看的是 Kimi 版：全部背景正文上站，repo 路径只做 provenance 脚注），完成后由 Clean Context Fable 复审官比对选版或合成。
  5. 长期接线（RDV-01）：台账 open 行回访扫描器与站点重投影合并为一个每日 cron job；扫描产出候选统一走 todo intake，不建第二决策真源。

已落地部分

v0 三页（index/decisions/progress）已上线 https://infra.guiming.net（07-19 晨 CNAME 经 Cloudflare Pages 集成完成，HTTP/2 200）；decisions.json 95 条=85 台账+10 登记簿；隐私断言 fail-closed 在构建期真实拦过一次泄漏。

下一步

关键裁定记录

provenance：adhoc_jobs/context_infra_base_tooling_buildout_20260615/reflection_decisions_visibility_20260719/design/D4_FINAL.md

dashboard data: generated 2026-07-19T14:05:10.073Z from 5 SSOT files