ehoandClaude Opus 5
12f17d9d73
Two backlog trees are complete: `docs/project/backlog/` (75 files, every WP done) and `docs/project/refactor-backlog-setup/` (the arc before it). Move both under `docs/project/archive/` with `git mv`, so history stays intact through `git log --follow`. `SHOWCASE-ROADMAP.md` moves with them, because it points at the now-archived backlog README. Add `docs/project/archive/README.md`. It states that these trees are historical and names the two directories that are still live. Repoint every inbound reference named in RD-30's Files table: CLAUDE.md, the root README, both backend READMEs, `LetterHtml.cs`, `a11y.mdx`, the `document-feature` and `new-ssp` skills, and the readable-codebase PLAN, README, and RD-19 ticket. Fix two upward-relative links inside the moved WP files (WP-68, WP-69) that gained a directory level and would otherwise break. Repoint `.prettierignore`'s two agent-prompt exclusions to their new path, so prettier keeps leaving those files' exact wording alone. Mark RD-30 done and check off its acceptance criteria; flip its README row to done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
84 lines
3.9 KiB
Markdown
84 lines
3.9 KiB
Markdown
# WP-66 — Wire the decision into OpenZaak
|
|
|
|
Status: done (d996ca2)
|
|
Phase: 11 — Behandelportal
|
|
|
|
## Why
|
|
|
|
WP-65's decision currently only updates local state (`LocalZaakSource`). For the
|
|
behandelportal to actually function against a real register, the recorded decision needs
|
|
to also write a besluit/status transition to ZGW — extending the write capability that
|
|
already partially exists (`CreateStatusRequest`, `CreateRolRequest` in
|
|
`OpenZaakZaakSource.cs`) rather than building a new ZGW client from scratch.
|
|
|
|
## Read first
|
|
|
|
- `backend/src/BigRegister.Api/Zgw/OpenZaakZaakSource.cs` (existing write records)
|
|
- ZGW's Besluiten API (referenced in `openzaak-integration.md` if covered, or the ZGW
|
|
standard docs) for besluit creation
|
|
- [WP-50](WP-50-openzaak-create-zaak.md) (the first ZGW write slice, for the pattern to
|
|
follow)
|
|
|
|
## Decisions (pre-made, don't relitigate)
|
|
|
|
- Extend `IZaakSource`/`OpenZaakZaakSource` with a besluit/status-transition write,
|
|
following the same pattern WP-50 established for create-zaak (a records + mapper
|
|
addition, not a new abstraction).
|
|
- Gated by `Zgw:Enabled` like every other ZGW write — the behandelportal keeps working
|
|
against `LocalZaakSource` when it's off.
|
|
- Best done after Phase 10's WP-60 (write-divergence resilience) lands, since this is
|
|
exactly the second write pair that resilience work should already cover — but not
|
|
strictly blocked on it if Phase 10 is still in progress (call out the residual risk
|
|
explicitly if shipped first).
|
|
|
|
## Files
|
|
|
|
`Zgw/OpenZaakZaakSource.cs` (besluit/status write), `Data/IZaakSource.cs` (new write
|
|
method), tests.
|
|
|
|
## Steps
|
|
|
|
1. Add the besluit/status-transition write to `OpenZaakZaakSource`, mirroring WP-50's
|
|
create-zaak pattern.
|
|
2. Wire WP-65's decision command to call it when `Zgw:Enabled=true`.
|
|
3. Integration test against the WP-54 harness (extend `OpenZaakIntegrationTests`).
|
|
|
|
## Acceptance criteria
|
|
|
|
- [x] A recorded decision writes a real besluit/status transition to OpenZaak when
|
|
`Zgw:Enabled=true`. Implemented as a Statussen (not Besluiten/BRC) write — see
|
|
`openzaak-integration.md`'s "Besluit write (WP-66)" section for why: the harness's
|
|
catalogus only provisions a begin/eind statustype pair, no besluittypen.
|
|
- [x] Behandelportal still works unchanged against `LocalZaakSource` when
|
|
`Zgw:Enabled=false` (`LocalZaakSource.RecordBesluit` is a no-op).
|
|
- [x] Unit-tested against a stub `HttpMessageHandler` (`OpenZaakZaakSourceTests`) — the same
|
|
pattern WP-50's `CreateZaak` tests use. Not added to the live-harness
|
|
`OpenZaakIntegrationTests` in this pass (residual risk below).
|
|
|
|
## Verification
|
|
|
|
`cd backend && dotnet test --filter Category=Integration` against the (ideally
|
|
Phase-10-hardened) OpenZaak harness; manual smoke with `Zgw:Enabled=true`.
|
|
|
|
## Out of scope
|
|
|
|
Any further behandelportal screens beyond beoordeling.
|
|
|
|
## Risks
|
|
|
|
WP-60 (write-divergence resilience) has landed: bounded retry lives in `ZgwHttpClient`, so
|
|
this write pair inherits it automatically. The flagging half is now also wired: the besluit
|
|
endpoint calls `RecordZgwDivergence` on `RecordBesluit`'s catch, the same way `Program.cs`'s
|
|
submit endpoint does for create-zaak/document writes — so this is no longer the "second,
|
|
currently-unprotected write pair" WP-60's own scope note anticipated.
|
|
|
|
**Residual risk (shipped in this pass):** no live-harness integration test (`OpenZaakIntegrationTests`,
|
|
WP-54) was added for this write — only the stub-`HttpMessageHandler` unit tests. The
|
|
create-zaak slice (WP-50) shipped the same way and WP-54's harness later caught a real bug
|
|
(the `Content-Crs` header) that the stub tests didn't model; the same class of gap could exist
|
|
here (e.g. a real OpenZaak rejecting a second `statussen` POST on an already-`Afgehandeld` zaak
|
|
in a way the stub never exercises). Extend `OpenZaakIntegrationTests` with a besluit round-trip
|
|
against the docker harness before relying on this in a real deployment.
|
|
|
|
Depends on: WP-65.
|