Files
atomic-design-poc/docs/project/backlog/WP-72-delete-legacy-submit-endpoints.md
ehoandClaude Sonnet 5 ae7781efef
CI / changes (push) Successful in 8s
CI / lint (push) Successful in 1m9s
CI / frontend (push) Successful in 2m27s
CI / backend (push) Successful in 1m56s
CI / e2e (push) Successful in 3m16s
CI / semgrep (push) Successful in 1m7s
CI / api-client-drift (push) Successful in 1m50s
CI / storybook-a11y (push) Successful in 11m4s
docs: close WP-72..75, regenerate behaviour spec
Four close-outs and their README rows. The behaviour spec is regenerated
once here rather than per-track — it derives from every test name in the
repo, so any track running it would have conflicted with the other three.

Records two findings the arc surfaced but did not cause: the /brief/preview
staleness for non-DemoOwner identities (blocking per-spec identity isolation
in brief-v2.spec.ts), and that WP-72/73 had to share a commit because both
edit Program.cs — separate execution waves prevented build collisions but
did not produce separable diffs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-19 16:34:54 +02:00

2.6 KiB
Raw Permalink Blame History

WP-72 — Delete the dead legacy submit endpoints

Status: done (6bc00a9) Phase: 12 — DDD hardening

Why

POST /api/v1/intakes and POST /api/v1/herregistraties were dead from the UI — the wizard submits through POST /applications/{id}/submit, and nothing in apps/ or libs/ called the generated intakes()/herregistraties() client methods. They were also strictly less capable than the endpoint that replaced them: they minted a bare reference and wrote no Aanvraag, made no ZGW/OpenZaak call, and performed no document-ownership check.

WP-69 hardened /intakes with a 400 last session. Deleting the surface is the stronger fix; WP-69's /applications/{id}/submit enforcement — the path the wizard actually uses — is untouched.

Decisions (pre-made)

  1. Delete both routes together. Their two EndpointTests are [Theory]s parameterised across both routes, so deleting one would leave an InlineData row 404-ing.
  2. Keep the shared Submit(...) helper, ReferentieResponse, SubmissionRules.NewReference and the whole IdempotencyStore path — /registrations and /change-requests still use them, and IdempotencyTests covers the latter.
  3. This WP owns the wire artifacts; no other track runs gen:api.

Acceptance criteria

  • Both routes return 404 against a live backend (verified by curl, not by inference).
  • Zero references remain in libs/shared/src/infrastructure/api-client.ts.
  • gen:api diff is pure deletion — 124 lines out of swagger.json, 109 out of the API client, zero additions.
  • Backend tests 245 → 240, exactly the 5 deleted cases (2 [Theory]s × 2 rows + 1 [Fact]).
  • Submit(...) and the idempotency path survive with their live callers intact.

Verification

cd backend && dotnet test BigRegister.slnx --filter "Category!=Integration"
npm run ci
curl -X POST http://localhost:5000/api/v1/intakes -d '{"uren":500}'   # 404

Notes

Committed together with WP-73 (6bc00a9): both edit Program.cs, and splitting them would have produced a commit that does not build. The two were run in separate execution waves to avoid a concurrent dotnet build collision — but since neither committed independently, the file-level entanglement remained at integration time. Worth remembering when planning future parallel backend tracks: separate waves do not produce separate commits.

Follow-ups

  • docs/reference/fp-tea-atomic-design.md:587 / ARCHITECTURE.md:464 still teach a visibleSteps-with-a-'scholing'-step intake the fixed-3-step wizard no longer matches (inherited from WP-69).