现象
用 /acp status（或模型的 acp_status 工具）查看消息详情时，列表永远只显示最早的一批消息。消息一多，刚发生的最新内容（比如某个超大工具输出）就看不到——limit 默认 30 条，超过就看不到末尾。
为什么会这样（内核 0.0.29 核实）
内核渲染消息详情列表时的行为：
collectVisible（dist:2437）：遍历 messages 数组，index = 数组位置（0 起升序）renderMessageDrilldown（dist:2562）：
sort === "time" → filtered.sort((a, b) => a.index - b.index) —— 升序，最旧在前shown = filtered.slice(0, limit) —— 只取头部 limit 条，无 offset / reverse / 分页
buildStatusReport 透传 options.sort / options.limit，无"看末尾"机制
推论：以内核当前实现，无论 limit 多大，sort:"time" 只能看到消息序列的前部——除非 limit ≥ 总消息数。
我们引擎侧是纯透传
src/tools.ts:596-634（handleStatus）：scope/view/tool/sort/limit 原样交给 buildStatusReport，无任何排序改写（符合规则 9：drilldown passes through verbatim）。
为什么只有我们受影响
- pi（上游项目）：模型在消息流里能直接看到每条消息的编号标签
<acp tokens="2.1K" type="bash">m00175</acp>（src/messages.ts:297 patchRefTag）——天然知道有哪些消息、最新的在哪，详情列表只是辅助。
- 我们：按照本项目决策 2「Seq is the ref — no
<acp> tags」设计，模型看不到任何 ref 标签，acp_status 的详情列表是唯一能看到消息清单的入口——这个缺陷就被放大了。
方案分析（已核实）
| 调用组合 |
效果 |
能看末尾？ |
sort:"tool"（无过滤） |
工具名分组 + 组内 token 降序（Top tools 展开版） |
❌ 与时间无关 |
tool:"X" + sort:"time" |
过滤后时间升序取前 limit，最新依然看不到 |
❌ 还是从头 |
tool:"X" + sort:"size" |
过滤后 token 降序，看到该工具最大的几条 |
⚠️ 只看到大消息 |
结论：sort:"tool" 帮不了"时间序末尾"；tool:"X" + sort:"size" 能帮"找某工具的大工具输出"（可压缩目标），但需要模型知道该工具名。
缓解（紧迫性有限）：压缩其实用 nudge 的 seq 范围（buildCompressibleSeqRanges，oldest-first + toolPct），不需要单消息 ref——"看末尾"是信息需求，不是压缩操作前置。
怎么修（两条路）
- 宿主侧适配（可选，低风险）：acp_status 工具描述/文档引导
tool:"X" + sort:"size" 找大工具输出
- 上游根治：acp-kernel PR——
ranxianglei/acp-kernel#123 为详情列表新增 reverse（排序后翻转，sort:"time" + reverse:true 就能从最新看起）和 offset（翻页）。pi 和我们都能受益。等它合并发布、我们升级内核版本后，本问题即解决，届时关闭此 issue。
验收标准
上游追踪：acp-kernel issue #93（ranxianglei/acp-kernel#93）→ 修复 PR ranxianglei/acp-kernel#123（reverse + offset，基于 v0.0.38，含 7 条回归测试，444 tests 全绿）。
现象
用
/acp status（或模型的acp_status工具）查看消息详情时，列表永远只显示最早的一批消息。消息一多，刚发生的最新内容（比如某个超大工具输出）就看不到——limit 默认 30 条，超过就看不到末尾。为什么会这样（内核 0.0.29 核实）
内核渲染消息详情列表时的行为：
collectVisible（dist:2437）：遍历 messages 数组，index= 数组位置（0 起升序）renderMessageDrilldown（dist:2562）：sort === "time"→filtered.sort((a, b) => a.index - b.index)—— 升序，最旧在前shown = filtered.slice(0, limit)—— 只取头部 limit 条，无 offset / reverse / 分页buildStatusReport透传options.sort/options.limit，无"看末尾"机制推论：以内核当前实现，无论 limit 多大，
sort:"time"只能看到消息序列的前部——除非 limit ≥ 总消息数。我们引擎侧是纯透传
src/tools.ts:596-634（handleStatus）：scope/view/tool/sort/limit原样交给buildStatusReport，无任何排序改写（符合规则 9：drilldown passes through verbatim）。为什么只有我们受影响
<acp tokens="2.1K" type="bash">m00175</acp>（src/messages.ts:297 patchRefTag）——天然知道有哪些消息、最新的在哪，详情列表只是辅助。<acp>tags」设计，模型看不到任何 ref 标签，acp_status的详情列表是唯一能看到消息清单的入口——这个缺陷就被放大了。方案分析（已核实）
sort:"tool"（无过滤）tool:"X"+sort:"time"tool:"X"+sort:"size"结论：
sort:"tool"帮不了"时间序末尾"；tool:"X"+sort:"size"能帮"找某工具的大工具输出"（可压缩目标），但需要模型知道该工具名。缓解（紧迫性有限）：压缩其实用 nudge 的 seq 范围（
buildCompressibleSeqRanges，oldest-first + toolPct），不需要单消息 ref——"看末尾"是信息需求，不是压缩操作前置。怎么修（两条路）
tool:"X"+sort:"size"找大工具输出ranxianglei/acp-kernel#123为详情列表新增reverse（排序后翻转，sort:"time" + reverse:true就能从最新看起）和offset（翻页）。pi 和我们都能受益。等它合并发布、我们升级内核版本后，本问题即解决，届时关闭此 issue。验收标准
sort:"time" + reverse:true能看到最新消息上游追踪：acp-kernel issue #93（ranxianglei/acp-kernel#93）→ 修复 PR ranxianglei/acp-kernel#123（
reverse+offset，基于 v0.0.38，含 7 条回归测试，444 tests 全绿）。