Memory und Synchronisierung

Memory ist ein eingebautes Architektur-Plugin von oHarness (memory), kein MCP-Server. Es registriert die Memory-Tools, den Index im System-Prompt, den Abruf pro Nachricht, die optionale Extraktion, die Memory-Seite und einen Hintergrund-Synchronisierer – alles über denselben PluginHost wie Modell-, Tool- und Audit-Plugins. Die Seitenerweiterung bleibt schlank: registrierte Deskriptoren plus Renderer, die dem Host gehören (derzeit memory), kein beliebiges Frontend-JavaScript und kein iframe-SDK.

Wo Notizen liegen

Eine Notiz pro Markdown-Datei, mit JSON-Frontmatter:

---
{"id":"pricing-borderless-3fa","summary":"Pricing cards use fills, not borders","type":"feedback","tags":["design"],"createdAt":1789000000000,"updatedAt":1789000000000}
---
Cards on the pricing page are separated by fill and whitespace.

**Why:** the outlines were the loudest thing on a page of numbers.

**How to apply:** keep the border declared but transparent. See [[pricing-layout-a91]].

Geltungsbereich	Verzeichnis	Enthält
`project`	`<project>/MEMORY/`	Entscheidungen, Einschränkungen und Verweise, die mit dem Projekt umziehen und exportiert werden
`user`	`~/.oharness/memory/user/`	Wer der Nutzer ist und wie er arbeiten möchte, in jedem Projekt

Jedes registrierte Projekt trägt eine .oharness/project.json. Ihre stabile ID hält Sitzungen auf der Home-Seite, Sync-Zustand und Abrufstatistiken zugeordnet, wenn der Ordner umbenannt oder exportiert wird. Ein Git-Repository nutzt anfangs seinen Root-Commit als diese ID; andere Verzeichnisse erhalten eine zufällige Projekt-ID. OHARNESS_HOME verlegt Nutzernotizen und maschinenlokalen Zustand, verschiebt aber nie das MEMORY/-Verzeichnis des Projekts.

memory.dir (oder das ältere memoryDir) in der Konfiguration überschreibt das Projektverzeichnis, relativ zur Projektwurzel. Lässt sich das Nutzerverzeichnis nicht anlegen, bleiben Projektnotizen in <project>/MEMORY verfügbar; nur Notizen auf Nutzerebene und der Memory-Zustand auf der Home-Seite fehlen, und eine Warnung weist darauf hin.

Typen

Typ	Standard-Geltungsbereich	Was er festhält
`user`	user	Rolle, Fachwissen und Arbeitsvorlieben des Nutzers
`feedback`	project	Eine Korrektur oder einen Ansatz, den der Nutzer bestätigt hat
`project`	project	Eine Entscheidung und ihren Grund, eine Einschränkung, laufende Arbeit, die sich nicht aus dem Code ableiten lässt
`reference`	project	Wo externe Informationen liegen

Nur user-Notizen landen standardmäßig im Nutzerbereich. Feedback landet standardmäßig im Projekt, weil sich die meisten Korrekturen darauf beziehen, wie an einer Codebasis gearbeitet wird; eine, die offensichtlich überall gilt, wird bewusst in den Nutzerbereich gelegt.

Notizen, die vor der Einführung der Typen geschrieben wurden, haben keinen und funktionieren weiter. type geht nur dann in den Inhalts-Hash einer Notiz ein, wenn er vorhanden ist, sodass bestehende Notizen die Hashes behalten, die ihre Sync-Baselines bereits enthalten.

Notizen schreiben

