- Migration 20260909140000_rls_remaining_tenant_tables ergaenzt ENABLE +
FORCE ROW LEVEL SECURITY und je eine tenant_isolation_policy fuer alle 16
noch offenen Tabellen mit tenantId
- Kopfkommentar korrigiert die zu pauschale D-03-Aussage aus
20260804130918: nur die drei Tender-Tabellen OHNE tenantId sind davon
betroffen, die sechs MIT tenantId bekommen jetzt eine Policy — die alte
Migrationsdatei bleibt unveraendert
- rls-coverage.spec.ts misst die Abdeckung aus Schema und Migrationen
statt Text zu vergleichen (rot mit 16 gemeldeten Luecken vor der
Migration, jetzt gruen); waechst automatisch mit kuenftigen Modellen und
erzwingt bei jedem neuen tenantId-losen Modell eine bewusste Entscheidung
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
- apps/api/scripts/rls-preflight.mjs misst fuenf benannte Eigenschaften
(rollenrechte, kontext-setzbar, ohne-kontext-leer, mit-kontext-sichtbar,
schreibrechte) jeweils in einer eigenen Transaktion gegen eine per
TESSERA_PREFLIGHT_DATABASE_URL angegebene Verbindung; --print-plan
verbindet nicht, das Werkzeug schreibt in keiner Betriebsart
- 5 Tests in rls-preflight.spec.ts (rot vor dem Werkzeug, jetzt gruen)
- docs/mandantentrennung-datenbankrolle.md: Befund, Sperrgrund (182
unskalierte Zugriffe, Anmeldeweg), Handgriffe des Betreibers samt
Kennwortsetzung, Freigabebedingung und Rueckweg; docs/README.md verweist
darauf
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
- apps/api/scripts/migrate-and-start.sh: TESSERA_MIGRATE_DATABASE_URL fuer
den Migrationsschritt, DATABASE_URL bleibt unveraendert fuer den
Laufzeitschritt; leer/nicht gesetzt = bisheriges Verhalten
- Dockerfile kopiert scripts/ und ruft das Skript als CMD auf; exec statt
&&-Verkettung, damit Signale den Node-Prozess erreichen
- docker-compose.yml/.prod.yml reichen TESSERA_MIGRATE_DATABASE_URL durch
(leerer Vorgabewert); docker-compose.dev.yml/.ci.yml unveraendert
- .env.example erklaert beide Variablen mit Platzhaltern, Umstellung bleibt
auskommentiert
- 5 Tests in start-script.spec.ts (rot vor dem Skript, jetzt gruen)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
- Migration 20260909130000_rls_app_role legt tessera_app mit NOSUPERUSER
NOBYPASSRLS wiederholbar an bzw. konvergiert eine vorhandene Rolle darauf
- Kein Kennwort im SQL, Datenbankname und Eigentuemer dynamisch gebildet
- 7 Tests in rls-app-role.spec.ts (rot vor der Migration, jetzt gruen)
- Rolle wird von niemandem benutzt — WINDOWS #18 bleibt offen
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
WINDOWS #18: RLS ist heute wirkungslos, weil die Anwendungsrolle
Superuser ist und BYPASSRLS traegt. Der Plan folgt der vorgegebenen
Reihenfolge — erst die Rolle ohne Umgehungsrecht, dann der Nachweis,
dann die Ausweitung auf die 16 fehlenden Tabellen.
Gemessen und im Plan festgehalten: 182 Zugriffe im API-Quelltext laufen
ueber den unskalierten Prisma-Client (nur 19 ueber tenantPrisma),
darunter der Anmeldeweg selbst. Ein Umlegen des Schalters wuerde die
Anwendung aussperren; der Plan bereitet die Umstellung deshalb vor und
misst sie, vollzieht sie aber nicht.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Beim Vorbereiten der RLS-Ausweitung gemessen: die API verbindet als Rolle
'tessera' (docker-compose.yml:33), und diese Rolle hat rolsuper=t und
rolbypassrls=t. PostgreSQL wendet Row-Level-Security auf solche Rollen nicht
an; FORCE ROW LEVEL SECURITY hilft nicht, das betrifft nur den
Tabelleneigentuemer.
Praktisch belegt statt hergeleitet: ohne gesetztes app.current_tenant liefert
SELECT count(*) FROM "Group" zwei Zeilen, obwohl die Policy bei NULL-Kontext
null liefern muesste.
Folge: alle sieben bisher mit RLS ausgestatteten Tabellen sind faktisch
ungeschuetzt. Die Trennung haengt allein am manuellen where-tenantId im Code.
Die Migration 20260804130918 beschreibt RLS als 'zweites Sicherheitsnetz' —
dieses Netz existiert derzeit nicht.
Das aendert die Reihenfolge der geplanten Arbeit: erst eine Anwendungsrolle
ohne Superuser- und BYPASSRLS-Recht, dann greifen die vorhandenen Policies,
erst danach lohnt das Ergaenzen fehlender Tabellen. Sonst baut man Regeln, die
nichts tun und Sicherheit vortaeuschen.
Kein akutes Risiko: Tessera laeuft intern mit einem einzigen Mandanten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Zwei kleine, unabhaengige Reparaturen in getrennten Commits (dab72eb, c807049).
Bemerkenswert an der Versionskorrektur: sie hat sechs Empfehlungen zutage
gefoerdert, die nie eingebaut wurden — Keycloak als Identitaetsanbieter, Redis,
TanStack Query, shadcn/ui, Playwright als Projektabhaengigkeit und Husky. Die
stehen jetzt in einem eigenen Abschnitt 'Recommended But Not Adopted', damit
niemand sie beim Lesen fuer vorhanden haelt. Ausserdem laeuft Vitest in den
beiden Anwendungen in unterschiedlichen Hauptfassungen (3.2.6 gegen 4.1.9).
Der Technik-Block in CLAUDE.md ist generiert. Eine Korrektur allein dort waere
bei der naechsten Regeneration still zurueckgeholt worden, deshalb zusaetzlich
ein Herkunftsvermerk im Block und eine datierte Hinweiszeile in der
Recherchedatei, deren Zahlen unveraendert bleiben.
Nebenbei zwei Verfaelschungen in STATE.md zurueckgesetzt, die Werkzeugaufrufe
hinterlassen hatten: eine Platzhalterzeile in der Quick-Task-Tabelle und
verfaelschte Fortschrittszahlen (3/82 statt 17/83).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
- CLAUDE.md Technik-Block zeigt jetzt den installierten Stand statt der
2026-06/07-Empfehlung: Next.js 15.5.19, Prisma 6.19.3, NestJS 11.1.27,
Express 5.2.1, Node node:24-alpine (neu ergaenzt), Vitest je App
(3.2.6 / 4.1.9), Docker/Compose als gemessene Wirtseigenschaft
- Authentifizierungs-Zeilen ersetzt: kein Identitaetsanbieter im Einsatz,
sondern @nestjs/jwt, passport/@nestjs/passport, argon2, ldapts;
@nestjs/passport-Zweckangabe korrigiert (Anmelde-/JWT-Strategien statt
Modul-zu-Modul-API-Keys)
- Nie uebernommene Empfehlungen (Keycloak, Redis, TanStack Query, shadcn/ui,
Playwright, Husky, lint-staged) sowie die beiden nicht aktualisierten
Hauptversionen (Next.js, Prisma) in eigenem Abschnitt "Recommended But
Not Adopted" statt in den Ist-Tabellen
- Herkunftsvermerk ergaenzt; Alternatives Considered/Version Pinning
Strategy/Sources als historische Entscheidungslage gekennzeichnet;
Multi-Tenancy Strategy verweist auf die tatsaechliche
prisma-tenant.extension.ts
- .planning/research/STACK.md erhaelt eine Hinweiszeile, Zahlen darin
unveraendert (datiertes Rechercheergebnis)
- Keine Abhaengigkeit aktualisiert (package.json/pnpm-lock.yaml
unveraendert, per Gate geprueft)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
- docker-compose.yml und docker-compose.prod.yml mounten /app/user-files
im Dienst api auf ein neues benanntes Volume user-files (Eigentuemerschaft
uid 1001 folgt aus dem Image, kein Bind-Mount)
- docker-compose.dev.yml bleibt unveraendert (Compose fuehrt Mount-Listen
ueber das Ziel zusammen)
- Betriebshandbuch Kapitel 6: Speicher als dauerhaft beschrieben, Mount-Zeile
woertlich zum Kopieren, Hinweis dass /opt/tessera/docker-compose.yml auf
dem Server separat gepflegt werden muss (Deploy erreicht sie nicht)
- Betriebshandbuch Kapitel 7: Fehlerzeile zu verschwundenen Avataren/Exporten
an den reparierten Repository-Stand angepasst
WINDOWS #17 bleibt offen, bis die Serverdatei manuell ergaenzt ist.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Zwei unabhaengige Aufgaben: user-files als benanntes Volume in beide
Repository-Compose-Dateien plus Betriebshandbuch Kapitel 6/7 (WINDOWS #17),
und die Technik-Tabelle in CLAUDE.md auf den installierten Stand bringen.
Beide Abnahmetore vor der Arbeit als rot gemessen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Bisher gab es fuer Kollegen keine Dokumentation: im Projekt lagen nur das
CI/CD-Runbook und die Arbeitsanweisungen fuer die Entwicklung. Diese Luecke
schliessen vier Anleitungen plus eine Einstiegsseite unter docs/.
Alle vier wurden gegen den Quelltext geschrieben, nicht aus der Planung
abgeleitet, und anschliessend unabhaengig gegengeprueft: jede zitierte
Beschriftung ist woertlich aus de.json belegt, jede beschriebene Funktion im
Code nachgewiesen, alle Befehle und Pfade gegen die echten Compose-Dateien,
Dockerfiles und package.json-Skripte verifiziert. Die Gegenpruefung fand keine
falsche Aussage.
Die Einstiegsseite hebt die drei Punkte hervor, die in der Praxis am meisten
Zeit gekostet haben: Anmeldung ueber den Benutzernamen statt der E-Mail,
der Unterschied zwischen aktiviert und freigegeben, und dass ein blosses
'up -d' die laufenden Container nicht ersetzt.
Nebenbefund beim Schreiben des Betriebshandbuchs, als #17 im Ledger erfasst:
user-files/ ist in keiner Compose-Datei als Volume eingebunden — hochgeladene
Profilbilder und DKV-Exporte ueberleben kein --force-recreate. Noch ohne
Schaden, da bisher kein Nutzer ein Profilbild hinterlegt hat.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Auf Entscheidung des Users vom 2026-09-09. Der Wunsch bleibt bestehen, hat aber
keine Dringlichkeit und wird nicht mehr als naechster Bau-Kandidat vorgelegt —
erst wieder aufgreifen, wenn der User ihn von sich aus nennt.
Damit ist derzeit kein naechster Schritt vorgemerkt: das Ledger ist leer, und
alle verbliebenen Punkte ruhen bewusst (Postfach-Test mangels Postfach,
Mandantentrennung solange Tessera intern laeuft, Lizenzpruefung bis alle Module
intern laufen, Branding ab jetzt).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Abnahme im Browser auf alpha gegen das echte AD, nachdem der User die Container
neu erstellt hatte. Voraussetzungen gemessen statt angenommen: Container
tatsaechlich getauscht, Migration 20260909120000_user_email_optional angewandt,
User.email is_nullable = YES. Die Migration lief beim API-Start automatisch mit.
#15 — der Sync meldet jetzt "Erstellt: 4" statt vier stiller Fehlschlaege. Die
kollidierenden Konten sind angelegt und aktiv, ohne Adresse; mbuntz behaelt als
erster Anspruch seine. Der Bericht zeigt zwei verstaendliche deutsche
Abschnitte statt Prisma-Text und englischer Meldungen. Die beiden Folgestellen
vertragen Konten ohne Adresse: die Benutzerliste zeigt einen Gedankenstrich,
und die Suche im Mitglieder-Dialog liefert die Konten sauber statt
abzustuerzen — das war der eigentliche Fallstrick.
#14 — die Matrix-Suche laesst die nicht getroffene Achse stehen. Alle vier
Faelle geprueft: Modulname behaelt die Gruppenspalten, Gruppenname behaelt die
Modulzeile, der AD-Name findet dieselbe Spalte wie der interne Name
(Regression #6c intakt), und eine Suche ohne Treffer erklaert sich in einem
verstaendlichen Satz.
Am Active Directory wurde nichts veraendert; es wurde nur gelesen. Der fuer die
Regressionsprobe gesetzte interne Name ist wieder geleert.
Ledger danach: 0 offen, 15 behoben, 1 zurueckgestellt (#12 — es gibt intern
kein Postfach fuer Ausschreibungs-Alarme).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Verifikation unabhaengig nachgemessen: 651/651 API-Tests, 233/233 Web-Tests,
beide Typpruefungen sauber.
Der Sicherheitsfund T-Q3-01 wurde nicht nur gruen getestet, sondern
falsifiziert: der Verifizierer hat die neue Besitzpruefung testweise
zurueckgebaut, woraufhin der Test fehlschlug und die fremde Adresse
tatsaechlich in prisma.user.update() landete. Danach sauber zurueckgesetzt.
Ebenso gegengeprueft: beide Anlege-Wege (Sync und Einzelimport) nutzen
denselben Kollisionsentscheider, im ausgelieferten Code stehen keine
kundenspezifischen Namen oder Adressen, rohe ORM-Texte erreichen die
Oberflaeche nicht mehr, und die Gruppensuche unter internem wie AD-Namen
(#6c) ist per Regressionstest gesichert.
Eine Abweichung des Ausfuehrenden ist dokumentiert und bestaetigt: die im
Plan vorgesehene Testvorlage war wegen Kurzschlussauswertung schon gegen den
unveraenderten Code gruen; mit einem zweiten, nicht passenden Konto
reproduziert sie den Absturz nun wirklich.
Status human_needed: die fuenf Browser-Pruefungen brauchen einen Neubau und
sind Sache des Users. WINDOWS #14 und #15 bleiben bis dahin offen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
- admin/ldap/page.tsx: SyncResult um emailConflicts/skippedNoLogin/
entryFailures erweitert; drei neue Berichtsabschnitte (Bernstein fuer
Kollisionen, neutral fuer fehlenden Anmeldenamen, destruktiv fuer
unerwartete Fehler) — kein englischer Techniktext, kein roher
Datenbank-Wortlaut mehr im Bericht
- GroupMembersModal.tsx: TenantUser.email optional, Suchvergleich gegen
leere Adresse abgesichert (WINDOWS #15) — die Mitgliedersuche stuerzt
nicht mehr ab, sobald ein Konto ohne Adresse existiert
- users/page.tsx: User.email optional, Formular faellt auf leere
Zeichenkette zurueck, Tabellenzelle zeigt einen Gedankenstrich;
UserFormData.email bleibt bei Handanlage Pflicht
- Neue Sprachschluessel unter admin.ldap.sync in de.json/en.json,
Umlaut- und Sprachschluessel-Gate bestaetigt gruen (kein neues
Allowlist-Wort noetig)
- Neuer Testfall in groups-page.test.tsx vorab gegen den unveraenderten
Bestand rot gelaufen; Abweichung von der Plan-Fixture dokumentiert
(Kurzfassung: ein einzelnes Konto mit passendem Benutzernamen loest die
Kollision wegen OR-Kurzschlussauswertung nie aus, ein zweites,
nicht-treffendes Konto ohne Adresse schon — Vollfassung im SUMMARY)
- 651/651 API- und 233/233 Web-Tests gruen, beide Typpruefungen sauber
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
- User.email auf optional gestellt (Migration geschrieben, NICHT
ausgefuehrt); Eindeutigkeitsindex unangetastet, NULL bleibt in Postgres
je verschieden
- Neuer Kollisionsentscheider (resolveEmailForWrite) in ldap.service.ts:
eine bereits vergebene Adresse wird nie umgehaengt (T-Q3-01) — das
zuerst angelegte Konto behaelt sie, jedes weitere Konto entsteht ohne
Adresse (gesperrte Nutzerentscheidung 2026-09-09, WINDOWS #15)
- Entscheider in upsertMappedUser (Sync) UND importUsersByDn (Handimport)
verdrahtet, damit der zweite Anlageweg nicht als Luecke bestehen bleibt
- LdapSyncResult um emailConflicts/skippedNoLogin/entryFailures erweitert;
rohe ORM-Ausnahmetexte gehen nur noch an logger.error, nie in den
Bericht (T-Q3-02)
- UserService.create nimmt die Adresse optional entgegen; Tender-Digest
und Instant-Alert ueberspringen Empfaenger ohne Adresse (continue)
- Fuenf neue Testfaelle vorab gegen den unveraenderten Bestand rot
gelaufen (erwartete Ursachen bestaetigt); 651/651 API-Tests gruen,
prisma validate und type-check sauber
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
- Gemeinsamer useMemo ermittelt moduleHits/groupHits getrennt; trifft der
Suchbegriff nur eine Achse, bleibt die andere vollstaendig sichtbar
(WINDOWS #14) statt leerzulaufen
- Regressionsschutz fuer WINDOWS #6c erhalten: Spaltensuche findet eine
importierte Gruppe weiterhin unter internem UND AD-Namen
- Neue Meldung adminModules.grants.noSearchResults, wenn ein Begriff weder
Modul noch Gruppe trifft — Tabelle wird dann nicht gerendert
- Vier neue Testfaelle in grants-matrix.test.tsx vorab gegen den
unveraenderten Bestand rot gelaufen (erwartete Ursachen bestaetigt)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
WINDOWS #14 (Suche leert die jeweils andere Achse der Freigaben-Matrix) und
WINDOWS #15 (roher Prisma-/englischer Techniktext im AD-Sync, vier Konten
wegen geteilter E-Mail-Adresse nie importiert) als drei getrennte Tasks.
Gesperrte Nutzerentscheidung vom 2026-09-09: kollidierende Konten werden
angelegt, nur ohne Adresse. Dafuer wird User.email optional — Migration wird
geschrieben, nicht ausgefuehrt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Abnahme im Browser auf alpha gegen den echten Exchange owa.ctl.de, nachdem die
Container mit --force-recreate getauscht waren. Der blosse pull genuegte nicht:
die neue Route fehlte im laufenden Container und war im gezogenen Image
vorhanden — hart belegt statt vermutet.
Alle vier Punkte bestanden:
- gespeicherte Konfiguration mit LEEREM Passwortfeld meldet "Verbindung
erfolgreich" — belegt zugleich den Rueckgriff auf die gespeicherten
verschluesselten Zugangsdaten
- absichtlich falscher Server meldet "Verbindung fehlgeschlagen: getaddrinfo
ENOTFOUND owa-gibtsnicht.ctl.de"
- keine Zugangsdaten im API-Protokoll (die Treffer einer Mustersuche waren
Routennamen wie /auth/reset-password)
- der Test schreibt nichts; die gespeicherte Konfiguration blieb unveraendert
Nebenbefund mit Gewicht: das Protokoll zeigt eine echte Antwort von Exchange
2019 (ServerVersionInfo 15.2) samt aufgeloester FolderId. Der in Plan 14-03 als
fragil markierte, handgeschriebene NTLM/SOAP-Weg ist damit erstmals gegen einen
echten Server gemessen — bisher lag nur gemocktes httpntlm.post vor.
WINDOWS #12 zurueckgestellt (waived): es gibt intern kein Postfach, in das
Ausschreibungs-Alarme hereinkommen. Ein frueheres Missverstaendnis hatte eines
angenommen. Nachzuholen, sobald ein solches Postfach existiert; offen ist dann
allein das Einlesen einer echten Alarm-Mail.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Abschluss-Dokumentation zum nachgeruesteten Verbindungstest (WINDOWS #16).
Verifikation unabhaengig nachgemessen, nicht aus dem Ausfuehrungsbericht
uebernommen: 646/646 API-Tests, 228/228 Web-Tests, beide Typpruefungen
sauber, und das Sprachschluessel-Gate ist von rot ("de fehlt testConnection")
auf gruen gewechselt. Sicherheitsseitig geprueft: die DTO traegt kein
Eigentuemer-Feld, der Handler zieht userId ausschliesslich aus dem
Auth-Kontext (eigener IDOR-Test mit Koeder-userId), Rueckfall auf gespeicherte
Zugangsdaten sucht nur ueber denselben userId, und in den geaenderten Dateien
findet sich keine Log- oder Antwortstelle mit Zugangsdaten.
Status bleibt human_needed: die Browser-Abnahme gegen ein echtes Postfach
steht aus und braucht einen Neubau durch den User. WINDOWS #16 bleibt
deshalb offen.
Ausserdem workflow.use_worktrees auf false: origin/HEAD ist in diesem Repo
nicht aufloesbar, der Basis-Check des Workflows verlangt daher selbst
sequenzielle Ausfuehrung ("fork-ref-unknown"). Ein isolierter Arbeitsbaum
wuerde von einem veralteten Stand abzweigen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
- testEmailConnection im API-Klienten, POST email-config/test
- EmailAlertConfigForm: Testknopf vor Speichern, Wartezustand, gruene/rote
Rueckmeldung, Formularaenderung raeumt vorherige Rueckmeldung weg
- Beschreibungsblock der Komponente korrigiert (Knopf existiert jetzt)
- Vier neue Schluessel unter tenderRadar.emailAlerts in de/en
- vi.mock-Fabriken in EmailAlertConfigForm.test.tsx und my-sources.test.tsx
um testEmailConnection erweitert, zwei neue Testfaelle
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
- TenderEmailConfigService.testConnection(userId, dto) mit Rueckfall auf
gespeicherte, entschluesselte Zugangsdaten bei leeren Feldern
- TendersController: POST email-config/test, userId aus Auth-Kontext,
deklariert vor @Get(':id')
- Beide Provider (ImapProvider/ExchangeInboxProvider) optional angehaengt,
bestehende 2-Arg-Konstruktoraufrufe bleiben typkorrekt
- Reihenfolge-Waechter und IDOR-Testfall ergaenzt
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Schliesst WINDOWS #16. Zwei Tasks: Endpunkt POST email-config/test
(Dienst + Route + Reihenfolge-Waechter) und Knopf 'Verbindung testen'
im Formular unter Meine Quellen samt Beschriftungen in beiden Sprachen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Das Postfach-Formular im Ausschreibungs-Radar hat keinen Verbindungstest,
obwohl beide Inbox-Provider testConnection() mitbringen und das DKV-Modul
sie ueber POST /dkv/test-connection samt Knopf bereits nutzt.
Historie geprueft: der Knopf war nie vorhanden — die Formular-Datei hat nur
zwei Commits (Erstellung 48e1252, Sprachumstellung 849aa9b), und eine Suche
ueber alle Zweige nach testConnection, test-connection, "Verbindung testen"
und passenden Uebersetzungsschluesseln findet fuer tender-radar nichts. Es
ist eine Luecke, keine Regression.
Ausserdem der Bildschirmabzug des Postfach-Formulars im Exchange-Modus als
Referenz fuer die Einrichtung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Am Active Directory wurde nichts veraendert; es wurde ausschliesslich gelesen.
Die beiden verbliebenen Pruefpunkte liessen sich auf der Tessera-Seite
ausloesen, weil der Sync nur vergleicht, was er gespeichert hat, mit dem, was
im Verzeichnis steht — ob eine Abweichung aus einer AD-Aenderung stammt oder
aus einem verfaelschten Group-Datensatz, kann er nicht unterscheiden.
#4 / A1 (Umbenennung bricht die Bindung nicht): Gruppe Albphone_Technik_VT neu
importiert, danach in der Datenbank Name und DN auf einen veralteten Stand
gesetzt, objectGUID echt gelassen. Der Sync fand die Gruppe allein ueber den
objectGUID und schrieb den AD-Namen zurueck — "1 umbenannt". Nicht gemessen,
weil dafuer das Verzeichnis geaendert werden muesste: dass AD den objectGUID
bei einer Umbenennung stabil haelt. Das ist zugesicherte AD-Eigenschaft und
kein Tessera-Code; der Anteil, der schiefgehen konnte, ist gemessen.
#6 / b (Amber-Zeile): dieselbe Gruppe zur Standardgruppe gemacht, dann ihren
gespeicherten objectGUID ins Leere zeigen lassen. Ergebnis: "1 geloescht" plus
die amber gefaerbte vierte Zeile "Standardgruppen-Markierung musste neu
vergeben werden (1x)". Die Markierung wanderte vor der Loeschung zurueck — die
Korrektheitszusage von D-06 haelt.
Ledger: #4 und #6 auf fixed. Offen bleiben #12 (braucht ein echtes
Exchange-Postfach), #14 und #15 (in dieser Sitzung neu gefunden).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Der Versuch, eine Wegwerf-Gruppe fuer den Livetest anzulegen, scheiterte mit
INSUFF_ACCESS_RIGHTS. Das Dienstkonto svc_tessera darf am Verzeichnis nur
lesen — vom User bestaetigt als gewollt, nicht als Luecke.
Folge, jetzt an drei Stellen dokumentiert (Livetest-Bericht, Deferred Items,
Ledger-Kontext): WINDOWS #4/A1 und #6b sind grundsaetzlich nicht aus Tessera
heraus belegbar. Beide brauchen eine Handlung durch einen AD-Administrator;
danach sind sie messbar. Kein Anlass, das Rechtekonzept zu aendern oder
Schreibrechte zu erbitten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Auf alpha gegen das echte Active Directory balios.ctl.local geprueft.
Belegt:
- WINDOWS #4 / Annahme A2 (byteweise Filter-Syntax): read-only gemessen.
EqualityFilter ueber rohen Buffer findet Claude_VT (DN und objectGUID
stimmen mit der Tessera-DB ueberein), der frueher verwendete escapte
Hex-String findet nichts. Der erwartete DN stammt aus der Datenbank,
nicht aus der Filter-Hilfsfunktion — sonst waere die Messung tautologisch.
- WINDOWS #6 Teil (a): Sync ausgeloest, alle drei Zahlenzeilen erscheinen.
- WINDOWS #6 Teil (c): die Spalte ist in der Freigaben-Matrix sowohl unter
dem internen Namen als auch unter dem AD-Namen auffindbar.
Weiterhin offen, weil Schreibzugriff im Verzeichnis noetig:
- #4 / A1 (objectGUID uebersteht Umbenennung)
- #6 Teil (b) (Amber-Zeile bei verschobener Standardmarkierung). Ueber den
konfigurierten Suchbereich nicht nachstellbar — die WR-03-Weitsuche
verhindert das zu Recht.
Neu im Ledger:
- #14: Die Suche in der Freigaben-Matrix filtert beide Achsen mit demselben
Begriff. Ein Begriff, der nur eine Achse trifft, leert die andere ganz —
es bleibt nie ein Kaestchen zum Klicken. Damit scheitert genau der Zweck
der Suche.
- #15: Der Sync reicht rohe Prisma-Fehler und englische Techniktexte an den
Administrator durch. Vier AD-Konten aus OU=CTL_PWS_Gruppen werden wegen
einer geteilten E-Mail-Adresse nie importiert, ohne verstaendlichen Hinweis.
Der Testzustand wurde zurueckgesetzt: Cert Manager wieder deaktiviert,
interner Name wieder geleert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
Die beiden .continue-here.md-Dateien stammten aus abgeschlossener Arbeit
(Phase 10 vom 2026-07-21, Meilenstein-Abschluss vom 2026-08-11) und waren als
Wiedereinstiegspunkt ueberholt. Ihre noch gueltigen Inhalte standen jedoch
nirgends sonst und waeren beim Loeschen verloren gegangen:
- fuenf Anti-Patterns (tautologischer Test, HTTP 200 als Funktionsbeleg,
Image-Datum als Aktualitaets-Beleg, Server-Compose ist kein Checkout,
stale live container maskiert Fertigstellung)
- Infrastruktur-Stand von alpha inkl. der Drift zwischen /opt/tessera und
dem Repository
- der Blocker "kein AD-Schreibzugriff", der den noch offenen Live-Test
WINDOWS #4 direkt betrifft
Beides ist jetzt als eigene Abschnitte unter Accumulated Context in STATE.md
festgehalten. Ausserdem den Blocker 15-06 als erledigt markiert (die
Gegenprobe wurde am 2026-09-07 nachgeholt) und .gsd/ ignoriert — das ist
Laufzeit-Scratch, das pro Sitzung neu geschrieben wird.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
STATE.md auf den Endstand gebracht, damit ein spaeteres /gsd-resume-work den
vollstaendigen Kontext findet: was erledigt wurde, was offen ist und warum.
Erledigt in dieser Sitzung: Phase 17 auf passed; die alten Browser-Gegenproben
#1, #2, #3 und #5 nachgeholt; drei echte Defekte gefunden und behoben (#10
Zugriffs-Guard griff nicht auf modul-eigenen Routen, #11 Fingerabdruck-Dedup war
wirkungslos, #13 Tailwind-Dunkelvariante nie an .dark gebunden); Logo und Favicon
eingebaut; Umlaute, Anrede und Ein-/Mehrzahl korrigiert; Meilenstein-Buchhaltung auf
v1.2 abgeschlossen.
Offen bleiben WINDOWS #4, #6 und #12 — alle drei brauchen ein echtes Active
Directory beziehungsweise Exchange-Postfach und sind als Deferred Items mit dem
jeweiligen Pruefauftrag im Klartext vorgemerkt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Die Unterlagen fuehrten weiterhin v1.1 als laufenden Meilenstein, obwohl alle 17
Phasen und 83 Plaene ausgefuehrt sind und die Phasen 15 bis 17 zu v1.2 gehoeren. Wer
neu draufschaute, sah einen falschen Projektstand.
Korrigiert in ROADMAP.md, STATE.md und PROJECT.md:
v1.0 bleibt ausgeliefert. v1.1 traegt jetzt den ehrlichen Zwischenstand — alle Plaene
fertig, alle Phasen ausser 14 verifiziert, offen allein der Live-Test von Phase 14
gegen ein echtes Exchange-Postfach; inhaltlich abgeschlossen, formal nicht. v1.2 ist
abgeschlossen, alle drei Phasen verifiziert. Ergaenzt um den Hinweis, dass kein neuer
Meilenstein begonnen wurde und die drei verbleibenden Pruefpunkte Fremdsysteme
brauchen.
Ausserdem die Zeile zu Phase 2 praezisiert. Sie stand auf "Incomplete", was nach
liegengebliebener Arbeit klang und im Widerspruch zu v1.0 als ausgeliefertem
Meilenstein stand. Tatsaechlich sind alle vier Baupläne fertig und seit v1.0 in
Betrieb; offen ist allein die nie ausgefuehrte Browser-Abnahme, die der User am
2026-09-07 bewusst zurueckgestellt hat, weil Tessera zunaechst nur intern laeuft.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Ueber "Keine Widgets aktiv" stand noch dasselbe handgezeichnete
Vier-Quadrate-Symbol, das auf der Anmeldeseite bereits durch das Logo ersetzt wurde
— beim Logo-Einbau uebersehen, weil der leere Zustand nur ohne Widgets sichtbar ist.
Jetzt die echte Bildmarke aus der Marken-Komponente, ohne den bisherigen grauen
Rahmen und ohne Kontur: die Marke steht frei auf dem Seitenhintergrund und braucht
keine eigene Flaeche. 226 Web-Tests gruen, im Browser gegengeprueft.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Die vorherige Korrektur war zu grob: sie hat das Gelb ueberall durch die
Vordergrundfarbe ersetzt, obwohl es nur im hellen Erscheinungsbild ein Problem war.
Nachgerechnet gegen die tatsaechlichen Farbwerte aus globals.css:
Gelb auf hellem Grund 1,26 : 1 (Kopfleiste) unlesbar
Gelb auf heller Leiste 1,24 : 1 (Seitenleiste) unlesbar
Gelb auf dunklem Grund 13,06 : 1 hervorragend
Gelb auf dunkler Leiste 14,00 : 1 hervorragend
WCAG verlangt 3:1 fuer grossen fetten Text. Das Gelb faellt also nur auf hellem
Grund durch — auf dunklem ist es die mit Abstand beste Wahl.
Der Schriftzug erbt jetzt im hellen Erscheinungsbild die Vordergrundfarbe (19:1) und
traegt im dunklen die Markenfarbe. Umgesetzt ueber wordmarkClassName an den beiden
Aufrufstellen, nicht in der Komponente selbst: das gelbe Anmelde-Panel ist
themeunabhaengig hell und braucht dort weiterhin dunkle Schrift.
Im Browser in beide Richtungen gemessen: hell oklch(0.15 0 0), dunkel
oklch(0.91 0.19 102) — letzteres ist exakt --primary.
Ausserdem in STATE.md festgehalten, dass Tessera zunaechst nur intern eingesetzt wird
und die Abnahme der Mandantentrennung (Plan 02-05, Erfolgskriterium 4) deshalb
bewusst zurueckgestellt ist — nicht zurueckgebaut, und vor einem Einsatz bei externen
Kunden nachzuholen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Beide Korrekturen im Browser gegengeprueft. Der aussagekraeftigste Fall ist die
Gruppe "Alle Benutzer" mit zwei Mitgliedern und einer Freigabe: der Dialog schreibt
"2 Mitglieder und 1 Modul-Freigabe" — Mehrzahl und Einzahl im selben Satz, jede Zahl
einzeln richtig. Bei "Vertrieb Innendienst" mit je einem heisst es durchgaengig
Einzahl.
Die vier Du-Stellen sind ebenfalls im Browser bestaetigt: Aktivierungsdialog,
Sperrseite und Marktplatz-Hinweis siezen jetzt. Der Leerzustand der Gruppenliste ist
live nicht erreichbar, weil Gruppen existieren — er bleibt durch den Komponententest
abgedeckt.
Der UAT-Bericht zu Phase 15, in dem beide Maengel urspruenglich notiert wurden, ist
entsprechend nachgezogen. Dort war nur der Aktivierungsdialog als Du-Stelle vermerkt;
bei der Korrektur kamen drei weitere zum Vorschein.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Beide Zahlen im Loeschdialog-Text wurden bislang in fest formulierte
Mehrzahl-Woerter eingesetzt, weshalb "1 Mitglieder und
1 Modul-Freigaben" entstand (live beobachtet an der Gruppe "Vertrieb
Innendienst"). admin.groups.deleteConfirm.body wird in de.json und
en.json auf ICU-Plural umgestellt (memberCount und grantCount je mit
eigenem plural-Argument), im selben Stil wie das bestehende
admin.ldap.…resultSummary. Die Mock-Nachricht in groups-page.test.tsx
wird auf denselben Wortlaut nachgezogen, wodurch der zuvor rote
Einzahl-Test jetzt gruen ist; die beiden bestehenden Mehrzahl-Tests
bleiben unveraendert gruen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Der Loeschdialog schreibt bei genau einem Mitglied und einer Freigabe
faelschlich "1 Mitglieder und 1 Modul-Freigaben". Der Mock-Uebersetzer
in groups-page.test.tsx wird um eine ICU-Plural-Aufloesung erweitert
(nach dem Vorbild der bestehenden select-Aufloesung in
grants-matrix.test.tsx), und ein neuer Test mit
{ memberCount: 1, grantCount: 1 } nagelt den korrekten Einzahl-Text
fest. Der Test ist an dieser Stelle rot, da der Uebersetzungstext noch
nicht auf ICU-Plural umgestellt ist.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Die Oberflaeche siezt ueberall, ausser an vier Stellen: leere
Gruppenliste, Modul-Aktivierungsdialog, Modul-Sperrseite und
Marktplatz-Hinweis duzten bislang. Alle vier Werte in de.json werden
auf die Sie-Form umgestellt, en.json bleibt unveraendert, da Englisch
die Unterscheidung nicht kennt. Die Mock-Uebersetzer und Zusicherungen
in den drei betroffenen Testdateien werden auf den neuen Wortlaut
nachgezogen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Zwei Wortlaut-Maengel, beide am Code verifiziert: vier deutsche Texte duzen
statt zu siezen, und der Gruppen-Loeschdialog setzt zwei Zahlen in fest
formulierte Mehrzahl-Woerter ("1 Mitglieder").
Beim Planen nachgeprueft: der Mock-Uebersetzer in groups-page.test.tsx kann
kein ICU-Plural — die Umstellung wuerde die beiden bestehenden
Loeschdialog-Tests brechen. Der Plan loest das ueber dieselbe Regex-Technik,
mit der grants-matrix.test.tsx bereits ICU-select aufloest, und nagelt den
Einzahl-Fall mit einem neuen Test fest.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Die Browser-Abnahme hat drei uebersehene Stellen gefunden — "Aenderungen speichern",
"Oeffnen" und einen LDAP-Hinweis — und damit die Luecke im Waechter aufgedeckt, durch
die sie geschluepft sind: sein Verdachtsmuster war case-sensitiv. Beides mit 85d2d77
behoben.
In der SUMMARY festgehalten, wie geprueft wurde: eine unabhaengige Analyse aller
Tokens in de.json findet keine Ersatzschreibung mehr, der Schluesselsatz ist
unveraendert bei 787, und die Modulbeschreibung in der bestehenden Datenbank ist beim
API-Neustart per Seed-Upsert mitgewandert — ohne Migration, wie geplant.
Ausserdem vermerkt, dass eine erste Sichtpruefung per fetch aus der laufenden Seite
faelschlich Entwarnung gab. Dieselbe Methode hatte in dieser Sitzung schon einmal ein
falsches Ergebnis geliefert; die berichteten Zahlen stammen aus echten
Seitenaufrufen.
Backlog-Punkt zu den Umlauten nach completed verschoben.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Die Gegenprobe im Browser hat drei Stellen gefunden, die der erste Durchgang nicht
erwischt hat — darunter zwei gut sichtbare Schaltflaechen:
Aenderungen speichern -> Änderungen speichern
Oeffnen -> Öffnen
Eine Aenderung ... -> Eine Änderung ...
Die Ursache ist dieselbe fuer alle drei und steckte im Waechter selbst: sein
Verdachtsmuster /(ae|oe|ue|ss)/ war case-sensitiv. "Aenderungen" beginnt mit "Ae",
nicht mit "ae", und ist deshalb durchgerutscht — der Waechter konnte gar nicht
anschlagen. Muster jetzt case-insensitiv; damit erfasst es auch die
grossgeschriebenen Formen.
Durch die schaerfere Pruefung melden sich neu die Abkuerzungen RSS, RSSGenerator und
SSL. Sie tragen ein doppeltes S ohne Umlaut-Bezug und stehen jetzt auf der
Positivliste.
Ausserdem zwei Meldungen des LDAP-Abgleichs korrigiert, die dem Administrator in der
Oberflaeche angezeigt werden (result.errors landet in der Fehlerliste der
LDAP-Seite): "ungueltiger ldapObjectGuid-Wert" und "Base-DN-Konfiguration pruefen.
Nicht geloescht." Drei Tests pinnen diese Texte bewusst und wurden mitgezogen.
Bewusst NICHT angefasst: die Warnung in crypto.service.ts. Sie geht ueber
logger.warn ins Protokoll und nicht an einen Nutzer.
Unabhaengig gegengeprueft: von allen Tokens in de.json, die ae/oe/ue tragen, ist
keines mehr eine Ersatzschreibung. 642 API-Tests und 225 Web-Tests gruen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Dokumentiert die drei ausgefuehrten Tasks (Woerterbuch + de.json,
Vitest-Waechter, API-Texte), die zwei waehrend Task 2 selbst
entdeckten und behobenen Woerterbuch-Luecken sowie die realen
Test-/Build-Ergebnisse fuer beide Apps. Task 4 (Sichtpruefung nach
Docker-Rebuild) bleibt dem Orchestrator ueberlassen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Korrigiert die deutschen Zeichenketten in beiden Mails aus
mail.service.ts (Betreff, Passwort-Reset-Fliesstext,
Willkommens-Mail) sowie die domaincheck-Modulbeschreibung in
domaincheck.seed.ts auf echte Umlaute. Wortlaut identisch, nur
Zeichen korrigiert; die englischen Zweige bleiben unveraendert.
seedModule() ist ein upsert mit update-Zweig und laeuft in
onModuleInit — ein API-Neustart schreibt die korrigierte
Beschreibung ueber bestehende Datenbankzeilen, ohne Migration oder
Backfill.
pnpm --filter @tessera/api run build: sauber.
pnpm --filter @tessera/api run type-check: sauber.
pnpm --filter @tessera/api run test: 46 Testdateien, 642 Tests gruen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Legt umlaut-guard.spec.ts an, das ausschliesslich das geparste JSON
von de.json/en.json liest (nie repo-weit ueber Quelldateien greift,
sonst schluege es am Woerterbuch selbst an) und drei Dinge prueft:
kein Token aus UMLAUT_REPLACEMENTS mehr in de.json, jedes verbliebene
ae/oe/ue/ss-Token steht auf UMLAUT_ALLOWLIST, und de.json/en.json
haben denselben Schluesselsatz. Manuell mit einem probeweise
eingefuegten "fuer" verifiziert: Meldung nennt "für" und den
Schluesselpfad, danach zurueckgenommen.
Beim Aufbau des Waechters kamen zwei Luecken der Task-1-Wortliste ans
Licht: "Bestaetigen" (Grossschreibung, common.confirm) fehlte in
UMLAUT_REPLACEMENTS und blieb faelschlich falsch geschrieben; die
Ersetzungen zu Passwoerter/vertrauenswuerdigen/ausschliessen/
entschluesselt ergeben nach der Korrektur korrektes Deutsch, das aber
weiterhin ae/oe/ue/ss enthaelt und deshalb auf UMLAUT_ALLOWLIST
ergaenzt werden musste. Beide Luecken behoben (Rule 1 - Bug).
pnpm --filter @tessera/web test: 38 Testdateien, 225 Tests gruen.
pnpm --filter @tessera/web run type-check: sauber.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Die deutsche Oberflaeche schrieb Umlaute als Buchstabenpaare aus
("fuer" statt "für", "Loeschen" statt "Löschen"). Legt
apps/web/src/messages/umlaut-dictionary.ts als einzige Wahrheitsquelle
fuer eine explizite Token-Ersetzungsliste sowie eine Positivliste
bereits korrekter Woerter (Passwort, Quelle, manuell, neue, ...) an
und korrigiert damit 67 falsche Tokens (140 Fundstellen) in de.json.
Ersetzt wird ausschliesslich per Ganzwort-Treffer, nie per
Zeichenregel, damit Woerter wie "Quelle" oder "manuell" unangetastet
bleiben. Der Platzhalterwert "empfaenger@example.com" bleibt
unveraendert, da er eine Beispiel-E-Mail-Adresse ist. Schluessel und
Reihenfolge in de.json sind unveraendert, de.json und en.json tragen
weiterhin denselben Satz von 787 Schluesseln.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Task 3 (Browser-Abnahme) ist durchgefuehrt. Von den beiden zur Freigabe gestellten
Gestaltungsfragen wurde eine zurueckgewiesen und eine blieb offen:
Die Anordnung auf dem Anmelde-Panel hat der User weder als "Marke oben" noch als
"Marke unten" abgenommen, sondern eine dritte Loesung verlangt — Logo links, Text
rechts daneben, wie in der gelieferten Schriftzug-Datei. Nachgezogen mit 11c0ec6.
Zur Schriftzugfarbe hat er sich nicht geaeussert; sie bleibt vorerst dunkel, die
Rueckkehr zu Gelb wurde als jederzeit moeglich angeboten.
Ausserdem in der SUMMARY festgehalten, dass die Abnahme einen Defekt ausserhalb dieses
Plans aufgedeckt hat: die Tailwind-Dunkelvariante war nie an die .dark-Klasse gebunden
(WINDOWS #13, behoben mit f8d7da0). Der Logo-Einbau hat ihn nur sichtbar gemacht,
verursacht hat er ihn nicht.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Beim Einbau des Logos im Browser aufgefallen und als Backlog-Punkte abgelegt, nicht
mitrepariert:
Mandanten-Branding — der Wunsch des Users, dass ein Administrator das Aussehen spaeter
selbst anpassen kann. Der Logo-Einbau hat dafuer schon vorgearbeitet: die Oberflaeche
zieht die Marke ausschliesslich aus einer zentralen Komponente, ein spaeterer Austausch
setzt an genau einer Stelle an. Was noch fehlt (Ablage, Mandantenfeld, Rueckfall,
Verwaltungsseite, Zusammenspiel mit hell/dunkel) steht im Punkt.
Umlaute — die deutschen Oberflaechentexte schreiben Umlaute in 29 Zeilen als
Buchstabenpaare aus: "fuer", "Loeschen", "Zurueck zum Dashboard", "Verfuegbar". Das
sieht jeder Nutzer auf jeder Seite. Mit Hinweis auf die Stolpersteine beim Ersetzen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Auf Wunsch des Users stehen Bildmarke und Text auf dem gelben Anmelde-Panel jetzt
nebeneinander statt untereinander — dieselbe Anordnung wie in der gelieferten Datei
tessera-logo-schriftzug.svg: links die Marke, rechts der Name und darunter der
Untertitel.
Dafuer nimmt die horizontale Variante der Marken-Komponente einen optionalen
Untertitel entgegen. Die gestapelte Variante entfaellt — sie war nach dieser
Umstellung nirgends mehr im Einsatz, alle uebrigen fuenf Stellen standen schon vorher
nebeneinander.
Der Test auf die entfallene Variante wurde nicht geloescht, sondern durch zwei Tests
auf das neue Verhalten ersetzt: einer prueft, dass ohne Angabe kein Untertitel
erscheint, der andere die tatsaechliche Reihenfolge im Dokument (Marke vor Name, Name
vor Untertitel) statt nur deren Vorhandensein. Die Erwartungstexte sind von Hand
geschrieben und nicht aus derselben Quelle gebildet, aus der die Komponente sie zieht.
222/222 Web-Tests gruen, Typpruefung sauber, im Browser gegengeprueft.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Beim Einbau des Logos fiel auf, dass dessen Plattenkontur dark:stroke-white/25 im
dunklen Modus nicht griff. Die Ursache reicht weit ueber das Logo hinaus.
globals.css definierte die Farbtokens unter .dark, deklarierte aber kein
@custom-variant dark. In Tailwind 4 haengt die dark:-Utility-Variante per Vorgabe an
prefers-color-scheme, also an der Einstellung des Betriebssystems. Die Anwendung
schaltet den Modus jedoch ueber next-themes mit attribute=class. Beides lief damit
auseinander: sobald ein Nutzer im Portal auf dunkel stellte, waehrend sein System hell
stand, blieb JEDE dark:-Utility im Quellcode wirkungslos — ueber 100 Vorkommen in mehr
als zehn Dateien, darunter Status-, Warn- und Fehlerfarben, Hinweisboxen und Badges in
der Administration.
Unentdeckt geblieben ist es, weil Hintergrund und Textfarbe NICHT ueber dark: laufen,
sondern ueber die CSS-Variablen unter .dark. Die Oberflaeche wurde also grundsaetzlich
dunkel und nur die Feinheiten fehlten.
Am laufenden System in beide Richtungen gemessen. Vorher, bei html.dark und hellem
System: dark:bg-gray-800 ergab transparent, dark:text-green-400 blieb ohne Wirkung.
Nachher greifen beide korrekt, und im hellen Modus greifen sie weiterhin nicht — die
Logo-Kontur ist dort unsichtbar, im dunklen Modus weiss mit 25 Prozent Deckkraft.
221/221 Web-Tests gruen, Typpruefung sauber.
Erfasst als WINDOWS.md #13 und mit diesem Commit geschlossen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Dokumentiert die uebernommenen/ausgelassenen Lieferdateien, die Begruendung
fuer Text- statt Bild-Schriftzug, die Konturloesung der dunklen Platte, die
Zusammenfuehrung des Gelbwerts sowie zwei waehrend Task 2 automatisch
behobene Deviationen. Status halted, weil Task 3
(checkpoint:human-verify) absichtlich nicht ausgefuehrt wurde.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
- header.tsx, sidebar.tsx (Schublade), login/page.tsx (breit + schmal),
reset-password/page.tsx, reset-password/[token]/page.tsx ziehen jetzt
alle TesseraLogo statt eines von Hand gesetzten Schriftzugs
- login/page.tsx: handgezeichneter Vier-Quadrate-Platzhalter entfernt,
gelbes Panel nutzt BRAND_YELLOW per Inline-Style statt eigener
Tailwind-Klasse, Kopfkommentar ohne Farbwert neu formuliert
- account-settings-form.tsx: DEFAULT_ACCENT liest jetzt BRAND_YELLOW statt
eines eigenen Literals
- tessera-logo.tsx: Schriftzug setzt keine eigene Textfarbe mehr, sondern
erbt sie vom umgebenden Container (Rule 1 -- ohne diese Korrektur waere
der Schriftzug auf dem immer gelben Anmelde-Panel im dunklen
Erscheinungsbild unlesbar hell auf hell gewesen)
- sidebar.tsx: nicht mehr benoetigtes tCommon entfernt; sidebar.test.tsx
um common.brand.logoAlt in der Uebersetzungs-Attrappe ergaenzt
- vollstaendige Web-Testsuite (221 Tests) und Typpruefung gruen
Docker-Neubau und Browser-Abnahme (curl-Health-Check gegen den lokalen
Container) bewusst ausgelassen -- der Orchestrator uebernimmt beides in
Task 3.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
schalli
Schalli