Repository navigation
[面板] organize 上线后：/dream-status 的最近 5 条 run 会混进 run_type='organize'（过滤还是标注） #495
Description
触发条件
organizeEnabled 打开、agent 调用 memory_organize 之后。默认关时一行 organize 回执都不会产生（工具不注册）。
事实（对照 main）
dsh-mneme/src/api.js:1517：const runs = (service.listDreamRuns?.({ limit: 5 }) ?? []).map(...)—— 不分run_type，取最近 5 条。dsh-mneme/src/api.js:1523：run_type: r.run_type ?? "auto"—— 类型是透出给面板的，面板有没有用它是一回事。- 一次整理产生两行：dryRun 报告一行 + apply 回执一行（回执的
outcome.dry_run_id指回报告）。也就是说一次 dryRun→apply 吃掉 5 个名额里的 2 个。 - 这是 PR feat(organize): agent 主动整理接口 dryRun -> apply（issue #231） #267 备注 1 里预留的那个决定，原话：「当前没有工具/API 暴露 organize，生产上不会产生 organize 行；等注册工具那批再决定要不要在面板的巩固列表里过滤它」。注册工具的那批是 feat(organize): agent 主动整理接口接上调用入口（memory_organize + organizeEnabled） #496，本条就是它刻意留下的那一半。
待定的是展示口径，不是数据
两条路都能走：
- 过滤：
/dream-status只列巩固族的行，整理回执另开一个读数。省事，但把「agent 刚刚改过库」这件事从界面上藏起来——而它恰恰是人最该看见的一类改动。 - 标注：保留混排，面板把
organize的行渲染成不同标签（报告 vs 落地还得再分开说），同时保证一次整理不要把列表挤空。信息全，代价是面板文案与run_type的口径都要动。
倾向 2，理由是这条线一贯的取向是「审计面是证据，不因显示面积而省略」；但这是面板侧的决定，归面板线拍。
为什么不在 #496 里做
lib/client.js 是单写者资源（AGENTS.md），面板线有别的工作在跑；#496 只动 src/ 与 test/。
参考
- 落地：PR feat(organize): agent 主动整理接口接上调用入口（memory_organize + organizeEnabled） #496（分支
feat/231-organize-tool-exposure） - 上游：issue [Feature] agent 主动整理接口：dryRun 比对报告 → agent 判断 → apply，全留审计 #231、PR feat(organize): agent 主动整理接口 dryRun -> apply（issue #231） #267 备注 1
Activity
modusensus commentedon Nov 2, 2026
修好了，走的是你倾向的那条路（标注，不是过滤）：#547。
具体形态
/dream-status新增顶层lastConsolidation（excludeRunType: "organize"后取一条），runs仍然是全类型 5 条。卡面取lastConsolidation；只有 organize 跑过时，卡面照实说「尚未运行」，并加一句脚注点名那次整理的时间——不抹掉，也不拿它冒充巩固。KPI 带下方那块「上一轮跳过什么」一并修正了：它原先也读
lastRun，而 organize 回执同样带skipped。但它的跳过不是巩固决策（比如「与既有记忆重复」），混进去会让人以为巩固那一整类动作被拦。三处和提议不完全一样的地方
excludeRunType做成了 SQL 下推，不是调用方后置过滤。 这一点是必须的：后端过滤放在LIMIT之后就已经晚了——5 个名额被 organize 占掉，再筛只能得到空，而那正好是你说的「一次整理不要把列表挤空」的反面。取值走
DREAM_RUN_TYPES白名单。 参数会拼进 SQL 的!=条件，所以只接受已知三个字面量。诚实说一句：测试钉得住「未知值 ⇒ 不过滤」这个可观测契约，钉不住白名单本身——换成裸绑定四条断言仍全绿。价值在纵深，不在可观测行为。没加配置开关。 这是显示口径的更正，不是可选功能。
测试
+5（api ×2、client ×1、store ×1，另原有用例补一行断言），变异自证四例都验过：去掉
excludeRunType→ api 两条红；excluded恒为null→ store 用例红；卡面退回state.lastRun→ client 红；KPI 退回d.lastRun→ client 红。全量
npm test2613 tests / 2612 pass / 0 fail / 1 skipped。顺带确认一下你 issue 里的那句判断，我这边核过是对的：
dream_runs里两行的区分判据就是outcome.dry_run_id的有无（src/organize.js的 dryRun 报告没有它，apply 回执有）。本轮没用到这个判据——按run_type排除足够——但如果你后面想把两行在面板里也分开显示，那个字段是现成的。fix(panel): 「最近巩固」不再显示 organize 整理回执，改按 run_type 区分口径（#495）
Merge pull request #547 from slow-stack/fix/495-dream-status-run-type
modusensus commentedon Nov 2, 2026
实现已合入 main（PR #547，
326f064），走标注而非过滤——这也是当时留的两个选项里更保守的那个：lastConsolidation✅/dream-status新增该字段，带excludeRunType: "organize"src/store.js:2409-2415用DREAM_RUN_TYPES.includes(excludeRunType)白名单筛，不是在取回 5 条之后再过滤（过滤晚一步就会「补不上第 6 条」，榜单变短）runs仍保留全类型 5 条 ✅ 原始读数没被改写，只是多给了一个不让 organize 混进来的视图