# Phase 10: Ausschreibungs-Radar Foundation & DÖE Ingestion - Context
**Gathered:** 2026-07-17
**Status:** Ready for planning
## Phase Boundary
Fundament des Ausschreibungs-Radar-Moduls: ein neues, im Marketplace registrierbares Tessera-Modul (wie DKV-Fleet/Cert-Manager), das deutsche Ausschreibungen über die DÖE OpenData-API abruft, in ein einheitliches, **plattform-globales** (nicht mandantengebundenes) OCDS-orientiertes Schema normalisiert, Änderungen an bestehenden Einträgen erkennt und alles über einen mandantensicheren **poll-once-fan-out-many**-Scheduler betreibt.
Requirements: CONFIG-01, INGEST-01, INGEST-06, SCHEMA-01, SCHEMA-02.
Nicht in dieser Phase: Filter/UI/Suchprofile (Phase 11), Benachrichtigungen (Phase 12), Scraping-Adapter + Dedup (Phase 13), RSS/E-Mail/i18n-Rollout (Phase 14).
## Implementation Decisions
### DÖE-Ingest-Umfang
- **D-01:** Initialer Backfill = **nur ab jetzt**. Beim ersten plattformweiten DÖE-Poll werden nur ab diesem Zeitpunkt veröffentlichte Ausschreibungen aufgenommen — kein historischer Import. Da die Tender-Daten global sind, sieht ein später aktivierender Mandant den seit Plattformstart aufgelaufenen Bestand. Passt zur späteren Backfill-Unterdrückung bei Benachrichtigungen (Phase 12).
- **D-02:** Nur **offene Ausschreibungen** (aktive Vergaben, auf die man bieten kann — tender/contract notices). Vergabeergebnisse, Zuschläge und Aufhebungen (award/result notices) werden in dieser Phase NICHT aufgenommen.
- **D-03:** Ingest lädt **ganz Deutschland global** (plattformweit einmal), **keine** Vor-Eingrenzung nach Region/CPV beim Ingest — Eingrenzung passiert erst pro Suchprofil (Phase 11). Bewusst wegen Multi-Tenant-Wiederverkauf.
- **D-04:** Standard-Poll-Intervall = **stündlich**, admin-konfigurierbar (INGEST-06).
### Datenaufbewahrung
- **D-05:** Ausschreibungen nach Ablauf der Abgabefrist werden **90 Tage** aufbewahrt, dann gelöscht. Vor Fristablauf: aktiv. Nach Fristablauf: als „abgelaufen" markiert, standardmäßig aus der aktiven Liste ausgeblendet, aber bis zur Löschung recherchierbar.
### Claude's Discretion
- Exakte Prisma-Schema-Felder (OCDS-orientiert, Form gemäß ARCHITECTURE.md), Adapter-Interface (`TenderSourceAdapter`), Normalizer-Interna, Dedup-Key-Berechnung (OCID → Quelle:NoticeId → …) und contentHash-Änderungserkennung.
- DÖE-API-Client (native `fetch` + `fast-xml-parser`, CSV-Fallback), Pagination/Rate-Limit-Handling (Detail per Phase-Research live zu klären).
- Scheduler-Implementierung: **poll-once-fan-out-many, mehrmandantensicher — NICHT** das DKV-`findFirst()`-Single-Tenant-Muster.
- Modul-Registrierung im Marketplace nach DKV/Cert-Manager-Vorbild.
## Canonical References
**Downstream agents MUST read these before planning or implementing.**
### Milestone-Research (verbindlich)
- `.planning/research/SUMMARY.md` — Gesamtbild, Build-Order, Architektur-Kernentscheidungen
- `.planning/research/ARCHITECTURE.md` — normalisiertes Schema, `TenderSourceAdapter`-Abstraktion, global-vs-tenant-Split, Scheduler, Dedup-Strategie, new-vs-modified-Inventar
- `.planning/research/STACK.md` — neue Libraries (fast-xml-parser, csv-parse) + „reuse, nicht neu bauen"-Liste
- `.planning/research/PITFALLS.md` — Multi-Tenant-Scheduler (Pitfall: DKV-findFirst), Tenant-Isolation in Background-Jobs, OCDS/eForms-Parsing-Fallen
- `.planning/research/ausschreibungs-portale-feasibility.md` — DÖE OpenData-API, OCDS-Prefix `ocds-mnwr74`, Swagger-Endpunkt
### Phasen-Vorgaben
- `.planning/ROADMAP.md` § Phase 10 — Ziel + 5 Erfolgskriterien (u.a. Zwei-Mandanten-Scheduler-Test)
- `.planning/REQUIREMENTS.md` — CONFIG-01, INGEST-01, INGEST-06, SCHEMA-01, SCHEMA-02
### Offener Research-Punkt (Phase-Research klären)
- DÖE OpenData Pagination/Rate-Limit-Parameter — Swagger `oeffentlichevergabe.de/documentation/swagger-ui/opendata/` ist JS-gerendert; **live gegen die API verifizieren** bevor der Poll-Zyklus finalisiert wird.
## Existing Code Insights
### Reusable Assets
- `apps/api/src/dkv/` — Modul-Struktur, Scheduler-Pattern (`@nestjs/schedule` + `SchedulerRegistry`) als Vorlage; Mail-/Config-Muster (erst ab Phase 12 relevant).
- `apps/api/src/module-registry/` — Modul-Selbstregistrierung + Marketplace-Aktivierung pro Mandant (CONFIG-01).
- `apps/api/src/prisma/prisma-tenant.extension.ts` (`forTenant`) — Mandanten-Scoping; hier bewusst NUR für tenant-bezogene Tabellen, NICHT für die globale `Tender`-Tabelle.
- `apps/api/prisma/schema.prisma` — Modell-Konventionen (uuid, Timestamps, Migrations-Format).
- Cert-Manager- und DKV-Modul als Gesamt-Template (Controller/Service/Module/Web-UI-Registrierung).
### Established Patterns
- Native `fetch` als HTTP-Client (kein axios) — siehe `icon-discovery.service.ts`, `ics.provider.ts`.
- Migrationen als handgeschriebene timestamped Ordner unter `apps/api/prisma/migrations/`.
### Integration Points
- Neues `TendersModule` self-registriert im Module-Registry.
- Globale `Tender`-Tabelle (kein `tenantId`); tenant-/user-bezogene Tabellen (Suchprofile, Matches, Triage) kommen in Phase 11.
- Scheduler läuft plattformweit einmal pro Quelle, unabhängig von der Anzahl aktiver Mandanten.
## Specific Ideas
- „Nur ab jetzt" + „nur offene" + „90-Tage-Retention" zusammen halten die DB schlank und die Trefferliste relevant (nur bietbare, aktuelle Vergaben).
- Erfolgskriterium aus ROADMAP.md ernst nehmen: Aktivierung für einen zweiten Mandanten darf keinen zweiten DÖE-Poll auslösen (poll-once-fan-out-many).
## Deferred Ideas
- Vergabeergebnisse/Zuschläge/Aufhebungen (award notices) aufnehmen — spätere Erweiterung, außerhalb v1.1-Scope.
- Historischer Backfill (letzte 30 Tage / alles) — bei Bedarf später als Konfig-Option.
- Vor-Eingrenzung des Ingest nach Region/CPV — bewusst verworfen (widerspricht Multi-Tenant-Wiederverkauf); Eingrenzung bleibt Sache der Suchprofile.
- Aufbewahrungsdauer (90 Tage) später ggf. admin-konfigurierbar machen.
None weiter — Diskussion blieb im Phasen-Scope.
---
*Phase: 10-ausschreibungs-radar-foundation-d-e-ingestion*
*Context gathered: 2026-07-17*