Changelog

Zwei CEO-Screenshot-Befunde (tolinax.com mobil), beide in der GLOBALEN
Marken-Huelle — sie galten fuer jede Mandanten-Website.

1) Der Fuss-Bereich stand mobil zweispaltig gequetscht. Die Grund-Regel
repeat(auto-fit,minmax(150px,1fr)) hat keine Mobil-Fassung; am echten
396px-Sichtfeld gemessen: 2 Spalten a 158,5px, nachher 1 Spalte a 349px.
Dazu Abstand unten fuer den schwebenden Chat-Knopf.

2) Die Menue-Schublade war NICHT anklickbar — und z-index war nie die Ursache.
backdrop-filter auf dem Kopf macht ihn zum containing block fuer
position:fixed-Kinder UND zu einem eigenen Stapel-Kontext. Die Schublade
liegt IM Kopf, war also an ihm verankert statt am Sichtfeld (top:40px statt 0)
und ihr z-index:200 wirkte nur innerhalb des Kopfes. elementFromPoint in ihrer
Mitte lieferte ay-body. Flip-Probe: mit backdrop-filter:none top:0 und
ay-nav-link.

🔴 Die erste Fassung war HALB wirksam: die Kopf-Regel im 768er-Block wird vom
spaeteren Dunkel-Block ueberschrieben (gleiche Spezifitaet, Reihenfolge
entscheidet). Weichzeichner ging, Durchsicht blieb — schlechter als vorher. Die
geltende Fassung steht als eigener Media-Block am ENDE der Datei; eine Probe
nagelt die POSITION fest, nicht nur die Anwesenheit.

⚠ Der Weichzeichner wird nicht ersatzlos genommen, sondern ueberfluessig gemacht:
deckender Hintergrund aus --ay-bg, hell wie dunkel. Der Schreibtisch behaelt ihn.

⚠ Die Schublade aus dem Kopf herauszuziehen waere der andere Weg — er scheitert
an .ay-header-collapse{display:contents}, das auf dem Schreibtisch Navigation
und Aktionen zu direkten Flex-Kindern macht.

7 neue Proben (mit Positiv-Kontrolle und Umkehrprobe), volle Reihe 1765/1766.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Der Zweig vom Vormittag war zu eng: user liegt in drei Auspraegungen vor
(objectId 7.130 / array 826 / fehlend 418), und 102 der Listen sind leer.
{user:null} trifft eine leere Liste nicht (418 statt 520) — die 102 waren nach
dem ersten Rollout fuer NIEMANDEN mehr sichtbar. Kategorien wie bei den
unadressierten, also Broadcasts.

$in statt $size:0 — dieselben 520 Treffer, aber indizierbar.

Session-Id: notifications-nutzer-scope-restschnitt-startup-aggregation-20260823-1739

An der Sammlung gemessen liegt user in drei Auspraegungen vor: objectId 7.130,
array 826, fehlend 418. Von den Listen sind 102 LEER, und {user:null} trifft eine
leere Liste nicht (418 statt 520). Diese 102 waren vor dem Schnitt fuer jeden
sichtbar und waeren mit dem engeren Zweig fuer NIEMANDEN mehr sichtbar gewesen.

Session-Id: notifications-nutzer-scope-restschnitt-startup-aggregation-20260823-1739

An der Sammlung gemessen liegt `user` in drei Auspraegungen vor: objectId 7.130,
array 826, fehlend 418. Von den Listen sind 102 LEER — und {user:null} trifft eine
leere Liste NICHT ({user:null}=418, {$in:[null,[]]}=520). Diese 102 tragen dieselben
Kategorien wie die unadressierten und waren vor dem Schnitt fuer jeden sichtbar;
mit dem engeren Zweig waeren sie fuer NIEMANDEN mehr sichtbar gewesen.

$in statt $size:0 — dieselben 520 Treffer, aber indizierbar.

Session-Id: notifications-nutzer-scope-restschnitt-startup-aggregation-20260823-1739

Der erzwungene Mandanten-Schnitt ist bei notifications zu grob: der Verteiler legt
EIN Dokument JE EMPFAENGER an, die SDUI-Tabelle zeigte also die Post der Kollegen.
Neu: {$or:[{user:<ich>},{user:null}]} — eigene ODER unadressierte, nie fremde.

Der Schnitt liegt am SERVER, nicht in der basePipeline des Zustands: die reist als
Teil der Aufrufer-Pipeline mit und kann weggelassen werden. Verdrahtet an allen
vier Lesewegen (aggregation, export, queries x2) — ein ungeschuetzter waere die
Umgehung aller anderen, und der Export gibt die Zeilen ausser Haus.

20 Proben, vier Flip-Proben (Feldname / Broadcast-Zweig / Export-Verdrahtung /
Einschub im Hauptweg).

Session-Id: notifications-nutzer-scope-restschnitt-startup-aggregation-20260823-1739

unreadNotifications + page.notifications lasen {_customerID, markread:false} —
der Verteiler legt aber EIN Dokument JE EMPFAENGER an, die Glocke zeigte also die
ungelesene Post der Kollegen. Neu: eigene ODER unadressierte, nie fremde.

Zweite Haelfte und ohne sie waere die erste wirkungslos: der Zwischenspeicher-
Schluessel traegt jetzt userId statt customerId — sonst fuellt der erste Nutzer
den Eintrag und jeder weitere bekommt 30 s lang dessen Post, ohne Fehler.

11 Proben, beide Haelften einzeln flip-belegt (6 rot / 2 rot).

Session-Id: notifications-nutzer-scope-restschnitt-startup-aggregation-20260823-1739

changeMany/updateMany bauen ihren Filter intern aus {_id} und nehmen keine
zusaetzliche Bedingung entgegen — der Schnitt liegt deshalb auf einer Vorab-Lesung
(filterIdsToRecipient). Fremde Kennungen fallen still heraus; trifft die Verengung
nichts, wird kein leerer bulkWrite gefahren (waere ein 500).

Rest-Schnitt zum P1 notifications-nutzer-scope (2026-08-23).

Session-Id: notifications-nutzer-scope-restschnitt-startup-aggregation-20260823-1739

Der Riegel in `syncDashboardConfig()` lief die ganze Zeit korrekt — gemessen: nach
dem Wechsel traegt `DashboardPageFilterService.layer` sauber `null`. Sichtbar blieb
der Fremd-Stand trotzdem, weil die Leiste `ChangeDetectionStrategy.OnPush` faehrt und
ihre Anzeige nur ueber GETTER auf den Dienst liest, ohne ihn zu abonnieren. Bei OnPush
prueft Angular ein Kind nur bei Referenz-Aenderung einer Eingabe, bei einem eigenen
Ereignis oder nach `markForCheck()`; beim Wechsel zwischen zwei Dashboards ohne
gespeicherten Filter trifft nichts davon zu (`@Input() layer` ist beide Male `null`),
und das `markForCheck()` am Ende von `syncDashboardConfig()` markiert die ELTERN-
Komponente, was ein OnPush-Kind nicht schmutzig macht.

Deshalb waren zwei Runden lang alle Proben gruen: sie messen `filter.layer`, also den
DIENST — und der war immer korrekt. Die Luecke sass zwischen Dienst und BILD.

- Leiste abonniert `pageFilter.layer$` und ruft `markForCheck()` (kein dritter Riegel:
der Zustand wird nicht erneut gesetzt, nur die Anzeige daran gehaengt).
- Optionen-Abruf nur bei geaenderten Filter-DEFINITIONEN, sonst laedt jede Bedienung neu.
- `ngOnChanges` ENTFERNT samt seiner fuenf Proben (Abschnitt B): er konnte den Fall per
Bauart nie fangen, und jeden Fall, den er wirklich abdeckte, deckt heute
`syncDashboardConfig()` ab.
- Neue Reihe misst das GERENDERTE Bild statt des Dienstes; beidseitige Flip-Probe
(vor dem Fix 1 FAILED, danach 6/6), Umkehrprobe (Dashboard MIT eigenem Filter behaelt
seinen Stand) und Gegenprobe (kein Optionen-Abruf pro Klick). 47/47 der vier
betroffenen Reihen gruen, `npm run build:stage` gruen.

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.

Der vorige Commit hat die Datei per Python-Schreibvorgang im Textmodus von LF auf
CRLF gedreht — aus 49 hinzugefuegten Zeilen wurde ein Diff ueber 10281. Der Blob
trug vorher 0 CR-Bytes, danach 5165 (genau eins je Zeile). Inhalt unveraendert;
gegen den Vor-Stand bleiben die 49 additiven Zeilen der su-Gruppe.

Die Falle steht in der Wurzel-CLAUDE.md: ein Python dreht unter
Windows die ganze Datei.

Der states-Dienst liefert Verweis-Felder POPULIERT (Liste von Objekten), die
Optionen tragen dagegen die Kennung als Wert. mat-select vergleicht ohne
compareWith per === — Objekt gegen Zeichenkette trifft nie, also war nichts
ausgewaehlt, obwohl der Wert da war. Im Browser am Feature "Anhang (HGB)"
gemessen: 21 Optionen geladen, 0 als ausgewaehlt gefuehrt.

Nicht nur Anzeige: mat-select multiple schreibt beim Speichern die Werte
zurueck, die es kennt — eine einzige Auswahl haette die unsichtbare
Zuordnung still ersetzt.

Der Wert wird deshalb vor dem ersten Rendern auf Kennungen zurueckgefuehrt
(emitEvent: false, kein dirty — die Maske speichert selbsttaetig auf
valueChanges). Bewusst nicht ueber compareWith: das haette allein die
Anzeige geheilt und weiter Objekte zum Server geschrieben.

Proben: 5 neue in multi-select-zeigt-gespeicherten-wert.spec.ts, davon zwei
als Flip-Probe belegt (vorher rot, nachher gruen); Reihe 30/30.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Die sechs `availability: 'both'`-Aktionen (archive, ignore-in-merge, blacklist,
add-to-list, assign-segment, export) lesen `req.params.id` und schreiben mit
`{_id: entityId, _customerID}`. An der Sammel-Adresse gibt es keine Kennung, und
Mongoose ENTFERNT `_id: undefined` still aus dem Filter statt zu werfen — der
Zugriff traefe damit einen BELIEBIGEN Datensatz des Mandanten, ohne Fehler und
ohne Protokollzeile.

Geschuetzt waren sie bis hierher nur durch die ABWESENHEIT der Sammel-Route: ein
Hand-Haertungs-Marker haelt den Erzeuger davon ab, sie dort erneut zu mounten.
Das war noetig, weil genau das schon EINMAL passiert ist (Commit 5bc61ad).
Abwesenheit ist keine Abwehr — die Ruempfe tragen jetzt selbst den Waechter aus
der Erzeuger-Vorlage (`actionStub.ts.tpl:64-82`) und antworten ehrlich 501.

Verhalten mit gueltiger Kennung ist unveraendert (reine Einfuegung, 6x16 Zeilen).

Proben: `sammelAdresseWaechter.test.ts` — je Aktion das PAAR aus Abweisung ohne
Kennung (KEIN Datenbank-Zugriff, KEIN Ereignis) und UMKEHRPROBE mit Kennung
(regulaerer Weg laeuft), plus zwei Negativkontrollen (leere Kennung wird ebenso
abgewiesen; der Waechter kommt beim isValid-Ausstieg nicht zum Zug). 14 Faelle.
Flip-Probe gefahren: Waechter aus actionConsumerArchive entfernt -> 2 rot, nach
byte-genauer Wiederherstellung 14/14. Volle Reihe 1878/1878.

Der Marker-Kommentar ist nachgezogen: er behauptete, die sechs seien draussen,
WEIL ihre Ruempfe die Kennung binden. Das gilt nicht mehr — sie bleiben draussen,
weil ein 501-Weg kein Nutzen ist; wer die Sammel-Form braucht, implementiert sie
mit Kennungen im Rumpf und aendert `availability` auf `many`.

Brief: crm-consumers-both-aktionen-und-sammel-rechte-fundament-fix
Session-Id: crm-consumers-both-aktionen-und-sammel-rechte-fundament-fix-TBD

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012LmDa2yAaQZtJrAss6EuZ8

Der UCD-Nachschlag fragte `UCDs.findOne({key})` ueber ALLE Mandanten hinweg. Der
Schluessel reist offen in der Adresse (?ayoune_ucd=), `key` traegt keinen
Eindeutigkeits-Riegel, und der zweite Zweig ({url,interest}) nimmt beide Werte vom
Klienten — eine fremde Adresse genuegte fuer fremde Inhalte. Filter-Bau jetzt in
tracking/ucdHelpers.ts, fail-closed (ohne _customerID kein Nachschlag, nie ein
leerer Filter).

Zweiter Aufrufer ({url,interest} im Interessens-Handler) war entgegen der
Brief-Annahme LIVE — vom Compiler gefangen, mit verriegelt.

idcadd.js: die Knopf-Schlitze setzten ausschliesslich .value. Der neue Seiten-Bauer
zeichnet Knoepfe als <a class=ay-btn>, wo .value wirkungslos ist — ohne Fehler und
ohne Warnung. ayoune_setSlot entscheidet ab jetzt nach Element-Art.

Proben: 523 gruen (15 neu). Flip beidseitig gefahren — Riegel entfernt: 5 rot;
Element-Art-Zweig entfernt: 2 rot.

Der Arbeiter war in `kubectl logs` vollstaendig stumm — null `ay.logger`-Zeilen,
obwohl er arbeitete (Gegenprobe: `domain-health` fuehrt abgeschlossene Auftraege).

Gemessen sind ZWEI unabhaengige Schwellen, und beide mussten fallen:

1. `logger.level: 'info'` (Stufe 3) ist die Schwelle des WURZEL-Protokollierers und
greift VOR jedem Ausgabeweg. `success` ist Stufe 5 — `Domain Workers started`
und die Abschluss-Zeile des Abgleichs erreichten damit WEDER die Standardausgabe
NOCH die Sammlung `ayounelogs` (dort 0 Zeilen der Stufe `success` fuer diesen
Dienst, waehrend die Flotte insgesamt 83.620 fuehrt).
2. Der Ausgabeweg auf die Standardausgabe steht in Kubernetes seit dem 2026-07-31
per Vorgabe auf `error` (`resolveConsoleLevel`, Buendel 20/A) — eine bewusste
Kosten-Abwaegung, kein Defekt.

Neu: `level: 'success'` + `consoleLevel: 'success'`. Die Schwelle ist eine
OBERGRENZE, also faellt `verbose` (8) heraus — genau richtig, denn das ist hier die
Zeile JE AUFTRAG und damit der Mengen-Treiber. Aufkommen rund 75 Zeilen je Stunde.

WIDERLEGT: die Boot-Reihenfolge ist NICHT die Ursache. Der `ay.on('ready')`-Rumpf
laeuft zwar vor `initLogger`, aber der Boot-Vor-Protokollierer schreibt in diesem
Fenster auf Stufe `silly` auf die Standardausgabe. Ein Verschieben nach hinten
wuerde die Stille VERSTAERKEN. Kommentar in server.ts haelt das fest.

