Commit Graph

9 Commits

Author SHA1 Message Date
Hitonabi c3fe6dbe8d No-Progress-Bremse: Schauen ist keine Schleife + Wiederaufnahme in alle SOULs
‼️ Die Bremse hat den Schaden angerichtet, den sie verhindern soll. Sie signiert
den ERGEBNISTEXT von terminal-Aufrufen; die Bestandsaufnahme in Schritt 0 besteht
aber aus vielen kurzen Schau-Befehlen (ls, cat, git log), deren Ausgaben sich stark
aehneln. Nach dreien blockte sie den naechsten Blick — ausgerechnet `ls /tmp/konzept-*`.
Der Worker las die Block-Meldung als "Verzeichnis existiert nicht", schloss daraus,
das fertige Konzept sei nicht verifizierbar, und warf eine halbe Stunde Arbeit weg
(Karte t_d26c3203, Log: "kein /tmp/konzept-* Verzeichnis gefunden (wegen
No-Progress-Bremse)"). Die Bremse verlangt in ihrem eigenen Text "Diagnose statt
Variation" — und verhinderte genau die.

- _nur_lesend(): rein lesende Befehle (ls/cat/head/find/grep/git status|log|diff|
  ls-remote …, keine Umleitung) werden weder gezaehlt noch geblockt. Strukturell
  nach Befehls-ART, nicht per Fehlertext-Liste — die Bremse bleibt generisch.
- Block-Meldung sagt jetzt ausdruecklich: "Dein Befehl wurde NICHT ausgefuehrt, das
  ist eine Bremse, KEIN Ergebnis — schliesse daraus nichts ueber Existenz oder
  Zustand." Ohne diesen Satz liest ein Agent den Block als Befund.
- Schritt 0 (Wiederaufnahme) + FORTSCHRITT.md jetzt auch in werkstatt-SOUL
  (Klon/Branch pruefen: liegt der Branch schon auf Gitea -> verifizieren und
  abschliessen statt neu bauen) und betrieb-SOUL (vorhandene Messwerte NICHT neu
  messen — ein wiederholter Bench laedt 70-GB-Modelle und gefaehrdet Lucys Warm-Set).
- projektstart: FORTSCHRITT.md gehoert ins Workspace-Wurzelverzeichnis, nicht in den
  Repo-Klon.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-21 09:37:17 +02:00
