docs: create milestone v1.1 roadmap (5 phases)

.planning/REQUIREMENTS.md

@@ -74,4 +74,36 @@
 
 ## Traceability
 
-_(Wird vom Roadmapper befüllt: REQ-ID → Phase.)_
+| Requirement | Phase | Status |
+|-------------|-------|--------|
+| CONFIG-01 | Phase 10 | Pending |
+| INGEST-01 | Phase 10 | Pending |
+| INGEST-06 | Phase 10 | Pending |
+| SCHEMA-01 | Phase 10 | Pending |
+| SCHEMA-02 | Phase 10 | Pending |
+| FILTER-01 | Phase 11 | Pending |
+| FILTER-02 | Phase 11 | Pending |
+| FILTER-03 | Phase 11 | Pending |
+| FILTER-04 | Phase 11 | Pending |
+| FILTER-05 | Phase 11 | Pending |
+| FILTER-06 | Phase 11 | Pending |
+| UI-01 | Phase 11 | Pending |
+| UI-02 | Phase 11 | Pending |
+| UI-03 | Phase 11 | Pending |
+| UI-04 | Phase 11 | Pending |
+| UI-05 | Phase 11 | Pending |
+| NOTIFY-01 | Phase 12 | Pending |
+| NOTIFY-02 | Phase 12 | Pending |
+| NOTIFY-03 | Phase 12 | Pending |
+| NOTIFY-04 | Phase 12 | Pending |
+| INGEST-02 | Phase 13 | Pending |
+| INGEST-03 | Phase 13 | Pending |
+| INGEST-07 | Phase 13 | Pending |
+| SCHEMA-03 | Phase 13 | Pending |
+| INGEST-04 | Phase 14 | Pending |
+| INGEST-05 | Phase 14 | Pending |
+| CONFIG-02 | Phase 14 | Pending |
+| CONFIG-03 | Phase 14 | Pending |
+| UI-06 | Phase 14 | Pending |
+
+**Coverage:** 29/29 v1.1 requirements mapped — no orphans.

.planning/ROADMAP.md

@@ -2,7 +2,12 @@
 
 ## Overview
 
-Tessera delivers a modular portal platform where tenants activate workflow modules from a marketplace, interact through a configurable dashboard, and optionally use a desktop wrapper. The roadmap builds foundation-first (Docker + DB + shell), layers in authentication and multi-tenancy, establishes the module system with a proof-of-concept module, adds marketplace and portal navigation, delivers the dashboard experience, and wraps up with desktop client and CI/CD integration.
+Tessera delivers a modular portal platform where tenants activate workflow modules from a marketplace, interact through a configurable dashboard, and optionally use a desktop wrapper. The roadmap builds foundation-first (Docker + DB + shell), layers in authentication and multi-tenancy, establishes the module system with a proof-of-concept module, adds marketplace and portal navigation, delivers the dashboard experience, and wraps up with desktop client and CI/CD integration. The v1.1 Ausschreibungs-Radar milestone (Phases 10-14) adds a new module that aggregates German public tenders from DÖE OpenData plus AI-AG NetServer, cosinex, RSS, and email-alert sources into one normalized, filterable, notifiable catalog -- shipped DÖE-first as a legally-clean, demoable MVP, then layered with scraping adapters and finally the long-tail RSS/email sources.
+
+## Milestones
+
+- ✅ **v1.0 MVP** - Phases 1-9 (shipped 2026-07-02)
+- 🚧 **v1.1 Ausschreibungs-Radar** - Phases 10-14 (in progress)
 
 ## Phases
 
@@ -22,6 +27,11 @@ Decimal phases appear between their surrounding integers in numeric order.
 - [x] **Phase 7: DKV Fleet Module** - Automated DKV invoice processing via email monitoring, PDF parsing, and Excel export with driver mapping (completed 2026-06-27)
 - [x] **Phase 8: Dashboard Widgets Vollimplementierung** - Calculator, Favorites, and Stopwatch widgets plus unified grid constraints across all dashboard widgets (completed 2026-07-01)
 - [x] **Phase 9: Cert Manager Module** - Server-side certificate toolkit: upload/paste, inspect, split chains, merge/bundle, convert formats, password-protected PFX support (completed 2026-07-02)
