Files
mission-control-v2/docs/wissen
Hitonabi 552299a761 Annahme-Selbstheilung: Orphan-Branches entlarven, veraltete Branches auto-rebasen
Anlass: feature/cleanse-skill-index — ein Werkstatt-Worker hatte git init statt
Klonen gemacht (Orphan-Commit ohne gemeinsamen Vorfahren, Inhalt: ~/.hermes-Index-
Dateien statt Repo-Dateien). Solche Karten sahen aus wie normale Vorschlaege,
liefen bei Annahme aber IMMER in 'refusing to merge unrelated histories' — und
die Fehlermeldung ('bitte am PC aufloesen') war eine Sackgasse. Das passiert
oefter; darum drei Schichten dagegen:

1) ERKENNEN (Auftragsbuch): neue Karten-Flags 'verwaist' (kein merge-base mit
   main -> rote Markierung 'kein gemeinsamer Ursprung', Annehmen-Knopf fehlt,
   API+Runner halten zusaetzlich dicht) und 'leer' (Diff gegen main leer ->
   'bringt nichts'-Badge). Empfehlung auf der Karte: ablehnen mit Grund,
   Idee frisch in die Queue.

2) HEILEN (beide Runner, mc2 + lucy): kollidiert der Merge, weil main weiter-
   gelaufen ist, versucht der Runner automatisch einen Rebase des Branches auf
   main (isolierter Worktree; Gates laufen danach normal, Merge-Message sagt
   'auto-rebased'). Nur wenn auch der Rebase kollidiert, faellt die Karte durch —
   mit ehrlicher Meldung statt 'am PC aufloesen'.

3) VERHINDERN (werkstatt-SOUL): voll klonen (nie git init/--depth), Selbstcheck
   'git merge-base HEAD origin/main' + fetch/rebase vor JEDEM Push, nie
   ~/.hermes-Artefakte committen.

Doku: AUFTRAGSBUCH.md + FALLEN.md (Erkennungsmuster: Diff 0 Dateien + behind ~
ganze Historie) + OFFENE-FAEDEN. Geprueft: py_compile gruen, bash -n beide
Runner gruen, tsc+vite build gruen (dist dabei); merge-base-Verhalten am echten
kaputten Branch auf der Box verifiziert.
2026-07-13 09:34:23 +02:00
..

docs/wissen/ — Die Wissens-Heimat für ALLE Agenten

Angelegt 10.07.2026 (Übergabe-Session S1). Dieses Verzeichnis ist die kuratierte Übergabe des Claude-Projektwissens ins Repo — damit Box-Hermes, Hermes Desktop, Gemini/Antigravity und jeder künftige Agent dieselbe Wahrheit lesen.

Warum hier: Die Box liest ~/mission-control-v2/docs/wissen/, Antigravity liest den F:\-Checkout — versioniert, deploybar, kein Agent-privates Gedächtnis. Der Wissens-Vault (~/wissens-vault/) bleibt Lucys LERNSCHICHT (Träume, Radar-Funde, Eigenbau-Landkarte); hier liegt das kuratierte PROJEKT-Wissen.

Die Dateien (Lese-Reihenfolge für einen frischen Agenten)

Datei Inhalt Wann lesen
ZIELBILD.md Richtungs-Entscheid 10.07.: Box übernimmt alles, 4-Session-Paket Immer zuerst — das ist der Kurs
ARBEITSWEISE.md Wer der User ist + die nicht verhandelbaren Arbeitsregeln Vor JEDER Arbeit
STACK.md IPs, Ports, Dienste, Modelle, Backups, Security (live verifiziert) Vor SSH/Deploy/Config
VERDIKTE.md Finale Technik-Entscheide mit Warum — NICHT neu aufrollen Bevor man etwas "Besseres" vorschlägt
FALLEN.md Hart erarbeitete Betriebs-Fallen (Git, Deploy, llama-swap, Hermes, Mem0, PC) Bevor man in eine davon läuft
OFFENE-FAEDEN.md Die EINE Liste offener Punkte + Termine Bei "was ist noch zu tun?"

Dazu im Repo-Wurzelverzeichnis bzw. docs/: AGENTS.md (verbindliche Projekt-Regeln), docs/GEMINI_BRIEFING.md (Notfall-/Review-Briefing für Gemini), docs/RUNBOOK.md (1-Seiten-Mensch-Anleitung), docs/ANTIGRAVITY_REVIEW.md (Review-Prompt).

Pflege-Regeln

  1. Erledigtes raus, Neues rein — OFFENE-FAEDEN.md ist die einzige offene Liste, keine neuen "pending"-Dateien anlegen.
  2. Verdikte werden nur mit neuem, belegtem Anlass wieder geöffnet (Messung, Release, User-Entscheid) — dann in VERDIKTE.md den alten Eintrag ERSETZEN, nicht löschen.
  3. Verifizieren vor Behaupten: Stand-Angaben tragen ein Datum; wer STACK.md ändert, hat live auf der Box gemessen/gelesen, nicht vermutet.
  4. Änderungen laufen wie alles über die Pipeline: Branch → Karte im Auftragsbuch → Klick. Reine Doku hier gehört zu den "Bagatellen ohne Klick"-Klassen (siehe ZIELBILD.md), erscheint aber immer in Morgenlage/Chronik.