Das Modell schreibt mit remember, liest mit memory und löscht mit forget. remember aus dem Memory-Plugin läuft in jedem Berechtigungsmodus ohne Rückfrage durch, außer in plan, das es wie jeden anderen Schreibvorgang ablehnt. Eine ask- oder deny-Regel, die remember nennt, gilt weiterhin, forget fragt weiterhin nach, und ein Tool namens remember aus einem anderen Plugin erhält keine solche Ausnahme. Tags werden vor dem Speichern getrimmt, an Kommas und Leerzeichen getrennt und dedupliziert. Der Memory-Abschnitt im System-Prompt sagt, wann sich eine Notiz lohnt und wann nicht. remember gibt die vorhandenen Notizen zurück, die dem gerade Geschriebenen am nächsten kommen, markiert ein wahrscheinliches Duplikat und listet Links auf, die auf noch nicht existierende Notizen zeigen. Alles, was wie eine Anmeldeinformation aussieht, wird abgelehnt. Notizen sollen Tags für die anderen Wörter tragen, die jemand verwenden könnte: Synonyme und den Begriff in der anderen verwendeten Sprache, denn der Abruf vergleicht Wörter, nicht Bedeutung.

Notizen verlinken einander im Text als [[note-id]]. Links werden beim Laden der Notizen aus den Texten abgeleitet; nichts davon wird separat gespeichert, und das Sync-Protokoll weiß nichts von ihnen. Ein Link wird zuerst im Projektbereich aufgelöst, dann im Nutzerbereich. Ein Link auf eine fehlende Notiz bleibt erhalten: Meist nennt er eine Notiz, die jemand schreiben wollte.

Automatische Extraktion

Standardmäßig aus, weil jeder Durchlauf ein Modellaufruf auf Kosten des Nutzerguthabens ist. Mit memory.autoExtract.onStop übergibt das Ende eines Laufs das Gespräch seit dem letzten Durchlauf an das kleine Modell, sobald seit damals mindestens minUserTurns echte Nutzernachrichten zusammengekommen sind. Mit onCompaction (oder onStop) wird der Teil des Abschnitts, den die Verdichtung gleich verwerfen wird und den noch kein Durchlauf gelesen hat, zuerst übergeben, egal wie kurz, denn es ist die letzte Gelegenheit, ihn zu lesen. Eine fortgesetzte Sitzung zählt ab dem Punkt, an dem sie fortgesetzt wurde, statt ihren gesamten Verlauf erneut zu extrahieren. Aus Subagenten wird nie extrahiert.

Der Extraktor bekommt die vorhandenen Notizen gezeigt, die dem Gespräch am nächsten kommen. Die relevantesten wenigen kommen mit vollständigem Text, innerhalb eines Größenbudgets, und nur diese dürfen aktualisiert werden; der Rest wird zum Verlinken mit seiner Zusammenfassung aufgelistet. Eine Aktualisierung ersetzt den Text, daher wird die ersetzte Version zuerst nach ~/.oharness/memory-backups/ gesichert. Seine Antwort gilt als nicht vertrauenswürdig: Aktualisierungen von IDs, die ihm nicht gezeigt wurden, werden verworfen, Links auf IDs, die ihm nicht gezeigt wurden, verlieren ihre Klammern, Anmeldedaten werden geschwärzt, und neue Notizen in einem Stapel verweisen aufeinander als [[new:N]], bis sie IDs haben. Die Konfiguration eines Repositorys kann die Extraktion abschalten; einschalten kann sie nur die eigene Konfiguration des Nutzers.

Die Extraktion endet erst, nachdem der auslösende Lauf beendet ist. Die gespeicherten Notizen werden daher zu Beginn der nächsten Nachricht angekündigt: „saved N memories from this conversation“, in jedem Frontend.

Abruf

Zwei Wege bringen Notizen vor das Modell:

Der Index. Zu Beginn jedes Laufs eine Zeile pro Notiz, die zuletzt aktualisierte zuerst, bis zu memory.indexChars Zeichen. Der Rest wird gezählt, nicht verloren; das Tool memory durchsucht alle.
Abruf pro Nachricht. Jede Nutzernachricht wird gegen jede Notiz bewertet, und die besten Treffer werden dieser Nachricht in <recalled-memory> angehängt, zusammen mit den Notizen, auf die sie verlinken, aufgelistet mit Zusammenfassung. Die Frontends zeigen „recalled N memories“. Es wird nichts angehängt, wenn nichts die Schwelle überschreitet – der Normalfall. Gibt es gar keine Notizen, wird der Index durch zwei Zeilen ersetzt, die sagen, wann man eine schreibt, statt durch die vollständige Anleitung.

