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.
8.9 KiB
Auftragsbuch — die Vorschlags-Inbox der Box
Das Auftragsbuch ist das Mensch-Gate des propose-only-Kreislaufs als Klick statt Git-Handarbeit: alles, was die Box von allein baut oder sich ausdenkt, landet hier als Karte — du entscheidest mit Annehmen oder Ablehnen.
Die Ideen-Queue davor (natives Hermes-Kanban, seit 10.07.2026)
Vor dem Auftragsbuch liegt DIE eine Ideen-Queue: das native Hermes-Kanban
(hermes kanban, SQLite-Board, Dispatcher läuft im Gateway). Der Weg einer Idee:
- Idee rein — Tür egal: Eingabefeld im Auftragsbuch-Tab (
POST /api/ideen), Telegram/Desktop (natives Toolkanban_create, Regel in SOUL.md) oder Lucys Sprech-Leitung (idee_notiereninmcp/mcp_voice.py). Alles landet alstriage-Aufgabe auf demselben Board. - Die Box arbeitet sie aus: der Kanban-Specifier macht aus der rohen Idee
einen sauberen Auftrag und wählt das Worker-Profil (Routing über die
Profil-Beschreibungen: Code →
werkstatt[Qwen3-Coder-Next, Leitplanken indeploy/werkstatt-SOUL.md], Doku/Analyse →default). - Der Worker baut im isolierten Workspace; Code-Ergebnisse pusht er als Vorschlags-Branch auf Gitea — der hier als Karte erscheint. Das Gate bleibt dein Klick.
Die Queue füttert sich auch selbst — Idle-Radar (S4 „Zündung", 12.07.2026): ein
nächtlicher Hermes-Cron (03:45, deploy/idle-radar-feed.sh) destilliert aus den
Journal-Fehlermustern der letzten 24 h und der jüngsten Traum-Notiz bis zu 2 belegte
Wartungs-Kandidaten und legt sie als rohe Ideen (triage, created_by=idle-radar) auf
dasselbe Board. Leitplanken: jedes Beleg-Zitat wird mechanisch gegen das Material
geprüft (erfundene Belege fliegen raus — reproduziert-oder-abgelehnt), Stau-Bremse
(ab 4 offenen Queue-Aufgaben oder 3 offenen Karten legt er nichts nach), dreifacher
Dedup (State-Datei ~/.hermes/state/idle-radar-gemeldet.txt, Board-Abgleich inklusive
archivierter = verworfener Ideen, --idempotency-key), Security/Config/Updates tabu.
Der Radar legt nur Ideen an — gebaut wird über denselben Kreislauf, dein Klick bleibt
das Gate.
Die Queue-Sicht im Tab (Status, offene Ideen) kommt aus hermes kanban list --json
(backend/services/ideen.py); die Morgenlage bekommt kanban stats als
Beweismaterial. Entscheid nativ-vs-Eigenbau (Hermes-first): Probe 10.07.2026 —
Dispatcher, Specifier, Profil-Modellwahl und Artefakt-Tracking sind nativ E2E
bewiesen; ein Eigenbau hätte all das nur nachgebaut.
Woher die Karten kommen
- Fertige Patches — Branches auf Gitea (
wartung/*,orchestrator/*,doku/*,feature/*), wie die Werkstatt und der Orchestrator sie hinterlassen. Die Karte zeigt Commit-Botschaft, geänderte Dateien und den vollen Diff. Seit S3 (lucy-pipeline) aus zwei Repos:mission-control-v2(Box-Stack) undlucy(Desktop-App, rosa „Lucy"-Badge auf der Karte). - Skill-Kandidaten — Ideen des nächtlichen Traum-Crons aus dem Wissens-Vault
(
~/wissens-vault/skill-kandidaten/). „Beauftragen" schickt sie als Auftrag an die Werkstatt (Orchestrator-Skill); das Ergebnis kommt als neuer Patch zurück.
Was „Annehmen" bei einem Patch macht (deploy/auftrag-annehmen.sh)
- Merge des Branches in einem isolierten Worktree (Live-Checkout bleibt unberührt). Kollidiert der Merge, weil main weitergelaufen ist, versucht der Runner automatisch einen Rebase des Branches auf main (Selbstheilung für veraltete Vorschläge) — erst wenn auch der kollidiert, fällt die Karte mit ehrlicher Meldung durch.
py_compile-Gate über die geänderten Python-Dateien.- Push nach
mainauf Gitea (mit Retry). - Deploy (als /tmp-Kopie von deploy.sh — Selbst-Reset-Falle) — die Zentrale startet dabei kurz neu.
- Health-Check mit Geduld. Rot ⇒ automatischer Revert des Merges + Redeploy + Alarm. Grün ⇒ Branch wird aufgeräumt, Meldung an Telegram + Chronik.
Der Lauf ist eine eigene systemd-Unit (detached) — er überlebt den Neustart des
Backends, das ihn gestartet hat. Fortschritt steht live auf der Karte
(/srv/models/mc2-auftragsbuch.json).
Kaputt aufgesetzte Branches (Worker machte git init/Shallow statt zu klonen → kein
gemeinsamer Ursprung mit main, „refusing to merge unrelated histories") erkennt das
Auftragsbuch an der Quelle: rote Markierung „kein gemeinsamer Ursprung", der
Annehmen-Knopf fehlt (Annehmen wäre ein garantierter Fehllauf), API und Runner halten
zusätzlich dicht. Ebenso markiert: „Diff leer — bringt nichts" (Branch würde gegenüber
main nichts ändern). In beiden Fällen: ablehnen mit Grund und die Idee frisch in die
Queue geben; die Prävention (voll klonen, merge-base-Selbstcheck, fetch+rebase vor dem
Push) steht in der werkstatt-SOUL.
Was „Annehmen" bei einer LUCY-Karte macht (deploy/lucy-annahme.sh)
Lucy (Electron) lebt auf dem Windows-PC; ihr dist liegt nicht im Repo — die Box
kann sie nicht bauen. Der Lucy-Runner spannt darum den PC ein (PC-Executor :7777,
Token aus ~/.hermes/config.yaml):
- Vorprüfung am PC, VOR dem Merge: Executor erreichbar? Arbeitskopie
F:\Coding Stuff\lucyaufmainund sauber? Läuft Lucy gerade? Scheitert etwas, bricht der Lauf ab, ohne irgendetwas zu verändern — der PC muss an sein. - Merge des Branches im isolierten Worktree von
~/lucy→ Push nachmain. - Der PC zieht
main(ff-only) und startet detacheddeploy/lucy-annahme.ps1(liegt im Lucy-Repo): ggf.npm ci(nur wenn sich das Lockfile geändert hat) →tsc --noEmit-Gate → dist-Backup →npm run dist→ Lucy-Neustart nur, wenn sie vorher lief (User-Entscheid: Lucy startet nur, wenn der Commander sie will) → Stimme-Health (:8130). - Die Box pollt die PC-Status-Datei (
.lucy-annahme.json) und spiegelt den Fortschritt live auf die Karte. Rot ⇒ Merge wird automatisch revertiert, der PC stellt dist aus dem Backup wieder her — die laufende Lucy bleibt die alte. Grün ⇒ Branch aufgeräumt, Meldung an Telegram + Chronik.
Bagatellen ohne Klick (mc2-bagatell.timer, 04:10)
Einzige Ausnahme vom Klick-Gate (User-Entscheid 10.07.2026, bewusst eng geschnitten):
deploy/bagatell-annahme.sh spielt nachts Vorschlags-Branches ein, deren Diff
ausschließlich .md-Dateien anlegt oder ändert — keine Code-Zeile, keine
Löschungen, keine Renames, keine Skripte. Der Weg ist derselbe Annahme-Runner wie
beim Klick (Merge → Gate → Deploy → Health → Auto-Revert), maximal 2 pro Nacht und
nur Branches ohne vorherige Fehl-Läufe. Fangnetz: Nacht-Sicherung 03:30 liegt davor,
jede Annahme steht in Chronik + Telegram, die Morgenlage 04:30 berichtet. Die Klasse
erweitert nur der Commander, nie das Skript.
„Lucy kennt sich" (12.07.2026): Selbstbild, Empfehlungs-Stempel, Lern-Gedächtnis
- Selbst-Inventur (Cron 03:35,
deploy/selbst-inventur.sh): erhebt den Selbst-Steckbrief der Box live aus der Realität (Versionen, Dienste, Modelle, Crons, Queue, Karten →~/.hermes/state/selbst-steckbrief.md) und bemerkt selbst, wenn sich etwas ändert (Diff gegen gestern → stille Chronik-Karte + kurze Telegram-Zeile; keine Änderung = still). Der Steckbrief ist das „was es schon gibt"-Gedächtnis: Idle-Radar-Analyst und Werkstatt (Realitäts-Check-Regel) lesen ihn, bevor sie vorschlagen oder bauen. - Karten-Gutachter (Cron 04:00,
deploy/karten-gutachter.sh): stempelt jede neue Karte mit „Empfehlung: Annehmen/Ablehnen/Unklar" + einem ehrlichen Satz — geprüft werden Redundanz (existiert das laut Steckbrief schon?), Risiko und Nutzen. Der Stempel ist eine Meinung, kein Gate; ein nachgeschobener Commit macht ihn ungültig (wird neu gestempelt). Ablage/srv/models/mc2-karten-gutachten.json. - Ablehnen mit Grund: Beim Ablehnen einer Karte kannst du der Box in einem Satz
sagen, warum („gibt es schon", „will ich nicht"). Der Grund landet in
/srv/models/mc2-ablehnungen.jsonlund wird Radar/Analysten als „NIE wieder vorschlagen"-Material vorgelegt — dein Klick wird damit zum Lehrer, nicht nur zum Tor. - Radar-Treffer → Queue: Meldet der wöchentliche Release-Radar einen echten Treffer, legt er zusätzlich EINE rohe Idee in die Ideen-Queue („Probe bauen?", idempotent je Release-Tag) — der Blick nach draußen füttert damit denselben Kreislauf.
Leitplanken
- Propose-only bleibt: keine Code-Zeile geht ohne Klick live. Das Gate ist dieses Buch; einzige Ausnahme sind die eng geschnittenen Doku-Bagatellen (oben).
- „Frontend ohne Build"-Warnung (nur mc2): enthält ein Branch
frontend/srcohne frischesfrontend/dist, bleibt die Oberfläche nach dem Annehmen alt, bis am PC gebaut wird. Lucy-Karten brauchen die Warnung nicht — dort baut IMMER der PC. - Ablehnen löscht nur den Remote-Branch; die Historie auf Gitea bleibt.
Diese Datei kam übrigens selbst über das Auftragsbuch ins Repo — als erste echte
End-to-End-Annahme (Probe-Branch wartung/annahme-probe, 08.07.2026).