5 Commits

Include renames

Author	SHA1	Message	Date
ehoandClaude Sonnet 5	73172510ea	feat(zgw): real per-request identity seam + citizen-scoping (WP-53) ... Replaces the hardcoded DocumentStore.DemoOwner and the static ZgwOptions UserId/UserRepresentation with one per-request CallerIdentity, resolved by a pluggable IIdentityProvider (StubIdentityProvider reads X-Role/X-Subject today; a real OIDC/DigiD provider swaps in without touching any consumer). - Domain/Authorization/{CallerIdentity,IIdentityProvider,StubIdentityProvider}.cs + a resolution middleware in Program.cs, right after correlation-id. - Authz.ResolvePrincipal(ctx) keeps its signature (now reads ctx.Caller().Role), so its ~15 call sites needed no changes. - Every endpoint that passed DocumentStore.DemoOwner to a store now passes ctx.Caller().Bsn. - ZgwTokenProvider gains Mint(CallerIdentity) alongside the original Mint() (kept for calls not tied to one citizen); ZgwHttpClient threads an optional caller through to pick the right overload. - IZaakSource gains ListMyCases(caller, now) — the citizen-scoped read OpenZaakZaakSource backs with ZGW's rol__...__inpBsn filter. GET /applications now routes through it instead of ApplicationStore directly, closing the last "reads a static store" gap for a citizen-facing endpoint. Backend 159/159 tests (+8, incl. an HTTP-level two-identity scoping proof), npm run ci green, no api-client drift. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-30 08:27:53 +02:00
ehoandClaude Opus 4.8	d1abd35b0d	feat(registratie): WP-35 — one Concept per case type (server-enforced) ... Make "at most one unsubmitted Concept per type" a server invariant instead of a client-only convenience. ApplicationStore.Create → CreateConcept guards atomically under the write gate and POST /applications returns 409 when a duplicate would be created. The FE draft-sync recovers from the 409 by adopting the existing Concept (ensureId → findConcept) rather than erroring — one-per-type means the second attempt lands on the existing draft. Typed client regenerated (documents the 409). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-23 11:07:11 +02:00
ehoandClaude Sonnet 5	556f2f47bf	feat(fp): WP-22 — durable persistence (SQLite/EF Core) ... Applications, documents (+ audit log) and the brief move off static in-memory Dictionaries onto a real SQLite file via EF Core, so demo data survives a process restart or `docker compose restart api` for the first time. The three stores (ApplicationStore/DocumentStore/BriefStore) keep their exact public signatures and static-class shape — no DI, no async ripple into Program.cs's minimal-API handlers — each method just opens a short-lived AppDbContext via Db.Create() under the same lock it already had. Opaque nested shapes (a wizard's draft snapshot, a brief's sections/placeholders/status) are stored as JSON text columns rather than redesigned into relational tables, matching the existing "don't interpret it" posture. Found two things the WP's own text got wrong, corrected in docs/backlog/WP-22-durable-persistence.md's Deviations section: SeedData never seeded these three stores (only the read-only BRP/DUO-mimicking GETs, which stay in-memory) so there's no seed step; and no new docker-compose volume is needed since the existing bind mount already covers the SQLite file — verified against this environment's real podman-backed compose stack, not just by reading the file. Also: pinned SQLitePCLRaw.bundle_e_sqlite3 to 3.0.3 (EF Core Sqlite's own transitive default bundles a pre-3.50.2 SQLite with a known high-severity memory-corruption advisory); found and fixed a real xUnit test race where concurrent test-class hosts stomped a shared static connection-string field, fixed by disabling cross-class test parallelization rather than adding DI the stores don't otherwise need. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-05 10:19:23 +02:00
ehoandClaude Opus 4.8	1137f59f7b	style: format backend with dotnet format ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-03 13:39:31 +02:00
ehoandClaude Opus 4.8	8c3f4c22ee	Mijn aanvragen (A): backend Aanvraag store + lifecycle endpoints ... Adds the backend-owned Aanvraag aggregate (PRD 0001, phase A) — the system of record the dashboard will read. In-memory static store mirroring DocumentStore. - ApplicationStore: create/get/list/draft-sync/cancel/submit; status COMPUTED ON READ (Mappers.ToStatusDto(now)) so auto-approval is pure timestamp arithmetic, no timers/jobs (ProcessingWindow = 8s). - Endpoints: GET /applications, GET/POST/PUT/DELETE /applications/{id}, POST /applications/{id}/submit. - Lifecycle: registratie duo -> auto (Goedgekeurd after window), handmatig -> manual pending (no 422); herregistratie/intake 0 uren -> Afgewezen else auto. Cancel blocks submitted aanvragen (409, no withdrawal in scope). - Old /registrations endpoint + RejectRegistratie 422 left intact (retire in E). - ApplicationTests: lifecycle + auto-approve window boundary (pure). 54/54 green. Also checks in the PRD (docs/prd/0001). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-01 11:35:19 +02:00