Kern UNBERUEHRT — der Befund gilt fuer jeden Dienst in Kubernetes und gehoert in
einen Fundament-Platz, nicht in diesen Fix.

Ein `pwa`-Eintrag OHNE `_websiteID` hat keine Geschwister. Die Zuordnung kannte
nur die Geschwister-Form und lieferte fuer ihn GENAU die eine Auffang-Regel auf
die consumer-app — er bekam Zertifikat, Tor und Route, war erreichbar und zeigte
die Marketing-Website unter der Anmelde-Adresse. Empirisch belegt am 2026-08-23:

buildHostRoutingRules({domain:'login.protos.ayoune.app', hosts:[]})
-> [{route:[{destination:{host:'consumer-svc',port:{number:3000}}}]}]

Diese Form ist der Regelfall, sobald ein Wiederverkaeufer gar keine Website hat —
also genau die Lage, in der Auftrag 4 (Beweis an EINEM Host) bewiesen werden soll.

- `hostRouting`: neuer Eingang `selfTarget`; ist er gesetzt, wandert **der Auffang
selbst** auf die Plattform-Flaeche (bewusst keine `match`-Regel davor: der
Platzhalter `*.<domaene>` steht in denselben `hosts` und fiele sonst weiter auf
die Website), und `rootTarget` wird ignoriert (die Umleitung waere eine Schleife).
- `platformHostGate`: `platformHostTargetFor()` gibt das ZIEL statt nur „ja";
`isEnabledPlatformHost` ruft sie — EINE Implementierung, nicht zwei.
- `provisionDomain` leitet den Schluessel aus dem Tor ab und reicht ihn durch.

Rueckwaerts-Identitaet festgenagelt: ohne `selfTarget` ist jede Bestands-Form
byte-gleich zu vorher (Probe ueber vier Formen), und eine `consumer`-Domaene
bekommt den Schluessel per Flip-Probe nachweislich NICHT.

Flip-Proben beidseitig gefahren: Regel-Ebene ausgehaengt -> 4 rot; Verdrahtung
ausgehaengt -> 1 rot; beide zurueck -> ganze Reihe exit 0 (25 + 47 + 4 + Rest).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018KTTjQDtPqzMCcA9pm8jND

Am laufenden Bildschirm gesehen: Material reserviert mit der Vorgabe EINE Zeile
fuer den Hinweis und rechnet mehrzeilige Hinweise nicht ein. Die Hinweise sind
hier bewusst laenger als eine Zeile, weil sie echte Fallen benennen (ein
Punkt-Pfad sperrt die Kante dauerhaft; der Joker ist nur als Ausgang zulaessig)
— sie standen deshalb im naechsten Feld.

subscriptSizing="dynamic" an allen zehn Feldern + etwas Abstand.

⚠ Vierter Treffer der Backtick-Falle an einem Tag, diesmal im neuen
CSS-Kommentar selbst. Der Warnhinweis stand schon zwei Zeilen darueber.

Proben 33/33. build:stage gruen.

Live gemessen (2026-08-23): der Listen-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 loest
unveraendert auf.

- Route traegt wieder BEIDE Kinder. Das leere heisst hier NICHT „anlegen" (ein
Prozess wird uebernommen, `hideCreate` bleibt), sondern „welchen Prozess?" —
die Liste kennt die Kennung der Plattform-Vorgabe nicht, der Editor loest sie
ueber `GET /applicationprocesses` auf und ersetzt die Adresse.
- Route-Probe auf beide Formen gedreht, Konstante umbenannt
(`EINSTIEG_OHNE_KENNUNG`), Begruendung an allen drei Fundstellen.

Proben 33/33. build:stage gruen.

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.

Zwei Befunde vom AUSGEBRACHTEN Bildschirm, nicht vom Entwurf.

1) Joker-Kanten (from: '*') liefen quer ueber die ganze Leinwand — bei der
Plattform-Vorgabe drei Linien (reject/withdraw/hold), die alles kreuzen, was
dazwischen liegt. Sie haben per Bauart keinen Ausgangs-Knoten; ein kurzer
Stummel links am Ziel sagt dasselbe („kommt von ueberall") und kreuzt nichts.
Probe mit Gegenprobe: eine NORMALE Kante darf lang bleiben, sonst waere der
Graph nicht mehr verbunden.

2) --mat-app-background-color GIBT ES NICHT im ausgelieferten Stil (am gebauten
styles-*.css gemessen) — der Rueckfall #fff schlug also immer durch, und auf
dem dunklen Thema standen weisse Karten auf dunklem Grund. Ersetzt durch die
M3-System-Tokens, die real existieren (surface-container-high / on-surface /
outline-variant / primary).

⚠ Dritter Treffer der Backtick-Falle an einem Tag: ein Backtick in einem
CSS-Kommentar INNERHALB der styles-Vorlage beendet das Template-Literal, und
der Uebersetzer zeigt auf eine Zeile weit dahinter. Der Warnhinweis steht jetzt
in beiden Vorlagen dieser Datei.

Proben 33/33.

Der Rueckfall-Wert von `hostnameOf` fuer den eigenen Host war ein
Sentinel-String, der beim Schreiben zu einem NUL-Byte wurde. Folge: git
fuehrte die Quelldatei als BINAER (`Bin 0 -> 11342 bytes`) — kein Diff, keine
Durchsicht, obwohl Bau und Proben gruen blieben. Gefunden beim Pflicht-Blick
auf `git show --stat` nach dem Commit, nicht vom Bau.

Der Sentinel ist zugleich sachlich ersetzt: ein leerer eigener Host darf gar
nicht vergleichen, sonst waere er ein Treffer fuer jeden ebenso unlesbaren
Host. Statt eines Wertes, der nie trifft, jetzt eine ausdrueckliche Bedingung.

19/19 Proben unveraendert gruen, `tsc` (app + spec) und `build:stage` gruen.

`redirectToLogin` schickte einen Nutzer, dessen Sitzung ablaeuft, auf
`${loginUrl}/ayoune` — der Marken-Slug stand fest im Quelltext. Auf einem
weiss-etikettierten Host (`app.kunde.de`) verschwand damit mitten in der
Nutzung die Marke des Wiederverkaeufers, ohne sichtbaren Fehler.

Der Slug wird jetzt aus dem HOST abgeleitet, in derselben Reihenfolge wie in
`clients/auth`: Zwischenspeicher → Plattform-Host → Abruf (`GET /host/:host`
auf reseller-api, seit 2026-08-23 gebaut). Faellt der Abruf aus, gilt `ayoune`
— fail-safe, nicht fail-closed. Die Rueckfall-Regel `login.ayoune.app/<slug>`
bleibt unangetastet; es wird nichts umgeleitet und nichts ersetzt.

ZWEI gemessene Abweichungen gegenueber `clients/auth`, beide notwendig:
(a) der Apex kommt aus `loginUrl`, NICHT aus `frontendUrl` — der traegt hier
`pwa.ayoune.app`, also eine Flaeche UNTER dem Namen; dieselbe Ableitung haette
`app.ayoune.app` zum Fremd-Host gemacht und den haeufigsten Rueckweg einen
Abruf gekostet. (b) die Etiketten-Liste traegt zusaetzlich `pwa`.

Messung (Schritt 1 des Auftrags): genau EINE fest verdrahtete Fundstelle.
Zwei weitere sehen so aus, sind es aber nicht (`${startupUrl}/ayoune` ist
`/:product`, kein Marken-Slug), und die Lib `@tolinax/ayoune-auth-client`
leitet nackt auf `loginUrl` ohne Slug — den Fall deckt der Host-Riegel der
Anmelde-Oberflaeche ab.

19 Proben (`login-brand.spec.ts`) mit Flip-Probe `login.protos.ayoune.app`
(Reseller-Domaene unter dem Plattform-Namen ist KEIN Plattform-Host),
Byte-Gleichheit auf der Plattform-Marke und drei Negativ-Kontrollen
(404 / Netzfehler / Antwort ohne slug → `ayoune`, nie `undefined`).

Zwei Befunde am Bewerbungsprozess, beide ueber ihn hinausreichend.

1) `resolveCreateCtaLabel` las `hideCreate` NICHT — der Leer-Zustand zeigte
seinen Anlege-Knopf auch dort, wo der Zustand das Anlegen ausdruecklich
unterdrueckt. Die drei anderen Leser respektieren ihn laengst
(`create-button-visibility.ts:59`, `primary-action.ts:41`,
`base-page.component.html:245`); allein die Beschriftung nicht, weil sie nur
`name_singular` brauchte. Am Bewerbungsprozess haette der Knopf einen leeren
`Workflows`-Datensatz ohne Stufen erzeugt — genau den kaputten Prozess,
gegen den die Server-Pruefung sieben Riegel faehrt. Gemessene Reichweite:
6 Zustaende tragen `hideCreate: true`. Flip-Probe: Riegel entfernt faerbt
genau 1 Probe rot, die Gegenprobe bleibt gruen.
⚠ `AyounePageViewConfig` DEKLARIERT `hideCreate` gar nicht (TS2345 „has no
properties in common") — das Feld existiert nur zur Laufzeit, `tableState()`
spreizt es hinein. Daher die Index-Signatur.

2) Platzhalter-Weg `edit/vorgabe`: die Liste kennt die Kennung der
Plattform-Vorgabe nicht (Aggregations-Weg blendet sie per Bauart aus), also
loest der Editor sie ueber die Sammel-Liste auf und ersetzt die Adresse.
Die EIGENE Kopie schlaegt dabei die Vorgabe.

Nebenbei: zwei Proben in `no-content.component.spec.ts` erwarteten seit dem
2026-08-12 ein `Create `-Praefix, das an jenem Tag ausgebaut wurde — sie waren
seither dauerhaft rot (baseline nachgemessen: 2 rot ohne jede eigene Aenderung)
und sind auf das gemessene Verhalten nachgezogen.

Proben 53/53. build:stage gruen (0 Fehler, Schrift-Waechter BESTANDEN).

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").

Reihe gruen: 52 Suiten / 1095 Proben.

CEO 2026-08-23: `JobOffers` IST Markt-BEOBACHTUNG (Job-Scraper-Zufluss), NICHT der Traeger
eigener Stellenangebote. Damit ist die einzige offene Produkt-Frage dieses Briefes
beantwortet und der `joboffers`-Teil faellt ENDGUELTIG aus dem Umfang — die fuenf Aktionen
(send/accept/reject/counter-offer/expire) brauchen einen EIGENEN Traeger, das ist ein
Folge-Brief (neue Entitaet ⇒ Fundament), nicht dieser hier.

Der Entscheid deckt sich mit dem am 2026-08-04 gemessenen Bestand, den der Brief selbst
fuehrt: 22 leere Stubs, KEIN `_customerID`, und die Form (`source`/`sourceId`/`applyLink`/
`descriptionHTML`) beschreibt ein eingelesenes FREMDES Angebot.

Drei Folgeaenderungen, damit der Brief nicht auf toten Praemissen stehen bleibt:
- awaiting `ceo-decision` → `none` (nichts Menschliches mehr offen)
- trigger `BLOCKED-ON-CEO-DECISION` → READY samt Begruendung
- claim_paths interfaces+models (Altlast, Fundament seit Kaskade 28 geliefert) → die drei
echten Ziel-Repos, AUS DER REGISTRY ABGELEITET statt geraten: Vacations→hr.js,
SupplierAgreements→purchase.js, Documents→crm.js; Umkehrprobe mit erfundenem Plural 0.

Danach gemessen: der Brief meldet nur noch NOT-READY:paths gegen eine LAUFENDE Sitzung
(bewerbermanagement-w4 haelt domains/hr/api) — ein echter, transienter Konflikt statt einer
toten Praemisse. Er loest sich, wenn jene Sitzung endet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Der Vorgaenger-Commit drehte die Datei von LF auf CRLF und zeigte dadurch 8939
geaenderte Zeilen statt der echten 139. Zweiter Fall derselben Klasse in dieser
Sitzung (der erste in domains/cms/api, drei Commits lang).

🔴 DIE URSACHE, die beim ersten Mal noch nicht benannt war: Pythons TEXT-Schreibmodus.
`io.open(p, "w", encoding="utf-8")` uebersetzt auf Windows jedes `\n` beim SCHREIBEN
nach `\r\n` (newline=None => os.linesep). Wer eine Datei so einliest und zurueck-
schreibt, dreht ihre Zeilenenden — auch wenn er nur drei Zeichen geaendert hat.

Abhilfe fuer den naechsten Bearbeiter, in dieser Reihenfolge:
1. Zeilenenden der Datei VOR dem Edit messen: git show <ref>:<datei> | ...
2. Im BINAER-Modus lesen und schreiben (open(p,"rb") / open(p,"wb")) ODER beim
Text-Schreiben newline="" mitgeben.
3. VOR dem Push git show --stat lesen: eine vierstellige Zeilenzahl bei einer
kleinen Aenderung ist immer dieses Problem.

⚠ Es gibt hier KEINE .gitattributes, also keine Repo-weite Politik — jede Datei
traegt ihren eigenen Stand. Diese hier ist LF (8939 Zeilen), pauschales
"normalisieren" ist deshalb genauso falsch wie das Drehen.

--selftest-intake unveraendert 32 ok / 0 fail.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Dritter Anlauf an der Zeilenenden-Frage, und diesmal GEMESSEN statt pauschal:

routerPageActions.ts CRLF <- war so, ist wieder so
die fuenf *.test.ts LF <- waren so, sind wieder so

Der Vorgaenger 80a05c4 hat ALLE SECHS auf LF gedreht. Fuer die fuenf Testdateien war
das richtig (mein erster Commit hatte ihnen CRLF eingeschleppt), fuer
routerPageActions.ts falsch — die Datei war im Repositorium schon immer CRLF, und die
"Normalisierung" war dort eine 7081-Zeilen-Aenderung, die niemand wollte.

⚠ Lehre: "Zeilenenden normalisieren" ist KEINE pauschale Handlung. Ohne .gitattributes
gibt es keine Repo-weite Politik; jede Datei traegt ihren eigenen Stand, und der ist
am URSPRUNGS-Commit zu messen (git show <ref>:<datei>), nicht am Nachbarn zu raten.

Der Netto-Diff dieser drei Commits gegen d43a167 ist jetzt das, was er von Anfang an
haette sein sollen: 241 Zeilen dazu, 19 weg, in sechs Dateien.

CI-Tor npm run test:unit: 2398/2398, 100 Reihen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

ZWEI Fehler am Vorgaenger-Commit b8656bf, beide meine:

1. DIE COMMIT-NACHRICHT IST FREMD. Sie lautet "fix(import): Menue kuriert ueber
ALLE Seiten der Website" und beschreibt eine ganz andere Arbeit. Ursache: der
erste Commit-Versuch wurde vom Fundament-Precheck-Hook geblockt — DER GANZE
Bash-Aufruf, also auch das `cat > /tmp/cmsmsg.txt` davor. Der zweite Versuch
las dieselbe Datei, die inzwischen einen fremden Stand trug.
⚠ Lehre: nach einem Hook-Block ist NICHTS aus dem Aufruf gelaufen — auch nicht
die Vorbereitung. Wer danach nur den letzten Befehl wiederholt, baut auf einem
Zustand auf, den er nicht hergestellt hat. Dieselbe Klasse wie das verschluckte
`git add` vom 2026-08-22 (neun Dateien fielen aus dem Commit).