Die Bewertung ist lexikalisch und läuft lokal: Wörter werden auf ihren Stamm reduziert, CJK-Text wird in überlappende Paare zerlegt, und Treffer in Zusammenfassung und Tags wiegen mehr als Treffer im Text. Eine Notiz muss in Zusammenfassung oder Tags treffen, um überhaupt angehängt zu werden. Eine einmal angehängte Notiz wird nicht erneut angehängt, solange eine Nachricht, die sie trägt, im Verlauf bleibt – auch nachdem die Sitzung fortgesetzt oder die App neu gestartet wurde; die IDs werden aus den Metadaten der Nachrichten zurückgelesen. Die Verdichtung gibt die Notizen frei, deren Nachrichten sie wegzusammengefasst hat. Angehängte Notizen stehen in einem eigenen Block der Nutzernachricht, festgehalten in deren Metadaten, sodass Verläufe, Sitzungstitel und der Web-Verlauf die eigenen Worte des Nutzers zeigen. Subagenten rufen nichts ab.

Ein fehlschlagender Abruf verhindert nie, dass eine Nachricht gesendet wird.

Limits

Einstellung	Standard	Bedeutung
`memory.maxNotes`	5000	Pro Geltungsbereich. Darüber werden die am längsten nicht geänderten Dateien nicht geladen, eine Warnung nennt die Anzahl; neue Notizen werden abgelehnt, bis einige entfernt sind
`memory.maxNoteBytes`	131072	Textgröße; der Sync-Server wendet zusätzlich sein eigenes Limit an
`memory.indexChars`	4000	Zeichen an Zusammenfassungen im System-Prompt
`memory.recall.enabled`	true	Abruf pro Nachricht
`memory.recall.perTurn`	3	An eine Nachricht angehängte Notizen
`memory.recall.budgetChars`	2000	Zeichen, die diese Notizen belegen dürfen
`memory.recall.minScore`	1.2	Schwelle für das Anhängen
`memory.autoExtract.onCompaction` / `onStop`	false	Automatische Extraktion
`memory.autoExtract.minUserTurns`	3	Kürzere Gespräche werden übersprungen

Wie oft jede Notiz abgerufen wurde, wird pro Rechner in ~/.oharness/memory-usage/ gespeichert, außerhalb der Notizen, sodass der Abruf nie einen Sync-Upload auslöst. Es beeinflusst das Ranking leicht und wird nie synchronisiert.

Cloud-Sync

Notizen funktionieren immer lokal, abgemeldet und offline.
Die Anmeldung aktiviert standardmäßig die automatische Synchronisierung. Sync läuft in beide Richtungen: Lokale Änderungen gehen hoch, und Änderungen von anderen Geräten kommen von selbst herunter.
Die Memory-Seite bietet 关闭云同步 und 立即同步. Der Schalter gilt für beide Geltungsbereiche. „Aus“ bleibt über Neustarts und erneute Anmeldung erhalten und blockiert automatische und manuelle Cloud-Anfragen, bis es ausdrücklich wieder aktiviert wird. Lokale Tools und Bearbeitung funktionieren weiter.
Das Abschalten von Sync bricht laufende Anfragen ab. Daten, die Cloud bereits angenommen hat, lassen sich nicht zurückziehen; das Abschalten löscht keine Cloud-Kopien.
Jeder logische Projekt- bzw. Nutzerbereich ist an das erste synchronisierende Konto und den Cloud-Origin gebunden. Ein Wechsel von Konto oder Origin pausiert den Sync. Die Seite bietet keine unsichere Neuzuordnung per Klick.

