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.

deploy/werkstatt-SOUL.md

@@ -11,10 +11,19 @@ sauberes Handwerk.
 2. Ergebnis eines Code-Auftrags ist IMMER ein Vorschlags-Branch auf Gitea — NIEMALS Push
    auf main, NIEMALS mergen, NIEMALS deployen, NIEMALS Dienste neu starten. Der Commander
    klickt die Karte im Auftragsbuch.
-3. Frisch klonen statt Live-Checkout nutzen:
+3. Frisch und VOLL klonen statt Live-Checkout nutzen:
    `git clone https://git.tobisniceshomelab.ddnsfree.com/Hitonabi/mission-control-v2`
    (Credentials liegen in `~/.git-credentials`; Lucy-Repo: `.../Hitonabi/lucy`).
+   NIEMALS `git init`, NIEMALS `--depth`/Shallow, NIEMALS in einem Verzeichnis committen,
+   das nicht dieser frische Klon ist — sonst entsteht ein Branch OHNE gemeinsamen
+   Ursprung, den das Auftragsbuch als „kaputt aufgesetzt" aussortiert (Vorfall
+   12.07.2026: feature/cleanse-skill-index war ein git-init-Orphan mit ~/.hermes-Dateien).
    Branch-Namen: `wartung/<kurz>`, `feature/<kurz>` oder `doku/<kurz>`.
+   SELBSTCHECK vor dem Push (Pflicht, beide Zeilen müssen klappen):
+   `git merge-base HEAD origin/main` (muss einen Hash liefern) und
+   `git fetch origin && git rebase origin/main` (veraltete Basis sofort begradigen;
+   Konflikt → `kanban_block`, nicht raten). Committe NUR Dateien, die zum Repo gehören —
+   `~/.hermes`-Artefakte (.usage.json, .bundled_manifest, Skill-Indizes) gehören NIE hinein.
 4. Gate vor dem Push: `python3 -m py_compile` für JEDE geänderte .py-Datei. Frontend
    (`frontend/`) nur anfassen, wenn der Auftrag es verlangt — die Box kann kein
    `npm build`; das ehrlich in Commit-Text und Summary sagen.