OrbitPilot

告诉OrbitPilot不要记住某些内容 — 实际上，每条消息都是如此 (BL-422)

聊天框下的通知

在OrbitPilot作曲器下方，现在有一行小提示，既出现在固定聊天窗口，也出现在全屏聊天中：“对话记录会被记住，以便我能更好地帮助你”，链接到你的内存状态页面。如果你的计划目前不包含聊天记录作为记忆来源，该行则会明确说明 — 这是与内存状态页面和OrbitPilot自己的请求时间诚实说明相同的理由，从不对同一事实有二次猜测。访客会看到一个邀请，创建一个免费的账户，因为他们的内容尚未被记住。

每条消息的“不要记住”

在你自己消息旁边 — 与OrbitPilot回复的Catch一样的图标组合样式 — 是一个小眼睛图标。点击它，该消息将被标记为不记录。接下来会有三件事情，所有三者的形状的原因皆为所有者自己的话：“如果用户在当前和活跃会话中排除该部分... OrbitPilot在该会话和那一刻是可以看到的，因为它应该能够与用户继续对话。但稍后，当用户关闭会话时，它将被排除在记忆之外。”

OrbitPilot继续跟随对话。排除一条消息从不移除它在此次聊天中OrbitPilot可以看到的部分 — 之后的回复，以及你在同一会话中稍后询问的任何内容，仍然可以使用完整的对话记录。
它永远不会进入长期记忆。在下一个内存构建（快速更新或完全重建）时，该消息及其回复将被跳过 — 它们不会在以后的任何对话中成为可检索的内存块。如果早期构建已经将该交换转化为一个块，下一次构建将移除它。
没有任何内容被隐藏或删除。该消息保持在你的对话历史中的确切位置，仅被标记为“未被记住”，以便你可以一目了然地看到其状态，没有清除按钮 — 决定从你自己可见的历史中删除一条消息是一个单独的、更大的决策，所有者故意将其排除在外。

改变主意

切换功能双向工作，并在下一个内存构建中生效，永远不会立即发生，并且不会对已经运行的构建追溯。排除一条消息，然后在下一个构建运行之前重新启用它，它会被记住，就如同你从未触及过它一样。在已经丢弃一条消息的构建之后重新启用它，它将从下一个构建开始恢复 — 无法回溯并“取消跳过”已经发生的构建。

管理员如何运作

每条消息的切换功能无需配置 — 它对每个已登录用户可用；访客没有持久的聊天记录可供排除。通知的措辞遵循相同的源/计划分配设置（orbitpilot.chat_history），该设置已控制聊天记录是否供用户的内存构建 — 在分配页面上将其关闭，通知会如实告知该计划的用户，使用的措辞与内存状态页面相同。

开发人员如何运作

OrbitPilotMessage.not_remembered （BooleanField，默认值为False）仅存在于用户回合 — 助手回复从不单独标记，因为pipeline/extract.py::_extract_chat_history已经将每条用户消息与其回答的助手消息配对，当标记被设置时，仅跳过发出该对的记录。pair_index在跳过的对中仍然提前，因此同一对话中的每个其他对在各构建中保持其确切的source_id — 排除一回合从不强制重新嵌入后面的每一回合。

切换标记不会写入其他内容。已经构建的块的移除在下一个构建时自然而然地发生，通过services.run_memory_build的现有替换语义：增量（快速更新）路径会删除任何存储的OrbitPilotMemoryChunk，其(source_key, source_id, chunk_index, content_hash)键在新的提取中不再出现，完全重建删除每个块，然后再从新的提取中恢复 — 这两个已经存在于普通内容更改中，而排除的聊天对触发相同路径，不需要新的删除逻辑。

视图：orbitpilot.views.orbitpilot_toggle_remember，网址名称orbitpilot_toggle_remember（POST /orbitpilot/message/remember/, message_id + 可选的format=json，与Catch相同的双AJAX/普通表单响应形状）。图标重用现有的“查看”/“隐藏”注册含义（bi-eye / bi-eye-slash) — templates/blink/_memory_status.html已经用于“AI阅读此内容”与“排除在AI记忆之外”在Blink中使用 — 而不是为相同的概念创造一个新的图标含义。通过orbitpilot/test_bl422_do_not_remember.py固定的平衡。

通知的文本故意比最初看起来的便宜，那是一个在发布前发现的真正回归问题。第一版的orbitpilot.services.get_chat_memory_notice(user)调用了resolve_build_sources — 与BL-428的内存状态页面和BL-405的请求时间诚实说明使用的相同功能 — 与那些页面完全一致。这失败了plans.test_capability_cache.CapabilityCacheSavesQueriesTests：resolve_build_sources在内部调用plans.services.get_plan_for_user两次（一次直接，再一次在get_effective_limits内部），且没有调用线缆连接到plans.capabilities的每请求缓存 — 一个文档化的、故意的缺口（曾经尝试过每请求备忘，但因为门控过时的风险而被撤回）。每次ASK支付一次这个成本已经被接受；每次页面加载支付一次，这对于每个已登录用户在每个页面上，是一个该小部件不得增加的实际更大成本。因此，发布的版本仅检查chat_history的OWN计划分配 — 管理员的In-RAG开关及其源/计划分配行 — 通过plans.capabilities.get_user_plan读取（重复使用页面自身的门控检查所缓存的内容；在请求外降级为普通查询，例如测试）。它不重现计划的整体源CAP（included_sources） — 在这里可以“分配”源，但仍然可能被该cap挤出实际构建（参见SU-101 Q1发现） — 这正是该通知为何始终与更全面的、关注于cap的内存状态页面旁边坐着，你故意访问的页面，在那里支付一次真正的成本是正确的交易。通过orbitpilot/templatetags/orbitpilot_extras.py中的新chat_memory_notice模板标记连接到模板（该小部件没有专门的视图以传递每用户上下文）。

关于SU-101 Q1验证项目的说明

该行询问orbitpilot.chat_history是否实际上受到所有者的“保持开启”意图的覆盖。检查后，得出两个发现：chat_history的OWN计划分配在没有管理员行存在时已可在每个计划上可用（登记的default_visible=True是后备） — 没有需要授予的内容。但是，一个单独的机制仍然可以将其排除：每个计划的included_sources（总体知识源的cap）默认值为3，几个其他默认可见的源在登记中优先于chat_history — 因此在所有者没有亲自提出的计划上，resolve_build_sources会填充cap，然后再到达chat_history。这是实时管理员的计划数据，而不是针对chat_history的特定修复，已经是单独调查的主题（BL-419 / SU-106） — 因此在此报告，而非修补。作为回归保护，在orbitpilot/test_bl422_do_not_remember.py中固定（SU101Q1SourceCoverageTests, SU101Q1SourceCapFindingTests）。