# Roadmap: Tessera

## 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. 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

**Phase Numbering:**

- Integer phases (1, 2, 3): Planned milestone work
- Decimal phases (2.1, 2.2): Urgent insertions (marked with INSERTED)

Decimal phases appear between their surrounding integers in numeric order.

- [x] **Phase 1: Foundation & Portal Shell** - Docker infrastructure, database with RLS, frontend shell with i18n and theming (completed 2026-06-18)
- [~] **Phase 2: Authentication & Multi-Tenancy** - User accounts, sessions, RBAC, tenant isolation per request (4/5 plans; 02-05 visual verification never run)
- [x] **Phase 3: Module System & Domaincheck** - Module SDK, registry, lazy loading, and first proof-of-concept module (completed 2026-06-20)
- [x] **Phase 4: Marketplace & Portal Navigation** - Module catalog, licensing, activation, and sidebar integration (completed 2026-06-23)
- [x] **Phase 5: Dashboard & Calendar** - Configurable widget grid with drag-and-drop, core widgets, and calendar integration (completed 2026-06-24)
- [x] **Phase 6: Desktop Client & CI/CD** - Tauri wrapper for Windows/Linux and automated Gitea integration (completed 2026-06-25)
- [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

### Phase 1: Foundation & Portal Shell

**Goal:** Users can access a running portal application with responsive layout, theme switching, and bilingual interface -- the structural frame into which all features will be placed.
**Mode:** mvp
**Depends on**: Nothing (first phase)
**Requirements**: INFRA-01, INFRA-02, INFRA-03, PRTAL-01, PRTAL-04, UI-01, UI-02, UI-03
**Success Criteria** (what must be TRUE):

  1. User can access the portal in a browser served from a Docker Compose stack with PostgreSQL
  2. User sees a responsive layout with header (branding area) and sidebar frame that adapts to screen size
  3. User can toggle between light and dark theme and the preference persists
  4. User can switch between German and English interface language
  5. All UI strings are rendered through the i18n framework (no hardcoded text)

**Plans**: 3 plans
**Wave 1**

- [x] 01-01-PLAN.md -- Walking Skeleton: Monorepo + Docker Compose stack with NestJS, Next.js, PostgreSQL, Traefik

**Wave 2** *(blocked on Wave 1 completion)*

- [x] 01-02-PLAN.md -- Portal Shell: Design tokens, i18n (DE/EN), theme switching, responsive layout with header + sidebar

**Wave 3** *(blocked on Wave 2 completion)*

- [x] 01-03-PLAN.md -- Visual Verification: Human confirms portal appearance and interactions

**UI hint**: yes

### Phase 2: Authentication & Multi-Tenancy

**Goal:** Users can securely log in, manage accounts, and operate within isolated tenant boundaries -- every request is scoped to the correct tenant with data fully separated at the database level.
**Mode:** mvp
**Depends on**: Phase 1
**Requirements**: AUTH-01, AUTH-02, AUTH-03, AUTH-04, AUTH-05, AUTH-06, TNNT-01, TNNT-02, TNNT-03
**Success Criteria** (what must be TRUE):

  1. Initial admin account is created automatically from Docker environment variables on first startup
  2. Admin can create, edit, and delete user accounts with role assignment (Admin/User)
  3. User can log in and log out, with session surviving browser refresh
  4. Admin can create and manage tenants, and each user's data is isolated per tenant via RLS
  5. Users can be imported from an LDAP/AD directory

**Plans**: 5 plans

**Wave 1**

- [x] 02-01-PLAN.md -- Backend Auth Foundation: Prisma schema, RLS migration, JWT Passport auth, admin seed, tenant middleware

**Wave 2** *(blocked on Wave 1 completion)*

- [x] 02-02-PLAN.md -- Frontend Auth & CRUD: Login page, Next.js middleware, user/tenant management UI, auth-wired portal
- [x] 02-03-PLAN.md -- Password Reset & Mail: SUS package verification, MailModule, password reset flow, force-change interceptor

**Wave 3** *(blocked on Wave 2 completion)*

- [x] 02-04-PLAN.md -- LDAP Integration: LDAP sync service, per-tenant config, field mapping, admin UI

**Wave 4** *(blocked on Wave 3 completion)*

- [ ] 02-05-PLAN.md -- Visual Verification: Human confirms complete auth and multi-tenancy flow (never executed — no summary)

**UI hint**: yes

### Phase 3: Module System & Domaincheck

**Goal:** The platform can discover, register, and load modules dynamically -- validated end-to-end by a working Domaincheck module that users can interact with.
**Mode:** mvp
**Depends on**: Phase 2
**Requirements**: MOD-01, MOD-02, MOD-03, MOD-04, DCHK-01, DCHK-02, DCHK-03
**Success Criteria** (what must be TRUE):

  1. Modules are registered in a database-driven registry with a versioned SDK interface
  2. An admin can activate and deactivate a module without restarting the application
  3. Module UIs load on demand (lazy loading) -- no bundle bloat from inactive modules
  4. User can open the Domaincheck module, enter a domain, and see whether it is registered or available

**Plans**: 4 plans

**Wave 1**

- [x] 03-01-PLAN.md -- Module SDK, Prisma Registry, Activation API

**Wave 2** *(blocked on Wave 1 completion)*

- [x] 03-02-PLAN.md -- Domaincheck Module: Backend DNS + Frontend UI
- [x] 03-03-PLAN.md -- Lazy Loading, Category Pages, Expanded Module View

**Wave 3** *(blocked on Wave 2 completion)*

- [x] 03-04-PLAN.md -- Visual Verification: Human confirms module system

**UI hint**: yes

### Phase 4: Marketplace & Portal Navigation

**Goal:** Users can browse available modules in a categorized marketplace, admins can activate modules per tenant, and activated modules appear in the sidebar for navigation.
**Mode:** mvp
**Depends on**: Phase 3
**Requirements**: MRKT-01, MRKT-02, MRKT-03, MRKT-04, PRTAL-02, PRTAL-03, PRTAL-05
**Success Criteria** (what must be TRUE):

  1. User can browse a marketplace view showing all available modules with descriptions and categories
  2. Admin can activate or deactivate modules for their tenant from the marketplace
  3. Only activated modules appear in the left sidebar, grouped by category
  4. User can select a module from the sidebar and it opens in the main content area
  5. User can search and filter modules in the sidebar

**Plans**: 4 plans

**Wave 1**

- [x] 04-01-PLAN.md -- Test infra (Vitest) + marketplace i18n + Marketplace page slice: card grid browse + activate (MRKT-01/02/04)

**Wave 2** *(blocked on Wave 1 completion)*

- [x] 04-02-PLAN.md -- Marketplace refinements: search/category/status filters, deactivation dialog, toast, Super-Admin tenant context, module detail page
- [x] 04-03-PLAN.md -- Sidebar enhancement: Next.js Link + usePathname active state, per-module links, sidebar search, live refresh (PRTAL-02/03/05, MRKT-03)

**Wave 3** *(blocked on Wave 2 completion)*

- [x] 04-04-PLAN.md -- Visual Verification: Human confirms marketplace, activation, tenant context, and sidebar navigation

**UI hint**: yes

### Phase 5: Dashboard & Calendar

**Goal:** Users have a personal, configurable start page with freely arrangeable widgets -- including clock, search, notes, and calendar with external calendar source integration.
**Mode:** mvp
**Depends on**: Phase 4
**Requirements**: DASH-01, DASH-02, DASH-03, DASH-04, DASH-05, DASH-06, DASH-07, CAL-01, CAL-02, CAL-03
**Success Criteria** (what must be TRUE):

  1. User sees a configurable dashboard as their start page with a drag-and-drop grid
  2. User can add, reposition, and resize widgets (clock, search bar, calendar, notes)
  3. Dashboard layout is saved per user and restored on next login
  4. User can configure external calendar sources (WebDAV, Exchange, ICS) in settings
  5. Calendar widget shows upcoming events from selected calendar sources

**Plans**: 5 plans

**Wave 1**

- [x] 05-01-PLAN.md -- Dashboard foundation: Prisma models, CRUD API, grid, edit-mode, clock widget, settings shell, header link, i18n (DASH-01/02/03/07)

**Wave 2** *(blocked on Wave 1 completion)*

- [x] 05-02-PLAN.md -- Search + Notes widgets, widget settings panel, SearchProvider backend (DASH-04/06)

**Wave 3** *(blocked on Wave 2 completion)*

- [x] 05-03-PLAN.md -- Calendar backend: Prisma model, AES-256-GCM crypto, source CRUD, CalDAV/ICS/Exchange providers, DB push (CAL-01/02/03, DASH-05)

**Wave 4** *(blocked on Wave 3 completion)*

- [x] 05-04-PLAN.md -- Calendar frontend: calendar widget, calendar settings page, API client (CAL-01/02/03, DASH-05)

**Wave 5** *(blocked on Wave 4 completion)*

- [x] 05-05-PLAN.md -- Visual Verification: Human confirms dashboard, widgets, calendar, settings

**UI hint**: yes

### Phase 6: Desktop Client & CI/CD

**Goal:** Users can install and run Tessera as a native desktop application, and the development workflow includes automated version control via Gitea.
**Mode:** mvp
**Depends on**: Phase 5
**Requirements**: DESK-01, DESK-02, INFRA-04
**Success Criteria** (what must be TRUE):

  1. User can install a Tauri-based desktop app on Windows or Linux
  2. Desktop app connects to the existing web backend (no standalone server)
  3. Code changes are automatically committed and pushed to Gitea with minimal manual intervention

**Plans**: 3 plans

**Wave 1** *(parallel — disjoint files)*

- [x] 06-01-PLAN.md -- Desktop foundation: Tauri toolchain, apps/desktop scaffold, URL-loading WebView + first-run server URL setup (DESK-01/02)
- [x] 06-03-PLAN.md -- CI/CD: Gitea remote, act_runner, multi-stage Gitea Actions pipeline (lint+type-check -> tests -> docker build+deploy) (INFRA-04)

**Wave 2** *(blocked on 06-01)*

- [x] 06-02-PLAN.md -- Desktop native: tray + close-to-tray, window-state, autostart, notifications + version check, branded icon, AppImage+NSIS bundles, /health/version API (DESK-01/02)

### Phase 7: DKV Fleet Module

**Goal:** Administrators can automatically process DKV fuel card invoices by monitoring an email inbox, parsing PDF attachments, mapping license plates to drivers, and exporting structured Excel reports via SMTP.
**Mode:** mvp
**Depends on**: Phase 6
**Requirements**: DKV-01, DKV-02, DKV-03, DKV-04, DKV-05
**Success Criteria** (what must be TRUE):

  1. System automatically detects DKV invoice PDFs from a configured email inbox (IMAP or Exchange)
  2. All transactions are parsed per vehicle with: date, service station, km reading, product, quantity, unit, net/gross amounts
  3. License plate → driver mapping is importable as CSV and manually editable in the UI
  4. Processed data is exported as Excel file and sent to a configurable recipient via SMTP
  5. SMTP settings are configurable in general settings (shared with other modules)
  6. Module configuration (inbox, sender filter, folder, recipient) is editable in the module settings UI

**Plans**: 6 plans

**Wave 0**

- [x] 07-01-PLAN.md -- Backend foundation: deps install, Prisma models, ScheduleModule, crypto export, validated DKV PDF parser (DKV-02)

**Wave 1** *(blocked on Wave 0 completion)*

- [x] 07-02-PLAN.md -- Inbox-access layer: InboxProvider interface, IMAP + Exchange providers, config/vehicle/history DTOs (DKV-01)
- [x] 07-03-PLAN.md -- Export + delivery + SMTP backend: SettingsModule (SMTP CRUD + test), DkvExportService (xlsx + prune), DkvMailService, MailModule DB-SMTP migration (DKV-04/05, D-06)

**Wave 2** *(blocked on Wave 1 completion)*

- [x] 07-04-PLAN.md -- Pipeline integration: DkvService orchestration, dynamic scheduler, DkvController REST, module registry seed, i18n keys (DKV-01/03/04/05)
- [x] 07-05-PLAN.md -- Module frontend: dkv-api client, main page (history + export download + "Jetzt prüfen"), inbox settings form, vehicle CRUD + CSV import (DKV-01/03/04)
- [x] 07-06-PLAN.md -- SMTP settings frontend: settings-api client, SMTP config form + connection test, settings-sidebar "Allgemein" category (DKV-05)

**UI hint**: yes

### Phase 8: Dashboard Widgets Vollimplementierung

**Goal:** Users have a complete dashboard widget set — Calculator, Favorites (with backend persistence), and Stopwatch added alongside existing widgets. All widgets share unified grid constraints for a consistent layout experience.
**Mode:** mvp
**Depends on**: Phase 5
**Requirements**: DASH-08, DASH-09, DASH-10, DASH-11
**Success Criteria** (what must be TRUE):

  1. User can open a Calculator widget and perform basic arithmetic operations with keyboard support
  2. User can manage favorite links (add, edit, delete) in the Favorites widget; links persist across sessions via a backend DB table (FavoriteLink)
  3. User can start, stop, and reset a Stopwatch widget with lap time recording
  4. All dashboard widgets share the same minW, minH, defaultW, defaultH grid constraint values
  5. Existing widgets (Clock, Search, Calendar, Notes) remain fully functional after constraint normalization

**Plans**: 4/4 plans complete

**Wave 1**

- [x] 08-01-PLAN.md — Foundation + Calculator slice: registry constraints for all 4 new types, catalog, DTO, i18n; working Calculator widget (DASH-08, DASH-11)

**Wave 2** *(blocked on Wave 1 completion)*

- [x] 08-02-PLAN.md — Stopwatch widget: start/stop/reset/lap with config persistence + reload reconstruction (DASH-10)

**Wave 3** *(blocked on Wave 2 completion)*

- [x] 08-03-PLAN.md — Favorites slice: FavoriteLink schema + FavoritesModule (SSRF icon discovery) + FavoritesWidget list/grid + inline CRUD (DASH-09)

**Wave 4** *(blocked on Wave 3 completion)*

- [x] 08-04-PLAN.md — Link widget: single-link tile reusing favorites backend, row/tile views (DASH-09 / D-06)

**UI hint**: yes

### Phase 9: Cert Manager Module

**Goal:** Users can upload or paste certificates in any common format, inspect their details, split fullchain/P7B bundles into individual certificates, merge certs into chains or PFX bundles, and convert between formats — all processed server-side with no database persistence.
**Mode:** mvp
**Depends on**: Phase 3
**Requirements**: CERT-01, CERT-02, CERT-03, CERT-04, CERT-05, CERT-06
**Success Criteria** (what must be TRUE):

  1. User can upload a cert file (PEM, DER, PFX/P12, CRT, CER, P7B) or paste PEM/CRT text and see parsed details (subject, issuer, validity, SANs, fingerprint)
  2. User can split a fullchain.pem or P7B bundle into individual certificate files (downloadable)
  3. User can merge multiple cert files into a PEM chain or a PFX bundle (with password)
  4. User can convert between PEM, DER, PFX/P12, P7B, CRT/CER formats
  5. Password-protected PFX/PKCS12 files can be opened (password prompt) and created (password input)
  6. Module appears in the module registry with slug `cert-manager`

**Plans**: 6/6 plans complete

Plans:
**Wave 1**

- [x] 09-01-PLAN.md — API foundation: install node-forge + Vitest runner, scaffold module, seed registry (CERT-06), shared node-forge helpers
- [x] 09-02-PLAN.md — Frontend shell: tab page, DropZone, conditional password field, download helpers, certManager i18n (de/en)

**Wave 2** *(blocked on Wave 1 completion)*

- [x] 09-03-PLAN.md — Inspect slice: parseCert (PEM/DER/PFX/P7B) + POST /parse + Inspect tab (CERT-01, CERT-05 read)

**Wave 3** *(blocked on Wave 2 completion)*

- [x] 09-04-PLAN.md — Split slice: splitCerts (fullchain/P7B) + POST /split + Split tab download list (CERT-02)

**Wave 4** *(blocked on Wave 3 completion)*

- [x] 09-05-PLAN.md — Convert slice: convertCert (PEM/DER/P7B round-trips) + POST /convert + Convert tab (CERT-04)

**Wave 5** *(blocked on Wave 4 completion)*

- [x] 09-06-PLAN.md — Merge/PFX slice: mergeCerts (PEM chain + password PFX) + POST /merge + Merge tab + PFX convert option (CERT-03, CERT-05 write)

**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**: 6 plans

**Wave 1**

- [ ] 10-01-PLAN.md — Foundation: install fast-xml-parser/adm-zip/csv-parse (adm-zip supply-chain checkpoint), add global Tender + TenderSourcePollConfig models, [BLOCKING] migration (SCHEMA-01)

**Wave 2** *(blocked on Wave 1 completion)*

- [ ] 10-02-PLAN.md — Marketplace registration slice: self-seed tender-radar module, module-loader whitelist entry, placeholder page, singleton doe-opendata poll config (CONFIG-01)

**Wave 3** *(blocked on Wave 2 completion)*

- [ ] 10-03-PLAN.md — DÖE adapter + normalizer (TDD): fetch/extract/parse day-export ZIP, D-02 open-tender filter, eForms-primary normalize with dedupKey + contentHash (INGEST-01, SCHEMA-01)

**Wave 4** *(blocked on Wave 3 completion)*

- [ ] 10-04-PLAN.md — Ingestion + shared scheduler: day-cursor gate, upsert change-detection, single global cron (poll-once-fan-out-many), 90-day retention, two-tenant safety test (SCHEMA-02, INGEST-06)

**Wave 5** *(blocked on Wave 4 completion)*

- [ ] 10-05-PLAN.md — Controller + admin source-config: global ModuleGuard-gated read, admin-configurable poll interval applied live to scheduler (INGEST-06)

**Wave 6** *(blocked on Wave 5 completion)*

- [ ] 10-06-PLAN.md — Admin config UI: tender-radar-api client + settings page SourceConfigForm reading/writing GET/PUT source-config, mirroring DKV InboxConfigForm (INGEST-06 admin-UI)

**UI hint**: yes (admin source-config settings form; results UI is Phase 11)

### 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 -> 10 -> 11 -> 12 -> 13 -> 14

| Phase | Plans Complete | Status | Completed |
|-------|----------------|--------|-----------|
| 1. Foundation & Portal Shell | 3/3 | Complete | 2026-06-18 |
| 2. Authentication & Multi-Tenancy | 4/5 | Incomplete — 02-05 visual verification never run | - |
| 3. Module System & Domaincheck | 4/4 | Complete | 2026-06-20 |
| 4. Marketplace & Portal Navigation | 4/4 | Complete | 2026-06-23 |
| 5. Dashboard & Calendar | 5/5 | Complete   | 2026-06-24 |
| 6. Desktop Client & CI/CD | 3/3 | Complete | 2026-06-25 |
| 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/6 | 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 | - |