Skip to content

Snapshot-Centric Compression Foundation: Single-Row Table as Source of Truth + Compression = Insert/Delete/Update Events | Snapshot中心化的压缩底座:单行表真源 + 压缩=对表的增删改事件(非增量车道,#5652/v6 线定位纠正) #5643

Open

Description

@ranxianglei

快进水位 v6:(sessionid, msgid) 复合身份驱动增量快路的完整设计(实现契约)

owner 裁定(2026-11-04):前代实现线全部作废——PR #5576(v5 身份门 / canonical 行链车道 / msgid 车道打包)虽经两轮深度评审,仍被 owner 关闭未合并;本次为全量重新开发,从最新 master 的干净分支起步,不移植旧分支任何代码(设计结论与评审教训只作参考,代码一律重写)。本文档是那次重做的唯一实现契约与防漂移基准。

第二轮对齐完成(2026-11-04):身份判决升级为 (sessionid, msgid) 复合键(单看任一者都有跨会话撞值风险);新增身份硬前置门(§3.2:收不到完整双 id = 故障 → 拒绝请求 + 零副作用,禁止任何形式的静默回退);新增 P9 身份层禁截断。由此 "?" 槽概念整段删除,原「无证据增量」路径作废。
第三轮对齐完成(2026-11-04,owner 裁定=纯忽略版):只要能对账(§3.2 双信道完整)就忽略客户端压缩——只看客户端增量消息;增量消息若是压缩摘要本身,一概接纳、不做特殊处理。由此:视图永远前向追加(P3 字面无例外);hide/replace/archive 日志种类整体删除(词汇表缩为 geom/block/arm/unarm 四种类);摘要前缀表、幸存区重锚定、W<0 判压缩机件、未知角落分支全删(后者并入 §3.2 故障拒绝);x-bili-pf-tail-ids 改为全元素全量列表(与 T 一一对应、体序排列),v5 尾窗+锚点模式仅为非 cohort 路径保留。§4/§4.1 存储机制至此经三轮走查定稿,直接进入实现。

范围边界(本 issue 只做 v6 msgid 车道):L1 身份薄表 + 身份硬门 + fastpath.ts 判决重写 + §4.1 三表存储(待下一轮定稿)+ §8 测试矩阵。
不属于本 issue:M1 原生身份观测层(nativeIdentityObservation)、canonical transcript 行链车道、以及此前各中间版本的演进过程。master 上已有的 v5 水位基线(pluginFullResendWatermark,含 tail-ids 信道)原样保留并继续为非 cohort 流量服务(其"降级诊断层"表述作废——它就是这些流量的正式服务路径);cohort 内采集端(src/agent/pf-channel.ts / native-intercept)切换全量列表模式的改动属本 PR 范围。

1. 背景(为什么重做,一段话)

dsh/pi/omp/opencode 等客户端全量重发历史,服务端每轮 JSON.parse 整个 multi-MiB 前缀 + 重建 CoreMessage(#5403 OOM 对)。此前实现把"身份"建立在服务端产物上(内容哈希/字节比对当主门、内核行链对齐当主门),违背了裁定:客户端自己的 sessionid + msgid 才是身份标志。在此基础上,第一轮实现的第二版又留了致命的软口:缺 id 时可以靠计数几何"猜"着继续跑——owner 裁定(2026-11-04):这种猜着跑一旦把错误增量缝进既有世界就是不可逆污染,后果灾难性,禁止回退。本版契约按该裁定收紧:身份是硬前置门,收不齐就报错,宁拒勿猜。一次性做完,不设观察期。

2. 已裁定原则(编号供引用,P1–P5 来自 owner 原始裁定记录 m02690/m02693/m02696/m03239;P6–P8 随第 2 版存储骨架一并裁定 2026-11-03;P9 随第二轮对齐裁定 2026-11-04)

  • P1 身份唯一:sessionid + msgid 统一处理为身份标志,以复合对 (sessionid, msgid) 参与判决——sessionid 单看会被不同会话复用撞值,msgid 单看也有跨会话发同值的观测风险,而对同时撞上 = 基本确定同一会话(owner 裁定 2026-11-04,残留的完整对撞按接受处理,不加第三信号)。不管载体是哪个(shim 信道、wb 显式头、codex 本地态头、cc/opencode/gemini 各自信道)。bili 自造的任何 id(内核 h_*)只属于渲染层,永不进入命中判决。快照分区键不由客户端任何头上报的值充当(见 §3.1)。
  • P2 只增量解析:命中轮只对**本轮新入册的元素(身份差集 NEW,可落任意体位)**做转换解析;其余全部字节零转换、零驻留原文。
  • P3 快照绝对权威:服务端稳定快照是唯一账本。客户端侧一切结构变化--压缩、切模型(族内)、换序、就地改写、重编号--在内容与档案层一律忽略;视图核只前向追加;没有任何单一客户端事件触发全局重定基。快照档案单调增长(防 [bug] DSH 桌面端 0.1.188:宿主原生压缩落地摧毁折叠基底 → 同一区间永久不可锚定、compress 连片失败并熔断(compaction-basic auto:false 仍无效) #2432 死螺旋 / "会话毁灭" 的底线不变量)。(注:客户端压缩的唯一账面动作是盖戳随身体几何走——t 天然等于本轮实测 T,属记账不是处置,不改档案与视图核本体,见 §6.1;第三轮裁定确认压缩无任何独立执行路径,摘要消息按普通增量接纳。)
  • P4 前置段透传:system、tool/skill 定义、第一条用户消息之前的一切可识别前置内容 → 每轮从当前流量取新鲜值透传,永不进入冻结快照(因此不存在"system 挡命中"问题,system 永远跟随当前轮)。识别不出前置段的未知布局 → 保守地从 body 开头起算账本边界(宁可多冻结正文,不误把系统文本冻进去再放不出去)。
  • P5 禁止全量重解析(硬红线):既有会话在任何情况下不再走全量解析路线。仅有的两个合法例外 = 冷启动武装轮 与 新身份发放(§3.1 匹配失败/未命中即新世界)。
  • P6 持久不重建:成立(§4.1.4 重启段)。全量重解析的合法入口恒定为恰好两个(全新会话、新发 pf_sid §3.1)。
  • P7 数据平面零状态、元数据 = log 派生:当前状态永远是确定性纯函数值 fold(pf_ckpt.meta_json, pf_log[ls_seq > ckpt_ls_seq]),内存只是缓存。
  • P8 id 永生(2026-11-04 扩展至 sess/msg 对):账本每行的 (sess_raw, ledger_id) 对只在首次入册写入,永不删除改写;「见过没?」= (sess_raw, ledger_id) 复合索引点查 → pf_sid + pos,跨重启恒可答。
  • P9 身份层禁截断(新增 2026-11-04):身份收集层对 (sessionid, msgid) 一律存储原值——数据平面、索引、ext 工作副本、诊断输出全链路,任何环节禁止截断 / 哈希 / digest 化 / 摘要化(防哈希碰撞致身份错认;前车之鉴:作废分支曾以 n:<sha1-8> 摘要入 ext 键位,round-1 评审 X1 已标记,此条将其升格为禁令)。内容侧衍生物([PR] protocol-stable core identity: same logical conversation, same ids in every dialect (#3642) #3658 身份 sig、Image message ids re-mint whenever an earlier image leaves the visible tail (membership-based ClusterCounter suffix) — prefix-cache breaks per fold, feeds #3748 storage growth #3751 图片指纹)只允许出现在 warn 诊断流,永不进入命中判决、永不入账本(原 sig 兜底锚定职责撤销)。
  • 结构事实(物理约束,非设计选择):跨协议族切模型(chat↔responses↔google proto)不能共用快照字节流——出站必然按目标族重建,逻辑核仍共享;族内切模型 = 忽略(无事件)。图片 base64 重编码在同 id 下不触发任何事件(命中标度只看 (序号, (sess,msgid), cs),不比内容字节,见 §6.2)。

3. 架构分层(建在 master 已有的标准结构上,不新建第二套)

层 内容 状态
L0 通用结构 BiliMessage/CoreMessage 规范 IR;{openai,anthropic,responses,google}ToCore ↔ coreToX wire 矩阵;#3642 跨协议稳定规范 id(规范投影 role|contentType|toolName|text,粒度公理);#3658 身份 sig、#3751 图片指纹(降为诊断信号,见 P9) master 已有,零重建
L1 身份提取 双信道采集(§3.2)+ pf_sid 匹配(§3.1)+ 载体表 resolver 链,归一输出 (pf_sid?, sess_raw, elementIds[])(elementIds 要么完整真实、要么触发故障门) 本 PR 新增(薄表)
L2 元素边界扫描 每族一个薄适配器,统一 span 机制 openai = 现有 scanMessagesSpans;他族同构跟进(rollout 排序问题,非架构问题)
L3 判决 纯函数,作用域=单个 pf_sid,只消费 (元素序号 × elementIds × (sess,msgid) × 宽度),协议无关 本 PR 重写 fastpath.ts
L4 出站 coreToX 每轮按目标族渲染 master 已有

L1 载体表(cohort 准入以双信道完备为准,§3.2 cohort 节):

  1. shim 信道 x-bili-plugin-conversation(会话级身份载体)+ x-bili-pf-count + x-bili-pf-tail-ids(v6 模式=全元素全量列表,与 T 一一对应、体序排列;fleet dsh/pi/omp/opencode 均有唯一原生 id,采集器读客户端存储 id;初始 cohort,主战场);
  2. wb:x-conversation-id / x-conversation-message-id(重试稳定)+ x-compaction / x-context-compacted 显式事件头;
  3. codex:session-id / thread-id / x-codex-window-id + turn-id,previous_response_id 轮换;
  4. cc:x-claude-code-session-id(+ metadata.user_id 双通道);
  5. opencode:x-session-affinity / x-opencode-session-id;
  6. gemini:协议形态信号 + <state_snapshot> 标记。

以上列出的是候选信道来源;每个 carrier 能否进 v6 cohort,以其 resolver 能稳定产出「请求级 sessionid + 与体元素一一对应的全量元素级 msgid」为准(配置级声明,见 §3.2)。取不到即不进 cohort 或按故障处理,不再有 "?" 保位一说。

3.1 身份发放与匹配(2026-11-04 第二轮对齐:复合键制)

事实基础(owner 裁定):sessionid 单看不唯一(观测到跨会话复用);msgid 单看有跨会话同值风险;(sessionid, msgid) 对同时出现 ⇒ 基本确定即同一会话。因此:

  • 快照分区键 = 服务端自造的 pf_sid(形如 pf_<hex12>),与客户端头上报的任何值完全解耦(自引用表查询,一经发放终身有效、重启可再匹配)。
  • 客户端身份原值成对入表(P8/P9):账本行记首见的 (sess_raw, ledger_id),只写一次、永不改写;全局复合索引 idx(sess_raw, ledger_id) 支撑 O(log n) 点查。sessionid 不再是"只入诊断日志"——它是复合键的一半,以原值、入表、参与判决(第一轮契约中"客户端 sessionid 退出判决/从不入表"的表述整体作废)。

匹配规则(每轮进道执行一次,纯读;本轮必须先通过 §3.2 身份门):
① echo 直中:请求头 x-bili-pf-session 在表 ⇒ O(1) 命中该 pf_sid,并抽验一致性——本轮上报的 sess_raw 与该世界登记 sess_raw 一致、且至少一个 (sess,msgid) 对在账本内;抽验不符 ⇒ 按 §3.2 故障处置(伪造回声/漂移环,计入 breaker)。echo 只是加速:不配合 echo 的客户端走②同样命中,匹配正确性不依赖客户端配合。
② 复合探测:任取本轮真实 (sess_raw, msgid) 对探测全局复合索引 ⇒ 命中该 pf_sid。仅 msgid 命中而 sess_raw 与登记值不符 ⇒ 视为未命中(防跨世界合并,本条是对第一轮"msgid 单探续接"规则的明确否决)。
③ 兜底发放:全不中 ⇒ 发放新 pf_sid + log arm 条目,本轮走合法武装轮(P5 例外二)。

已裁定代价(2026-11-04):"同一逻辑对话换了 sessionid 回来"不再自动续接旧世界——严格复合键下它表现为规则③,付一轮合法全量武装,旧档案完整保留可回滚。判据:绝不合并两个世界 > 偶尔多一轮全量。

  • 不设冷静期(维持):连续发放多个身份且后续无命中不触发特殊处理;诊断留痕,异常再诊断。
  • 生命周期(维持):随内核会话删除清理,无独立保留期。

3.2 身份硬前置门(新增 2026-11-04,本版最硬的条款)

前置条件:任何一轮请求要走 v6 快道,必须先成功收集完整双信道——请求级 sessionid + 元素级 msgid[],且 msgid[] 与本轮 body 的元素一一对应(长度 == 扫出的元素总数 T)、全部为真实 id(空位、占位、解析失败的槽一律不接受)。

故障判定(满足任一即为身份故障):

  • 信道缺失:无 sessionid 头 / msgid 列表头缺失或无法解析;
  • 数量失配:|msgid[]| ≠ T(与几何扫描矛盾 = 信道谎报或半路丢失);
  • 成员失真:列表中任一元素非真实 id;
  • 一致性破裂:echo 头声称的世界与其携带的身份对互相矛盾(规则①抽验失败)。

故障处置(owner 裁定:报错,不回退):

  1. 立即拒绝本轮请求——返回错误响应(具体 HTTP 状态码 / 错误体格式列入下轮议程 §7-D),客户端可见、响亮;
  2. 服务端零副作用:不写 pf_rows / pf_log / pf_ckpt、不动 ext、不推水位、不落任何核(拒绝不留痕 ⇒ 客户端重试同一轮(id 相同)自然成功收敛,无需特殊重放机件);
  3. ERROR 级日志 + 诊断输出(含 carrier、缺哪一半、|R| vs T);故障计数器递增,喂 breaker 与告警。

三个禁止(红线):
① 不得静默落 legacy 非快路继续服务该请求("默认回退"正是本条封死的对象);
② 不得凭计数几何猜测归属去追加增量(第一轮契约的「无证据增量」路径——R 缺/不全但 W>0 照做尾切片——作废删除);
③ 不得用内容签名猜测任何判决(配合 P9:sig/指纹退出判决层)。

理由记录(为何拒绝是唯一自洽处置):身份污染是不可逆的——错误的增量一旦缝进既有世界的账本,账本只增不删,之后每一轮都在污染之上生长(#2432 类失效的加强版);而拒绝是可逆的——什么都没发生,下一轮照常。可逆操作永远优于不可逆操作。

cohort 准入(配置级,区别于运行时故障):carrier 天生不具备完整双信道的 ⇒ 在配置层面排除出 v6 快道——保持现状基线行为,不报错、不启用、不进 breaker(它从未承诺过身份,谈不上违约);运行时故障 = carrier 声称有信道但某轮实际收不齐(这才是 §3.2 的报错对象)。初始 cohort 名单逐 carrier 核实后置入配置(§7-D 议程)。

4. 两个寿命不同的持久结构

  1. 位置水位 t(易变):上一轮请求体的元素总数语义的水印,每轮末 = 本轮实测 T(盖戳定义使然,无"重置"动作——客户端压缩只是让这个数字自然变化,见 §6.1)。用途收窄为三:① 握手盖戳诚实性(戳永远=身体实测几何,否则下轮客户端窗口错位);② §3.2 数量失配检查的对账基准;③ 漂移诊断流。不再参与增量区间计算(第三轮裁定后唯一判决轴是身份)。
  2. 累计身份账本(只增):本世界见到的一切 (sess_raw, msgid) 对的有序集合,跨重启恒在。它永不收缩——它就是档案本身,也是集合差能永久算下去的原因。规范版存于 §4.1 数据平面 pf_rows 的 (sess_raw, ledger_id) 列 + 全局复合索引;ext 里只留有界工作副本(容量帽 2048×512ch 量级,超出转诊断;工作副本中的 id 同为原值,P9)。

视图核:按账本序排列的前向追加核数组。内存驻留纪律:原始请求字节只做临时解码、零驻留;稳态内存 = 窗口化核(由现有 fold/block 管道治理预算)+ 账本元数据(≤256KB 量级)+ KB 级状态。永久细节档案 = 磁盘上的 unified transcript rows(现有设施),不在内存里重复存一份全史。

4.1 服务端实时快照存储与"当前状态"(原始存储 + LSM tree 元数据,2026-11-04 三轮走查定稿)

状态横幅(2026-11-04,已定稿进入实现):本节机制经 owner 三轮走查审定(快照维护全生命周期、两种"压缩"的区分、三表结构逐项确认)。第二轮对齐强制变更持续有效:sess_raw 列入表、idx(sess_raw, ledger_id) 复合索引、"?" 槽整体移除、故障轮零写入(第四条不变量:rejected ⇒ no trace)。第三轮裁定并入:客户端压缩纯忽略(无 hide/replace/archive 事件,词汇表缩为四种类)、x-bili-pf-tail-ids 全量列表线格式、未知角落并入 §3.2 故障拒绝、故障计数挂 geom payload 扩展位(faults?)。

演进记录(背景):初版「单可变行 Meta@rev + CAS」2026-11-03 被裁定作废;第 2 版按 owner 定向的「原始存储 + LSM tree 元数据」设计。核心一句话:LSM 版是元数据本身也是日志——所有元数据变更以不可变条目追加进 L0,周期性压实成 L1 检查点,当前元数据 = 检查点 ⊕ 回放其后的日志;丢更新结构上不可能,历史可重建,读成本有压实保证。

4.1.1 三张表、两个平面

数据平面(原始存储,append-only,无状态列)
  pf_rows(sid, pos, sess_raw, ledger_id, core_id, core_json, ts)   PK(sid, pos)

元数据平面(LSM)
  pf_log(sid, ls_seq, kind, payload_json, born_pos_hi, ts)   PK(sid, ls_seq)   ← L0 热日志
  pf_ckpt(sid, ckpt_ls_seq, meta_json, checksum, updated_at) PK(sid)           ← L1 检查点

sid = pf_sid(服务端发放,§3.1);sess_raw / ledger_id 均为客户端上报原值(P9)
索引:idx(pf_rows(sess_raw, ledger_id)) 全局复合 —— §3.1 规则②探测;idx(pf_rows(sid, core_id)) —— block↔pos 绑定
  • pf_rows(数据平面):pos 单调元素序永不重排;(sess_raw, ledger_id) = 该位首次见到的宿主身份对原文,跨重启 host↔核心绑定的唯一依据,集合差因此永远算得下去,永生(P8);core_id = 规范核 id(= 内核接收后的 msg_id,The intermediate message (core) is not protocol-agnostic: switching protocols/models causes identity churn; cross-protoc | 中间消息(core)没有做到协议无关:切协议/切模型制造身份 churn,补齐跨协议映射 #3642),用于把 bili 自己的 fold block 精确绑定回 pos 区间而无需重解析内容;core_json = 协议中立的规范 CoreMessage 序列化。严格 append-only:半成品(在途解析)绝不占 pos 再改写。清理 = 内核会话删除事件时按该会话 ext 中的 pf_sid 列表三表连删(无独立保留期)。表零状态:无 status/frontier/状态列。
  • pf_log(L0):每条元数据操作一行,ls_seq 每会话单调递增;条目自包含——锚点一律用稳定 id,不用会被后续追加推移的数字偏移;born_pos_hi 记录该条目生效时数据平面的最大 pos(两平面的时序戳)。
  • pf_ckpt(L1):每会话一行的压实结果,checksum = fold 后完整元数据的短哈希,水合时快速校验而不必全量 diff。

4.1.2 元数据日志的条目种类(穷举,全部纯追加语义)

kind payload 谁写
geom {t, maxPos, m, misses?, faults?, disabledAt?}(faults? = 本轮之前累计的身份故障计数,第三轮定夺挂在扩展位) 每轮 finalize
hide / replace / archive 已删除(第三轮裁定 2026-11-04:客户端压缩纯忽略、视图不收缩,无隐藏区概念;原审计职责归 unified transcript rows) —
block {blockRef, span}(bili 自己 fold 的可见性隐藏,从内核 blocks 按 core_id 绑定派生,best-effort:绑定不齐就不写该条目,宁可视图多给、由内核 fold 管道自行治理,绝不为对齐去猜) finalize
unarm / arm {reason}(身份边界:匹配失败新发 pf_sid 清档重武装的事件化记录) 对应路径

当前元数据 = fold(pf_ckpt.meta_json, pf_log[ls_seq > ckpt_ls_seq])。fold 规则逐 kind 定义、确定性、幂等(同 key 重复提交 no-op)。视图核可见性 = f(pf_rows × fold(meta)):状态只存在于日志条目里,行永远不变——P7 在 LSM 形态下的表述:数据平面零状态、元数据 = log 派生。

4.1.3 原子性:三层各守一个事务边界

  1. 单事务双平面提交:finalize 时 INSERT 新行[pos..newMax] + INSERT pf_log(kind='geom')(及当轮产生的 block/arm/unarm 条目,若有)同一个 SQLite 事务。读者任何时刻看到的是整轮前或整轮后,不存在「行在但几何没到」或反之。
  2. 压实同事务:UPDATE pf_ckpt(新meta, checksum) + DELETE pf_log(ls_seq <= 新ckpt_ls_seq) 同一事务;不变式 fold(new_ckpt, remaining_log) ≡ fold(old_ckpt, old_log)——压实前后读出的当前元数据逐字段相等。
  3. 崩溃分支由此穷尽且有定义:
    • 轮中崩 → 事务回滚,下轮客户端重发全量 body,未提交追加消失,零痕迹(天然 at-least-ononce;客户端 body 本身就是重放源,我们是请求驱动的中继不是长驻 runner,刻意不抄 claim/resume 长驻语义并说明理由);
    • WAL 页撕裂 → SQLite 自身恢复,上层无感;
    • checksum 校验失败(坏块)→ 降级现状行为 + 诊断打点,绝不猜测重建。安全优先于聪明,设计决策而非遗漏。
    • (第四条不变量见本节横幅:rejected ⇒ no trace。)

4.1.4 读路径与水合("重启只水合未覆盖窗口"的可实现细节)

  • 进程内:每会话一份常驻可见核数组(稳态内存 = 窗口化核 + 账本元数据 ≤256KB 量级;存储不是省内存用的)+ ≤64KB 元数据缓存(ckpt⊕log 结果)。
  • 命中轮:身份探测与集合差纯内存判定;前缀核供服务用常驻数组;NEW 元素现解。缓存有效时全程不碰磁盘(常路命中轮触碰数据面 0 次)。
  • 重启首触会话(惰性:第一次有该会话请求才做):读 ckpt(校验和)→ 回放尾部 log(有界,见压实策略)→ 得到 geom.t 与 frontiers → 按可见区间水合 pf_rows 的 core_json 填常驻数组(深度折叠区只取轻列不出正文)→ 该会话回到纯增量态,后续轮次与重启前完全一致。没有任何「重启武装轮」:武装只属于 P5 的两个例外(全新会话、新发 pf_sid),重启不在其中(P6 由本条满足)。⚠️ 已知陷阱(作废分支 round-1 B1 发现,重写时必须钉死回归):hydration 快照必须携带活跃世界原点 o,frontier 只能由 arm/reset 类条目移动,绝不能用"水合窗口起点"冒充原点,否则重启后服务截断历史。
  • 压实策略(保证回放有界,都在 finalize 顺带做,无后台线程):pf_log 条目数 ≥ 64 或 ≥ 64KB 或 会话 30min 无活动时触发一次;稳态读成本 = O(1 行 ckpt + ≤64 条 log)。

4.1.5 两种压缩对表的动作(2026-11-04 第三轮裁定后形态)

(A) 客户端侧压缩(cc /compact、opencode 自动、codex 本地 compact、wb 显式头——到 relay 层无需区分产者)→ 纯忽略(owner 裁定原话:"我们只要能对账就忽略客户端压缩,只看客户端增量消息;如果客户端的增量消息是压缩消息本身,一概接纳不做特殊处理"):

(B) bili 自己的 fold/token 预算管道(可任意中间段)→ 数据平面仍不动(零状态)、log 变:finalize 检测新增活跃 block → 按 core_id 绑定算出 pos 区间 → 追加 block 条目。渲染不假设可见集合的任何单调性(代码库已有 #3222 中段成对剥离、filterDeadRanges 等非前缀操作先例)。

4.1.6 原则效力修正与容量/迁移

  • P6–P9:效力已并入 §2,本节不再重复。
  • 容量:数据面典型长会话 MB~数十 MB(core_json 数百 B~数 KB/行);v1 不做物理淘汰(fold 深处行被 block 条目隐藏后即为冷数据,GC 留后续题)。元数据面稳态 < 2×64KB(压实保证)。
  • 迁移:schema v10→v11,三张表纯 CREATE IF NOT EXISTS,存量安装升级后全空、字节零变化;rollout 开关 OFF 时全套代码零流量零读写。MySQL 后端本期不实装(sidecar 不可用节点行为见 §7-A②)。

5. 逐轮流程(常路)

  1. 门:rollout 开关(watermarkV6MsgId 默认 OFF,config-file key,见 §9 配置面);pluginMode;非 title-gen;breaker 未熔断;carrier ∈ cohort(§3.2,配置级双信道声明)。
  2. 扫描与身份采集:span 扫出 T(本轮元素总数);采集双信道(请求级 sess_raw + 元素级 msgid[]);§3.2 身份门:任一故障判定成立 ⇒ 拒绝 + 零副作用(流程到此终止,不进后续步骤)。
  3. 身份匹配:按 §3.1 规则①→②→③执行(echo 直中+抽验 / 复合探测 / 新发放武装)。
  4. 集合差判定(唯一判决轴):本轮全部元素 (sess_raw,msgid) 对逐一探全局复合索引 ⇒ 命中 = 老面孔(冻结核已在视图中,零动作零解析);未命中的真实 id = NEW 真新增(可落任意体位)。没有幸存区贪心、没有签名兜底、没有几何推断——对不上就是新增,这是身份自描述的直接推论。
  5. 增量转换:只解析覆盖 NEW 元素的字节 span(span 来自步骤 2 结构扫描按元素序号定位;NEW 分散时逐块解析);单次整数组 codec 调用保证 _N 编号与传统行为逐字一致(codec ClusterCounter 规则,node_modules/acp-kernel/dist/wire/index.js:64)。实现验证点:v5 已证连续尾切片可达成逐字一致,散布子集需复验(对应 §8 行 6)。
  6. 组装与出站:视图 = 冻结前缀核 + 追加新核;coreToX 出站;记账 t←T、账本 ∪= 本轮对集、写 ext、打 x-bili-pf-session(echo 恒带回)+ x-bili-pf-seq=T。
  7. miss 语义(格式级 fail-soft):几何/编解码等格式级判据不足(非身份维度)⇒ 不进快道,落入既有非快路(含 dsh-compaction-guard 边界机件 fix: rebase fold substrate on Codex local auto-compaction (#2372) #2373/[bug] DSH 桌面端 0.1.188:宿主原生压缩落地摧毁折叠基底 → 同一区间永久不可锚定、compress 连片失败并熔断(compaction-basic auto:false 仍无效) #2432/bili-authored client compaction: let the host's own compaction flow run, but bili writes the checkpoint #3733)。credited-miss breaker(5 连击 60min TTL)保留,§3.2 故障计数同样喂入。

关键推论(第三轮修订:身份是唯一判决轴):身份由 (sess_raw, msgid) 复合键自描述——谁旧谁新、属于哪个世界,一次点查即答,与元素在体中的位置无关。计数几何(t/k/T/W)降级为三重辅助:① 握手盖戳必须诚实(戳=本轮实测 T,否则下轮客户端窗口错位);② 故障门输入之一(|R|≠T = 数量失配 ⇒ §3.2 拒绝);③ 漂移探测诊断流。它不再承担任何正确性推理——第一轮"k 意味着客户端保留了 [0..k)、故即便 id 缺失增量也精确已知"的位置信任链在 v6 已整体作废(id 是硬前置不是可选优化)。客户端压缩因此无害:身体怎么变形都不影响逐元素身份探测,唯一需要跟上的是盖戳数字本身。这正是 P2(只解析增量)与 P3(档案不被外来内容污染、单调增长)同时成立的支点。

6. 事件矩阵(完整判定表)

事件 信号 视图核动作 账本 水位 解析代价
纯追加(常态) NEW 非空(常态恰在体尾) 追加新核 ∪新对 t=T 仅 NEW 元素
客户端压缩(任意产者形态——cc /compact、opencode 自动、codex 本地、wb 显式头,无需区分) 无需检测:任何身体形状(含 W<0)一律常路处理 视图继续前向追加,不收缩(模型看到旧核全集 + 新核,不跟随客户端裁剪) ∪= NEW(摘要消息若在场=普通新消息照常入册,零特殊识别) t=T_new(盖戳跟身体几何) 仅 NEW 元素(任意体位)
id 稳定·内容变(就地改写) 判决层不可见(不比字节,§6.2) 骑旧核 不动 不动 零
顺序换位 判决层不可见 按账本序呈现(模型看到的顺序恒定) 不动 不动 零
族内切模型 无(忽略类) 不动 不动 不动 尾切片照旧
身份边界 §3.1 规则③匹配失败 ⇒ 新发 pf_sid(含"同一对话换 sessionid 回来"场景) 新世界 新世界 重置(arm/unarm 条目) 合法全量(P5 例外二)
身份故障(新增行) §3.2 任一故障判定(信道缺失/数量失配/成员失真/一致性破裂) 无动作(拒绝,零副作用) 不写 不推 零(请求被拒)
未知布局角落 已并入 §3.2:双信道硬门下该状态不可达——身份/几何任一不一致即故障拒绝;身份完整则几何无判决权 — — — —

6.1 客户端压缩的执行细则

  • 没有专门的执行路径(第三轮裁定:"只要能对账就忽略客户端压缩")。常路(§5)对压缩轮的处置与非压缩轮完全同构:逐元素身份探测 → 集合差 → 只解析 NEW。摘要消息若以真实 id 出现在体里,它就是一条普通的新消息:被解析、入册、进视图,与自家 <bili-snapshot v1 …(src/server/dsh-authored-compaction.ts)没有任何待遇差别。
  • 前缀表 / 产者归属识别:删除。行为不因产者而异;诊断日志如需归因,记录该消息前若干字节的原文片段即可(不进判决、不建常量表)。
  • 盖戳跟身体几何:t 每轮末 = 本轮实测 T。这不是"重置"而是盖戳定义使然;它保证下一轮客户端的窗口算术不错位(§3.2 数量失配检查的对账基准)。
  • 防 [bug] DSH 桌面端 0.1.188:宿主原生压缩落地摧毁折叠基底 → 同一区间永久不可锚定、compress 连片失败并熔断(compaction-basic auto:false 仍无效) #2432 不变:全程零碰冻结区 ⇒ 内核 fold 锚点永不因客户端事件自毁;与现有 markNativeCompactionBoundary / carriesDshLocalCompactionSummary(阈值 8)guard 互补。

6.2 字节变动的执行细则

7. 待裁项与下轮议程

A. 遗留待裁默认值(可否决,逐条独立)

~~1. ~~未知布局角落 — 已关闭(第三轮 2026-11-04):该状态在双信道硬门下不可达——任何身份/几何不一致直接落入 §3.2 故障拒绝,不再有独立处置分支。
2. sidecar 不可用节点(MySQL 后端本期不实装):默认 = 该节点 v6 全套软停用、现状行为,请求不报错(节点级配置排除,区别于 §3.2 的请求级故障)。
3. pf_log 压实后旧条目:默认 = 物理删除(checksum + 诊断兜底);备选 = 保留最近 K 代检查点做深度回滚审计。
4. 就地编辑可见性:默认 = 维持服务端绝对权威,白名单仅前置段(P4);若要允许某种覆盖语义需另行裁定,本 PR 不实现。

B. 已锁定(本轮对齐关闭,不再复议除非 owner 推翻)

身份复合键制(§3.1)、身份硬门与三禁止(§3.2)、P9 禁截断、"?" 槽删除、无证据增量作废、sessionid 原值入表、旋转不换绑(付武装代价)、故障=拒绝+零副作用、cohort 配置级准入、客户端压缩纯忽略(B 版,视图恒前向追加)、日志词汇表缩为四种类(geom/block/arm/unarm)、tail-ids 全量列表线格式、cohort 初始名单 = shim 系(x-bili-plugin-conversation + 全量 msgid 列表)。

C/D. 下一轮对齐议程("实时快照与存储",owner 点名)

  • D1 实时快照机制 已完成(2026-11-04 走查通过:全生命周期带数字时间线 + 四条不变量);
  • D2 三表 schema 定稿 已完成(三表/索引/fold/原子性/压实/水合逐项确认;ckpt 语义=纯回放成本装置不承载业务语义;sess_raw 不设存储上限、P9 约束成立;B1 陷阱回归钉已入 §8 行 19);
  • D3 故障响应形态:HTTP 状态码 / 错误体 JSON 形状 / 客户端重试约定 / 是否带诊断 id;
  • D4 初始 cohort 清单:六个候选 carrier 逐个核实"resolver 能否稳定产出完整双信道",定进/出名单(含 shim 采集器的落地形态);
  • D5 重编号事件:id 值被客户端换掉(内容同、id 异)在新体系下 = 旧对消失 + 新对 NEW ⇒ 需明确是判为新增(会双份)还是引入对级去重——本轮未裁,留待 D 轮;
  • D6 测试矩阵锁定(§8 现稿随 D 轮修订后冻结)。

8. 测试矩阵(按新语义重写 tests/fastpath*.test.ts + 新增 tests/fastpath-v6-msgid.test.ts;D6 轮锁定)

  1. 纯追加命中,尾切片转换、_N 编号与全量路径逐字一致;
  2. 双信道完整(sess+msgid 齐)⇒ 正常命中入道;
  3. cohort 排除:无双信道声明的 carrier ⇒ 保持现状基线行为,开关 ON/OFF 均不报错(门双向断言,Test Blind Spot Retrospective: Reinforcing Negative Assertion Discipline, Tightening Fake Upstream Strictness, Thin Inst | 测试盲区复盘:补反向断言纪律、假上游严格化、薄安装冒烟、形态矩阵与生命周期覆盖 #3617 规约);
  4. 压缩·纯忽略(B 版):压缩轮后视图继续前向追加不收缩(模型看到全部旧核+新核)、无 hide 类条目写入、次轮照旧命中;
  5. 压缩·摘要即增量:摘要消息以真实 id 出现在压缩轮体中 ⇒ 当普通新消息正常解析、入册、进视图(零特殊识别回归钉);
  6. 压缩·散布 NEW:NEW 落在任意体位(如 opencode 形态摘要在 pos 0)⇒ 正确解析且 _N 编号与全量路径逐字一致(散布子集编码一致性回归钉);
  7. 身份故障·零副作用:msgid[] 缺一项 ⇒ 请求被拒 + 三表/ext/水位无任何写入 + ERROR 日志与计数存在;
  8. 身份故障·数量失配:|msgid[]| ≠ T ⇒ 拒绝;
  9. 故障恢复无痕迹:故障轮后客户端重发同一轮(同 ids)⇒ 正常命中、世界与账本和故障未发生时逐字段一致(拒绝可逆性的回归钉);
  10. 仅 msgid 命中而 sess 不符 ⇒ 判未命中、新发放(跨世界合并防护钉——第一轮规则②的反向回归);
  11. 同一对话换 sessionid 回来 ⇒ 新发 pf_sid + 合法武装轮 + 旧世界档案完整保留(旋转代价钉);
  12. 伪造 echo 头(sid 在表但身份对矛盾)⇒ §3.2 故障 + breaker 计数;
  13. id 稳定内容改:骑旧核、视图不变、诊断 warn 存在;
  14. 换序:视图按账本序,与输入顺序无关;
  15. 族内切模型:无事件,照旧命中;
  16. breaker:5 连击 credited-miss(含故障计数)⇒ 60min 熔断 + 恢复;
  17. 容量帽:ext 工作副本超 2048 条截断 + 诊断(磁盘全量原值仍在);
  18. 开关关(默认)⇒ 现有 v5 套件全绿不变;
  19. 水合一致性:模拟进程重启(丢内存镜像)后首轮命中,视图与重启前最后一轮逐字节相同(P6;叠加跨 L1 折叠的 3 次连续重启 oracle 比对——B1 陷阱回归钉);
  20. 中间段折叠渲染:block 日志条目落在中段时,出站视图与内核可见性一致,被折区 id 仍可解析(P7/P8);
  21. 身份 echo:响应头 x-bili-pf-session 存在 ⇒ 稳态直接命中(O(1))+ 抽验通路存在;
  22. 换绑后档案:新发后旧 pf_sid 数据完整保留(回滚参照);deleteSession 连带清理该会话全部 sid(pf_* 三表连删无孤儿)。

验收:tsc --noEmit 0 + 相关全套绿;PR 正文引用本 issue(Closes 本 issue)。

9. Rollout 与实施顺序

  • 开关 watermarkV6MsgId 默认 OFF,config-file key(src/knobs.ts,不新增 env 旋钮;env 稀缺面规约),与现有 pluginFullResendWatermark 并存;v5 代码路径保留、继续为非 cohort 流量服务(不是删掉)。
  • 配置面(PR 必须单列章节):watermarkV6MsgId(总闸)+ v6 cohort carrier 名单(每项声明其双信道 resolver;初始名单 = shim 系:x-bili-plugin-conversation+全量 msgid 列表;他族逐格解锁)。
  • 实施顺序(对齐完成,直接开工):schema v11 三表 → 存储模块(fold / 原子提交 / 压实 / 水合)→ knobs 开关面 → L1 载体薄表 + 采集端全量列表化 → L3 判决纯函数 → evaluate 接线 → §8 测试矩阵 → tsc + 全套 → 回归交 owner。从最新 master 开干净分支全新实现,单 PR,不分观察期,不移植 [PR] Native-Identity Fastpath: Observation Layer (M1) + Identity-Only Hit Gate (v5) | 原生身份快路径:观测层+身份制判据(一次做完) #5576 旧代码。
  • 观测/归因类能力(原生身份观察层等)不在本 PR 范围;客户端身份原值本就入表入诊断,如后续需要更强归因另行立项。

补充裁定(2026-11-05,owner):规范流转顺序——所有平面的设计基准(ai: sglang-gpu0/qwen3.8-27b)

裁定背景:PR #5689(#5664 渲染快照平面)被 owner 指出设计偏离本契约——缓存单位取成映射后的出站字节、稳态轮直接拼接此前已发字节跳过再序列化。完成偏离盘点后,owner 裁定如下,补录进契约正文(不另开子 issue)。

  1. 目标函数:快路体系追求的是稳定性、扩展性、通用性,不是性能;性能收益是按下面流程做对的副产品。一切设计评审先问"流转顺序对不对",不问"快不快"。
  2. 规范流转顺序(固定,每轮全链路必须走全):
    原始字节 → to core 通用协议 → 改写(内核)→ apply 到快照 → to 目标协议 → 出站
    快照只允许缓存改写层右侧的通用核形态(即 §4.1 pf_rows.core_json 的 CoreMessage 形态),禁止缓存任何映射后的出站 wire 字节。每一轮都必须完整经过全部环节、含最后的目标协议序列化——这是 §2「结构事实」(跨协议族不能共用出站字节流、出站必然按目标族重建)的物理体现:族内切模型因此天然过映射层,身份平面不必为它设事件。
  3. 边界归属:快照的校验、状态指纹与审计比对点只落在两处——内核侧内部状态(策略/折叠摘要等)与改写后的通用核形态;模型/渲染阶段专属参数(model、maxDim、toolArmed 等)降为每轮映射层的输入,不参与快照有效性判定。
  4. 结构事件的处置:一切客户端结构变化(压缩、就地改写、换序、重编号等)一律走规范链:改写层重新推导、映射层每轮重建,受影响段落的快照按版本化重建/替换处理,永不就地覆写;车道关死只保留一种情形——存储底材本身损坏且不可恢复(校验和不符/水合失败)。
  5. 实施约束:v12 三表与 rollout 开关均未合入 master,改形在合并前完成 ⇒ 零迁移成本。fastpath v6 render snapshot plane: one-time full rewrite, steady-state rounds skip full view scan (#5643 sub-item) | fastpath v6 render 快照平面:全量改写只做一次,稳态轮跳过全视图扫描(#5643 子项) #5664 / PR [PR] feat(fastpath): v6 render-snapshot plane — steady turns skip the full-view scan (#5664) #5689 恢复施工时按本节重写其正文与实现,正文引用本节而不另立新原则。

补充裁定(2026-11-05 下午,owner):快照必须随压缩演进——事件化更新语义(ai: sglang-gpu0/qwen3.8-27b 记录)

背景质疑(owner):压缩是 bili 自己的核心功能;链上「改写」这一环的主体就是压缩。快照平面若在任何一次折叠发生时自杀,那么在「上下文大到需要压」的目标会话里它的收益从第一次折叠起就永久消失——等于给核心场景没做东西。快照必须活过压缩的完整生命周期。

裁定三原则(owner 原话骨架):

  1. 压缩是 bili 自己的压缩核心功能;
  2. 压缩本质是客户端请求服务端——它走普通请求进来,没有带外事件通道;
  3. 服务端收到请求后直接生成最新的 snapshot 修改:权威投影与当前快照的 diff = 一串有序事件(插入/更新/删除),按序作用于快照,完成对快照的修改。

实施基准(由上述原则落地):

  • 行键 = ledger 绝对位置(append-only、永不复用的身份地基),不是存活元素的紧凑序号——delete 事件来了全表不重编号;
  • 快照表就是普通可变表:每轮 diff 落成 INSERT(尾部新元素)/ UPDATE(块覆盖范围被改写的格)/ DELETE(被折叠行),单事务提交。持久性与崩溃一致性由 SQLite/WAL 事务 + unified 双写对账承担;禁止再叠加日志结构化层(op 表/版本列/ckpt+回放)——快照是派生缓存而非账本,真值在 pf_rows 与内核状态里,且死版本只增不减踩泄漏红线;
  • diff 只按内核管道证据寻址(块覆盖范围、ledgerSeq、checkpoint 帧边界),禁止模糊相似度匹配;地址对不上 ⇒ 该轮不产事件、整轮 legacy 回退,下轮再说;
  • 四件套保护一个不少:tripwire(核心形态边界比对)、S4 逐行校验和、见证要求(结构变化必须有内核事件背书)、审计节拍抽验。无见证漂移照样永久判死,行为与现状逐字节相同;
  • §5 上文一条不改:行内容仍是改写后通用核形态、出站整段每轮现过完整映射链;红门词汇、90% 压让路、O(新) 稳态开销保留;存储随存活元素有界增长;
  • 明确否决的替代方案:A) 折叠即判死(目标场景收益归零);B) 分段重置/换段重建(离散事件的粗糙近似,被事件化语义取代);C) 逐行版本链+WAL 回放(重复建设 + 死版本泄漏)。
    附录(2026-11-05,落点确认):插件模式的压缩调用打的就是 bili 的管理端点(POST /__bili/plugin/tool,src/server/admin.ts:801 → handlePluginTool)——压缩在该次管理请求内执行,服务端内核当场改写、blocks 当场更新,端点即第一现场。实施口径:端点执行压缩成功后给该会话盖一次性「结构事件待处理」标记;期间平面保持红门(新红因 structural-pending)拒绝任何绿轮猜测;下一轮模型请求走全量路径时执行表修改(UPDATE 摘要格 + DELETE 被覆盖行 + INSERT 新增,落地形态为「自首个分歧点截断 + 整段重新追加」的单事务写)。行键维持存活元素紧凑序号的连续不变量,不引入稳定行键——理由:结构变化总是使分歧点之后的整段按权威投影重同步,前缀逐字节不变,稳定寻址在此无正确性收益、只增加索引与水合复杂度;「插入/更新/删除」三原语对紧凑有序表的语义与截断重追加完全等价,存储与校验和机制不动。绕过该端点的宿主(dsh native compaction,[bug] DSH 桌面端 0.1.188:宿主原生压缩落地摧毁折叠基底 → 同一区间永久不可锚定、compress 连片失败并熔断(compaction-basic auto:false 仍无效) #2432 类)由既有的 checkpoint 帧签名+rebase 检测把证据喂给同一个表修改例程。标记在表修改成功落盘后消费;进程重启丢失标记的后果是保守方向(下轮按无见证漂移判死,fail-safe)。无见证漂移的判死语义一字不改。

附录二(2026-11-05 晚间,owner):事件写回时序补正——压缩请求内同步落表,下一轮只做核对

owner 复述裁定:「改写压缩产生 diff 直接写快照;快照就是 lsm tree 追加增删改事件,合成就是新快照」——对「实施基准」的时序措辞作如下补正:

  • 写入时机 = 压缩请求内同步。结构事件的第一现场(插件端点 / 内核自折点)在拿到内核管道证据的当次请求里就把增删改事件落成单事务写;「下一轮模型请求走全量路径时执行表修改」仅保留为绕过第一现场的宿主(dsh native compaction 类)的兜底路径。两路喂同一个表修改例程。
  • 快照形态确认(owner 原话):普通可变表就是 lsm tree——每轮把 diff 追加为插入/更新/删除事件、单事务提交,表本身即最新合成结果。此表述与实施基准「禁止再叠加日志结构化层(op 表/版本列/回放引擎)」不矛盾:事件是单事务里的 DML,不是持久化重放日志;崩溃一致性照旧由 SQLite/WAL 承担,S4 校验和与 ckpt 折叠不动。
  • 「行键维持存活元素紧凑序号」的实施口径作废,恢复为实施基准原文:行键 = ledger 绝对位置,delete 事件来了全表不重编号(三原语各自真寻址;紧凑序号≡截断重追加只是等价落地形态,不是采纳的理由)。

Activity

  1. changed the title [-]feat(fastpath): v6 msgid 身份驱动增量快路 —— 全量重新开发(前代 #5576 线作废)| fastpath v6: msgid-identity-driven incremental fastpath, full rework[/-] [+]feat(fastpath): v6 msgid identity-driven incremental fastpath — full rework (previous #5576 line voided) | fastpath v6: | feat(fastpath): v6 msgid 身份驱动增量快路 —— 全量重新开发(前代 #5576 线作废)| fastpath v6: msgid-identity-driven incremental fastpath, full rework[/+] on Nov 4, 2026
  2. changed the title [-]feat(fastpath): v6 msgid identity-driven incremental fastpath — full rework (previous #5576 line voided) | fastpath v6: | feat(fastpath): v6 msgid 身份驱动增量快路 —— 全量重新开发(前代 #5576 线作废)| fastpath v6: msgid-identity-driven incremental fastpath, full rework[/-] [+]feat(fastpath): v6 msgid identity-driven incremental fastpath — full rework (previous #5576 line voided) | fastpath v6: | feat(fastpath): v6 msgid identity-driven incremental fastpath — full rework (previous #5576 line voided) | fastpath v6: | feat(fas…[/+] on Nov 4, 2026
  3. ranxianglei commented on Nov 4, 2026

    @ranxianglei
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

    查重: 不重复。前代实现线 #5576 已由 owner 关闭作废(本 issue 契约第一条即其替代);open/closed 全量检索无其他同机制(msgid 身份驱动增量快路)在途条目。本 issue 是 v6 的唯一实施契约。

    标签: dsh pi opencode omp(涉及的全部插件车道,dsh threads 模型为主战场)+ scope/wiring(请求管道快路车道 + 统一存储三表)+ p3(性能/内存加固型 feature,当前用户面无可感知缺陷——#5403 OOM 对已有 v5 水位兜底;不打 bug:功能请求非缺陷)。

    开工确认(按契约执行,单一 PR、干净分支自最新 master 23a826d37、零移植旧分支代码):

    1. §4.1 三表落存储 schema v10→v11:pf_rows(sid,pos,ledger_id,core_id,core_json,ts) 数据平面 + pf_log/pf_ckpt LSM 元数据平面,走 sidecar(Storage layer: four concrete defects (filename coupling, multi-writer heuristic, non-atomic content-store write, immortal compressed sessions) #2671/Web UI first paint stalls 78-180s+: /__bili/overview cold scan blocks the event loop, and the freeze itself feeds the respawn churn #3199),随 kernel session 删除级联清理;
    2. §3.1 L1 身份薄表:pf_sid 铸造/匹配三规则(回显头 → ledger_id 全局索引探针 → 新铸合法冷启动),client sessionid 降级为纯诊断;
    3. fastpath.ts L3 判决重写为「(元素位 × id × 宽度)」纯函数,§5 每轮流程 + §6 事件矩阵全行覆盖(客户端压缩只动元数据平面、摘要永不注入、未知角落走默认①身份边界);
    4. §8 测试矩阵 19 例(含 hydration P6、折叠渲染 P7/P8、熔断恢复、归档保留 P8);
    5. rollout 开关 watermarkV6MsgId 默认 OFF + env override,与现有 pluginFullResendWatermark 并存;v5 字节门保留为诊断+兜底层,不删。

    待决项 ①②④⑤ 按契约默认值执行(未知角落=身份边界 / 原位编辑不可见 / sidecar 不可用=降级现状 / log 压实物理删除),owner 随时可否决,推翻即改。PR 落地后按八问回归报告。开始实现。

  4. changed the title [-]feat(fastpath): v6 msgid identity-driven incremental fastpath — full rework (previous #5576 line voided) | fastpath v6: | feat(fastpath): v6 msgid identity-driven incremental fastpath — full rework (previous #5576 line voided) | fastpath v6: | feat(fas…[/-] [+]feat(fastpath): v6 (sessionid,msgid) 复合身份驱动增量快路 —— 全量重新开发 | fastpath v6: composite-identity-driven incremental fastpath, full rework[/+] on Nov 4, 2026
  5. changed the title [-]feat(fastpath): v6 (sessionid,msgid) 复合身份驱动增量快路 —— 全量重新开发 | fastpath v6: composite-identity-driven incremental fastpath, full rework[/-] [+]fastpath v6: composite-identity-driven incremental fastpath, full rework | feat(fastpath): v6 (sessionid,msgid) 复合身份驱动增量快路 —— 全量重新开发[/+] on Nov 4, 2026
  6. ranxianglei commented on Nov 4, 2026

    @ranxianglei
    OwnerAuthor

    Implementation landed: PR #5652 (2026-11-04_fastpath-v6-msgid, from clean master — no #5576 code ported).

    Scope delivered against this contract: hard identity pre-gate with four fault classes and zero-side-effect rejection (§3.2), composite-key matching with server-minted pf_sid worlds (§3.1), set-difference-only judgment over the full element-id list (§5), scattered-NEW incremental parse with absolute _N/wire-index rekeying, compaction-as-pure-ignore (§6.1), schema v11 sidecar plane pf_rows/pf_log/pf_ckpt with single-transaction row+log commits and fold(ckpt⊕log) semantics (§4.1), client full-list wire form + x-bili-pf-session echo, rollout feature watermarkV6MsgId default OFF (nested cohort under pluginFullResendWatermark), §8 test matrix incl. 3× restart across an L1 fold hydration oracle, and session-deletion cascade.

    Local pre-flight: tsc clean, targeted suites green; two pre-existing sandbox failures (claude-native port, storage golden drift) verified identical on pristine master. Full-suite verdict left to CI. Open defaults followed per §7-A (unknown corner → §3.2 rejection; soft-degrade without sidecar; physical log deletion after compaction with checksum guard) — vetoable before merge.

  7. ranxianglei commented on Nov 4, 2026

    @ranxianglei
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

    Confirmed — PR #5652 is real and matches the contract. I independently verified the landed branch before responding (I did not author or push it; commits are under your identity ranxianglei / bili-dev).

    Live state (GitHub API):

    Independent spot-check of the diff against load-bearing contract points (all pass):

    • §4.1 schema v11 — STORAGE_SCHEMA_VERSION = 11; pf_rows / pf_log / pf_ckpt created; idx_pf_rows_ledger ON (sess_raw, ledger_id) (the global "seen it?" probe index) + idx_pf_rows_core ON (sid, core_id) (block↔pos binding).
    • §9 rollout — watermarkV6MsgId: { percent: 0, base: "pluginFullResendWatermark" } = default OFF, nested cohort under the existing watermark flag, env override intact.
    • §3.2 / lane core — PfV6IdentityFault (terminal identity fault, zero-side-effect rejection), 5-consecutive-fault breaker → 60 m park (pf:v6-guard), randomBytes-minted pf_sid worlds, metadata = fold(ckpt, log-after-ckpt) with checksum.
    • §4.1.6 cascade — deleteSession reads session_ext['pf:v6-sids'] before sweeping and cascades all bound sids.
    • §8 matrix — present incl. the §8-16/19 restart-hydration row (3× boot across an L1 fold, post-restart view byte-identical to pre-restart).

    Positioning / loop guard: I had been doing parallel local exploration of this same contract while working the issue — it is uncommitted and was never pushed. Since the complete implementation already landed as #5652 under your identity, I will not open a competing second PR (one issue → at most one PR; a duplicate would only create conflicting churn). My local tree is superseded; say the word and I'll discard it.

    Open items are yours to drive: mergeable_state: blocked = needs review sign-off + green CI (merge is human-only either way). Happy to run a deeper line-by-line review pass over the 2033-line diff, or targeted local repros of specific §8 rows, if you want a second set of eyes before you veto-merge.

  8. ranxianglei commented on Nov 4, 2026

    @ranxianglei
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

    收工判定: 本 issue 的实施已由 PR #5652 完成并落地(owner 身份提交,4 commits / 19 files / +2033−59,干净切自 master 23a826d37)。我已完成独立核验(schema v11 三表+索引、rollout 默认 OFF 嵌套灰度、§3.2 身份预门+熔断、fold(ckpt⊕log)、会话删除级联、§8 测试矩阵含跨 L1 fold 重启水合——全部与契约一致),详见上一条确认回复。按「一 issue 一 PR」纪律我不再另开 PR;本地并行探索的未提交代码已作废,需要我清掉说一声。剩余动作(review 签核 + CI 全量判定 + merge)在 owner 侧。

  9. 53 remaining items

  10. ranxianglei commented on Nov 7, 2026

    @ranxianglei
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

    收到新状态:v6 全线撤回已确认,issue reopen 等重设计。独立核验结果附上。

    ✅ 独立核验(刚对 origin/master @ bebc239f2 实跑):

    ⚠️ 唯一残留(记录在案,无需动作):Nov 5–7 上线窗口内若有个别实例手动开过 watermarkV6MsgId=1,其本地库会留有 pf_rows/pf_log/pf_ckpt 三张孤儿表且 user_version=12;升级到回滚后 master(v11)时迁移只前进不后退,三表成为无代码引用的死字节——无害,DB 重建自然消失。

    我的立场:不擅自启动重设计——功能类 triage 规矩,范围由 owner 拍板(FLOOR 48 已写明「重设计以独立形态启动,范围由 owner 拍板」)。本 issue 沉淀的裁定(目标函数=稳定性/扩展性/通用性、固定链「原始字节→通用核→内核改写→快照应用→目标协议→出站」、校验点只落内核内部状态与改写后核形态、结构事件走规范链、零迁移窗口、附录二事件写回时序)继续作为重设计基准,全部保留在 issue 正文里。你定了范围后,我可以先交一份方案对比/评估(各候选路线如何满足保留裁定、上一版在哪一维失败),拍板后再进实现。

    卫生:我的工作区还留着最初实施阶段的未提交探索代码(fastpath-v6.ts 等,从未推送)。目标设计既已撤回,我现在清理并把工作区重置到干净的 origin/master 状态。

  11. ranxianglei commented on Nov 7, 2026

    @ranxianglei
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

    定位纠正收到,线程记录已更新:这条线不是「增量车道」,是新的基于快照表的压缩底座(新存储为主)——压缩算法内核(折判定/摘要/prompts/ref 契约)不动,动的是状态存取底座(kstate JSON/hydration/save 换挂行表,pos↔内容哈希 id 翻译在 bili 存储桥层,kernel/ 零改动);有 session+msgid 的宿主全走此路,无 msgid 按顺序>hash 降级身份通道、同一套表;#5855 只是工程基底非终态。issue 标题里的 "incremental fastpath" 措辞随本纠正作废(标题归系统管道所有,我不改)。

    ✅ #5855 核验("Re-land v6 lane — inverse of #5854 revert (base for snapshot-centric rework, #5643)"):open / mergeable_state: blocked(等 review),head 8d5f069 @ 2026-11-07_reland-v6-lane,base master,1 commit / 35 files / +5822−125。CI 镜像缓存当前在 head 上 30/30 零失败零 pending(我上一刻抓到过一瞬的 3 failed 快照,随后刷新即消——是被取代 run 的中间态,未深挖;若复现再说)。

    三个待裁定项的参考意见(明确推荐、非拍板,决策在你):

    ① 折叠覆盖格行生命周期——同意建议方案(标 inactive 保留双形态供 decompress,GC 再物理清)。与内核 lossless round-trip 结构不变量及既有 dead_refs+GC 批量清扫纪律同构。一个微调建议:物理清空的触发条件绑定到覆盖块的生命周期(该格所在 block 本身被归档/删除时才允许 GC 该行),不用全局 TTL——否则 decompress 引用窗口和 GC 窗口需要额外对齐证明。

    ② 宿主自行变更历史的无见证漂移——推荐分级处置,不要永久关死。理由:这现在是底座不是可选快车道,可用性大于性能(#3128 规矩);且表设计上就是「一次全量 pass 可廉价重建」的(零迁移窗口性质),永久关死浪费了这个便宜。具体:(a) 身份级有证据(宿主自己重发的 msgid 列表与账本 diff 得出布局变化)⇒ witnessed resync=强制恰好一轮全量对账 + 单事务重建受影响段;(b) 真无见证的字节级漂移⇒ sid 级弃表 + 下一 arm 轮全新重建 + 熔断计数;(c) 永久关死只留作反复循环后的最后手段。不变的前提:tripwire(出站字节必须与全量路径逐字相等)仍是最终护栏——漂移状态下供出陈旧前缀字节=缓存投毒,任何 resync 策略都不能绕过这道逐字校验。

    ③ 无 msgid 降级边界——推荐 count-geometry 为骨架(v6 线已验证的 KEY COROLLARY:增量正确性由计数几何保证,id 只是辅助证据,全 ? 槽位+有效计数也照样正确解析尾窗)。边界行为具体化:模式每会话粘滞,进入 msgid 模式需一致 id 打标证据(按车道白名单纪律,同 dshPersonaFingerprintApplies 的证据门槛);? 槽位走顺序通道拿序数 pos,不阻塞邻居的 id 解析;会话中途换模式=一次 resync,禁止静默混用。

    卫生:工作区清理已完成——初版探索代码(fastpath-v6.ts 等 3 个未跟踪文件)已删,8 个改动文件已还原,分支 reset 到干净 origin/master @ bebc239f27(#5854 回滚点),status 除平台目录外全净。

  12. ranxianglei commented on Nov 7, 2026

    @ranxianglei
    OwnerAuthor

    (ai: sglang-gpu0/qwen3.8-27b)

    设计草案 v0.1:Snapshot 中心底座 —— 纯新增 LSM 表族,现有存储零改动

    状态:待逐条裁定,未动工。本阶段不触发压缩、不写实现。批准后从 P0 开始。

    0. 锁定的边界(按 11-07 裁定原样落字)

    1. 现有存储零改动:12 组既有表的结构、行、读写代码一律不动;messages、内容 CAS、blocks、refs/dead_refs、checkpoints、kstate、CCR、kv、conversations、media 原地继续服务。此前「把 messages 升级成快照行表」「退休 kstate」等提法全部收回作废。
    2. 快照表是独立 LSM:行表 + 追加事件日志 + meta checkpoint,直接沿用刚经 [PR] Re-land v6 composite-identity fastpath lane — inverse of #5854 revert (base for snapshot-centric rework, #5643) #5855 合回的那套三件套模式(行 PK(sid,pos)、单事务事件追号、S4 校验和的 ckpt 在 compaction 时吸收自身日志),持久化走 WAL 单写者——就是你问的「我们不是已经有 lsm 设计了吗」,这套骨架已合入且有回归钉。
    3. 内核零改动:pos ↔ 内容哈希 id 的翻译全部放在 bili 存储桥层;acp-kernel 一个文件不碰,无人工评审门槛开销。
    4. 纯加法才可回滚:撤销 = DROP 三个新表 + 关旗,行为逐字节回到今天;无迁移、无反迁移,因为没动过任何东西。
    5. 宿主自带压缩不特殊处理:多数被拦截;拦不到的只看增量 msgid;最差我们 snapshot 多一条小摘要行,无影响。
    6. 适用面:凡有 session + msgid 的系统都走这一套;无 msgid 系统理论可接入(接入面留到后续裁定)。

    1. 全链路(目标数据流)

    入站: 客户端重发历史 (session id + 每元素 msgid 信封)
           │ 协议转换 → 通用核形态(inbound form)
           ▼
    身份平账: msgid 定身份, abs pos 只增不复用   ← 现有 ledger/messages 继续兜底, 不新建账本
           │ 每轮判定 = msgid 成员集合差(增量)
           ▼
    ┌─ snapshot LSM 表族 (纯新增) ─────────────────────────────────────┐
    │ snap_rows  (sid, pos, …)                 行表 = 最新合成版本      │
    │ snap_log   (sid, seq, kind, payload)     追加事件日志, 单事务编号 │
    │ snap_ckpt  (sid, meta, checksum)         meta 检查点, S4 吸收日志 │
    └──────────────────────────────────────────────────────────────────┘
           │ 内核改写(压缩) = 对表的单事务 I/U/D 事件(覆盖行失效 + 摘要行落位)
           ▼
    出站: 存活行按 pos 排序 ++ 本轮尾窗 → 目标协议映射(每轮全新) → 发送
    红态: 任何校验不过 → 整轮退回今天的旧路径(旧表, 逐字节一致), 降级不猜
    

    关键点:只要表里行不物理删除,snapshot 本身就是全量数据(你的原话定调);所谓「引入 log」的本质 = snapshot 最终是 log+meta 压实成的最新快照(LSM 合成语义)。

    2. DDL 草案(新增版本块 v13:老库升级只跑 CREATE,不碰任何旧列)

    CREATE TABLE snap_rows(
      sid        TEXT NOT NULL,
      pos        INTEGER NOT NULL,     -- ledger abs pos, 只增不复用; 失效不全局重编号
      core_ids   TEXT NOT NULL,        -- 该元素绑定的内核 msg id ("|" 连接), 对齐身份账本的键
      pre_json   TEXT,                 -- 入站通用核形态 (是否必存见裁定 A)
      post_json  TEXT NOT NULL,        -- 改写后通用核形态; 出站前缀直接来源; 永不存映射后的 wire 字节
      active     INTEGER NOT NULL DEFAULT 1,
      ts         INTEGER NOT NULL,
      PRIMARY KEY(sid, pos)
    );
    CREATE TABLE snap_log(
      sid TEXT NOT NULL, seq INTEGER NOT NULL, kind TEXT NOT NULL,
      payload_json TEXT NOT NULL, ts INTEGER NOT NULL,
      PRIMARY KEY(sid, seq)
    );
    CREATE TABLE snap_ckpt(
      sid TEXT PRIMARY KEY, ckpt_seq INTEGER NOT NULL,
      meta_json TEXT NOT NULL, checksum TEXT NOT NULL, updated_at INTEGER NOT NULL
    );

    不变量:

    • (i) 单会话单写者,一切写都走同一个提交原语;
    • (ii) log 序号严格大于 max(log.max_seq, ckpt.ckpt_seq),单调、永不重排;
    • (iii) S4 = sha256(meta_json),校验失败 = 该 sid 平面永久关死并整体回落旧路径(红线,沿用已验证纪律);
    • (iv) 行不物理删除(v0 阶段),折叠 = active=0 标记;物理清理属裁定 B;
    • (v) post_json 恒为改写后通用核形态:model/maxDim/toolArmed 等只是每轮映射输入,从不入表、不参与快照有效性——所以族内切模型不需要任何事件。

    3. 写路径(方向唯一:内核/压缩事件 → 新表;反向永不发生)

    • 提交原语(单一入口),形状同已合入的 pfRenderCommit:单事务内 [可选清空重建] → upsert 行 → log 追号 → [可选] 折 ckpt(写新 meta+checksum,随后吸收自身日志)。任何疑点抛错即整轮放弃、不落半态。
    • 事件词汇(最小集):cast(车道首次装载)/append(新元素)/update(改写落位或摘要就地覆写)/delete(覆盖行置 inactive,载荷 = pos 列表)/compact(ckpt 吸收)。
    • 压缩事件的 diff 语义:覆盖 pos 集合 = 引擎输出的覆盖范围 ∩ 身份账本绑定(core_ids join)——就是你说的「结构变更 = 压缩引擎输出的行,很好找」。一次压缩 = 一次单事务 {delete 覆盖段 + update/append 摘要},下一帧出站即刻生效,没有补偿轮、没有中间状态。
    • 见证规则:一切结构变化的主证据 = 客户端 msgid 成员集合差(增/减/换一眼可见);「无见证漂移 → 关死」降格为最后手段,只在真异常(校验和坏、链断裂)时触发,按你裁定的口径执行。

    4. 读路径(消费面切换,全部是新读者,旧读者原地不动)

    • 出站绿轮:mapEgress(存活行按 pos 排序 ++ 本轮尾窗);前缀字节跨轮稳定 ⇒ 缓存友好。旧版拼缝/tripwire 机器的绝大部分可以退役,仅保留逐字节核对作为红线守卫。
    • hydrate(喂内核的输入):绿道从新表取入站形态重建内核输入;红道 = kstate 旧路,原样保留、随时承接。
    • decompress / export / UI / 媒体 / 计费:接口逐步切读新表;旧表同时保留作回退源,直到最后一类消费者完成切换再单独裁定去留。
    • 客户端协议面收缩(后续阶段,不在本期):msgid 信封保留;x-bili-pf-* 握手头堆叠大部分可以删掉(它们的存在前提是旧的两级快路径)。

    5. 灰度与回滚

    • 两级嵌套开关(master 旗 ⊃ lane 旗)默认全关,按会话分桶,复用现成 rollout 设施;新表在旗关期间不存在于热路径。
    • 摘除 = DROP 三个新表 + 关旗,立即回到今天的行为;无需数据修复步骤(因为我们从未写旧表)。

    6. 测试矩阵(全 hermetic,门闸类断言一律双向)

    1. 升级纯加性钉:老库升级 v13 前后,既有全部表逐字节一致(防「顺手改了一列」)。
    2. 事件事务单元:单事务 I/U/D、log 编号单调、ckpt 吸收、S4 篡改 ⇒ 该 sid 永久关死且整体回落。
    3. A/B 字节级:新道 vs legacy 道,N 回合真实语料,出站字节除时间戳属性外逐字相同。
    4. 回滚演练:DROP 新表 ⇒ 立刻 legacy 行为,无残留影响。
    5. CI:复用 docker bili-gate 的 A/B 方法;决策矩阵(lane-decisions)每加一行工具形/车型都配正负两条。

    7. 分期(批准后才启动,每步可独立回退)

    • P0:DDL + 提交原语 + 上述 1/2/4 三项测试 —— 行为零变化,纯铺底;
    • P1:影子写(只写新表、不读它),长跑验证事件正确性与体量增长曲线;
    • P2:选一条车道做 hydrate/egress 切源灰度(A/B 字节钉全程在场);
    • P3:其余消费面(decompress/export/UI/计费)逐个切换。

    8. 待你裁定(每条附倾向,不同意就直接说)

    • A. 行内存几种形态? ① 双形态都存(pre+post,自足但体量近翻倍)② 只存 post,pre 照旧引用现有 messages/CAS(省体量、符合「已有的别重复」;代价是 decompress 审计跨两表)。我倾向 ②。
    • B. 失效行(active=0)保留多久? ① 永不清理:全量绝对成立,但表随会话历史单调增长(与 0.1.200 → 0.1.201 upgrade (#3658 identity change) mass-unfolds persisted sessions incl. Anthropic lane; downgrade re-churns #3752 烧过的「状态只增」红线同源)② ckpt compaction 时按策略物理清理:控住体量,但要给定保留期。现有 messages 表的 retired_at 软标记+最终 GC 是既有的同类先例。需要你显式拍板,我不代拟默认值。
    • C. 摘要行落位:① 摘要以 U 事件就地占据覆盖段首 pos(段内其余行置 inactive):出站相对顺序不变,前缀缓存不碎 ② 摘要取自己新到的尾部 pos 并在 meta 记 replaces:语义更直白但序列位置靠后。我倾向 ①(也是 PK 不被撞的自然解法)。
    • D. 会话键空间:新表沿用现有 sid(桥接成本最低),还是独立命名空间?我倾向沿用。
    • E. 本期做到哪一步:只做 P0+P1(影子写验证、零行为面)就收手交验收,还是一口气做到 P2 单车道灰度?

    附:与已撤回工作的关系

    已撤回的「egress 视图层」实现不复活,它的零件只以两种身份回来:pf_* 三件套的事务骨架(已随 #5855 合回 master,本草案直接站在上面)与被实战检验过的测试方法论(A/B 字节级对比、docker gate 演练)。其余(水位握手头、补偿轮、端点 journal、splicing 机器)全部废弃,理由写在 #5854 复盘与本 thread。

  13. ranxianglei commented on Nov 7, 2026

    @ranxianglei
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

    设计草案 v0.1 收到,记录为重设计基线文档(待逐条裁定、未动工)。先报一个前提事实校正,再给 A–E 参考意见。

    ⚠️ 前提事实校正(刚查 API):草案 §0.2 说 pf_* 三件套「已随 #5855 合回 master」——#5855 目前仍 open/未合入(head 8d5f069,CI 30/30 绿,但 mergeable_state: behind:master 已前进到 fb18e7e4c4,需先同步)。当前 origin/master 的 schema 仍是 v11(#5539),pf_ 表不在。推论:①「骨架已合入且有回归钉」暂不成立;② 草案的 v13 版本号隐含 #5855 的 v12 先行——P0 的 DDL 工作应排在 #5855 合入之后(或叠在其分支上),否则版本块编号要重排。建议先把 #5855 同步到最新 master 并合掉,再启 P0。

    A–E 参考意见(明确推荐、非拍板):

    A. 行内形态——同意倾向 ②(只存 post)。pre 形态在既有 messages/CAS 里已有持久化(边界 1 规定它们原地继续服务),复制一份体量近翻倍换零新能力。附加条件:与 B 联动——被存活 snap 行引用的 pre 字节必须活得比该行久(GC 顺序耦合),否则 decompress 审计路径要有「pre 缺失→诊断降级」的显式出口,不能静默空引用。

    B. 失效行保留——推荐 ②(compaction 时物理清理),策略绑定生命周期而非全局 TTL。保留期 = max(覆盖摘要/块的生命周期, 消费方引用窗口[decompress 审计/计费引用]),在 compaction 时逐格判定。反对 ①(永不清理)的理由很硬:单调无界增长正是 #3752 烧过的红线,owner 修订已把「存储只增不减失控增长」列为 p1 类——长会话下 snap_rows 会重演这个事故。messages 表的 retired_at 软标记+最终 GC 是现成同类先例,照搬其判定框架即可。此项草案明确要求你显式拍板,以上仅供决策输入。

    C. 摘要落位——同意倾向 ①(就地占据段首 pos)。出站相对顺序不变=前缀缓存不碎,这是整个底座的存在理由;也是 PK 不撞的自然解。补一条要钉死的:delete 事件的 pos 列表载荷会被 ckpt 吸收掉,所以 ckpt meta 必须在吸收后保留显式覆盖映射(摘要 pos → 被覆盖 pos 区间),decompress/GC 不能只靠位置推断——否则日志压实一次,覆盖关系就只剩隐式约定了。

    D. 会话键空间——同意沿用现有 sid。独立命名空间=身份管道翻倍+会话生命周期出现第二事实源(删除级联要跨两个键空间);沿用则 deleteSession 级联平凡化,单写者纪律不破。

    E. 本期范围——推荐只做 P0+P1 就收手交验收。这条线刚经历整线撤回,信任要增量重建:P0+P1 是零行为面(影子写不被读),恰好证明事件正确性+体量增长曲线这两个此刻最不确定、且错了最贵的东西;P2(真实 hydrate/egress 切源)是字节对等风险集中点,值得独立 PR+灰度 cohort 在你观察下走(#5403/#5576 的教训都是小流量先行)。P2/P3 等 P1 长跑数据落地后另开 PR。

    全部为参考意见,拍板在你。裁定落地后 P0 实施可指派给我(或支援任何接手的 agent)——工作区已在干净 master 待命。

  14. changed the title [-]Snapshot中心化的压缩底座:单行表真源 + 压缩=对表的增删改事件(非增量车道,#5652/v6 线定位纠正)[/-] [+]Snapshot-Centric Compression Foundation: Single-Row Table as Source of Truth + Compression = Insert/Delete/Update Events | Snapshot中心化的压缩底座:单行表真源 + 压缩=对表的增删改事件(非增量车道,#5652/v6 线定位纠正)[/+] on Nov 7, 2026
  15. ranxianglei commented on Nov 7, 2026

    @ranxianglei
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

    收工:本回合工作=设计草案 v0.1 评审(FLOOR 57 已发:#5855 前提事实校正 + A–E 五条参考意见,拍板在你)。当前无在途代码动作;等你对 A–E 逐条裁定(尤其 B 需你显式拍板)+ #5855 同步合入后,P0 随时可启动。

  16. ranxianglei commented on Nov 7, 2026

    @ranxianglei
    OwnerAuthor

    (ai: sglang-gpu0/qwen3.8-27b)

    快照表压缩底座:正式提案已出稿,docs-only PR 提交,Discussion 已建。

    按上面定位纠正评论(本线 = 基于快照表的压缩底座,内核不动,非增量车道、非 v5 续作),缺口分析报告已整理成完整设计提案:

    更正上一条回帖:Discussion API 实际可用(GraphQL createDiscussion mutation),帖已直接建好,无需手动操作。按 owner 要求,目标图改为两张:主图是与 §2 现状图逐位对齐的全貌(两图并排即可看出改动落在全局哪块、影响范围多大),六段链内部流转另出「分阶段展开」附录图。以下保留可复制全文备查——四张架构图用锚定 commit 0aee319 的不可变 raw URL,任何位置粘贴都可直接渲染。

    ---- 粘贴开始 ----

    提案:快照表式压缩底座(六段固定链,单一存储真源)

    状态:设计提案,待 owner 裁定后开工。 未实施任何代码。
    基线: origin/master(写于 2026-11-07;存储 schema v11,#5854 已把 v6 整线撤出 master)。
    来源讨论: #5643(含定位纠正评论)。
    姊妹文档: English version。


    0. 摘要(TL;DR)

    本提案把上下文压缩的状态底座从「进程内存 + kstate JSON + 多张表」的平行真源格局,换成一套快照表作为唯一存储真源。每轮请求固定走完同一条链:

    原始字节 → 协议转换(通用核) → 改写(压缩) → 快照表应用 → 出站映射 → 出站

    压缩内核(折判定、摘要、prompts、ref/msgid 契约)零改动。有宿主 session+msgid 双信道的会话全部走新链路;没有 msgid 的宿主按「顺序 > hash」降级身份写同一套表。任何环节失步,该轮整体回落今天的 legacy 全量路径(降级,不猜)。回滚 = DROP 四张新表 + 关旗,逐字节回到今天。

    目标函数排序不变:稳定性 / 扩展性 / 通用性优先,性能是副产品——先问流转对不对,不问快不快。


    1. 背景与定位

    1.1 来龙去脉

    1.2 这条线不是什么(防止再次漂移)

    容易误认的方向 为什么不是
    增量车道(plugin-turn divert) 那条是「只传新增 delta」的请求形状优化;本提案每轮仍收全量重发,只是服务端不再对全量做无差别解析/存储
    v5 watermark 快路径的续作 v5 解决的是「解析成本」(戳握手 + 尾窗解析);本提案解决的是「状态真源」,v5 继续服务非 cohort 流量
    换内核/改折叠算法 内核零改动是硬约束;折叠判定、摘要、节拍、id 契约原样保留
    「快一点」的性能特性 性能收益(前缀缓存稳定、内存下降)是流转正确的副产品,不作为设计判据

    1.3 保留的基准裁定(继承自 #5643 正文,全文有效)

    目标函数排序、固定链、两处校验点(内核内部状态 + 改写后核形态)、行键 append-only、diff 只按内核管道证据寻址(禁模糊相似)、四件套保护(tripwire / S4 逐行校验和 / 见证要求 / 审计抽验)、客户端压缩纯忽略、P5–P9 五组不变量,全部沿用,不在本文重复展开;与本文冲突处以本节为准并在裁定表(§14)显式登记。


    2. 现状架构与三个结构性问题

    现状架构(位图备选:arch-current.png)

    今天的一条模型请求从入站到出站要经过:prepare-* 适配器 → lane-decisions 分轨(legacy 全量 / 增量 plugin-turn / v5 watermark 5%灰度 / D-lane 快照渲染 ≈0%灰度)→ 内核 → coreTo* 出站映射。状态住在三个地方:进程内存(lastMessages AST、常驻核数组)、统一 SQLite v11 表族、kstate JSON(经 mergeState() 水合)。三个结构性问题:

    1. 状态三处住(痛点①)——kstate JSON 与表是双通道分叉点;[Bug][dsh] 20k-message / 81 MiB-inbound session: host aborted 6× in 2 h — the #3050 resident-AST OOM is not bounded by sessions.hardMaxBytes (Windows, 0.1.210) #5403 OOM 的直接生产者就是 lastMessages 整包驻留;重启靠水合拼装,拼错即降级或烧会话。刚被撤回的那条线的根病正是这种平行真源。
    2. 身份不落盘(痛点②)——宿主的 (sess_raw, msgid) 对在 ingest 时剥掉,只活在 in-flight 信封里一轮。messages.msgId 列存的是 bili/内核自己的规范 id,宿主的原始身份没有任何表承载。「这个元素见过没?」跨进程、跨重启无法回答(P8 要求恒可答),于是每轮都冷启动重新探测。
    3. 快路径各自打补丁(痛点③)——v5 / 增量车道 / D-lane 各管一段流量,缓存稳定性靠多层补丁堆叠;任何一层失步就是缓存投毒或整体回退。没有一个单一存储真源兜底。

    3. 目标架构总览

    全貌与 §2 现状架构图逐位对齐,直接对照即可看出改的是全局哪一块、影响范围多大(灰 = 零改动 · 青 = 新增段/表 · 琥珀 = 角色变更 · 红虚线 = 兜底安全网):

    目标架构(位图备选:arch-target.png)

    六段固定链自身的内部流转 —— 分阶段展开(提交原语 / DDL chip / 降级红门 R1–R4 / 共存路由与回滚灰度):

    分阶段展开(位图备选:arch-stages.png)

    现状图里的每一块在新架构下变成什么样子 —— 组件迁移总览(底部为三个结构性痛点的一一对应解决锚点):

    组件迁移总览(位图备选:arch-migration.png)

    六个阶段的职责一句话版:

    # 阶段 一句话 状态
    0 入站·身份入册 双信道身份 + L1 世界匹配,决定这轮每行的出身 新增
    1 协议转换→通用核 wire 矩阵现成复用;只对身份差集 NEW 元素做 span 解析 现成 + 一个新回归钉
    2 改写/压缩 内核一行不改,产出结构化事件;落表时序按附录二 内核零改动
    3 快照表应用 单事务提交原语写入 snap 三件套(rows/log/ckpt);ckpt meta 携带内核态+覆盖映射+S4 新增核心
    4 出站映射 存活行按 pos 排序 ++ 尾窗新解析;双 carrier 分支 读侧重建
    5 出站 tripwire 抽样比对后放行上游 守卫强化

    横切两条:红门降级带(§7,任何疑点回落 legacy)与共存路由(§8,每种流量只有一个家)。


    4. 六段固定链逐段设计

    4.0 第 0 段:入站 · 身份入册(现状中不存在的一段)

    输入:原始字节体 + 双信道身份——请求头里的 sess_raw(宿主会话 id 原值)+ 逐元素 msgid[] 信封。采集直接消费 #5842 已合入的载体 resolver 输出(shim / pi entry-walker / opencode transform 钩子 / codex / cc / gemini 六候选载体),不建第二套采集系统。

    世界匹配裁决(顺序执行,第一个命中即止):

    1. echo 直中 + 抽验:宿主回带的 id 列表与服务端正史逐位吻合,抽样见证核对通过后直接采用;
    2. 复合探测:(sess_raw, msgid) 在 L1 表中探测命中 ⇒ 沿用既有账本身份;
    3. 发放新身份:都没命中 ⇒ 发放新账本 id 并记入 L1,付一轮武装(本轮该元素只进不入缓存决策)。

    cohort vs 降级的边界(裁定 I,见 §14):声称具备双信道的 cohort 宿主某轮收不齐 id = 故障,硬拒绝 + 零副作用 + 喂 breaker(baseline §3.2 原样);天生没有 msgid 的非 cohort 宿主走「顺序 > hash」粘滞降级通道,写同一套表(pos 由序位发号);模式每会话粘滞,中途换模式 = 一次显式 resync,禁止静默混用。

    L1 表(G 裁定的承载体):l1_world(sess_raw PK, ledger_id, …),全局可跨重启查询;原值禁截断(P9),sig/fingerprint 只进 warn 诊断流永不入判决(P8/P9)。

    4.1 第 1 段:协议转换 → 通用核(现成复用)

    4.2 第 2 段:改写 / 压缩(内核零改动)

    acp-kernel 保持一行不改:折叠判定(projectUnit 共享投影)、四条 prompts、nudge flat-50K 节拍、ref/msgid 永不复用契约。它对外的输出在本设计中定义为结构化事件流:

    cast     首次铸入行(新会话首载)
    append   新增行(新回合尾部)
    update   行内形态变更(如 tool result 回填)
    delete   覆盖/失效(active=0,不物理删)
    compact  折叠压实(块吸收覆盖段,meta 更新覆盖映射)
    

    事件寻址规则沿用 baseline:只按内核管道证据(block 覆盖区间 / ledgerSeq / 帧边界)定位受影响行,禁止任何模糊相似匹配;对不上 ⇒ 该轮不产事件、整轮走 legacy(§8 R2)。

    落表时序(以 #5643 附录二为准):第一现场 = 插件端点 POST /__bili/plugin/tool(src/server/admin.ts:797)在当次请求内同步单事务完成事件→表修改;下一轮模型请求只做核对。绕过端点的宿主(dsh native compaction 一类)由 checkpoint 帧签名 + rebase 检测喂同一个表修改例程兜底。端点到落表之间平面挂 structural-pending 标记;进程重启丢失标记 = 保守判死(fail-safe 方向,§8 R4)。

    4.3 第 3 段:快照表应用(本提案主体)

    提交原语 = 单事务,内含三步:

    upsert snap_rows(按证据寻址的行)
      → 追加 snap_log(seq 严格 > max(log.max_seq, ckpt_seq))
        → (可选)折 snap_ckpt(吸收 log 载荷,更新 meta)
    任一步抛错 ⇒ 整轮放弃,不留半态(不变量 i)
    

    不变量表(草案 v0.1 起、review 补强后沿用):

    # 不变量
    i 单会话单写者:所有表修改只经这一个提交原语
    ii log.seq 严格单调:> max(log.max_seq, ckpt_seq),跨压实不断号
    iii S4:逐行校验和不符 ⇒ 该 sid 平面永久关死,整体回落旧路(红线不变)
    iv 行不物理删除:折叠只翻 active,pre/post 双形态保留供 decompress
    v post_json 恒为「改写层右侧的通用核形态」——缓存永远不允许 wire 字节

    ckpt.meta_json 三件套(F+C 裁定的合流):① 内核会话态(CompressionState:blocks/refs/deadRefs/nudge/tokenSnapshot/…)序列化 + 自身校验和——内核没有确定性「事件流→状态」重建入口,序列化随 checkpoint 走是唯一既零改内核又满足 P7(内存只是缓存)的方案;② 覆盖映射(摘要 pos → 被覆盖 pos 区间)——delete/compact 载荷会被 ckpt 吸收,压实之后 decompress/GC 的唯一依据就是这份显式映射;③ S4 聚合校验和。

    失效行生命周期(B 裁定建议):inactive 行保留至其覆盖块本身被归档/删除时一并物理清理;反对永不物理清(#3752 单调无界增长是 p1 红线)也反对全局 TTL(GC 窗口和解引用窗口不用额外对齐证明)。

    4.4 第 4 段:出站映射

    mapEgress = 存活行按 pos 排序取核 ++ 尾窗 [K..T) 本轮新解析的核,再过 coreToX 到目标协议族。前缀跨轮字节稳定 ⇒ 前缀缓存友好(这就是目标函数,不是巧合而是结构保证)。

    • 双 carrier 分支(会话粘滞绑定,两模式必须同时想清——本仓库惯犯病类 [Bug] ACP: ≥2 compressed blocks render as multiple system messages → SGLang (vLLM-compatible) upstreams return 400 #377):pluginMode 抑制 tool+nudge 注入(agent 本地执行压缩);proxy 模式 acp_summary revoice 为 user 消息(systemToUser,保护头部 system 逐字稳定)。
    • 透明变化(不是红条件):跨协议族切模型、maxDim 变、toolArmed 变——都只动映射输入。因为快照只存改写右侧的通用核形态,族切换天然透明。
    • 失步处理:join 链断 / 对不上 ⇒ 该轮整条 legacy 全量路径并重新盖戳(客户端一轮收敛)。

    4.5 第 5 段:出站

    tripwire 运行期形态(J 裁定建议):低比例抽样把出站字节与 legacy 全量路径产物逐字比对(除 time attr)。一致放行;不一致 ⇒ 该会话立即摘回 legacy + 告警。最终护栏防的是「漂移状态下供出陈旧前缀 = 缓存投毒」。

    协议卫生:pf-* / 信封类握手头是协议头不是 hop 头,转发上游前剥掉(UPSTREAM_HOP_HEADERS 白名单纪律);本提案引入的任何新握手头同样进白名单管理。灰度期全程 A/B 字节钉在场。


    5. 存储 schema(提案骨架,P0 契约定稿)

    版本叠加规则:#5855 合并落地它自己的 schema 版本(草案假定 v12)之后,本方案在其上再升一版(v13+);老库升级纯 CREATE ... IF NOT EXISTS 加性变更,无数据迁移。DDL 骨架(精确列型留待 P0 契约评审):

    -- L1 身份薄表(裁定 G 的承载体;baseline §4.1.1 的两列恢复为独立表)
    CREATE TABLE IF NOT EXISTS l1_world(
      sess_raw      TEXT    NOT NULL,         -- 宿主会话 id 原值,禁截断(P9)
      ledger_id     TEXT    NOT NULL,         -- bili 规范 sid(沿用现有键空间,裁定 D)
      witness_probe TEXT,                     -- echo 抽验见证样本(仅诊断流)
      issued_at     INTEGER NOT NULL,
      armed_at      INTEGER,                  -- 新身份发放的武装轮标记
      PRIMARY KEY (sess_raw)
    );
    CREATE INDEX IF NOT EXISTS idx_l1_ledger ON l1_world(ledger_id);
    
    -- 行表:正史本体
    CREATE TABLE IF NOT EXISTS snap_rows(
      sid         TEXT    NOT NULL,
      pos         INTEGER NOT NULL,           -- ledger 绝对位置,append-only 永不复用
      core_ids    TEXT    NOT NULL,           -- 通用核元素 id 序列(json text)
      pre_json    TEXT,                       -- 改写前形态引用(CAS digest),裁定 A② 默认引用不内嵌
      post_json   TEXT    NOT NULL,           -- 改写后通用核形态(唯一允许被缓存的形态)
      tokens_est  INTEGER,                    -- 估算 token(裁定 L:判决面增长数据源 + 计费共用)
      active      INTEGER NOT NULL DEFAULT 1, -- 0=被覆盖/失效(保留供 decompress,生命周期见 §4.3)
      cover_ref   TEXT,                       -- 覆盖它的摘要块 id(物理清理的生命周期锚)
      updated_at  INTEGER NOT NULL,
      PRIMARY KEY (sid, pos)
    );
    
    -- 事件日志(LSM log 层)
    CREATE TABLE IF NOT EXISTS snap_log(
      sid        TEXT    NOT NULL,
      seq        INTEGER NOT NULL,            -- 严格 > max(log.max_seq, ckpt_seq)
      kind       TEXT    NOT NULL,            -- cast|append|update|delete|compact
      payload    TEXT    NOT NULL,
      created_at INTEGER NOT NULL,
      PRIMARY KEY (sid, seq)
    );
    
    -- 检查点(LSM meta 层;吸收 log 载荷并显式保留覆盖映射)
    CREATE TABLE IF NOT EXISTS snap_ckpt(
      sid        TEXT    NOT NULL PRIMARY KEY,
      ckpt_seq   INTEGER NOT NULL,
      meta_json  TEXT    NOT NULL,            -- 内核态序列化 + 覆盖映射 + 自身校验和
      checksum   TEXT    NOT NULL,            -- S4 聚合校验和
      updated_at INTEGER NOT NULL
    );

    写模型假设(H 裁定项):默认单进程假设(WAL 天然串行化跨进程写);若要多实例并发写,需附内存视图失效协议(常驻核数组/元数据缓存谁作废谁通知)——P0 契约里二选一钉死。


    6. 读路径与消费方切换台账

    hydrate 双道:绿道(新表可读且 S4 通过)从 snap_rows+meta 重建读视图;红道(开关关 / 无活跃块 / 表不可读 / 校验失败)原样走 kstate 旧路承接。切换按会话粒度、单向渐进,任何一道失步整轮回退 legacy——与 D-lane #3756 同纪律。

    消费方逐个标注(P0 列全清单,此处为主干):

    消费方 处置
    decompress(restore/decompress 工具路径) P3 切到新表 pre/post 双形态 + 覆盖映射;pre 字节缺失时必须走审计显式诊断出口,不得静默空引用
    export P3 切换;诚实输出纪律不变(#155:0-block 会话不许谎称「原始对话」)
    计费 tokens_est 列共用;切读源不改变计费口径
    Web UI(sessions 面板 / acp_status uncompressed view) acp_status 判决面(KDD#12 共享投影)输入源指到新表;面板新增表健康度指标(§11)
    kv_store namespaces / notice store / persona fork(|sub:<fp>) 不触碰(独立机制,fork 记录自己后缀 id 进同一车道即可)
    CCR(ccr_entries) P0–P2 不碰;P3 单独评估是否并入或长期并存

    7. 降级红门枚举(命中任一 ⇒ 该轮/该会话整体回落 legacy 全量路径并重新盖戳)

    # 红条件 后果
    R1 S4 / 校验和坏 该 sid 平面永久关死,整体回落旧路(底材损坏不可恢复,红线不变)
    R2 出站 join 链断(core_ids ↔ 行对不上,链回溯失败) 该轮不产事件,整轮 legacy
    R3 cohort 宿主身份门故障(收不齐双信道 id) 硬拒绝 + 零副作用 + 喂 breaker(baseline §3.2 原样)
    R4 structural-pending 未消费(含重启丢失标记) 保守判死(fail-safe 方向)

    不是红条件的:跨协议族切模型、maxDim 变化、toolArmed 变化、客户端压缩痕迹(纯忽略,只看增量)。把这组边界写成判定函数放进 lane-decisions 矩阵,每种组合正负成对断言(#3617 纪律)。


    8. 与既有车道的共存路由(每种流量只有一个家)

    流量 归属 说明
    cohort 宿主(有双信道)全量重发会话 新底座 本提案服务的主对象
    非 cohort(无 msgid)流量 v5 watermark 快路径继续服务 与本底座同表不同车道,旗位独立;「顺序>hash」降级写入走同一套表
    anthropic wire divert 回合 增量 plugin-turn 车道维持原职 dsh shim 逐回合二选一,互不双处理
    dsh native compaction 等绕过端点的宿主 第 2 段同一事件例程(checkpoint 帧签名 + rebase 检测喂入) 见 §4.2 时序
    #3756 D-lane 新底座就绪的车道让位退役(旗互斥) 待裁定 K;退役判断放在 P3

    lane-decisions 矩阵:每个组合一行,正负成对(触发时触发、不该触发时不触发),新增行可追溯。


    9. Rollout 与配置面(owner-gated,命名待 P0 config-surface 章节定稿)

    • 两级嵌套开关:master 旗 ⊃ lane 旗(lane 旗只在 master 开时有意义),config-file key 经 src/knobs.ts(env > file > default)解析;不新增 env 旋钮(env 稀缺面纪律 彻底整治环境变了滥用,除非必要都走配置文件 #2030)。具体 key 名在 P0 PR 的 config-surface 专章申报后定稿。
    • cohort 名单:配置级声明(哪些 carrier/宿主声称具备双信道),初值待定(遗留 D4:shim/pi/opencode/codex/cc/gemini 六候选逐个核实)。
    • Web「配置」页三态快速开关同步出厂;i18n en/zh 对;registry-test 死键守护行;website/config-reference yaml 种子(若 ship 旋钮)。
    • 默认 OFF,按会话分桶(announcement-id 盐值桶之外的独立桶),P2 单车道灰度起步。

    10. 观测面

    • 决策日志:统一词汇表(hit / miss / red:<R编号> / degrade / resync / arm …),每行可 grep 可聚合;rollout 期间就是信心证据。
    • /__bili/status:attribution 字段扩展新底座维度(哪条链路在服务本会话、平面健康)。
    • 面板健康度:snap 表行数 / log 深度 / ckpt lag(seq 落后量)/ GC 水位 / tripwire 抽验命中率,进 sessions 面板或独立小卡。
    • acp_status uncompressed view:判决输入源指到新表行(KDD#12 共享投影的 apply/recommend/status 三方一致性在新表上重新钉测试)。

    11. 测试矩阵

    分期测试骨架(正负成对原则全程适用):

    # 测试 期
    T1 升级纯加性钉:老库升级前后既有查询行为逐字节不变;DROP 四张新表回滚演练 = 逐字节回到今天 P0
    T2 事件事务单元:提交原语单事务原子性;seq 单调跨压实不断号;抛错无半态 P0
    T3 B1 陷阱钉 ×3 连续重启 oracle 比对(水合快照必须携带活跃世界原点 o;frontier 只能由 arm/reset 移动) P1
    T4 A/B 字节级:N 回合真实语料下新链路出站字节 == legacy 全量产物(除 time attr) P1–P3 常开
    T5 散布 NEW 编码字节一致钉(ClusterCounter 复现) P2 准入
    T6 deleteSession 级联连删(含 l1_world)无孤儿 P0/P1
    T7 覆盖映射压实时存活:compact 后 decompress/GC 依据仍可查 P1
    T8 GC 后 decompress 的诚实失败出口(pre 缺失 ≠ 静默空引用) P3
    T9 长会话体量增长曲线模型(行数/log 深度/ckpt 尺寸,对照 #3752 红线)长跑验收 P1
    T10 红门矩阵:R1–R4 各配「触发时回落」+「不该触发时不回落」成对行 各期随对应模块
    T11 真实客户端 e2e(pi / dsh × sglang)全链路 P2 准入
    T12 双模式(pluginMode/proxyMode)carrier 分支双验证(§4.4) P2

    CI:docker gate + 求解器无关;hermetic,端口 listen(0)(#360 纪律)。


    12. 分期交付(每期为独立 PR,人审关卡标出)

    期 范围 行为面 验收
    P0 DDL 四件套 + 提交原语 + 升级钉 + 回滚演练 + 事件事务单元测试 零行为变化(纯铺底) T1/T2/T6;写模型假设(H)与 key 命名(config-surface 章)在此期定稿——人审点①
    P1 影子写:新表与旧路并行落数据,读侧完全不切 零行为面 T3/T4(影子比对)/T7/T9 长跑曲线;体量模型过红线检查——人审点②(信任重建关键期)
    P2 单车道 hydrate-egress 切源灰度(cohort 首个成员,建议 pi 或 dsh 之一) 灰度会话读出站来自新表 T5/T10/T11/T12 + A/B 钉常开 + tripwire 抽样在场;exit switch 一键回退
    P3 decompress/export/UI/计费逐一切换;CCR/persona 处置;#3756 退役判断;cohort 名单扩员 消费方逐个切换 T8 + 全矩阵复跑;每期独立 PR

    E 裁定建议维持:本期范围到 P0+P1 收手交验收;P2 的字节对等风险集中,独立 PR + 灰度基建齐备后再上。


    13. 前置依赖与时序

    1. [PR] Re-land v6 composite-identity fastpath lane — inverse of #5854 revert (base for snapshot-centric rework, #5643) #5855 先合并(人合):它是事务骨架的工程基底,也是 schema 版本的垫层。它 open/dirty 一天,P0 的 DDL 就没法干净地叠版本。
    2. [PR] #5825 Identity Channel Wiring: Unified Consumption Seam + Six Lanes (opencode V2/goose/qwen/claude/codebuddy/mcode) | #5825 身份信道接线:统一消费缝 + 六条车道(opencode V2/goose/qwen/claude/codebuddy/mcode) #5842(身份采集)✓ 已在 master —— 第 0 段直接复用,无需等待。
    3. [PR] Revert "[PR] feat(fastpath): v6 composite-identity incremental fastpath lane (full rework, #5576 line voided)" #5854(撤回)✓ 已 merged —— 确认 v6 符号零残留于 master。
    4. 裁定闭环(§14):F/G/B 三项决定表结构骨架,先行拍板;其余随 P0 PR 一并裁。

    14. 待 owner 裁定汇总

    已在线讨过的(A–E,沿用草案 v0.1 编号)+ 缺口分析新增(F–L)+ 遗留(D3–D5):

    # 事项 倾向 阻塞什么
    A 行内形态 ② 只存 post,pre 引用既有 CAS;附加:被存活行引用的 pre 字节活得比该行久 P0 DDL
    B 失效行保留策略 绑定覆盖块生命周期的压实清理;反对永不清(#3752 红线)与全局 TTL P0 DDL/GC 设计
    C 摘要落位 ① 就地占覆盖段首 pos + ckpt meta 显式保留覆盖映射 P0 DDL
    D 会话键空间 沿用现有 sid P0 DDL
    E 本期范围 P0+P1 收手交验收,P2 另开 PR 灰度 排期
    F 内核状态居所 ckpt.meta_json 携带 CompressionState 序列化 + 校验和(内核零改动、水合 O(1)) P0/P1 核心
    G L1 身份薄表 恢复 baseline §4.1.1 的 (sess_raw, ledger_id) 持久化(独立薄表 + 索引),复用 #5842 采集 P0 DDL
    H 写模型 单进程假设(WAL 串行化)or 多进程 + 内存视图失效协议,P0 二选一定稿 P0
    I 硬门 vs 降级边界 cohort 声称宿主故障拒绝 + 零副作用 + breaker;非 cohort 走顺序>hash 同表降级、会话粘滞、换模式=resync P0/P2 路由
    J tripwire 运行期低比例抽样 + 不匹配即摘回 legacy + 告警 P2
    K 与 #3756 / v5 共存 新底座车道上 #3756 让位退役(旗互斥);v5 继续服务非 cohort P2/P3
    L 行内 token 计账列 tokens_est 入表:判决面增长数据源 + 计费共用 P0 DDL
    D3 故障响应形态 HTTP 码 / 错误体 / 客户端重试约定(R3 硬拒绝的对端视角) P2
    D4 cohort 初始名单 shim/pi/opencode/codex/cc/gemini 六候选逐个核实载体稳定性 P0 配置初值
    D5 重编号语义 内容同 id 异:判新增双份 or 对级去重 P0 语义

    15. 风险与诚实边界

    • 「保元素数的前缀字节改写不可检测」(继承 baseline 代价条款):代价就是跳过逐条复核的信任模型变化——需人工评审把关,不得自动合并(KDD §7.4 同类门槛)。
    • 多模态尾部进入缓存后该段历史永久降级 legacy 全量轮(继承 KDD#15 诚实边界②):宁降级不偏离。
    • marker-strip 计数随种子账本继承,中部区从不重扫(同上③)。
    • 本提案所有「不变量」的最终裁判是运行期 tripwire + S4 抽验,不是纸面论证——所以 P1 影子期存在意义就是攒这份实证。

    16. 参考号速查

    #5643(本线起源+定位纠正)· #5854(整线撤回,merged)· #5855(工程基底 re-land,open)· #5842(身份采集 wiring,merged)· #3756(D-lane 快照渲染,将被 K 裁定处置)· #3752(存储无界增长 p1 红线)· #5403(OOM:lastMessages 驻留)· #2432(客户端压缩死螺旋,纯忽略策略的来源)· #3236(共享投影判据)· #3642(跨线稳定规范 id)· #3617(gate 双向断言)· #1104/#1106/#1107(fingerprint 白名单纪律)· #4491/#4834(msgid 身份层级)· #5539(schema v11 FK 子索引)· #155(诚实输出)· #360(listen(0) 端口纪律)· MESSAGE-IDENTITY.md(身份教义)· #5643 定位纠正评论:#5643 (comment)

    ---- 粘贴结束 ----

  17. ranxianglei commented on Nov 7, 2026

    @ranxianglei
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)

    正式提案收到(PR #5873,docs-only)。事实核验全过,附一条实质评审发现 + 文档小疵 + F–L 参考意见。

    ✅ 事实核验:#5873 open/blocked(6 files,纯文档);#5842(身份采集六车道)✓ 已合入——§4.0「直接复用不建第二套」成立;#5855 仍 open/behind master——§13.1 第一时序依赖属实未解;POST /__bili/plugin/tool 端点确在 src/server/admin.ts(≈:798)——附录二第一现场落点准确。Discussion 建帖受 API 限制只能你手动三步粘贴,知悉。

    🔍 评审发现 1(实质,建议随 G 裁定一并定,P0 DDL 前应解决):l1_world 的 PK(裸 sess_raw) 与 KDD#9 persona fork 纪律冲突。已知实例:dsh auto-review 的 classifyRisk() 把同一 conversation id 盖在主会话和辅助 persona 的每次请求上(固定 REVIEW_POLICY system + 每次工具调用前新拼 blob),现行解法是在会话键层用 subagentNamespace(id, systemText) fork 成 <id>|sub:<fp>。若 L1 以裸 sess_raw 为主键:persona 流量的复合探测要么误采主会话的账本身份(mis-attribution=MESSAGE-IDENTITY.md 定义的最贵失败),要么同一 sess_raw 下要求第二个 ledger_id=PK 冲突。两种结果都不可接受。建议:L1 键改用解析后的会话键(含 fork 命名空间后缀)或 (sess_raw, fingerprint) 复合键——这正是 #1916/#1307/#1314/#2156 烧过的同一类坑,P0 契约定稿前钉死。

    🔍 评审发现 2(文档小疵):不变量 iv 写死「行不物理删除」,但 §4.3/B 裁定建议是绑定覆盖块生命周期的物理清理——B 一旦落地,iv 字面自相矛盾。加限定词即可(「覆盖块归档前不删」或「以 B 裁定为准」)。

    + 一条正面观察:§4.1 散布 NEW 编码(P2 准入的脏实现点)在本设计里比旧车道更可解——snap_rows.post_json 存着精确的前缀编号上下文,ClusterCounter 基数可直接从存储行推导(同 v5 rekeyWindowCoresFromCounts 的 base-counts 机制),不必从零复现整数组调用语境。建议写进 P2 准入设计注记。

    F–L 参考意见(非拍板):

    立场不变:F/G/B 先行拍板(决定表骨架)+ #5855 合入之前不动工;裁定落地后 P0 可指派给我,工作区干净待命。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions