docs: Roadmap-Status ehrlich gemacht, zwei unsichtbare Befunde ins Ledger

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

.planning/ROADMAP.md

@@ -603,10 +603,10 @@ Phases execute in numeric order: 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9 -> 10
 | 8. Dashboard Widgets Vollimplementierung | 4/4 | Complete   | 2026-07-01 |
 | 9. Cert Manager Module | 6/6 | Complete   | 2026-07-02 |
 | 10. Ausschreibungs-Radar Foundation & DÖE Ingestion | 6/6 | Complete   | 2026-07-21 |
-| 11. Filter Engine, Results UI & Saved Searches | 6/6 | In Progress|  |
-| 12. Tender Notifications | 4/4 | In Progress|  |
-| 13. Scraping Adapters & Cross-Source Deduplication | 6/6 | In Progress|  |
-| 14. RSS, Email-Alert Ingestion & Module Rollout | 5/5 | In Progress|  |
+| 11. Filter Engine, Results UI & Saved Searches | 6/6 | Complete | 2026-07-22 (Verifikation: passed) |
+| 12. Tender Notifications | 4/4 | Complete | 2026-07-23 (Verifikation: passed) |
+| 13. Scraping Adapters & Cross-Source Deduplication | 6/6 | Offener Befund | Alle Plaene fertig, Verifikation 3/4 — Fingerprint-Dedup greift wegen leerer cpvDivisions beim Scraper nicht (WINDOWS.md #11) |
+| 14. RSS, Email-Alert Ingestion & Module Rollout | 5/5 | Wartet auf Live-Test | Alle Plaene fertig, Verifikation 4/5 — echter Exchange/EWS-Durchlauf steht aus, bewusst zurueckgestellt (WINDOWS.md #12) |
 | 15. Modul-Berechtigungen: Gruppen & User-Grants | 8/8 | Complete | 2026-08-04 (Bericht 15-04 am 2026-08-11 nachgezogen) |
 | 16. AD-Gruppen-Synchronisation | 5/5 | Complete | 2026-08-11 |
 | 17. Eigene Ausschreibungs-Quellen je Nutzer | 3/3 | Complete | 2026-08-12 (Browser-Gegenproben #7/#8/#9 am 2026-09-07 nachgeholt, alle bestanden) |

.planning/WINDOWS.md

@@ -1,10 +1,10 @@
 ---
 schema_version: 1
-open_count: 3
+open_count: 5
 waived_count: 0
 fixed_count: 7
-total_count: 10
-last_updated: 2026-09-07T08:03:51.517Z
+total_count: 12
+last_updated: 2026-09-07T08:09:04.406Z
 ---
 
 # Broken Windows Ledger
@@ -25,6 +25,8 @@ last_updated: 2026-09-07T08:03:51.517Z
 | 8 | 17 | unrun-verify | apps/web/src/app/(portal)/modules/tender-radar/my-sources/page.tsx |  | Browser-Gegenprobe Plan 17-03 Task 1 (Tracer-Feedback-Gate): Meine Quellen mit drei Abschnitten, neu angelegter eigener Feed sofort sichtbar, plattformweiter Feed ohne Entfernen-Knopf, Digest-Intervall speichert nach Reload — kein Browser-Tool in dieser Sitzung verfuegbar | fixed |  | 2026-08-12T10:02:49.122Z | 2026-09-07T07:50:56.693Z |
 | 9 | 17 | unrun-verify | apps/web/src/app/(portal)/modules/tender-radar/settings/page.tsx |  | Browser-Gegenprobe Plan 17-03 Task 2: USER-Konto sieht keine Bedienelemente auf /settings (nur Hinweis+Verweis), ADMIN-Konto sieht Abrufintervall+plattformweite Feeds ohne Postfach/Benachrichtigung, Zahnrad fuehrt in beiden Faellen nach Meine Quellen — kein Browser-Tool in dieser Sitzung verfuegbar | fixed |  | 2026-08-12T10:02:49.291Z | 2026-09-07T07:50:56.910Z |
 | 10 | 15 | unmet-truth | apps/web/src/app/(portal)/modules/tender-radar/page.tsx |  | PERM-04 greift nicht auf modul-eigenen Routen: der Zugriffs-Guard sitzt nur in modules/[category]/[moduleSlug]/page.tsx. Die vier fest verdrahteten Modulrouten (tender-radar, dkv-fleet, cert-manager, domaincheck) samt Unterseiten (z.B. tender-radar/my-sources) laufen daran vorbei und rendern fuer einen USER OHNE Modulfreigabe vollstaendig, inklusive bedienbarer Knoepfe. Im Browser gemessen am 2026-09-07 mit nutzer2 (keine Freigabe): /modules/procurement/tender-radar zeigt korrekt die 403-Seite, /modules/tender-radar und /modules/tender-radar/my-sources und /modules/dkv-fleet zeigen die volle Seite. Keine Datenpreisgabe - die API antwortet auf allen Endpunkten mit 403 - aber der Nutzer sieht Bedienelemente, die er nicht benutzen darf, und bekommt rohe englische Techniktexte statt einer verstaendlichen Meldung. Beleg: .planning/phases/17-eigene-ausschreibungs-quellen-je-nutzer/uat-2026-09-07/befund-modul-eigene-route-ohne-freigabe.png | open |  | 2026-09-07T08:03:45.978Z |  |
+| 11 | 13 | unmet-truth | apps/api/src/tenders/tender-fingerprint.ts |  | Cross-Source-Dedup kollabiert die Mehrzahl echter Duplikate nicht: tenderFingerprint() haengt [buyerName, title, cpvDivisionKey, deadlineKey, valueBucket] zu einem String und hasht ihn. Die Scraper-Adapter liefern cpvDivisions immer leer, DOE dagegen meist gefuellt - dieselbe Ausschreibung ergibt aus beiden Quellen verschiedene Fingerabdruecke, die Fingerprint-Stufe greift also gerade dort nicht, wo sie greifen soll. Steht als offener Rest in 13-VERIFICATION.md (status gaps_found, 3/4 Wahrheiten), war aber bisher nicht im Ledger und damit unsichtbar. Die frueher vermutete Ursache (Normalizer-Defaults) ist mit 9881005 geschlossen und nicht gemeint. | open |  | 2026-09-07T08:09:04.188Z |  |
+| 12 | 14 | unrun-verify | .planning/phases/14-rss-email-alert-ingestion-module-rollout/14-03-PLAN.md |  | 14-03 Task 4 (checkpoint human-verify, gate blocking): echtes Portal-Alert-Postfach ueber den Exchange/EWS-Weg anbinden und eine echte Alarm-Mail ingestieren. Zu belegen sind (a) die Mail erzeugt eine mandantenprivate Ausschreibung, (b) ein anderer Mandant sieht sie nicht, (c) der EWS-Body-Abruf liefert nicht-leeren, nicht-verstuemmelten Inhalt gegen einen echten Exchange-Server. Der handgeschriebene NTLM/SOAP-Weg ist nur gegen gemocktes httpntlm.post geprueft, nie gegen einen echten Server. Braucht ein echtes Postfach - vom User am 2026-07-24 bewusst zurueckgestellt. Stand bisher nur in 14-VERIFICATION.md (status human_needed), nicht im Ledger. | open |  | 2026-09-07T08:09:04.406Z |  |
 
 ````json
 [
@@ -147,6 +149,30 @@ last_updated: 2026-09-07T08:03:51.517Z
     "reason": "",
     "recorded_at": "2026-09-07T08:03:45.978Z",
     "resolved_at": null
+  },
+  {
+    "id": 11,
+    "kind": "unmet-truth",
+    "phase": "13",
+    "file": "apps/api/src/tenders/tender-fingerprint.ts",
+    "line": null,
+    "description": "Cross-Source-Dedup kollabiert die Mehrzahl echter Duplikate nicht: tenderFingerprint() haengt [buyerName, title, cpvDivisionKey, deadlineKey, valueBucket] zu einem String und hasht ihn. Die Scraper-Adapter liefern cpvDivisions immer leer, DOE dagegen meist gefuellt - dieselbe Ausschreibung ergibt aus beiden Quellen verschiedene Fingerabdruecke, die Fingerprint-Stufe greift also gerade dort nicht, wo sie greifen soll. Steht als offener Rest in 13-VERIFICATION.md (status gaps_found, 3/4 Wahrheiten), war aber bisher nicht im Ledger und damit unsichtbar. Die frueher vermutete Ursache (Normalizer-Defaults) ist mit 9881005 geschlossen und nicht gemeint.",
+    "status": "open",
+    "reason": "",
+    "recorded_at": "2026-09-07T08:09:04.188Z",
+    "resolved_at": null
+  },
+  {
+    "id": 12,
+    "kind": "unrun-verify",
+    "phase": "14",
+    "file": ".planning/phases/14-rss-email-alert-ingestion-module-rollout/14-03-PLAN.md",
+    "line": null,
+    "description": "14-03 Task 4 (checkpoint human-verify, gate blocking): echtes Portal-Alert-Postfach ueber den Exchange/EWS-Weg anbinden und eine echte Alarm-Mail ingestieren. Zu belegen sind (a) die Mail erzeugt eine mandantenprivate Ausschreibung, (b) ein anderer Mandant sieht sie nicht, (c) der EWS-Body-Abruf liefert nicht-leeren, nicht-verstuemmelten Inhalt gegen einen echten Exchange-Server. Der handgeschriebene NTLM/SOAP-Weg ist nur gegen gemocktes httpntlm.post geprueft, nie gegen einen echten Server. Braucht ein echtes Postfach - vom User am 2026-07-24 bewusst zurueckgestellt. Stand bisher nur in 14-VERIFICATION.md (status human_needed), nicht im Ledger.",
+    "status": "open",
+    "reason": "",
+    "recorded_at": "2026-09-07T08:09:04.406Z",
+    "resolved_at": null
   }
 ]
 ````