WS-6 v1.3-delta — Closure docs-PR #12
Reference in New Issue
Block a user
Delete Branch "docs/ws-6-v1.3-delta-closure"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
WS-6 v1.3-delta — Closure docs-PR
Closes the docs side of WS-6 v1.3-delta. With this merged, all WS-6 v1.3 work is documented as complete, all chat-identified no-compromises gaps are closed (either by direct fix or actionable BACKLOG anchoring), and the only remaining task is the GlitchTip alert rule configuration in the web UI (operational, separate from code lifecycle).
This is a docs-only PR. No code changes, no migrations, no test changes.
Refs
dev-docs/RFC-WS-6.mdv1.3.1 — implemented as of 2026-05-08 (D1: PR #10c6f4d1b, D2: PR #1123a5696)dev-docs/ARCH-BINDINGS.mdv1.2 — context only, no editsWhat this PR delivers
1. Runbook addition:
dev-docs/runbooks/observability-triage.md§7 Form-builder binding failures (commit7ba01a6)New top-level section, placed after §6 Audit trail to preserve existing cross-references. Five subsections:
failure_response_codetriage matrix (4 tokens × triage path)form_schema.has_public_tokentag distinguishing customer-facing vs organizer-driven failuresphp artisan form-failures:retryexamples +DismissalReasonTypeenum casesCompanion to the operational GlitchTip alert rule (configured separately in the GlitchTip web UI on
monitoring.hausdesign.nl).2. RFC-WS-6 v1.3.1 — fully implemented marker (commit
5ac6b41)c6f4d1b, D2: PR #1123a5696)" lineNo spec changes — purely lifecycle marker update.
3. BACKLOG.md updates — initial closure pass (commit
ce552ec)WS-6 v1.3-delta — closure (mei 2026)bullet under## Opgeloste items (mei 2026), following the existing single-bullet/strikethrough/✅ conventionTriggerPersonIdentityMatchOnFormSubmitwrites the initial'pending'; post-D2 that'sApplyBindingsOnFormSubmit::handle's job per RFC §Q1 v1.3 add 1. The underlying ticket (detectMatchesByValuesextension) stays open.No pre-existing BACKLOG entries resolved. D1 + D2 implemented RFC §Q3 v1.3 changes that pre-existing tickets didn't anticipate.
4. BACKLOG.md updates — no-compromises gap closure (commit
c5682f1)Chat review of commit 3 surfaced three concessies that were too softly handled. This commit closes them:
FORM-05 'Resterend werk' sub-paragraph: surgical replacement of TWO obsolete references (not just one): the
TriggerPersonIdentityMatchOnFormSubmit::resolveStatusmethod (D2 inlined the status derivation intohandle()) AND the "altijd 'pending'" framing (failsafe-pad behaviour from v1.0/v1.2; failsafe-pad is gone post-D2). Updated to describe the actual post-D2 gap: self-registered public submitters whose exact-email matcher comes back empty get'none'becausePersonIdentityServiceskips fuzzy-name fallback forregistration_source='self'. Includes concrete PHP fenced blocks showing the newdetectMatchesByValues()method onPersonIdentityServiceand the new match-arm inhandle()'s status-derivation. Cross-reference at the close toFRONTEND-ECHO-IDENTITY-MATCH-SUBSCRIPTION. Ticket stays open (description correction, not resolution).FRONTEND-ECHO-IDENTITY-MATCH-SUBSCRIPTION(NEW): tracks the frontend follow-up where the portal IdentityMatchBanner subscribes to thesubmission.{id}private channel via Laravel Echo for live banner updates. Previously documented in PR #11 body and RFC §Q1 v1.3 add 2 commentary but without an actionable BACKLOG ticket. Trigger condition: bring forward when (a) TanStack refetch-on-focus UX produces customer complaints, OR (b) the next form-builder frontend sprint lands so all Echo-wiring lands together. Estimate: 0.5–1 day.HARD-DEADLINE-QUERY-TIMEOUT(NEW): tracks the upgrade from soft post-call microtime deadline to a hard deadline that can interrupt hanging MySQL queries. The currentFormBindingApplicator::withDeadline()works for "applicator runs slow over many bindings" (the long tail) but cannot interrupt during a hanging query or lock-for-update wait. Three potential implementation paths sketched: MySQL connection-level timeouts, per-queryMAX_EXECUTION_TIMEhints (MySQL 5.7+ only), orpcntl_alarm+ signal handler in queue-worker context. Trigger condition: first production incident where soft deadline proves insufficient, OR enterprise SLO requirements demanding stricter response-time guarantees. Estimate: 2–3 days.BACKLOG entries that stay open (intentional follow-up)
TECH-CHANNEL-AUTH-ORG-ADMINsubmission.{id}channel auth to organisation admins after Spatie Permission helper-pattern auditFRONTEND-ECHO-IDENTITY-MATCH-SUBSCRIPTION(new)HARD-DEADLINE-QUERY-TIMEOUT(new)PARTIAL-BINDING-SUCCESSFORM-SCHEMA-DRIFT-DETECTIONFORM-05detectMatchesByValuesextension for public submissions — Stub-status AND Resterend werk paragraphs corrected in this PR; underlying work still openFORM-BINDING-SNAPSHOT-MULTIFORM-BUILDER-LIBRARY-AUDIT-LOGOperational follow-up (NOT in this PR)
apply_status=failed AND form_schema.has_public_token=true— configured manually in the GlitchTip web UI onmonitoring.hausdesign.nl. The runbook procedure that the alert will trigger is documented in §7 of this PR.Audit findings (Phase A — initial pass)
## §7after§6 Audit trail(rather than mid-document) to avoid renumbering existing sections and preserve internal cross-refs.## Opgeloste items (mei 2026)convention followed: single-bullet, strikethrough, ✅ format.resolveStatusas obsolete; second audit (commit 4) caught the additional "altijd pending" framing as also obsolete. Both corrected in commit 4.Audit findings (Phase A — review pass)
Chat review caught two BACKLOG gaps in commit 3 that were too softly handled:
FRONTEND-ECHO-IDENTITY-MATCH-SUBSCRIPTION.FormBindingApplicator::withDeadline()was documented as a code comment but had no actionable BACKLOG ticket — closed in commit 4 asHARD-DEADLINE-QUERY-TIMEOUT.Both new entries follow the established BACKLOG convention: explicit trigger conditions (not "ooit eens een keer"), three potential implementation paths sketched where applicable, estimates included.
Commits
7ba01a6— docs(runbooks): add form-builder binding failures section5ac6b41— docs(rfc-ws-6): mark v1.3.1 as fully implementedce552ec— docs(backlog): WS-6 v1.3-delta closure entry + FORM-05 stub-status touch-upc5682f1— docs(backlog): close no-compromises gaps from WS-6 v1.3-delta reviewReview hints
resolveStatusreference remains in BACKLOG but it's deliberate — the new FORM-05 text mentions it explanatorily ("D2 inlinete de status-derivation in handle() zelf — er is geen aparte resolveStatus methode meer") to anchor future readers in the post-D2 reality. Not a stale reference.FRONTEND-ECHO-IDENTITY-MATCH-SUBSCRIPTION,HARD-DEADLINE-QUERY-TIMEOUT, plus pre-existingTECH-CHANNEL-AUTH-ORG-ADMIN) carry the small remaining surface area.🤖 Co-Authored-By: Claude Opus 4.7