Einstieg OHNE Kennung — das Platzhalter-Segment traf keinen Zustand
Live gemessen (2026-08-23, Mandant tolinax): der Einstieg zeigte auf `/hr/applicationprocesses/edit/vorgabe`. Die Adresse wechselte, die LISTE blieb stehen, und es erschien „State hr.applicationprocesses.edit.vorgabe nicht registriert".
Ursache: `PageService.urlToView` nimmt bei VIER Segmenten das letzte nur weg, wenn es eine ObjectId ist (`page.service.ts:1999`). Ein Platzhalter bleibt also stehen und wird Teil des gesuchten Zustands-Namens. Die DREI-Segment-Form (`/hr/applicationprocesses/edit`) loest unveraendert auf; die PWA-Route traegt dafuer wieder ein leeres Kind — das heisst hier NICHT „anlegen" (der Prozess wird uebernommen, `hideCreate` bleibt), sondern „welchen Prozess?".
Reihe gruen: 41 Proben der zwei betroffenen Reihen.
Fixhr
die Prozess-Flaeche war eine Sackgasse — Einstieg in den Editor
Am laufenden Programm gemessen (Mandant tolinax): die Liste zeigt „0 von 0", weil der Aggregations-Weg die Plattform-Vorgabe per Bauart ausblendet (`workflows` steht in ACKNOWLEDGED_NON_CATALOGS). Es gibt also keine Zeile zum Anklicken — und „Uebernehmen" liegt IM Editor, den man ohne Zeile nicht erreicht. Ein Mandant ohne eigene Kopie kam ueber die Oberflaeche NIE zu einer; der Leer-Zustand riet ihm woertlich zu einem POST-Aufruf.
- Listen-Aktion `link` auf `/hr/applicationprocesses/edit/vorgabe`. Der Platzhalter statt einer Kennung ist Absicht: die Flaeche KENNT die Kennung der Vorgabe nicht — derselbe Grund, aus dem `actions/adopt` auf der Sammel-Ebene liegt. Der Editor loest ihn ueber `GET /applicationprocesses` auf und ersetzt die Adresse durch die echte Kennung. - Zwei Proben inkl. Gegenprobe („der Einstieg traegt keine Kennung").
Die Konfigurations-Flaeche aus W2 war nicht bedienbar: der Formular-Renderer kennt keinen Objektlisten-Typ. Statt eines neuen Feldtyps im Fundament (Weg a) haengt jetzt ein zweck-gebauter Editor als Komponenten-Override an der Standard-Route (Weg b) — CEO-Regel 2026-08-22 plus zwei gemessene Gruende: transitions[].from/to verweisen auf die Geschwister-Liste statuses[], und kein Feldtyp des Vertrags bindet eine Auswahl an eine Liste im selben Modell.
- registerStates: hr.applicationprocesses.edit (pageType component, endpoint applicationprocesses, keine kuratierten Aktionen — sie reiten im zentralen Aktions-Slot), Zeilenklick der Liste kuratiert statt abgeleitet - Proben: 9 neue Flip-/Gegenproben, Katalog-Waechter 25 -> 26 - Reihe gruen: 52 Suiten / 1093 Proben
Fixhr
die drei Bewerbungs-Flaechen aus W1 fehlten im Modul-Raster
Gemessen am AUSGEBRACHTEN Modul-Zustand: 17 Verweise, keiner auf `hr.applications`, `hr.applications-board` oder `hr.applicants`. Die Flaechen waren gebaut, geseedet und in der PWA gerendert — aber aus der Oberflaeche NICHT auffindbar: diese Liste ist die einzige Auswahl des Rasters "ALLE FUNKTIONEN" (resolveNavigationLinks serverseitig, base-page.component.ts im Klienten). Wer eine Flaeche registriert und sie hier vergisst, baut einen Tiefverweis, den niemand findet — dieselbe Klasse wie pm.onboarding (CEO-Entscheid 2026-08-22).
Ergaenzt in fachlicher Reihenfolge: Bewerbungen, Bewerbungs-Pipeline, Bewerber (vor dem W2-Verweis "Bewerbungsprozesse").
Neue Probe haelt alle VIER fest, mit Positiv-Kontrolle gegen eine leere Liste. Flip-Probe: einen Verweis entfernt faerbt genau 1 rot. Proben 987/987.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neuhr
Fundament-Pin auf 448.1/452.1 + voller Codegen-Modul-Lauf
Pin-Bump auf den publizierten Stand (interfaces 2026.447.1->2026.448.1, models 2026.451.0->2026.452.1, core 2026.315.1 unveraendert) per fix-foundation-pinning --pin-exact --de-latest, danach npm ci — ohne das liest der Erzeuger die ALTE installierte Fassung und ueberspringt neue Entitaeten still als [skew] (Kaskade-50-Falle). Lock-Beleg vor dem Commit: genau DREI Aufloesungen der Fundament-Pakete, keine verschachtelte Zweitkopie.
Kaskade-48-Pruefpunkt gefahren: use('/:id/actions') 5 -> 7. NICHTS verloren; neu verdrahtet sind employees und payslips, deren Aktionen deklariert, aber nie an den Router gehaengt waren.
Der uebrige Diff ist die Suchfelder-Vorlage (74b04f2150): die Freitextsuche liest jetzt searchableFields statt hartkodiert name/title/subject. Fuer die zwei neuen Entitaeten ist das keine Kosmetik, sondern Bedingung — ?q= haette sonst NICHT in firstName/lastName/email/headline gesucht. Testreihe 785/785 gruen (42 Suiten); der in marketing gemessene Rot-Effekt derselben Vorlage tritt in hr nicht auf.
MESSUNG statt Annahme zu den neu erzeugten Aktions-Ruempfen: von den fuenf Employees-Aktionen sind VIER durch handgeschriebene custom-Router gedeckt (generate-/stylize-portrait, grant-/revoke-portal-access) und damit tot, weil custom vor default mountet; Payslips print ebenso. UNGEDECKT ist allein import-lexware-dls — sein Rumpf ist fail-closed (ALLOWED_FIELDS leer, schreibt nichts), aber er antwortet 200 und feuert das Ereignis, ist also ein STILLER Nicht-Vollzug, bis der echte Importer gebaut ist (eigener Brief lexware-dls-importer-hr-upload-diff-upsert).
Nur die 19 inhaltlich geaenderten Dateien sind aufgenommen; der Erzeuger schreibt LF und liess 153 weitere Dateien als reine Zeilenende-Umschreibung im Status stehen — die sind verworfen, nicht committet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011XC3R3yf9u7xnZneEKnU8w
Neuhr
Bescheinigungs-Selektoren gegen den Fundament-Katalog pruefen
`ABSENCE_CERTIFICATE_SELECTORS` stand auf `Record<string, ...>` — ein Tippfehler im `docType` ging still durch und schlug erst zur Laufzeit auf. Gemessen: mit `employer-sick-certificat` (ein Buchstabe fehlt) blieb der Bau gruen (Exit 0), waehrend die Positiv-Kontrolle (`maxDurationDays: "drei"`) korrekt mit TS2322 fiel — die Kopplung fehlte also wirklich, die gruene Null war echt.
Jetzt prueft ein `satisfies Partial<Record<EmployeeCertificateDocType, ...>>` das Katalog-Literal gegen `EMPLOYEE_CERTIFICATE_DOC_TYPES` aus @tolinax/ayoune-interfaces. Derselbe Tippfehler faellt mit TS2353.
`Partial` und nicht das volle `Record` ist Absicht: der Fundament-Katalog fuehrt seit Kaskade 64 auch `benefit-in-kind-receipt`, und die haengt am Mitarbeiter und einem Monat (`entityType: "Employees"`, `periodic: true`), nicht an einer Abwesenheit — ein Abwesenheits-Selektor dafuer existiert per Sache nicht. Ein volles Record verlangte einen Schluessel, der hier nie hingehoert. Gegenprobe gefahren: der zweite Katalog-Wert waere zulaessig (Exit 0), er ist nur nicht erzwungen.
`AbsenceCertificateDocType` ist aus dem Selektor-Bestand ABGELEITET (`keyof typeof`), damit keine dritte Wahrheit entsteht. `istBekannterBescheinigungsFall` ist jetzt ein Type-Guard und bleibt ausdruecklich am lokalen Bestand statt auf `isEmployeeCertificateDocType` zurueckzufallen: der Fundament-Waechter beantwortet "kennt der Katalog den Typ?", diese Funktion "kann DIESER Massenlauf ihn auswaehlen?" — fuer `benefit-in-kind-receipt` lautet die erste Antwort ja und die zweite nein.
`IAuswahlArgs.docType` bleibt `string`: der Wert kommt aus einem Anfrage-Rumpf und kann per Sache nicht zur Bauzeit geprueft werden; der Wurf bleibt der Laufzeit-Schutz, den die Testreihe festnagelt.
