While cutting v0.3.5 I checked the merge gate and found nothing enforces CI on main:
```
$ gh api repos/pulseengine/kiln/branches/main/protection/required_status_checks
→ .contexts = []
$ gh api repos/pulseengine/kiln/rules/branches/main # rulesets
→ (no required_status_checks rule)
```
CI runs on every PR and push, but neither classic branch protection nor a ruleset lists any required context — so a PR can be merged while checks are red, queued, or cancelled. The green dashboard is advisory, not a gate.
Why it matters: this is the campaign invariant the release process asserts ("the protected branch's required_status_checks.contexts is non-empty — the gate is real"). An empty gate means "verified release" can't be guaranteed by the machinery; every release currently relies on a human confirming green before merge (as I did for v0.3.5). One distracted merge lands red on main.
Fix: add a ruleset (or classic protection) on main requiring the actual gate contexts — at minimum `build`, `Core Tests, Analysis & Coverage`, `CI Checks & Docs`, `Safety Analysis with Clippy`, `SCORE-Inspired Safety Verification`, and the `Security Audit` matrix. Consider requiring the WAST conformance gate too once #362 has run a few cycles.
Found during the v0.3.5 release. Not a v0.3.5 blocker (that commit was confirmed green pre-merge), but it should gate before the next release.
While cutting v0.3.5 I checked the merge gate and found nothing enforces CI on
main:```
$ gh api repos/pulseengine/kiln/branches/main/protection/required_status_checks
→ .contexts = []
$ gh api repos/pulseengine/kiln/rules/branches/main # rulesets
→ (no required_status_checks rule)
```
CI runs on every PR and push, but neither classic branch protection nor a ruleset lists any required context — so a PR can be merged while checks are red, queued, or cancelled. The green dashboard is advisory, not a gate.
Why it matters: this is the campaign invariant the release process asserts ("the protected branch's required_status_checks.contexts is non-empty — the gate is real"). An empty gate means "verified release" can't be guaranteed by the machinery; every release currently relies on a human confirming green before merge (as I did for v0.3.5). One distracted merge lands red on main.
Fix: add a ruleset (or classic protection) on
mainrequiring the actual gate contexts — at minimum `build`, `Core Tests, Analysis & Coverage`, `CI Checks & Docs`, `Safety Analysis with Clippy`, `SCORE-Inspired Safety Verification`, and the `Security Audit` matrix. Consider requiring the WAST conformance gate too once #362 has run a few cycles.Found during the v0.3.5 release. Not a v0.3.5 blocker (that commit was confirmed green pre-merge), but it should gate before the next release.