The gap
main-base is the merge-routing jail: it runs, and fails, only on a PR to
main whose head is not staging or a reviewed non-feature lane. It is
documented as the mechanism that stops a feature PR riding around the promotion
path.
It is not a required status check, so it cannot stop anything.
Live ruleset main: require PR requires exactly gate, paths,
promotion-gate. A feature PR opened straight to main passes all three:
paths short-circuits to exit 0 for any head not named predict/run-* or
evaluate/run-*, and promotion-gate reports skipped, which satisfies the
requirement. main-base goes red beside them without blocking the merge.
So merge routing into main currently rests on the promotion convention plus
the maintainer's merge. That is a real control, not nothing — but it is not the
mechanical one the design intends, and required approvals are 0, so the
platform contributes no second pair of eyes either.
Why it cannot simply be switched on
main-base is defined in .github/workflows/ci.yml on staging. It does not
exist in origin/main's ci.yml.
On a pull_request, the workflow runs from the merge ref. Every legitimate lane
into main — the collect run branches, cleanup/*, metrics/refresh,
metrics/cert-backtest — is cut from main, so those PRs run main's own
ci.yml, which has no main-base job. The context would never report, and a
required context that never reports leaves every auto-merging collect PR
pending forever. That would stall data production, which is worse than the gap
it closes.
Order of operations
- Promote the
main-base job definition into main's ci.yml (it rides an
ordinary staging→main promotion batch; no special handling).
- Confirm a collect PR reports the context and passes — one real data run is
the test, not a dry run.
- Only then add
main-base to main: require PR's required contexts.
Step 3 before step 1 hangs every collect auto-merge. The steps are separated by
at least one promotion cycle by construction.
Worth deciding at the same time
Whether required_approving_review_count should move off 0 on main. The
docs now say plainly that review there is convention rather than enforcement;
docs/security.md notes 1 is the setting if a second reviewer exists. That is
a people question, not a config one, so it may well stay at 0 — but it should
be a decision rather than a default.
Where this is documented
docs/security.md (the ruleset inventory), docs/pipeline.md (the promotion
section and the one-time-setup checklist), and ci.yml's main-base comment
all now describe the gap accurately. They will need a pass when it closes.
The gap
main-baseis the merge-routing jail: it runs, and fails, only on a PR tomainwhose head is notstagingor a reviewed non-feature lane. It isdocumented as the mechanism that stops a feature PR riding around the promotion
path.
It is not a required status check, so it cannot stop anything.
Live ruleset
main: require PRrequires exactlygate,paths,promotion-gate. A feature PR opened straight tomainpasses all three:pathsshort-circuits toexit 0for any head not namedpredict/run-*orevaluate/run-*, andpromotion-gatereportsskipped, which satisfies therequirement.
main-basegoes red beside them without blocking the merge.So merge routing into
maincurrently rests on the promotion convention plusthe maintainer's merge. That is a real control, not nothing — but it is not the
mechanical one the design intends, and required approvals are
0, so theplatform contributes no second pair of eyes either.
Why it cannot simply be switched on
main-baseis defined in.github/workflows/ci.ymlonstaging. It does notexist in
origin/main'sci.yml.On a
pull_request, the workflow runs from the merge ref. Every legitimate laneinto
main— the collect run branches,cleanup/*,metrics/refresh,metrics/cert-backtest— is cut frommain, so those PRs runmain's ownci.yml, which has nomain-basejob. The context would never report, and arequired context that never reports leaves every auto-merging collect PR
pending forever. That would stall data production, which is worse than the gap
it closes.
Order of operations
main-basejob definition intomain'sci.yml(it rides anordinary staging→main promotion batch; no special handling).
the test, not a dry run.
main-basetomain: require PR's required contexts.Step 3 before step 1 hangs every collect auto-merge. The steps are separated by
at least one promotion cycle by construction.
Worth deciding at the same time
Whether
required_approving_review_countshould move off0onmain. Thedocs now say plainly that review there is convention rather than enforcement;
docs/security.mdnotes1is the setting if a second reviewer exists. That isa people question, not a config one, so it may well stay at
0— but it shouldbe a decision rather than a default.
Where this is documented
docs/security.md(the ruleset inventory),docs/pipeline.md(the promotionsection and the one-time-setup checklist), and
ci.yml'smain-basecommentall now describe the gap accurately. They will need a pass when it closes.