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

docs(14): mark RESEARCH open questions resolved (plan-checker warning 2)

Browse Source
This commit is contained in:
Schalli
2026-07-23 12:17:57 +02:00
parent cf105f0884
commit b2c52843aa
1 changed files with 4 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.planning/phases/14-rss-email-alert-ingestion-module-rollout/14-RESEARCH.md
+4 -3
View File
@@ -544,19 +544,20 @@ async function getConfigForApi(prisma: PrismaService, crypto: CalendarCryptoServ
**If this table is empty:** N/A — see rows above; all three should be confirmed with the user or resolved via a `checkpoint:human-verify`/explicit discuss-phase note before the planner locks task-level detail for the affected areas.
## Open Questions
## Open Questions (RESOLVED)
1. **Email-alert Tender visibility across tenants (see Pitfall 5 / A3)**
1. **Email-alert Tender visibility across tenants (see Pitfall 5 / A3)** — **RESOLVED via CONTEXT.md D-13 (User-Entscheidung 2026-07-23):** E-Mail-Tender sind nur für den konfigurierenden Mandanten sichtbar (nullable `Tender.ownerTenantId`), öffentliche Quellen inkl. RSS bleiben global. Umgesetzt in Plan 14-03.
- What we know: `Tender` is architecturally platform-global (D-03); `TenderEmailConfig` is architecturally per-tenant (D-06). CONTEXT.md doesn't reconcile the two for this specific case.
- What's unclear: Whether this is accepted product behavior (matches the existing "all discovered tenders are shared" philosophy) or an oversight.
- Recommendation: Surface explicitly to the user in `/gsd-discuss-phase` follow-up or as a plan-time `checkpoint:human-verify` before implementing INGEST-05's dedup/storage step — this is a five-minute confirmation that prevents a much larger later rework if the answer is "no, that's not okay."
2. **subreport-elvis `<description>` field structure (see A1)**
2. **subreport-elvis `<description>` field structure (see A1)** — **RESOLVED via Plan 14-02 Task 1:** Baseline schickt nur die bare-minimum Bag (title/link/guid), reicht für INGEST-04; optionale Feld-Anreicherung aus der HTML-Tabelle ist nicht Teil des Baselines. Live-Fixture-Capture bei Bedarf zur Ausführungszeit.
- What we know: It's an HTML `<table>`; the outer feed/item shape (title/link/guid/author) is fully confirmed live.
- What's unclear: The internal table structure (column labels, whether "Angebotsfrist"-equivalent data exists at all for subreport-elvis, unlike service.bund.de where it's confirmed present in the description).
- Recommendation: Capture a fresh, complete raw XML fixture from a live subreport-elvis feed at Wave-0/plan-time (mirroring Phase 13's live-fixture-capture convention for NetServer/cosinex HTML) before deciding whether to attempt the optional field-enrichment for this source, or to ship it with the bare-minimum bag only (title/link/guid — already fully sufficient for INGEST-04's baseline requirement).
3. **Default seeded RSS feeds**
- **RESOLVED via Plan 14-02 Task 2:** service.bund.de wird active-by-default geseedet, die Feed-Liste sonst leer für admin-getriebene Ergänzungen (matcht die „framework ready, activation deferred"-Haltung).
- What we know: service.bund.de's feed is genuinely national/global and safe to seed by default; subreport-elvis has no such single URL.
- What's unclear: Whether to seed zero rows and require an admin action before any RSS ingestion happens, or seed the service.bund.de URL as an always-on default.
- Recommendation: Seed service.bund.de active-by-default (mirrors DÖE's `isActive: true` seed from Phase 10), leave the RSS feed list otherwise empty for admin-driven additions — matches the "framework ready, activation deferred" stance already established for ai-netserver/cosinex-dtvp in Phase 13.