docs(quick-260911-fh9): Fehlerrichtung fuer Bereich auth messen und aufschreiben

- rls-scratch-check.mjs: dreizehnter Abschnitt runAuthAreaChecks, getrennt
  von runAuthLookupChecks — misst die Grenze zwischen Anmeldeweg (drei
  SECURITY-DEFINER-Funktionen, unveraendert) und Nach-Anmeldung (getMe,
  changePassword, adminResetPassword) ueber den generierten Client; neuer
  Helfer readSchemaModelScalarFieldNames() filtert Relationsfelder
  ueber ihren Typ heraus
- zehn neue, namentlich benannte Pruefungen (120/120 insgesamt), sechs davon
  ueber den generierten Client an der auf 15 Spalten erweiterten
  Wegwerf-Tabelle "User"; pg_proc bestaetigt SECURITY DEFINER/STABLE/festen
  Suchpfad/LIMIT 1 fuer alle drei Anmeldefunktionen
- docs/mandantentrennung-etappe2-fehlerrichtung.md: neuer Abschnitt
  "## Bereich auth" (h1)-(h5) vor "## Verweis" — Signaltabelle je Pfad,
  getMe-Kette als "verschluckt" statt "laut", Etappe-3-Vorbehalt,
  Schwesterweg-Luecke in user.controller.ts

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

apps/api/scripts/rls-scratch-check.mjs

@@ -2794,6 +2794,41 @@ function readSchemaModelFieldNames(modelName) {
   return fields;
 }
 
