OrbitPilot

Sag OrbitPilot, dass er sich etwas nicht merken soll — ehrlich, pro Nachricht (BL-422)

Die Mitteilung unter dem Chatfenster

Eine kleine Zeile befindet sich jetzt unter dem OrbitPilot-Composer, sowohl im angedockten Chatfenster als auch im Vollbild-Chat: "Unterhaltungen werden gespeichert, damit ich dir besser helfen kann", mit einem Link zu deiner Speicherstatus-Seite. Wenn dein Plan momentan keinen Chatverlauf als Speicherquelle beinhaltet, wird dies stattdessen deutlich angegeben — aus dem gleichen Grund, den die Speicherstatus-Seite und die Anfrage-Honestheitshinweise von OrbitPilot geben würden, nie einen Zweifel an derselben Tatsache. Gäste sehen stattdessen eine Einladung, ein kostenloses Konto zu erstellen, da von ihnen bisher nichts gespeichert wird.

Pro-Nachricht "nicht merken"

Neben deinen eigenen Nachrichten — im gleichen Icon-Cluster-Stil wie Catch auf OrbitPilots Antworten — befindet sich ein kleines Augensymbol. Tippe darauf und diese Nachricht wird als nicht gespeichert markiert. Drei Dinge folgen, und die Worte des Besitzers sind der Grund für die Form dieser drei: "Wenn der Benutzer diesen Abschnitt für diese aktuelle und aktive Sitzung ausschließt... kann OrbitPilot für diese Sitzung und diesen Moment sehen, weil er in der Lage sein sollte, das Gespräch mit dem Benutzer fortzusetzen. Aber später, wenn der Benutzer die Sitzung schließt, wird es aus dem Speicher ausgeschlossen."

OrbitPilot verfolgt das Gespräch weiterhin. Das Ausschließen einer Nachricht entfernt sie nie aus dem, was OrbitPilot während dieses Chats sehen kann — die Antwort direkt danach und alles, was du später in derselben Sitzung fragst, hat immer den vollen Verlauf, mit dem gearbeitet werden kann.
Es gelangt niemals in den Langzeitgedächtnis. Beim nächsten Speicheraufbau (schnelles Update oder vollständiger Neubau) wird diese Nachricht UND die Antwort, die darauf geantwortet hat, übersprungen — sie werden nie zu einem abrufbaren Speicherblock in späteren Gesprächen. Wenn ein früherer Aufbau diesen Austausch bereits in einen Block umgewandelt hat, entfernt der nächste Aufbau ihn.
Nichts wird versteckt oder gelöscht. Die Nachricht bleibt genau da, wo sie in deinem Gesprächsverlauf war, einfach mit dem Tag "Nicht gespeichert" gekennzeichnet, sodass du ihren Status auf einen Blick sehen kannst. Es gibt keinen Lösch-Button — zu entscheiden, eine Nachricht auch aus deiner eigenen sichtbaren Historie zu löschen, ist eine separate, größere Entscheidung, die der Besitzer absichtlich aus dieser herausgelassen hat.

Meinung ändern

Der Schalter funktioniert in beide Richtungen und tritt bei dem nächsten Speicheraufbau in Kraft, niemals sofort und niemals rückwirkend für einen bereits durchgeführten Aufbau. Schließe eine Nachricht aus, aktiviere sie dann vor dem nächsten Aufbau wieder, und sie wird genau so gespeichert, als hättest du sie nie berührt. Aktiviere sie NACH einem Aufbau, der sie bereits entfernt hat, und sie kommt zurück ab dem nächsten Aufbau — es gibt keine Möglichkeit, auf einen bereits durchgeführten Aufbau zurückzugreifen und ihn "nicht zu überspringen".

Wie das funktioniert — für Administratoren

Es gibt nichts zu konfigurieren für den Pro-Nachrichtenschalter — er ist für jeden angemeldeten Benutzer verfügbar; Gästen steht keine dauerhafte Chatverlauf zur Verfügung, aus dem sie etwas ausschließen könnten. Die Formulierung der Mitteilung folgt der selben Source/Plan-Zuweisung (orbitpilot.chat_history), die bereits steuert, ob der Chatverlauf einen Benutzer-Speicheraufbau überhaupt speist — schalte das für einen Plan auf der Zuweisungsseite aus und die Mitteilung erklärt das den Benutzern dieses Plans ehrlich, in denselben Worten, die die Speicherstatus-Seite bereits verwendet.

Wie das funktioniert — für Entwickler

OrbitPilotMessage.not_remembered (BooleanField, Standard False) existiert nur im USER-Durchlauf — die Assistentenantwort wird nie separat gekennzeichnet, weil pipeline/extract.py::_extract_chat_history bereits jede Benutzer-Nachricht mit der Assistentenantwort, die darauf reagiert, paart und einfach das Emitten des Datensatzes dieses einen Paares überspringt, wenn das Flag gesetzt ist. pair_index steigt immer für ein übersprungenes Paar, sodass jedes ANDERE Paar im selben Gespräch seine genaue source_id über die Aufbauten hinweg beibehält — das Ausschließen eines Durchlaufs zwingt niemals zu einem erneuten Einbetten jedes späteren Durchlaufs.