+- [ ] **Phase 10: Ausschreibungs-Radar Foundation & DÖE Ingestion** - Normalized DÖE tender ingestion on a multi-tenant-safe shared schedule, module activatable from the marketplace
+- [ ] **Phase 11: Filter Engine, Results UI & Saved Searches** - Searchable/filterable tender results, personal saved search profiles, per-user read/favourite triage
+- [ ] **Phase 12: Tender Notifications** - Configurable digest and instant email alerts without duplicate sends or backfill floods
+- [ ] **Phase 13: Scraping Adapters & Cross-Source Deduplication** - AI-AG NetServer + cosinex adapters with fuzzy cross-source dedup and a hard denylist for banned portals
+- [ ] **Phase 14: RSS, Email-Alert Ingestion & Module Rollout** - RSS + email-alert long tail, admin source/mailbox config, excluded-portal transparency, i18n
 
 ## Phase Details
 
@@ -320,10 +330,91 @@ Plans:
 
 **UI hint**: yes
 
+### Phase 10: Ausschreibungs-Radar Foundation & DÖE Ingestion
+
+**Goal:** The platform ingests German public tenders from the DÖE OpenData API on a shared, multi-tenant-safe schedule into a normalized, platform-global schema, and the module can be activated per tenant from the marketplace.
+**Mode:** mvp
+**Depends on**: Phase 9 (existing platform infrastructure: module registry, multi-tenancy, mail/SMTP)
+**Requirements**: CONFIG-01, INGEST-01, INGEST-06, SCHEMA-01, SCHEMA-02
+**Success Criteria** (what must be TRUE):
+
+  1. Admin can find "Ausschreibungs-Radar" in the marketplace and activate it for a tenant, same as the DKV-Fleet/Cert-Manager modules
+  2. New DÖE OpenData tenders appear as normalized records (title, buyer, CPV codes, region/PLZ, deadline, estimated value, procedure type, source URL) after a poll cycle -- tender data is platform-global, not tied to any one tenant
+  3. A DÖE tender that changes on the source side (e.g. deadline extension, cancellation) updates the existing record via content-hash change detection instead of creating a duplicate
+  4. DÖE is polled once on a shared, admin-configurable interval regardless of how many tenants have the module active -- never once per tenant (poll-once-fan-out-many, not the DKV single-tenant `findFirst()` pattern)
+  5. Activating the module for a second tenant does not duplicate ingestion, re-trigger a redundant DÖE poll, or interfere with the first tenant's data
+
+**Plans**: TBD
+
+### Phase 11: Filter Engine, Results UI & Saved Searches
+
+**Goal:** Users can search, filter, and personally triage DÖE tender results, and save reusable filter combinations as personal search profiles, with the UI transparently communicating data coverage.
+**Mode:** mvp
+**Depends on**: Phase 10
+**Requirements**: FILTER-01, FILTER-02, FILTER-03, FILTER-04, FILTER-05, FILTER-06, UI-01, UI-02, UI-03, UI-04, UI-05
+**Success Criteria** (what must be TRUE):
+
+  1. User sees a searchable, sortable results list (by deadline, value, publish date) and can filter by keyword, region/PLZ/Bundesland, CPV code (hierarchical, with autocomplete), deadline, and estimated value -- tenders with no value stated are handled gracefully, not excluded or errored
+  2. User can open a detail view for any tender showing the source link and any document URLs present in the notice (no local mirroring of Vergabeunterlagen)
+  3. User can save a combination of filter criteria as a named search profile and later edit or delete it -- profiles are personal (per user) and scoped to their own tenant
+  4. User can mark a tender as read/unread and as favourite, and filter the results list to only favourites -- both states are per-user, not shared across the tenant
+  5. The UI clearly indicates data coverage (Oberschwelle vs. Unterschwelle) so an empty or thin result set isn't mistaken for a bug
+
+**Plans**: TBD
+**UI hint**: yes
+
+### Phase 12: Tender Notifications
+
+**Goal:** Users are proactively notified by email about new matching tenders, via a configurable digest and/or instant alert, without duplicate sends or backfill floods, using the tenant's own SMTP configuration.
+**Mode:** mvp
+**Depends on**: Phase 11
+**Requirements**: NOTIFY-01, NOTIFY-02, NOTIFY-03, NOTIFY-04
+**Success Criteria** (what must be TRUE):
+
+  1. User receives a periodic email digest of new matches for their active search profiles, with the interval configurable in the web interface
+  2. User can enable an instant email alert per search profile and receives a single email shortly after a new match against that profile
+  3. Activating a new search profile with many pre-existing historical matches does not flood the user with individual emails -- backfill is suppressed/batched on first activation, and a match already notified once (digest or instant) is never notified again for the same tender+profile pair (explicit matched-vs-notified state)
+  4. Notification emails are sent through the tenant's own SMTP configuration (reusing the DKV mail pattern), not a shared/global system mailer
+
+**Plans**: TBD
+**UI hint**: yes
+
+### Phase 13: Scraping Adapters & Cross-Source Deduplication
+
+**Goal:** The platform expands tender coverage with AI-AG NetServer and cosinex portal adapters and collapses tenders seen on multiple sources into a single entry, while structurally refusing to ever scrape the AGB-prohibited portals.
+**Mode:** mvp
+**Depends on**: Phase 12
+**Requirements**: INGEST-02, INGEST-03, INGEST-07, SCHEMA-03
+**Success Criteria** (what must be TRUE):
+
+  1. Tenders from AI-AG NetServer portals (lhs-vpbw, tender24, vergabe.landbw) appear as additional, correctly normalized results via one config-driven adapter
+  2. Tenders from the cosinex Vergabemarktplatz (DTVP) appear as additional, correctly normalized results via a separate config-driven adapter
+  3. A tender that appears via both DÖE and a scraping adapter shows up once in the results list (fuzzy fingerprint dedup on buyer+title+CPV+deadline+value), with links to all of its source portals -- dedup logic only activates once a second source is live
+  4. Attempting to register vergabe24 or aumass as a poll source is refused by the system itself (adapter registry denylist enforced in code), not just documented as forbidden
+
+**Plans**: TBD
+
+### Phase 14: RSS, Email-Alert Ingestion & Module Rollout
+
+**Goal:** The platform rounds out Unterschwelle long-tail coverage via RSS feeds and per-tenant email-alert mailboxes (reusing a shared inbox module extracted from DKV), admins can manage source and mailbox configuration per tenant, excluded portals are shown transparently, and the whole module is bilingual.
+**Mode:** mvp
+**Depends on**: Phase 13
+**Requirements**: INGEST-04, INGEST-05, CONFIG-02, CONFIG-03, UI-06
+**Success Criteria** (what must be TRUE):
+
+  1. Tenders from the RSS feeds subreport-elvis and service.bund.de appear automatically in the results list
+  2. Tenders parsed from a configured mailbox's portal-alert emails appear automatically in the results list -- built on a shared `inbox/` module, extracted as a one-time prerequisite refactor from DKV's `ImapProvider`/`ExchangeInboxProvider` (previously living inside `dkv/`)
+  3. Admin can manage per-tenant source poll configuration and the email-alert ingestion mailbox, with credentials stored encrypted (same AES-256-GCM pattern as `DkvModuleConfig`)
+  4. vergabe24 and aumass are shown in the UI as "manually monitor" with a direct link, instead of appearing as a silent coverage gap
+  5. The entire module UI (results list, filters, saved searches, settings) is fully usable in both German and English
+
+**Plans**: TBD
+**UI hint**: yes
+
 ## Progress
 
 **Execution Order:**
