Commit Graph

3 Commits

Author SHA1 Message Date
Hitonabi faf25bf76c Faden 8+5-Fix: Worker-Scope korrigieren + Profil-Hooks reproduzierbar
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>
2026-07-13 22:51:47 +02:00
Hitonabi 913256e241 gitattributes: agent-hooks/*.py auf LF pinnen (Shebang-Falle)
Ohne Regel wuerde autocrlf tabu-pfade-guard.py bei Checkout zu CRLF machen ->
`#!/usr/bin/env python3\r` bricht auf der Box. Analog zur *.sh-LF-Regel.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 22:27:27 +02:00
Hitonabi 7bc20a6302 Fix: installierte Engine-Build-Nummer lesen (Format 'version: NNNN') + .gitattributes (LF)
- _installed_engine_build matchte nur 'build: <hash> (N)' / 'bNNNN', aber der
  aktuelle llama-server meldet 'version: 9821 (hash)'. Dadurch war installed_build
  immer None → Engine-Badge fiel auf ungenauen mtime-Vergleich zurueck. Jetzt
  praeziser Build-Nummer-Vergleich (latest > installed).
- .gitattributes erzwingt LF fuer *.sh/*.service/*.timer: die Box hatte
  core.autocrlf aktiv und checkte deploy.sh mit CRLF aus -> 'set -euo pipefail'
  wurde zu 'pipefail\r' (invalid option name), Deploy brach ab.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-28 10:58:59 +02:00