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
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
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
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
Entscheidung des Users vom 2026-09-07: die drei verbleibenden Ledger-Punkte werden
spaeter am Live-System geprueft, nicht in der Entwicklungsumgebung. Sie brauchen ein
erreichbares Active Directory (#4, #6) beziehungsweise ein echtes Exchange-Postfach
(#12) und sind hier nicht ersetzbar.
Als Deferred Items in STATE.md eingetragen, mit dem jeweiligen Pruefauftrag im
Klartext, damit beim naechsten Aufsetzen niemand neu recherchieren muss, was genau
zu tun ist.
Im Ledger bleiben sie ausdruecklich `open` und wurden NICHT auf `waived` gesetzt —
sie sollen nachgeholt werden, nur eben dort, wo die Fremdsysteme erreichbar sind.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Die Fingerabdruck-Stufe legte vor dem Fix bei 16.255 Zeilen null Duplikate
zusammen — nicht zu wenige, sondern gar keine. Nach der Umstellung auf die
quellstabilen Felder sind es 26 Gruppen mit 52 Zeilen, davon 2 durch das neue
Wert-Veto getrennt. 374/374 API-Tests unabhaengig nachgelaufen.
Die automatische Nachrechnung wurde scharf geprueft statt nur beobachtet: 500
Zeilen wurden kuenstlich auf ein altes Fingerabdruck-Format zurueckgesetzt, dann
die API neu gebaut und gestartet. Der Start um 08:46:25 meldete "500 Zeile(n) auf
die neue Formel gebracht" und hinterliess null veraltete Zeilen; der Neustart um
08:46:49 erzeugte keine Meldung mehr. Damit ist beides belegt — dass sie repariert
und dass sie nicht bei jedem Start erneut laeuft.
Der Bericht haelt die drei bewusst getragenen Grenzen fest (zweites Los gleicher
Groessenordnung wird falsch zusammengelegt; RSS/E-Mail matchen nur ueber den Titel;
der eine bereits messbare Fall LSA242) und begruendet, warum ein Riegel dagegen
verworfen wurde: er wuerde RSS dauerhaft von der Dublettenerkennung ausschliessen.
Ausserdem festgehalten, dass die Stufe nur beim Einlesen wirkt — der Altbestand
wird nicht rueckwirkend zusammengefuehrt.
Phase 13 steht damit auf Complete.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Die sechs seit Anfang August offenen Browser-Durchlaeufe aus Phase 15 und 16
(WINDOWS.md #1-#6) waren liegengeblieben, weil in den damaligen Sitzungen kein
Browser-Tool verfuegbar war. Der Stack lief fuer die Phase-17-Gegenproben ohnehin,
also wurden alle nachgeholt, die ohne echtes Active Directory pruefbar sind.
Geschlossen:
#1 (15-06) Gruppenverwaltung: anlegen, umbenennen, Standardmarkierung exklusiv
setzen und zuruecknehmen, Mitglied hinzufuegen und entfernen, Loeschdialog nennt
beide Zahlen konkret. Bei gestoppter API meldet der Loeschvorgang deutschen
Klartext und laesst die Gruppe stehen. Die AD-Bindung ist an dieser Stelle
gegenstandslos geworden — Phase 16 hat sie in den LDAP-Bereich verlagert.
#2 (15-07) Freigaben-Matrix: setzen und entziehen, Aktivierungsdialog auf beiden
Wegen (Sofort-Freigabe legt den Grant an, "Spaeter konfigurieren" nicht),
Direkt-Grant neben Gruppen-Grant mit sichtbarer Gruppenspalte, langer Gruppenname
bleibt in seinen Massen. Bei gestoppter API springt die Checkbox zurueck und die
Datenbank bleibt unveraendert — kein optimistischer Zustand ueberlebt.
#5 (16-04) Gruppen-Dialog in allen drei Zustaenden, inklusive importierter Gruppe
mit gesperrtem AD-Namen und freiem internen Namen; die Liste zeigt danach den
internen Namen und traegt den AD-Namen im Tooltip. Die AD-Bindung wurde dafuer in
der Datenbank gesetzt, nicht importiert — im Bericht ausdruecklich vermerkt.
#3 (15-08) wurde durchgefuehrt und hat einen Defekt aufgedeckt:
WINDOWS #10 (neu, offen): PERM-04 greift nicht auf den modul-eigenen Routen. Der
Zugriffs-Guard sitzt allein in modules/[category]/[moduleSlug]/page.tsx. Die vier
fest verdrahteten Modulrouten (tender-radar, dkv-fleet, cert-manager, domaincheck)
samt Unterseiten laufen daran vorbei. Ein USER ohne Freigabe bekommt unter
/modules/procurement/tender-radar korrekt die 403-Seite, unter /modules/tender-radar,
/modules/tender-radar/my-sources und /modules/dkv-fleet dagegen die volle Seite mit
bedienbaren Knoepfen. Keine Datenpreisgabe — die API antwortet durchgehend 403 —
aber der Nutzer sieht Bedienelemente, die er nicht benutzen darf, und rohe
englische Techniktexte statt einer verstaendlichen Meldung. Sidebar, Marketplace
und API verhalten sich dagegen korrekt.
Offen bleiben #4 und #6: beide messen den Sync-Vorgang selbst und brauchen ein
erreichbares Active Directory.
Berichte mit Screenshots unter 15-UAT-2026-09-07.md und 16-UAT-2026-09-07.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Die drei human-check-Punkte aus Phase 17 waren am 2026-08-12 offen geblieben,
weil in der Ausfuehrungssitzung kein Browser-Tool verfuegbar war. Sie wurden
jetzt gegen frisch gebaute Images aus main (79015dd) mit echtem Chrome und
leerer Datenbank durchgeklickt.
#7 (17-01 Task 2): nutzer1 speichert sein Postfach, die Werte ueberleben den
Reload; nutzer2 sieht ein leeres Formular statt der Werte von nutzer1. Danach
zwei TenderEmailConfig-Zeilen mit je eigenem userId.
#8 (17-03 Task 1): Meine Quellen zeigt alle drei Abschnitte, ein eigener
RSS-Feed erscheint sofort mit Entfernen-Knopf, der plattformweite service-bund
steht darunter ohne, und das Digest-Intervall "Woechentlich" ueberlebt den
Reload.
#9 (17-03 Task 2): USER sieht auf /settings keine Bedienelemente, nur Hinweis
und Verweis; SUPER_ADMIN sieht Abrufintervall und plattformweite Feeds, aber
kein Postfach und keine Benachrichtigung mehr. Das Zahnrad fuehrt in beiden
Faellen nach Meine Quellen.
Zusaetzlich am laufenden Server gemessen, weil eine ausgeblendete Schaltflaeche
kein Beweis fuer eine serverseitige Sperre ist: als nutzer2 liefert GET
/rss-feeds nur den plattformweiten Feed, DELETE auf den plattformweiten wie auf
den fremden Feed antwortet 404 ohne die Zeile anzufassen, und POST mit
scope=platform wird mit 403 abgewiesen.
WINDOWS.md #7/#8/#9 auf fixed (open_count 9 -> 6), Verifikationsbericht mit
Nachtrag und Screenshots auf passed, ROADMAP auf Complete, STATE nachgezogen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
The note predated 7bda56d and f574884, so two of its three points were
already shipped when it was picked up. Records what each commit actually
closed, and that the .env deny rules block the two committed template
files that hold no secrets.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Notes what was deliberately left out: extracting and renaming the crypto
service out of calendar/ touches five modules and belongs in its own change,
so the existing provider is reused as-is and the naming smell is recorded in
LdapModule instead.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The AD group membership sync shipped on 2026-08-04 as 614de28; only its
summary was never written, which left Phase 15 sitting at 7/8 as if work were
outstanding. Nothing was.
Each promise the plan made is checked against today's source rather than
against the commit message: bound-only selection, no second sync job, deletion
restricted to source LDAP, manual memberships preserved, memberOf reverse query
instead of attribute reads, RFC-4515 escaping of the group DN, no nested-group
resolution, order independence, per-group error isolation. The 2026-08-11 sync
run on alpha additionally exercised this path against a real directory.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Records the user's choice between the two candidate link targets (the notice
page on oeffentlichevergabe.de, not the awarding portal's own page), what was
checked before touching the adapter, and the trap in verifying it: the target
is a single-page app that answers 200 with an identical shell for any id, so
only rendered content proves the link works.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The user has no write access to the company AD, so tests 1, 3, 4 and 8 cannot
be run there, and building a throwaway domain controller for them was judged
disproportionate now that the one substantive defect at this spot is found and
fixed (UAT test 2 -> quick task 260811-f9i).
Recorded rather than hidden: A1 (objectGUID survives a rename) now rests on
Microsoft's documentation, not on our own measurement. The Tessera-side rename
and delete logic stays covered by unit tests against fixtures. If a rename ever
fails to propagate in production, 16-VERIFICATION.md names that as the starting
point.
Phase 16 marked complete in STATE.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Quick task 260811-f9i: plan and summary of the fix, STATE.md row, and the UAT
test 2 result. Test 2 was the read-only A2 check against the real directory --
it turned assumption A2 from "unverified" into "false as implemented" and
surfaced a defect that would have deleted every AD-bound group on the first
real sync.
Also records why the defect survived review: the spec mocks built their
expected filter with the same escape helper the production code used, so the
test asserted self-consistency rather than directory behaviour.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two-level module access: tenant activation stays a prerequisite, plus new
per-group and per-user grants. Records the four design decisions taken with
the user: Tessera-owned groups with optional AD binding, closed-by-default
access, ADMIN/SUPER_ADMIN bypass within their tenant, and access on/off only
(no permission levels inside modules). Starts milestone v1.2.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
schalli