Q3 E2E Scenario Inventory

Purpose

This inventory defines the bounded acceptance scenarios that LTI may execute. It separates the currently observed catalog from the scenario coverage that still needs implementation. Runtime discovery remains authoritative because lists, petitions, and donation forms change more frequently than LTI releases.

Current Acceptance Catalog

The seeded acceptance baseline contains:

30 segment definitions copied as non-personal reference data;
450 acceptance petitions, with 15 fixtures per segment;
90 donation forms, with 3 fixtures per segment;
CitizenGO and HazteOir staging frontends backed by acceptance services;
CitizenGO and HazteOir sandbox donation frontends;
Stripe test mode and GoCardless sandbox as independently gated providers.

The inventory job must read active acceptance segments and forms from the acceptance API. It must not copy supporter records or use production as a runtime fallback. A missing segment or form is a visible inventory failure.

Locale Baseline

The legacy LTI express suite currently contains these locale and currency pairs. They are a compatibility baseline, not proof that a current acceptance form exists:

Locale	Currency	Stripe compatibility	GoCardless compatibility
`de-de`	EUR	yes	yes
`de-at`	EUR	yes	yes
`de-ch`	CHF	yes	no
`en-af`	USD	yes	no
`en-au`	AUD	yes	no
`en-ca`	CAD	yes	no
`en-ie`	EUR	yes	yes
`en-row`	EUR	yes	no
`en-gb`	GBP	yes	yes
`en-us`	USD	separate organization identity required	no
`es-ar`	USD	yes	no
`es-mx`	USD	yes	no
`es-us`	USD	separate organization identity required	no
`fr-fr`	EUR	yes	yes
`fr-ca`	CAD	yes	no
`hr`	EUR	yes	no
`it-it`	EUR	yes	yes
`hu`	EUR	yes	no
`nl-nl`	EUR	yes	yes
`nl-be`	EUR	yes	yes
`pl`	PLN	yes	no
`pt-br`	BRL	yes	no
`pt-pt`	EUR	yes	yes
`sk`	EUR	yes	yes

Runtime discovery must report newly active list codes and locales instead of silently excluding them. Provider tests remain disabled for a locale unless the provider, organization identity, currency, and cleanup contract all match.

Scenario Matrix

Journey	Required surfaces	Minimum assertion	Mutable
CitizenGO signature	CitizenGO staging, backend acceptance, MODB development	Success/share state and one correlated acceptance signature event	yes
HazteOir signature	HazteOir staging, backend acceptance, MODB development	HazteOir host continuity and one correlated acceptance signature event	yes
One-time donation	sandbox DonUI, FRAPI acceptance, provider sandbox	Amount, currency, `OTD`, provider, and terminal FRAPI state agree	yes
Monthly donation	sandbox DonUI, FRAPI acceptance, provider sandbox	Amount, currency, `MD`, provider, and subscription state agree	yes
Express donation	sandbox DonUI, FRAPI acceptance, telemetry evidence	Express request and provider result correlate without retaining a raw DR token	yes
Express fallback	sandbox DonUI, FRAPI acceptance, telemetry evidence	One trace links express failure or fallback to the manual donation outcome	yes
Manual recovery	sandbox DonUI, FRAPI acceptance	Recovery is reported separately from first-attempt success	yes
Unsubscribe	backend acceptance, Iterable restricted project, MODB development	One synthetic profile reaches the expected subscription state	yes
PPAE ingestion	owner-approved PPAE fixture and WebApp acceptance	One run-owned campaign follows the confirmed workflow states	pending owner contract
External synchronization	owner-approved sandbox integration	Correlated side effect, idempotency, and exact cleanup are proven	pending owner contract

Bot rejection and successful recovery are diagnostic outcomes. Neither is counted as a first-attempt donation success or failure.

Selection Policy

The first implementation slice selects:

one active CitizenGO list and one active HazteOir list;
one seeded petition for each selected list;
one OTD and one MD form for the selected locale;
one Stripe-compatible locale;
one GoCardless-compatible locale only after its sandbox gate passes.

Selection is deterministic for a given catalog version and records the selected list code, locale, form identifier, scenario version, and source revision. Credentials, raw DR tokens, and personal data are never inventory fields.

Drift and Readiness

Before a scheduled suite starts, LTI must compare the runtime catalog with the last accepted inventory:

added items are reported as uncovered until a scenario policy includes them;
removed or inactive fixtures fail only scenarios that selected them;
a locale or provider mismatch blocks that scenario without falling back to production;
zero active petitions or donation forms is a hard catalog failure;
the prior accepted inventory remains available for diagnosis but does not authorize execution against stale identifiers.

Implementation Boundary

The generated Q3 acceptance adapter smoke suite now provides deterministic, read-only coverage for the configured CitizenGO and HazteOir staging frontends, CitizenGO sandbox DonUI, and FRAPI acceptance health route. Matrix generation also inventories current LTI list-language and donation-form configuration and marks unsafe or production form URLs as blocked.

This is not the full runtime catalog required by LTI-FR-037..038: active petition discovery, acceptance API form discovery, provider compatibility, and freshness/drift comparison remain pending. The current legacy express test still constructs production DonUI URLs and remains outside the acceptance suite until the mutable donation and cleanup contracts are approved.