Das Umschalten des Flags schreibt nichts anderes. Die Entfernung eines bereits aufgebauten Blocks geschieht natürlich beim NÄCHSTEN Aufbau, durch die bestehenden Ersetzungssemantiken von services.run_memory_build: Der inkrementelle (schnelle Update) Pfad löscht jeden gespeicherten OrbitPilotMemoryChunk, dessen (source_key, source_id, chunk_index, content_hash)-Schlüssel im frischen Extraktionsprozess nicht mehr erscheint, und der vollständige Neubau löscht jeden Block, bevor er aus der neuen Extraktion wiederhergestellt wird — beides existierten bereits für gewöhnliche Inhaltsänderungen, und ein ausgeschlossener Chat-Paar löst denselben Pfad ohne neue Löschlogik aus.

Ansicht: orbitpilot.views.orbitpilot_toggle_remember, URL-Name orbitpilot_toggle_remember (POST /orbitpilot/message/remember/, message_id + optionale format=json, die gleiche doppelte AJAX/plain-Form-Antwortstruktur wie Catch). Icons nutzen die EXISTIERENDEN Bedeutungen "sehen"/"verstecken" (bi-eye / bi-eye-slash) — das gleiche Paar, das bereits für "die KI liest dies" vs. "vom KI-Gedächtnis ausgeschlossen" auf einem Blink verwendet wird — anstatt eine neue Icon-Bedeutung für dieselbe Idee zu schaffen. Parität verankert durch orbitpilot/test_bl422_do_not_remember.py.

Der Text der Mitteilung ist absichtlich BILLIGER, als er zunächst aussieht, und das war ein echter Rückschritt, der erkannt wurde, bevor er veröffentlicht wurde. Die erste Version von orbitpilot.services.get_chat_memory_notice(user) rief resolve_build_sources auf — dieselbe Funktion, die die Speicherstatus-Seite von BL-428 und der Anfrage-Honestheitshinweis von BL-405 verwenden — für volle Übereinstimmung mit diesen Seiten. Das scheiterte bei plans.test_capability_cache.CapabilityCacheSavesQueriesTests: resolve_build_sources ruft plans.services.get_plan_for_user intern ZWEIMAL auf (einmal direkt, ein weiteres Mal innerhalb von get_effective_limits), und keiner der Aufrufe ist in den pro-Anfrage-Cache von plans.capabilities verdrahtet — eine dokumentierte, absichtliche Lücke (ein pro-Anfrage-Memo wurde dort einmal versucht und aufgrund des Risikos von Gate-Stale-Updates zurückgenommen). Diese Kosten einmal pro ANFRAGE wurden bereits akzeptiert; diese Kosten einmal pro SEITENLADEVORGANG für jeden angemeldeten Benutzer auf jeder Seite zu zahlen, ist ein wesentlich höherer Preis, den dieses Widget nicht hinzufügen darf. Daher überprüft die ausgelieferte Version nur die eigenständige Plan-Zuweisung von chat_history — der In-RAG-Schalter des Administrators und die Zeile für Source/Plan-Zuweisung — gelesen durch plans.capabilities.get_user_plan (wiederverwendet, was die eigenen Gate-Überprüfungen der Seite bereits zwischengespeichert hat; verschlechtert sich zu einer einfachen Abfrage außerhalb einer Anfrage, z.B. Tests). Sie reproduziert nicht die Gesamtquelle CAP des Plans (included_sources) — eine Quelle kann hier "zugewiesen" sein und könnte dennoch aus einem tatsächlichen Aufbau durch die CAP ausgeschlossen werden (siehe die SU-101 Q1 Feststellung unten) — was genau der Grund ist, warum die Mitteilung immer neben einem Link zur umfassenderen, cap-bewussten Speicherstatus-Seite steht, einer Seite, die du absichtlich besuchst, wo es der richtige Deal ist, den realen Preis einmal zu zahlen. Verdrahtet in die Vorlage über ein neues chat_memory_notice Template-Tag in orbitpilot/templatetags/orbitpilot_extras.py (das Widget hat keine spezielle Ansicht, um kontextabhängige Daten für den einzelnen Benutzer weiterzugeben).

Ein Hinweis zu SU-101 Q1's Überprüfungsitem

Die Zeile fragte, ob orbitpilot.chat_history tatsächlich von der "beibehalten" Absicht des Besitzers abgedeckt ist. Geprüft, zwei Feststellungen: Die eigene Plan-Zuweisung des chat_history wird bereits auf jedem Plan als verfügbar gelesen, wann immer es keine Administrator-Zeile gibt (die Sichtbarkeit des registrierten default_visible=True ist der Rückfall) — nichts zu gewähren dort. Aber ein GETRENNTES Mechanismus kann es dennoch ausschließen: Die included_sources eines jeden Plans (das gesamte Wissensquelle-CAP) defaults auf 3, und mehrere andere standardmäßig sichtbare Quellen sortieren im Registry vor dem chat_history — sodass bei einem Plan, den der Besitzer nicht persönlich erhoben hat, resolve_build_sources das CAP erfüllt, bevor es reaching chat_history. Dies sind live-Administrator-DATEN, kein chat_history-spezifischer Fix, und bereits Gegenstand einer separaten Untersuchung (BL-419 / SU-106) — daher wird es hier berichtet, nicht gepatcht. Verankert als Rückschrittswächter in orbitpilot/test_bl422_do_not_remember.py (SU101Q1SourceCoverageTests, SU101Q1SourceCapFindingTests).