2. ZEILENENDEN: meine Edits schrieben CRLF in sechs Dateien, das Repositorium
speichert LF (Nachbardateien 0 CRLF, core.autocrlf=false, keine .gitattributes).
Der Vorgaenger-Diff zeigte deshalb 3360 Zeilen statt der echten 241/19. Hier
zurueckgedreht; kuenftige Diffs und blame auf diese Dateien sind wieder lesbar.

INHALT DES VORGAENGERS (das, was in seiner Nachricht haette stehen sollen):
- logos: Eintrag ohne verwertbare Bildadresse wird als Text-Chip gezeichnet,
nicht als <img src="">. Gemischte Reihen tragen.
- mapCustomerLogosToItems: der Filter warf bildlose Eintraege WEG — deshalb waren
sie unsichtbar; ein Fix nur im Zeichner waere wirkungslos geblieben.
- references: Leer-Aussage zweisprachig, nur bei Entitaets-Speisung; ein leerer
INLINE-Block bleibt still. Resolver setzt __referenceItems auch bei leerer Menge.
- BEWUSSTE EINENGUNG: eine ABGELEHNTE Adresse bleibt src="#" wie bei den fuenf
Geschwister-Sinks (klassenweiter Vertrag, renderBlockMediaBlocks.test.ts:324).

CI-Tor npm run test:unit nach der Normalisierung: 2398/2398, 100 Reihen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Am Beleg-Lauf gemessen: das kurierte Hauptmenue liess ausgerechnet die
Schwerpunkt-Seite /active-campaign-management weg. Sie ist von Hand gebaut und
steht in keiner Quell-Sitemap, war also nie im Lauf-Bestand. Ein Menue, das nur
zeigt, was der Import gerade angefasst hat, ist bei jedem zweiten Lauf ein anderes.

Neu findPages(websiteId) am Datenbank-Weg (optional — ein Adapter ohne ihn faellt
auf das bisherige Verhalten zurueck statt zu scheitern) und collectCurationPages:
Lauf-Bestand plus alle UEBRIGEN veroeffentlichten Seiten. Die Angaben des Laufs
gewinnen, weil ihr Titel bereits gereinigt ist.

Nur veroeffentlichte Fremd-Seiten kommen dazu — ein fremder Entwurf im Hauptmenue
waere ein Verweis auf eine Seite, die es oeffentlich nicht gibt. Die Seiten des
Laufs sind davon ausgenommen, sie sind per Bauart Entwuerfe.

4 neue Proben inkl. Negativ-Kontrolle (Entwurf faellt weg, Positiv-Kontrolle
daneben), Rechtsseiten-Zuordnung und Fehlertoleranz. 88/2027 -> 88/2031.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Die Annahme-Seite liess ausschliesslich 'invite-sent' als offen gelten und wies
'user-created-by-admin' als not-open ab. Der Betreiber-Weg ueber
superuser.ayoune.app legt aber genau mit diesem Status an
(routerOnboardingActions.ts:96/105) - eine so angelegte Person konnte ihr
Passwort ueber /:reseller/accept-invite?token= nie setzen. Der CEO-Entscheid
2026-08-22 (Weg a) verlangt genau das.

- INVITE_OPEN_STATUSES als Menge; INVITE_OPEN_STATUS bleibt der Einzelwert fuer
den Rueckbau-Rueckfall.
- Der atomare Riegel fragt {$in: INVITE_OPEN_STATUSES}. Mit dem Einzelwert
haette er bei einer Betreiber-Einladung nie gegriffen: die Vorpruefung liesse
sie als valid durch, hier waere sie als race-lost gescheitert - ein 410
"schon angenommen" fuer eine Einladung, die niemand angenommen hat.
- Der Rueckbau stellt den URSPRUENGLICHEN Status wieder her ({new:false} liefert
ihn). Vorher haette ein Fehlschlag eine Betreiber-Einladung still in eine
Team-Einladung verwandelt und dem Betreiber-Weg seinen Wiedervorlage-Datensatz
entzogen.

NICHT der Erzeuger auf 'invite-sent' umgestellt: der Status traegt die HERKUNFT,
und der Betreiber-Weg sucht mit ihm. Eine Verschmelzung braeche jene Suche.

Die W2-Probe, die 'user-created-by-admin' auf not-open festnagelte, ist
umgedreht statt geloescht - samt Negativ-Kontrolle, dass die Weitung GENAU einen
Status umfasst und die Frist fuer beide gilt. Flip-Probe: 2 rot / 9 gruen.
Volle Reihe 660/665 (5 uebersprungen), tsc --noEmit sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Gefunden an der LIVE-Probe, nicht an den 987 gruenen Proben: ein Uebergang auf eine
nicht sichtbare Kennung meldete "Error 500: Applications not found".

Ursache: `customerMongoose.findById` gibt bei Nicht-Fund kein leeres Ergebnis zurueck,
sondern WIRFT (`RessourceNotFoundError`, core methods/find/findOne.js:35) — und der
Fehler traegt seinen Status (404) bereits im zweiten super-Parameter. Der `if (!doc)`-
Zweig ist damit unerreichbar, und der pauschale 500er im Fang-Zweig machte aus JEDEM
Aufruf mit fremder oder falscher Kennung eine Dienst-Stoerung.

Der Fang-Zweig respektiert jetzt `e.status` (4xx/5xx) und protokolliert ein 4xx als
`warn` statt `error` — dieselbe Klassifikation wie im Fang-Zweig von createApplication.
Ein Bedienfehler weckt damit niemanden in der Ueberwachung.

⚠ Die Klasse ist breiter als dieser Weg — eine Parallel-Sitzung arbeitet an derselben
Sache im Kern (core-updateone-wickelt-404-in-500). Hier ist der Verbraucher behoben.

Proben 988/988. Flip-Probe: Status ignorieren faerbt genau 1 rot.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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>

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>

Am laufenden Dienst gemessen (2026-08-22): GET /applicationprocesses/<erfunden>
antwortete mit HTTP 404 und `meta.code: 500`. Die ay-CLI liest den Rumpf und meldete
deshalb "Error 500" fuer einen Bedienfehler — in der Ueberwachung eine Stoerung.

Ursache: der HTTP-Status kommt aus `res.locals.status` (returnResponse), der
`meta.code` aber aus `err.status || 500` (defaultAPIAnswerError) bzw. einem
HARTKODIERTEN 400 (defaultAPIAnswerRequestFailed). Beide lesen `res.locals` nicht.
Damit kam auch die ganze GUARD_STATUS-Abbildung der Motor-Ablehnungen (403/409/422)
als 400 beim Aufrufer an — der Kern von W2 war im Rumpf unsichtbar.

Neue Naht `lib/antwortMitStatus.ts` haengt den Status an den Fehler, damit
`err.status` greift; alle Ablehnungen der drei W2-Wege laufen darueber.

⚠ Die zwei Antwort-Bauer in `platform/core` sind NICHT angefasst — sie liegen
ausserhalb der claim_paths, und eine Aenderung dort traefe ~330 Verbraucher. Die
Codegen-Vorlage traegt denselben Widerspruch (actionJobOfferSend).

⚠ Der strukturelle Waechter allein reichte NICHT: eine Flip-Probe, die der Naht das
Anhaengen wegnimmt, liess ihn gruen — er prueft, DASS sie benutzt wird, nicht DASS sie
wirkt. Deshalb zusaetzlich `antwortMitStatus.test.ts` (7 Faelle inkl. Negativ-Kontrolle
am rohen Bauer). Mit ihr beisst die Flip-Probe: 6 rot.

Proben 986/986 (49 Reihen, vorher 979/48).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Der Dubletten-Schluessel trug ein literales NUL als Trenner. Folge: git stuft die
Datei als binaer ein und zeigt keinen Diff mehr — eine Codeueberpruefung saehe
Aenderungen daran nie. Gefunden am "Bin 0 -> 8496 bytes" im Commit-Statistik-Block,
nicht an einem Fehlschlag: Bau und Proben waren die ganze Zeit gruen.

Ersetzt durch eine verschachtelte Karte (Map<from, Set<event>>) statt eines
zusammengesetzten Schluessels — damit entfaellt die Trenner-Frage ganz. Ein
Escape half nicht: es wurde auf dem Schreibweg erneut zu einem echten NUL.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

130e28a committete mit , und das nimmt UNVERSIONIERTE Dateien nicht auf:
die zwoelf geaenderten Dateien gingen mit, die neun neuen nicht. Der lokale Bau blieb
gruen (er sieht den Arbeitsbaum), die Kette #174 fiel mit neun — genau den neun fehlenden Dateien.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

BEFUND (systemisch, aber klein): der Pruefer loest `DEPENDS-ON <slug>` gegen SITZUNGS-
Kennungen in sessions/done/ auf. Wird ein Brief innerhalb einer FUNDAMENT-KASKADE geliefert,
wandert er nach queue/done/, ohne je eine eigene Sitzung getragen zu haben — gemessen 0
Sitzungen fuer beide Ziele, bei status:done. Ein stamm-basierter Aufloeser findet das nie,
und der abhaengige Brief meldet fuer immer `trigger:waiting`.
GROESSE der Klasse gemessen (nicht geschaetzt): 36 blockierte Briefe tragen ein DEPENDS-ON,
6 davon haben ein Ziel in queue/done/, und genau 2 davon haben keine Sitzung. Diese zwei.

Beide Abhaengigkeiten stattdessen EMPIRISCH am installierten Fundament belegt
(@tolinax/ayoune-interfaces 2026.451.0), je mit Positiv- und Umkehrprobe:
- presse-portale: `PressReleases` in data/modelsAndRights/marketing.js (1 Treffer;
Positiv-Kontrolle `Partners` 2; Umkehrprobe erfundener Name 0). Geliefert von Kaskade 64.
- white-label: IDomain.d.ts fuehrt `serviceType` (Z.66) UND `rootTarget` (Z.94)
(Positiv-Kontrolle 51 Feldzeilen; Umkehrprobe 0). Der Auslöser fragte ohnehin nach
PUBLIKATION, nicht nach Brief-Status — also so gemessen.

⚠ Beim Schreiben in die dokumentierte Zitat-Falle gelaufen und wieder heraus: das woertliche
Zitat des alten Auslösers wurde vom Pruefer als AKTIVER Auslöser gelesen, der Brief blieb
`waiting`. Genau das haelt `backup-pending-haenger-und-erster-lauf-beleg` in seinem eigenen
trigger fest. Marker-Schreibweise deshalb vermieden; danach beide READY.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

paymenttransactions-consumerid — Auslöser UEBERHOLT, und der Brief widerlegt ihn selbst.
Er verlangte "einen FUNDAMENT-PLATZ (Einzelschreiber auf interfaces + models)", waehrend
sein eigener STOPP-Block auf Zeile 53 vier positive Quelltext-Belege fuehrt, dass die
Fundament-Haelfte seit Kaskade 28 geliefert ist (IPaymentTransaction._consumerID:48 ·
IConsumer.recipients:848 · PaymentTransactions.ts:29 + Index :37 · Consumers.ts:996).
Offen sind nur die zwei Verbraucher-Teile: die Schreib-Seite von `_consumerID` und der
Reiter "Empfaenger", der weiterhin `Notifications` zeigt. Beides ohne Fundament-Platz.
claim_paths BEWUSST nicht ersetzt — der Rumpf benennt fuer die zwei offenen Haelften keine
eindeutigen Ziel-Repos; ein Ersatz waere geraten. Als erster Schritt im Lauf zu setzen.

oauth-app-kontingente-bau — Schwelle NACHGEMESSEN statt geglaubt (rein lesend, Prod):
`oauthclients` = 1, `oauthtokens` = 0. Der Auslöser verlangt BEIDE > 0, er ist NICHT
erfuellt — der Brief liegt zu Recht. Gegenueber der 08-03-Messung (0/0) hat sich die eine
Haelfte bewegt. Nebenbefund festgehalten, NICHT behoben: claim_paths fuehrt platform/core
bei `foundation: false`; der Widerspruch ist latent, solange die Schwelle sperrt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

callagent-drei-tote-felder — EINGEHAENGT. Sein Auslöser nannte
"foundation-batch-cascade-31" als Halter von platform/interfaces; der Bestand steht bei
68. Vor allem aber braucht der Brief gar keinen Platz: sein eigener Defer-Grund sagt
"Nach dem ABBILDEN-Entscheid gibt es KEINEN interfaces/models-Anteil — die Arbeit liegt in
drei anderen Repos", und Rumpf-Zeile 84 benennt sie woertlich (communication-server /
mobile-app / domains/ai/api). claim_paths entsprechend gesetzt — vorher standen dort
interfaces+models, was ihn bei JEDER laufenden Fundament-Sitzung mit NOT-READY:paths
kollidieren liess (4x zurueckgelegt). Danach gemessen: nur noch ein ECHTER, transienter
Konflikt mit einer aktiven Sitzung, den der Pruefer selbst als verengbar ausweist.
Der Teilbefund `sttProvider ist nicht abbildbar` bleibt ausdruecklich offen.

rang2-restposten-zustandsfelder — ZWEITE Korrektur am selben Tag, sie nimmt meine erste
zurueck. Der Commit 158ae945cd hob ihn auf `dependency` mit der Begruendung "reiner
Platz-Warter"; das war SACHLICH FALSCH. Gemessen: die Fundament-Haelfte ist geliefert
(3 von 4 Entitaeten), der Rest braucht keinen Platz. Offen ist eine PRODUKT-Entscheidung,
die der Brief selbst benennt: `joboffers` wurde am Bestand gestoppt (22 leere Stubs, kein
`_customerID`) — gehoeren die fuenf Aktionen ueberhaupt an diese Entitaet? Daher
`ceo-decision`, damit /interview ihn ueberhaupt sieht.
Die Fundament-Pfade blieben dort BEWUSST stehen: der Brief benennt kein einziges
Nicht-Fundament-Repo, ein Ersatz waere geraten gewesen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Jeder der sieben traegt `foundation: false` UND sagt im eigenen Rumpf, dass sein
Fundament-Anteil erledigt ist ("Der Fundament-Teil dieses Briefes ist GELIEFERT",
"KEIN Fundament-Diff", "FUNDAMENT-ANTEIL GELIEFERT"). Stehen geblieben war nur der
`claim_paths`-Eintrag auf platform/interfaces|models|core.

DER SCHADEN ist der in CLAUDE.md (Kaskade 68) beschriebene: ein `foundation:false`-Brief,
der einen Fundament-Pfad weiter beansprucht, faellt beim Promote mit
`NOT-READY:paths:<sitzung>:<pfad>`, sobald irgendeine Fundament-Sitzung laeuft — und die
laufen rund fuenfmal taeglich. Er wird eingesammelt, kollidiert, wird zurueckgelegt,
wiederholt. Gemessen: von sieben geprueften Briefen dieser Klasse sind ALLE SIEBEN
mehrfach zurueckgelegt (2-4x).

