Uebergabe

Neuester Stand: Vorhandenes operator-Profil vermittelt jetzt lokal zwischen Kanban und freigegebenen Fachbearbeitern. Live geprueft mit wggesucht und verifier. Ergebnis und unabhaengige Pruefung.

Ein Agent haengt fest. Ein anderer uebernimmt und antwortet. Der erste macht weiter. Samuel traegt dabei keine Nachricht und koordiniert nichts.

Aktueller Status: Lokaler Bearbeiter implementiert; Hello World ausgefuehrt und von Samuel gehoert. Eine echte Codex-Hermes-Uebergabe mit benutzter Antwort ist nachgewiesen. Kein Go fuer Dauerbetrieb oder globale Ausrollung: die unabhaengige Hermes-Pruefung hat offene Laufzeit-/Freigabeluecken benannt.

Aktueller Befund und Belege: IMPLEMENTATION_REPORT.md. Die folgenden Abschnitte bewahren den urspruenglichen Kontrakt; sie sind keine Behauptung, dass alle Punkte bereits implementiert und live geprueft sind. Angelegt 2026-09-09.

Kontrakt (von Samuel gesetzt)

1 · Gezielte Uebergabe. Pflichtfelder, sonst wird der Eintrag abgewiesen: projekt · frage · versucht · benoetigt versucht ist das Feld, das entlastet — ohne es wiederholt B die Sackgasse von A.

2 · Sichtbare Verantwortung. Jeder Eintrag hat eine ID, genau einen Inhaber ab dem Claim, und die Antwort referenziert die ID. Jederzeit abfragbar: wer haelt gerade was.

3 · Begrenzte Eskalation. Harte Zaehler statt Hoeflichkeit:

Rueckfragen: maximal eine, danach automatisch blocked
Frage unbeantwortet: 30 min -> blocked
Geclaimt ohne Antwort: 10 min -> zurueck auf open (protokolliert); zweiter Verfall -> blocked

4 · Gefilterte Aufmerksamkeit. Nur echte Zustaendigkeit erreicht Samuel. Das vollstaendige Log bleibt nachlesbar, wird aber nicht zugestellt.

5 · Abgeleitete Prioritaet. Nicht selbstvergeben (verrottet), sondern aus dem Zustand: blocking = ein Agent wartet gerade darauf · background = niemand wartet.

Zustandsmaschine

open ──► claimed ──► resolved      Normalfall
open ──────────────► blocked       niemand kann helfen / TTL
claimed ───────────► open          Claim verfallen (Totmannschalter)
  *   ────────────► escalated      nur bei echter Samuel-Zustaendigkeit

Terminal: resolved, blocked, escalated. Nichts bleibt im Umlauf.

blocked ist NICHT Samuels Problem. Sichtbar geparkt, nachlesbar, nicht zugestellt. Landet "niemand kann helfen" automatisch bei ihm, ist Eigenschaft 4 sofort kaputt.

Eskalationsliste — nur diese fuenf erreichen Samuel:

Geld · Aussenwirkung (senden, posten, veroeffentlichen) · Irreversibles · Zugangsdaten · Prioritaet und Scope

Alles andere loesen die Agents oder es wird blocked.

Abnahme

Eine echte Uebergabe zwischen zwei bestehenden Harnesses. Zwei Prozesse, die voneinander nichts wissen; keiner ruft den anderen; beide beruehren nur den Store.

A bekommt eine Aufgabe in zwei Haelften: Haelfte 1 schafft A allein, Haelfte 2 braucht eine Auskunft, an die A nicht rankommt.

Eintrag 1  beantwortbar    open -> claimed -> resolved -> A liefert Haelfte 2
Eintrag 2  unbeantwortbar  open -> claimed -> blocked   (nach 1 Rueckfrage, kein Ping-Pong)

Bestanden nur wenn alle sieben stimmen:

As Frage ist echt — A kann sie nachweislich nicht selbst beantworten
B hat den Eintrag durch Pollen gefunden, nicht durch einen Aufruf von A
Die Antwort steht im Store, nicht in einem Seitenkanal
Haelfte 2 ist fertig und benutzt die Antwort — nicht nur "Antwort erhalten"
Eintrag 2 endet auf blocked und erreicht Samuel nicht
Samuels Nachrichten im Vorgang: 0
Eingriffe der Hauptsession nach dem Start: 0

Punkt 4 ist der, an dem so ein Test schummelt. Nachrichten schieben ist leicht; dass die Antwort die Arbeit weiterbringt, ist der Beweis.

Im Nachweis ist B lesend. Beantworten, nicht handeln. Alles mit Schreibzugriff, Aussenwirkung oder Samuels Entscheidung geht auf escalated und bleibt liegen.

Keine globale Ausrollung vor diesem Nachweis. Menschliche Freigaben bleiben erhalten.

Offene Entscheidung: uebernehmen statt bauen

Entscheidungsstand: Hermes Kanban wurde als vorhandener Store uebernommen. Der folgende Recherchetext beschreibt den Ausgangspunkt, nicht eine weiterhin offene Produktauswahl.

Der Befund aus der Recherche vom 2026-09-09 (siehe ../2026-09-09_FREMDBEFUND_*.md): was ueberlebt, hat viele Nutzer; was stirbt, hat genau einen — seinen Erbauer. Gas Town (Orchestrator, ein Nutzer) kollabierte. Beads (duenner git-nativer Store, tausende Nutzer) haelt.

Daraus folgt: erst pruefen, ob es das fertig gibt. Laufende Pruefung gegen den Kontrakt oben — Beads, backlog.md, HumanLayer, A2A, GitHub Issues als Agent-Store, MCP-Task-Server. Ausserdem im eigenen Bestand: ob hai_intake / hai_park / hai_status oder der intake-router bereits einen tauglichen Store haben. Dann waere das hier eine Anschluss- und keine Baumassnahme.

Eigenbau nur, wenn nichts den Kontrakt erfuellt — und dann so duenn wie moeglich.