Changelog

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 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