Eine Stichprobe zusaetzlich am Quelltext belegt statt am Brieftext geglaubt:
sdui-aktions-schiene verlangt ein Verb-Feld an `actionDef` — es steht seit laengerem in
platform/core/src/lib/api/registerModuleStates.ts:899 und wird :914 verwendet.

WIRKUNG GEMESSEN: drei der sieben melden nach der Verengung `READY`
(dashboard-geteilter-seitenfilter, stackdump-restmenge, statusseite-tages-rollup);
vorher keiner. Alle sieben behalten nicht-leere claim_paths.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Der Ausstoss eines Erzeuger-Laufs vom 2026-08-22T05:13Z lag 121 Dateien gross unversioniert
im Arbeitsbaum. Gepruefte Entscheidung: uebernommen, mit EINER benannten Korrektur.

BELEG, dass der Ausstoss reproduzierbar ist: Arbeitsbaum-Stand gesichert, auf HEAD
zurueckgesetzt, voller Modul-Lauf `codegen routes --module hub` neu gefahren, danach
byte-verglichen — deckungsgleich (sha1 ueber alle 171 .ts identisch), mit Positiv-Kontrolle
gegen HEAD (163 Unterschiede, der Vergleich greift also wirklich).

WAS SICH FACHLICH AENDERT — 11 Router (chats, examresults, exams, faqs, glossaries,
hubquestions, knowledgebases, polls, quotes, savedreplies, wikipages):

PUT /many vorher extendForNewRights(BASE) -> verlangte `hub.<e>.new`
nachher extendForMassEditOrEdit() -> `hub.<e>.edit` ODER `hub.<e>.massEdit`
DELETE /many vorher extendForDeleteRights(BASE) -> verlangte `hub.<e>.delete`
nachher extendForMassDeleteOrDelete() -> `hub.<e>.delete` ODER `hub.<e>.massDelete`

Der PUT-Fall ist eine Korrektur, kein Zusatz: eine Mengen-AENDERUNG verlangte bis hierher das
ANLEGE-Recht. Wer `new` haelt, aber weder `edit` noch `massEdit`, verliert den Mengen-Weg — er
haette ihn nie haben duerfen. Wer `edit` haelt, aber nicht `new`, gewinnt ihn. Der DELETE-Fall
ist rein additiv (any-of): niemand verliert, `massDelete`-Halter gewinnen.

Dazu die 4xx-Klassifikation aus der Vorlage (ValidationError/CastError enden als 400 + warn
statt 500 + error) in allen create/update/delete/get-Handlern.

DIE EINE KORREKTUR AM AUSSTOSS: der Modul-Lauf entfernt in routerHubQuestions.ts still die von
Hand gesetzte Montage `use('/:id/comments', routerHubQuestionsComments)` samt Einfuhr — acht
Kommentar-/Reaktions-/Stimmen-Routen waeren danach ueber HTTP unerreichbar gewesen.
Wiederhergestellt und mit dem vorgeschriebenen Zeile-1-Haertungsmarker versehen, damit der
naechste Lauf sie meldet statt sie zu entfernen. Gegenprobe am Waechter: `--probe` meldete
vorher 0 gehaertete Dateien, jetzt 1, mit dem Vermerk "NUR ueber den Marker" — die zwei
Bestands-Achsen (verlorene Deklaration / verlorener Hand-Import) sind fuer eine verlorene
`use()`-Montage strukturell blind.

Verify: `npm run build` gruen; Testreihe 217/217 in 16 Suiten gruen. Kontrolle vorher gefahren:
mit dem rohen Ausstoss fielen 2 Proben in `hubquestionsRouterMounting.test.ts`, bei HEAD waren
dieselben 5/5 gruen — die Regression war echt und ist geschlossen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Der Katalog-Eintrag aus 7281a71 haette eine Mail verschickt, deren Verweis auf
eine Seite fuehrt, die ihn ABWEIST — also genau die Fehlerklasse, mit der der
CEO-Entscheid Weg (b) verworfen hat ("toter Verweis"), nur eine Ebene weiter.

Gemessen: `platform/auth/src/lib/inviteState.ts:32` fuehrt
`INVITE_OPEN_STATUS = 'invite-sent'` als "der EINZIGE Status, aus dem heraus
eine Einladung angenommen werden darf"; Zeile 70 weist jeden anderen als
`not-open` ab. Der Betreiber-Weg schreibt `user-created-by-admin`. W2 hat den
Fall gesehen und den Wert in einer eigenen Probe FESTGENAGELT
(`platform/auth/test/inviteState.test.ts:44`) — eine getroffene Entscheidung
der Nachbarstrecke, kein Versehen. Der Entscheid nahm an, W2 trage die Annahme;
er sagt selbst "die Annahme-Seite muss stehen, BEVOR diese Mail sinnvoll
verschickt wird".

Die VORARBEIT bleibt und ist geprueft: Empfaenger-Rueckfall auf `evt_data.email`
(der Betreiber-Weg kennt kein `inviteEmail`) und Handelnden-Rueckfall auf
`aYOUneInvites.sourceUser` (das Ereignis meldet keinen `sourceUserId`; ohne ihn
begaenne der Betreff mit einer Luecke — am Bestand belegt: 2 von 2 Betreiber-
Einladungen tragen `sourceUser`).

Zwei Proben lesen jetzt die BLOCKER-Zeilen im Quelltext: wird eine geaendert,
faellt die Probe und zwingt zur erneuten Messung, statt dass jemand den Eintrag
blind setzt. Umkehrproben: Vorarbeit ausgehebelt -> 2 rot, auth-Zeile geweitet
-> 1 rot. Volle Reihe 864/864.

Rest-Schnitt: queue/toPost/annahme-seite-nimmt-betreiber-einladung-nicht-an

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Die Bibliothek deklariert ihre Angular-Peers ab 2026.3.4 als optional, der
Express-SSR-Dienst zog sie bis dahin mit, ohne sie je zu laden. Gemessen:
985 -> 982 Lock-Eintraege, 25 MB weniger im Abbild, npm ci gruen (958 Pakete),
tsc-Bau gruen gegen einen Baum ohne jedes Angular-Paket.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`deferred` steht im AWAITING_ENUM, fehlt aber in BATCH_READY_AWAITING
(coord-admin.mjs:6716) — die sechs Briefe waren damit fuer den Kaskaden-
Kollektor UND den Grant-Waehler dauerhaft unsichtbar, obwohl ihr trigger
READY sagt und einzig der Fundament-Platz fehlt.

Fuer Fundament-Platz-Warter gab es nur zwei Etiketten, und BEIDE fuehren in
den Ausschluss: `foundation-slot` liegt ausserhalb des Enums (fail-closed),
`deferred` faellt aus BATCH_READY_AWAITING. Ein Brief dokumentiert den
vergeblichen Wechsel woertlich (knowledgebase-eigene-ki-aktionen-je-sammlung,
/resync 2026-08-18). Gehoben auf `dependency` — der Wert, der bei 32
Geschwistern nachweislich traegt.

Wirkung gemessen (foundation-batch --dry-run): 5 der 6 sind jetzt als
[core]/[field] IM Kollektor. Positiv-Kontrolle haelt: der echt geparkte
devopsalerts-entity-retire-candidate bleibt [awaiting-human] EXCLUDED, das
Tor ist also nicht pauschal geoeffnet.

Der sechste (rang2-restposten-zustandsfelder-fundament) bleibt draussen und
legt einen eigenen Befund frei: er beansprucht platform/interfaces+models,
traegt aber `foundation: false` — 11 Briefe liegen so, davon 7 mehrfach
zurueckgelegt. Nicht in diesem Commit behoben (Koordinations-Entscheid).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Der Zweit-Einstiegspunkt /core ist framework-frei, das Paket deklarierte seine
Angular-Peers aber ohne peerDependenciesMeta — npm installierte sie deshalb in
jeden Verbraucher. Gemessen an einem leeren Testpaket: 3 Angular-Eintraege plus
rxjs vorher, 0 danach.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`foundation-batch-cascade-65-fields` trug seit dem CEO-Einfalten in Kaskade 66
(2026-08-21) ein `superseded_by`, aber weiter `status: blocked`. `foundation-advance`
liest den STATUS, nicht das Feld — der Brief meldete sich damit als
"Next-in-line (P1, 8-14 h)", obwohl sein Inhalt in 66 geliefert ist.

- status blocked -> superseded (Vorbild: Kaskade 67, die es korrekt traegt)
- echter Next-in-line jetzt: core-updateone-wickelt-404-in-500 (P1)

Gefunden durch CEO-Rueckfrage im /resync-Tick, nicht durch einen Waechter.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`pl-grant` steht NICHT im kanonischen Vorrat (`ceo-decision | ceo-verification |
user-input | operator-action | hardware | dependency | deferred | dedicated-session |
none`). Der Pruefer sagt dazu woertlich: „ein Wert ausserhalb macht ihn fuer JEDE
Automatik unsichtbar" — die drei Briefe waren also weder claimbar noch befoerderbar.

🔴 ZWEI DAVON SIND MEINE, aus derselben Sitzung (Iteration 5, 2026-08-22): ich hatte
den Wert aus dem BESTAND abgeschrieben (`grep` zeigte ihn an einem vorhandenen Brief),
statt den Kanon zu pruefen. Genau die Fehlerklasse „vom Bestand abschreiben statt die
Regel lesen" — der vorhandene Brief trug denselben Fehler.

Korrigiert auf `awaiting: none`, und das ist gemessen, nicht geraten: der
Fundament-Grant laeuft ueber `foundation: true` plus den Grant-Mechanismus, NICHT ueber
`awaiting`. Die Verteilung der `foundation: true`-Briefe in `blocked/` bestaetigt es —
26x `dependency`, 11x `none`, 11x `deferred`, 1x `trigger`; kein einziger nutzt
`awaiting` als Grant-Tor.

Wirkung belegt: `ensure-worker-prompt` meldete fuer beide vorher
`awaiting-not-in-enum … nichts angefasst`, danach `already complete (no-op)`.

⚠ NICHT MITKORRIGIERT, bewusst: drei weitere Briefe tragen `awaiting: trigger`
(ebenfalls nicht im Kanon). Dort ist die richtige Ersetzung NICHT eindeutig —
`deferred` und `dependency` bedeuten Verschiedenes, und die Wahl aendert die
Einreihung. Das gehoert gelesen, nicht geraten:
`codingjobs-lebenszyklus-routen-und-cli-stilllegen`,
`codingjobs-strukturell-entfernen`, `deployment-health-severity-wirkung-nachmessen`.

Der Melder schrieb fuer JEDEN fehlenden Publish „die Kette meldet gruen, geliefert
wird nichts". Bei `ayoune-google-ads-client` meldete gar keine Kette etwas
(`pipelines_config` 404, 0 Laeufe). Der Satz beschrieb also einen anderen Zustand als
den vorliegenden — und schickte den Folge-Auftrag in die falsche Richtung: er suchte
den Fehler im `|| echo` des Publish-Schritts, waehrend der Schritt nie ausgefuehrt
worden war. ⚠ Diese Vermutung stammte aus MEINEM eigenen Brief; sie war nie gemessen.

Ueber zehn Bibliotheken gemessen: 5 mit eingeschalteter Kette, 4 OHNE Kette und
trotzdem veroeffentlicht (von Hand), 1 ohne Kette und ohne Paket. Die Haelfte hat gar
keine laufende Kette — und das ist offenbar in Ordnung.

Getrennt wird jetzt die URSACHE, nicht die Schwere: die Befund-Klasse bleibt
`paket-fehlt` (Ausstiegs-Vertrag unveraendert, beide Faelle faerben rot), dazu kommt je
Fund ein Feld `chain` und ein eigener Satz. Die Klassen-UEBERSCHRIFT ist jetzt
ursachen-NEUTRAL — der alte Satz steht nur noch dort, wo er zutrifft.

🔴 DREI BEFUNDE UEBER DAS EIGENE WERKZEUG, alle beim Verify aufgefallen:

1. `--registry` war fuer SCOPED Pakete WIRKUNGSLOS. Gemessen:
`npm view @tolinax/ayoune-http --registry https://registry.npmjs.org` liefert
`2026.1.0`, weil `npm config get @tolinax:registry` auf `registry.ayoune.app` zeigt
und eine scope-spezifische Registry ueber `--registry` GEWINNT. Gegenprobe im selben
Lauf: `npm view express --registry …` greift. Der Schalter war also fuer genau die
Pakete blind, fuer die dieser Waechter gebaut ist — und haette jeden Gegen-Lauf
gegen ein anderes Register still verfaelscht. Behoben ueber `npmViewArgs`, das den
Scope aus dem Paketnamen ableitet und `--@scope:registry=` mitgibt (3 Proben).

2. Die 404-ZWEIDEUTIGKEIT: Bitbucket antwortet auf `pipelines_config` mit 404, wenn die
Kette nie eingeschaltet wurde UND wenn es das Repositorium gar nicht gibt. Aus dem
404 allein folgt „nie eingeschaltet" NICHT. Geloest OHNE dritten Abruf: der
Publish-Durchgang laeuft per Bauart nur ueber lokal existierende Verzeichnisse, die
Existenz ist dort belegt und wird durchgereicht. ⚠ Ein erster Anlauf fragte sie per
API nach — und machte aus einem korrekten `kette-nie-gelaufen` ein `unbestimmt`,
sobald jene Abfrage aus einem anderen Grund als 404 fehlschlug. Eine Probe, die
scheitern KANN, darf eine belegte Tatsache nicht ueberschreiben.

3. Der Status-Regex stand als `/API (d{3}) /` statt `\d{3}` in der Datei (der Backslash
ging beim Einsetzen ueber ein Heredoc verloren). Er traf damit NIE, `configStatus`
blieb null, und JEDER Befund fiel auf `unbestimmt` — die ganze Nachschaerfung war
still ausgehebelt, ohne dass eine Probe rot wurde. Die vorhandenen Proben pruefen die
reine Klassifikation; der Regex lag im netzabhaengigen Abruf. Jetzt als reine
`statusFromError` herausgezogen und mit 3 Proben festgenagelt. LEHRE: eine
Zeichenketten-Auswertung gehoert in eine reine Funktion, sonst ist sie per Bauart
ungeprueft.

VERIFY, live gegen Bitbucket (nicht per Fixture):
- `ayoune-google-ads-client` -> `kette-nie-gelaufen` (404 + size=0, unabhaengig gemessen)
- `ayoune-email-blocks` -> `kette-laeuft` (enabled=true, size=9)
- chainCounts zaehlt beide getrennt: {nie-gelaufen 1, laeuft 1, unbestimmt 0}
- Negativ-Kontrolle mit ungueltigen Zugangsdaten: der Melder laeuft durch, meldet den
Registry-Befund und behauptet KEINE Ursache (`unbestimmt`), Ausstieg unveraendert.

Proben +21 (I Ursachen-Klassen · J Registry-Schalter · K 404-Zweideutigkeit ·
L Status-Regex), 84/84 in dieser Datei gruen. Volle Paket-Reihe 4797/8 — dieselben acht
Bestandsfehler wie vor der Aenderung (4776/8 in Iteration 2 gemessen), also +21 Tests,
+21 pass, fail unveraendert: keine Regression.

