docs(backlog): add phase 10 (OpenZaak hardening) and phase 11 (behandelportal)

WP-55..60 harden the OpenZaak integration for production (secrets/TLS,
idempotent provisioning, least-privilege scopes, real notifications,
confidentialiteit config, write-divergence resilience). WP-61..66 stand up
a staff-facing behandelportal per ADR-0002, wired to the same backend via
BFF-lite decision DTOs. Both phases are independent tracks; WP-60's
Decisions block is deliberately left open for a planner-agent kickoff.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/project/backlog/WP-63-aanvraag-status-lifecycle.md

@@ -0,0 +1,69 @@
+# 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.