diff --git a/.planning/REQUIREMENTS.md b/.planning/REQUIREMENTS.md index fa0daff..494a6e1 100644 --- a/.planning/REQUIREMENTS.md +++ b/.planning/REQUIREMENTS.md @@ -1,185 +1,77 @@ -# Requirements: Tessera +# Requirements — Milestone v1.1: Ausschreibungs-Radar -**Defined:** 2026-06-18 -**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. +**Module:** Ausschreibungs-Radar — durchsucht deutsche Vergabeportale nach Ausschreibungen, filtert nach Kriterien, zeigt Treffer im Portal an und versendet optional per E-Mail. +**Basis-Research:** `.planning/research/SUMMARY.md`, `.planning/research/ausschreibungs-portale-feasibility.md` +**Defined:** 2026-07-17 -## v1 Requirements +> v1.0-Requirements sind ausgeliefert und in PROJECT.md (Validated) nachgehalten. Diese Datei enthält nur die v1.1-Requirements. REQ-IDs setzen neue, modul-lokale Kategorien. -Requirements for initial release. Each maps to roadmap phases. +## v1.1 Requirements -### Authentication & User Management +### INGEST — Datenquellen -- [ ] **AUTH-01**: Initialer Admin-Account wird beim Setup via Docker-ENV erstellt -- [x] **AUTH-02**: Admin kann Benutzer manuell anlegen, bearbeiten und loeschen -- [x] **AUTH-03**: Benutzer kann sich anmelden und abmelden -- [x] **AUTH-04**: Benutzer-Session bleibt ueber Browser-Refresh bestehen -- [ ] **AUTH-05**: Rollenbasierte Zugriffskontrolle (Admin, User) -- [ ] **AUTH-06**: Benutzer koennen per LDAP/AD importiert werden +- [ ] **INGEST-01**: Das System ruft Ausschreibungen zeitgesteuert über die DÖE OpenData-API (oeffentlichevergabe.de, eForms/OCDS, auth-frei) ab. +- [ ] **INGEST-02**: Das System importiert Ausschreibungen von Administration-Intelligence-NetServer-Portalen (lhs-vpbw, tender24, vergabe.landbw) über einen konfigurierbaren Adapter. +- [ ] **INGEST-03**: Das System importiert Ausschreibungen vom cosinex-Vergabemarktplatz (DTVP) über einen Adapter. +- [ ] **INGEST-04**: Das System importiert Ausschreibungen aus RSS-Feeds (subreport-elvis, service.bund.de). +- [ ] **INGEST-05**: Das System liest Portal-Benachrichtigungs-E-Mails aus einem konfigurierten Postfach ein (nutzt bestehende DKV-Inbox-Infrastruktur) und extrahiert daraus Ausschreibungen. +- [ ] **INGEST-06**: Jede Quelle wird einmal zentral pro Zeitplan abgefragt (poll-once-fan-out-many), Intervall pro Quelle im Admin-Bereich konfigurierbar; das Ergebnis wird an alle passenden Mandanten-Suchprofile verteilt. +- [ ] **INGEST-07**: vergabe24 und aumass sind als harte Denylist hinterlegt und können nicht als automatische Scraping-Quelle registriert werden (AGB-Verbot). -### Multi-Tenancy +### SCHEMA — Normalisierung & Deduplizierung -- [ ] **TNNT-01**: Daten sind per PostgreSQL Row-Level Security mandantengetrennt -- [x] **TNNT-02**: Admin kann Mandanten anlegen und verwalten -- [ ] **TNNT-03**: Jeder Request wird automatisch dem richtigen Mandanten zugeordnet +- [ ] **SCHEMA-01**: Alle Quellen werden in ein einheitliches, OCDS-orientiertes Ausschreibungs-Schema normalisiert (Titel, Auftraggeber, CPV-Codes, Region/PLZ, Frist, geschätzter Wert, Verfahrensart, Quell-URL, Rohdaten). Ausschreibungsdaten sind plattform-global, nicht mandantengebunden. +- [ ] **SCHEMA-02**: Das System erkennt Änderungen an bereits importierten Ausschreibungen (Fristverlängerung, Aufhebung) über einen Content-Hash und aktualisiert den Datensatz. +- [ ] **SCHEMA-03**: Dieselbe Ausschreibung aus mehreren Quellen wird zu einem Eintrag mit mehreren Quell-Links dedupliziert (Schlüssel: OCID → Quelle:NoticeId → Fuzzy-Fingerprint aus Auftraggeber+Titel+CPV+Frist+Wert). Dedup greift erst ab der zweiten aktiven Quelle. -### Portal Shell +### FILTER — Suche & Profile -- [x] **PRTAL-01**: Schmale Kopfzeile mit Branding und Benutzer-Menu -- [ ] **PRTAL-02**: Linke Seitenleiste zeigt Kategorien und aktivierte Module -- [ ] **PRTAL-03**: Ausgewaehltes Modul oeffnet sich im Hauptbereich (Mitte) -- [x] **PRTAL-04**: Responsive Layout fuer verschiedene Bildschirmgroessen -- [ ] **PRTAL-05**: Module koennen in der Seitenleiste durchsucht und gefiltert werden +- [ ] **FILTER-01**: Nutzer kann per Volltext-Stichwort (Titel/Beschreibung) suchen. +- [ ] **FILTER-02**: Nutzer kann nach Region / PLZ / Bundesland filtern. +- [ ] **FILTER-03**: Nutzer kann nach CPV-Code / Branche filtern (hierarchische Auswahl mit Autocomplete). +- [ ] **FILTER-04**: Nutzer kann nach Abgabefrist filtern, inkl. Option „nur noch offene". +- [ ] **FILTER-05**: Nutzer kann nach geschätztem Auftragswert (min/max) filtern; Ausschreibungen ohne Wertangabe werden korrekt behandelt. +- [ ] **FILTER-06**: Nutzer kann Suchprofile (Kombination aus Filterkriterien) speichern, bearbeiten und löschen — pro Nutzer, mandantenbewusst. -### Marketplace +### UI — Anzeige & Triage -- [ ] **MRKT-01**: Uebersicht aller verfuegbaren Module mit Beschreibung und Kategorie -- [ ] **MRKT-02**: Admin kann Module pro Mandant aktivieren und deaktivieren -- [ ] **MRKT-03**: Nur aktivierte Module erscheinen in der Seitenleiste des Mandanten -- [ ] **MRKT-04**: Module sind in Kategorien gruppiert +- [ ] **UI-01**: Nutzer sieht eine durchsuchbare, sortierbare Trefferliste (Sortierung nach Frist, Wert, Veröffentlichungsdatum). +- [ ] **UI-02**: Nutzer öffnet eine Detailansicht einer Ausschreibung mit Link zur Quelle und ggf. Dokument-URLs (keine lokale Spiegelung der Vergabeunterlagen). +- [ ] **UI-03**: Nutzer kann Treffer als gelesen/ungelesen markieren (pro Nutzer). +- [ ] **UI-04**: Nutzer kann Treffer als Favorit/Merkliste markieren und eine Merklisten-Ansicht filtern (pro Nutzer). +- [ ] **UI-05**: Die UI weist die Abdeckung transparent aus (Oberschwelle vs. Unterschwelle), damit „keine Treffer" nicht als Fehler missverstanden wird. +- [ ] **UI-06**: Ausgeschlossene Portale (vergabe24, aumass) werden als „manuell zu überwachen" mit Direktlink angezeigt. -### Dashboard +### NOTIFY — Benachrichtigung -- [x] **DASH-01**: Konfigurierbares Dashboard als Startseite mit Drag & Drop Grid -- [x] **DASH-02**: Widgets koennen frei positioniert und in der Groesse geaendert werden -- [x] **DASH-03**: Uhr-Widget (analog oder digital) -- [x] **DASH-04**: Suchleiste-Widget (oeffnet Google/Suchmaschine im Browser) -- [x] **DASH-05**: Kalender-Widget mit Terminvorschau -- [x] **DASH-06**: Notiz-Widget (Freitext-Kachel) -- [x] **DASH-07**: Dashboard-Layout wird pro Benutzer gespeichert -- [ ] **DASH-08**: Taschenrechner-Widget (Grundrechenarten, Tastatureingabe) -- [ ] **DASH-09**: Favoriten-Widget mit Backend-Persistenz (Links mit Titel, URL, Icon) -- [ ] **DASH-10**: Stoppuhr-Widget (Start/Stop/Reset, Rundenzeiten) -- [ ] **DASH-11**: Alle Widgets haben einheitliche Grid-Constraints (gleiche minW/minH/defaultW/defaultH) +- [ ] **NOTIFY-01**: Nutzer erhält einen periodischen E-Mail-Digest passender Treffer; Intervall im Webinterface konfigurierbar. +- [ ] **NOTIFY-02**: Nutzer erhält optional eine Sofort-E-Mail bei einem neuen Treffer eines aktiven Suchprofils; im Webinterface aktivierbar. +- [ ] **NOTIFY-03**: Das System unterscheidet „getroffen" von „benachrichtigt" (kein Doppelversand Digest+Sofort; kein Rückstau-Massenversand beim Anlegen eines Suchprofils). +- [ ] **NOTIFY-04**: Der E-Mail-Versand nutzt die mandantenspezifische SMTP-Konfiguration (bestehendes DKV-Mail-Muster). -### Kalender-Integration +### CONFIG — Modul & Verwaltung -- [ ] **CAL-01**: In Einstellungen koennen mehrere Kalenderquellen eingebunden werden (WebDAV, Exchange, ICS-Link) -- [x] **CAL-02**: Benutzer kann waehlen welche Kalender im Widget angezeigt werden -- [x] **CAL-03**: Benutzer kann waehlen fuer welche Kalender Terminvorschauen angezeigt werden +- [ ] **CONFIG-01**: Das Modul ist im Marketplace registriert und pro Mandant aktivierbar (wie DKV-Fleet- und Cert-Manager-Modul). +- [ ] **CONFIG-02**: Admin verwaltet Quellen-Poll-Konfiguration sowie das E-Mail-Ingestion-Postfach pro Mandant (Zugangsdaten verschlüsselt gespeichert). +- [ ] **CONFIG-03**: Die gesamte Modul-UI ist mehrsprachig (Deutsch + Englisch, i18n). -### Module System +## Future Requirements (deferred) -- [ ] **MOD-01**: Versioniertes Modul-SDK mit standardisiertem Interface (@tessera/sdk) -- [ ] **MOD-02**: Module werden per Datenbank-Registry verwaltet -- [ ] **MOD-03**: Module koennen ohne Neustart aktiviert/deaktiviert werden -- [ ] **MOD-04**: Modul-UIs werden per Lazy Loading geladen (kein Bundle-Bloat) +- [ ] TED API v3 (EU-weite Redundanz) — für DE-only weitgehend redundant zu DÖE. +- [ ] Relevanz-/Ranking-Score innerhalb eines Suchprofils. +- [ ] Dashboard-Widget „Ausschreibungen mit naher Frist" (nutzt Phase-8-Widget-Framework). +- [ ] CSV/Excel-Export gefilterter Ergebnisse. +- [ ] Team-/Kollaborationsfunktionen (Zuweisung, interne Notizen). -### Domaincheck (Erstes Modul) +## Out of Scope (explizit ausgeschlossen) -- [ ] **DCHK-01**: Benutzer kann eine Domain in ein Eingabefeld eingeben -- [ ] **DCHK-02**: System prueft ob die Domain registriert oder frei ist -- [ ] **DCHK-03**: Ergebnis wird klar angezeigt (frei/registriert) - -### UI & Internationalisierung - -- [x] **UI-01**: Light/Dark Theme umschaltbar pro Benutzer -- [x] **UI-02**: Zweisprachig: Deutsch und Englisch mit Sprachwahl -- [x] **UI-03**: i18n-Framework von Anfang an integriert (alle Strings ueber t('key')) - -### Infrastruktur - -- [x] **INFRA-01**: Komplette Anwendung laeuft als Docker-Compose-Stack -- [x] **INFRA-02**: PostgreSQL-Datenbank im Container -- [x] **INFRA-03**: Docker-Netzwerksegmentierung (Frontend/Backend/Data) -- [x] **INFRA-04**: Automatisierte Gitea-Integration (Commits, Pushes, Merges) - -### Desktop-Client - -- [x] **DESK-01**: Tauri-basierter Desktop-Wrapper fuer Windows und Linux -- [x] **DESK-02**: Desktop-App verbindet sich mit dem Web-Backend (kein eigenstaendiger Server) - -## v2 Requirements - -Deferred to future release. Tracked but not in current roadmap. - -### Authentication Erweiterungen - -- **AUTH-V2-01**: SSO/OIDC-Anbindung -- **AUTH-V2-02**: Zwei-Faktor-Authentifizierung (2FA) -- **AUTH-V2-03**: Magic-Link Login - -### Marketplace Erweiterungen - -- **MRKT-V2-01**: Bezahlsystem fuer Module (Lizenzschluessel oder Abo) -- **MRKT-V2-02**: Drittanbieter koennen Module einreichen -- **MRKT-V2-03**: Bewertungen und Reviews fuer Module - -### Erweiterte Features - -- **FEAT-V2-01**: Notification Center (In-App-Benachrichtigungen) -- **FEAT-V2-02**: Per-Tenant Branding (Logo + Akzentfarbe) -- **FEAT-V2-03**: Keyboard Shortcuts und Command Palette -- **FEAT-V2-04**: Admin-Impersonation (als anderer Benutzer agieren) -- **FEAT-V2-05**: Onboarding-Wizard fuer neue Mandanten - -## Out of Scope - -| Feature | Reason | -|---------|--------| -| Mobile App | Web-first, Desktop-Wrapper reicht fuer v1 | -| Real-time Chat | Hohe Komplexitaet, nicht Kern der Plattform | -| Video/Streaming | Storage/Bandwidth, nicht relevant fuer Workflow-Tools | -| Payment/Billing | Lizenzierung erstmal per Admin-Freischaltung | -| Third-Party Module SDK | Erst eigene Module, oeffnung spaeter | -| Microservice-Architektur | Modular Monolith reicht, Extraction spaeter moeglich | +- Direktes Scraping von vergabe24 & aumass — AGB-Verbot automatisierter Zugriffe; Oberschwellen-Daten kommen ohnehin über DÖE. +- Generisches „beliebiges Portal scrapen"-Framework — zu fragil über inkompatible Portal-Familien, dauerhafter Wartungsaufwand. +- Sub-stündliches Polling — Ausschreibungs-Lebenszyklen laufen über Tage/Wochen; erhöht nur Last/ToS-Risiko. +- Vollständiges Bid-Management/CRM (Angebotserstellung, Einreichung, Win/Loss) — anderes Produktsegment. +- KI-Zusammenfassungen / Bid-Fit-Scoring — verfrüht, eigener AI-SPEC-Phase vorbehalten. +- Lokale Spiegelung/Hosting der Vergabeunterlagen — rechtlich unklar; nur Verlinkung zur Quelle. ## Traceability -Which phases cover which requirements. Updated during roadmap creation. - -| Requirement | Phase | Status | -|-------------|-------|--------| -| AUTH-01 | Phase 2 | Pending | -| AUTH-02 | Phase 2 | Complete | -| AUTH-03 | Phase 2 | Complete | -| AUTH-04 | Phase 2 | Complete | -| AUTH-05 | Phase 2 | Pending | -| AUTH-06 | Phase 2 | Pending | -| TNNT-01 | Phase 2 | Pending | -| TNNT-02 | Phase 2 | Complete | -| TNNT-03 | Phase 2 | Pending | -| PRTAL-01 | Phase 1 | Complete | -| PRTAL-02 | Phase 4 | Pending | -| PRTAL-03 | Phase 4 | Pending | -| PRTAL-04 | Phase 1 | Complete | -| PRTAL-05 | Phase 4 | Pending | -| MRKT-01 | Phase 4 | Pending | -| MRKT-02 | Phase 4 | Pending | -| MRKT-03 | Phase 4 | Pending | -| MRKT-04 | Phase 4 | Pending | -| DASH-01 | Phase 5 | Complete | -| DASH-02 | Phase 5 | Complete | -| DASH-03 | Phase 5 | Complete | -| DASH-04 | Phase 5 | Complete | -| DASH-05 | Phase 5 | Backend Complete (05-03) | -| DASH-06 | Phase 5 | Complete | -| DASH-07 | Phase 5 | Complete | -| CAL-01 | Phase 5 | Backend Complete (05-03) | -| CAL-02 | Phase 5 | Backend Complete (05-03) | -| CAL-03 | Phase 5 | Backend Complete (05-03) | -| MOD-01 | Phase 3 | Pending | -| MOD-02 | Phase 3 | Pending | -| MOD-03 | Phase 3 | Pending | -| MOD-04 | Phase 3 | Pending | -| DCHK-01 | Phase 3 | Pending | -| DCHK-02 | Phase 3 | Pending | -| DCHK-03 | Phase 3 | Pending | -| UI-01 | Phase 1 | Complete | -| UI-02 | Phase 1 | Complete | -| UI-03 | Phase 1 | Complete | -| INFRA-01 | Phase 1 | Complete | -| INFRA-02 | Phase 1 | Complete | -| INFRA-03 | Phase 1 | Complete | -| INFRA-04 | Phase 6 | Complete | -| DESK-01 | Phase 6 | Complete | -| DESK-02 | Phase 6 | Complete | - -**Coverage:** - -- v1 requirements: 44 total -- Mapped to phases: 44 -- Unmapped: 0 - ---- -*Requirements defined: 2026-06-18* -*Last updated: 2026-06-18 after roadmap creation* +_(Wird vom Roadmapper befüllt: REQ-ID → Phase.)_