Repository navigation
docs: .coi 优化知识旁挂——格式规格 + 施工计划 - #161
Merged
Merged
Conversation
- 产物：docs/maintainer/design/coi-optimization-knowledge-sidecar.md（**只新增这一个文件**，零改动既有正文） - 真源：/tmp/briefs/coi-raw.md（维护者 22 节原文，逐字保留、未改写） - 核验基线 = develop@origin @ 0eb1efd；全部 file:line 经 `jj file show -r develop@origin` 实核（不就地 grep） - 现场实测锚点：1872 个 ver=9 的 .ccr 产物 opt_count 全 0 + SYM 走查 tail 全 0 （写侧唯一 = regalloc.cr，且它不在 corec 清单 ⇒ SYM opt_meta 子节 = 版本化空壳载体） - 立论锚点：v7 规格「开放点 3」＋ ENT home 注记「分配决策不写回格式」与 g_opt_meta 的物理位置自相矛盾 - 不变量 #3/#4 各给一条「能证明它没被违反」的检查（强制未命中开关对拍 / 敌意载荷对拍 + 结构闸）； 全部 12 条给三件套（形式陈述 · 禁止什么 · 可机械检查的判据形状），判据默认两向 - §21「Minimal V1」按维护者当场指示「不规定什么 v1 反正你完整实现」改写为「落地顺序」 （按返工半径排序，不缩小交付面）；四条性质保留并改写为验收判据，每条配反向钉子 - §20 十三问逐条给结论（13/13 有结论，8 条带子项待裁）；待裁 12 项 · 未核实 11 项各自单独成节 - `.coi` 如何消解 V8 规格 C-10（metadata 同名不同物）：把 opt_meta 整节搬出 .ccr ⇒ 从改名问题降级为不存在问题
- 产物：docs/superpowers/plans/2026-09-23-coi-implementation.md（只新增这一个文件）
- 分工：格式规格管「格式长什么样」· 本计划管「怎么把它做出来」；两份互不覆盖（§七 防第二份权威）
- 工序 S1..S8（容器/序列化 → 读写器 → 身份与失效 → 管线接线 → 索引 → 目标谓词 → 合并 → 安全面），
每步给入口文件/函数 + 完成判据；**顺序 ≠ 分期**（维护者明示不要 V1；本计划不写最小版）
- 与 V8 的先后（§二）= 本计划最核心的一节，判定依据三条 V8 实读事实：
· V8 的 EntityRef 正是 .coi §20 Q3 问的「稳定身份」，且 V8 自己**编码未定**（待裁新-4）
· V8 下 NOD id 失去垄断（D1）⇒ 用文件序坐标作主锚可能不再最优
⇒ 结论：分界线不在「身份 vs 非身份」而在「**框架 vs 取值**」——
S1 把 source_ref 做成带标签变体 ⇒ 身份框架可先行、取值后挂（V8 冻结后只加一个 kind 值，零重做）
可先行 7/8 步；唯一**真串行点** = g_opt_meta 搬迁（A9），理由 = 搬迁动 .ccr 字节而 V8 落地
必然作废 .ccr canary 四条（爆炸半径 §4 #1）⇒ 先搬会让 .ccr 判据重锁做两遍
- 返工风险 R1..R7，逐条给触发条件/重做面/降险手法；R1 可完全消除（靠带标签变体）、R3 无法消除（靠薄接线压面）
- 判据 19 条（J1..J19）全部可跑（rc / sha256 / cmp / 套件），零「人工检查」；含 7 条判据纪律
（其中「本批一律不写 .ccr 字节值」= 因 V8 必然作废它们 ⇒ 判据在 V8 前后都成立）
- 本批不做：原文 §4 十三项 + §19 第 10/11/12 条逐条转显式声明 + 越界判据
- §三.1 新增**口径表**（匹配式 · 单位 · 文件范围 三列），六种数法并列： 行数 全仓 97 / 后端三轴 67 · 读侧表达式 按行 18 / 按次数 19 · 写侧 26 行 · 三档行数和 71 - **更正本文两处**：① 先前报的「全仓 93 行」是**本文的加法错误**（自打印逐档数之和 = 97），非文件范围差异； ② 「71」可复现，但数法是「regalloc 54 + instr 7 + ent_kernel 10 的**行数和**」，**不叫「读侧表达式」** （按行读侧 = 18）；且 ent_kernel 那 10 行**全是注释**（该档读/写表达式均 = 0） - 新增 ⭐「关键现状一屏」（K-1/K-2/K-3）：opt_meta 空壳载体（写明**两条独立证据**：写侧清单 + 1872/1872 产物实测）、 教义与物理位置的自相矛盾 + v7 开放点 3、`.coi` 零对应物 —— 放显眼处 - U1 条改为「已解决（2026-09-23）」并保留澄清内容；附录 A 三态计数补数法 - ⚠ U9 的标注**保留**（把 `.coi` 读成开放点 3 的用途是本文展开，非维护者原话）
- 开工前必读补 ⭐「关键现状一屏」与 §三.1 口径表（引用任何 g_opt_meta 计数前先读） - U1 状态改为「2026-09-23 已澄清」，写明正确值（全仓 97 / 后端三轴 67）与数法名不符之处 - §四 判据补纪律：判据计数（如 S8「七项校验」）落地时须给出可复现的匹配式
- §二.3（真串行点 = g_opt_meta 搬迁）末尾新增「⚠⚠ 本条判定的直接推论」块： 不碰 .ccr 字节 ⇒ 也不得测 .ccr 字节（判据一律不写 sha256/字节数，用同源 pre/post 自比） - §四.1 第 1 条（不写 .ccr 字节值）补同链回指，并写明「缺任一面会出现判据红了但分不清是本批还是 V8 造成的」 - 补 J16 的例外写法：canary 仍跑，但读法「全绿即过 / 变即停」，其绝对写入不得进任何判据 - 实核：本计划零硬编码 hex 锚定值（grep 无 16+ 位十六进制 token）
- §四.1 新增第 8 条：(a) 脱离数法的计数不得引用；(b) 标签必须能被匹配式复现，做不到就只写匹配式不起名字 - 写明本批踩过的实例（71 被起名「读侧表达式」⇒ 行数和变成「读取强度」主张）与「错名比错数更坏」的理由 - 按新纪律自查本文四处计数并给出匹配式：J=19 · S=8 · R=7 · 不变量=12（四者均与文中声明一致）
- 由口径表第 6 行（71）的实例推出两条：① 数法不全是不得引用；② 标签必须能被匹配式复现， 做不到就只写匹配式、不起名字 - 写明理由：错名比错数更坏——错数会被对拍发现，错名逃过一切数学校验（它不对应任何匹配式） - 附反查手法：名字给出后应能反推匹配式；反推不出、或反推出的匹配式给出另一个数 ⇒ 删名字、留匹配式 - 自查：口径表六行的标签与所列匹配式+单位逐行自洽（含「三档行数和」这个可复现名替换掉「读侧表达式」）
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
这份 PR 是两份文档
docs/maintainer/design/coi-optimization-knowledge-sidecar.mddocs/superpowers/plans/2026-09-23-coi-implementation.md.coi是什么可选、非权威的旁挂：存可复用的优化知识，
.ccr仍是与目标无关的程序关系表示。依赖方向
.coi → .ccr/.cir；禁止方向.ccr → 必需 .coi。12 条设计不变量，其中 #3「永远可选」与 #4「绝不是语义权威」各给了一条能证明它没被违反的检查（#3 = 强制全部读点"未命中"后产物仍逐字节相同；#4 = 敌意载荷对拍 + 结构闸）。一条硬读数（支撑立论）
1872 个
ver=9的.ccr产物，opt_count全为 0 ⇒.ccr里那一节是空的版本化壳子：占格式位、参与 load 校验、不携带信息。写侧唯一 =regalloc.cr，而它不在corec_files清单（两条独立证据）。⇒ 搬走它今天零成本。与 V8 的先后（施工计划 §二）
不是"身份面一律等 V8"——核了三条 V8 实读事实后那样写是错的（V8 自己的
EntityRef编码还没定；V8 下 NOD id 失去垄断）。⇒ 分界线在「框架 vs 取值」：
source_ref做成带标签变体 ⇒ 框架可先行、取值后挂（V8 冻结后只加一个kind值，零重做）⇒ 7/8 步可先行，唯一必须等 = 与.ccr读取面接线那步；唯一真串行点 =g_opt_meta搬迁（动.ccr字节，而 V8 落地必然作废那四条 canary 锁 ⇒ 先搬会重锁两遍）。答维护者"不规定 v1"
§21 已改为落地顺序（顺序 ≠ 分期，是为少返工）；§20 那 13 条开放问题逐条给了结论，不留在"实现时再定"。没有最小版/分期。
诚实边界
12 项待裁 · 11 项未核实（首要：未跑任何编译/测试 ⇒ "V8 下 ELF canary 是否仍逐字节不变"未实证，只给机制证据）。§4 非目标 13 条 + §19 第 10/11/12 条逐条转成显式声明。