Gemeinsamen Projektspeicher über verschachtelte Repos teilen

Standardmäßig wird ein Projekt über sein umschließendes Git-Repository identifiziert, sodass jedes physische Git-Repo einen eigenen isolierten Speicher erhält. Das ist falsch für Multi-Repo-Workspaces — Bäume, die von Googles repo verwaltet werden, Monorepos oder jedes Layout, in dem mehrere verschachtelte Git-Repositories zu einem logischen Projekt gehören —, weil jedes Sub-Repository siloed wäre.

Lege eine leere Marker-Datei .opencode-mem-project an der Workspace-Wurzel ab:

my-workspace/
├── .opencode-mem-project   ← Workspace-Wurzel
├── kernel/                 (eigenes Git-Repo)
├── userspace/              (eigenes Git-Repo)
└── tools/                  (eigenes Git-Repo)

Jede Sitzung, die irgendwo unterhalb des Markers gestartet wird, löst dann auf diese Wurzel auf und teilt einen Speicher, unabhängig davon, in welchem Sub-Repo das Arbeitsverzeichnis liegt:

touch ~/my-workspace/.opencode-mem-project

Der Marker wird durch Aufwärtslaufen vom Arbeitsverzeichnis gefunden, das jeder Codepfad bereits übergibt (Arbeitsverzeichnis des Plugins, process.cwd() der Web-API), sodass die Identität verzeichnisgetrieben und prozessunabhängig ist. Sie stützt sich nicht auf Umgebungsvariablen oder einen globalen Config-Wert, die hier unzuverlässig wären: opencode-mem läuft über mehrere opencode-Prozesse, die einen einzelnen Webserver teilen, und nur einige dieser Prozesse tragen eine gegebene Env-Var. Mit dem Marker wird die Projektwurzel immer davon abgeleitet, wo die Sitzung tatsächlich läuft.

Der Marker hat Vorrang vor der Git-Erkennung. Ist er vorhanden, wird die eigene Git-Remote des Sub-Repos absichtlich ignoriert (sie würde nur ein verschachteltes Repository beschreiben). Ohne Marker bleibt das Verhalten unverändert (Git-basierte Identität).