Add registratie wizard, BFF dashboard-view, contracts/value-objects, and architecture docs

Checkpoint of in-progress work: the registration wizard (address prefill,
DUO diploma lookup, policy questions), decision-DTO contracts, parse-don't-
validate value objects, infrastructure adapters, plus CLAUDE.md and the
architecture/ADR docs.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
eho
2026-06-26 17:23:52 +02:00
co-authored by Claude Opus 4.8
parent 8a8a2f0f29
commit 64385999eb
58 changed files with 7271 additions and 556 deletions
@@ -0,0 +1,15 @@
/**
* WIRE CONTRACT for the BRP address lookup ("BFF-lite" — one screen-shaped call).
*
* In production this is GENERATED from the OpenAPI/TypeSpec spec and served by our
* own backend, which talks to the BRP behind an adapter. The frontend never sees
* the BRP's own wire format. See docs/architecture/0001-bff-lite-decision-dtos.md.
*
* "Geen adres bekend" is a first-class outcome (`gevonden: false`), not an error —
* the wizard falls back to manual entry (PRD §7). Slice 1 ships only the happy
* path (gevonden: true).
*/
export interface BrpAddressDto {
gevonden: boolean;
adres?: { straat: string; postcode: string; woonplaats: string };
}
@@ -0,0 +1,36 @@
import { Registration } from '@registratie/domain/registration';
import { Person } from '@registratie/domain/person';
import { BigProfile } from '@registratie/domain/big-profile';
/**
* WIRE CONTRACT for the dashboard screen — the "BFF-lite" response.
*
* In production this type is GENERATED from the OpenAPI/TypeSpec spec (one source
* of truth for both sides), and the `decisions` block is computed BY THE BACKEND
* — never recomputed on the client. The frontend renders decisions; it does not
* own the rules. See docs/architecture/0001-bff-lite-decision-dtos.md.
*
* One screen-shaped call replaces the previous three (BIG-register + BRP + …),
* so the page always sees one consistent snapshot instead of three independently
* loading/erroring resources.
*/
export interface DashboardViewDto {
registration: Registration;
person: Person;
decisions: HerregistratieDecisions;
}
/** Server-computed decisions. The eligibility rule lives on the backend; the
optional reason lets the UI explain itself without knowing the rule. */
export interface HerregistratieDecisions {
eligibleForHerregistratie: boolean;
herregistratieReason?: string;
}
/** The parsed, frontend-side view (DTO mapped onto our own domain model). Keeping
this distinct from DashboardViewDto is the decoupling seam: the wire shape can
change without the FE domain following, and vice-versa. */
export interface DashboardView {
profile: BigProfile;
decisions: HerregistratieDecisions;
}
@@ -0,0 +1,38 @@
/**
* WIRE CONTRACT for the DUO diploma lookup ("BFF-lite" — one screen-shaped call
* returning everything the beroep step needs).
*
* Each diploma carries its server-computed `beroep` (the profession it maps to)
* and the `policyQuestions` (geldigheidsvragen) that apply to it. These are
* DECISIONS computed by the backend from the diploma's attributes — the frontend
* renders them, it does not derive them (decision-DTO pattern, ADR-0001). E.g. an
* English-language diploma carries the Dutch-proficiency question.
*
* `handmatig` is the fallback when the diploma is not in the DUO list: the
* professions the user may declare and the MAXIMAL policy-question set that then
* applies (a manual diploma is unverified, so the strictest set is used).
*/
export interface DuoLookupDto {
diplomas: DuoDiplomaDto[];
handmatig: ManualDiplomaPolicyDto;
}
export interface DuoDiplomaDto {
id: string;
naam: string;
instelling: string;
jaar: number;
beroep: string; // server-derived profession
policyQuestions: PolicyQuestionDto[]; // server-decided geldigheidsvragen
}
export interface ManualDiplomaPolicyDto {
beroepen: string[]; // professions the user may declare for a manual diploma
policyQuestions: PolicyQuestionDto[]; // maximal set applied to a manual diploma
}
export interface PolicyQuestionDto {
id: string;
vraag: string;
type: 'ja-nee' | 'tekst';
}