Repository navigation
compress 端点落在被 orphan-hiding 隐藏的失败 compress 调用上时整条区间被拒为 cannot be anchored（应吸附到相邻可见消息） #396
Description
现象
compress 区间的端点如果落在一个被 orphan-hiding 隐藏的失败 compress 调用上，整条区间会被拒为 cannot be anchored，即使区间里其余内容都可见、合法、超过最小体量。这个端点并没有被任何块消费，错误文本却说 "likely consumed by an existing block" / "message content changed"，会误导模型。
环境
- billion-context-pi 0.1.77（npm 包，未改动），宿主 Prime Agent 0.9.6（
PI_ACP_FORK_HOST=1），模型 gpt-6-astra - 相关代码在 acp-kernel master
77b651a上与 0.1.77 打包版一致：src/hide-consumed.tsKEEP_LAST_ORPHANED = 2；src/boundaries.tsresolveAnchorIndex的consumed分支
复现（headless，两个回合）
回合 1：一次成功的 compress（建 b1），之后 4 次失败的 compress（前 3 次是 Total compressible content too small (… min 5000)，第 4 次被 [ACP] PAUSED — 3 compress attempts already failed this turn 挡住）。留下 4 个无块 compress 调用 m00011 / m00013 / m00015 / m00017 及其结果。hideConsumedCompressCalls 只保留最近 2 个，m00011、m00013 被移出可见视图。
回合 2（新的 user 消息）：compress m00011..m00028（区间内可见内容 > 5000 字符）→
Requested range(s) cannot be anchored (e.g. m00011..m00028) — the refs exist in this session's ref map, but the messages they point to are no longer in the visible context and no active block covers them: the message content changed (or the message was filtered out of the view) and now carries a new ref, leaving your old refs dangling. [diagnostics: session highest ref=m00028, unknown ranges in request=0/1, session history=1 compression(s), 1 block(s)] Run acp_status, then call the compress tool again using only the refs it reports.
同一回合 compress m00003..m00008 正常建出 b2（34.1K → 16.7K），说明问题只在端点。
机制
m00011在messageRefs.byRef里存在 → 不是unknown。- 它指向的消息被 hide-consumed 的 orphan 窗口藏掉，不在
indexByMessageId里。 - 没有 active block 覆盖它 →
activeOwnerAnchor返回 null → 抛BoundaryNotFoundError("consumed", …)。
被藏掉的只是一个无块、没有内容价值的失败 compress 调用，却让整条区间失效。
模型会用到这种 ref，是因为它在同一回合里亲眼见过这些调用（都是它自己刚发出的）；orphan 窗口往后滑，调用就从视图消失了，但模型记住的 ref 在 byRef 里仍然合法。我们之前在 0.1.69 上做离线复现时也见过：acp_status 刚报告的可压区间，同一回合内因为窗口滑动变得无法锚定。
影响
单次看代价不大：白费一次 compress，报错引导模型跑 acp_status 后能恢复。但是：
- 这类拒绝会占用每回合 3 次的失败配额（bcp
MAX_COMPRESS_ATTEMPTS）； - 和 KEEP_LAST_ORPHANED orphan-hiding swallows actionable compress rejection diagnostic (#330 factor 3) | KEEP_LAST_ORPHANED orphan-hiding 吞掉可操作的 compress 拒绝诊断(#330 factor 3) #220（orphan-hiding 把拒绝诊断本身也藏掉）叠在一起时，模型拿不到正确原因，容易反复踩；
- 错误文本把原因说成"内容变了/已被块消费"，与实际不符。
建议（任选其一）
resolveAnchorIndex：端点的 raw id 属于被 hide-consumed 隐藏的 orphan compress call/result 时，start 吸附到其后第一条可见消息，end 吸附到其前最后一条可见消息，返回snapped提示而不是抛错（和现有 "anchored to the active block covering it instead" 同一种处理）。- hide-consumed 保留 refs 仍然可见的 orphan 调用，窗口只裁剪 refs 已失效的。
- 至少让
consumed分支区分"被 orphan-hiding 隐藏"和"被块消费"，给出准确原因。
相关：#220、#307。bcp 侧相关的日志误报：ranxianglei/billion-context-pi#532
Activity
ranxianglei commentedon Sep 25, 2026
继续
ranxianglei commentedon Sep 25, 2026
继续
ranxianglei commentedon Sep 25, 2026
[bot] 进程此前因长时间无输出被强制重启了一次，现已恢复并继续。
进展：已定位根因——
src/boundaries.ts的resolveAnchorIndex中，当端点 ref 存在于byRef、但对应消息被 orphan-hiding 移出可见视图、且没有任何 block 覆盖它时，会落入consumed分支抛出误导性的 "likely consumed by an existing block"。计划采用 issue 建议的方案 1：此类端点吸附到相邻可见消息（start→其后第一条、end→其前最后一条）并返回snapped提示；无法吸附时回退为准确报错。正在补复现测试 + 实现，完成后回复结论与 PR 链接。ranxianglei commentedon Sep 25, 2026
[bot] 已修复，PR: #397 #397 （CI 运行中）
审核结论（先审后改）
messageRefs.byRef中存在、但消息被hideConsumedCompressCalls的 orphan 窗口（KEEP_LAST_ORPHANED=2）从可见列表移除后不在indexByMessageId，又无 active block 覆盖 →resolveAnchorIndex抛BoundaryNotFoundError("consumed")，整条区间被拒；报错文案「likely consumed by an existing block」把原因归错了。仅凭 (可见消息 + state) 无法区分二者，唯一区分信号是「隐藏路径删掉了哪些 ref」，而该信息在
processTurn→applyCompression之间丢失。所以根治办法是让隐藏路径把被隐藏孤儿的 ref 记进 state，而不是在边界解析里盲目吸附——盲目吸附会把 fix: protected-zone rejection carries acp_status guidance; leanPack ref-stability wording (#385) #387 的 dangling 场景变成误导性的「too small」并破坏其回归测试。hiddenOrphanRefs时才吸附，否则维持原报错。start 向前吸附到下一个可见消息、end 向后吸附到上一个可见消息并返回 snapped 提示；若该方向无相邻可见消息，则给出准确报错。行为变更（按规范显式披露 旧→新）
需人工合并：本改动新增一个可选 state 字段
CompressionState.hiddenOrphanRefs?（旧持久化 state 无此字段 = 视为空，无需迁移），属 §7.3 状态结构变更，故不自动合并。请 owner 自行合并：#397验证：新增 tests/orphan-endpoint-snap.test.ts（6 例全过，含 #387 守卫 + 端到端
applyCompression）；全量 1047 pass / 0 fail；typecheck、build 均绿。无 wire 格式变更、无新增依赖、不改 pipeline 节点顺序。一句话：修复了 compress 端点落在被隐藏的失败 compress 调用上时整条区间被误拒的问题（吸附到相邻可见消息，#387 语义保持不变），已提 PR #397，因涉及新增可选 state 字段需你手动合并。
ranxianglei commentedon Sep 25, 2026
[bot] 补充：PR #397 的 CI 已全部通过（test / pr-validation / build-artifact 均 success），与本地 typecheck+test(1047/0)+build 一致，可放心合并：#397
ranxianglei commentedon Sep 25, 2026
[bot] 先同步现状：实现侧已无待办。PR #397 当前状态 —— open、非 draft、
mergeable=true、mergeable_state=clean（无冲突）、CI 四项全绿（test×2 / pr-validation / build-artifact）、无未处理的 review 或行内评论。修复本身已完成并交付。剩下唯一的一步是人工合并。按系统规则 Agent 不能合并任何 PR，需 owner 自行操作：#397 （页面点 Merge，或走 API）。我无法代合。
如果你说的「继续」是指别的方向，请明确一下，我马上接着做，例如：
告诉我具体要哪一项，我立即继续。
Merge pull request #397 from ranxianglei/2026-09-25_orphan-endpoint-snap