[ranxianglei]

Closes #3975

kernel-change: the consumed-call cleanup (kernel/src/hide-consumed.ts) cannot parse the plain-text line-form content that the compress tool itself accepts (parseLineEntry); the host side cannot fix this without duplicating the line-form parser in a second location (format-drift risk — the #3780 precedent already locates the shared home for this decode in the kernel). Issue #3975 is the dedicated issue naming the kernel root cause.

Rebased onto current master c9ba48566 (2026-11-04; incl. #3769, which replaced the old keep-last-two orphan rotation with the fold-gated sweep); tests adapted to the current semantics, end-state guarantees unchanged. Kernel version 0.0.180 → 0.0.181.

What breaks today

parseCallText understood object-array content and stringified JSON arrays only. A plain-text line-form content string (first line m00100–m00120 topic, remaining lines the summary) resolved to no quoted ranges, so such calls mis-resolved as orphans: on quiet turns they stayed visible unstubbed — retaining their full summary text forever alongside the kernel acp_summary — and on fold turns they were swept as failure residue although they ARE the folded block's summary carrier (#1567). Measured in the reporter's snapshot: 2 of 15 mcp__bili__compress calls unsimplified (~2.68K tokens args, ~2.54K redundant full-text overlap across 10 active blocks).

The same mechanism also kept bare-name proxy-lane line-form calls at full length forever (id-matched fate always keeps; the rewrite returned null pre-fix).

Field validation (2026-11-05, v0.1.211 running / v0.1.212 code-checked): the reporter applied an equivalent parser patch to the shipped v0.1.212 dist/index.js — offline against the 8 compress calls of one real long-session request, rendered arguments dropped 48,425 → 5,569 chars with every range parsed and the output kept as plain text; live, the session's next request after restarting bili already carried stubbed tool_use.input for the past compress calls (~25–30K redundant CJK tokens per request removed).

Fix

Reuse the tool's own acceptance ladder instead of a second reader:

• parse-compress-input.ts: new exported parseLineContent(content) — stripJsonWrapperResidue → splitLineEntries → parseLineEntry, i.e. exactly what the compress tool accepts when content is not a JSON array. Unparsable entries keep source/header only and never claim a range.
• hide-consumed.ts: string content whose inner JSON value is not an array (or fails to parse) flows through parseLineContent; quoted-range keys use the normalized refs (aligning with how line-form specs store block refs); rewrite/compact rebuild the line form with headers verbatim and long summaries stubbed to 200 chars, re-emitting the full args object with the string shape preserved (fix: persistent overlay homes for pi/omp/hermes launchers (session history loss) #230 convention). Garbage/refless strings stay byte-identical.

Line-form calls now resolve active/inactive by range exactly like object-array calls and get stubbed identically; on fold turns they are fate=active and therefore exempt from the #3769 sweep, while true orphans are still swept at/after the fold start.

An exact-name allowlist entry for mcp__client__compress was considered after the first field report and DROPPED on correction: that name is minted by a downstream gateway that re-exposes client tools above bili and never reaches bili itself (which sees the bare proxy-injected compress); it has no traffic evidence, and client is a generic MCP server name carrying the same misidentification risk for which suffix matching was rejected (#2578). The PR ships the parser fix only.

Out of scope (owner-deferred from the 2026-10-23 review): the two legacy flat arg shapes ({startId,endId,summary} top-level; {content:<prose>,startId,endId} salvage form) — data-safe (the anchor carries the full text), population shrinks since #4252 stopped advertising them; left for a separate decision.

Behavior change (old → new)

Surface	Old	New
Rendered args of a line-form compress call with long summaries	full text retained forever (both MCP lane and bare-name proxy lane)	long summaries stubbed to 200 chars, header lines verbatim — identical end state to object-array calls
Fate of line-form calls	always orphan (full text visible on quiet turns; swept as failure residue on folds despite being the block's carrier)	active/inactive by quoted range; quiet-turn orphans still visible but stubbed
Kernel acp_summary retention for these blocks	unchanged (anchor stays the sole complete carrier)	unchanged — deliberately NOT extended: post-stub args are not a complete carrier, so stripping the anchor would lose the full text (issue expectation #3)

Object-array, stringified-array, and garbage paths are regression-pinned unchanged. One-time consequence of rolling out: sessions with historical line-form calls get one cache-prefix rewrite when their arguments are first stubbed; the stubs are deterministic and stable across turns thereafter.

Design note for future carrier-index extensions (field report, 2026-11-05)

A second field report (OpenCode 2 plugin lane, bare compress) confirmed the line-form end state above and raised a forward constraint worth recording here: in the plugin lane, array-form folds ALREADY reach a stub-only wire steady state — hideConsumedCompressCalls truncates the re-sent call to a 200-char stub and stripKernelSummaries strips the acp_summary render, because the client's own re-sent pair IS the carrier by contract (#1567); the full text stays recoverable from the client's stored history and via decompress. Line-form folds sit in the conservative counterpart: buildCarrierIndex cannot parse line-form args, so the render remains the standing full copy (unparseable ⇒ anchor kept). If anyone later teaches buildCarrierIndex / reconcilePluginFoldCallIds the line form, line-form blocks move to the same stub-only steady state — acceptable only while at least one complete carrier survives (the client-side pair in plugin lanes, the decompress path); do NOT ship a variant where neither the stubbed call nor the render carries the full text and the lane does not retain it either.

Config surface

None — no config/env/CLI changes.

Tests

• kernel/tests/issue3975-hide-consumed-lineform.test.ts (new, 12): normalization (m100→m00100, b2/b5, topic), refless-garbage verbatim, MCP synthetic-id plain-text carrier stubbed as STRING, fold-sweep exemption for a live-range plain-text carrier while a true orphan is swept ([Bug] MCP failed compression record rotation prematurely rewrites the history prefix, triggering expensive cache recompu | [Bug] MCP 失败压缩记录轮换提前改写历史前缀，触发大额缓存重算 #3769/plugin mode: in-place acp_summary never stripped when the client's own compress pair rides inbound — double summary carrier on every post-fold turn #1567), partial-range invalidation (live kept+stubbed / dead dropped), all-dead hidden, quiet-turn failed-fold orphans visible but stubbed, bare-name id-matched lane, stringified-array shape+stub regression (fix: persistent overlay homes for pi/omp/hermes launchers (session history loss) #230), plus the two review pins (clamped-range compact fallback, stub fixpoint stability).
• tests/issue3975-mcp-lineform-endstate.test.ts (new, host level, 2): issue expectations 2–3 pinned end-to-end — after hideConsumedCompressCalls + stripKernelSummaries, the plain-text call ends stubbed while its acp_summary_b0 anchor stays byte-complete; object-array parity pin.
• Targeted lanes green locally (kernel: issue3975 + hide-consumed family + parse-compress-input + issue3769 sweep = 130/130; bili: predicate + end-state + invariant-judge + [Feedback] Noticed during testing that Zcode doesn't seem to trigger compression very often. | [反馈]在测试途中发现Zcode好像不怎么会触发压缩 #4344 dialect + [Bug] MCP compress 未接入 reasoning 清理及未完成调用保护 #3222 reasoning-prune = 67/67); typecheck clean; full suite = CI.

[github-actions]

📦 Built Package Artifact

Branch: wt-3975-ework-daemon (74653f2)

Latest build — install this exact version

npm install -g billion-context@0.0.8549-pr.4032.8817d90

This exact version is immutable and reproducible. The rolling pr tag tracks the newest test build across all PRs.

Recent builds (commit → version)

commit	version	build
74653f2	billion-context@0.0.8549-pr.4032.8817d90	build
d6949d1	billion-context@0.0.8538-pr.4032.d94e5ba	build
66caf50	billion-context@0.0.8489-pr.4032.2a7347e	build
bdf8c10	billion-context@0.0.8474-pr.4032.f3198ef	build
acd8853	billion-context@0.0.8460-pr.4032.b28a585	build
e8fc736	billion-context@0.0.8188-pr.4032.68485b5	build
72f7103	billion-context@0.0.8187-pr.4032.9bcd374	build
38fd9ac	billion-context@0.0.8186-pr.4032.2d72e41	build
c86ab0c	billion-context@0.0.8185-pr.4032.49b085b	build

Download artifact

1. Download the artifact from the Actions run
2. Extract the tarball and install:

tar xzf billion-context-pr4032.tgz
npm install -g package

---

Install instructions are refreshed on each push.

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

查重：不重复。 本 PR 是 #3975 的专属修复 PR（Closes #3975）。相邻条目核对：#3785（line-form 双重转义换行打捞，已合）改的是解析入口的容错，不是 consumed-call 清理；#2970/#2977（MCP compress 路由进清理层）、#3769/#3784（orphan 清扫门控）是本 PR 依赖的既有机制而非平行修复；#4311（摘要双份保留，已关）与本 PR 同症状家族但指向的是载体去重边界，PR 已按该边界刻意不扩大 carrier 索引。无并列的同机制在途 PR。

标签：pr + bug + scope/kernel + p2（缺陷类；根因与改动都在 kernel 的 consumed-call 清理面；能用但有冗余驻留、有绕行——p2；MCP shim 为多宿主共用面，不打具体客户端标签）。

开始独立审核（不照抄 #3975 线程结论）：拉分支通读 diff、清点触碰路径的既有行为、本地定向跑新增测试与相关套件、核对 CI。另注意到 PR head 相对当前 master 显示 merge conflict（master 已推进约 3 天），审核中一并处理 rebase。结论随后按八问回复。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

PR #4032 独立复审结论（对最新 master 重读 diff 与行为，不复述 #3975 线程结论）。

已执行的动作

• rebase 到最新 master（期间 master 前进了 ~224 commits，含 [Bug] MCP failed compression record rotation prematurely rewrites the history prefix, triggering expensive cache recompu | [Bug] MCP 失败压缩记录轮换提前改写历史前缀，触发大额缓存重算 #3769/compress calls rejected when the summary text rides in content next to top-level startId/endId — plus U+2212 dash silently folds the wrong range #4252/[Bug] compress range straddling the protected latest user message: summary of the reply is anchored BEFORE that user message (causal order inversion) #3953/Accident re-anchor debris is unrecoverable: the overlay island lands mid-turn, and the turn-split guard means the orphan | 事故重锚碎屑无法回收:覆盖岛落在 turn 中段,turn-split 守卫让孤另一半永远折不了 #4348）；冲突仅版本行，按 Kernel Boundary 规则解为 kernel 0.0.159→0.0.160，两个 lockfile 仅版本行变化（已核对 delta）；
• 补 2 个回归钉（commit 40c9d06a0）：① clamped-range compact fallback——id-matched 调用引用的范围与块实存范围不一致时（[Bug] compress range straddling the protected latest user message: summary of the reply is anchored BEFORE that user message (causal order inversion) #3953 内部受保护消息截断），live-range rewrite 保留为空、compact 兜底仍须 stub，此前无测试覆盖该可达路径；② stub 幂等定点——第二遍处理已 stub 的文本输出字节一致（跨轮缓存稳定的直接证据）；
• 本地验证：typecheck 干净（含 kernel/pi-subagents 构建）；定向测试 163/163 绿（kernel：issue3975-lineform(12)/hide-consumed-mcp/hide-consumed-stub/issue3769-orphan-sweep/parse-compress-input/orphan-fixes/orphan-endpoint-snap/prune-orphan-mcp/hide-merge-rebuild/issue3371；host：issue3975-mcp-lineform-endstate）；全量套件以 CI 为准；
• 已推送 wt-3975-ework-daemon（40c9d06a0），PR 冲突解除（mergeable=true）。CI 12 条流水线已触发，当前在 runner 队列等待（并行会话多，排队中）。

八问

1. 是什么问题：compress 工具接受纯文本 line-form content（首行 m00100–m00120 主题），但 consumed-call 清理只认对象数组/字符串化数组——line-form 调用被误判孤儿：完整摘要永不被截成 200 字符，与 kernel acp_summary 长期重复占上下文；且 fold 时被当「失败残留」扫掉，尽管它正是该块摘要的 carrier。
2. 什么原因导致的：清理层（hide-consumed 的 parseCallText）是工具的第二个读取器，没有复用工具自己的接受阶梯（stripJsonWrapperResidue→splitLineEntries→parseLineEntry），两个读取器漂移，line-form 形状缺失。修在根上=单一解码源归 kernel（compress: literal backslash-n in string content still fails as kind=content-not-array, hiding the real missing-summary reason #3780 先例：共享解码的家在内核）。
3. 影响范围与严重程度：所有用 line-form compress 的会话（MCP 名车道 + bare-name 代理车道均命中，后者 id-matched 也永不 stub）。报告者实测 15 次调用中 2 次未简化（~2.68K tokens args、~2.54K 重复重叠）。严重程度 p2：可用但持续冗余上下文成本，无数据丢失。注意 compress calls rejected when the summary text rides in content next to top-level startId/endId — plus U+2212 dash silently folds the wrong range #4252 之后 line-form 是 schema 唯一advertised 形状，新流量主力即此形，修复重要性相应提高。
4. 怎么修复的：kernel 导出 parseLineContent，逐字走工具自己的接受阶梯；hide-consumed 把「内层 JSON 非数组或解析失败」的字符串内容路由给它；range key 用规范化 refs；rewrite/compact 按 line-form 重建（header 逐字、>200 字符摘要截 200、字符串形状保留，fix: persistent overlay homes for pi/omp/hermes launchers (session history loss) #230 约定）；垃圾/无 ref 字符串保持字节不变。fate/sweep 逻辑本体未动，只扩展消费点。
5. 是否有回归问题：逐项清点既有行为——对象数组/字符串化数组/垃圾路径回归钉住不变（fix: persistent overlay homes for pi/omp/hermes launchers (session history loss) #230 字符串形状约定、无 ref 垃圾字节稳定均有测试）；[Bug] MCP failed compression record rotation prematurely rewrites the history prefix, triggering expensive cache recompu | [Bug] MCP 失败压缩记录轮换提前改写历史前缀，触发大额缓存重算 #3769 fold-gated sweep 语义保持（测试同时钉 carrier 豁免 + 真孤儿清扫两方向）；quotesActiveBlock 不解析 line-form，判定与对象形 clamped-range 行为对称（都落到 fold 时处理），非回归；acp_summary 锚点保留刻意不扩展——stub 不是完整载体，删锚会丢全文（issue 期望 Use kernel renderTags:"text-only" + forbid tag echoing in prompt #3）；无 fail-fast 变吞错，SUMMARY_STUB_CHARS=200 常量未动，无阈值/时序/输出格式漂移。两种压缩模式都过了一遍：清理层作用于重发历史，MCP/bare-name 双车道各有测试钉。
6. 是否破坏缓存：否。重建确定性（同输入同字节，JSON.stringify 键序稳定），stub 输出是定点（新增幂等测试实证第二遍字节不变），前缀缓存稳定。
7. 是否改了设计方向：否。方向=单一共享解码源放 kernel，与 compress: literal backslash-n in string content still fails as kind=content-not-array, hiding the real missing-summary reason #3780/[Bug] recommend/apply 对同一区间的 turn-integrity 判定永久不一致：acp_status 反复推荐的区间被 apply 侧整段拒绝（0.1.196，Range would split N turn(s) at the protected-zone boundary） #3236「判定与执行共用单一投影」同源。
8. 是否引入新配置：无。

已知残留（不阻塞，已在 #3975 记为 checklist 项）：parser 仍接受的两种 legacy flat 形状（{startId,endId,summary} 无 content；{content: 摘要文本, startId, endId}，#4252 后不再 advertised）cleanup 同样不解析——前者在其块 active 期间全程全文可见（从不 stub），后者下次 fold 正常被清（只是中间不 stub）。两者均先于本 PR 存在、属未 advertised 的衰减形状、无数据丢失；是否扩展 cleanup 覆盖留给 owner 决策。

判定：代码闭环、测试有牙（10+2 kernel / 2 host，含负向门）、冲突已解、本地定向证据齐。等 CI 全局门转绿后建议合并——kernel 变更属 human-only review 档，请人工合并：#4032 。CI 结果出来我再补一条确认。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

lock-sync 红已在分支侧自行修复,本轮无需再推任何提交。 阻塞快照指向的旧 head c86ab0cd7 已不是分支头——作者随后把分支 wt-3975-ework-daemon 重推到 38fd9ac91(rebase 到 master c9ba48566),新 head 上 lock-sync 已绿。

根因(旧 head 为何红): 0.0.180→0.0.181 的版本 bump 是用一次把换行压成空格的编辑落进去的。kernel/package-lock.json 里两处字段被挤到同一行("version": "0.0.181", "lockfileVersion": 3, 和 "version": "0.0.181", "license": "MIT",)。lock-sync job 用 npm install --package-lock-only 重新生成时会把这些行拆回标准两行格式,于是 git diff --exit-code 报漂移失败。根 package-lock.json 当时是干净的(只改了版本号一行),所以红的只有 kernel 这一份锁文件。

验证(本地用与 CI 完全相同的命令复跑,新 head 38fd9ac91):

• 根目录 npm install --package-lock-only --ignore-scripts --no-fund --no-audit → git diff -- package-lock.json 零差异;
• kernel/ 下同一命令 → git diff -- kernel/package-lock.json 零差异(旧 head 上此步恰好产生那 6 行漂移,可稳定复现);
• CI 实况(run 41944294905,head 38fd9ac91):lock-sync | completed success;kernel-guard / lane-guard / version-guard / docs-sync / pi-subagents-guard 等全部绿;仅剩分片 test 矩阵还在跑(与本问题无关)。

一处遗留小瑕疵(未动,仅标记): kernel/package.json 第 3 行仍是挤在一行的 "version": "0.0.181", "description": …。这是合法 JSON,npm 按语义解析、kernel-guard 的正则也不受影响,对任何门禁和功能都无影响;因为落在人工把关的 kernel/ 目录内且与本次红无关,CI 车道不越界代改,建议作者下次推分支时顺手拆回两行即可。

---

结构化结论(八问)

1. 是什么问题:PR 分支的 kernel/package-lock.json 与 package.json 版本号不同步(lock-sync 漂移门禁红)。
2. 什么原因导致的:版本 bump 编辑把换行写成空格,锁文件里两个字段被挤到同一行;npm 重新生成时恢复标准排版,产生 6 行纯格式差异,git diff --exit-code 判为漂移。
3. 影响范围与严重程度:仅影响本 PR 的 CI 门禁(合并前拦截),无运行时行为影响;严重度 = 流程阻塞,非用户可见缺陷。
4. 怎么修复的:作者重推分支(rebase 到当前 master)时锁文件已修正为标准格式;我用与 CI 相同的命令在本地对新 head 复跑确认幂等(零差异),并核对新 head 的 CI 运行中 lock-sync 已为 success。本次运行未向分支推送任何提交。
5. 是否有回归问题:无。改动面只有两份锁文件的版本记录行与排版,不涉及代码语义;高危模式逐项过——无语义漂移、无错误处理变化、无默认值/阈值/时序/输出格式变化。
6. 是否破坏缓存:不涉及(锁文件不参与运行时缓存/重试/去重逻辑)。
7. 是否改了设计方向:不涉及。
8. 是否引入了新的配置:不涉及。

收工判定:lock-sync 阻塞已解除(分支侧自修 + 本地与 CI 双重验证),本 CI 车道无需进一步动作;等待剩余 test 矩阵完成后由 reviewer/owner 推进合并。

[ranxianglei]

(ai: vllm-qwen/qwen3.8-27b)

独立审核结论（review-worker-r1，对 head 38fd9ac91 重读全量 diff——不复述前轮/issue 结论）

判定：代码与测试层面可合。因触及 kernel/ 且携带 kernel-change: 声明，按 Kernel Boundary 属 human-only 审核档，本审核不执行 approve——转 🔶 需要决策 流程请 owner 授权（见后续评论）。

已审既有行为清单（回归审查，逐项判读改动前代码而非只看 diff）：

• 对象数组 / 字符串化数组路径：parseCallText 仅在内层 JSON 非数组或解析失败时才改道 lineEntries；两既有形状解析、重写、字节稳定性不变，#230「字符串形状保留」约定有回归钉。→ 保持 ✓
• #3769 fold-gated sweep：fate/sweep 本体未动；line-form carrier 经 fate=active 在 sweep 分支之前被豁免，真孤儿照旧在 foldMinRef 处清扫，quiet turn 不扫（测试双向钉住）。→ 保持 ✓
• acp_summary 锚点保留：buildCarrierIndex 刻意未扩名（stub ≠ 完整载体，删锚即丢全文），issue 期望 #3 守住。→ 有意不变更，PR 已披露 ✓
• 谓词面：isMcpBiliCompress 仅新增一个精确全名条目（带流量证据注释），unobserved 服务名负向钉住；invariant-judge.ts lockstep twin 同步扩展；接线已核实到全部消费点（src/config.ts:1715 → src/loop/core.ts:1469、src/server/relay.ts:2188、src/plugin-render.ts:148、src/reasoning-drop.ts:77）。→ 有意变更已披露 ✓
• 两种压缩模式：清理层作用于重发历史，MCP/bare-name 双车道各有测试钉。→ 均过 ✓

发现（三条均不阻塞）：

1. quotesActiveBlock（kernel/src/hide-consumed.ts，约 L44）仍不解析 line-form——对纯文本字符串恒返回 false。唯一可达角落：bare-name 且 id 失配的孤儿调用引用活跃块范围时，fold 轮仍会被扫。该角落要求「块先于 compressCallId 记录时代且至今仍 active」的遗留状态；改前同样存在（改前更糟：所有 line-form 调用都是孤儿），非本 PR 引入的回归。可选收尾：让它复用 parseLineContent，或注释钉死不可达性。
2. refs 规范化不对称（既有）：object 形 validateEntry 原样存 ref，line-form 经 normalizeLineRef 补零——跨形状引用同一范围时键可能不匹配而停留在孤儿态。只欠认领（安全方向）、需同会话混用形状+补位风格，非本 PR 引入。
3. kernel/package.json:3：版本行与 description 挤在同一行（与旧 head lock-sync 红同一手误，CI 车道 floor 13 已标记）。合法 JSON、不影响任何门禁；落在人工把关的 kernel/ 内，本审核未代改——建议合并前拆回两行。

测试有效性（质量关）： 12 kernel + 3 host + 谓词真值表正/负行，断言有牙（精确长度/逐字节/双方向门）；fixpoint 稳定性测试直接钉「重写输出跨轮字节一致」（前缀缓存稳定的直接证据）；end-state 测试跑完整 hideConsumedCompressCalls + stripKernelSummaries 管道并显式防住「扩大 carrier 索引 → 删锚丢全文」的错误修法。issue 期望 1–4 全覆盖。真测试，能兜底。

八问

1. 是什么问题：compress 工具接受纯文本 line-form content（首行 m00100–m00120 主题），但 consumed-call 清理是第二个读取器、缺这一形状——此类调用被误判孤儿，全文摘要永驻并与 kernel acp_summary 重复占上下文，fold 轮还被当失败残留扫掉（它正是该块的摘要 carrier）；另有观测到的 mcp__client__compress 桥接方言不被任何清理谓词识别，整条车道全文永驻。
2. 什么原因导致的：清理层没有复用工具自己的接受阶梯（stripJsonWrapperResidue→splitLineEntries→parseLineEntry），两个读取器漂移，line-form 形状缺失；方言缺失是精确名允许列表里没有该条目（设计如此——新方言须带流量证据入列）。
3. 影响范围与严重程度：所有发 line-form compress 的会话（MCP 各车道 + bare-name 代理车道）；#4252 之后 line-form 是 schema 唯一 advertised 形状，新流量主力命中。冗余上下文成本 p2 级：报告者实测 15 次调用 2 次未简化（~2.68K tokens args）；OpenCode 车道字段报告每请求 ~25–30K tokens 重复。无数据丢失、可用、有绕行。
4. 怎么修复的：kernel 导出 parseLineContent 作为单一解码源（逐字走工具自身阶梯，消灭第二读取器）；hide-consumed 把「内层非数组/解析失败」的字符串内容路由给它；range key 用规范化 refs；rewrite/compact 按 line-form 重建（header 逐字、>200 字符摘要截 stub、字符串形状保留 #230 约定）；垃圾/无 ref 字符串字节不变。方言走精确全名允许列表 + invariant-judge lockstep twin。
5. 是否有回归问题：无。见上「已审既有行为清单」逐项结论；高危模式过完——无语义漂移、无 fail-fast 变吞错、无阈值/时序/输出格式变化（SUMMARY_STUB_CHARS=200 未动、sweep 门控本体未动）。发现 1/2 均为既有残留、安全方向、非本 PR 引入。
6. 是否破坏缓存：否。重写输出是定点（第二遍处理字节一致有测试实证）、JSON.stringify 键序确定，前缀缓存稳定；不动去重键/增量游标/重试策略。
7. 是否改了设计方向：否。方向 = 单一共享解码源归 kernel（#3780/#3236 同源纪律）；carrier 去重边界刻意不扩（stub 不是完整载体）。
8. 是否引入新配置：无（PR 已声明 Config surface: None）。

CI：head 38fd9ac91 镜像缓存 summary total=30 / failed=0 / pending=0（含 12 个 test 分片、static-gates、mysql-contract、gate；ci.yml 中 kernel 套件 job 与 kernel-guard/version-guard/lock-sync 均在该 run 内绿）。mergeable_state=blocked = 等审核（分支保护），与本派单一致。

收工判定：代码闭环、测试有牙、CI 全绿。待 owner 对 kernel 变更授权后由人工合并（Kernel Boundary human-only 档，agent 不合并不 approve）：#4032 。发现 3 建议合并前顺手拆回两行。

[ranxianglei]

🔶 需要决策

(ai: vllm-qwen/qwen3.8-27b)

PR #4032 触及 kernel/ 并携带 kernel-change: 声明，按 Kernel Boundary（AGENTS.md：声明前置 + owner 批准 + human-only 审核）属人工把关档——review-worker 已完成独立技术审核但无权 approve。请 owner 对以下受门禁改动授权或否决：

受门禁 diff（kernel/）

• kernel/src/hide-consumed.ts（±71 行：line-form 字符串内容路由进 parseCallText / quotedRangeKeys / rewriteCompressText / compactCompressText）
• kernel/src/parse-compress-input.ts（+46：新增导出 parseLineContent，复用工具自身接受阶梯 stripJsonWrapperResidue→splitLineEntries→parseLineEntry）
• kernel/tests/issue3975-hide-consumed-lineform.test.ts（新增，12 测试）
• kernel/package.json 0.0.180→0.0.181 + 两份 lockfile 版本行（Kernel Boundary 版本纪律）

审核状态：技术审核已完成（见上方 review 评论，含八问与三条不阻塞发现）；CI 全绿（head 38fd9ac91，30 checks / 0 failed）。代码层面判定可合。

选项

• A 批准：owner 人工合并 [PR] fix(kernel): stub plain-text line-form compress calls in consumed-call cleanup (#3975) #4032 （agent 不合并）。建议合并前顺手把 kernel/package.json:3 挤成同行的 version/description 拆回两行。
• B 打回：说明理由，后续按意见返工。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b) review-worker-r1 收工：PR #4032（head 38fd9ac）独立审核完成——代码与测试层面可合、CI 全绿（30 checks / 0 failed）；因触及 kernel/（含 kernel-change 声明）按 Kernel Boundary 不 approve，已发 findings-only review + 🔶 需要决策 评论（选项 A 批准人工合并 / B 打回），needs-decision 标签已打，待 owner 拍板。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b) 本条为 review-worker 自己刚发的 🔶 需要决策 评论经上游同步回显，非新用户输入，无新动作。当前状态不变：技术审核完成、CI 全绿、待 owner 在选项 A（批准人工合并）/ B（打回）中拍板。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

🔶 需要决策 —— 本 PR 剩余红 = master 级 born-red(tests/msgid-rule-parity.test.ts v6 F1/F2 pin 与 revert 后代码失配),修法互斥,需 owner 拍板方向(该家族已登记 #4599 floor 1091,本车道不代选、零重复修)

背景一句话:#5652 fastpath-v6 的 owner 裁定(v6 F1/F2,2026-11-04)被 #5826 review 的 parity 测试钉进 CI(36210fc + 33b2f82),但 #5652 实现随后被 #5854 revert(bebc239/66aadbd89f)——测试钉的是 v6 语义,代码退回 pre-v6「? travels」宽容语义,master 自 revert 起对该文件确定性 2 红(子测 3「one hole voids the WHOLE list」expected undefined actual ['h_deadbeefcafe0001','?','h_cafebabe12345678'];子测 4「F1 fixed tail window + F2 holes clear the table」)。本 PR diff 与该文件及其全部 import 模块(src/msgid-pin.js、src/request-membership.js、src/agent/pf-channel.js、src/server/fastpath.js、src/agent/dsh-native.js、src/agent/incremental-client.js)零交集,文件与 master 逐字节一致,本地独立运行 3 pass/2 fail 精确复现——纯继承,非本 PR 引入。

选项(互斥):

• A) 按 11-04 裁定重新实现 v6 F1/F2(pfSlotIdsOf 全有全无 + pf-channel 64 窗口/MAX_IDS 发射)——前提:裁定在 revert 后仍然有效。代价:等于部分重落已被有意 revert 的 [PR] feat(fastpath): v6 composite-identity incremental fastpath lane (full rework, #5576 line voided) #5652,且子测 4 同时钉 F1,改动不止 pfSlotIdsOf 几行。
• B) 把 pin 回退到 pre-v6「? travels」语义(test-only 对齐现网行为与 KDD docs: env vars primary config method + cleanup #15 文档契约)——前提:revert 同时作废了裁定。代价:零 wire 行为变更、最小解锁;若日后 v6 重落再随实现重钉。

推荐:B(最小解锁、零行为变更;重新落地被有意 revert 的实现应等 owner 明确指示,而不是由 CI 车道反推)。
未拍板时的默认:维持现状不动——master 该文件继续红,所有含当前 master 的 PR 头在跑到该文件的分片上同签红,各车道一律引用 #4599 floor 1091,零重复修。

本车道状态:合并冲突已解(master 并入,唯一文本冲突 = 三处版本行,按 Kernel Boundary max+1 取 0.0.184)、ci-fixes 经 ancestry 验证已完整在树内、本地 build/typecheck/定向套件全绿,新 head acd8853 已推;本轮无进一步可做的机械修复,停手等裁决(needs-decision 标签已在案)。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

本轮 CI 工程处置总结(旧 head e8fc736 → 新 head acd8853)

1. 是什么问题:两波阻塞——①分支落后 master 产生合并冲突,旧 head 上 test 矩阵 10 片全红;②解冲突重推后仍有 3 个 test 分片红(run 42350570540:ubuntu-24 s3 / ubuntu-22 s3 / windows-22 s1)。
2. 什么原因导致的:①旧 head 的红 = ci-fixes 已登记的「DSH: If the first request of a session originates from a bypass call, compression for the entire session is permanently | DSH: If the first request of a session originates from a bypass call, compress for the entire session is permanently inv | DSH：会话首个… #5656 sidecar residual」五枚 dsh 回归钉 born-red 家族(issue2446/2447/2419/2481 guard-stamp + issue2817 persona fold),修复 0470bec 已随 master 落地;②新 head 的 3 片红 = master 级 born-red:tests/msgid-rule-parity.test.ts 子测 3/4 钉的是 v6 F1/F2 裁定语义([PR] feat(fastpath): v6 composite-identity incremental fastpath lane (full rework, #5576 line voided) #5652,owner 2026-11-04),而 [PR] feat(fastpath): v6 composite-identity incremental fastpath lane (full rework, #5576 line voided) #5652 实现已被 [PR] Revert "[PR] feat(fastpath): v6 composite-identity incremental fastpath lane (full rework, #5576 line voided)" #5854 revert(bebc239)——pin 与代码永久失配,确定性红。该文件与 master 逐字节一致、本 PR diff 不触其任何 import 模块,本地独立运行 3 pass/2 fail 精确复现——纯继承,非本 PR 引入或放大。
3. 影响范围与严重程度:①仅本 PR,已随 master 落地消失;②master 全局——裁决落地前,任何含当前 master 的树在跑到该文件的分片上必红 2 条,阻塞所有 PR 合入(CI 门禁面);属 master 侧既有状态,已按政策登记 CI Control Center: Centralized CI Failure Handling & Status Sync (Comment all CI issues here; do not open new issues) | CI 总控: CI 失败集中处理与状态同步(所有 CI 问题在此评论, 勿开新 issue) #4599(floor 1091 在档家族)。
4. 怎么修复的:①merge upstream/master 进分支——唯一文本冲突 = kernel/package.json、kernel/package-lock.json、package-lock.json 三处版本行,按 Kernel Boundary 版本纪律取 max+1 = 0.0.184(master 0.0.183,本 PR 携带 kernel/src 变更必须 bump),两个 lockfile 用 CI 同款命令 npm install --package-lock-only --ignore-scripts --no-fund --no-audit 重生成并幂等验证;ci-fixes 经 ancestry 验证已完整在树内(merge no-op)。②剩余红无可修项:修法 A/B 互斥且需 owner 拍板——已在 CI Control Center: Centralized CI Failure Handling & Status Sync (Comment all CI issues here; do not open new issues) | CI 总控: CI 失败集中处理与状态同步(所有 CI 问题在此评论, 勿开新 issue) #4599 补一行状态引用 floor 1091,本帖留 🔶 需要决策 评论(推荐 B:回退 pin 到「? travels」,零行为变更最小解锁),不在自己分支重复修 master 级失败。
5. 是否有回归问题:无。merge 为纯并集,唯一冲突按版本纪律解决;本 PR 原有 7 文件 diff(kernel src/tests + 版本/lockfile)语义保持;本地 build/typecheck/kernel 定向 12/12/host 定向 19/19 全绿;未改任何行为常量、阈值、时序、输出格式、错误处理路径。
6. 是否破坏缓存:不涉及——未触碰压缩/缓存/账本逻辑,kernel 变更仍是原 PR 自身的 line-form stub(其缓存语义由原审核覆盖)。
7. 是否改了设计方向:不涉及——冲突解决只动版本号与 lockfile,零架构/数据流转向。
8. 是否引入了新的配置:不涉及——零新增 env/config/默认值。

收工判定:本车道机械工作完结——冲突已解、可消化的继承红已随 master 消失、新 head acd8853 已推且除 master 级 born-red 外预期全绿(lock-sync/static-gates/mysql-contract 等门禁已绿);剩余 3 片红等待 owner 对 v6 裁定存废的 A/B 裁决(#4599 floor 1091 + 本帖 🔶 评论),裁决落地后本 PR 重跑即转绿,无需再动分支。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

本轮 CI 工程处置总结(head acd8853 → bdf8c10)

1. 是什么问题:上一轮登记的 3 片 test 红(msgid-rule-parity v6 F1/F2 pin 与 revert 后代码失配)在同一 head/run 上被再次触发——但触发时 master 已推进,阻塞性质从「等裁决」变为「跟进 master 修复」。
2. 什么原因导致的:红根因不变(pin 钉 v6 语义、代码是 pre-v6);变化在于 owner 已按 B 路线在 master 落地修复——613d290ef9「master hygiene: restore msgid-rule-parity pins to pre-v6 verdicts」(test-only,精确撤销 33b2f82 的重钉 hunk),即我上轮 🔶 评论推荐的选项。本分支尚不含该提交。
3. 影响范围与严重程度:随 master 修复落地而消失;本 PR 只需跟进合并。无残留影响。
4. 怎么修复的:merge upstream/master(df0a402)进分支——零冲突(双方独立把 kernel 同版本行升到 0.0.184,文本一致自动合并)。随后按 Kernel Boundary 版本纪律处理版本对撞:master 已自取 0.0.184([PR] fix(nudge): no billing sample this round → hold pressure-band injection one round (phantom-pressure guard) #5860 phantom-pressure guard),本 PR 携带 kernel/src 变更必须有版本增量 → bump 到 0.0.185,两个 lockfile 用 CI 同款命令 npm install --package-lock-only --ignore-scripts --no-fund --no-audit 重生成,diff 仅 4 行版本串、幂等验证通过。
5. 是否有回归问题:无。merge 纯并集零冲突;本地验证:tests/msgid-rule-parity.test.ts 5/5 绿(继承红消除的直接证据)、PR 自身定向套件(kernel issue3975 + host issue3975)14/14 绿、typecheck 干净、build 成功;最终 PR diff 对新 master 仍恰为原 7 文件(kernel src/tests + 版本/lockfile),零漂移。
6. 是否破坏缓存:不涉及——本轮只动版本号/lockfile 与并入 master 既有变更。
7. 是否改了设计方向:不涉及——v6 裁定存废已由 owner 以 613d290 拍板(B),本分支只是跟随;🔶 待决事项关闭,needs-decision 标签保留前序车道状态不动。
8. 是否引入了新的配置:不涉及——零新增 env/config/默认值。

收工判定:新 head bdf8c10 已推(master df0a402 + 本 PR 内容,kernel 0.0.185),预期全矩阵转绿——此前的确定性 2 红已随 master 修复消失,门禁类(lock-sync 等)已按 CI 同款命令本地钉住;等 CI 重跑结果,#4599 已留一行收账结论。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

本轮 CI 工程处置总结(自动修复车道 attempt 1/3,head bdf8c10a09)

一句话结论:9 个红分片全部是继承性 master born-red,不是本 PR 引入;本 PR 自身代码与测试已验证全绿,本轮零推送(修 host 侧 nudge 逻辑不属于这个 kernel line-form PR 的范围,收敛走 ci-fixes→master)。已在 #4599 登记该继承家族。

证据链

1. 取真实 job 日志(镜像缓存当时是过期的 queued 快照):windows-22-s2 实际跑完 2143 tests → fail 3,全部落在 tests/silent-backend-nudge.test.ts(#728A/#728C/#1119),硬布尔断言(expected true / actual false),harness 判 concrete-assertion、明确不自动重试。
2. 本地在本分支复现:同样 3 红。
3. 决定性隔离:把本 PR 改的两个 kernel 源文件(kernel/src/hide-consumed.ts、kernel/src/parse-compress-input.ts)临时换回 master(5af5f9fed3)版本、重建 kernel 后重跑该测试文件 → 仍同样 3 红。⇒ 失败与本 PR 的 kernel 改动零关联,纯继承自 master。
4. 本分支对 master 的完整 diff 只有 10 文件,没有一处落在 nudge 路径;我的两个新测试 14/14 绿、既有 hide-consumed/orphan 相关 151/151 绿——本 PR 自身面干净。
5. 为什么不在自己分支修:① 修 host 侧 nudge 会把这个 kernel line-form PR 的 diff 污染成跨范围改动(违反 one-issue-one-scope / clean-diff);② 「是真回归 vs 测试期望漂移」是需要 owner 拍板的判断,不是机械小修;③ 政策明令禁止在自己分支重复修 master 级失败。ci-fixes 相对 master 当前零增量(merge 为 no-op),也没有可 merge 的东西能解锁它。

八问

1. 是什么问题:PR 的 test 矩阵 9 个分片红,根因是一个 master 级 born-red——silent-backend 会话第 2 轮该出现的 trailing nudge 没出现(nudge 压力估算路径上 3 个子测断言失败)。
2. 什么原因导致的:master 自身代码在 nudge 触发判定上有确定性问题(疑似近期 [PR] fix(nudge): no billing sample this round → hold pressure-band injection one round (phantom-pressure guard) #5860 phantom-pressure guard / [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 identity-channel 波次引入,具体待哨兵定位);本 PR 通过 merge master 继承了它。本 PR 自己的 kernel line-form 改动已被反证排除。
3. 影响范围与严重程度:master 全局——任何含当前 master 的树跑到该文件的分片都必红这 3 条,阻塞所有 PR 合入(CI 门禁面);非用户可见功能缺陷,属 master 侧既有状态。对本 PR:阻塞其转绿。
4. 怎么修复的:本轮不修(见上第 5 点)——已在 CI Control Center: Centralized CI Failure Handling & Status Sync (Comment all CI issues here; do not open new issues) | CI 总控: CI 失败集中处理与状态同步(所有 CI 问题在此评论, 勿开新 issue) #4599 登记继承家族并给出签名 + 隔离证据,交哨兵/owner 判定方向(真回归→修 nudge 源;期望漂移→对齐测试钉),修复收敛 ci-fixes→master;落地后本 PR 重跑(或 rebase 到修复后的 master)即绿。
5. 是否有回归问题:本 PR 自身无回归——新增 2 测试 14/14 绿,既有 hide-consumed/parse-compress-input/orphan 相关 151/151 绿,kernel 定向套件此前 1327/1327 绿;高危模式逐项过:未动任何行为常量/阈值/时序/输出格式/错误处理路径。
6. 是否破坏缓存:不涉及——本轮零推送,未触碰压缩/缓存/账本逻辑。
7. 是否改了设计方向:不涉及。
8. 是否引入新的配置:不涉及——零新增 env/config/默认值。

收工判定:本 CI 车道的机械工作到此为止——可修的在范围内项为零(红全是继承),已登记 #4599 并把方向判断交给哨兵/owner;等 master 侧 nudge born-red 收敛后本 PR 重跑即转绿,届时再补确认。kernel-guard 的人工授权卡点维持 floor 16 的 🔶 需要决策(A 批准人工合并 / B 打回)不变,不在本轮范围。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

本轮 CI 工程处置(attempt 1/3;head 已从 bdf8c10 → 66caf50)

一句话结论:本次唤醒列的 6 片红 = 已在 #4599 归因钉死、并由 owner 立项待裁定的 #5860 phantom-pressure guard born-red 波次的 F3 行为面;机械半边(F1 storage-render 快照 + F2 wire-contract golden)哨兵已修好、并已由哨兵把 ci-fixes merge 进本分支(即当前 head 66caf50)。剩余 F3 属 owner 在 #5867 拍板的 A/B/C 设计决策,本轮零推送(无 in-scope 机械修复可做)。

live 复核(不凭记忆):镜像缓存 fetched_at 11:18Z——run 42366601829 @ 66caf50 仍在跑(pending 10 / in_progress 3),目前仅 test (windows-latest, 22, 2) completed/failure;唤醒列的 6 片是运行中的过期快照,非终态。本地在本 head 复现三个 F3 文件全部确定性红:tests/silent-backend-nudge.test.ts(3,#728A/#728C/#1119)+ tests/fork-nudge-trigger.test.ts(2,zero-baseline / #1137 image-heavy fork)+ tests/issue4241-judge-render-baseline.test.ts(1)——共 6 条 estimate-grade pin,与 #4599 floor 1103 登记的 F3 签名逐字一致(#728B real-usage precedence 通过,只伤 estimate 读数)。

为什么本轮不修、不推:

1. 当前 head 66caf50 = 哨兵 help-merge sweep(CI Control Center: Centralized CI Failure Handling & Status Sync (Comment all CI issues here; do not open new issues) | CI 总控: CI 失败集中处理与状态同步(所有 CI 问题在此评论, 勿开新 issue) #4599 floor 1106③)把含 F1+F2 golden 修复的 ci-fixes 并入本分支的产物(HEAD..origin/ci-fixes 为空,已完整在树内)——机械修复已经在我分支里了,无需再 merge/push。
2. 剩余红 = F3,根因 = master a7cbfd12fc([PR] fix(nudge): no billing sample this round → hold pressure-band injection one round (phantom-pressure guard) #5860):新增 compress.requireUsageSampleForPressure(默认 true)+ decideNudge 对 tokenCountSource==="estimate" 读数的 pressure-band 推迟(pressureDeferredNoSample),未同步更新既有 estimate-nudge 测试。这是产品契约裁定项,owner 已单独立项 The storage-render golden snapshot on master went stale after kernel 0.0.184 (#5860): the next scheduled CI run will def | master 的 storage-render 黄金快照在 kernel 0.0.184(#5860)之后过期:定时 CI 下次必红 #5867(A 接受饥饿改断言 / B 有界推迟+对齐测试[推荐] / C revert [PR] fix(nudge): no billing sample this round → hold pressure-band injection one round (phantom-pressure guard) #5860);拍板前这 6 条在所有分支保持红是预期状态(CI Control Center: Centralized CI Failure Handling & Status Sync (Comment all CI issues here; do not open new issues) | CI 总控: CI 失败集中处理与状态同步(所有 CI 问题在此评论, 勿开新 issue) #4599 floor 1106⑤ 明令各车道引用归因楼层、勿重复修)。
3. 三选项都是设计决策非机械小修,且属 master 级([PR] fix(nudge): no billing sample this round → hold pressure-band injection one round (phantom-pressure guard) #5860 已在 master),不在本 kernel line-form PR 的 diff 范围;在自己分支重复修违反政策(2026-10-24)与 one-issue-one-scope。

八问

1. 是什么问题:test 矩阵部分分片红,剩余失败全部落在 [PR] fix(nudge): no billing sample this round → hold pressure-band injection one round (phantom-pressure guard) #5860 phantom-pressure guard 引入的 F3 estimate-grade nudge 行为测试(silent-backend-nudge / fork-nudge-trigger / issue4241-judge-render-baseline 共 6 条)。
2. 什么原因导致的:master a7cbfd12fc([PR] fix(nudge): no billing sample this round → hold pressure-band injection one round (phantom-pressure guard) #5860)加 requireUsageSampleForPressure(默认 true)+ estimate 读数的 pressure-band 推迟,未更新这些既有 estimate-nudge 测试;master push 不触发 CI(2026-11-01 决定),born-red 隐形至 schedule cron 暴露。与本 PR 零关联(决定性隔离见 CI Control Center: Centralized CI Failure Handling & Status Sync (Comment all CI issues here; do not open new issues) | CI 总控: CI 失败集中处理与状态同步(所有 CI 问题在此评论, 勿开新 issue) #4599 floor 1102/1103)。
3. 影响范围与严重程度:master 全局——任何含当前 master 的树在跑到这 6 条的分片必红,阻塞所有 PR 合入(CI 门禁面);非用户可见功能缺陷,是「永不上报 usage 的后端在 pressure-guard 下是否该触发 nudge」的产品契约待定项。对本 PR:阻塞其转绿,但非本 PR 引入。
4. 怎么修复的:本轮不修——机械半边(F1+F2 golden)哨兵已修并进本分支(head 66caf50);F3 半边按 owner 立项 The storage-render golden snapshot on master went stale after kernel 0.0.184 (#5860): the next scheduled CI run will def | master 的 storage-render 黄金快照在 kernel 0.0.184(#5860)之后过期:定时 CI 下次必红 #5867 走 A/B/C 裁决,裁定后修复骑到 ci-fixes→master,届时本 PR 随 master 自愈转绿,无需再动分支。
5. 是否有回归问题:本 PR 自身无回归——kernel line-form stub 定向套件此前 14/14 绿、既有 hide-consumed/orphan 相关 151/151 绿;高危模式逐项过:未动任何行为常量/阈值/时序/输出格式/错误处理路径。
6. 是否破坏缓存:不涉及——本轮零推送。
7. 是否改了设计方向:不涉及。
8. 是否引入新的配置:不涉及——零新增(env/config/默认值)。

收工判定:本 CI 车道无可做的机械工作——机械半边已被哨兵合入本分支、剩余 F3 属 owner 在 #5867 的待决设计项(拍板前保持红为预期),零推送、零改动。等 #5867 裁定落地进 ci-fixes→master 后本 PR 重跑即转绿,届时再补确认。kernel-guard 人工授权卡点维持 floor 16 的 🔶 需要决策(A 批准人工合并 / B 打回)不变,不在本轮范围。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[ework] auto-fix stalled: test (ubuntu-latest, 22, 1), test (ubuntu-latest, 24, 3), test (ubuntu-latest, 22, 3), test (ubuntu-latest, 24, 1), test (windows-latest, 22, 2), test (windows-latest, 22, 1) — stopping for human review

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

本轮 CI 工程处置(attempt 1/3;head d6949d1 → 74653f2)

一句话结论:唯一红 = kernel-guard,根因是版本对撞——master 经 #5867 estimate-hold backstop 已把 acp-kernel 升到 0.0.185,与本分支的 0.0.185 撞车,使本 PR 独有的 #3975 kernel/src line-form stub「改了源码却没有版本增量」触发 Rule 2。这是机械性 max+1 版本同步(与本线程 floor 25/28 同一套路),已修:bump 0.0.185→0.0.186 + 两份 lockfile 按 CI 同款命令重生成,新 head 74653f24e6 已推(fast-forward,无 force)。未动任何 kernel 源码、未改 PR 正文;owner 对 #3975 kernel 改动的人工授权(floor 16 🔶 A/B)独立待决、不受本次影响。

live 复核(不凭记忆):镜像缓存 fetched_at 15:25Z 显示 30 checks / 仅 kernel-guard failure(其余含 test 矩阵全绿——F3 已随 #5867 裁定落地转绿)。本地按 .github/workflows/ci.yml:436–490 的判定逻辑逐条复现:

• Rule 1(声明):kernel/ 触碰 = hide-consumed.ts / parse-compress-input.ts / issue3975 test;正文有 kernel-change: → 通过。
• Rule 2(版本纪律):SRC_CHANGED=1(两个 kernel/src 相对 master 有差异,The plain text content of MCP compress is not simplified, causing the full summary to be redundantly retained. | MCP compress 的纯文本 content 未被简化，导致完整摘要重复保留 #3975 stub master 从未拿到)、BUMPED=0(master 与 PR head 的 kernel 版本都是 0.0.185 → 无版本行 diff)→ 红「kernel/ source changed without bumping the version」。

为什么这是机械修复而非越权代批:① 失败在 Rule 2(版本纪律),不在缺声明——正文声明一直都在。② 我只改版本号 + 生成的 lockfile,没碰一行 kernel 源码(floor 16 待 owner 拍板的是 #3975 那段源码,其字节未变)。③ max+1 是确定性规则、零设计依赖;本线程 floor 25(→0.0.184)、floor 28(→0.0.185)已就同一「master 前进撞版本」机制做过同样的 max+1 同步。④ 按 AGENTS.md「无决策依赖的部分先修」,不应把它串行阻塞在 owner 授权之后。

八问

1. 是什么问题:PR 唯一红 check = kernel-guard,判「kernel/ 源码变更但 kernel/package.json 无版本行增量」。
2. 什么原因导致的:master 合入 The storage-render golden snapshot on master went stale after kernel 0.0.184 (#5860): the next scheduled CI run will def | master 的 storage-render 黄金快照在 kernel 0.0.184(#5860)之后过期:定时 CI 下次必红 #5867 estimate-hold backstop(bcda253a56)把 acp-kernel 升到 0.0.185,与本分支早已 bump 到的 0.0.185 相撞;于是本 PR 独有的 The plain text content of MCP compress is not simplified, causing the full summary to be redundantly retained. | MCP compress 的纯文本 content 未被简化，导致完整摘要重复保留 #3975 kernel/src(hide-consumed.ts / parse-compress-input.ts)相对 master 有差异却无对应版本增量 → Rule 2 触发。属继承性版本漂移,非本 PR 逻辑缺陷。
3. 影响范围与严重程度:仅本 PR 的合并门禁(kernel-guard 一格);无运行时行为影响、无用户可见缺陷,严重度=流程阻塞。test 矩阵上一 head 已全绿(F3 随 The storage-render golden snapshot on master went stale after kernel 0.0.184 (#5860): the next scheduled CI run will def | master 的 storage-render 黄金快照在 kernel 0.0.184(#5860)之后过期:定时 CI 下次必红 #5867 落地转绿)。
4. 怎么修复的:max+1 同步——bump kernel/package.json 0.0.185→0.0.186,用 CI 同款命令(npm install --package-lock-only --ignore-scripts --no-fund --no-audit)重生成 kernel/ 与 root 两份 lockfile,diff 仅 4 行版本串、幂等验证通过(二次重生成零漂移);本地复跑 kernel-guard 两条判定 SRC=1 / BUMP=1 均满足。
5. 是否有回归问题:无。改动面只有版本号 + 生成物(lockfile),零代码语义;高危模式逐项过——无语义漂移、无错误处理变化、无默认值/阈值/时序/输出格式变化;lockfile 幂等确保 lock-sync 不红。
6. 是否破坏缓存:不涉及——版本号/lockfile 不参与运行时缓存/重试/去重。
7. 是否改了设计方向:不涉及。
8. 是否引入新的配置:不涉及——零新增 env/config/默认值(仅 acp-kernel 内部版本号推进)。

收工判定:kernel-guard 机械红已清(head 74653f24e6 已推),CI 在新 head 重跑中(镜像缓存此刻仍是旧 head 的过期快照 fetched_at 15:25Z,我未据此断言绿;kernel-guard 两条判定已在本地按 ci.yml 逐条验证通过)。重要边界:本 PR 触及 kernel/,按 Kernel Boundary rule 3 + §7.4 恒属人工合并档——floor 16 的 🔶 需要决策(A 批准人工合并 / B 打回)是 owner 独立待决项,我既无权 approve 也未代批;本次只做版本簿记,不替代该授权。CI 转绿后仍需 owner 人工合并 #4032 。