Die Seite pflegt ~/.oharness/plugins.json (OHARNESS_HOME überschreibt das) unter runtimePlugins[id=memory].config.syncTargets[sha256(stableScopeKey)]:

{ "userId": "verified-account-label", "origin": "https://your-cloud.example", "enabled": false }

Legen Sie keine R2-Schlüssel oder Supabase-Konfiguration in dieser Datei ab. Die URL von Cloud bleibt in cloud.json; R2-Anmeldedaten existieren nur in der Umgebung des Sync-Deployments. Um das gesamte Plugin zu deaktivieren (Seite, Tools, Prompts, Abruf und Hintergrundarbeit), fügen Sie { "id": "memory", "enabled": false } zu runtimePlugins hinzu; das wirkt bei der nächsten Harness-Erstellung. Die Projektregistrierung legt weiterhin die leeren Standardverzeichnisse MEMORY/ und ARTIFACTS/ an. Für Einbettende ist harness.memory der Projektspeicher und harness.memoryUserService der des Nutzers; beide fehlen, wenn das Plugin deaktiviert ist. AgentOptions.memory bleibt eine Einbettungs-API auf niedrigerer Ebene und erhält den Abruf ohne Plugin-Host.

Wann synchronisiert wird

Ein Koordinator pro Prozess plant jedes Notizverzeichnis, egal wie viele Projekte ein lokaler Webserver oder die Desktop-App geöffnet hat. Jedes Verzeichnis hat einen Sync-Dienst im Prozess, sodass die eigenen Notizen des Nutzers einmal synchronisiert werden statt einmal pro offenem Projekt.

Ein lokaler Schreibvorgang wird etwa drei Sekunden später hochgeladen; eine Reihe von Schreibvorgängen ergibt einen Durchlauf.
Ansonsten wird ein Verzeichnis jede Minute geprüft, mit Rückfall auf alle fünf Minuten, solange sich auf keiner Seite etwas ändert.
Ihre eigenen Notizen werden immer geprüft. Die Notizen eines Projekts werden nur geprüft, solange das Projekt in Gebrauch ist (eine Nachricht darin gesendet oder die Memory-Seite geöffnet), und dreißig Minuten danach.
Der Prozess beschränkt sich auf etwa zwanzig Anfragen pro Minute und lässt so unter dem Limit pro Konto des Sync-Dienstes Raum für andere Geräte.
Ein 429 pausiert jedes Verzeichnis bis zu der Zeit in seinem Retry-After, und die Seite meldet, dass zu häufig synchronisiert wurde und erneut versucht wird, statt die Konfiguration zu beschuldigen.

立即同步 läuft immer sofort.

Was die Seite zeigt

Der Schalter, „zuletzt synchronisiert“ und Fehler gelten für beide Geltungsbereiche: Sync gilt nur als an, wenn er für beide an ist, die angezeigte Zeit ist die ältere der beiden, und jeder Fehler sagt, ob er Projektnotizen oder Ihre eigenen betrifft. Die Seite zeigt außerdem, was der letzte Pull gebracht hat (hinzugefügt, geändert, entfernt), und in einem kostenlosen Tarif dessen Limits.

Notizen aufräumen

Die Liste 待整理 auf der Seite ist eine Prüfung auf diesem Rechner, ohne Modell:

Befund	Bedeutung	Was Sie tun können
Gleiches Thema	Zwei bis sechs Notizen in einem Geltungsbereich, deren Zusammenfassungen und Tags sich weitgehend überschneiden	Zusammenführen oder verwerfen
Defekter Link	Ein `[[id]]`, das keine Notiz nennt	Notiz öffnen oder verwerfen
Fehlende Datei	Eine Projektnotiz nennt einen relativen Pfad, der nicht im Projekt existiert	Öffnen oder verwerfen
Ungenutzt	Weder abgerufen noch bearbeitet seit `memory.consolidate.unusedDays` (90)	Öffnen oder verwerfen
Zu lang	Ein Text über 8.000 Zeichen	Öffnen oder verwerfen