+/**
+ * Aufgabe 1 (260911-fh9) — wie `readSchemaModelFieldNames`, aber laesst
+ * jedes Feld weg, dessen TYP (zweites Wort der Zeile, `?` und `[]`
+ * abgestreift) selbst der Name eines anderen `model` im Schema ist —
+ * Relationsfelder haben keine Spalte (Befund M aus 260911-e2s, dort fuer
+ * "Tenant" ueber die Migration umgangen; bei "User" ist die Spaltenmenge
+ * ueber drei Migrationen verteilt, deshalb hier der Weg ueber das Schema
+ * mit Relationsfilter). `Role` ist ein `enum`, kein `model`, und bleibt
+ * deshalb ein skalares Feld.
+ */
+function readSchemaModelScalarFieldNames(modelName) {
+  const schemaSource = readFileSync(SCHEMA_PRISMA_PATH, 'utf-8');
+  const modelNames = new Set(
+    [...schemaSource.matchAll(/^model\s+(\w+)\s*\{/gm)].map((m) => m[1]),
+  );
+  const re = new RegExp(`model ${modelName} \\{([\\s\\S]*?)\\n\\}`);
+  const match = schemaSource.match(re);
+  if (!match) return [];
+  const fields = [];
+  for (const rawLine of match[1].split('\n')) {
+    const line = rawLine.trim();
+    if (!line) continue;
+    if (line.startsWith('@@')) continue;
+    if (line.startsWith('//')) continue;
+    const parts = line.split(/\s+/);
+    const fieldName = parts[0];
+    if (!fieldName) continue;
+    const rawType = parts[1] ?? '';
+    const fieldType = rawType.replace(/\?$/, '').replace(/\[\]$/, '');
+    if (modelNames.has(fieldType)) continue; // Relationsfeld, keine Spalte
+    fields.push(fieldName);
+  }
+  return fields;
+}
+
 /**
  * Aufgabe 1 (260911-cwh) — misst die zwoelf im Plan genannten
  * Verhaltensweisen des Bereichs `calendar` unter der Rolle ohne BYPASSRLS,
@@ -3445,6 +3480,302 @@ async function runTenantAreaChecks(adminUrl, scratchRoleUrl, results) {
   }
 }
 
+/**
+ * Aufgabe 1 (260911-fh9) — misst die Grenze zwischen Anmeldeweg (die drei
+ * SECURITY-DEFINER-Funktionen, gemessen in `runAuthLookupChecks`) und
+ * Nach-Anmeldung (dieser Abschnitt, gebundener Modellzugriff ueber den
+ * GENERIERTEN Client) fuer die drei Methoden `getMe`, `changePassword`,
+ * `adminResetPassword`. Ausdruecklich GETRENNT von `runAuthLookupChecks`:
+ * jener misst den Anmeldeweg VOR bekanntem Mandanten (Funktionen), dieser
+ * die drei Methoden NACH der Anmeldung (gebundener Modellzugriff) — die
+ * Grenze, die dieser Plan festnagelt.
+ *
+ * Setzt auf der vorhandenen Wegwerf-Tabelle "User" auf (aus
+ * `runAuthLookupChecks`, mit eingeschaltetem und erzwungenem Zeilenschutz,
+ * wortgleicher Policy, zwei Zeilen in zwei Mandanten; seit
+ * `runTenantAreaChecks` zusaetzlich mit Fremdschluessel auf "Tenant") und
+ * auf der bereits eingespielten Funktions-Migration; erweitert "User" um die
+ * fuenf im generierten Client fehlenden Spalten (Befund G). Keine spaetere
+ * Pruefung setzt auf diesen Erweiterungen auf (`runTransactionShapeMeasurement`/
+ * `runConcurrencyProbe` fassen weder "User" noch "Tenant" an, Befund M aus
+ * 260911-e2s) — dieser Abschnitt ist ein Blatt in der Aufrufkette und muss
+ * deshalb NACH `runTenantAreaChecks()` und VOR
+ * `runTransactionShapeMeasurement()` laufen (siehe Aufrufkette in `main()`).
+ */
+async function runAuthAreaChecks(adminUrl, scratchRoleUrl, results) {
+  // Vorbereitung ueber die Wartungsrolle: die fuenf im generierten Client
+  // fehlenden Spalten nachruesten (Befund G). Typen aus den drei
+  // ausgelieferten Migrationen (20260618112124_auth_multi_tenancy,
+  // 20260630095533_add_user_avatar, 20260702000000_add_user_accent_color).
+  // ABWEICHUNG: "updatedAt" bekommt fuer die zwei bereits vorhandenen
+  // Wegwerf-Zeilen (user-a/user-b aus runAuthLookupChecks) eine Vorgabe
+  // CURRENT_TIMESTAMP, die die ausgelieferte Migration nicht hat (dort NOT
+  // NULL ohne DEFAULT — Prisma setzt den Wert clientseitig ueber
+  // `@updatedAt`) — betrifft nur dieses Nachruesten hier, keine Aussage
+  // ueber den ausgelieferten Stand.
+  await withAdminPrisma(urlForDatabase(adminUrl, SCRATCH_DB_NAME).toString(), async (db) => {
+    await db.$executeRawUnsafe(
+      `ALTER TABLE "User" ADD COLUMN "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP;`,
+    );
+    await db.$executeRawUnsafe(
+      `ALTER TABLE "User" ADD COLUMN "updatedAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP;`,
+    );
+    await db.$executeRawUnsafe(`ALTER TABLE "User" ADD COLUMN "lastLoginAt" TIMESTAMP(3);`);
+    await db.$executeRawUnsafe(`ALTER TABLE "User" ADD COLUMN "avatarPath" TEXT;`);
+    await db.$executeRawUnsafe(`ALTER TABLE "User" ADD COLUMN "accentColor" TEXT;`);
+  });
+
+  // Pruefung — steht VOR den Client-Pruefungen (4-10 unten); faellt sie
+  // durch, bricht der Abschnitt ab (Lehre aus Pruefung 8 im Bereich
+  // `calendar`/Pruefung 3 im Bereich `tenant`).
+  const schemaFields = readSchemaModelScalarFieldNames('User');
+  const tableColumns = await withAdminPrisma(
+    urlForDatabase(adminUrl, SCRATCH_DB_NAME).toString(),
+    async (db) => {
+      const rows = await db.$queryRaw`
+        SELECT column_name FROM information_schema.columns
+        WHERE table_schema = 'public' AND table_name = 'User'
+      `;
+      return rows.map((r) => r.column_name).sort();
+    },
+  );
+  const schemaFieldsSorted = [...schemaFields].sort();
+  const columnsMatch =
+    schemaFieldsSorted.length > 0 &&
+    schemaFieldsSorted.length === tableColumns.length &&
+    schemaFieldsSorted.every((f, i) => f === tableColumns[i]);
+  report(
+    results,
+    'auth-wegwerftabelle-user-deckt-alle-spalten-des-generierten-clients',
+    columnsMatch,
+    `Schema-Felder aus schema.prisma (model User, skalare Felder ohne Relationen, ${schemaFieldsSorted.length}): ${JSON.stringify(schemaFieldsSorted)}; Spalten der Wegwerf-Tabelle (${tableColumns.length}): ${JSON.stringify(tableColumns)}`,
+  );
+  if (!columnsMatch) {
+    return;
+  }
+
+  // Pruefung 1: pg_proc-Messung der drei Anmeldefunktionen — die
+  // Datenbankseite von "nichts an der Anordnung angefasst" (Befund H).
+  const functionRows = await withAdminPrisma(
+    urlForDatabase(adminUrl, SCRATCH_DB_NAME).toString(),
+    async (db) =>
+      db.$queryRaw`
+        SELECT proname, prosecdef, provolatile, proconfig, pg_get_functiondef(oid) AS def
+        FROM pg_proc WHERE proname LIKE 'auth_lookup_%' ORDER BY proname
+      `,
+  );
+  const expectedFunctionNames = [
+    'auth_lookup_reset_token',
+    'auth_lookup_user_by_email',
+    'auth_lookup_user_by_username',
+  ];
+  const actualFunctionNames = functionRows.map((r) => r.proname).sort();
+  const perFunctionProps = functionRows.map((r) => ({
+    proname: r.proname,
+    prosecdef: r.prosecdef,
+    provolatile: r.provolatile,
+    proconfig: r.proconfig,
+    hatLimit1: typeof r.def === 'string' && r.def.includes('LIMIT 1'),
+  }));
+  const allSecurityDefinerStableFixedSearchPathLimit1 = perFunctionProps.every(
+    (p) =>
+      p.prosecdef === true &&
+      p.provolatile === 's' &&
+      Array.isArray(p.proconfig) &&
+      p.proconfig.some((c) => String(c).replace(/\s+/g, '') === 'search_path=public,pg_temp') &&
+      p.hatLimit1,
+  );
+  const functionsOk =
+    functionRows.length === 3 &&
+    JSON.stringify(actualFunctionNames) === JSON.stringify(expectedFunctionNames) &&
+    allSecurityDefinerStableFixedSearchPathLimit1;
+  report(
+    results,
+    'auth-anmeldefunktionen-security-definer-unveraendert',
+    functionsOk,
+    `${functionRows.length} Funktion(en) unter 'auth_lookup_%' gefunden: ${JSON.stringify(actualFunctionNames)}; je Funktion prosecdef/provolatile/proconfig/LIMIT-1: ${JSON.stringify(perFunctionProps)}`,
+  );
+
+  const prisma = new PrismaClient({ datasourceUrl: scratchRoleUrl });
+  try {
+    // Pruefung 3: die Anmeldesuche findet den Benutzer weiterhin, mit dem
+    // FESTEN Spaltensatz der Funktion — die Spaltenerweiterung oben laesst
+    // weder avatarPath noch accentColor noch email durch.
+    const lookupRows = await prisma.$queryRaw`SELECT * FROM auth_lookup_user_by_username('alice')`;
+    const lookupKeys = lookupRows.length === 1 ? Object.keys(lookupRows[0]).sort() : [];
+    const lookupOk =
+      lookupRows.length === 1 &&
+      lookupKeys.length === 9 &&
+      !lookupKeys.includes('avatarPath') &&
+      !lookupKeys.includes('accentColor') &&
+      !lookupKeys.includes('email');
+    report(
+      results,
+      'auth-anmeldesuche-findet-benutzer-weiterhin-mit-festem-spaltensatz',
+      lookupOk,
+      `auth_lookup_user_by_username('alice') liefert ${lookupRows.length} Zeile(n) mit ${lookupKeys.length} Schluessel(n): ${JSON.stringify(lookupKeys)} — der feste Spaltensatz der Funktion laesst die Spaltenerweiterung nicht durch`,
+    );
+
+    // Die tragende Belegzeile: getMe() als Client-Form, UNGEBUNDEN.
+    const getMeSelect = {
+      id: true,
+      username: true,
+      displayName: true,
+      role: true,
+      tenantId: true,
+      mustChangePassword: true,
+      passwordHash: true,
+      ldapDn: true,
+      avatarPath: true,
+      accentColor: true,
+    };
+    const unboundGetMe = await prisma.user.findUnique({
+      where: { id: 'user-a' },
+      select: getMeSelect,
+    });
+    report(
+      results,
+      'auth-getme-generierter-client-ungebunden-liefert-null',
+      unboundGetMe === null,
+      `ungebundenes prisma.user.findUnique({ where: { id: 'user-a' }, select: {...} }) (die Form von getMe) liefert ${JSON.stringify(unboundGetMe)} — das ist der Wert, den GET /auth/me nach dem Scharfschalten als leeren Rumpf ausliefert`,
+    );
+
+    const boundA = buildInlineExtendedClient(prisma, 'TENANT-A');
+    const boundGetMeOwn = await boundA.user.findUnique({
+      where: { id: 'user-a' },
+      select: getMeSelect,
+    });
+    const ownTenantOk =
+      Boolean(boundGetMeOwn) &&
+      boundGetMeOwn.tenantId === 'TENANT-A' &&
+      Object.keys(boundGetMeOwn).sort().length === 10;
+    report(
+      results,
+      'auth-getme-generierter-client-gebunden-eigener-mandant-findet-benutzer',
+      ownTenantOk,
+      `gebunden unter TENANT-A liefert findUnique({ where: { id: 'user-a' }, select: {...} }): ${JSON.stringify(boundGetMeOwn)}`,
+    );
+
+    const boundB = buildInlineExtendedClient(prisma, 'TENANT-B');
+    const boundGetMeForeign = await boundB.user.findUnique({
+      where: { id: 'user-a' },
+      select: getMeSelect,
+    });
+    report(
+      results,
+      'auth-getme-generierter-client-gebunden-fremder-mandant-liefert-null',
+      boundGetMeForeign === null,
+      `gebunden unter TENANT-B liefert findUnique({ where: { id: 'user-a' } }) (gehoert TENANT-A): ${JSON.stringify(boundGetMeForeign)} — ein Administrator von TENANT-B sieht 'user-a' nicht, die Datenbankseite von T-FH9-01`,
+    );
+
+    // Die Schreibform, die changePassword heute stellt: UNGEBUNDEN.
+    let ungebundenesUpdateWarf = false;
+    let ungebundenesUpdateCtor = 'unbekannt';
+    let ungebundenesUpdateCode;
+    let ungebundenesUpdateMessage = '';
+    try {
+      await prisma.user.update({
+        where: { id: 'user-a' },
+        data: { passwordHash: 'hash-a-neu-ungebunden', mustChangePassword: false },
+      });
+    } catch (err) {
+      ungebundenesUpdateWarf = true;
+      ungebundenesUpdateCtor = err?.constructor?.name ?? 'unbekannt';
+      ungebundenesUpdateCode = err?.code;
+      ungebundenesUpdateMessage = (err.message ?? '').toString().trim();
+    }
+    const passwordHashNachUngebundenemVersuch = await withAdminPrisma(
+      urlForDatabase(adminUrl, SCRATCH_DB_NAME).toString(),
+      async (db) => {
+        const rows = await db.$queryRaw`SELECT "passwordHash" FROM "User" WHERE id = 'user-a'`;
+        return rows[0]?.passwordHash;
+      },
+    );
+    report(
+      results,
+      'auth-changepassword-generierter-client-ungebundenes-update-scheitert-laut',
+      ungebundenesUpdateWarf && passwordHashNachUngebundenemVersuch === 'hash-a',
+      `ungebundenes prisma.user.update({ where: { id: 'user-a' }, data: {...} }) (die Form von changePassword) wirft ${ungebundenesUpdateCtor}${ungebundenesUpdateCode ? ` (code ${ungebundenesUpdateCode})` : ''}: ${ungebundenesUpdateMessage} — die Wartungsrolle liest danach weiterhin passwordHash=${JSON.stringify(passwordHashNachUngebundenemVersuch)}`,
+    );
+
+    // Dasselbe update, GEBUNDEN unter TENANT-A (eigener Mandant): gelingt.
+    await boundA.user.update({
+      where: { id: 'user-a' },
+      data: { passwordHash: 'hash-a-neu', mustChangePassword: false },
+    });
+    const nachGebundenemUpdate = await withAdminPrisma(
+      urlForDatabase(adminUrl, SCRATCH_DB_NAME).toString(),
+      async (db) => {
+        const rows =
+          await db.$queryRaw`SELECT "passwordHash", "updatedAt" FROM "User" WHERE id = 'user-a'`;
+        return rows[0];
+      },
+    );
+    report(
+      results,
+      'auth-changepassword-generierter-client-gebundenes-update-eigener-mandant-gelingt',
+      nachGebundenemUpdate?.passwordHash === 'hash-a-neu' && nachGebundenemUpdate?.updatedAt != null,
+      `gebunden unter TENANT-A liefert die Wartungsrolle danach passwordHash=${JSON.stringify(nachGebundenemUpdate?.passwordHash)}, updatedAt=${JSON.stringify(nachGebundenemUpdate?.updatedAt)} — bestaetigt nebenbei, dass die Wegwerf-Tabelle die clientseitig gesetzten Werte annimmt`,
+    );
+
+    // Dieselbe Schreibform, GEBUNDEN unter TENANT-B (fremder Mandant): die
+    // Form, die adminResetPassword fuer ein fremdmandantiges Ziel stellt.
+    let fremdesUpdateWarf = false;
+    let fremdesUpdateCtor = 'unbekannt';
+    let fremdesUpdateCode;
+    let fremdesUpdateMessage = '';
+    try {
+      await boundB.user.update({
+        where: { id: 'user-a' },
+        data: { passwordHash: 'hash-a-fremd' },
+      });
+    } catch (err) {
+      fremdesUpdateWarf = true;
+      fremdesUpdateCtor = err?.constructor?.name ?? 'unbekannt';
+      fremdesUpdateCode = err?.code;
+      fremdesUpdateMessage = (err.message ?? '').toString().trim();
+    }
+    const passwordHashNachFremdemVersuch = await withAdminPrisma(
+      urlForDatabase(adminUrl, SCRATCH_DB_NAME).toString(),
+      async (db) => {
+        const rows = await db.$queryRaw`SELECT "passwordHash" FROM "User" WHERE id = 'user-a'`;
+        return rows[0]?.passwordHash;
+      },
+    );
+    report(
+      results,
+      'auth-adminreset-generierter-client-gebundenes-update-fremder-mandant-scheitert-laut',
+      fremdesUpdateWarf && passwordHashNachFremdemVersuch === 'hash-a-neu',
+      `gebunden unter TENANT-B liefert update({ where: { id: 'user-a' } }) (gehoert TENANT-A) ${fremdesUpdateCtor}${fremdesUpdateCode ? ` (code ${fremdesUpdateCode})` : ''}: ${fremdesUpdateMessage} — ein ADMIN von TENANT-B kann das Kennwort von 'user-a' nicht setzen, gemessen statt behauptet; die Wartungsrolle liest danach weiterhin passwordHash=${JSON.stringify(passwordHashNachFremdemVersuch)}`,
+    );
+
+    // Fan-out je Mandant, gebunden: die Form, die Aufgabe 2/3 fuer die
+    // oberste Rolle (SUPER_ADMIN) benutzt — Tenant ungebunden als Treiber
+    // (Tenant ohne Regel, gemessen in runTenantAreaChecks), je Mandant EIN
+    // gebundener findUnique.
+    const tenantsForFanOut = await prisma.tenant.findMany({ orderBy: { id: 'asc' } });
+    let fanOutHit = null;
+    let fanOutTenantId = null;
+    for (const t of tenantsForFanOut) {
+      const boundForT = buildInlineExtendedClient(prisma, t.id);
+      const hit = await boundForT.user.findUnique({ where: { id: 'user-a' } });
+      if (hit) {
+        fanOutHit = hit;
+        fanOutTenantId = t.id;
+        break;
+      }
+    }
+    report(
+      results,
+      'auth-fan-out-je-mandant-gebunden-loest-mandant-der-kennung-auf',
+      Boolean(fanOutHit) && fanOutTenantId === 'TENANT-A' && fanOutHit.tenantId === 'TENANT-A',
+      `Fan-out ueber ${tenantsForFanOut.length} Mandant(en): 'user-a' gefunden unter ${JSON.stringify(fanOutTenantId)}, tenantId der Zeile=${JSON.stringify(fanOutHit?.tenantId)} — die Kennung allein ergibt den Mandanten des Ziels, weil User.id plattformweit eindeutig ist`,
+    );
+  } finally {
+    await prisma.$disconnect();
+  }
+}
+
 /**
  * Aufgabe 1 (260909-jts), TEIL 2 — misst, welche der drei Transaktionsformen
  * den Mandantenkontext auf DERSELBEN Verbindung ueber alle Teilschritte
@@ -3683,6 +4014,7 @@ async function main() {
     await runDashboardAreaChecks(adminUrl, scratchRoleUrlString, results);
     await runCalendarAreaChecks(adminUrl, scratchRoleUrlString, results);
     await runTenantAreaChecks(adminUrl, scratchRoleUrlString, results);
+    await runAuthAreaChecks(adminUrl, scratchRoleUrlString, results);
     await runTransactionShapeMeasurement(scratchRoleUrlString, results);
     await runConcurrencyProbe(scratchRoleUrlString, results);
   } finally {

docs/mandantentrennung-etappe2-fehlerrichtung.md

@@ -2470,6 +2470,210 @@ im Bereich `user` — kein eigener Eintrag noetig.
 - Schema und Migrationen — geprueft und bewusst gelassen, `Tenant` bekommt
   KEINE Regel.
 
+## Bereich auth
+
+Dieser Abschnitt erweitert die Kritikschrift um den Bereich `auth`
+(Quick-Task 260911-fh9) und beschreibt ihn zum Zeitpunkt seiner Umstellung.
+Anders als jeder Bereich davor traegt dieser Bereich die Grenze, an der die
+gesamte Mandantentrennung haengt: der Anmeldeweg (Benutzer suchen, BEVOR der
+Mandant bekannt ist) wurde bereits in Etappe 1 (260909-eor) ueber drei enge
+SECURITY-DEFINER-Funktionen geloest und bleibt in diesem Durchlauf
+unangetastet; gegenstand dieses Durchlaufs sind ausschliesslich die drei
+Methoden NACH der Anmeldung (`getMe`, `changePassword`,
+`adminResetPassword`), die in Etappe 1 bewusst liegen gelassen wurden.
+
+### (h1) Die Messung
+
+Aufgabe 1 hat `apps/api/scripts/rls-scratch-check.mjs` um einen dreizehnten
+Abschnitt (`runAuthAreaChecks`) erweitert — ausdruecklich GETRENNT vom
+bestehenden `runAuthLookupChecks`: jener misst den Anmeldeweg VOR bekanntem
+Mandanten (die drei Funktionen ueber `$queryRaw`), dieser die drei Methoden
+NACH der Anmeldung (gebundener Modellzugriff ueber den GENERIERTEN Client).
+Der neue Abschnitt setzt auf der von `runAuthLookupChecks` bereits angelegten
+Wegwerf-Tabelle `"User"` auf (eingeschalteter und erzwungener Zeilenschutz,
+wortgleiche Policy, zwei Zeilen in zwei Mandanten; seit `runTenantAreaChecks`
+zusaetzlich mit Fremdschluessel auf `"Tenant"`) und ruestet sie um die fuenf
+Spalten nach, die der generierte Client zusaetzlich braucht (`createdAt`,
+`updatedAt`, `lastLoginAt`, `avatarPath`, `accentColor` — Befund G): dafuer
+liest ein neuer Helfer `readSchemaModelScalarFieldNames('User')` die
+skalaren Felder aus `schema.prisma` und filtert Relationsfelder ueber ihren
+Typ heraus (`tenant`, `passwordResetTokens`, `groupMemberships`,
+`moduleGrants` fallen weg, `role` bleibt — `Role` ist ein `enum`, kein
+`model`). Diese Spaltenpruefung steht VOR den Client-Pruefungen und bricht
+den Abschnitt ab, wenn sie durchfaellt (Lehre aus Pruefung 8 im Bereich
+`calendar`).
+
+Tatsaechlich beobachtete Ausgabe dieses Laufs (2026-09-11, gegen
+`tessera-ctl-db-1`, Adresse `172.19.0.2`):
+
+```
+auth-wegwerftabelle-user-deckt-alle-spalten-des-generierten-clients: bestanden — Schema-Felder aus schema.prisma (model User, skalare Felder ohne Relationen, 15): ["accentColor","avatarPath","createdAt","displayName","email","id","isActive","lastLoginAt","ldapDn","mustChangePassword","passwordHash","role","tenantId","updatedAt","username"]; Spalten der Wegwerf-Tabelle (15): ["accentColor","avatarPath","createdAt","displayName","email","id","isActive","lastLoginAt","ldapDn","mustChangePassword","passwordHash","role","tenantId","updatedAt","username"]
+auth-anmeldefunktionen-security-definer-unveraendert: bestanden — 3 Funktion(en) unter 'auth_lookup_%' gefunden: ["auth_lookup_reset_token","auth_lookup_user_by_email","auth_lookup_user_by_username"]; je Funktion prosecdef/provolatile/proconfig/LIMIT-1: [{"proname":"auth_lookup_reset_token","prosecdef":true,"provolatile":"s","proconfig":["search_path=public, pg_temp"],"hatLimit1":true},{"proname":"auth_lookup_user_by_email","prosecdef":true,"provolatile":"s","proconfig":["search_path=public, pg_temp"],"hatLimit1":true},{"proname":"auth_lookup_user_by_username","prosecdef":true,"provolatile":"s","proconfig":["search_path=public, pg_temp"],"hatLimit1":true}]
+auth-anmeldesuche-findet-benutzer-weiterhin-mit-festem-spaltensatz: bestanden — auth_lookup_user_by_username('alice') liefert 1 Zeile(n) mit 9 Schluessel(n): ["displayName","id","isActive","ldapDn","mustChangePassword","passwordHash","role","tenantId","username"] — der feste Spaltensatz der Funktion laesst die Spaltenerweiterung nicht durch
+auth-getme-generierter-client-ungebunden-liefert-null: bestanden — ungebundenes prisma.user.findUnique({ where: { id: 'user-a' }, select: {...} }) (die Form von getMe) liefert null — das ist der Wert, den GET /auth/me nach dem Scharfschalten als leeren Rumpf ausliefert
+auth-getme-generierter-client-gebunden-eigener-mandant-findet-benutzer: bestanden — gebunden unter TENANT-A liefert findUnique({ where: { id: 'user-a' }, select: {...} }): {"id":"user-a","username":"alice","displayName":null,"role":"USER","tenantId":"TENANT-A","mustChangePassword":false,"passwordHash":"hash-a","ldapDn":null,"avatarPath":null,"accentColor":null}
+auth-getme-generierter-client-gebunden-fremder-mandant-liefert-null: bestanden — gebunden unter TENANT-B liefert findUnique({ where: { id: 'user-a' } }) (gehoert TENANT-A): null — ein Administrator von TENANT-B sieht 'user-a' nicht, die Datenbankseite von T-FH9-01
+auth-changepassword-generierter-client-ungebundenes-update-scheitert-laut: bestanden — ungebundenes prisma.user.update({ where: { id: 'user-a' }, data: {...} }) (die Form von changePassword) wirft PrismaClientKnownRequestError (code P2025): Invalid `prisma.user.update()` invocation: An operation failed because it depends on one or more records that were required but not found. No record was found for an update. — die Wartungsrolle liest danach weiterhin passwordHash="hash-a"
+auth-changepassword-generierter-client-gebundenes-update-eigener-mandant-gelingt: bestanden — gebunden unter TENANT-A liefert die Wartungsrolle danach passwordHash="hash-a-neu", updatedAt="2026-09-11T09:42:42.165Z" — bestaetigt nebenbei, dass die Wegwerf-Tabelle die clientseitig gesetzten Werte annimmt
+auth-adminreset-generierter-client-gebundenes-update-fremder-mandant-scheitert-laut: bestanden — gebunden unter TENANT-B liefert update({ where: { id: 'user-a' } }) (gehoert TENANT-A) PrismaClientKnownRequestError (code P2025): Invalid `prisma.user.update()` invocation: An operation failed because it depends on one or more records that were required but not found. No record was found for an update. — ein ADMIN von TENANT-B kann das Kennwort von 'user-a' nicht setzen, gemessen statt behauptet; die Wartungsrolle liest danach weiterhin passwordHash="hash-a-neu"
+auth-fan-out-je-mandant-gebunden-loest-mandant-der-kennung-auf: bestanden — Fan-out ueber 2 Mandant(en): 'user-a' gefunden unter "TENANT-A", tenantId der Zeile="TENANT-A" — die Kennung allein ergibt den Mandanten des Ziels, weil User.id plattformweit eindeutig ist
+Alle 120 Pruefungen bestanden.
+```
+
+Die tragende Belegzeile ist `auth-getme-generierter-client-ungebunden-liefert-null`: der IDENTISCHE `findUnique`, den `getMe` heute stellt, liefert UNGEBUNDEN `null`, waehrend die Wartungsrolle die Zeile sieht — das ist der Wert, den `GET /auth/me` nach dem Scharfschalten als leeren Rumpf ausliefert. Die `pg_proc`-Messung
+(`auth-anmeldefunktionen-security-definer-unveraendert`) und der feste
+Spaltensatz (`auth-anmeldesuche-findet-benutzer-weiterhin-mit-festem-spaltensatz`)
+belegen zusammen, dass die drei Anmeldefunktionen unangetastet sind und die
+Spaltenerweiterung von `"User"` nichts Zusaetzliches preisgibt: alle drei
+Funktionen sind weiterhin `SECURITY DEFINER`, `STABLE`, mit festem Suchpfad
+`search_path=public, pg_temp` und `LIMIT 1`, und `auth_lookup_user_by_username`
+liefert nach der Spaltenerweiterung weiterhin genau neun Spalten — weder
+`avatarPath` noch `accentColor` noch `email` sind darunter.
+
+Sechs der zehn Pruefungen laufen ueber den GENERIERTEN CLIENT
+(`prisma.user.findUnique`/`update`, `bound.user.findUnique`/`update`), nicht
+ueber Roh-SQL — bewusst, weil `findUnique` ohne `select` (die Form von
+`changePassword`/`adminResetPassword`) und das `select` von `getMe` Client-
+Formen sind: Roh-SQL sieht sie strukturell nicht (Fehler 7 des Vorhabens).
+
+### (h2) Signaltabelle je Pfad
+
+| Pfad | `@Public()` | Verhalten HEUTE nach dem Scharfschalten (ohne diesen Plan) | Konkretes Signal | Frontend laesst es durch? |
+|---|---|---|---|---|
+| `validateUser` (`POST /auth/login`) | ja | Sucht ueber `auth_lookup_user_by_username` (Funktion, unveraendert) — findet den Benutzer weiterhin, dann gebundener `lastLoginAt`-Schreibzugriff | Anmeldung funktioniert unveraendert | — |
+| `requestPasswordReset` (`POST /auth/request-reset`) | ja | Sucht ueber `auth_lookup_user_by_email` (Funktion, unveraendert), dann gebundene Token-Anlage | Unveraendert, immer `200` (T-02-12) | — |
+| `resetPassword` (`POST /auth/reset-password`) | ja | Sucht ueber `auth_lookup_reset_token` (Funktion, unveraendert), dann gebundenes Kennwort-Update und Token-Markierung | Unveraendert | — |
+| `login`/`logout` | ja/nein | Kein Datenbankzugriff | Keins | — |
+| `getMe` (`GET /auth/me`) | nein | Vor diesem Plan: ungebundener `findUnique` liefert `null` (`auth-getme-generierter-client-ungebunden-liefert-null`) statt der eigenen Zeile | `200` mit leerem Rumpf statt der Profildaten | Ja — verschluckt, siehe (h3) |
+| `changePassword` (`POST /auth/change-password`) | nein | Vor diesem Plan: ungebundener `findUnique` liefert `null` | `UnauthorizedException('User not found or has no local password')`, `401` | Ja — als `networkError`, siehe (h3) |
+| `adminResetPassword`, ADMIN-Zweig (`POST /auth/admin-reset-password/:userId`) | nein | Vor diesem Plan: ungebundener `findUnique` sieht Ziele JEDES Mandanten — Rechteausweitung ueber die Mandantengrenze (T-FH9-01), kein Frontend-Aufrufer | `BadRequestException('User not found')` nur, wenn die Kennung gar nicht existiert; ein fremdmandantiges Ziel wuerde heute GEFUNDEN | Kein UI-Aufrufer (gemessen, Befund D) |
+| `adminResetPassword`, SUPER_ADMIN-Zweig | nein | Dieselbe Ausweitung; zusaetzlich keine Rollenpruefung des Ziels (T-FH9-04) | Dieselbe Meldung | Kein UI-Aufrufer |
+
+Nach der Bindung (Aufgabe 2) loest der SUPER_ADMIN-Zweig den Mandanten des
+Ziels ueber den gebundenen Fan-out `UserService.findByIdForPlatformAdmin`
+auf — denselben Praezedenzfall, den `user.controller.ts` (`resolveTargetUser`,
+260910-das) fuer seine eigene Rollenverzweigung benutzt; der ADMIN-Zweig
+bindet dagegen an `currentUser.tenantId` aus dem Sitzungsnachweis.
+
+### (h3) Welcher Code Leere als Abwesenheit deutet
+
+Die `getMe`-Kette, alle vier Glieder namentlich: `getMe` liefert `null` (die
+Belegzeile `auth-getme-generierter-client-ungebunden-liefert-null`) →
+`AuthController.me` gibt `null` zurueck, ohne zu werfen → NestJS'
+`ExpressAdapter.reply` sendet bei `isNil(body)` einen LEEREN Rumpf mit
+Status `200` (`apps/api/node_modules/@nestjs/platform-express/adapters/express-adapter.js`,
+Methode `reply`) → `fetchCurrentUser` (`apps/web/src/lib/auth-actions.ts`)
+laeuft mit `response.json()` auf den leeren Rumpf, faengt im `catch` und
+liefert `null` → `apps/web/src/components/layout/header.tsx` (`if (u)
+setUser(...)`) und `apps/web/src/components/settings/account-settings-form.tsx`
+(`if (u) ...`) tun bei `null` NICHTS. Folge: die Portalhuelle rendert OHNE
+angemeldeten Benutzer — kein Name, kein Avatar, `isAdmin` falsch, Admin-
+Navigation weg. Der Auftrag vermutete hier "laut"; die Lesung ergibt
+**verschluckt**: `fetchCurrentUser` liefert fuer "nicht angemeldet" und
+"Zeile unsichtbar" denselben Wert `null` — das ist NICHT die Familie eines
+lauten Fehlers, sondern dieselbe Familie wie WINDOWS #23/#25/#26. Die Seite
+`apps/web/src/app/(portal)/change-password/page.tsx` haengt an demselben
+Aufruf; `ForcePasswordChangeInterceptor` laesst `/auth/me` und
+`/auth/change-password` ausdruecklich durch, weil der erzwungene
+Kennwortwechsel `getMe` braucht.
+
+`changePassword`: der gebundene `findUnique` liefert nach der Bindung `null`
+fuer ein fremdmandantiges Ziel (kommt hier praktisch nicht vor — der
+angemeldete Benutzer sucht sich selbst) → `UnauthorizedException('User not
+found or has no local password')`, `401` → `auth-actions.ts` uebersetzt NUR
+die woertliche Meldung `Current password is incorrect` in
+`wrongCurrentPassword`, jede andere 401-Meldung in `networkError` — der
+Nutzer saehe eine Netzwerkfehler-Meldung fuer einen Trennungsfehler. Der
+Auftrag vermutete "falsches altes Kennwort"; gemessen ist es `networkError`.
+
+`adminResetPassword`: `BadRequestException('User not found')`, `400`, kein
+UI-Aufrufer (Befund D) — fuer einen API-Aufrufer bedeutet das "diesen
+Benutzer gibt es nicht", und fuer ein fremdmandantiges Ziel ist das NACH der
+Bindung dieses Plans die RICHTIGE Antwort: sie macht keine Aussage ueber die
+Existenz oder den Mandanten eines fremden Halters (dieselbe Form wie
+T-DAS-08).
+
+### (h4) Was dieser Durchlauf bewusst nicht löst
+
+**(a) Etappe 3.** Die Etappe-3-Entscheidung (1) macht `username` (und
+`email`) je Mandant eindeutig. Davon betroffen, alles NICHT dieser Auftrag:
+`auth_lookup_user_by_username(p_username)` (stuetzt sich heute auf `username
+@unique` plattformweit; braucht kuenftig `(p_tenant_id, p_username)` — die
+Funktion wird dabei ENGER, zwei Gleichheitsbedingungen statt einer, nicht
+weiter), gegebenenfalls `auth_lookup_user_by_email`, `local.strategy.ts`
+(kennt nur `username`/`password`, braucht eine Mandantenangabe VOR der
+Suche), die `@unique`-Indizes auf `User`, `UserService.findByUsername`,
+`resolveEmailForWrite` (ldap), die P2002-Uebersetzung in `UserService.create`/
+`update` (WINDOWS #22). Dieser Plan ist dafuer NEUTRAL: die Bindung der drei
+Methoden haengt am Claim `tenantId` (das es unabhaengig davon gibt, WIE der
+Anmeldeweg den Mandanten ermittelt) und an `User.id` (plattformweite UUID,
+Kette aus 260911-cwh: Schema → `auth.service.ts` `sub: user.id` →
+`JwtStrategy.validate` → `@CurrentUser().id`) — nicht an `username`/`email`.
+Unterlassen, damit Etappe 3 nicht schwerer wird: Selbstbedienung ueber
+`req.tenantId` binden; den Mandanten irgendwo nach der Anmeldung aus
+`username`/`email` ableiten; die Funktionen um Spalten erweitern.
+
+**(b) Die Rechteausweitung ADMIN → SUPER_ADMIN im Schwesterweg.**
+`apps/api/src/user/user.controller.ts`, `update` (Zeilen 172-208) prueft mit
+T-02-08 nur, ob die Rolle `SUPER_ADMIN` NEU ZUGEWIESEN wird
+(`dto.role === Role.SUPER_ADMIN`), nicht, ob das ZIEL diese Rolle bereits
+HAT — `password`/`isActive` im `UpdateUserDto` gehen fuer ein bestehendes
+`SUPER_ADMIN`-Ziel ungeprueft durch. `remove` (Zeilen 220-244) prueft
+ueberhaupt keine Rolle des Ziels, nur Selbstloeschung und Mandantengrenze.
+Erneut gelesen (260911-fh9, Aufgabe 1): beide Luecken bestehen unveraendert
+— `grep -n "Role.SUPER_ADMIN" apps/api/src/user/user.controller.ts` findet
+nur die eine Stelle in `update` (`dto.role === Role.SUPER_ADMIN`), keine im
+`user`-Objekt selbst. Kein Mandantenproblem, sondern Rechteausweitung
+INNERHALB des Mandanten — derselbe Fall wie T-FH9-04 in diesem Plan, nur am
+Schwesterweg. Reparatur in einem Satz: die Rolle des ZIELS pruefen (ist
+`user.role === Role.SUPER_ADMIN` und der Aufrufer nicht `SUPER_ADMIN`,
+`ForbiddenException`) — die Vorlage steht seit dieser Aufgabe in
+`AuthService.adminResetPassword`. Ausserhalb der Erlaubnisliste dieses
+Plans, deshalb Ledger-Eintrag statt Reparatur (Aufgabe 3, T-FH9-05).
+
+**(c) Das Frontend, das `null` verschluckt.** Nicht angefasst (siehe (h3));
+Ledger-Eintrag in Aufgabe 3, Familie #23/#25/#26.
+
+**(d) Die fehlende Existenzpruefung des `x-tenant-id`-Werts.** Bekannt aus
+`(n4)(f)` des Abschnitts `## Bereich tenant`; hier nur genannt, weil sie die
+Entscheidung gegen `req.tenantId` fuer Selbstbedienung stuetzt — ein
+SUPER_ADMIN kann per `x-tenant-id` eine erfundene Kennung schicken, sie
+bindet an einen leeren Kontext, kein Leck. Nicht dieser Auftrag.
+
+**(e) Die Etappe-4-Vorabpruefung.** Fuer einen bekannten Benutzer die Zeile
+ueber die Wartungsrolle lesen und den gebundenen `findUnique` unter seinem
+Claim-Mandanten daneben halten — dieselbe Form wie bei den Bereichen `user`
+und `tenant`.
+
+**(f) `changePassword` hat zwei verschiedene 401-Meldungen.**
+`User not found or has no local password` (kein lokales Kennwort, z. B.
+LDAP-Konto) vs. `Current password is incorrect` (falsches Kennwort) —
+bestehendes Verhalten, betrifft nur die eigene Zeile des angemeldeten
+Benutzers, unveraendert in diesem Plan.
+
+### (h5) Was dieser Durchlauf bewusst nicht anfasst
+
+- Die drei SECURITY-DEFINER-Funktionen aus Etappe 1
+  (`auth_lookup_user_by_username`, `auth_lookup_user_by_email`,
+  `auth_lookup_reset_token`) und ihre Migration `20260909160000_auth_lookup_functions`
+  — belegt durch `git diff --name-only 6236b30 -- apps/api/prisma` (leer)
+  und die `pg_proc`-Messung aus (h1).
+- Die drei `$queryRaw`-Aufrufe in `validateUser`, `requestPasswordReset`,
+  `resetPassword` — bleiben auf dem ungebundenen Klienten `this.prisma`.
+- `local.strategy.ts` und `jwt.strategy.ts` — nur gelesen.
+- `apps/api/src/auth/dto/admin-reset-password.dto.ts` — nur gelesen, kein
+  Mandantenfeld.
+- `docs/mandantentrennung-datenbankrolle.md`, Abschnitt 3 — beschreibt die
+  Anordnung des Anmeldewegs korrekt, keine Aenderung noetig.
+- `docs/anleitung-entwicklung.md` — nennt keine der drei Methoden.
+- `apps/api/src/user/user.controller.ts` — nur gelesen (siehe (h4)(b)).
+- Das Frontend (`header.tsx`, `account-settings-form.tsx`, `auth-actions.ts`,
+  `change-password/page.tsx`) — nur beschrieben, nicht geaendert.
+- Schema und Migrationen.
+- Die Kopfzeile in `auth.service.spec.ts` (Zeile 4-6), die auf ein Muster in
+  `ldap.service.spec.ts` verweist — wird in Aufgabe 2 ersetzt, hier nur als
+  Befund F genannt.
+
 ## Verweis
 
 Die Bestandsaufnahme, welche Fundstelle den hier beschriebenen Übergang