5 Commits

Include renames

Author	SHA1	Message	Date
ehoandClaude Sonnet 5	3652ff8d3f	docs(test): make Given/When/Then the default BDD structure (WP-71) ... bdd.mdx previously banned "Given/When/Then ceremony" outright, which directly contradicted WP-70's own acceptance tests (Acceptance/ BesluitLifecycleTests.cs already used // Given/When/Then comments) and the backend's organically-evolved PascalCase_snake_sentence convention, which the doc gave zero guidance for. Reverses that rule: every test is now structured Given -> When -> Then, with a genuinely empty phase omitted rather than faked; present-tense declarative naming and the one-behaviour-per-test rule are unchanged. ADR-0006 gets a cross-reference so both documents agree everywhere, not just in acceptance tests. Also closes out the doc's other named-but-unenforced rules found by the audit: fixes the 5 files asserting rendered $localize copy instead of the underlying tag/message-id (the compliant pattern already existed in werkvoorraad-item-view.spec.ts), splits the multi-behaviour titles the doc itself calls a smell (";", "and", "/"), and fixes bdd.mdx's own false citation of registratie-wizard.machine.spec.ts as "one transition per test" by actually splitting that test into one-transition-per-test. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-18 20:25:30 +02:00
ehoandClaude Opus 5	472a49f19f	docs(backend): correct IntakePolicy's false re-validation claim (WP-68 F5) ... The doc-comment claimed "the backend re-validates on submit as the authority" — it doesn't. Neither SubmitApplicationRequest nor IntakeRequest carries a scholing answer at all, so there's nothing to re-validate; both submit paths only apply SubmissionRules.RejectZeroUren. A crafted POST can bypass the scholing requirement entirely. States the gap and points to WP-69 (opened, not yet planned) for the enforcement, which needs a wire change. Also strengthens the F2 concurrency test to assert the persisted status matches whichever request actually won the race, and updates WP-68's own Decisions/ acceptance-criteria text to reflect two implementation choices that improved on the original write-up once real constraints surfaced: ProcessingWindow stays on ApplicationStore (StatusAt is already in the same file), and AanvraagStatusTag is not given a Concept member (would have broken AanvraagStatusTag_covers_the_published_lifecycle) — AanvraagStatus.Tag is nullable instead, null exactly for Concept. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 15:42:21 +02:00
ehoandClaude Opus 5	31d4aa1848	test(backend): cover WP-68 F2/F6/T3 (besluit concurrency, toelichting rule, transitions) ... - Concurrent_besluiten_on_the_same_aanvraag_yield_exactly_one_success: races two besluiten on the same open aanvraag, asserts exactly one 200 and one 409 — the behavior F2's in-lock guard exists to guarantee. - Only_a_non_approval_requires_a_toelichting: unit test for BeoordelingRules.RequiresToelichting (F6). - A_terminal_decision_refuses_any_further_besluit / MeerInfoOpvragen_is_not_terminal_a_further_besluit_is_still_legal: the transition table at the aggregate level (T3) — an Aanvraag whose BesluitStatus already records a decision computes a terminal StatusAt, and CanDecide refuses a further besluit, independent of the endpoint-level equivalent. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 15:38:30 +02:00
ehoandClaude Sonnet 5	af8a011819	feat(behandelportal): WP-65b beoordeling besluit (decision write) ... Adds POST /beoordeling/{id}/besluit: a Besluit enum (Goedkeuren/Afwijzen/ MeerInfoOpvragen) backed by new Aanvraag.BesluitStatus/BesluitToelichting columns, gated by the same BeoordelingRules.CanDecide the read side's canBesluiten flag already uses (409 on an illegal transition, 400 on a missing required toelichting). Mappers.ToStatusDto gains the "a recorded decision wins" branch. FE: besluit.machine.ts + besluit-form organism (same form idiom as change-request-form), wired into the beoordeling page behind the server's canBesluiten flag. Completes WP-65 (65a + 65b) — verified end-to-end against a running backend (werkvoorraad -> beoordeling -> besluit -> status reflected back). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-03 09:46:20 +02:00
ehoandClaude Sonnet 5	4133b30e5d	feat(behandelportal): WP-65a beoordeling detail (read) + fix unreachable medewerker login ... New GET /beoordeling/{id} shows one aanvraag's status, linked documents, and a canBesluiten decision flag, gated by the same CanBeoordelen capability as the werkvoorraad list. Reads through IZaakSource.ListCases rather than a new seam method (WP-66 needs one anyway for the real write); owner BSN is masked. Fixes a real gap found while wiring this up: the behandelportal's login was still WP-61's copied citizen/BSN DigiD flow, so nothing ever sent X-Medewerker and the werkvoorraad screen (WP-64) always denied in a real browser. A dev-only medewerkerInterceptor (mirrors the existing ?role= stand-in as ?rollen=) fixes that. WP-65's own Risks note authorized splitting read from write across sessions given its size; this is the read half. The decision-recording mutation is next (65b). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-03 09:01:09 +02:00