Rueckfall-Luecke des Ereignis-Stroms benannt + Waechter fuer die stream-json-Argumente
Der Glied-B-Fix (defaultAgentArgs) trug den ganzen Rueckkanal und hatte keine einzige Probe: ein versehentliches Streichen der vier Zeichenketten faellt nirgends auf, weil der Lauf gruen bleibt und nur der Strom verschwindet.
- agentArgs.test.mjs: 9 Proben (Bestandteile einzeln, Pfad-/Endungs-Aufloesung, zwei Negativ-Kontrollen, Flip-Probe). In test:floors verdrahtet. - structuredOutputMissing(): ein Dispatch MIT eigenen args behaelt sie unveraendert und verliert dabei den Strom - das wird jetzt benannt statt stillschweigend ueberstimmt. - CLAUDE.md: der Strom-Vertrag samt empirischem Beleg gegen Claude-CLI 2.1.241.
Fixcoding
Rueckkanal zur Plattform — Kennung im Rumpf, Ausfaelle sichtbar, schlankes Terminal-Fenster
Nach dem ersten erfolgreichen PWA->DC-Dispatch (CEO-Test 2026-08-22) lief der Auftrag am Geraet bis Exit 0, waehrend das Sitzungs-Dokument unveraendert auf 'dispatching' stand. Drei Glieder, alle am Quelltext vermessen.
A) Der Rueckschreiber baute PUT /codeagentsessions/<id>. Diesen Weg gibt es an der Entitaet nicht: der erzeugte Router fuehrt nur put("/") und put("/many"), sein Abschluss get("*") ist nur fuer Lese-Wege. Der Aufruf traf keine Route und endete in "Not Found" - geschluckt, also von "laeuft" ununterscheidbar. Jetzt der Vertragsweg mit _id im Rumpf.
Warum die Messung in 546803a den Aufrufer nicht sah: Adresse und Verb stehen in verschiedenen Funktionen (Adresse in writeBackToServer, method:'PUT' erst in flushWriteBack, das sie als Parameter bekommt). Eine Suche nach "PUT nahe einem Pfad-Muster" kann diese Form per Bauart nicht finden.
B) Der Ereignis-Strom hat KEINEN statisch auffindbaren Defekt - die Kette ist Ende-zu-Ende verdrahtet und die Aufnahme-Route ist eingehaengt. Der Grund fuer null Ereignisse war nicht ermittelbar, weil jeder Aussteig wortlos war. Die drei stillen Aussteige melden sich jetzt einmal je Sitzung, damit der naechste Lauf die Antwort liefert statt wieder zu schweigen.
C) Das Terminal-Fenster bekam kein preload, also gab es dort kein window.electronAPI; der Renderer-Dienst stieg in listen() sofort aus, der Fokus-Kanal wurde nie gehoert und das Fenster blieb auf der Standard-Route - eine zweite volle Anwendung. Die Whitelist trug den Kanal die ganze Zeit (preload.ts:52) und der Hoerer existierte auch; nur die Bruecke fehlte. Zusaetzlich laedt das Fenster die Sitzung jetzt direkt ueber die Adresse (?terminal=1), damit die schlanke Huelle vor dem ersten Bild feststeht.
Ausserdem: ein non-2xx-Rueckschreiben protokolliert benannt und meldet nach dem zweiten Fehlversuch einmalig ans Geraet - "schreibt nicht" und "schreibt unsichtbar" waren drei Monate lang ununterscheidbar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neucoding
Modul-Zuordnung und Wissens-Kontext im Job-Kontext
Ein Coding-Job kannte sein Repositorium, aber nicht das Modul dahinter - und konnte einen Doku-Vorschlag deshalb nicht verorten. performDispatch ist der EINE geteilte Ausliefer-Kern hinter allen vier Eingaengen; der Block haengt dort, nicht in einem zweiten Weg.
- Die Kette wird GELESEN (Repository._module/._component), nicht aus dem Pfad abgeleitet - der Ableiter bleibt im Melder repo-platform-drift. - Der Wissens-Kontext kommt aus GET /{modules,components}/:id/knowledge (pm-api), kein zweiter Aufloeser, kein zweites Retrieval. - Die Luecke wird BENANNT statt weggefiltert; gemessen tragen 5.318 von 5.331 Sitzungen ein Repositorium ohne Zuordnung. - Mandanten-Grenze: _customerID-gebundener Lesezugriff, Token des ausloesenden Benutzers, bewusst ohne Zwischenspeicher. - IRepository fuehrt KEIN name-Feld (gemessen 0 von 200) - Anzeige ueber friendlyName > repoFullName > repoSlug, per Umkehrprobe festgenagelt.