Quanta · Level 3 · for red-pen

CI Receipt Banking

Today a green CI run leaves no permanent trace. After this build, every green run on a wired repo’s home branch banks one receipt into the repo itself — a tiny robot commit anyone can read from a plain clone. This is the job that gates your team announcement.

Reviewed draft (graded 7/10, findings folded) · build starting · fleet re-stamp waits on your word

Jump to: Decisions · Your calls · What could go wrong · How we know it works

The decisions, locked by evidence

The receipt commits back into its own repo. Four independent research passes checked every other home for it — git’s hidden metadata channel, GitHub’s attestation vaults, a central collector — and each fails structurally: invisible to anyone who just clones, or expires in 90 days, or needs a powerful key we don’t want to mint. Committing back is what the whole field does for exactly this job.
GitHub’s own robot makes the commit. GitHub documents — and I verified from the source, not memory — that the robot’s pushes cannot restart CI. The infinite-loop nightmare is structurally impossible, not merely guarded.
Banking is a separate final job. If it fails, the owner’s tests and deploys never notice. It can skip; it can never block.
Each repo’s home branch is read, never assumed. The reviewer caught that assuming “main” would silently never-bank the repos that live on dev. The generator now derives it from each repo’s own CI.
Org repos first; team repos opt in. Bot commits on Greg’s or a-cline’s branches are their call, not ours.

The journey of one green run

  1. A repo’s checks go green. Someone pushes to the repo’s home branch; the tests pass. Today that moment evaporates. After this build, it leaves a permanent, checkable trace.
    ↘ go deeper — when banking fires and when it deliberately doesn’t
    Fires only when all three are true: the run succeeded, the trigger was a push (never a pull request), and the branch is one the repo’s own CI names as home (derived from on.push.branches; multi-branch repos get a list guard; no derivable home = the generator refuses loudly and wires nothing). Fork PRs carry a read-only token and skip by construction. No bot commits ever land on feature branches.
  2. The banking job wakes — alone, at the end. It is a leaf: nothing downstream depends on it, so a banking failure is a loud log line, never a blocked deploy.
    ↘ go deeper — the job’s guardrails
    Runs needs: [the repo’s CI job] with if: success() && push && home-branch. Asks for write permission at the job level only — GitHub’s docs confirm this elevates past the org’s read-only default (the reviewer thought the default was a hard cap; the docs say otherwise; the proof run confirms empirically). Overlapping runs on the same branch queue behind a concurrency group instead of racing.
  3. It installs quanta on the throwaway machine. The quanta repo is private, and a repo’s own CI key can’t read other private repos — so one org-level key (same mechanism as your existing Cloudflare deploy keys) unlocks the install for every org repo at once. Its shape is your call #1.
    ↘ go deeper — the key touches nothing but the install
    The org secret is read-only on the quanta repo and is used solely by the install (npm pack of the private repo, the proven team-install path). The later push home uses GitHub’s built-in robot key — never this one — which is what keeps the loop-exemption intact. Install fails? Named skip, job green, no receipt, no blockage.
  4. It mints the receipt. The same quanta deposit the team runs locally — it refuses dirty or unverifiable states exactly the same way. Banking transports receipts; it never manufactures them.
  5. It commits the receipt home. One tiny commit by GitHub’s robot account onto the home branch. This is the load-bearing step, and its two classic failure modes are both closed: loops are structurally impossible (verified from GitHub’s docs — robot pushes don’t trigger CI), and racing runs queue then retry with a rebase, worst case skipping loudly.
    ↘ go deeper — the verified fact this rests on
    GitHub’s documentation, verbatim: “if a workflow run pushes code using the repository’s GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.” Belt-and-suspenders: the commit message also carries [skip ci]. The push names its target branch explicitly (a bare push can silently fail on CI checkouts — reviewer catch). The commit adds only the receipt folder, never the whole tree.
  6. Anyone who clones the repo can read it. No tool, no login, no API — the receipt is a line in a file in the tree, pinned to the exact commit it attests. This is the moment your announcement sentence — “when a repo’s checks pass, it banks a record” — becomes plainly true.
Nothing team-facing moves before the witnessed proof and your word. Both Slack drafts stay held.

Your calls

1. The install key: simple token, or GitHub App?

Simple read-only token (my recommendation for now): five minutes to set up; expires yearly — when it lapses, banking quietly pauses until renewed, and a tripwire is chipped so the silence gets noticed. GitHub App: never expires, no renewal duty, about thirty minutes of one-time ceremony. The workflow is identical either way. You create the credential yourself either way — I stage the exact clicks.

2. Confirm brand-discovery as the proof repo.

Checked today: its main branch is unprotected, org keys reach it, and its CI is simple. Good witness conditions — but any org repo works if you’d rather.

3. The fleet re-stamp stays on your word.

After the proof, re-wiring the rest of the fleet — and the repos already wired the old way get the old step swapped out in the same clean diff, one reviewed PR per repo.

What could go wrong — and what catches each one

Two green runs race to push. They queue behind a per-branch gate and retry with a rebase; worst case one receipt skips, loudly. Never a corrupted branch.
A protected branch rejects the robot. Fail-safe skip with a loud log; the fix is a per-repo call surfaced to you. The proof repo is verified unprotected as of today.
The install key lapses. Banking silently pauses — the one failure that looks like nothing. A chipped doctor check will flag any wired repo that hasn’t banked in N days; until it ships, the witnessed proof is the detection.
Commit noise. One one-line robot commit per green push on the home branch — a few a day fleet-wide, each tagged to stay out of CI’s way.
Someone re-runs an old green run. A receipt for that old commit banks again — a true statement about a commit that really did pass. Harmless by design; noted so nobody mistakes it for a bug.

How we’ll know it works

Your DONE, verbatim intent: one CI-only repo (brand-discovery) shows a receipt committed from a green CI run, witnessed — the robot’s commit visible on GitHub, the receipt readable from a fresh clone with no tools — plus the install step present in the generated job. Rollback is one revert of one commit.

↘ go deeper — the mechanical gates under that
Fixture proofs for every generated shape (single-branch, multi-branch, delegator workflows, no-filter-with-derivable-default, and the migration case where the old inline step must vanish). Deliberate-break legs that must go red: a dropped guard clause, the comment-absorbed no-op class, a lingering old step, a guard naming a branch the CI never runs on. Loud refusals proven for the unwireable shapes. Idempotent re-runs. The existing gate harness stays green. Then the mandatory adversarial pair — two independent engines with different failure modes — on the generator diff before anything merges, and finally the witnessed proof run with its preconditions checked first.