Ein Verwerfen wird lokal gegen die aktuellen Versionen der Notizen gespeichert, sodass das Bearbeiten einer davon den Befund zurückbringt.

Zusammenführen öffnet einen Editor mit einem Entwurf: dem des kleinen Modells (生成合并建议) oder allen Originalen aneinandergehängt (手动合并). Beim Anwenden bleibt die ID der ältesten Notiz erhalten, die anderen werden gelöscht, jeder [[deleted]]-Link in diesem Geltungsbereich zeigt dann auf die behaltene Notiz, und jede geänderte Notiz wird gesichert. Eine Zusammenführung, die aus inzwischen geänderten Notizen geplant wurde, wird abgelehnt.

Mit aktivem Cloud-Sync wird der Geltungsbereich zuerst synchronisiert und die Zusammenführung vor diesem Rechner in der Cloud festgeschrieben (commitFirst), sodass eine zwischenzeitliche Änderung von einem anderen Gerät die Zusammenführung ablehnt, statt zu einem Konflikt zu werden. Der zusammengeführte Text muss in das Limit pro Notiz des Sync-Dienstes passen. Bei abgeschaltetem Sync ist die Zusammenführung eine gewöhnliche lokale Bearbeitung.

Zusammenführen im Hintergrund ist standardmäßig nur für bezahlte Tarife aktiv ("auto": "subscribers"): Es läuft, wenn die letzte Antwort des Sync-Dienstes besagt, dass das Konto oder eines seiner Teams einen bezahlten Tarif hat, und bleibt für kostenlose Konten aus sowie immer dann, wenn der Tarif unbekannt ist (Cloud-Sync aus, abgemeldet). true oder false überschreibt das:

{ "memory": { "consolidate": { "auto": false, "cooldownHours": 24, "maxMerges": 3 } } }

Wenn aktiv, startet ein Durchlauf höchstens einmal pro Abkühlzeit zwei Minuten nach dem Start und führt bis zu maxMerges Gruppen von Notizen zum gleichen Thema mit dem kleinen Modell zusammen, auf demselben Weg wie die Seite. Auf die anderen Befunde reagiert er nie. Eine Projektkonfiguration kann ihn abschalten, aber nicht einschalten.

Backups und Wiederherstellung

Eine Kopie wird nach ~/.oharness/memory-backups/ geschrieben, bevor eine Notiz ersetzt oder entfernt wird, ohne dass jemand diese Version gewählt hat: Löschen auf der Seite, forget, Übernahme der Cloud-Seite eines Konflikts, ein automatischer Pull, der eine Notiz ändert oder entfernt, eine Neufassung durch den Extraktor und eine Wiederherstellung, die eine neuere Version ersetzt. Die Memory-Seite listet die letzten fünfzig mit Zeitpunkt und Grund und stellt jede davon in dem Verzeichnis wieder her, aus dem sie stammt; die Notiz wird dann wie jede andere lokale Änderung synchronisiert. Backups, die geschrieben wurden, bevor Gründe erfasst wurden, werden ebenfalls aufgelistet und lassen sich wiederherstellen.

Speicherung und Abgleich

Der Sync-Server stellt authentifiziert /v1/memory/identity, /snapshot und /commit bereit. Er speichert keine Datenbankzeilen. R2 enthält unveränderliche Markdown-Revisionen plus ein atomar ersetztes JSON-Manifest:

users/<server-verified-user-id>/projects/<project-id>/memory/
users/<server-verified-user-id>/memory/                       user scope
  manifest.json
  objects/<note-id>/<revision-id>.md

Implementierungen dürfen ein anderes Identitäts- oder Speichersystem verwenden; die genauen Anfrageformen, der Hash-Algorithmus, das CAS-Verhalten und die Fehlercodes sind im Sync-Protokoll festgelegt.

