OrbitPilot

内存状态 — 一页，一个真相 (BL-428)

这个页面是什么

OrbitPilot 已经在多个不同的地方跟踪它对你的记忆：仪表盘上的构建卡片、每个 Blink 旁边的小图标，以及当内存过时时它向自己的答案添加的一行。发货当天业主自己的话：一个对 SCOPE 没有提示的更新时间——“今天更新但无法访问”——是一个真实的句子，但仍让你感到困惑。内存状态页面 (/orbitpilot/memory-status/) 将所有内容集中在一个页面上：内存最后一次更改的时间及其方式，当前所有来源及其计数，以及——对于任何缺失内容——以简单语言说明的真实原因。

它显示了什么

最后更新。 内存最后一次更改的时间和方法——完全重建、快速更新或单个已保存更改的自动/手动更新——此外，如果内存过时、退化或从未构建过，OrbitPilot 此刻会附加到答案上的确切句子。
在你的记忆中。 每个在内存中有真实内容的来源——Blinks、目标、项目、业务、文件等等——以及每个来源的项目计数和上次构建时间。
不在你的记忆中。 每个其他可用来源，每个都有可操作的原因：在站点范围内关闭、不在你的计划中（升级将添加它）、待移动到受保护的 OrbitPilot 文件夹中的文件，或根本还没有被构建提取。

从这个页面刷新内存

自 BL-435 起，最后更新 卡片自带两个刷新操作—— Quick update（仅重新读取自上次构建以来的更改；成本低）和 Full rebuild（重新读取并重新嵌入所有内容；使用更多 AI 信用）——因此没有人需要离开页面就能对它展示的内容采取行动。它们与 OrbitPilot 聊天窗口的  menu Memory 相同，由业主的规则“不要重复代码”：一个共享模板部分 (templates/_orbitpilot_rebuild_controls.html) 在两个界面上渲染，一个端点 (orbitpilot_rebuild_memory，POST mode=soft|hard)，相同的确认对话框，相同的点击堵塞构建恢复（BL-404 收割者）和相同的实时进度环（BL-410）。按钮由文档级 [data-op-rebuild] 委托在 static/js/orbitpilot-widget.js 中连接；由于该脚本是延迟加载的，orbitpilot-loader.js 在加载之前排队点击并重放它（rebuildFromButton），就像它保护聊天按钮的第一次点击一样。当构建完成时，此页面会自动重新加载，以便“最后更新”信息重新从 get_memory_status_page 读取，而不是变得过时。保护：orbitpilot/test_memory_status_page.py::RebuildControlsTests 在按钮被复制到第二个模板或注册第二个重建路由时失败。

在哪里找到它

在 OrbitPilot 聊天窗口的底部工具栏中有一个“🤖 内存状态”链接——与新建/历史/复制/此聊天位于同一行——因此它距离每个对话都是一键之遥，无论是停靠还是全屏。访客看到相同的链接，但它会引导到账户创建，因为还没有个人记忆可以报告。

这如何运作——针对管理员

今天无需进行任何配置。该页面对所有已登录用户开放；一个更高计划的限制（例如，限制高层用户使用）距离功能注册只需一行——注册一个 Feature，键为 orbitpilot_memory_status_page 并分配或禁用，无需代码更改。

员工和超级用户账户在页面上看到额外通知：他们的账户完全绕过计划限制（plans.services.get_effective_limits 向员工无条件提供所有标志），因此员工账户看到的与同计划的非员工用户看到的并不相同。这是为了确保管理员从未将其自己跳过的视图误认为真实用户页面的样子。

这如何运作——针对开发人员

orbitpilot/services.py::get_memory_status_page(user) 是整个计算，它仅进行聚合——它调用每个其他界面已经使用的完全相同的函数，因此这个页面绝对不会与它们不一致：get_last_build/get_last_completed_build，memory_is_stale，build_notice.ask_honesty_note（BL-405，逐字返回）以及 resolve_build_sources + _plan_gate_reason （#597 / BL-410-P1，相同原因 build_user_snapshot 在对话中提供模型）。每个来源的计数来自于一个 GROUP BY 语句在 OrbitPilotMemoryChunk 上，排除了 get_rag_disabled_keys()，与 pipeline/retrieve.py 排除的方式相同——一个管理员在构建后关闭的来源在表中仍然有行，而这个页面在检索时无论如何都不应将这些行称为“内存中的”。

视图：orbitpilot.views.orbitpilot_memory_status，URL 名称 orbitpilot_memory_status。模板：orbitpilot/templates/orbitpilot/memory_status.html。平衡由 orbitpilot/test_memory_status_page.py 锁定——一个测试创建一个真实的块行，并断言页面的计数等于对同一表的简单查询，所以页面不会默默开始重新计算自己的数字。