WS-6 v1.3-delta — Closure docs-PR #12

Merged
bert.hausmans merged 4 commits from docs/ws-6-v1.3-delta-closure into main 2026-05-08 10:30:20 +02:00

4 Commits

Author SHA1 Message Date
c5682f181f docs(backlog): close no-compromises gaps from WS-6 v1.3-delta review
Three edits closing concessies surfaced in chat review of the closure
docs-PR:

1. FORM-05 'Resterend werk' sub-paragraph: surgical replacement of
   resolveStatus references (method removed in D2, PR #11 23a5696).
   Updated to describe post-D2 reality: gate + invariant +
   handle()-internal status derivation. Ticket stays open (the
   detectMatchesByValues extension is unbuilt).

2. FRONTEND-ECHO-IDENTITY-MATCH-SUBSCRIPTION (NEW): tracks the frontend
   follow-up where the portal IdentityMatchBanner subscribes to the
   submission.{id} channel for live banner updates. Previously
   documented in PR #11 body and RFC §Q1 v1.3 add 2 commentary but
   without an actionable BACKLOG ticket.

3. HARD-DEADLINE-QUERY-TIMEOUT (NEW): tracks the upgrade from soft
   post-call microtime deadline to a hard deadline that can interrupt
   hanging MySQL queries (connection-level timeouts, MAX_EXECUTION_TIME
   hints, or pcntl_alarm). Previously documented as 'soft deadline
   limitation' inline in code comments without an actionable BACKLOG
   ticket.

No spec changes; no code changes. Closes the chat-identified gaps so
WS-6 v1.3-delta closure has zero un-anchored mental TODOs.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-08 10:11:50 +02:00
ce552ec7be docs(backlog): WS-6 v1.3-delta closure entry + FORM-05 stub-status touch-up
Append WS-6-V1.3-DELTA closure bullet under "Opgeloste items (mei 2026)"
summarising D1 (PR #10 c6f4d1b) + D2 (PR #11 23a5696) deliverables and
open follow-ups.

Surgical correction to FORM-05 Stub-status paragraph: pre-D2 description
claimed TriggerPersonIdentityMatchOnFormSubmit writes initial 'pending';
post-D2 that's ApplyBindingsOnFormSubmit's job per RFC §Q1 v1.3 add 1.
The underlying ticket (detectMatchesByValues extension) stays open.

No other BACKLOG entries resolved — D1+D2 implemented RFC §Q3 v1.3
changes that pre-existing tickets didn't anticipate.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-08 08:59:40 +02:00
5ac6b4168d docs(rfc-ws-6): mark v1.3.1 as fully implemented
§1 Status: add Implementation status line citing D1 (PR #10 c6f4d1b)
and D2 (PR #11 23a5696), both 2026-05-08.

§10 Document history: append v1.3-delta closure entry summarising what
D1 and D2 each delivered + what remains as separate operational task
(GlitchTip alert rule configuration in the web UI) and frontend
follow-up (Echo subscription).

No spec changes — purely lifecycle marker update.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-08 08:57:50 +02:00
7ba01a6dfa docs(runbooks): add form-builder binding failures section
Per RFC-WS-6 §Q3 v1.3 + ARCH-BINDINGS §11.

Nieuwe runbook-sectie §7 (na §6 Audit trail) die de triage-flow
documenteert wanneer GlitchTip een FormBindingApplicatorException
event opbrengt:

- §7.1 failure_response_code classificatie (schema_config_error /
  temporary_error / data_integrity_error / unknown_error) drijft het
  initiële triage-pad
- §7.2 form_schema.has_public_token tag onderscheidt klant-zichtbare
  failures (alert-waardig) van organizer-driven failures (admin-UI only)
- §7.3 retry/dismiss decision-matrix met form-failures:retry artisan
  command + DismissalReasonType enum cases
- §7.4 severe-failure escalatie criteria (>10/uur op één schema = P1)
- §7.5 cross-references naar RFC, ARCH-BINDINGS, en erasure-runbook

Companion van de operationele GlitchTip alert-rule (apart geconfigureerd
in de GlitchTip web UI op monitoring.hausdesign.nl).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-08 08:57:02 +02:00