Entscheidung: Volume-Persistenz nach LanceDB-Havarie

Datum: 2026-04-06 | Betroffen: Infrastruktur

Problem

Drei Container-Resets (4.-6. April 2026) durch LanceDB-Installation ohne persistentes Volume → Workspace-Datenverlust.

Entscheidung

Volume bot_workspace_2 dauerhaft mounten auf /home/node/workspace
Provisioning-Reihenfolge: Volume → chown -R node:node → Stateful Plugins installieren
Alle persistenten Daten (Config, memory/, .openclaw/) müssen auf dem Volume liegen
ByteRover .brv-cli benötigt separates Volume für OAuth-Tokens (🔴 nie umgesetzt)

Status

✅ Volume funktioniert, Permission-Fix dokumentiert
❌ .brv-cli-Volume nie deployed → OAuth-Token weiterhin Container-lebensdauer
❌ ByteRover Knowledge Mining blockiert seit 2026-04-11

Hintergrund — Warum das passierte

Vor dieser Entscheidung lief der Bot-Container mit einem ephemeren Filesystem — kein persistentes Volume, kein Bind-Mount. Drei Probleme häuften sich in der ersten Aprilwoche:

LanceDB-Installation am 2026-04-04 verursachte einen Container-Reset, weil das Datenverzeichnis ~/.lancedb auf dem Container-Filesystem lag und beim Rebuild verloren ging.
Memory-System (Schicht 3) baute auf LanceDB auf — Reset bedeutete Totalverlust des Vektor-Index.
OAuth-Tokens (ByteRover .brv-cli, Subconscious-Plugin-Tokens) wurden gleich mitverloren.

Die Entscheidung am 2026-04-06 zog daraus die Konsequenz: alles, was über Container-Lebensdauer hinaus leben soll, gehört auf ein gemountetes Volume — nicht "manchmal" oder "für wichtige Daten", sondern ausnahmslos.

Konsequenzen

Die strikte Volume-Pflicht wurde zur Grundlage für alle späteren Architekturentscheidungen: Memory-System, Wiki-Repository, Plugin-State. Siehe wiki/architecture/container-volume-persistence für die allgemeinen Lessons Learned und wiki/architecture/byterover-knowledge-mining für die konkrete Pipeline, die an genau dieser Lücke scheiterte.

2.4 KiB Raw Blame History