run.sh / pre-push
same suite CI will run; on the machine; once, before the PR is marked ready. Since #2107 the pre-push hook keeps the drift gate on every push and runs the suite only on a push to main. This is CI. It does not need GitHub.
Local
—
not a served origin. Worktrees are unobservable from this page until a draft PR exists.
Staging
…
Production
…
Six columns of work in flight. Everything not yet claimed is on the Backlog page — the whole of it, Later included, with epics nesting their children.
Claimed / local
0Heuristic — local worktrees are invisible until a draft exists.
Draft PR
0Ship skipped. Nested issue numbers.
Ready / Ship
0Non-draft, not queued. Leak chip if suite runs > 1.
Queued
0Waiting on land-sweep.
On staging
0The app, landed, not yet promoted.
Production
0The last promote only.
Landed, not deployed
0On main, and NOT inside the commit the production console is serving. Landing publishes the console nowhere.
Deployed
0What admin.provenbatch.co.uk actually serves, read from its own bytes.
Backlog
Every open issue. No cap, nothing dropped — a child sits under its epic because something attached it there, not because of a label.
If this page and WAYS-OF-WORKING.md / handbook/shipping.md disagree, this page is stale — the same rule as the batch-protocol diagram. Do not fork a second copy of the rules here.
Processes
open draft
backup of the branch, not a test run. ship.yml skips suite / test / preview. land.yml refuses a draft.
ready → ship.yml
paid confirmation of the same suite, plus preview. Marking ready (or opening non-draft) starts it. Further pushes to a ready PR each pay another suite run.
queued
orchestrator labels; land-sweep collects. Workers never apply queued.
land.yml → staging
only writer to main. Gates the merged tree (the tree is different from the PR branch). Then stamps and deploys staging.
your ok → promote.yml
Dave. Never autonomous.
Two trains, one repo
The board and the Backlog are filtered by release train, and the switch above the environment strip picks which. The two share the merge point and nothing else: the app ships APP_VERSION (v*) through land → staging → promote; the admin console ships ADMIN_VERSION (a*) and is published only by dispatching Deploy site, once for staging and once for production. So the admin tail is Landed, not deployed and Deployed, not On staging and Production: there is no promote to wait for.
| What it is | How it is classified | Which board |
|---|---|---|
| A pull request | By the paths it touches, read from /pulls/{n}/files | outputs/bakery-app-site/ → App. outputs/admin-site/ or supabase/functions/admin-api/ → Admin Portal. Both → both boards. |
| A PR that is neither: CI, workflows, documents, the marketing sites, ops | Same files call; it simply matches no prefix | App before landing, nothing after. It is genuinely in flight, so it stays visible; once landed it is waiting on no promote and no dispatch, so both tails exclude it. That is a decision, not a gap. |
| A PR nobody could classify | The files call was skipped for budget, or did not answer | App, always. Fails open: a card nobody could read must be visible somewhere, and it is never shown on both, because "on both boards" would then mean two unlike things. The count is bannered above. |
| An issue | The admin portal label, and nothing else. An issue has no files. | Labelled → Admin Portal. Everything else → App. |
| A landed admin change, deployed or not | Ancestry, never a clock. Is the pull request's merge_commit_sha inside the commit the served ADMIN_BUILD names? | Inside it → Deployed, so off the tail. Not inside it → Landed, not deployed. Undecidable → stays on the tail, counted and bannered. merged_at cannot answer this: land.yml commits to main before its gate and GitHub stamps merged_at after it, so every pull request of the landing that built the deployed console reports itself undeployed. And a tolerance window cannot repair it, because the pull requests of one batched landing share a single merged_at while each gets its own build. One thing older than the ancestor page is decidable, though: a pull request merged before the oldest commit on that page was already in main when the deployed build was created, so it reads Deployed. That is an ordering a page apart, not a tolerance. |
Three copies of the same suite
CI is copies 1–3. CD to staging is land after copy 3. CD to production is promote, which is not the suite.
| Copy | Where | Which tree | Cost | Keep? |
|---|---|---|---|---|
| 1 | run.sh / pre-push | This worktree, this issue | Once before ready (~3–6 min). Branch-push hook skips (#2107) | Keep. Inner loop. |
| 2 | ship.yml on a ready PR | This branch, still not main | GitHub, per ready PR | Candidate to drop (B2). Not this issue. |
| 3 | land.yml on the merge | main as it is now, plus this PR | GitHub, per landing | Keep. CI-together. |