diff --git a/.planning/REQUIREMENTS.md b/.planning/REQUIREMENTS.md index 494a6e1..1c6bce9 100644 --- a/.planning/REQUIREMENTS.md +++ b/.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. diff --git a/.planning/ROADMAP.md b/.planning/ROADMAP.md index 1d3243a..f22b39d 100644 --- a/.planning/ROADMAP.md +++ b/.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 | - | diff --git a/.planning/STATE.md b/.planning/STATE.md index 28f3ba8..a5a23e6 100644 --- a/.planning/STATE.md +++ b/.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