← The Machine
The measurement · integration.yml

Integration

Whether the work arrives — stranded branches, dead pipelines, and trunks a property is deploying behind.

.github/workflows/integration.yml

What it does

Every other gate in this estate asks whether the work is good. This one asks whether it arrives, which is where a read of every branch on 31 August found it was actually losing: forty-two stranded branches, seven hundred and eighty-six commits waiting, the oldest fifty-five days old, three properties deploying behind their own trunk, and a security fix unmerged since July.

Two halves, deliberately separate. The offline half reads git and is a ratchet — the recorded numbers are ceilings, and the job fails when any of them grows, so a backlog of unmerged work cannot creep upward while every individual check stays green.

The other half judges CI colour, which needs the API. The fetching happens in the workflow, where a token exists; everything decided lives in the tool, where it is tested against fixtures. It fails on any red trunk, because a red trunk is a failure — flashyID’s own CI config records four days of one that nobody noticed.

When it runs
Daily, and on demand. Daily rather than weekly because a stranded branch and a dead pipeline are both time-sensitive: a weekly cadence would have reported those four red days as, at best, one tick.
What it emits
A ratchet verdict against the recorded ceilings — branches, commits, age, properties behind their trunk — and a pass or fail on the colour of every trunk in the estate.

What a stranger can verify

That “merged” is measured rather than assumed. Run `node tools/estate-integration.mjs` over the checkouts yourself: it is offline, it reads the refs rather than the working tree, and its ceilings are recorded in the repository so a regression is a failing check rather than a slightly worse number nobody was watching.

Questions

What does the Integration workflow check?
Whether work arrives, not whether it is good: branches that never merged, commits waiting on them, properties deploying behind their own trunk, and the colour of every trunk in the estate. It is a ratchet, so any of those growing is a failing check.
Why is it daily rather than weekly?
Because a stranded branch and a red pipeline are time-sensitive in a way a hygiene regression is not. A weekly run would have reported four consecutive days of red CI on one property as a single tick, long after it mattered.
Why does it fail rather than skip when it cannot clone the estate?
Same reason the hygiene gate does. A repository-scoped token cannot see sibling repositories, and a gate that goes green because it looked at nothing is worse than no gate at all — because somebody believes it.

Keep reading

Read the workflow — it hides nothing ↗How the estate stays honest — all of it
Also in the measurement
RegistrySurfacesEstate graphAdoption signalHygieneScoreboardShipOS gateFlashyOS branch mesh sync