MetaMetaMeta / Uebergabe /SESSION_LOG.md
smlflg's picture
Initial public upload from Projekte/MetaMetaMeta
3bc7cb3 verified
|
Raw History Blame Contribute Delete
3.44 kB

Session-Log

2026-09-09 → 10, Nacht

Ausgangsfrage: "ich verliere den agentischen Überblick, zu viele Agenten, zu viele Harnesses — wie lösen andere das?"

Gebaut

  • uebergabe (CLI, jetzt versioniert unter Uebergabe/uebergabe, Symlink in ~/.local/bin). Vier Pflichtfelder, weist unvollständige Karten ab, schreibt immer ohne Assignee → der Dispatcher überspringt sie nachweislich (Skipped (unassigned)), Schreiben startet nie etwas.
  • AGENTEN_ZEILE.md — die Zeile für AGENTS.md/CLAUDE.md/SOUL.md, ohne Umformulierung in jedem Harness gültig.
  • liveness-check.py: neue Prüfung check_uebergabe_backlog. Meldet ab 24 h unberührt oder ab 15 offenen Karten. 53 statt 52 geprüfte Automatisierungen.
  • kanban-vermittler/SKILL.md: Abschnitt „Intake" — Wunsch aufnehmen ohne zu handeln, Board nie erfragen, keine Options-Menüs. (Liegt in ~/.hermes/profiles/, nicht versioniert.)
  • Schreibriegel: HERMES_WRITE_SAFE_ROOT=/home/smlflg/Projekte:/home/smlflg/.hermes/kanban in allen 97 Profil-.env. Getestet: ~/Projekte und Scratch-Workspaces erlaubt; ~/.hermes/config.yaml, ~/.claude, fremde .env, ~/.ssh gesperrt.

Belegt

  • Vollständige Übergabe zwischen zwei Harnesses ohne Samuel: t_2b73bcf0, unabhängig aus dem Store geprüft (Frage → Claim → Antwort → Fortsetzung, Kriterium „Antwort wird benutzt" über Event hai_answer_used + Artefakt).
  • Operator routet und führt selbstständig aus: once nahm t_3b4f99a2, wählte verifier, Ausführung lief, alle drei Arbeitskopien blieben unverändert.
  • Der HAI-Pfad ist auf Werkzeugebene eingesperrt: board_worker.py:210 startet den Spezialisten mit enabled_toolsets=['hai_board_bounded'] — kein Datei-, kein Terminal-Tool. Deshalb schrieb der HAI-Pfad nichts, der native Pfad dagegen schon.

Offene Defekte

  1. Grant eingefroren. routes.verifier.grant.objective in operator-mandate.json enthält die Aufgabe von gestern (139 Jobs) als festen Text, checks verlangt wörtlich „139". Jede Karte an verifier bekommt daher die falsche Frage beantwortet — und besteht. operator_loop.py:107/113 reicht den Grant unverändert durch; aus der Karte fließt nur ihr Hash ein. Das ist Injection-Schutz, kein Versehen. Lösung liegt vor: handoff-mandate.json hat das generische Preset-Muster („Beantworte die Frage anhand des freigegebenen Snapshots … sonst UNANSWERABLE"). Offen ist nur, welche Leserechte ein generisches Preset pro Karte bekommt.
  2. Kein wiederkehrender Auslöser. operator_loop.py once läuft nur, wenn jemand ihn startet. Uebergabe/kanban-operator.service liegt bereit, ist nicht installiert.
  3. Ein Worker schrieb um 00:31 über den nativen Pfad ins Live-Repo. Ab jetzt durch den Schreibriegel auf ~/Projekte begrenzt — aber der Riegel gilt nur für Datei-Tools, nicht für das Terminal-Tool (file_safety.py:1-6: "NOT a security boundary").

Nicht gebaut, bewusst

Kein neues Board-System (~/.hermes/kanban.db deckte den Kontrakt bereits ab), keine globale Ausrollung, kein default_assignee, kein Eingriff in auto_decompose, kein SOUL-Invariant.

Lease

S-20260910T011907-5e00d042, capabilities: ["read"], gültig bis 2026-09-10 23:19 UTC. Danach neu minten (hai_authorize_session, nicht owner-gated) und die Id in operator-mandate.json eintragen.