Befund 17.09.: Sonntags-Update hatte beide Ebenen gepinnt (Hermes 06.09., Engine 13.09.),
die Box stand zwei Wochen still. Live nachgestellt und behoben:
- llama.cpp hat --no-mmap zwischen b10819 und b10936 gestrichen ("invalid argument"):
jedes Modell starb 2 s nach dem Start, der Stack-Check sah nur "rot". Ersatz
--load-mode none in llama-swap-Config, CMD_TEMPLATE und Bench-Skripten. Gemessen auf
b11026: Coder+DFlash2 32,0 t/s (vorher 30,0), Hirn 85 t/s, alle sieben Rollen laden.
- hermes update endet mit Exit 1, wenn sein Fleet-Check nach dem eigenen Gateway-Neustart
keine Zeilen sieht (#93406) - unter systemd bei uns der Normalfall. Die &&-Kette des
MC2-Jobs brach ab, autoupdate.sh rollte zurueck und pinnte, obwohl der Gehirn-Check gruen
war. Jetzt --no-gateway-restart: Neustart und Urteil gehoeren dem Job.
- Box live: Engine b11026, Hermes v0.21.3 (main @ dd13b475), UI mit /hermes-ui/-Basis neu
gebaut, Pins geloest. STACK.md/FALLEN.md nachgezogen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Der erste Live-Lauf der Lucy-Annahme (wartung/pc-annahme-und-turncheck-aus) fand
zwei Bugs im Box-Runner — der Build selbst war gruen, nur Start und Abschluss
mussten manuell nachgezogen werden:
1) Start-Process -ArgumentList quotet Elemente NICHT (PS 5.1): der Runner-Pfad
'F:\Coding Stuff\lucy\...' zerbrach am Leerzeichen, die gespawnte powershell
starb still (kein Status, kein Log). Fix: Anfuehrungszeichen ins -File-Element
eingebettet. (Der Probe-Test lief ueber einen Pfad OHNE Leerzeichen — deshalb
nicht gefangen.)
2) Poll-Parser: \" in f-String-Ausdruecken ist seit Python 3.12 ein SyntaxError
(Box: 3.14) -> der Poll blieb blind und haette den GRUENEN Merge nach 25 min
revertiert. Fix: keine f-String-Quote-Akrobatik mehr, Werte in Variablen.
Neuer Parser 1:1 auf der Box getestet.
3) executor.py /shell: CREATE_NO_WINDOW — der Executor laeuft unter pythonw,
jede gespawnte powershell bekam ein SICHTBARES Konsolenfenster (Polling
blitzte im 10-s-Takt auf dem Desktop). Nach Annahme: PC-Checkout pullen +
HermesPCExecutor-Task neu starten (mache ich, steht auch in FALLEN.md).
Beide Fallen + Fensterblitz in docs/wissen/FALLEN.md; OFFENE-FAEDEN: S3-Stand.
Geprueft: bash -n gruen, py_compile gruen, Parser auf Box-Python 3.14 verifiziert.