-Phases execute in numeric order: 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9
+Phases execute in numeric order: 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9 -> 10 -> 11 -> 12 -> 13 -> 14
 
 | Phase | Plans Complete | Status | Completed |
 |-------|----------------|--------|-----------|
@@ -336,3 +427,8 @@ Phases execute in numeric order: 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9
 | 7. DKV Fleet Module | 6/6 | Complete   | 2026-06-27 |
 | 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 | 0/TBD | Not started | - |
+| 11. Filter Engine, Results UI & Saved Searches | 0/TBD | Not started | - |
+| 12. Tender Notifications | 0/TBD | Not started | - |
+| 13. Scraping Adapters & Cross-Source Deduplication | 0/TBD | Not started | - |
+| 14. RSS, Email-Alert Ingestion & Module Rollout | 0/TBD | Not started | - |

.planning/STATE.md

@@ -3,10 +3,10 @@ gsd_state_version: 1.0
 milestone: v1.1
 milestone_name: Ausschreibungs-Radar
 status: planning
-last_updated: "2026-07-17T07:57:59.935Z"
+last_updated: "2026-07-17T08:45:00.000Z"
 last_activity: 2026-07-17
 progress:
-  total_phases: 0
+  total_phases: 5
   completed_phases: 0
   total_plans: 0
   completed_plans: 0
