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

这页的内容

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

它展示了什么

• 最后更新。 内存最后一次更改的时间和方法——一次完整重建、快速更新，或来自单个保存更改的自动/手动更新——而且如果内存陈旧、降级或从未构建过，OrbitPilot 当前会附加在答案上的确切句子。
• 在你的内存中。 每个实际内容的来源——Blinks、目标、项目、企业、文件等——以及项目计数和最后构建时间。
• 不在你的内存中。 每个其他可用来源，每个都有一个可操作的原因：全站关闭、不在你的计划中（升级将添加此项）、等待移动到受保护的 OrbitPilot 文件夹中的文件，或尚未被构建提取。

在哪里可以找到

在 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 在对话中所交付的相同原因）。每个来源的计数来自对 OrbitPilotMemoryChunk 的一次 GROUP BY，排除 get_rag_disabled_keys() 的方式与 pipeline/retrieve.py 排除它们的方式一样——在构建后管理员关闭的来源仍在表中有行，而该页面在检索时不会搜索这些行，因此不得称这些行为“在内存中”。

视图：orbitpilot.views.orbitpilot_memory_status，网址名称 orbitpilot_memory_status。模板：orbitpilot/templates/orbitpilot/memory_status.html。通过 orbitpilot/test_memory_status_page.py 确保一致性——一个测试创建一个真实块行并断言页面的计数等于对同一表的简单查询，因此页面不能无声地开始重新计算自己的数字。

相关页面

Docshub: “每个 Blink 的内存状态图标”（BL-417，使用相同的词汇和措辞），“你的内存保持诚实”（BL-405）。docs/orbitpilot/TASKS.md.