Der am Vormittag gefundene Zugriffs-Guard-Defekt ist behoben (260907-e8k) und im
echten Browser gegen ein frisch gebautes Web-Image nachgeprueft.
nutzer2 ohne Freigabe bekommt jetzt auf /modules/tender-radar, dessen Unterseiten
my-sources und settings sowie auf /modules/dkv-fleet die 403-Seite als
Serverantwort. Auf /modules/cert-manager, wo er eine Freigabe hat, kommt er
weiterhin durch — das ist die Gegenprobe dagegen, dass die Sperre zu weit greift.
admin sieht alle vier Adressen unveraendert, nutzer1 sieht Meine Quellen mit allen
drei Abschnitten; die Phase-17-Funktion ist unbeschaedigt.
Im Bericht zusaetzlich festgehalten, dass ein erster Messversuch per fetch() aus der
laufenden Seite heraus faelschlich alle Seiten als gesperrt meldete, auch fuer den
Administrator. Der Aufruf fuehrt die Sitzung nicht wie eine echte Navigation mit.
Alle berichteten Zahlen stammen aus echten Seitenaufrufen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5jtbGzC5Sf9npJ3JCjKhq
Die Phasen 11 bis 14 standen in der Roadmap-Tabelle auf "In Progress", obwohl an
keiner davon noch gearbeitet wird. Der Status wurde gegen die Verifikationsberichte
gehalten und dabei zeigte sich, dass es kein reiner Buchhaltungsrueckstand war:
11 und 12 stehen auf passed und sind jetzt Complete.
13 traegt einen offenen Befund. tenderFingerprint() haengt buyerName, title,
cpvDivisionKey, deadlineKey und valueBucket zu einem String und hasht ihn. Die
Scraper liefern cpvDivisions immer leer, DOE meist gefuellt — dieselbe
Ausschreibung ergibt aus beiden Quellen verschiedene Fingerabdruecke. Die
Fingerprint-Stufe greift also gerade dort nicht, wo sie greifen soll. Das stand
seit dem 2026-07-23 in 13-VERIFICATION.md, aber nicht im Ledger und war damit
praktisch unsichtbar. Jetzt WINDOWS.md #11.
14 wartet auf den Live-Test gegen ein echtes Exchange-Postfach; der
NTLM/SOAP-Weg ist nur gegen Mocks geprueft. Vom User am 2026-07-24 bewusst
zurueckgestellt, stand ebenfalls nur im Verifikationsbericht. Jetzt WINDOWS.md #12.
Beide Phasen tragen den wahren Status statt "In Progress", mit Verweis auf den
jeweiligen Ledger-Eintrag.
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
- 16-05-SUMMARY.md documents the two-task plan (sync-report wiring,
grants-matrix internal-name fallback).
- PERM-02 marked complete in REQUIREMENTS.md: all five Phase-16 success
criteria are code-complete across plans 16-01..16-03; this plan
delivered the last missing visibility layer (D-05/D-06) and the
third D-04 display site.
- WINDOWS.md #6: this plan's own manual browser walkthrough (sync
report three-line render, amber default-marker line, grants-matrix
two-name search) not executed — no browser tool in this session.
schalli