@@ -17,17 +17,19 @@ progress:
 
 ## Project Reference
 
-See: .planning/PROJECT.md (updated 2026-06-18)
+See: .planning/PROJECT.md (updated 2026-07-17)
 
 **Core value:** Eine zentrale Plattform, in der beliebige Workflow-Tools als Module lizenziert, aktiviert und genutzt werden koennen -- ohne zwischen verschiedenen Anwendungen wechseln zu muessen.
-**Current focus:** Phase 9 — cert-manager-module
+**Current focus:** Phase 10 — Ausschreibungs-Radar Foundation & DÖE Ingestion
 
 ## Current Position
 
-Phase: Not started (defining requirements)
-Plan: —
-Status: Defining requirements
-Last activity: 2026-07-17 — Milestone v1.1 started
+Phase: 10 of 14 (Ausschreibungs-Radar Foundation & DÖE Ingestion)
+Plan: — (not yet planned)
+Status: Ready to plan
+Last activity: 2026-07-17 — ROADMAP.md created for v1.1 (Phases 10-14), 29 requirements mapped, 100% coverage
+
+Progress: [░░░░░░░░░░] 0%
 
 ## Performance Metrics
 
@@ -73,7 +75,13 @@ Last activity: 2026-07-17 — Milestone v1.1 started
 Decisions are logged in PROJECT.md Key Decisions table.
 Recent decisions affecting current work:
 
-- [Roadmap]: 6 phases derived from 44 v1 requirements, standard granularity
+- [Roadmap v1.1]: 5 phases (10-14) derived from 29 v1.1 requirements, standard granularity — DÖE-only MVP (10: ingestion, 11: filter/UI, 12: notifications) ships first as legally-clean demoable slice, then scraping adapters + cross-source dedup (13), then RSS + email-alert long tail (14)
+- [Roadmap v1.1]: Tender data modeled as platform-global (no tenantId on Tender) — only TenderSavedSearch/TenderMatch are tenant+user-scoped; deviates deliberately from the DKV per-tenant template
+- [Roadmap v1.1]: Scheduler must be poll-once-fan-out-many from Phase 10 onward — explicitly NOT the DKV `findFirst()` single-tenant pattern (documented pitfall)
+- [Roadmap v1.1]: Notification phase (12) requires an explicit matched-vs-notified state with backfill suppression to avoid first-activation email floods and duplicate digest+instant sends
+- [Roadmap v1.1]: INGEST-07 (vergabe24/aumass hard denylist) enforced in the adapter registry in Phase 13, not just documented
+- [Roadmap v1.1]: inbox/ module extraction (ImapProvider/ExchangeInboxProvider out of dkv/) scoped as a one-time prerequisite refactor inside Phase 14, not done earlier
+- [Roadmap]: 6 phases derived from 44 v1.0 requirements, standard granularity
 - [Roadmap]: Research recommends NestJS + Next.js + PostgreSQL RLS + Keycloak + Tauri stack
 - [01-01]: Used Traefik v2.11 instead of v3.4 due to Docker API version incompatibility on host
 - [01-01]: Traefik placed on frontend-net + backend-net for routing to both web and api services
@@ -133,7 +141,8 @@ None yet.
 
 ### Blockers/Concerns
 
-None yet.
+- [Roadmap v1.1]: DÖE OpenData API pagination/rate-limit parameters unverified (Swagger UI is JS-rendered) — resolve via a live API call during Phase 10 planning, not assumed from docs.
+- [Roadmap v1.1]: Whether AI-AG NetServer / cosinex VMP search pages require JS rendering is unverified — needs a Phase 13 start-of-phase spike before committing to playwright.
 
 ### Quick Tasks Completed