🟢 NEBENBEFUND: `ayoune-google-ads-client` ist inzwischen VEROEFFENTLICHT — der Brief,
den dieser Waechter am 2026-08-22 erzeugt hat, ist abgearbeitet worden. Der Live-Beleg
oben laeuft deshalb bewusst

`checkHealth.ts:205` lautete `severity: unavailable > 1 ? 'critical' : 'warning'`.
Die Stufe hing damit an der ABSOLUTZAHL nicht verfuegbarer Instanzen statt am
Verhaeltnis zur Sollzahl - in beide Richtungen falsch, beides an echten Alarmen
gemessen (Fenster 2026-08-15..22, Sammlung `alerts`):

- Falsches critical: 636 von 688 kritischen `deployment_failed` trugen
`availableReplicas > 0`, liefen also weiter. Spitzenreiter sind drei
Ein-Instanz-Laeufer, bei denen "0 verfuegbar" der Normalzustand jedes
Neustarts ist (368 + 149 + 54 Alarme).
- Verpasster Totalausfall: ein Ein-Instanz-Dienst, der ganz ausfaellt, zeigt
`unavailable = 1` und war damit nur `warning` - niedriger eingestuft als das
harmlose Neuausrollen des Nachbarn.

Neu: `helpers/deploymentOutage.ts` haelt das Urteil EINMAL (rein, AY-frei) -
`outageScope` (full/partial/none) plus der aus `syncCluster` hierher gezogene
`deploymentHealthStatus`. Beide Regeln standen an getrennten Stellen und sind
genau deshalb auseinandergelaufen.

Karenz gegen Ausroll-Rauschen ueber den BESTEHENDEN Aufschlag des geteilten
Schreibers (`upsertAlert.escalateAfterMs`), kein neuer Mechanismus: ein
Totalausfall startet als `warning` und wird `critical`, sobald er die Karenz
(Vorgabe 10 min, `DEPLOYMENT_OUTAGE_CRITICAL_MINUTES`) ununterbrochen steht.
Gemessen trennt das sauber: von 1.960 Alarmen mit `availableReplicas = 0`
standen 1.934 (98,7 %) genau EINEN Takt, 25 laenger als drei Stunden, genau
einer dazwischen.

Zwei Praemissen des Auftrags korrigiert:
- `syncCluster.ts:81` (readyReplicas === 0) und `availableReplicas === 0` sind
NICHT dieselbe Regel - 430 Alarme ueber 33 Dienste tragen ready=1 bei
available=0. Fuer die Stufe gilt `availableReplicas`, weil
`escalationGate.decideEscalation` genau dieses Feld fuer sein FULL OUTAGE liest.
- Die vorgeschlagene Regel ALLEIN haette die Lage verschlimmert: sie macht aus
1.908 heutigen Warnungen kritische Alarme (Ein-Instanz-Neustart). Erst die
Karenz dreht das um. `status.updatedReplicas` geprueft und nicht gebaut -
ohne Zusatznutzen neben der Karenz.

Proben: `test/deploymentOutage.test.ts`, die vier Faelle des Verify-Gates plus
Karenz, Zahl-Lesung und Verhaltensgleichheit des Gesundheitszustands. Die
abgeloeste Regel steht als `legacySeverity` daneben, damit der rote Gegenpart im
selben Lauf entsteht. Flip-Probe gefahren: mit der alten Regel an derselben
Stelle fallen 11 Proben, die uebrigen 355 bleiben gruen. `npm test` 366/366.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

GEMESSEN, nicht abgeleitet: nach der Ausbringung von 0.1.9 landeten BEIDE Repliken
von ayoune-updates-develop-node auf demselben Knoten (fp7m), waehrend heartbeats im
selben Lauf sauber auf zwei Knoten verteilte. Gegenprobe: das Loeschen einer der
beiden updates-Repliken liess den Ersatz-Pod auf einem ANDEREN Knoten (fny8) starten
- der Mechanismus greift also, nur nicht waehrend eines Rollouts.

Ursache: der labelSelector der Spreizung (name/instance/app) trifft auch die Pods der
ALTEN Fassung. Waehrend eines Rollouts zaehlen die mit, die Schiefe wird gegen den
falschen Bestand gerechnet, und mit dem weichen ScheduleAnyway kann die Wertung dann
zugunsten eines einzelnen Knotens ausfallen.

matchLabelKeys: [pod-template-hash] beschraenkt die Zaehlung auf dieselbe Fassung
(stabil seit K8s 1.30, Cluster faehrt 1.35). Umkehrprobe gefahren: der API-Server
liefert das Feld im Objekt zurueck, verwirft es also nicht still.

Ein-Replikat-Render bleibt gegen 0.1.7 identisch (ausser dem Fassungs-Etikett);
leere matchLabelKeys-Liste laesst das Feld ersatzlos entfallen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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>

Der Vor-Commit `8c7d7ed` brachte die Kette zu Fall, und beide Waechter hatten recht:

1. `germanUmlautHygiene` — die Kurzbeschreibung des neuen Zustands trug „pruefen"
und „uebernehmen" statt „prüfen"/„übernehmen". Der Waechter liest die
einfach-gequoteten Zeichenketten der Seeder (Kommentare vorher entfernt) gegen
die geteilte Stamm-Liste `@tolinax/ayoune-umlaut-stems`.
2. `registerStates.test.ts` — der Drift-Sentinel steht per Bauart auf einer festen
Zahl; ein neuer Zustand IST die beabsichtigte Abweichung. 89 -> 90, mit der
Herleitung in der Zeile wie bei allen Vorgaengern.

🔴 Die Lehre, nicht der Fix: `npm run build` war gruen und hat NICHTS davon
gesehen. Beide Waechter haengen an `npm test`, und genau der wurde vor dem Push
nicht gefahren. Die repo-eigene Testreihe ist vor dem Push Pflicht, nicht der Bau.

Der Umlaut-Waechter ist damit an der Sache selbst als beissend belegt — er hat den
Fehler in Kette #219 real gefangen, nicht in einer gestellten Probe.

Testreihe jetzt: 44/44 Suites, 726/726 Proben gruen.

Gemessener Ausgangszustand (2026-08-22): POST /api/playground/proxy war OHNE
Anmeldung nutzbar, OHNE Rate-Begrenzung, OHNE Zeitlimit und OHNE Groessen-Deckel,
und liess JEDE .ayoune.app-Unterdomaene zu — su-api (Superuser/godfather, laut
Wurzel-CLAUDE.md ausdruecklich nie aus Kunden-Clients), credentials-api
(Zugangs-Tresor) und registry (private Paket-Registry) eingeschlossen. Der
Weiterleiter verbarg dabei die Herkunfts-Adresse des Aufrufers hinter der
Pod-Adresse.

Der Riegel liegt in der REINEN Funktion checkPlaygroundTarget (kein Express,
kein Netz, kein Zustand) — nur so ist er ohne laufenden Dienst pruefbar:
- Sperrliste privilegierter Wirte, ausgewertet VOR der Nachsilben-Pruefung
(sonst faellt su-api durch das -api-Muster wieder herein)
- Anmeldedaten in der Adresse abgewiesen (verschiebt, was ein Mensch LIEST,
ohne zu aendern, wohin die Anfrage GEHT)
- ausdruecklicher Port abgewiesen (sonst Port-Abtaster fuer alles unter der
Nachsilbe); der Regel-Port bleibt erlaubt
- Rate-Begrenzung 20/min je Herkunft ueber das vorhandene checkRateLimit
- Zeitlimit 10 s und Antwort-Deckel 512 KiB; redirect manual, weil eine
Umleitung aus einem erlaubten Wirt einen gesperrten machen koennte, NACHDEM
die Pruefung gelaufen ist

Verify: npm run build Ende 0 / 0 TS-Fehler; neue Reihe 19/19; volle Reihe des
Repositoriums 1632/1632, 0 Fehler. Die Reihe traegt drei FLIP-PROBEN, die die
alte Regel woertlich nachbauen und belegen, dass sie genau diese Faelle
durchliess — samt Gegenkontrolle, dass das regulaere Ziel crm-api.ayoune.app
bei BEIDEN Regeln durchgeht, der Playground also nicht gebrochen ist.

Brief: api-lieferwege-playground-und-livemap (Punkt 5).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2uHkCzw3A1XWKSCf6c7JF

Ursache am Bestand gemessen: ayouneusers traegt username_1 als unique OHNE
sparse/partialFilterExpression, und der EINE erlaubte Platz ohne Wert ist seit
dem 2026-07-12 belegt (1 von 200 Zeilen). Die Route legte ohne username an, also
scheiterte JEDE Anlage — zweimal 500 ohne Datensatz, gemessen 2026-08-22.

Neu: deriveUsername leitet deterministisch ab (Adresse, sonst Adresse+Mandant,
sonst zaehlend) und scheitert laut statt still. Zusaetzlich antwortet die Route
auf einen Schluessel-Konflikt jetzt mit 409 statt 500. 8 Proben inkl. zwei
Negativ-Kontrollen.

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.

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.

Verify: 16 Proben gruen, `npm run build:stage` Exit 0 inkl. Schrift-Check.

`IEmployee.gender` stand im Vertrag und erreichte den Prompt-Bau nie — er las
ausschliesslich `appearance`. Drei von sechs erzeugten Portraets trugen daraufhin
das falsche Geschlecht ("Tobias Kern" als Frau, CEO-Sichtbefund 2026-08-22). Der
Fehler war STILL: kein Fehlschlag, kein Protokolleintrag, nur ein falsches Bild.

- `PortraitSubject.gender` (`m|w|d|x`, 1:1 der Vertrag) + Satz im Prompt
- `d`/`x` behaupten bewusst NICHTS — aus ihnen folgt kein Bild-Merkmal
- fehlt das Feld, wird aus `appearance` abgeleitet (de+en, WORTGRENZEN:
"woman" enthaelt "man"); nennt der Text beide, wird nichts abgeleitet
- schweigen beide Quellen: `PortraitGenderUnknownError` statt Ratewurf,
im Router als 422 mit echter Meldung statt 502 "bitte erneut versuchen"
- der Aufrufer reicht `employee.gender` aus der Akte durch (die fehlende Zeile)
- `buildStylizePrompt` bleibt BEWUSST ohne Geschlechts-Satz: beim Angleichen
fuehrt das Foto, ein widersprechendes Feld erzwaenge den Gesichts-Tausch,
den PORTRAIT_IDENTITY_CLAUSE verbietet
- `portraitSeed` unberuehrt — die Szenen-Wahl darf sich nicht verschieben,
wenn jemand ein Geschlecht nachtraegt

Proben: 915/915 gruen (13 neue, mit Umkehr- und Negativ-Kontrollen).
Gegenprobe am gebauten dist fuer m / w / leer / leer+Freitext / d / Angleichung.

Brief: portraet-erzeuger-liest-das-geschlecht-nicht

Der Socket-Ruf des Servers war der einzige Abonnent der Kiosk-Einstellungen —
`KioskSettingsService.applied$` (die HTTP-Antwort des eigenen Schreibvorgangs)
hatte flottenweit null Abonnenten. Der Socket-Ruf ist aber best-effort: der Server
schluckt jeden Fehler (config-api lib/kioskDeviceSettings.ts:169-173) und antwortet
trotzdem mit 200. Ist der Melder nicht erreichbar oder das Geraet gerade nicht im
Raum controlpanel:<id>, blieben Kopfleiste, Ton-Politik und Stumm-Riegel bis zum
naechsten Neuladen auf dem alten Stand.

- applied$ abonniert, mit feedPanel=false (das Panel kennt den Wert aus seiner
eigenen save()-Antwort; ein Rueckfluss ueber external$ waere eine zweite
Zuweisung desselben Wertes)
- 9 Proben: Kopplungswirkung, Panel-Rueckfluss-Schalter, Fern-Weg unveraendert,
Geraet ohne Alarm-Anzeige, leerer Satz, plus die Bibliotheks-Kettenhaelfte gegen
die echt installierte Lib (voller Server-Satz, Weg-Trennung, Fehlerfall)
- angular.json: die neue Spec in die explizite include-Liste (ohne den Eintrag wird
eine Spec-Datei hier NIE eingesammelt und laeuft still gar nicht mit)

Verify: Bau gruen (Application bundle generation complete), 188/188 Proben gruen,
Flip-Probe beisst (Schalter ausgehebelt -> genau die Schalter-Probe rot).

Bis hierher verwarf ein Rumpf mit leerer ALLOWED_FIELDS jedes Rumpf-Feld,
schrieb nur noch `_id` und antwortete 200 mit dem unveraenderten Dokument —
fuer den Aufrufer von Erfolg nicht zu unterscheiden. Genau dieses Bild hat
den Etikettendruck der Lagerplaetze sieben Wochen lang stillgelegt.

Der leere Vorgabewert bleibt RICHTIG (fail-closed; der Erzeuger kann die
Felder einer Aktion gar nicht kennen). Geaendert ist, was der Rumpf damit tut.

- 422, nicht 501: 501 hiesse „nicht auf diesem Wirt" und trifft nicht zu; die
Aktion IST zustaendig, sie hat nur keinen Rumpf. Vorbild: die dreifach im
Bestand umgesetzte `refuseUnimplementedAction` (hr/config).
- Der Sammel-Zweig behaelt sein 501 — dort ist die ADRESSE unbedienbar.
Reihenfolge test-gepinnt: 501 greift VOR 422.
- Kein Schalter, kein Opt-out: sobald ein Feld opt-in ist, faellt der Zweig
weg und der Pfad laeuft unveraendert.
- Die Kopf-Prosa beider Varianten nachgezogen; die emits-Variante sagt
ausdruecklich, dass auch KEIN Ereignis mehr feuert (die Verweigerung greift
vor dem Ereignis-Block).

Belege: echter Erzeuger-Lauf gegen cms/WebPages in einem Wegwerf-Ziel, der
erzeugte Rumpf gelesen UND uebersetzt (npm run build Exit 0), danach voll
zurueckgenommen (Arbeitsbaum sauber, Aktions-Verdrahtung 1 -> 2 -> 1).
11 neue Proben inkl. Kontrollfluss-Nachbildung und Flip (ohne die Wache 6 rot).
Volle Reihe 4709/4717 — die 8 roten sind vorbestehend und beidseitig belegt.

⚠ first-write-wins: wirkt NUR auf kuenftige Stuempfe, die 146 Bestands-
Fundstellen bleiben unveraendert. Der Melder zaehlt einen verweigernden Rumpf
weiter — gemessen und richtig: er misst Funktionslosigkeit, nicht Stille.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`incrementalSync` schrieb `consumerVisible: source.consumerVisible || false`,
waehrend sein Zwilling `structuredDataChunker.ts:125` seit dem 2026-05-26
(`758d69e`, "wiki-internal leak fix") den Riegel `&& doc.internal !== true`
traegt. Der Abgleich ist der LAUFENDE Schreiber (alle 30/60/120 min je Quelle):
eine interne Wiki-Seite, die nach der Erst-Indizierung bearbeitet wurde, lief
durch den Weg ohne Riegel und wurde dabei endkunden-sichtbar.

