Summary
ci.yml only triggers on PRs whose base is main (or feat/package-quality):
on:
pull_request:
branches: [main, "feat/package-quality"]Every PR in a stacked wave targets its integration branch, not main. So for those PRs the two lanes that matter — check-test (repo-wide deno check + deno test) and quality (lint, fmt, scaffold-version guard, publish dry-run, advisory audit) — do not run at all.
The PR page still shows green, because surface-diff and code-quality do trigger on packages/**. A green tick on a stacked PR is therefore not evidence the code checks, tests, lints, or formats. It is nearly empty.
Why this is biting now (beta.10)
Three gates were made blocking this wave, and all three live in the quality job:
| Gate |
PR |
repo-drift (@ts-ignore / as never sweep) |
#772 |
| README tagline byte-cap |
#771 |
version-less jsr:@netscript/* specifier guard |
#769 |
None of them has executed in CI even once. They fire for the first time on the feat/beta10-integration → main PR — simultaneously, alongside the run-deno-lint.ts / run-deno-fmt.ts wrapper fixes that change what "green" even means. That integration→main PR is the first honest CI verdict for the entire wave, and it is carrying three brand-new blocking gates at once.
The second layer
ci.yml's own header states:
quality … "Additive and intended to become a required check (branch protection) once observed green; until then a red quality cannot block the merge gate."
So even on a main-targeted PR, making a gate "blocking" inside quality does not block a merge unless quality is a required check in branch protection. Worth confirming the branch-protection state before anyone relies on these gates — a gate that cannot fail a merge is documentation, not enforcement.
Why it matters beyond this wave
This is structural, not a beta.10 accident: any work developed on an integration branch — which is the repo's normal pattern for epics — accumulates unverified commits behind green ticks and discovers the truth in one large, late, noisy PR. That is the opposite of what CI is for.
Suggested fix
- Trigger
ci.yml on PRs into integration branches too — e.g. branches: [main, 'feat/**', 'epic/**'], or drop the base filter and rely on path filters.
- Confirm (and record) whether
quality is a required check in branch protection. If it is not, a "blocking" gate inside it blocks nothing.
- Consider surfacing, in the PR template or a bot comment, which lanes actually ran — so a reviewer cannot mistake "2 checks passed" for "CI passed".
Provenance
Found during the beta.10 wave while auditing why three newly-blocking gates showed no CI evidence. Related false-green findings from the same run: #769 (published-mode-only defect invisible to every local gate), #773 (generated artifact never diffed against source). The pattern across all of them: an exit code — or a green tick — is not evidence. Evidence is output you can point at, from a lane you can prove ran.
Summary
ci.ymlonly triggers on PRs whose base ismain(orfeat/package-quality):Every PR in a stacked wave targets its integration branch, not
main. So for those PRs the two lanes that matter —check-test(repo-widedeno check+deno test) andquality(lint, fmt, scaffold-version guard, publish dry-run, advisory audit) — do not run at all.The PR page still shows green, because
surface-diffandcode-qualitydo trigger onpackages/**. A green tick on a stacked PR is therefore not evidence the code checks, tests, lints, or formats. It is nearly empty.Why this is biting now (beta.10)
Three gates were made blocking this wave, and all three live in the
qualityjob:@ts-ignore/as neversweep)jsr:@netscript/*specifier guardNone of them has executed in CI even once. They fire for the first time on the
feat/beta10-integration→mainPR — simultaneously, alongside therun-deno-lint.ts/run-deno-fmt.tswrapper fixes that change what "green" even means. That integration→main PR is the first honest CI verdict for the entire wave, and it is carrying three brand-new blocking gates at once.The second layer
ci.yml's own header states:So even on a
main-targeted PR, making a gate "blocking" insidequalitydoes not block a merge unlessqualityis a required check in branch protection. Worth confirming the branch-protection state before anyone relies on these gates — a gate that cannot fail a merge is documentation, not enforcement.Why it matters beyond this wave
This is structural, not a beta.10 accident: any work developed on an integration branch — which is the repo's normal pattern for epics — accumulates unverified commits behind green ticks and discovers the truth in one large, late, noisy PR. That is the opposite of what CI is for.
Suggested fix
ci.ymlon PRs into integration branches too — e.g.branches: [main, 'feat/**', 'epic/**'], or drop the base filter and rely on path filters.qualityis a required check in branch protection. If it is not, a "blocking" gate inside it blocks nothing.Provenance
Found during the beta.10 wave while auditing why three newly-blocking gates showed no CI evidence. Related false-green findings from the same run: #769 (published-mode-only defect invisible to every local gate), #773 (generated artifact never diffed against source). The pattern across all of them: an exit code — or a green tick — is not evidence. Evidence is output you can point at, from a lane you can prove ran.