Aufgaben-Aktion dispatch-code-agent in modelsAndRights deklarieren
Die Route POST /tasks/:id/actions/dispatch-code-agent existiert handgebaut seit 2026.28.0, war aber ohne Registry-Eintrag fuer Nutzer unerreichbar — actionsForEntity baut ohne Deklaration keinen Knopf. Rein additiv: modelsAndRights bleibt bei 843 Eintraegen, null neue plural-Zeilen.
Bewusst OHNE emits (die custom-Route gewinnt per Mount-Reihenfolge, ein deklariertes Ereignis haette keinen Erzeuger), ohne defaultOnScan (ein Barcode-Scan darf nie ungefragt eine Code-Agent-Sitzung starten) und ohne right (die Ableitung pm.tasks.actions.dispatch-code-agent traegt).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CEO-Entscheid 2026-08-21 (decisions.log 20:22:43Z, LOCKED, E10). Der Kanon ist aus dem GEMESSENEN Bestand abgeleitet (42.521 Aufgaben, nach dem Dublettenlauf `ayauto migrate task-status-type-kanon`): elf Werte, `ITask.type` traegt jetzt `PmTaskTypeValue` statt `string`.
BEWUSST OFFEN gelassen (`| (string & {})`), wie `status`: das Schliess-Gate des Auftrags ist NICHT erfuellt. Gemessen schreiben die realen Erzeuger ueber `any`/`string`-typisierte Objektliterale (`tooling/cli` dispatcher.ts:365, `platform/middleware-worker` handleBitBucket.ts:66) — eine geschlossene Union faengt davon NICHTS. Der tragende Riegel ist der Normalisierungs-Haken in `platform/models`, nicht dieser Typ.
BEWUSST NICHT sprach-normalisiert: `type:'Bug'` traegt die plattformweite Errors-as-Tasks-Konvention (24.468 Dokumente). Eine Umbenennung auf `bug` waere ein Flotten-Eingriff mit Leser-Implikationen, kein Vertrags-Detail — Produkt-Entscheid, CEO.
`CodeAgent` und `CodeAgent-Todo` sind ZWEI Sachverhalte, keine Dublette (Sitzungs-Aufgabe gegen Einzelpunkt innerhalb einer Sitzung) — beide im Kanon, kein Merge.
Flip-Probe beidseitig gefahren: offen -> erfundener Wert geht durch; testweise geschlossen -> TS2322 auf `type` UND `status`, waehrend die Kanon-Positiv-Kontrolle still bleibt. Der Vertrag haengt also wirklich am Feld.
Nicht-brechend: PmTaskTypeValue ist von jedem string zuweisbar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UVmnsay4L5Rw8MvnFMVqmj
Fixpm
lesbare Beschriftungen — primary war als Text auf dunklem Grund blind
Sicht-Kritik am LIVE ausgebrachten Stand (pwa.ayoune.app, dunkles Thema), nicht am Entwurf: zwei Stellen faerbten Text in `--mat-sys-primary` und waren damit die am schlechtesten lesbaren der ganzen Seite.
- Der AKTIVE Schritt der Schiene traf es am haertesten — ausgerechnet seine Beschriftung war unlesbar, waehrend die Ziffer daneben (primary als FLAECHE mit `on-primary` darauf) einwandfrei stand. Die Betonung traegt jetzt Rahmen und Ziffer, der Text hat volle Textfarbe. - „Alle"/„Keines" sind Neben-Griffe: Sekundaerfarbe plus Unterstreichung, beim Ueberfahren volle Textfarbe.
Lehre: in einem dunklen M3-Thema ist `primary` als Flaeche gedacht, nicht als Textfarbe auf dunklem Grund.
Verify: `npm run build:stage` Exit 0 inkl. Schrift-Check.
Fixpm
Assistent nennt die richtige Grenze und sagt, WAS er liest
Zwei Befunde aus dem Live-Durchlauf gegen echte Repositorien (pwa.ayoune.app, Mandant tolinax) — beide gefunden, weil die Fläche wirklich gefahren wurde:
1. Der Abschneide-Hinweis schob JEDE Grenze auf die Tiefe und meldete am Wurzel-Repositorium woertlich "0 Eintraege unterhalb von Ebene 3" — der Leser war dort an der SEITEN-Grenze. Ein Hinweis, der die falsche Ursache nennt, ist schlimmer als keiner: er schickt den Leser die Tiefe erhoehen, wo die Seitenzahl das Problem ist. Jetzt getrennt benannt. 2. Filtert die Suche die gewaehlte Karte aus der Sicht, blieb "Struktur lesen" scharf, ohne dass irgendwo stand, WAS gelesen wird. Die Fussleiste nennt das gewaehlte Repositorium jetzt beim Namen.
Assistent "Bilde deine Software ab" — Oberflaeche (W5, Weg b)
Statischer PWA-Baustein unter `pm/onboarding`, CEO-Entscheid 2026-08-22 Weg (b). Der Motor (scan-repository / apply-proposal, pm-api `a6b805b`) bleibt unangetastet.
Drei Schritte, und die Reihenfolge traegt eine Aussage: verbinden -> pruefen -> uebernehmen. Erst der dritte schreibt.
- Der BELEG steht sichtbar an jeder Zeile (die Manifest-Datei, die den Vorschlag traegt), nicht in einem Tooltip. Was nicht eindeutig war, steht als OFFEN gleichberechtigt daneben statt in einer Fussnote — ein Vorschlag, der seine Luecken verschweigt, sieht vollstaendig aus und ist es nicht. - Zuordnungen sind korrigierbar; ein abgewaehltes Modul zieht seine Zuordnungen mit, sonst zeigte die Oberflaeche eine Zuordnung, die der Server als OFFEN behandelt. Eine Komponente ohne geltendes Modul reist OHNE `moduleKey`. - Rechte prueft der Baustein SELBST (`pm.modules` / `pm.modules.edit`), weil kein SDUI-Zustand die Sichtbarkeit uebernimmt — ueber den treuen Spiegel `holdsRight`, also dieselbe Glob-Semantik wie `checkRights` im Kern. - Benannte Fehler statt leerem Vorschlag: ein fehlender Vault-Zugang wird als solcher gezeigt, nicht als leere Struktur.
Verify: `npm run build:stage` (das Gate, das master faehrt) Exit 0 inkl. Schrift-Check BESTANDEN; 16 Proben gruen; Flip-Probe am Rechte-Riegel faellt mit genau 2 roten Reihen und ist zurueckgebaut.
Neupm
Abschnitt "Website" an den Modul- und Feature-Bildschirmen
Die Kaskade `modul-feature-vertrag-website-felder-kanon` hat den Freigabe-Schalter geliefert — es gab aber keinen Ort, an dem ihn jemand umlegt. Diese Datei ist feld-fuer-feld hand-kuriert; ein neues Vertragsfeld erscheint hier NICHT von selbst. Der Schmerzpunkt der Quell-Kaskade ("ein Redakteur kann einen Eintrag nicht zurueckhalten, ohne seinen Text zu loeschen") war damit nicht behoben, sondern eine Schicht nach oben gewandert.
Der eigentliche Auftrag sind die HINWEISE, nicht die Felder: ein leeres Kaestchen heisst hier NICHT "aus", sondern "keine Aussage — es gilt das Ersatz-Tor". Jeder Hinweis nennt deshalb die Bedeutung bei LEER, und jeder ist am echten Tor belegt (isPubliclyVisible, consumer-app), nicht am Vertragstext: - showOnWebsite false=versteckt / true=sichtbar (gewinnt in BEIDE Richtungen) - published:false haelt zurueck AUCH bei showOnWebsite:true - leer MIT Beschreibung sichtbar, leer OHNE versteckt - _websites leer = auf ALLEN Auftritten, nicht "auf keinem" - slug leer = Rueckfall auf key (kein 404)
Der echte Bestandsfall traegt `slug:""` und `showOnWebsite:null` — also GESETZTE leere Werte, nicht "absent". Am Tor geprueft: verhaelt sich identisch zu absent, die Flaeche darf sie also schreiben.
Bewusst `multiSelect` statt des im Auftrag genannten `remoteSelect`+multiple: in dieser Datei ist `multiSelect` die belegte Bauform (1x, `_components`), `remoteSelect` kommt 0x mit `multiple` vor.
`sortOrder` nur beim Modul — das Feature fuehrt es bereits unter "Stammdaten"; ein zweites Feld auf denselben Pfad waeren zwei Bedienorte fuer einen Wert.
Vorab gemessen: das installierte models kennt alle fuenf Felder (2026.452.1) — der lokale node_modules hing auf 451.0, wo KEINES existiert; der Lock war korrekt, `npm ci` hat es geradegezogen. Ohne diese Pruefung haette `strict` jede Eingabe still verworfen.
Proben 650/650 (38 Reihen), inkl. der feldweisen Spec-Struktur-Probe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PmMj9oQCU9nxusjcbD8Dp8
