docs(rfc-ws-6): v1.3 amendment — listener queueing, invariant cleanup, failure-UX

Five refinements from the 2026-05-07 architectural review:

- Q1: TriggerPersonIdentityMatchOnFormSubmit moves to queued; sync-chain reduced to ApplyBindings only; queued-listener gating invariant; sync-chain deadline wrapper.

- Q2: Failsafe pad in TriggerPersonIdentityMatch removed in favour of strict invariant + throw; RequiresIdentityKeyBinding unconditional for event_registration; FormSubmissionResource.identity_match=null contract for non-person purposes.

- Q3: Three failure-UX additions (GlitchTip alert, custom exception hierarchy + error_code, BACKLOG entries for partial-success and schema-drift).

Spine unchanged: pre-publish guards, strict service / log-and-swallow listener, two-transaction pattern, single identity-key per target_entity.

Refs: dev-docs/RFC-WS-6.md (now v1.3), dev-docs/ARCH-BINDINGS.md (now v1.1), dev-docs/BACKLOG.md (PARTIAL-BINDING-SUCCESS, FORM-SCHEMA-DRIFT-DETECTION added)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

dev-docs/BACKLOG.md

@@ -360,6 +360,36 @@ class extractie (2026-04-25)".
 
 ---
 
+### FORM-SCHEMA-DRIFT-DETECTION — Detecteer stale bindings na schema-migrations
+
+**Aanleiding:** RFC-WS-6 v1.3 §Q3 addition 4 — schema-drift werd in v1.2 als
+zijdelingse opmerking afgedaan ("DB modified out from under us"), v1.3 maakt het
+expliciet als follow-up.
+
+**Wat:** Migration-listener die, wanneer een binding-target column wordt
+renamed/dropped/type-changed, alle `form_field_bindings.target_attribute` scant op
+matches. Affected `form_schemas` krijgen `needs_revalidation=true`. Schema-detail UI
+toont banner; affected schemas accepteren geen nieuwe submissions tot organiser
+re-publisht.
+
+**Vereiste:**
+- Migration-listener (Laravel `events` integration of een custom `MigrationObserver`)
+- Nieuwe boolean kolom op `form_schemas`: `needs_revalidation` + index
+- Re-publish flow op schema-detail UI
+- Tests die simuleren: column rename → schemas met binding op die column gemarkeerd
+  → re-publish reset
+
+**Trigger-conditie:** Eerste productie-incident waar een runtime-throw te herleiden
+is naar een stale binding na een migration. Of: pre-emptive trigger als enterprise
+customer een grootschalige column-renaming uitvoert.
+
+**Estimate:** 2-3 dagen.
+
+**Refs:** ARCH-BINDINGS.md §6.5 (binding-change safety, related but distinct),
+RFC-WS-6.md §Q3 v1.3.
+
+---
+
 ### FORM-04 — `grace_days` configurable on public_token rotation
 
 **Aanleiding:** S2c §10.4 opgeleverd met een hardgecodeerd 7-daagse grace window in `PublicFormTokenResolver`. `rotatePublicToken` endpoint accepteert wel een `grace_days` request param maar schrijft die nergens naartoe; `form_schemas` heeft geen `grace_days` kolom.
@@ -446,6 +476,33 @@ Prioriteit: Medium. Kan gebundeld worden met de organizer
 
 ---
 
+### PARTIAL-BINDING-SUCCESS — Granular per-binding success-state in FormBindingApplicator
+
+**Aanleiding:** ARCH-BINDINGS v1.0 §19 noemde dit als "future RFC topic" — RFC-WS-6
+v1.3 verplaatst het naar expliciete BACKLOG met trigger-conditie.
+
+**Wat:** Granular per-binding success/failure tracking voor `FormBindingApplicator`.
+Huidige v1.0: één binding throw → hele apply rolt terug → submission `apply_status=failed`.
+Toekomstig: per-binding success-state, failed bindings expliciet zichtbaar in admin UI,
+gebruiker krijgt "submission gedeeltelijk verwerkt — 11 van 12 velden zijn opgeslagen,
+één veld vereist organiser-aandacht."
+
+**Vereiste designkeuzes:**
+- SAGA pattern met per-binding compensation, OF
+- Per-binding transactie met idempotency-keys per binding-application
+- Trust-precedence resolution moet opnieuw doordacht (huidige model assumeert atomic
+  pass)
+
+**Trigger-conditie:** Eerste enterprise customer rapporteert all-or-nothing als UX
+issue. Concreet signaal: support-ticket of customer-call met "gebruiker vulde 12
+velden, één crashte, alles ging verloren."
+
+**Estimate:** 4-6 dagen.
+
+**Refs:** ARCH-BINDINGS.md §19, RFC-WS-6.md §Q3 v1.3.
+
+---
+
 ### SUP-01 — Leveranciersportal + productieverzoeken
 
 **Aanleiding:** Leveranciers moeten productie-informatie kunnen indienen.