# WP-63 — Backend: aanvraag status lifecycle as a published DTO

Status: todo
Phase: 11 — Behandelportal

## Why

The FE currently infers "in behandeling" from a single boolean, `pendingHerregistratie`
(`big-profile.store.ts:53`) — explicitly called out in ADR-0002 as "a temporary stand-in
for a real, backend-owned status." The full lifecycle (`Ingediend → In behandeling →
(Meer info gevraagd ⇄) → Goedgekeurd/Afgewezen`) needs to become a real backend-published
value before either frontend can render it meaningfully — the SSP needs it as a richer
read (this WP), the behandelportal needs it as the thing it advances (WP-65).

## Read first

- [ADR-0002](../reference/architecture/0002-user-groups-and-bounded-contexts.md) (status
  lifecycle diagram)
- `src/app/registratie/application/big-profile.store.ts` (the current boolean)
- [ADR-0001 — BFF-lite decision DTOs](../reference/architecture/0001-bff-lite-decision-dtos.md)

## Decisions (pre-made, don't relitigate)

- Status lives on the existing `Aanvraag`/`ApplicationSummaryDto` aggregate (extend,
  don't invent a parallel status resource).
- The DTO change is additive: the SSP's `pendingHerregistratie` boolean can be derived
  from the new status field (or kept as a computed convenience) so this ships with zero
  required FE behavior change — a pure backend + contract widening.
- Only the status _value_ is published here; any transition (advancing it) is a separate
  write endpoint, not part of this slice (that's WP-65's mutation).

## Files

- `Data/ApplicationStore.cs` (status field/enum)
- `Contracts/Dtos.cs` (extend `ApplicationSummaryDto`/status DTO)
- The FE `infrastructure/*.adapter.ts` + `parse*` boundary consuming it
- `big-profile.store.ts` (derive the existing boolean from the new field)

## Steps

1. Model the full status enum backend-side (`Ingediend`, `InBehandeling`,
   `MeerInfoGevraagd`, `Goedgekeurd`, `Afgewezen`) on `Aanvraag`.
2. Publish it on the existing DTO the SSP already consumes.
3. Regenerate the typed client (`npm run gen:api`); update the FE `parse*` boundary to
   read the new field.
4. Point `pendingHerregistratie` (or its replacement) at the new field so the SSP's
   existing behavior is unchanged, just backed by a real value.

## Acceptance criteria

- [ ] Backend publishes the full status lifecycle value on the existing aanvraag DTO.
- [ ] `npm run gen:api` leaves no drift; SSP's existing "pending" display is unchanged in
      behavior, now backed by the real status.
- [ ] `dotnet test` + `npm run ci` green.

## Verification

`cd backend && dotnet test`; `npm run gen:api` (no drift); `npm run ci`; manual: SSP
dashboard still shows the same pending/approved states it does today.

## Out of scope

Any endpoint that _advances_ the status (WP-65); the behandelportal consuming it (WP-64).

## Risks

If the enum doesn't anticipate a state WP-65 needs (e.g. distinguishing who can transition
from what), it gets revised there — acceptable, this slice only needs to cover the states
already named in ADR-0002's diagram.