Gemessen (Produktion, rein lesend, 2026-08-22): 18 von 18 Wiki-Seiten mit
`internal: true` haben endkunden-sichtbare Abschnitte — 46 aktive Abschnitte
ueber zwei Mandanten, kein einziger korrekt verborgen. Alle 18 Seiten sind
NACH der Haertung des Zwillings entstanden (aelteste 2026-07-22), die Ursache
ist also dieser Weg und nicht Alt-Bestand. Direkter Beleg: Seite
6a82e86536b34963d60a2b78 traegt `internal: true` seit 11:53:54Z, ihr Abschnitt
wurde am 2026-08-18T12:30:04Z neu geschrieben — sichtbar.

Zweiter Zwilling geprueft: die Objekt-Literale sind sonst feldgleich. Die
Abweichung bei `_customerID` ist begruendet (globale Quellen erben den Stempel
des Rebuilds, incrementalSync.ts:51-70), also kein zweiter Befund.

⚠ Der Bestand heilt hierdurch NICHT: beide Zwillinge ueberspringen Abschnitte
mit unveraendertem `textHash`, und der Schluessel enthaelt `consumerVisible`
nicht — eine reine Flag-Aenderung loest also weder hier noch im Rebuild ein
Neuschreiben aus. Die 46 brauchen einen eigenen Korrektur-Lauf; Abbild liegt
unter .claude/reports/rueckroll-abbilder/.

Verify: Flip-Probe gegen den gebauten Ausdruck beidseitig (internal:true unter
sichtbarer Quelle true→false), zwei Negativ-Kontrollen unveraendert (ohne
`internal` bleibt sichtbar; Quelle consumerVisible:false bleibt unsichtbar),
6/6 gruen; Ausdruck jetzt identisch mit dem Zwilling; Regression 29/29.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015yTiSkb8SH9siwzkjmMDHT

The freshness hint at coord claim treats any non-exact pin as "kein exakter Pin"
and recommends --pin-exact for it — correct for normal consumers, but wrong for
the six shared libraries (ayoune-theming, ayoune-device-shell, comm-sidebar,
notifications, permission-editor, communicator) that CLAUDE.md's transitional
override explicitly keeps on ranges until the deployment-plan bump_dependency
step carries them along. Following the hint there creates a second Foundation
resolution at their consumers (measured 2026-08-02, 11 affected pairs).

TRANSITIONAL_RANGE_LIBS excludes exactly those six from the hint; everything
else is unaffected (flip-probe-verified, gegenprobe for a 7th unlisted lib).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Am laufenden Dienst gefunden, nicht am Reissbrett: nach dem Abschluss
eines Durchgangs fiel der Stand bei der naechsten Antwort kommentarlos
von 2/2 auf 1/2 zurueck. Ursache ist ein NEUER Ergebnis-Datensatz —
richtig im Ergebnis (Exams.retries sieht Wiederholungen vor), aber
unangekuendigt und ohne Deckel.

Drei Maengel behoben:

1. `retries` wird geprueft. Die Lesart ist ausdruecklich festgeschrieben:
retries sind die WIEDERHOLUNGEN, der erste Durchgang zaehlt nicht dazu
(retries:2 = drei Durchgaenge). Der Vertrag sagt es nicht, und beide
Lesarten sind vertretbar - wer sie anders liest, deckelt um eins
daneben. Aufgebraucht -> 409 versuche-aufgebraucht.

2. Der NEUESTE Versuch bestimmt den Stand. Liste und Detail sortierten
nicht; bei mehreren Ergebnis-Datensaetzen war unbestimmt, welcher den
Stand liefert - die Uebersicht zeigte je nach Fund-Reihenfolge der
Datenbank mal den alten, mal den neuen.

3. Die Antwort meldet `neuerVersuch`, damit die Oberflaeche den
Ruecksprung erklaeren kann statt ihn geschehen zu lassen.

Dabei von der Testreihe eine Null-Falle gefangen: Number(null) ist 0,
nicht NaN - ein nicht gesetztes `retries` haette den Deckel still auf
EINEN Durchgang gesenkt statt auf den Vorgabewert zu fallen.

69 Tests, Flip-Probe auf den Deckel gefahren.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Drei CEO-Befunde der Runde vom 2026-08-22, zwei davon aus EINER Ursache.

1) Stumm-Knoepfe antworteten „until fehlt" und haben nie eine Stummschaltung
angelegt. GEMESSEN sass der Fehler auf der CLIENT-Seite: der bibliothekseigene
Anbieter schickte eine DAUER (`minutes`), der Vermittler verlangt einen
ZEITPUNKT (`until`, buildSnoozeDoc in @tolinax/ayoune-core). Die einzige andere
Bindung (clients/desktop-client) rechnet seit jeher korrekt um -- ein „Fix" am
Vermittler haette sie mitgerissen und eine zweite Drift erzeugt.

2) Weisser Grund im Dunkeln UND Fremd-Rahmen im Hellen sind EIN Fehler: dem
Akustik-Fenster (seit 2026-08-21) fehlte sein [popover]-Ruecksetz-Block, also
schlug das Browser-Blatt durch (`background-color: Canvas`, `border: solid`).
Der Block existierte fuer die fuenf aelteren Top-Layer-Flaechen.

3) Quittieren war rot und teilte sich die Zeile mit den drei Stumm-Knoepfen.
Jetzt eigene Zeile, volle Breite, 60px hoch, Farbe aus --brand-primary.
Der rote Rahmen der Karte BLEIBT -- er zeichnet den Alarm, nicht die Handlung.

Karte, Innentexte und Stumm-Knoepfe ziehen gegen --brand-background/--brand-text
(bisherige Werte als Rueckfall), damit ein heller Mandanten-Anstrich traegt.

Proben: 8 zum Rumpf-Vertrag + 10 zum Top-Layer (als REGEL ueber alle Flaechen aus
dem Bauplan, nicht als Einzelfall), je mit Positiv-Kontrolle und Umkehrprobe,
beide flip-geprueft. Volle Reihe gruen.

