cmux-Benachrichtigungen: smith sagt dem Terminal, wenn ein Lauf fertig ist

[webmatze]

Ein langer Lauf endet, und niemand bekommt es mit: smith schreibt die letzte Zeile in ein Terminal, das möglicherweise seit zehn Minuten nicht sichtbar war. In cmux gibt es dafür einen Benachrichtigungsweg — einen Unix-Socket, den das Terminal in jeden Prozess exportiert, den es startet.

Ist-Zustand

cmux legt in seiner Umgebung ab:

• CMUX_SOCKET_PATH — der Socket des Daemons (lokal: ~/.local/state/cmux/cmux.sock)
• CMUX_SURFACE_ID, CMUX_WORKSPACE_ID — der Kontext, der gerade läuft
• CMUX — gesetzt, wenn smith innerhalb von cmux läuft

Am Socket antwortet cmux auf JSON-RPC; notification.create_for_caller nimmt title/subtitle/body und löst den Aufruferkontext selbst auf. notification.create_for_surface und create_for_target erwarten stattdessen eine explizite surface_id bzw. workspace_id. Zusätzlich gibt es ältere Verben (notify, set_status, set_progress, …), die nicht dieselbe Form haben: rohes notify liest title|subtitle|body an einem Strich getrennt und versteht --title=… nicht als Flag.

Getestet gegen einen echten Socket: Verbindung ohne Passwort möglich, Fehlerfall ist durchgehend Socket::ConnectError — fehlender Pfad, reguläre Datei statt Socket, Socket ohne Server dahinter.

In smith existiert davon nichts. Es gibt keine [notify]-Sektion, keinen Ort, an dem die beiden Quellen — config.toml und die CMUX_*-Umgebung — zusammengeführt werden, und keinen Aufruf an einem Laufende.

Spezifikation

• Eine [notify]-Sektion in config.toml: enabled, socket_path, surface_id, workspace_id, timeout
• Die CMUX_*-Umgebung gewinnt gegen die Config: sie beschreibt das Terminal, das gerade offen ist, und nicht eines, das jemand beim Schreiben der Config offen hatte
• enabled = true allein reicht nicht — ohne Socket-Pfad gibt es nichts zu senden
• Ein falsey-Wert ("", 0, false, no, off) gilt als abwesend, damit die nächsttiefere Ebene sprechen kann; CMUX_SOCKET_PATH vor CMUX_SOCKET vor CMUX, und CMUX wird nur als Pfad gelesen, wenn es wie einer aussieht
• Smith::Notify kennt keine Umgebung, keinen Socket und kein Protokoll, und der Rest von smith kennt keinen dieser drei Namen außer Notify
• Ein Lauf, der nicht innerhalb von cmux läuft, merkt keinen Unterschied: dieselbe Zeile Code, nur ohne Wirkung
• Eine fehlgeschlagene Benachrichtigung beendet keinen Lauf. Sie wird verschluckt, und der Lauf endet so, wie er ohne sie geendet hätte
• Ein Body, der leer oder nur Whitespace ist, wird nicht gesendet — er rendert als Lücke statt als nichts

Offene Punkte

Die erste Fassung baut die Auflösung und den Orchestrator und endet an der Grenze zum Socket: CmuxClient.client liefert in jedem Fall den Null-Client, auch bei vollständiger Config. Absicht, damit nichts behauptet, eine Benachrichtigung sei zugestellt worden, solange kein Draht da ist. Danach zu klären:

• Protokoll: notification.create_for_caller (löst den Kontext selbst auf) gegen die älteren Verben
• Framing: ein JSON-Objekt pro Zeile, Antwort lesen oder fire-and-forget, Deadline
• Aufrufstellen: welches Ereignis eine Benachrichtigung wert ist — TurnCompleted, BudgetExceeded, ContextExhausted, ein Tool, das auf Freigabe wartet
• ob surface_id/workspace_id mitgesendet werden sollen, wenn der Caller-Kontext ohnehin serverseitig aufgelöst wird

[webmatze]

Triagiert nach dem Merge von #121: ready-for-human.

Die acht Punkte der Spezifikation sind erfüllt, die Auflösung und der Orchestrator stehen. Was offen ist, sind die vier Punkte unter „Offene Punkte" — und keiner davon ist eine Implementierungsfrage, die sich aus dem Code beantworten ließe:

• Protokoll und Framing wären am echten Socket zu messen, nicht abzuleiten. Antwort lesen oder fire-and-forget ist eine Beobachtung, kein Entwurf.
• Welches Ereignis eine Benachrichtigung wert ist, ist eine Produktentscheidung. TurnCompleted hat cmux notifications: resolve the setup and give TurnCompleted a consumer #121 verdrahtet; ob BudgetExceeded, ContextExhausted oder ein auf Freigabe wartendes Tool dazugehören, entscheidet, wie oft ein Terminal blinkt — und das ist die Eigenschaft, an der eine Benachrichtigung entweder nützlich oder lästig wird.
• Der Nachweis der Zustellung braucht ein laufendes cmux. Ein Agent kann den Draht schreiben, aber nicht belegen, dass am anderen Ende etwas ankommt — und genau das war der Grund, cmux notifications: resolve the setup and give TurnCompleted a consumer #121 an dieser Naht anzuhalten.

Sobald Verb, Framing und die Liste der Aufrufstellen entschieden sind, ist der Rest wieder AFK-fähig.