Auftragsbuch 5436e4df16 Auftragsbuch: 'feature/soul-push-verify' angenommen (Ein-Klick-Gate) 2026-07-13 18:23:33 +02:00
werkstatt a1957d7094 deploy/werkstatt-SOUL.md: Drittes Gate 'Push wirklich gelandet' hinzufügen 2026-07-13 18:21:49 +02:00
claude-direkt 0a9293f669 Werkstatt-Anleitung: Push wirklich verifizieren bevor Abschluss
Drittes Gate nach merge-base + rebase: git ls-remote origin <branch> muss den Branch zeigen, sonst kanban_block statt kanban_complete. Behebt Schein-Erfolg (13.07.2026: Worker meldete gepusht+done, Branch war nie auf Gitea).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-13 18:17:08 +02:00
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
Hitonabi 1570b2fc71 Lucy kennt sich: Selbst-Inventur, Karten-Gutachter, Lern-Klick, Radar->Queue
User-Auftrag 12.07. ("bau das alles ein im Sinne der Autonomie. Auch muss
Lucy selbst bemerken wenn sich etwas aendert"):

- deploy/selbst-inventur.sh (Cron 03:35): SELBST-STECKBRIEF wird LIVE aus
  der Realitaet GENERIERT (Versionen, Dienste, Timer, Modelle, Crons,
  Queue, Karten -> ~/.hermes/state/selbst-steckbrief.md) statt von Hand
  gepflegt. Diff gegen gestern => die Box BEMERKT SELBST Aenderungen an
  sich (stille Chronik-Karte + kurze Telegram-Zeile; sonst still).
- deploy/karten-gutachter.sh (Cron 04:00): stempelt jede neue Karte mit
  "Empfehlung: ANNEHMEN/ABLEHNEN/UNKLAR + ein ehrlicher Satz" (prueft
  Redundanz gegen den Steckbrief, Risiko, Nutzen; Ein-Schuss-Richter
  gpt-oss/GLM; Stempel = Meinung, kein Gate; neuer Commit entwertet den
  alten Stempel). Backend mischt den Stempel in /api/auftragsbuch,
  UI zeigt ihn farbig auf der Karte.
- Ablehnen mit Grund (Lern-Klick): UI-Inline-Feld beim Ablehnen ->
  /srv/models/mc2-ablehnungen.jsonl -> Idle-Radar bekommt die Gruende
  als "NIE wieder vorschlagen"-Material vorgelegt.
- idle-radar-feed.sh: Material + Raster erweitert um Selbst-Steckbrief,
  Inventur-Diff und Ablehn-Gruende (Fehlerfall 12.07.: redundanter
  Gateway-Restart-Vorschlag waere damit gestorben).
- werkstatt-SOUL Regel 7 + wartung-Skill: REALITAETS-CHECK - existiert es
  schon? Dann kanban_block statt Branch (ein Branch fuer Ueberfluessiges
  ist ein gescheiterter Lauf).
- hermes-release-radar-feed.sh: echter Treffer legt zusaetzlich EINE rohe
  Idee in die Queue (idempotent je Release-Tag) - der Blick nach draussen
  fuettert denselben Kreislauf.
- deploy.sh: kopiert beide neuen Skripte; Doku AUFTRAGSBUCH.md +
  wissen/OFFENE-FAEDEN.md; frontend/dist frisch gebaut (tsc+vite gruen,
  UI gegen Live-Box verifiziert).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-12 19:58:00 +02:00
Hitonabi 961b003df4 Zuendung (S4): Idle-Radar + Grossbau-Etappen-Regeln
- deploy/idle-radar-feed.sh (Hermes-Cron 03:45): destilliert aus Journal-
  Fehlermustern (24h) + juengster Traum-Notiz max. 2 belegte Wartungs-
  Kandidaten und legt sie als rohe Ideen (triage) ins native Kanban.
  Ehrlichkeits-Gate: Beleg-Zitat wird MECHANISCH gegen das Material
  geprueft (reproduziert-oder-abgelehnt). Stau-Bremse (>=4 offene Queue-
  Aufgaben oder >=3 offene Karten -> nichts Neues), Dedup dreifach
  (State-Datei + Board-Abgleich inkl. archivierter + --idempotency-key),
  Security/Config/Updates tabu. Analyst gpt-oss-120b, Vertretung GLM.
- deploy/idle-radar-prompt.md: versionierter Boten-Auftrag (Lucys Stimme,
  max 3 Saetze, nichts selbst umsetzen).
- deploy.sh: kopiert idle-radar-feed.sh nach ~/.hermes/scripts/ (greift
  wegen Selbst-Reset-Falle erst ab dem 2. Deploy -> Vorinstallation
  einmalig von Hand; Cron-Registrierung einmalig: hermes cron create).
- Grossbau-Etappen-Regeln (Zielbild-Entscheid 4, 10.07.): werkstatt-SOUL
  Regel 6 + wartung-/orchestrator-SKILL Scope-Check: Grosses nicht mehr
  ablehnen, sondern in Etappen bauen - jede Etappe eigener Branch, fuer
  sich lauffaehig + annehmbar, Folge-Etappen als neue Queue-Aufgaben,
  NIE auf unangenommene Branches aufbauen.
- Doku: AUFTRAGSBUCH.md (Idle-Radar-Abschnitt), wissen/OFFENE-FAEDEN.md.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-12 18:58:05 +02:00
Hitonabi 6d5b09a592 Lucy-Pipeline (S3): Auftragsbuch liest zwei Repos, Annahme baut am PC
Das Auftragsbuch-Gegenstueck fuer Lucy (Abloesungs-Paket S3, PC-Annahme-Weg):

- backend/services/auftragsbuch.py: Multi-Repo (mc2 + lucy via ~/lucy-Clone).
  Karten tragen repo-Feld; Status-Schluessel fuer Lucy = 'lucy:<branch>';
  fehlt ~/lucy, werden Lucy-Karten still weggelassen. Runner je Repo.
- deploy/lucy-annahme.sh: detached Annahme-Runner fuer Lucy-Karten.
  Vorpruefung am PC VOR dem Merge (Executor erreichbar, Arbeitskopie main+clean,
  laeuft Lucy?), dann Merge im isolierten Worktree von ~/lucy -> Push main ->
  PC zieht ff-only und baut detached (deploy/lucy-annahme.ps1 im Lucy-Repo),
  Box pollt .lucy-annahme.json und spiegelt Fortschritt auf die Karte.
  Rot = Merge automatisch revertiert, laufende Lucy bleibt die alte.
  Executor-Zugang (URL+Token) kommt aus ~/.hermes/config.yaml — kein zweiter
  Ablageort. Neustart nur, wenn Lucy vorher lief (User-Entscheid).
- Router/UI: repo-Parameter (rueckwaertskompatibel, Default mc2), rosa
  Lucy-Badge, eigener Annahme-Confirm-Text, Diff/Ablehnen je Repo.
- werkstatt-SOUL: Lucy-Auftraege ebenfalls propose-only, bauen macht der PC
  bei der Annahme.
- Doku: docs/AUFTRAGSBUCH.md (Lucy-Annahme-Kapitel), docs/wissen/OFFENE-FAEDEN
  (S2 erledigt, S3-Stand).

Geprueft: py_compile gruen, bash -n gruen, tsc+vite build gruen (dist dabei).
2026-07-12 14:48:03 +02:00
Claude (Werkstatt PC) e1ca7f6a5e Ideen-Queue: natives Hermes-Kanban wird DIE Sammelstelle (Abloesung S2)
Entscheid nach Probe (Hermes-first): Dispatcher im Gateway, Specifier
(triage -> sauberer Auftrag), Profil-Routing und Artefakt-Tracking sind
nativ E2E bewiesen — kein Eigenbau. Auftragsbuch bleibt das Klick-Gate.

- backend services/ideen.py + routers/ideen.py: MC2-Tuer zur Queue
  (GET /api/ideen, POST /api/ideen -> kanban create --triage, Archiv)
- AuftragsbuchView: Ideen-Queue-Sektion (Eingabefeld + Status-Liste),
  dist frisch gebaut
- mcp_voice.py: idee_notieren (Lucys Sprech-Leitung, Prompt-Diaet: 1 Tool)
- chef-gutachter-feed.sh: Morgenlage bekommt kanban stats + Bewegung
- Bagatell-Pfad: bagatell-annahme.sh + mc2-bagatell.timer (04:10) —
  NUR .md-Anlagen/-AEnderungen, max 2/Nacht, gleicher Annahme-Runner
  mit Health-Gate + Auto-Revert, Chronik/Telegram-Meldung
- werkstatt-SOUL.md: Leitplanken des Kanban-Worker-Profils (propose-only,
  nie main, nie Live-Checkout) — deploy.sh zieht sie kuenftig nach

Box-live heute schon (ausserhalb Repo, mit Backups): toolsets+kanban,
platform_toolsets.telegram+kanban, SOUL.md-Ideen-Regel, Profil werkstatt
(model.default=coder), Gateway neu gestartet + E2E-Tuer-Test gruen.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-12 14:02:50 +02:00