docs(10): add admin config UI plan (INGEST-06 gap), resolve research open questions

2026-07-21 10:08:40 +02:00
parent e7b59d16af
commit b52a0a796b
4 changed files with 152 additions and 5 deletions
@@ -321,7 +321,10 @@ function isOpenTenderNotice(release: { tag?: string[]; awards?: unknown[]; contr
 | A2 | Fetching both `eforms.zip` and `ocds.zip` per poll cycle (two HTTP calls) is acceptable overhead vs. a single-format MVP | Pattern 3 | Low — at day-granularity polling (at most 1-2 real fetches/day per the day-cursor gate), two requests instead of one is negligible; if the planner descopes to single-format for MVP speed, document that deadline/value coverage will be measurably worse (per Pattern 4's 100%-null spot check) as an explicit MVP trade-off, not a silent gap |
 | A3 | The 105-notice, 12-notice, and 11-notice samples (all from 2026-07-20) are representative of typical daily volume/tag distribution, not an anomalous day | Pattern 2, Pattern 4 | Medium — a single day's sample is directional, not statistically proven; if actual production volume/tag ratios differ significantly, the D-02 filter logic itself is still correct (tag-based), only the *magnitude* estimates (70% tender / 16% award / etc.) may shift |

-## Open Questions
+## Open Questions (RESOLVED)
+
+> **Q1 (RESOLVED):** rate-limit tolerance is mitigated, not left open — Plan 04 (`TenderIngestionService`) inserts a ~1-2s polite delay between successive catch-up day-fetches, so the catch-up loop cannot rapid-fire the DÖE host even after extended downtime.
+> **Q2 (RESOLVED):** eForms-vs-OCDS deadline-coverage rate is addressed by the coverage-metric logging recommendation planned into Plan 04 (log `% of ingested tender-tagged notices with non-null deadlineAt`), so the aggregate rate is measured empirically in production instead of re-guessed.

 1. **Exact rate-limit tolerance of the DÖE API (undocumented)**
   - What we know: no `X-RateLimit-*` headers observed on a real response; a `cache-control: max-age=120` + `etag` suggest a caching/CDN layer that can absorb repeated identical requests cheaply.