OrbitPilot

Speicherstatus — eine Seite, eine Wahrheit (BL-428)

Was diese Seite ist

OrbitPilot hat bereits an verschiedenen Stellen verfolgt, was es über ihre erinnert: eine Build-Karte auf dem Dashboard, kleine Symbole neben jedem Blink und eine Zeile, die es zu seinen eigenen Antworten hinzufügt, wenn der Speicher veraltet ist. Die eigenen Worte des Eigentümers am Tag des Versands: eine Aktualisierungszeit, die über den SCOPE schweigt — "heute aktualisiert, kann aber nicht zugreifen" — ist ein wahrheitsgemäßer Satz, der dich trotzdem verwirrt zurücklässt. Die Speicherstatus-Seite (/orbitpilot/memory-status/) stellt alles auf einer Seite dar: wann sich der Speicher zuletzt geändert hat und wie, jede aktuell darin enthaltene Quelle mit Zählungen und — für alles, was fehlt — den ehrlichen Grund warum, in einfacher Sprache.

Was es zeigt

Letzte Aktualisierung. Die Zeit, zu der sich der Speicher zuletzt geändert hat und die Methode — ein vollständiger Neuaufbau, eine schnelle Aktualisierung oder ein automatisches/manuelles Update von einer einzigen gespeicherten Änderung — plus, falls der Speicher veraltet, degradiert oder noch nie aufgebaut wurde, der genaue Satz, den OrbitPilot gerade an eine Antwort anhängen würde.
In deinem Speicher. Jede Quelle mit echtem Inhalt im Speicher — Blinks, Ziele, Projekte, Unternehmen, Dateien und mehr — mit einer Elementanzahl und wann sie zuletzt aufgebaut wurde.
Nicht in deinem Speicher. Jede andere verfügbare Quelle, jede mit einem umsetzbaren Grund: von der gesamten Seite deaktiviert, nicht in deinem Tarif (ein Upgrade würde es hinzufügen), Dateien, die darauf warten, in den geschützten OrbitPilot-Dateifolder verschoben zu werden, oder einfach noch nicht von einem Build erfasst.

Speicher von dieser Seite aktualisieren

Seit BL-435 trägt die Letzte Aktualisierung-Karte die beiden Refresh-Aktionen selbst — 4a1 Schnelle Aktualisierung (liest nur das nach, was sich seit dem letzten Build geändert hat; günstig) und 5ce Vollständiger Neuaufbau (liest alles neu und bettet alles neu ein; benötigt mehr AI-Credits) — sodass niemand die Seite verlassen muss, um auf das, was sie zeigt, zu reagieren. Es sind die genau gleichen Kontrollen wie im OrbitPilot-Chatfenster im 5e3 Menü 4a1 Memory, laut der Regel des Eigentümers "den Code nicht verdoppeln": EINE geteilte Template-Partial (templates/_orbitpilot_rebuild_controls.html) wird auf beiden Oberflächen gerendert, EIN Endpunkt (orbitpilot_rebuild_memory, POST mode=soft|hard), der gleiche Bestätigungsdialog, das gleiche Stuck-Build-Heilmittel bei Klick (BL-404 Erntearbeiter) und der gleiche Live-Fortschrittsring (BL-410). Die Schaltflächen sind durch dokumentenweite [data-op-rebuild]-Delegierung in static/js/orbitpilot-widget.js verdrahtet; da dieses Skript lazy-loaded ist, wartet orbitpilot-loader.js auf einen Klick, der ankommt, bevor es geladen hat und spielt ihn ab (rebuildFromButton), auf die gleiche Weise, wie es den ersten Klick des Chat-Buttons schützt. Wenn ein Build abgeschlossen ist, lädt sich diese Seite selbst neu, damit die "Letzte Aktualisierung"-Fakten neu aus get_memory_status_page gelesen werden, anstatt veraltet zu gehen. Wachen: orbitpilot/test_memory_status_page.py::RebuildControlsTests schlagen fehl, sobald die Schaltflächen in eine zweite Vorlage kopiert werden oder ein zweiter Neuaufbau-Routen registriert wird.

Wo man es findet

Ein "9f0 Speicherstatus"-Link befindet sich in der unteren Werkzeugleiste des OrbitPilot-Chatfensters — derselbe Bereich wie Neu / Verlauf / Kopieren / Dieser Chat — sodass es nur einen Klick von jedem Gespräch entfernt ist, angedockt oder in Vollansicht. Gäste sehen denselben Link, aber er führt stattdessen zur Kontoerstellung, da es noch keinen persönlichen Speicher zu berichten gibt.

Wie das funktioniert — für Administratoren

Heute ist nichts zu konfigurieren. Die Seite ist für jeden angemeldeten Benutzer offen; ein späteres Plan-Gate (z.B. die Einschränkung auf höhere Stufen) ist eine Zeile im Funktionsregister entfernt — registriere ein Feature mit dem Schlüssel orbitpilot_memory_status_page und weise es zu oder deaktiviere es, ohne Codeänderungen erforderlich.

Stab- und Superbenutzerkonten sehen eine zusätzliche Mitteilung auf der Seite: Ihr Konto umgeht die Plan-Gates vollständig (plans.services.get_effective_limits übergibt den Mitarbeitern jede Flagge bedingungslos), sodass das, was ein Mitarbeiterkonto sieht, nicht das ist, was ein nicht-Staff-Nutzer mit demselben Tarif sieht. Dies gibt es, damit ein Administrator seine eigene umgangene Ansicht niemals mit dem, wie die Seite eines echten Benutzers aussieht, verwechselt.

Wie das funktioniert — für Entwickler

orbitpilot/services.py::get_memory_status_page(user) ist die gesamte Berechnung, und sie AGGREGIERT NUR — sie ruft die genau gleichen Funktionen auf, die jede andere Oberfläche bereits verwendet, sodass diese Seite niemals mit ihnen in Konflikt geraten kann: get_last_build/get_last_completed_build, memory_is_stale, build_notice.ask_honesty_note (BL-405, wörtlich zurückgegeben) und resolve_build_sources + _plan_gate_reason (#597 / BL-410-P1, die gleichen Gründe, die build_user_snapshot dem Modell mitten im Gespräch übergibt). Per-Quelle Zählungen stammen von einem GROUP BY über OrbitPilotMemoryChunk, wobei get_rag_disabled_keys() auf die gleiche Weise ausgeschlossen wird, wie pipeline/retrieve.py sie ausschließt — eine Quelle, die ein Administrator ausgeschaltet hat, nachdem sie erstellt wurde, hat immer noch Zeilen in der Tabelle, und diese Seite darf diese Zeilen nicht "im Speicher" nennen, wenn eine Abfrage sie niemals suchen wird.

Ansicht: orbitpilot.views.orbitpilot_memory_status, URL-Name orbitpilot_memory_status. Vorlage: orbitpilot/templates/orbitpilot/memory_status.html. Parität wird durch orbitpilot/test_memory_status_page.py gesichert — ein Test erstellt eine echte Chunk-Zeile und bestätigt, dass die Anzahl auf der Seite gleich einer einfachen Abfrage über dieselbe Tabelle ist, sodass die Seite nicht stillschweigend beginnen kann, ihre eigenen Zahlen neu zu berechnen.