Die lokale Baseline (~/.oharness/memory-sync/) ermöglicht einen Drei-Wege-Abgleich: Unveränderte Notizen werden übersprungen, einseitige Änderungen kopiert. Daneben hält der Client eine Kopie jeder Notiz im Stand der letzten Synchronisierung, sodass eine auf beiden Seiten geänderte Notiz zusammengeführt statt nur markiert wird:

Zusammenfassung und Typ kommen von der Seite, die sie geändert hat;
Tags werden als Mengen kombiniert: Was eine Seite hinzugefügt hat, bleibt, was eine Seite entfernt hat, fällt weg;
Texte werden zeilenweise zusammengeführt, und auseinanderliegende Bearbeitungen werden kombiniert;
eine Bearbeitung gegen eine Löschung behält die Bearbeitung, denn erneutes Löschen ist ein Klick, eine verlorene Bearbeitung aber ist weg.

Vor einer Zusammenführung werden beide Versionen gesichert. Was sich nicht kombinieren lässt (zwei verschiedene Zusammenfassungen oder Typen, Änderungen an denselben oder benachbarten Zeilen, eine Zusammenführung, die für den Tarif zu groß ist, oder eine Notiz ohne Kopie ihres zuletzt synchronisierten Stands), wird zum Konflikt. Ein Konflikt hält nur seine eigene Notiz zurück: Alles andere wird weiter hoch- und heruntergeladen. Die Memory-Seite zeigt den zuletzt synchronisierten Stand, den dieses Rechners und den der Cloud und bietet an, den Stand dieses Rechners zu behalten, den der Cloud zu übernehmen, beide zu behalten (der Cloud-Stand wird zu einer neuen Notiz daneben) oder von Hand zusammenzuführen; was beiseitegelegt wird, wird gesichert, egal von welcher Seite es stammt. Es gibt kein Überschreiben nach dem Prinzip „letzter Schreibvorgang gewinnt“. Löschungen sind Tombstones, und Manifest-Schreibvorgänge nutzen ETag-Compare-and-Swap.

Stapeländerungen, die niemand Notiz für Notiz prüft (Konsolidierung), werden zuerst in die Cloud geschrieben: Jede beteiligte Notiz muss vollständig synchron sein, der Commit trägt die geprüfte Manifest-Version, und erst wenn der Dienst ihn annimmt, wird der Stapel lokal geschrieben. Eine zwischenzeitliche Änderung von einem anderen Gerät lehnt der Dienst ab, statt dass sie zum Konflikt wird.

Anfragen listen die Hashes der Notizen auf, die dieser Rechner hält (have); der Server liest diese Texte weder noch gibt er sie zurück, sodass ein Sync mit wenigen Änderungen wenig überträgt. Commits werden auf das vom Server angekündigte Änderungskontingent aufgeteilt. Tombstones, die älter sind als das Zeitfenster des Servers, fallen aus dem Manifest; ein Rechner, der danach zurückkommt, findet eine Notiz, die er zuletzt synchron und unverändert gesehen hat, nicht mehr gelistet und löscht sie, während eine Notiz, die er in der Zwischenzeit bearbeitet hat, zum Konflikt wird. Zwei Notiz-IDs, die sich nur in Groß- und Kleinschreibung unterscheiden, werden abgelehnt, da die Dateisysteme von macOS und Windows nicht beide aufnehmen können.

Sync wiederholt vorübergehende Fehler nach einer Abkühlzeit von 60 Sekunden; ein manueller Sync kann sofort erneut versuchen. Konflikte warten auf den Nutzer. Die Seite sichert gelöschte Notizen und unterlegene lokale Versionen von Konflikten unter ~/.oharness/memory-backups/; forget tut dasselbe. Direkte Bearbeitungen im Dateisystem werden weiterhin unterstützt, aber ein gleichzeitiger externer Schreibvorgang während einer Zusammenführung ist durch die prozesslokale Schreibsperre nicht geschützt; lassen Sie pro Verzeichnis nur einen Prozess laufen.

