Stop merging with pr-gate red; make guest-feature removal fail pre-merge with the profile-first instruction

[ebursztein]

What happened (2026-09-24/25)

main went red twice in a row. In both cases CI had caught the problem before merge, and the PR merged anyway with the required pr-gate check failing.

PR	Red check at merge	Result on main
#246	fast-gate / static: tests/capsem-build-chain/test_process_profile_runtime_contract.py (capsem-process/src/metric_export.rs read corp files)	fast-gate / static red; fix in #248
#247	fast-gate / static and test-install: the published stable 0.6.1 rootfs doctor runs the snapshot MCP tests (guest/artifacts/diagnostics/test_mcp.py) that #247 removed from the binaries	test-install red on every PR until the stable profiles are republished

pr-gate is the only required status check on main, and both merges bypassed it. #247 also reversed the order in RELEASE.md §6.5: the feature was removed from the binaries before the profiles that still exercise it were republished. That leaves every PR red until someone runs a release.

Proposal

1. No merge while pr-gate is red. Turn off admin bypass for pr-gate (or enable "include administrators"), and add a line to AGENTS.md: an agent never merges with a required check red, even when the red predates its change. A red check that predates the change gets a fix PR first, as fix: grant VM processes their metric endpoint at launch (trunk red) #248 did.
2. A fast, pre-merge signal for guest-visible removals. test-install only finds this after about 45 minutes, and its failure doesn't say what to do. Add a citadel/fast-gate guard: when a PR deletes or renames a test under guest/artifacts/diagnostics/ (or removes an MCP tool the published profile's doctor calls), fail with the RELEASE.md §6.4–6.5 instruction. Republish the affected profiles first (just release-profile <channel> <profile> <sha>), then remove the feature from the binaries. The guard could compare the diff's deleted def test_* names under guest/artifacts/diagnostics/ against the doctor inventory of the currently published profile's manifest.
3. Record the known-red state in the gate digest. When main's red is a release-order state rather than a code defect, the trunk-CI hook should say so and name the owner, so agents don't route around it or stack changes on it.

Not proposed

• Booting the candidate profile in test-install: it would drop the published-profile compatibility proof §6.4 requires.
• A version-skew-aware doctor: it would bring back the compatibility stubs feat!: remove workspace snapshots; harden fork/create-from and the guest share #247 removed.

🤖 Generated with Claude Code