Nicht enthalten: der vorgelesene Satz (CEO „Alerts created by System"). Er
entsteht in domains/config/worker-notifications/src/lib/alertTts.ts:101 aus
subject+body -- ausserhalb der beanspruchten Pfade dieses Auftrags.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Der von send-portal-invite geminteten Einladungs-Token wurde im KLARTEXT in
die Consumer-Zeile geschrieben. Wer die Datenbank lesen kann, konnte damit
jeden offenen Einladungs-Link uebernehmen (Passwort setzen = Konto-
Uebernahme). Dieselbe Fehlerklasse wie storeevent-persistiert-rohen-reset-
token (behoben 2026-08-20).

Neu: hashPortalInviteToken = sha256(token) hex; nur der Digest geht in die
Zeile. Der Roh-Token verlaesst diesen Prozess ausschliesslich in
setPasswordUrl, also in der Mail.

🔴 AUSBRINGUNGS-REIHENFOLGE, nicht optional: clients/consumer-app MUSS
ZUERST live sein. Sein Leser ist beidseitig (Hash zuerst, Roh-Wert als
Uebergangs-Rueckfall). Geht dieses Repositorium zuerst raus, schreibt es
Hashes, waehrend der alte Leser nur den Klartext kennt — jede neue
Einladung waere unaufloesbar, ohne Fehlermeldung.

⚠ ZWILLING: dieselbe Funktion liegt in
clients/consumer-app/src/routes/data-fetcher.ts, genau wie
mintPortalInviteToken schon vorher. Laufen sie auseinander, findet der
Nachschlag einfach nichts — kein Fehler, kein Protokolleintrag. Beide
Proben-Reihen nageln denselben fest verdrahteten Digest fest; das ist die
einzige Stelle, an der eine Abweichung auffaellt.

Die zwei bestehenden Proben, die verificationCode auf /^pi-/ pruefen, sind
auf den neuen Vertrag umgestellt — sie hielten das alte, unsichere Verhalten
fest und wurden von dieser Aenderung erwartungsgemaess rot (der Diff zeigte
den Digest an der Stelle des pi-Tokens). Fuenf neue Proben dazu.
22/22 gruen, tsc --noEmit Exit 0.

⚠ Scoped Commit: der Arbeitsbaum trug zugleich 227 fremde Dateien aus einem
laufenden Codegen-Lauf. Sie sind NICHT Teil dieses Commits.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Der einmal verwendbare Portal-Einladungs-/Reset-Token lag im KLARTEXT in
Consumers.verificationCode. Wer die Datenbank lesen kann, konnte damit jeden
offenen Einladungs-Link uebernehmen — Passwort setzen ist Konto-Uebernahme.
Dieselbe Fehlerklasse wie storeevent-persistiert-rohen-reset-token (behoben
2026-08-20); die Nutzer-Ebene (platform/auth password.ts) hasht laengst.

Neu: hashPortalInviteToken = sha256(token) hex. In der Zeile liegt nur noch
der Digest; der Roh-Token verlaesst den Prozess ausschliesslich in der
Mail-Adresse.

Reihenfolge ist tragend — der LESER kommt zuerst und ist beidseitig:
findConsumerByPortalInviteToken fragt ZUERST den Hash und faellt danach auf
den Roh-Wert zurueck, damit vor dem Umbau geminteten Einladungen einloesbar
bleiben. Der Rueckfall traegt ein Ablaufdatum im Kommentar (ENTFERNEN AB
2026-08-29 = Umbau-Tag + PORTAL_INVITE_TTL_MS); danach kann kein Roh-Token
mehr gueltig sein, weil inspectPortalInviteToken vorher abweist.

Bewusst OHNE pi-Praefix am Hash: ein reiner Hex-Digest kann per Bauart nicht
mit pi- beginnen, der Praefix bleibt damit die Trennung zum Telegram-
Anmelde-Wert in DERSELBEN Spalte. Gemessen 2026-08-22: 158 Zeilen mit
verificationCode, davon 2 mit pi-; die uebrigen 156 gehoeren Telegram und
werden nicht angefasst. Von den 2 war genau EINE noch innerhalb der
Lebensdauer (gesetzt 07:30Z), die andere 24 Tage alt und damit laengst
abgewiesen.

Kein Salz: der Token traegt 24 zufaellige Bytes, ein Woerterbuch-Angriff ist
gegenstandslos — und ein Salz machte den Gleichheits-Nachschlag unmoeglich,
den dieser Weg braucht.

portal-auth.ts ist NICHT angefasst: es ruft nur mint + set + find und
bekommt den Roh-Token weiterhin fuer die Mail-Adresse. Die Schichtung
stimmt damit von selbst.

8 neue Proben mit AY-Attrappe, die den WEG pruefen (welcher Wert im Filter
stand, in welcher Reihenfolge gefragt wurde) — nicht nur das Ergebnis.
Zwei Flip-Proben gefahren: Schreiber zurueck auf Klartext => 1 rot,
Lookup-Reihenfolge umgedreht => 2 rot, zurueck => 15/15. Volle Reihe 1574
gruen. Der fest verdrahtete Digest in der Probe ist derselbe wie in
crm-api — laufen die Zwillinge auseinander, wird eine Einladung
unaufloesbar, OHNE dass ein Fehler entsteht.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Der Dialog wurde mit autoFocus:false geoeffnet (brand-switcher.component.ts) --
deshalb blieb das Suchfeld am Kiosk leer, bis man hineintippte. Gemessen lag die
Ursache an der OEFFNUNGSSTELLE, nicht wie vermutet in der Dialog-Vorlage.

- brand-switcher: autoFocus 'first-tabbable' (beachtet [cdkFocusInitial])
- customer-switcher-dialog: Suchfeld traegt [cdkFocusInitial]
- Der Fortschritts-Dialog behaelt autoFocus:false (Spinner unter disableClose)
- Neue Testreihe (4 Proben) inkl. Umkehrprobe + Positiv-Kontrolle; flip-geprueft

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Der Vorab-Riegel von vault-change-password griff NICHT. Gefunden hat es erst
die Live-Probe: der Wechsel ging trotz eines vorhandenen Alt-Zugangs raus und
wurde vom SERVER mit 409 gestoppt — die Zusage "stoppt, bevor gesendet wird"
war damit gebrochen.

Ursache, am laufenden Dienst gemessen: die Antwort ist
{ payload: { data: [...] }, meta } — `payload` ist ein OBJEKT, kein Feld. Der
Code las `res.payload ?? res.data` als Liste, bekam ein Objekt, und
`Array.isArray(...) ? ... : []` machte daraus STILL eine leere Liste. Eine
leere Liste heisst hier "keine Alt-Bestaende", also: senden.

Zwei Fehler, nicht einer — und der zweite ist der teurere:
(a) falscher Pfad in die Antwort;
(b) eine unerwartete Form wurde als "nichts vorhanden" gelesen statt als
"nicht feststellbar". Genau die Fehlerklasse, gegen die dieser Riegel
steht.

Behoben: der gemessene Pfad zuerst, danach zwei ausdrueckliche Rueckfaelle —
und FAIL-CLOSED. Ist das Ergebnis keine Liste, bricht der Befehl ab, statt
weiterzumachen. Ebenso, wenn die Liste die Obergrenze (500) erreicht und
damit abgeschnitten sein koennte; `meta` traegt keine Gesamtzahl, mit der
sich das anders pruefen liesse.

Belegt: dieselbe Live-Probe stoppt jetzt VOR dem Senden, nennt den Zugang
namentlich (69fe8996e1772fc374ef1c86 "Rustdesk Public Key") und endet mit
Exit 2 statt mit dem Server-409. Drei neue Proben halten die gemessene Form,
die unerwartete Form und den Obergrenzen-Fall fest; die bestehenden Proben
sind auf die ECHTE Form umgestellt — sie hatten meine falsche Annahme
gespiegelt und deshalb gruen gemeldet.

Dazu: die Phrasen-Abfrage nimmt die Phrase nicht-interaktiv ueber die
STANDARDEINGABE (nie ueber ein Flag — das stuende in der Prozessliste), je
eine Zeile pro Abfrage. Der Leser wird je Befehlsaufruf erzeugt statt im
Modul gehalten; als Modul-Zustand teilten sich zwei Aufrufe im selben Prozess
einen bereits geleerten Vorrat.

23 Proben in dieser Datei; volle Reihe 1545 gruen / 3 uebersprungen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Erlaubt sind laut @tolinax/ayoune-workitem-quality genau: reuse | extend |
genuinely-new | verify. Der Validator hatte die drei Briefe deshalb als
reuse-check-missing gefuehrt.

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.

Das Gate lag ueber der Kappung: autopilot-safe.md §3.1A Pfad 1 rief das Skript
genau in dem Band auf, in dem es nichts tat. Einheit bleibt bewusst BYTES, der
Wert wird die Zeichen-Kappung — fuer UTF-8 gilt Buffer.byteLength(s) >= s.length,
also folgt aus der Aufruf-Bedingung (Zeichen > 24985) zwingend Bytes > 24985; das
Gate kann damit nie mehr ein No-Op sein, wenn sein Aufrufer feuert.

Herkunft auf decisions.log 2026-08-18 umgestellt (loest den 2026-07-01-Entscheid
ab, der die 30.000 setzte). Byte-Kommentar berichtigt: der System-Reminder misst
ZEICHEN, nicht Bytes (gemessen 25.436 Z = 24,84 KB gegen die gemeldeten 24.8KB) —
die alte Gleichsetzung war der Mechanismus der Drift.

Flip-Probe auf identischer Fixture (26756 B): alt no-op, neu -2285 B unter Limit.
Umkehr-Kontrolle (20000 B) weiterhin no-op. SIZE_FLOOR byte-identisch. Margin 512
bleibt: Ziel 24473 B erreicht mit 31 von 56 Kandidaten in Reserve, kein Thrash.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Die Curation loeste bei 30.000 Zeichen aus, die Harness kappt MEMORY.md aber
schon bei 24.985 und verwirft alles darueber STILL. Dazwischen lag ein Fenster
von rund 5.000 Zeichen, in dem der Index abgeschnitten geladen wurde, waehrend
jede Iteration gruen meldete. Gemessen war es besetzt: MEMORY.md = 25.297.

Vollzug des CEO-Entscheids decisions.log:5019 (2026-08-18), der in
memory-curator.md schon umgesetzt war und hier nicht mitgezogen wurde.

Die Brief-Tabelle nannte VIER Stellen, real waren es SIEBEN Vorkommen auf sechs
Zeilen plus die 30KB-Anzeige (zusaetzlich Zeile 338 und ein zweites Vorkommen in
Zeile 585). Aufgefallen ist es nur, weil das Verify-Gate grep -c '30000' => 0
verlangt statt 'die vier Zeilen'. Jede Fundstelle wurde vor dem Ersetzen im
Kontext geprueft; der historische Messwert 30.962 blieb unberuehrt.

Dazu je ein Absatz an 1b und 3.1A, der die Zahl ERKLAERT (Schmerzgrenze, nicht
Ziel) — sonst wandert sie beim naechsten Umbau zurueck.

Nebenbefund als Folge-Brief: scripts/memory-curator-daily.mjs traegt dieselbe
30000 als ausfuehrbares Gate (Phase B no-op bei 26.271 Bytes) und rechnet dabei
in BYTES statt Zeichen — ausserhalb der claim_paths und an einen aelteren
CEO-Entscheid gebunden, daher eigener Brief statt stiller Mitnahme.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Der Melder stufte allein nach locked gegen published ein und fragte nie, ob ein
Repositorium ueberhaupt ausbringbar ist — dieselbe Fehlerklasse, die CLAUDE.md
fuer die Pipelines-Zeile festhaelt (zaehlt Dateien, nie laufende Dienste).

Gemessen fuehrte er platform/internal als BEHIND: nie ausgebracht, nie eine Kette
gehabt, seit 2026-08-22 stillgelegt. Zwei belegte Schaeden — es entstand echte
Pflege-Arbeit daran (zwei Fundament-Pin-Commits am 2026-08-21 an einem
Repositorium ohne fachlichen Commit seit 2024-02-19), und --apply haette eine
Kette ausgeloest, die es gar nicht gibt.

Ein Repositorium mit RETIRED*.md im Wurzelverzeichnis faellt jetzt VOR der
Einstufung heraus — damit zugleich aus BEHIND, aus BEDINGT und aus der
Modul-Zaehlung. Es wird als eigene Zeile AUSGEWIESEN, nie still verschluckt
(ein unsichtbarer Ausschluss waere dieselbe Fehlerklasse in der anderen
Richtung); die JSON-Form traegt es ebenfalls.

--apply ist damit MITgehaertet und braucht keinen zweiten Waechter: die
Ausloese-Menge faellt ueber vier filter-Stufen aus derselben Liste, wer aus ihr
faellt, kann sie nicht erreichen. Eine Probe nagelt genau das fest.

Verify: Trockenlauf 24 -> 23 Kandidaten, platform/internal nur noch in der
Stillgelegt-Zeile, Negativ-Kontrolle domains/audit/api weiterhin drin. Neue
Probenreihe 7 Proben je Richtung; alle redeploy-Reihen 49/49.
Die 8 Fehlschlaege der vollen Reihe sind VORBESTEHEND — mit engem Rueckbau nur
dieser Datei nachgemessen: identische acht Titel auch ohne die Aenderung.

An der Flaeche widerlegt: das ausgebrachte Bedienpanel (App-Laufzeit
360 s) zeigt 'seit 13.08. 18:30 · vor 8d'. Ein acht Tage alter Ursprung
kann nicht aus dem Arbeitsspeicher stammen — der START-Weg
(app.component.ts:1388-1392) liefert die Vorkommens-Daten sehr wohl.

Die Suche, die zur falschen Praemisse fuehrte, war ein FALSCHES NEGATIV:
eine Namens-Suche kann einen generisch gebauten Umschlag nicht sehen.
Die Positiv-Kontrolle fing es nicht — sie belegte nur, dass die Suche
ueberhaupt trifft, nicht dass der Erzeuger seine Felder woertlich
hinschreibt.

Offen ist damit nur noch, ob der LIVE-Weg (Socket) sie ebenfalls traegt.

Am 2026-08-22 standen fuenf von sechs Alarmen dieses Melders 4,4 bis 4,6 Stunden
und wurden ausschliesslich von Hand geschlossen — jeder 2 bis 67 Sekunden nach
seiner eigenen Quittierung. Der Melder lief durchgehend und meldete fuer de_de
schon um 00:07:54Z wieder `queueStatus: ok` bei 236.603 wartenden Auftraegen.

Ursache der Klasse: `decideSymptom` loest ausschliesslich ueber den UEBERGANG
bad→gut auf. Geht dieser eine Uebergang verloren, steht der Alarm fuer immer,
und zwar lautlos — der Zustandsautomat nimmt danach den stillen Zweig
`gut + prevStatus !== "bad"` → `none`.

Neu: `decideStandingAlertSweep` loest ueber den ZUSTAND auf. Solange fuer eine
Kachel ein Alarm als offen vermerkt ist und die Lage HEUTE gut und beurteilbar
ist, wird aufgeloest — unabhaengig davon, ob der Uebergang je erkannt wurde.
Der Marker faellt dabei, der Weg feuert also genau einmal je Episode.

- eigenes Feld `SymptomState.openAlert`, BEWUSST keine Umdeutung von
`lastAlertAtMs` (das traegt die Melde-Daempfung und wird von
checkCrawlSuccessRate mitbenutzt) — `decideSymptom` bleibt unveraendert
- kein Ruhe-Fenster-Aufloesen: `judgeable` ist Bedingung
- nachgeholte Aufloesungen loggen als `warn`, nicht `info` — sie heissen, dass
der regulaere Weg versagt hat
- Waechter test/crawlStandingAlertSweep.test.ts (G1 Wiedergabe des echten Falls,
G2 Flip-Probe, G3 Positiv-Kontrolle de_ch inkl. keine Doppel-Aufloesung)

Der Bau war rot, seit `tsc || exit 0` entfernt wurde. Ohne `include` greift das
Vorgabe-Muster `**/*` und zieht test/jobEventBuffer.test.ts + test/jobRegistry.test.ts
in den Haupt-Bau — beide liegen ausserhalb von rootDir './src' (TS6059).

Die Testreihe hat ihr EIGENES tsconfig.test.json (rootDir '.', outDir './.test-out')
und ueberschreibt `exclude` vollstaendig, laeuft also unveraendert weiter. dist und
.test-out sind Bau-Ergebnisse und faenden sich sonst beim naechsten Lauf selbst als
Quelle wieder.

Kein @ts-ignore, kein || exit 0, kein noEmitOnError-Aequivalent.
Verify: npx tsc --noEmit 0 Fehler - npm run build Exit 0 - npm test 60/60 gruen -
dist-Struktur unveraendert (dist/server.js liegt weiter obenauf, Einstiegspunkt intakt).

Der Bau war rot, seit `tsc || exit 0` entfernt wurde — 10 Uebersetzungsfehler,
alle TS2339 in jobs/generateVideo.ts an zwei gleichlautenden Stellen.

Der Code baut einen `Documents`-Datensatz, setzt darauf aber fuenf Felder, die zu
`IImage` gehoeren: _productID, _productGroupID, _productDivisionID, _publicationID,
_filename. Gemessen: 0 Treffer in Vertrag UND Schema von Documents, je 1 Treffer in
IImage; Positiv-Kontrolle (originalname/mimetype/linktype/isCloudFile) 1/1, Umkehr-
probe mit erfundenem Feld 0. Der Block stammt aus einem Bild-Upload-Pfad.

Mongoose `strict` hat alle fuenf beim Speichern die ganze Zeit STILL verworfen — der
Riegel verdeckte also nicht nur einen roten Bau, sondern eine tote Schreiboperation.
Es geht nichts verloren: die vier Verweise wurden ohnehin nur auf null gesetzt, und
_filename trug denselben Wert wie originalname, das echte Feld des Vertrags, das eine
Zeile weiter unten gesetzt wird.

Kein @ts-ignore, keine Fundament-Kaskade (nichts fehlt im Vertrag - das Feld gehoert
an eine andere Entitaet).
Verify: npx tsc --noEmit 0 Fehler - npm run build Exit 0 (20 .js emittiert).

Der Bau war rot, seit `tsc || exit 0` entfernt wurde — 22 Uebersetzungsfehler, alle
in runBrowserAutomation.ts. Zwei getrennte Defekte:

1. Die Arbeits-Handles waren als ClosableBrowser/ClosablePage deklariert. Das sind
die NARROW Cleanup-Vertraege (nur close()/process()), damit closeBrowserSafely
ohne echtes Chrome testbar bleibt — kein Ersatz fuer die volle puppeteer-API.
Jeder Schritt-Aufruf (newPage, goto, $$eval, screenshot, ...) war dadurch ein
TS2339. Jetzt Browser/Page aus puppeteer; die erfuellen den Cleanup-Vertrag
strukturell an den closeBrowserSafely-Aufrufstellen.

2. ClosableProcess.kill(signal: string) war in KEINER Richtung zu einem echten
ChildProcess.kill (signal?: NodeJS.Signals|number) zuweisbar — number ist kein
string. Ein echter Browser erfuellte ClosableBrowser also gar nicht (TS2322),
entgegen dem eigenen Kommentar der Datei. Jetzt string|number: echter
ChildProcess UND die Testattrappen (kill: (sig: string)) passen, ohne Node-
oder puppeteer-Typen in den bewusst abhaengigkeitsfreien Helfer zu ziehen.

Kein @ts-ignore, kein || exit 0, kein noEmitOnError-Aequivalent.
Verify: npx tsc --noEmit 0 Fehler - npm run build Exit 0 (9 .js emittiert) -
npm test 49/49 gruen.

Der Vorlagen-Fix 74b04f2150 (2026-08-21) hat `getMany.ts.tpl` an ihre Schwester
`list.ts.tpl` angeglichen: statt der fest verdrahteten Felder name/title/subject
liest sie jetzt die am Modell deklarierten `searchableFields`. Der Commit fasste
GENAU EINE Datei an — kein Modul wurde danach neu erzeugt. Dieses Modul ist der
erste nachgezogene Konsument.

GEMESSEN statt geschaetzt (eigene Messung 2026-08-22, gegen interfaces 2026.448.1):
ueber die 18 Module mit erzeugten Lese-Routen wuerden sich 109 getMany- und 70
list-Handler bewegen; 17 Entitaeten sind hand-gehaertet und bleiben unberuehrt.
marketing allein stellt 109 dieser Bewegungen — der Modul-Lauf hat 110 Dateien
geaendert.

⚠ DIE ERSTE MESSUNG WAR EINE FALSCHE NULL, und sie ist hier festgehalten, weil sie
die naechste Messung genauso treffen wuerde: hand-gehaertete Handler bauen ihr `$or`
aus `SEARCH_FIELDS.map(...)` statt als Literal-Block. Ein Muster, das nur den
Literal-Block liest, meldet fuer sie eine LEERE Feldliste — also weder einen Treffer
noch einen Fehler. marketing sah dadurch nach 2 betroffenen Entitaeten aus statt 69.

ZWEI BEKANNTE NEBENWIRKUNGEN DES MODUL-LAUFS: beide gemessen, keine eingetreten.
Aktions-Verdrahtung `use('/:id/actions'` 1 -> 1 Datei. Testdateien unter
routes/default/__tests__ 1 -> 1, keine Loeschung im Diff. EXPECTED_MOUNT_COUNT
bleibt 72 (der Waechter ist gruen, es kam keine Route dazu).

PROBEN AUF DAS NEUE VERHALTEN GEHOBEN, nicht nachgezogen: 78 Proben in 41 Reihen
nagelten den ALTEN Zustand fest. Sie behaupten jetzt die aus `modelsAndRights`
ABGELEITETE Feldliste (`src/lib/testing/searchableFields.ts`), nicht eine von Hand
abgeschriebene — eine Probe, die die Implementierung spiegelt, belegt nichts. Die
Ableitung wirft bei einem unbekannten Plural, damit ein Tippfehler nicht still auf
den Rueckfall laeuft.

NEUER MODUL-WAECHTER `searchableFieldsParity.guard.test.ts` (7 Behauptungen,
statisch, ohne AY-Start): jeder erzeugte getMany-Handler gegen die Deklaration,
jeder list-Handler gegen seinen getMany-Zwilling, UMKEHRPROBE an LoyaltyPoints
(einzige marketing-Entitaet ohne Deklaration -> exakt der Rueckfall), GEGENPROBE
dass keine deklarierte Entitaet auf dem Rueckfall steht, plus die namentliche Liste
der 15 hand-gehaerteten Entitaeten (eine stille Haertung faellt damit auf).

FLIP-PROBE GEFAHREN: ein Handler kuenstlich auf den Rueckfall zurueckgesetzt ->
GENAU DIE DREI tragenden Behauptungen fallen, die vier Kontrollen bleiben gruen;
nach dem Zuruecksetzen wieder 7/7. Der Waechter beisst also wirklich.

⚠ Der Haertungs-Marker taugt NICHT als Erkennungsmerkmal: die Vorlage zitiert die
Zeichenkette `HAND-HÄRTUNG` selbst in einem Anleitungs-Kommentar, jede erzeugte
Datei enthaelt sie. Erkannt wird an der zeilen-verankerten `const SEARCH_FIELDS`,
die in keiner Vorlage vorkommt (29 Dateien / 15 Entitaeten).

WIRKUNGS-BELEG, nicht Bau-Beleg: Awards deklariert name/slug/issuer/description —
getAwards UND listAwards rendern genau diese vier. LoyaltyPoints ohne Deklaration
rendert weiterhin name/title/subject.

Bau gruen, volle Reihe 120 Suiten / 6316 Proben gruen (vorher 119 / 6309).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EK5PonxfgqrAuKZCvkjyHs

`IRating` fuehrt `created`, das `RatingSchema` deklariert es NICHT — `strict` verwirft es beim
Schreiben still, es lebt nur in Alt-Dokumenten. Am Bestand gemessen 2026-08-22: `created` in 6
von 46 Dokumenten, `createdAt` in 46/46 (Positiv-Kontrolle im selben Lauf). Fuer 40 Dokumente
sortierte MongoDB gegen `null` — der Zug lieferte also NICHT die neuesten `_ratingsLimit`,
sondern eine beliebige Auswahl, ohne je fehlzuschlagen. Die vier Alt-Anzeigewege sortieren
`createdAt` (`legacy-core-api/services/micro/content/dynamic.ts:315`).

Heute ohne sichtbare Wirkung (plattformweit passieren nur 4 Bewertungen den Filter, die
Vorgabe-Grenze ist 12) — der Zweig wird erst mit wachsendem Bestand falsch, und dann lautlos.
Genau deshalb war er nicht aufgefallen: der bestehende Fall (c) prueft Filter UND Grenze, die
Sortierung nie. Die neue Probe schliesst die Luecke, mit Negativ-Kontrolle auf das Phantom-Feld
(rot vor dem Fix belegt, gruen danach).

Dazu die Abgrenzung der ACHT bewertungs-artigen Achsen im Blocktyp-Kanon — welche Entitaet auf
eine Website gehoert und welche nicht (`StoreViews` ist gar keine Bewertung; `Settings.rating`
ist die achte Achse und steht per Bauart NICHT in `modelsAndRights`). Voller Beleg:
`.claude/reports/bewertungs-achsen/abgrenzung-2026-08-22.md`.

`KNOWN_BLOCK_TYPES` unveraendert — kein neuer Blocktyp, die zwei Waechter bleiben gueltig.

Verify: `tsc --noEmit` Exit 0; volle Reihe 2318/2319 (der eine Fehlschlag
`__tests__/contents.test.ts:282` ist VORBESTEHEND — mit gestashten Aenderungen identisch rot).

Der Zweig zog `Ratings` mit `_customerID` + `rating != ""` und sonst nichts — als einziger
oeffentliche Massen-Zug der Plattform ohne Freigabe-Filter. Der `references`-Zweig 40 Zeilen
tiefer in DERSELBEN Datei filtert `published: true`; vier Alt-Anzeigewege filtern `web: true`
(`legacy-core-api/services/micro/content/dynamic.ts:314/:346/:390`, `replacer.ai.ts:584`).

Gemessen 2026-08-22 an den drei lebenden `testimonials`-Bausteinen: 35 Texte im Zug, davon 4
web+freigegeben und 1 mit ausdruecklich abgewaehltem `web`. `rejected` ist 0 — es wurde also
keine ABGELEHNTE Bewertung gezeigt; gebrochen war das Versprechen des Schalters, nicht die
Moderation.

Bewusst NICHT die strengere Dreier-Bedingung des CMS-Blocktyps `testimonial`
(`approved+web+!rejected`): sie kuerzte diese drei Bausteine von ~10 auf <=4 Eintraege — eine
sichtbare Inhaltsaenderung und damit eine Entscheidung, keine Fehlerbehebung. Vorgelegt als E1 in
`.claude/reports/bewertungs-achsen/abgrenzung-2026-08-22.md`.

Verify: `tsc --noEmit` Exit 0 (das Repositorium fuehrt kein Testwerk).

Die Zeile lautete 'awaiting: none # CEO 2026-08-21 …' — mein Muster verlangte das Zeilenende
direkt nach 'none' und griff deshalb nicht. Ein blockierter Brief mit 'awaiting: none' waere
weiterhin claimbar gewesen (none steht in AWAITING_CLAIMABLE).

Letzte drei von sieben Verbrauchern, die exakt auf 2026.9.0 festhingen und deshalb nicht
von selbst heilen.

🔴 ABWEICHUNG VOM BRIEF, und sie ist der Kern: er nennt 2026.10.0 — publiziert ist
2026.10.1, und der Unterschied ist tragend. Changelog:
10.0 feat(capabilities): Faehigkeits-Erkennung in die Kiosk-Huelle, plus Mikrofon
10.1 fix(capabilities): enumerateDevices bekommt eine Frist — die Erkennung wurde
sonst NIE fertig
Auf 10.0 zu pinnen hiesse, das neue Feature mitsamt seinem bekannten Haenger auf drei
Kiosk-Geraeteklassen auszurollen.

PIN-FORM: exakt beibehalten. Der Brief laesst beides zu; exakt folgt der Grundregel
(Richtung A, 2026-07-23) fuer VERBRAUCHER-Repositorien — reproduzierbare Baeue mit
committetem Lock. Die Uebergangs-Regel auf Spannen gilt Bibliotheken, die FUNDAMENT
pinnen, nicht Clients, die eine Bibliothek pinnen. `clients/pos` mit Caret ist der
Ausreisser, nicht das Vorbild.

Lock-Beleg: je genau EINE Aufloesung auf 2026.10.1 in allen drei.
Wirkung gemessen: `shared-lib-drift` client-facing stale (exact pins) 4 -> 1 = Grundlinie
(der verbleibende mobile-app|communicator-Eintrag). Ratsche NICHT bewegt.

URSACHE, reproduziert statt vermutet: die Scan-Wurzel kam aus `process.cwd()`, und der
Verzeichnis-Durchlauf verschluckt einen fehlenden Pfad still (`catch { return }`). Aus einem
beliebigen anderen Verzeichnis gefahren lieferte der Befehl deshalb `affected: []` — bei
FUNKTIONIERENDER Registry-Abfrage und ohne jeden Hinweis.

Das ist byte-genau die Form des Befundes vom 2026-08-21 (`affected: []` bei
`published: 2026.444.0`) und beantwortet die Frage des Briefes, welche der beiden Stufen
versagt: die KANDIDATEN-Erkennung, nicht der Versions-Vergleich. Waere es der Vergleich
gewesen, haetten 24 Zeilen mit `UNKNOWN` dagestanden.

Drei Aenderungen:
- `defaultScanRoot()` nutzt `getMonorepoRoot()` (leitet aus dem EIGENEN Ort ab) statt cwd —
der kanonische Helfer, den drei andere Befehle bereits nutzen.
- `scanEntityConsumers` WIRFT, wenn unter der Wurzel keiner der vier Ordner liegt. Eine leere
Menge ist hier nie eine Entwarnung; ohne den Waechter ist eine falsche Wurzel von einem
leeren Monorepo nicht zu unterscheiden.
- Ehrliche Zaehlung in Zusammenfassung UND json: `Kandidaten: N · davon BEHIND: M · CURRENT ·
UNBEKANNT`. „0 von 0" und „0 von 24" sahen bisher gleich aus — genau dieser Unterschied war
der ganze Befund. Plus ein ausdruecklicher Hinweis, wenn die veroeffentlichte Fassung nicht
lesbar war (dann ist jeder Stand UNBEKANNT, nicht CURRENT).

Flip-Probe (test/redeploy-entity-consumers-scan-root.test.mjs, 3 Proben inkl.
Negativ-Kontrolle): vorher liefert `scanEntityConsumers(<leeres Verzeichnis>)` still `[]`,
nachher wirft es. Suite-Ebene: Grundlinie 9 Fehlschlaege, danach 8 — die 8 sind vorbestehend
und fremd (Renderer, coord-admin, Formatter), meine Datei kippt von rot auf gruen.

Ende-zu-Ende aus /tmp gefahren: 24 Kandidaten, 24 BEHIND, `custom-functions-worker` gefuehrt.

Derselbe tote Feldname wie in taskBySPE, an acht weiteren Stellen derselben Datei - alle
auf ay.models.Tasks. Nach dem pm-Praefix-Feldzug W1 (2026-08-20) tragen gemessen 30.579 von
42.392 Aufgaben _project und nur 106 den Altnamen; jede Projekt-Einengung der Wand wurde
damit still verworfen.

Am schwersten traf es taskByProject: die Kachel GRUPPIERTE auf $project, wodurch 42.286 von
42.392 Aufgaben (99,75 %) in einem einzigen Eimer _id:null landeten und als 'Projekt
geloescht' beschriftet wurden. Die Kachel war damit vollstaendig unbrauchbar.

Betroffen: buildTaskQuery (bedient 5 Test-/Review-Kacheln), gantt, taskByEmployee (2x),
lastTasks, simpleTaskBreakdown (taskByType/-Priority/-Status/-Progress), taskTestCoverage,
taskDocuCoverage, taskByProject.

NICHT angefasst - und das ist ein Messergebnis, keine Auslassung: worklogs hat die Wanderung
NICHT mitgemacht (gemessen 3.709 von 3.987 Arbeitszeiten tragen project, 0 tragen _project).
In dieser Datei wird jedoch keine Arbeitszeit nach Projekt gefiltert; die einzige
WorkLogs-Abfrage laeuft ueber buildWorkLogsQuery. Ein WorkLogs-Feldzug ist ein eigener Vorgang.

Restkontrolle: 0 Vorkommen des Altnamens in der Datei, 10 Stellen auf _project, 331 Proben gruen.

Die Kachel nahm :from/:to entgegen und benutzte KEINE der beiden Grenzen - sie zeigte
immer den gesamten Bestand und behauptete dabei, sie zeige den gewaehlten Zeitraum
(gemessen ~124.000 Dokument-Abrufe je Aufruf, 3 x 41.441). Zwei weitere Filter waren aus
demselben Grund wirkungslos und sind mitbehoben:

- project -> _project (pm-Praefix-Feldzug W1). Gemessen 2026-08-21: 30.579 von 42.392
Aufgaben tragen _project, nur 106 den Altnamen. Jede Projekt-Einengung wurde still
verworfen.
- service -> servicedesk. Das Feld 'service' existiert NICHT (0 von 42.392); der Balken
'Service' war strukturell immer 0, ohne Fehler, ohne Warnung.

Zeitachse createdAt, gemessen statt angenommen: alle fuenf Geschwister-Kacheln mit
demselben :from/:to-Vertrag filtern darauf (neue BFF-Route wie Alt-Route), createdAt ist
zu 100 % belegt (doneAt 26,5 %, due 13,2 %), und start/end sind zu 99,9 % sekundengenaue
Kopien von createdAt. Herleitung im Kopf von lib/taskStatsQuery.ts.

Fehlende, unlesbare oder vertauschte Grenzen liefern jetzt 400 statt eines stillen
Rueckfalls auf 'alles' - ebenso eine unlesbare Projekt-Kennung.

11 neue Proben, Flip-Probe beidseitig: alle drei wiederhergestellten Defekte werden von
genau der zustaendigen Probe rot gemeldet, die uebrigen 328 bleiben gruen.

- `build`: `rimraf dist && tsc || exit 0` -> `rimraf dist && tsc`. Das `|| exit 0`
machte JEDEN Bau gruen. Beidseitig belegt: altes Skript + absichtlicher TS-Fehler
-> exit 0 (verschluckt, Fehler stand im Protokoll); neues Skript + derselbe Fehler
-> exit 2. Fehler danach zurueckgenommen, Bau exit 0, Testreihe 326/326.

- `tenantBriefings.ts` + `lib/tenantBriefing.ts`: beide Kommentare behaupteten,
`Settings.defaultmails.briefing` existiere im Schema nicht, und nannten
"94 Briefings, 0 zugestellt". Beides ueberholt. Das Feld liegt seit Kaskade 59
im Schema (installiert 2026.450.0, mit Negativ-Kontrolle belegt). Der
Umgehungs-Weg bleibt richtig, aber weil das Feld je Mandant LEER ist.

- `dailyBriefing/channels.ts`: `sendBriefingEmail` ist NICHT tot. Es hat genau
einen lebenden Aufrufer monorepo-weit - diesen - und er erzeugt alle 72
gescheiterten Zustellungen (550 5.6.0 No Sending Domain found in From header).
Ausserdem festgehalten: dieser Weg schreibt keine MailLogs-Zeile.

Kein Verhaltens-Change am Zustellweg - nur Bau-Riegel und Begruendungen.

Die Umkehrprobe am Persistat hat es gefangen, der Bau nicht: eine Mongoose-
Liste materialisiert sich IMMER als []. Ohne default: undefined waere
_websites: [] beim naechsten Speichern in alle 38 Module und 554 Features
gewandert — genau der Vorgabewert, den der Auftrag ausdruecklich verbietet,
und er machte "nie entschieden" von "ausdruecklich mandanten-global"
ununterscheidbar.

Dieselbe Fehlerklasse wie quality.flags und IEmployee.benefits (Kaskade 64).

Hydrierung jetzt 20/20 gruen, inkl. Negativ-Kontrolle (erfundenes Feld faellt,
strict greift also wirklich) und Umkehrprobe am Persistat.

`Flags.isEnabled` beantwortet NICHT „steht der Schalter auf an?", sondern „gibt
es das Merkmal und ist es nicht stale/archived?" — `flag.value` kommt in seiner
Auswertung gar nicht vor. Ein Kill-Schalter mit dem Wert "false" galt damit als
EINGESCHALTET, allein weil jemand ihn angelegt hat.

Gemessener Schaden: beim Mandanten tolinax UG steht
`config.wallboardAlertThrottle.disabled` seit dem 2026-07-14T19:52 auf
value:"false", und die Beschreibung des Schalters sagt woertlich „REVERT des
Notnagels … auf false … wird nicht mehr gebraucht". Der Rueckbau ist NIE
wirksam geworden — die Drossel war fuenfeinhalb Wochen aus. Unbemerkt, weil ein
erneut klingelnder Dauerfehler an einer Wandanzeige wie normales Alarmieren
aussieht. Belegt am 2026-08-21: dieselbe Signatur klingelte in zehn Minuten
16-mal, waehrend zehn andere Alarme im selben Fenster je genau einmal klingelten.

Der Beleg stand in derselben Datei: die Fenster-Groesse liest `getValue`, und der
ENV-Zweig parst 'true'|'1'|'yes'. Der WERT war immer gemeint.

Rueckfall bewusst beibehalten: ohne hinterlegten Wert entscheidet weiterhin
`isEnabled`, ein wertloses Merkmal aendert sein Verhalten also nicht.

5 Proben (249 statt 244), Flip auf `Boolean(raw)` — den Originalfehler — beisst.

Domain jobs upsert up to 10,000 keywords sequentially (2 DB round-trips
each) plus Google Ads quota-retry backoff, routinely exceeding the 30s
BullMQ default lockDuration. Once the lock expires mid-job, stalled-job
recovery reassigns the job and the original process's later
moveToFinished races the reassignment, surfacing as "could not renew
lock", "Missing key for job ... moveToFinished" and "Lock mismatch"
errors (dozens/week in the Errors-as-Tasks firehose). Raise lockDuration
to 10 minutes on both keyword-planner workers.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011XC3R3yf9u7xnZneEKnU8w

Der 448.0-Kommentar behauptete "absent = auf der Website nicht zeigen". Der
Leser kann das heute nicht tun: 38 Module und 554 Funktionen tragen das Feld
nicht, und Backfill ist ausdruecklich ausgeschlossen — ein strenges Tor
schaltete die Achse in derselben Sekunde dunkel.

Richtig ist: absent = KEINE Aussage, Rueckfall auf das bestehende Ersatz-Tor
("traegt eine kuratierte Beschreibung", selbst fail-closed); GESETZT gewinnt
das Feld in beide Richtungen. Die Ziel-Semantik (absent = nicht zeigen) ist
als solche benannt und braucht einen eigenen Vorgang.

Ein Vertrag, der etwas anderes behauptet als sein Leser tut, ist die teuerste
Sorte Kommentar — er bescheinigt sich selbst.