Skip to content

PayPal sandbox only. No real money moves.

OperatorsRun it yourself

CI and deployment map

Every workflow that checks, proves, deploys or watches GAVEL, when it runs, what it needs by name and what it leaves behind.

Verifiedbacked by a real run or committed evidence

Page last changed 7 Nov 2026 (from the git history)

All heavy work runs in GitHub Actions: builds, test suites, browsers, screenshots, gate runs and deploys. Nothing in this project asks you to run them on a laptop.

CI and deployment map: which workflow runs when

Sandbox workflows marked
CI and deployment map: which workflow runs whenFive lanes by trigger. Every pull request: ci and docsite. Pull requests that change certain paths: sim-multiday, ui-screens, the sandbox skip check and the early G3 read. Scheduled: nightly-sandbox at 20:30 UTC, judge-smoke at 21:45 UTC, gate-g3 every six hours, uptime every five minutes, backup daily, audit weekly and mutation weekly. Started by hand: the G3 probe start, gate-g3-early and the live screen tour. Deploy: deploy-staging on server changes on main, deploy-prod on a version tag, and the docs site deploy job.Hatched top edge: calls the PayPal sandbox with repository secrets. Dashed border: simulated clock, no network.EVERY PULL REQUESTand every push to mainPULL REQUEST, ONLYwhen these paths changeON A SCHEDULEcron, UTCSTARTED BY HANDworkflow_dispatchDEPLOYhost and docs sitecipull_request, push to maintypecheck, lint, unit, property, voice ... then requireddocsitePR and main, paths: docsite, GATES.md, SIMartifacts: docsite, docsite-shots (7 days)sim-multidaypaths: payments src, simdays testsartifact: sim-multiday-reportui-screenspaths: web screens tests, configartifacts: ui-screens, failuresnightly-sandbox (PR)skip-check job, no secretsproves the specs skip, not failgate-g3-early (PR)reads statuses onlypaths: workflow, early scriptnightly-sandbox30 20 * * * (20:30 daily)sandbox-report, 14 daysjudge-smoke45 21 * * * (21:45 daily)traces on failure, 7 daysgate-g317 */6 * * * (every 6 hours)g3-probe-state, g3-entryuptime*/5 * * * * (every 5 minutes)off until UPTIME_ENABLEDbackup17 3 * * * (03:17 daily)red when it cannot back upaudit17 5 * * 1 (Monday 05:17)also on push to mainmutation0 3 * * 0 (Sunday 03:00)seeded check, strykergate-g3: start the probeRun workflow on mainday 0 of the 5 day probegate-g3-earlyinput mode: read or probeartifact: g3-early-evidenceui-screens-liveinputs: web_url, api_urlartifact: ui-screens-livedeploy-stagingpush to main (server paths), manualhook, wait for sha, smokedeploy-prodtag v*, manual (with rollback)must be the head of maindocsite deploy jobmain, same-repo PRsCloudflare Pages preview

Scroll the figure sideways, or open it full size.

Hover, focus or tap a workflow for its trigger, secrets (names only), artifacts and evidence label.

Every trigger, cron and artifact comes from the workflow file of the same name in .github/workflows on main. A hatched top edge marks a workflow that calls the PayPal sandbox with repository secrets; a dashed border marks the simulated-clock suite, which is a simulation and not a sandbox result. Secrets and variables appear by name only. Other workflows exist; this map shows the ones these docs rely on.
Text version of this diagram
  • Every pull request and push to main: ci (typecheck, lint, unit, property, voice and more, rolled up by the required job) and docsite (build, screenshots, deploy).
  • Pull requests that change certain paths: sim-multiday (simulated clock), ui-screens, the nightly-sandbox skip check, and the gate-g3-early read.
  • Scheduled, in UTC: nightly-sandbox 20:30 daily, judge-smoke 21:45 daily, gate-g3 every six hours at minute 17, uptime every five minutes, backup 03:17 daily, audit Monday 05:17, mutation Sunday 03:00.
  • Started by hand: gate-g3 to start the probe, gate-g3-early in read or probe mode, ui-screens-live with the web and API origins.
  • Deploy: deploy-staging on server-side changes on main, deploy-prod on a v tag that is the head of main, and the docs site deploy job.

Reading the map

The five lanes group workflows by what starts them. Hover or focus a box for its cron line, the secrets and variables it needs (names only), the artifacts it leaves and its evidence label.

Checks on every change

ci and docsite. A roll-up job named required collects the results.

Evidence workflows

nightly-sandbox, gate-g3, gate-g3-early (sandbox) and sim-multiday (simulated).

Deploys

deploy-staging, deploy-prod and the docs site publish.

Watchers

uptime, judge-smoke and backup run on a schedule and fail loudly when not configured.

Evidence labels

WorkflowWhat it provesLabel
nightly-sandboxReal PayPal sandbox specs R1 to R10 and the G5 speech harnessSandbox
gate-g3Whether an authorization stays capturable past the honor periodSandbox, in progress
gate-g3-earlyAn additional early reading from older G2 authorizationsSandbox, partial
sim-multidayThe settlement code against the fake PayPal on a simulated clockSimulated
ciTypes, lint, unit, property and scenario tests, the fake PayPalFake PayPal

Secrets and variables, by name

Values never go in the repository. Only throwaway sandbox values belong in the sandbox secrets.

Prop

Type

The sandbox environment protects nothing yet

The job names the GitHub environment sandbox-nightly, but it has no reviewer, no branch rule and no secrets of its own. The secrets are repository-level, so a workflow file on any pushed branch can read them. That is why only throwaway sandbox values are allowed in them.

When a check goes red

Open the failed run and read the failing job: gh run view <run-id> --log-failed.

If it is required, the failing job is named in its log; fix that job, not the roll-up.

If a scheduled evidence workflow ended red because secrets are missing, that is by design: a night that tested nothing must not look like a pass. Add the secrets named in its notice.

Download artifacts with gh run download <run-id> -n <artifact-name>: sandbox-report, g3-probe-state, g3-entry, g3-early-evidence, sim-multiday-report, ui-screens, judge-smoke-traces, docsite, docsite-shots.

Where this lives in the repository

Edit on GitHub

Last updated on

Re-running a gate

What to do when a gate fails, stays NOT RUN, or reads stale.

Incident response unverified

What to do, in order, when money state looks wrong. Built only from what the repository documents.