- Executive Summary
- Scope And Ownership
- Execution And Evidence Flow
- Components And Contracts
- Environment And Integration Gates
- Delivery And Operational Boundaries
- References
Executive Summary
CitizenGO extends the existing Live Testing Interface (LTI), rather than building a replacement. LTI owns executable acceptance scenarios, bounded execution, assertions and retained evidence. CitizenGO Ultra owns the reusable CI/CD delivery pipeline and release decision. A green infrastructure check is not proof that a signature, payment or external synchronization succeeded.
This handbook describes repository behavior as of 19 September 2026. It is not a certification of the currently deployed revision, active schedules or provider readiness. Cristian coordinates the E2E rock; application and data owners confirm their respective contracts. Production changes and live payments require separate approval.
Scope And Ownership
| Boundary | Accountable Role | Handoff |
|---|---|---|
| Scenario catalogue, runner and evidence | LTI/E2E owner | Versioned scenario, synthetic fixtures, correlated results |
| Pipeline, secrets, deployment and promotion | CI/CD/platform owner | Candidate SHA, environment identity, gate record |
| Frontend, DonUI, backend and FRAPI behavior | Respective application owner | API/UI contract and reproducible failure |
| MODB, Iterable, Salesforce and reporting | Data/integration owner | Accepted mapping, latency and cleanup contract |
| Production release | Authorized release approver | Reviewed evidence and rollback plan |
Roles are intentionally used instead of assuming that a task assignment grants operational access. Record the named responder and escalation contact in the release or incident task.
Execution And Evidence Flow
flowchart LR
A[Specs and acceptance configuration] --> B[Deterministic scenario matrix]
B --> C[Reviewed scenario and synthetic fixture]
C --> D[Acceptance runner]
D --> E[Browser or read-only API adapter]
E --> F[Acceptance applications and approved sandbox providers]
F --> G[Correlated assertions and redacted evidence]
G --> H[Retained LTI report]
H --> I[Run summary and failure triage]
H --> J[Ultra release gate]
J --> K[Human promotion decision]
Signature and email gates are separate. A confirmed signature can pass while the Iterable email gate remains blocked. Express fallback and manual recovery must remain separate outcomes, not an invented successful express payment. Database and provider assertions must correlate to this run, not a global row count.
Components And Contracts
| Component | Repository Source | Contract |
|---|---|---|
| Matrix generator | test_interface/scenario_matrix.py |
Deterministic catalogue; applying it is an explicit write |
| Execution contract | test_interface/execution_contracts.py |
Version 1, at most 20 steps, 50 KB, 600 seconds total; individual steps at most 60 seconds |
| Orchestration | test_interface/agentic_qa.py |
Ordered steps, terminal result and redacted report ownership |
| Signature and donation preparation | signature_scenarios.py, donation_scenarios.py |
Preview before scheduling; acceptance target and approval gates |
| Scheduled execution | test_interface/cron.py |
Existing scheduler and execution path; do not launch overlapping workers |
| Regression suites | test_interface/sandbox_regression.py |
Acceptance-only smoke and donation-recovery suites |
| Persistence evidence | specs/022-acceptance-payment-persistence-evidence/ |
Pre-submit baseline and correlated post-submit observations |
| Offline summary | test_interface/run_summary.py |
Bounded, redacted Markdown projection; no network or database calls |
The deterministic API adapter permits GET/HEAD, not arbitrary writes. Browser actions such as submission are single-attempt; retrying a payment or signature is not equivalent to retrying a harmless read. Configured safe retries have at most three attempts and ten-second backoff, within the total scenario deadline.
ScheduledTest holds scheduled execution and evidence; Agentic QA stores versioned scenarios and runs; ReportTable retains generated reports. This change adds no database model, external API or scheduled job.
Environment And Integration Gates
Before execution, verify LTI_TARGET_ENVIRONMENT=acceptance, the exact target allowlist, deployed revisions, database targets, synthetic identity and cleanup authorization. A hostname containing "test" is not proof of database isolation. Preserve screenshots or metadata that establish the target without exposing credentials.
Staging CitizenGO/HazteOir and sandbox DonUI are intended acceptance entry points, but effective backend/FRAPI URLs must be checked at run time. Never substitute a production endpoint when acceptance is unavailable.
Provider payments require sandbox credentials and approved test methods. Iterable requires the approved sandbox project, list/message-type mapping and recipient allowlist. MODB and legacy persistence checks require the agreed acceptance database and run correlation. BigQuery availability is not full reporting validation until an acceptance discriminator, event mapping and bounded query are approved.
Delivery And Operational Boundaries
Reuse the Ultra delivery factory, affected-app calculation, protected environments and existing LTI regression dispatch. Do not add a second scheduler or pipeline in this handbook. Preview, acceptance and production are separate promotion stages; deploying a feature branch does not certify main, and merging source does not prove deployment.
The current Ultra frontend manifest explicitly allows the shared soft-backend-fastapi.vercel.app backend for its POC pilot. That owner-approved delivery choice is not evidence of an isolated E2E database. LTI mutation scenarios still need independently verified acceptance targets and data boundaries.
The release record needs candidate SHA, scenario version, target configuration, source report, provider coverage, failures/blocks, approver and rollback reference. The offline summary deliberately cannot authorize promotion. Read-only smoke treats some authorization/not-found responses as reachable; it must never be called an end-to-end business pass.
Roll back a bad reporter by ceasing to use its output and retaining the source JSON. Application/runtime rollback follows the existing environment runbook. Do not delete evidence or replay side effects to manufacture a green result.