seam-coverage has been failing on main since somewhere between 2026-07-28 and 2026-07-31. It is not caused by #66 — see below.
Evidence it's pre-existing
Surfaced as a red check on #66. I dispatched the same workflow on main, where the pin was still the old one, as a control:
|
#66 branch (c693d07) |
main (3bb0154) |
| Checkout |
✅ |
✅ |
| Setup Bun / Install |
✅ |
✅ |
| Seam coverage step |
❌ |
❌ |
Same step, same conclusion, Checkout green in both. Control run: 30600571408.
Last known green on main: 2026-07-28 (3bb0154, push).
Why it can go red on its own
scripts/check-seam-coverage.ts enumerates the org's public non-archived repos, keeps the ones whose package.json carries a bounded block, shallow-clones each, and runs assertAllPackagesChecked over them. That makes it an assertion about org state, not about this repo's contents — a new capability repo without a seam claim turns it red with no commit here.
That's the check working as designed; the failure is real, it just isn't a regression in this repo.
What's needed
Either a seam claim in whichever repo is newly uncovered (@bounded-systems/seam-check + an assertSeam test), or an EXEMPT entry with a written reason per the note in the script.
I couldn't identify which repo — it's outside the scope this session had access to. The step's own error output names the offending packages:
✗ seam-coverage gap — capability packages (carry a 'bounded' block) with NO seam check:
<names printed here>
Worth considering separately
A check that asserts over org state will keep going red on unrelated PRs, which trains people to merge past it. Splitting it from the per-PR required set — scheduled, or reporting to one place — would keep the signal without attaching it to whoever happens to open the next PR. It already runs weekly on a schedule; the pull_request trigger is the part that spreads it.
seam-coveragehas been failing onmainsince somewhere between 2026-07-28 and 2026-07-31. It is not caused by #66 — see below.Evidence it's pre-existing
Surfaced as a red check on #66. I dispatched the same workflow on
main, where the pin was still the old one, as a control:c693d07)main(3bb0154)Same step, same conclusion,
Checkoutgreen in both. Control run: 30600571408.Last known green on
main: 2026-07-28 (3bb0154, push).Why it can go red on its own
scripts/check-seam-coverage.tsenumerates the org's public non-archived repos, keeps the ones whosepackage.jsoncarries aboundedblock, shallow-clones each, and runsassertAllPackagesCheckedover them. That makes it an assertion about org state, not about this repo's contents — a new capability repo without a seam claim turns it red with no commit here.That's the check working as designed; the failure is real, it just isn't a regression in this repo.
What's needed
Either a seam claim in whichever repo is newly uncovered (
@bounded-systems/seam-check+ anassertSeamtest), or anEXEMPTentry with a written reason per the note in the script.I couldn't identify which repo — it's outside the scope this session had access to. The step's own error output names the offending packages:
Worth considering separately
A check that asserts over org state will keep going red on unrelated PRs, which trains people to merge past it. Splitting it from the per-PR required set — scheduled, or reporting to one place — would keep the signal without attaching it to whoever happens to open the next PR. It already runs weekly on a schedule; the
pull_requesttrigger is the part that spreads it.