- werkstatt-SOUL Regel 3: Klonen IMMER ueber http://192.168.178.153:3000
(DDNS-Domain nachts wegen Zwangstrennung tot -> Worker hielt Gitea am
24.07. faelschlich fuer kaputt und blockte). Nie SSH-Remotes, nie nach
Passwoertern fragen.
- deploy/gitea-pr (neu): PR per Gitea-REST-API mit Token aus
~/.git-credentials (Vorfall 23.07.: Worker bat um Web-Passwort).
- ampel-waechter: /repos/search statt /user/repos - Token hat nur
write:repository, /user/repos gab 403 und der stille exit 0 versteckte
das seit Inbetriebnahme (Merkliste blieb leer, kein Alarm ging je raus).
API jetzt intern, Telegram-Links bleiben auf der Domain.
- tabu-pfade-guard: Klon-Empfehlung in der Blockmeldung auf interne URL.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Nacht-Worker t_7a05992a ersetzte 03:59 den Live-Checkout mit cwd=$HOME und
RELATIVEN Pfaden (rm -rf mission-control-v2 && git clone ...) — der Guard
prueft beim terminal-Tool nur den Kommandotext auf home-verankerte Formen
und liess das durch (.venv weg -> Gateway 203/EXEC-Crash-Loop).
Drei Stopfen:
(1) cwd IN einem Tabu-Pfad -> jede Schreib-Operation geblockt (Lesen frei).
(2) git clone/init mit Ziel direkt in $HOME geblockt (Worker klonen im
Task-Workspace); explizites Ziel ausserhalb $HOME bleibt erlaubt.
(3) cwd == Vorfahr eines Tabu-Pfads -> relative Nennung des Tabu-Ziels
zaehlt als Treffer; Lookarounds lassen den Workspace-Klon-Pfad
(.hermes/kanban/workspaces/<id>/mission-control-v2) weiter durch.
Nebenbefund zu: clone fehlte in der git-Schreibliste (a) — auch
git clone URL ~/mission-control-v2 war vorher ungeblockt.
Lokal bewiesen: 35/35 Payload-Faelle (Vorfalls-Kommando geblockt,
Workspace-Arbeit/Lesen frei, Alt-Verhalten regressionsfrei).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Drei Naechte in Folge bauten Worker git-init-Branches ohne gemeinsamen
Ursprung mit main (cleanse-skill-index 12.07., skill-kanten-generator
13.07., blogwatcher-logging ~14.07.) - bei der Annahme technisch tot,
Nacht-Arbeit verloren. SOUL-Prosa allein driftet (Meta-Lehre Fallstrick-
Audit) -> jetzt mechanisch: tabu-pfade-guard blockt 'git init' im
Kanban-Workspace hart; pre-verify-gates prueft VOR dem Fertigmelden
merge-base gegen origin/main (Orphan-Gate ROT).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
R1: Steckbrief-Hook erinnert Worker an kanban_complete/kanban_block-Pflicht
(Nacht-Karte 14.07. blockierte trotz fertiger Arbeit am fehlenden Aufruf).
R2: tabu-pfade-guard sperrt ~/.config/systemd/user fuer Worker — Unit-/
Override-Dateien nur noch ueber angenommene Karte.
R4: Orchestrator-/Wartungs-Worktrees von /tmp nach ~/.hermes/worktrees
(ueberleben Reboot, keine kaputten Registrierungen).
Neu: self-smoke Check 4 'Repo-Waechter' — Box-main mit Commits, die origin
fehlen, loest Alarm aus (so ging die angenommene Karte
wartung/lucy-annahme-fixes am 12.07. still verloren; am 15.07. als
rescue/-Branch gerettet und wieder gemergt).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Zwei zusammenhaengende Bugs, beim echten Worker-Test entdeckt:
1) HOOKS FEUERTEN FUER WORKER NIE. Kanban-Worker laufen unter IHREM Profil
(HERMES_HOME=~/.hermes/profiles/<name>) und lesen dessen config.yaml, NICHT
die Top-Level ~/.hermes/config.yaml. Die neuen Hooks waren nur oben
registriert -> fuer Worker inaktiv. FIX: ensure-profile-hooks.py registriert
pre_llm_call + pre_tool_call in jeder Worker-Profil-config (idempotent,
validiert, Backup); deploy.sh ruft es je Profil auf -> reproduzierbar.
2) FALSCHER SCOPE. Beide Hooks scopeten auf task_id == t_<hex>. Aber Worker
tragen als effective_task_id den SESSION-Zeitstempel (z.B.
20260713_224206_267304), NICHT die Kanban-t_-ID -> der Check schlug immer
fehl -> box-steckbrief injizierte nie, tabu-guard liess alles durch.
FIX:
- tabu-pfade-guard.py: Schutz jetzt UNBEDINGT (kein Task-Scope) - kein
legitimer Hermes-Agent-Flow schreibt je in Live-Checkout/Hermes-Quelle
(Werkstatt arbeitet im Workspace-Klon, Wartung ist Shell nicht Agent-Tool).
- box-steckbrief-inject.sh: Scope jetzt cwd unter ~/.hermes/kanban/workspaces/
(zuverlaessiger Worker-Signal; Lucy/Voice/CLI laufen nie dort).
Verifiziert: echter betrieb-Worker versuchte in den Live-Checkout zu schreiben
-> GEBLOCKT, Datei nicht erstellt, TABU-Meldung im Log. 26 Guard-Unit-Faelle gruen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fallstrick #2: Worker koennen in die falsche Ebene wandern - Patches im
Live-Checkout ~/mission-control-v2 ablegen oder die Hermes-Quelle
~/.hermes/hermes-agent anfassen. Hermes' native is_write_denied deckt diese
Pfade NICHT ab (nur Credentials/System, live geprueft).
deploy/agent-hooks/tabu-pfade-guard.py (neu): pre_tool_call-Hook, blockt
Schreib-Operationen (write_file/patch + terminal git-write/sed-i/redirect/rm)
auf den home-verankerten Live-Checkout und die Hermes-Quelle - NUR fuer echte
Kanban-Worker (task_id t_<hex>); Lucy/CLI (UUID) = No-op (~15 ms). Der
Workspace-KLON (<workspace>/mission-control-v2) bleibt beschreibbar (nur der
home-verankerte Pfad ist tabu) -> legitime Worker-Arbeit ungestoert. Lesen
erlaubt. 25 Faelle gruen (Block + Allow, inkl. git log 2>/dev/null, Redirect
nach /tmp, Workspace-Commit). deploy.sh synct den Hook (cmp-Guard).
Registrierung in ~/.hermes/config.yaml (pre_tool_call) einmalig von Hand.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hitonabi