Code-Agent-Aktion aus der Registry ziehen (Pin auf interfaces 2026.452.0)
Der Pin-Bump zieht den neuen entityActions-Eintrag `dispatch-code-agent` nach — ohne ihn rendert kein Knopf, egal was publiziert ist (actionsForEntity liest die INSTALLIERTE Registry). Wirksam wird er an den zwei Aufgaben-Tabellen (registerStates.ts:483/589) und in der Rechte-Ableitung.
An der Detail-Ansicht wird der generische Eintrag BEWUSST herausgefiltert: dort stehen seit CEO 2026-07-08 zwei handgebaute Knoepfe auf derselben Route, die die Laufzeit-Wahl (bodyData dc/k8s) und einen Bestaetigungs-Dialog tragen — entityActions kann beides nicht ausdruecken (actionsForEntity setzt bodyData fest). Ohne den Filter stuenden dort drei Knoepfe auf einer Route, davon einer namenlos.
Lock-Beleg vor dem Push: interfaces/models/core je genau EINE Aufloesung, alle gleich dem publizierten Stand. 726/726 Proben gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fixtasks
waitingOnOthers auf den Kanon-Wert blocked abbilden
Outlooks `waitingOnOthers` wurde auf `waiting` abgebildet — kein Wert des Kanons `PmStatus`. CEO-Entscheid 2026-08-22 (via /interview), Weg (a): `blocked`.
Gemessen mit Positiv-Kontrolle: der Normalisierungs-Haken `TASK_LIKE_STATUS_MAP` fuehrt sieben Eintraege, KEINER heisst `waiting` — die Annahme des Auftrags, der Haken fange den Wert ohnehin ab, ist falsch. Diese Zeile ist der einzige Riegel.
Waechter-Test nagelt JEDEN ausgegebenen Status gegen den Kanon fest (nicht nur den einen Fix); Flip-Probe: mit dem alten Wert 93/94 rot, mit dem Fix 94/94.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neutasks
type-Normalisierung (Stufe 2) + zwei nachgetragene status/priority-Luecken
CEO-Entscheid 2026-08-21 (E10). Neue Karte TASK_TYPE_MAP faengt die zwei gemessenen Schreibweisen-Dubletten am SCHREIBWEG ab: 'Code-Agent' -> 'CodeAgent', 'Task' -> 'Aufgabe'. Registriert an `Tasks` neben status/priority.
WARUM DER HAKEN UND NICHT DIE UNION: gemessen 2026-08-22 schreiben die realen Erzeuger ueber `any`/`string`-typisierte Objektliterale (`tooling/cli` dispatcher.ts:365 schreibt bis heute 'Code-Agent'; `platform/middleware-worker` handleBitBucket.ts:66) — eine geschlossene TypeScript-Union faengt davon NICHTS, dieser Haken alles. Er ist damit der tragende Riegel des Auftrags, nicht der Vertrag.
NICHT in der Karte: 'CodeAgent-Todo'. Am Bestand gemessen ein EINZELPUNKT INNERHALB einer Sitzung (origin `code-agent-hook:<id>`), nicht die Sitzungs-Aufgabe (origin `code-agent-hook`) — der lebende Erzeuger sucht ihn idempotent ueber genau diesen Wert.
ZWEI GEMESSENE LUECKEN NACHGETRAGEN (dieselbe Schreibstelle, middleware-worker, ausgerollt): `Erledigt` -> done und `Hoch` -> high waren der Karte UNBEKANNT und liefen damit unbehelligt in den Bestand. Wirkt zugleich fuer Projects/FeatureRequests, die dieselbe Karte teilen. Der Erzeuger liegt ausserhalb der Anspruchspfade — die Karte ist der Hebel ohne Fremd-Edit.
`waiting` (worker-outlook) bleibt BEWUSST unzugeordnet: es gibt kein offensichtliches Kanon-Ziel, und raten waere schlimmer als offenlassen. Liegt als Rest-Schnitt-Brief.
19 neue Proben, davon vier gegen das ECHTE Tasks-Schema (die Attrappen-Tests belegen die Mechanik, nicht die Verdrahtung). Flip-Probe: Haken-Zeile entfernt -> genau der eine Verdrahtungs-Test faellt, alles andere bleibt gruen. Volle Reihe 707/707.
interfaces-Caret auf ^2026.451.0 (Fundament-interne Kette bleibt Caret).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UVmnsay4L5Rw8MvnFMVqmj
Fixtasks
die vier Zuteilungs-Rechte ausdruecklich registrieren
Ohne additionalRights sieht registerModuleRights sie nie -> sie stehen in keiner Rolle und keinem Paket -> checkRights weist JEDEN Aufruf der vier Lease-Wege mit 403 ab. Die Wege waeren tot geboren gewesen.
Die Praemisse des Auftrags ist widerlegt und nachgemessen: CodingJobs.entityActions fuehrt claim/heartbeat/complete/cancel/approve/ reject — das dort zitierte 'hat keine Registry-Zeile' trifft nicht zu. Die zweite genannte Praezedenz (dispatchCodeAgent) traegt nicht, weil sie gar kein neues Recht erfindet.
additionalRights ist genau dafuer da und braucht keinen Fundament-Griff. Drei Proben pinnen es fest, inkl. Textprobe auf app.ts.
Neutasks
Zuteilung im Pull-Modell — claim/lease-heartbeat/lease-complete/lease-cancel
Portiert aus domains/coding/api/.../codingjobs (CEO-Entscheid 2026-08-21, coding-pm-abschluss-zuteilung-und-spiegel: die Lease wandert an ITask, CodingJobs wird eingestellt). Vier Wege plus drei Bibliotheken.
Die Abhol-Bereitschaft ist entschieden: ein unabhaengiges Merkmal aus BESTEHENDEN Feldern (runtimePolicy als Designation + offener PmStatus + keine lebende Lease), kein neuer Status-Wert und kein Workflow-Uebergang. Ohne die Designation waeren 3.547 offene Aufgaben holbar (Prod gemessen).
Drei Stellen, an denen eine 1:1-Portierung STILL falsch gewesen waere: - priority ist ein WORT, keine Zahl: sort{priority:-1} liefert normal vor critical. Ersetzt durch Stufen-Durchgaenge; Flip-Probe belegt die Umkehr. - ITask fuehrt weder availableAt noch attemptCount noch result: strict haette diese Schreibvorgaenge verworfen. Ersetzt bzw. entfallen. - complete existiert bereits im PM-Sinn -> lease-complete.
18 Proben gegen echten mongod, davon 20-fache Nebenlaeufigkeit.
