Coverage, sources and version boundaries

Meaning of the status

Screen: the named interface was visited and captured with Playwright, not necessarily every scenario. Code: behaviour was checked in source or operating instructions, not trialled in production. Partial: an implementation slice or surface exists, but the complete journey needs verification. Spec: behaviour comes from the specification, without a complete interface test. Future: explicitly future or requiring definition.

Known boundaries of this version

• Open-call decision release and the individual-submission action are still in open PRs and are not presented as available screens.
• Programme (04). The CFP-to-Programme handover is merged (#2172, #2286, #2290, #1356) and described from source; it was not exercised in the browser for this handbook. Merged code is not full Programme acceptance: screen-reader, native-language, load, live-room and real-provider acceptance remain open (#43, #488).
• Programme screenshots are examples, not journey evidence. All captures were retaken at the pinned revision, after the interface overhaul (#2425), in an isolated demo edition. Its sessions were created by hand with one fictional speaker and no attendees; a first publication was confirmed through the admin API before capture. The screens therefore do not show the CFP handover, attendee favourites or demand, a safety-checked or downloadable file (the demo stack did not run the safety check) or a confirmed review in the workbench. Demand has no screenshot, because without attendees it would show no interest.
• Programme boundaries still open: operator replay of pending handovers (#2319); remaining resource-link acceptance, including the speaker screen and attendee display (#2023); fresh time slot verification at confirmation (#757); affected-person information for day-announcement notices (#759); participant changes on a repeated session after one time slot completed (#760); concurrent adds of the same person to overlapping sessions (#1111; fix in open PR #2518); durable propagation of definitive entitlement loss (#1348); live-room integration (PRG-008–011); programme change notifications (C-19); user and workload acceptance (#488).
• Integrations (28). The MCP endpoint, two anonymous read-only tools, protected-resource metadata, assistant connections, agent registration and the MCP audit are merged as API and backend capabilities (#1979, #2031, #2013, #2086, #2140). There is no screen for connections. Token-to-connection resolution (#1968), approvals and step-up (#1975), CFP submission over MCP (#2335, PR #2343, #2341; target 1 December 2026) and real client and identity-provider acceptance (#1821) are not available.
• Privacy (27). Person erasure coordination and several participating domains are merged but switched off by default; the production erasure flow is open (#1821). Retention in calendar months is an available setting without a consumer; its first specification is still open (omnia-spec #365). Rejected action-link completions write no receipt yet (#2577).
• Commerce (06–08). Buyer-shape rules and the claim-link replacement are API only; there is no admin screen. The workshop-places check (#2580) is internal and refuses nothing yet.
• Sponsors and leads (15–16). Package benefit types (includedTeamTickets, booth, leadScanning, sponsoredTalkSlot) are merged as API only (#2594); the Sponsors page has no screen for packages. Lead scanning exists only as a read of whether the package grants it (LEAD-001). There is no scanning app, no lead capture and no disclosure yet, so module 16 stays at Spec. The grant does not yet wait for a contracted purchase (#1802, #1562).
• Ticketing (06). Each ticket type has a registration terms version, API only (termsVersion, #2596). Nothing records it on a lead disclosure yet (LEAD-003, PRIV-006).
• Screenshots do not provide production verification of OIDC, payment providers, printers, scanners or retention behaviour.
• Chapters marked Spec or Future do not describe invisible buttons; they state what still needs verification.

Update the documentation

Edit the Markdown page and its Dutch or English counterpart. Check the relevant specification and code. Recapture changed screens in your own demo edition and update the screenshot manifest. Build the container and run link, search, language and mobile checks. Then update source revisions and the review date.

The review journey consists of setup, assessment and use for selection. Screenshots show group configuration and own-submission protection; the normal scoring form and full review chain have not yet been exercised in the browser during this documentation round. Those instructions are based on the pinned source code. Full N-of-M review coverage in the specification is not yet available in this reference version.