3 Commits

Include renames

Author	SHA1	Message	Date
ehoandClaude Sonnet 5	edaf1360c5	docs: close WP-69, record verification result ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-18 22:44:36 +02:00
ehoandClaude Sonnet 5	5d73ca21f6	feat(backend): enforce the scholing threshold server-side (WP-69) ... ADR-0001's own canonical "config value" example was unenforced: GET /intake/policy echoed ScholingThreshold, but no request DTO carried a scholing answer, so the server had nothing to re-validate. A crafted POST could skip a requirement the wizard presents as mandatory. IntakePolicy.RejectIncompleteScholing is the authority — three-valued completeness (below threshold an answer is required; "nee" is legal and still submits; punten only belong to a followed scholing), living in the class that owns the constant so scripts/check-seam.sh keeps guarding the FE/BE literal pair. Both submit paths call it; a violation 400s with ProblemDetails and leaves the aanvraag a Concept. Gated on Type == "intake" (the endpoint's switch lumps herregistratie with intake, which has no scholing question), and guarded by `reject is null` so a zero-uren submission is still decided on its merits. Also fixes a live FE bug in the same rule: validateStep required punten whenever scholingGevolgd was 'ja' regardless of lageUren, while the template renders those fields only when lageUren — so answering 'ja' then raising uren either blocked the user on an invisible field or emitted aanvullendeScholing: undefined alongside punten. punten now derives from aanvullendeScholing, so that combination is unrepresentable in ValidIntake. Note: EndpointTests' Worked_hours_submission_succeeds was itself asserting the vulnerable payload ({ uren: 40 }, no answer) and needed a complete answer added; the zero-hours rows are the ordering regression net and are unmodified. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-18 22:42:14 +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