R2 ist privat und nutzt TLS, aber das ist keine Ende-zu-Ende-Verschlüsselung: Cloud kann den Inhalt der Notizen lesen. Synchronisiert werden nur Notizen, keine Sitzungsprotokolle, Dateien oder Anmeldedaten.

Kontingente und Tarife

Der Server verwaltet seine Kontingente selbst und kündigt sie in jeder Antwort an; Clients halten keine Kopie. Standardwerte: 5000 aktive Notizen pro Projekt und pro Nutzer, 500 Änderungen pro Commit, 128 KiB pro Text, 16 MiB an Texten pro Antwort, 90 Tage pro Tombstone. Ein gesenktes Kontingent blockiert nur Wachstum, sodass ein Nutzer darüber immer löschen kann. Die Variablen finden Sie unter Eigenen Sync-Server betreiben.

Für kostenlose Konten gelten zusätzlich engere Limits: eine Anzahl Notizen pro Projekt und pro Nutzer sowie eine Größe pro Notiz, festgelegt in src/memory-entitlements.json des Sync-Dienstes. Bezahlte Konten haben kein Tariflimit, nur das obige Kontingent. Der Tarif wird aus dem ent-Claim gelesen, den Cloud in das Access-Token schreibt: Ein eigener bezahlter Tarif des Nutzers oder der eines seiner Teams gilt als bezahlt. Begrenzt ist nur der Cloud-Sync; Notizen auf dem Rechner sind es nicht, und ein kostenloses Konto über dem Limit behält jede lokale Notiz und hört auf, neue hochzuladen, mit einer Meldung, die den Grund nennt.

Ein Konto löschen

Das Löschen eines Kontos auf der Website entfernt alles, was es synchronisiert hat: Sitzungs-Feeds und Memory in beiden Geltungsbereichen. Das Gateway ruft POST /v1/admin/erase des Sync-Dienstes mit einem Schlüssel auf, den nur es besitzt (OHARNESS_SYNC_ADMIN_KEY auf beiden Seiten), bevor das Konto selbst gelöscht wird, und danach noch einmal. Der Sync-Dienst schreibt zuerst eine Markierung für das Konto und lehnt ab dann dessen Feed- und Memory-Anfragen ab, sodass ein noch angemeldetes Gerät die Daten nicht erneut hochladen kann. Notizen und Sitzungen auf Ihren eigenen Rechnern bleiben unberührt.

Das Löschen eines Teams tut dasselbe für den gemeinsamen Sitzungsverlauf des Teams: Das Gateway löscht feed/team-<id>/ (das {team}-Erase des Sync-Dienstes), nachdem das Abonnement des Teams gekündigt wurde und bevor seine Zeilen entfernt werden, und danach noch einmal. Der Sync-Dienst lehnt die Feeds dieses Teams ab dann ab, selbst für ein Token, das es noch auflistet. Teams haben kein Memory.

Upgrade

Aktualisieren Sie den Sync-Server vor den Clients. Ein neuer Client fällt gegenüber einem alten Server für Projektnotizen ohne Typ auf das alte Protokoll zurück. Notizen auf Nutzerebene oder Notizen mit Typ kann er nicht mit einem alten Server synchronisieren. Ein alter Client, der eine typisierte Notiz aus der Cloud erhält, stellt den Sync mit einem Prüfsummenfehler ein, bis er aktualisiert wird.

Verifizierung und Deployment

Führen Sie npm run test:memory, npm run test:sync-memory, npm run test:plugins, npm run typecheck und npm run build aus. script/memory-ui-demo.ts startet eine isolierte, abgemeldete Oberfläche auf 4319 mit einem temporären Home-Verzeichnis; es liest nie die Anmeldedaten des Nutzers. Fehlende R2-Konfiguration erzeugt einen sichtbaren Sync-Fehler, ohne das lokale Memory zu beeinträchtigen. Starten Sie den lokalen Dev-Server nach Änderungen am Quellcode neu.

← Cloud-Connectors Selbst gehosteter Sync →