schalli/tessera-ctl
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 14 Wiki Activity

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

Browse Source
This commit is contained in:
Schalli
2026-07-17 12:54:48 +02:00
parent 21cae97ca0
commit eb3ed949a9
3 changed files with 150 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.planning/ROADMAP.md
+98 -2
View File
@@ -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 | - |