You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The Factory repo's rulesets hold the Release tags and each required check's App #62
Part of the epic "Epic: slice 0, foundations. The repo holds the line, its context is tested, and the platform facts are recorded". Why. Any identity that can write contents could move next or stable, and the shim runs whatever those tags point at. Done when a tag ruleset limits the creation, update and deletion of factory/* tags to the Maintainer, until trial P-30 names the release identity. A fixture records each required check's type and integration id, and the merge-queue rule.
Raised by the security pass on story #20, "The Apps' permissions as data"; ruling on that issue.
Added scope, from the security pass on the story "Session hooks that check" (2026-10-14): a session hook is a guard against mistakes, not a sandbox. The controls an agent cannot get around live on the server. Consider in this story: require signed commits on main, and restrict pushes so that the machine user (donpetry-bot) cannot push or create refs, through the API or otherwise.
Applied 2026-10-15, with the Maintainer's credential and approval: ruleset 25183656, "factory release tags".
Target: tags matching refs/tags/factory/*.
Rules: creation, update, deletion and non-fast-forward are all refused.
Bypass: only the repository's admin role, which today is the Maintainer alone. It excludes donpetry-bot (maintain), every write collaborator, and every App, until trial P-30 names the release identity.
Effect today: no tags exist yet, so nothing current is affected.
Still to do in this story (next session):
A fixture under trials/ recording each required check's type and integration id (verify, pinned to GitHub Actions, 15368), the main ruleset's merge-queue rule, and this tag ruleset, so drift is visible.
Considered, and left out of what was applied:
Signed commits on main: the merge queue's squash commits are signed by GitHub, so it should hold, but it needs a trial before it is required.
Restricting donpetry-bot's pushes: it holds the repository's maintain role, which can push branches. The main ruleset (pull request and merge queue, no bypass) already stops a direct push to main. Lowering the machine user to the least role that can approve (write) is the Maintainer's call.
From #113 (PR #135, decision 0020): the Kernel now holds a change to a protected path or a Lens's input until every model Lens has reviewed its head, and the machine user then approves it. GitHub does not yet hold the same line, because the main ruleset requires no review. The ruleset half stays here: require the machine user's approval of the latest push, at least for the paths in config/hooks.json (protected, plus lens_inputs), for example through code owners and "require approval of the most recent push". This is the Maintainer's, with #89.
Applied on 2026-10-18 at the Maintainer's word: the main ruleset (24886320) now has required_review_thread_resolution: true, which is "Require conversation resolution before merging". No other field changed: the ruleset was read back and compared with its earlier state.
Why: PRs #156 and #166 were added to the merge queue three times as don-petry, with no App, while review threads were still open. The session's clean-and-green script didn't do it. GitHub now refuses to queue or merge a pull request with an unresolved thread, whoever asks. The fixture of the rulesets that this issue records should include this rule.
The fixture does not wait on P-30. The tag ruleset (25183656) and the main ruleset (24886320, with thread resolution required since 2026-10-18) are applied and can be recorded now: one read-only capture through the Maintainer's login, redacted outside the repo, as trials/rulesets.json or under the trial number the fixture names, with each required check's type and integration id (verify, GitHub Actions, 15368), the merge-queue rule, the tag rules and their bypass. #95's threshold joins it once set. When P-30 names the release identity (its own story, batch 2), the tag ruleset changes and the fixture is replaced. Lane c2, one PR, any free slot. The drift check (the live ruleset against the fixture) waits on controller/, as the readiness check of §3.12 does; the fixture alone makes drift visible by hand.
Activity
don-petry commentedon Oct 14, 2026
Added scope, from the security pass on the story "Session hooks that check" (2026-10-14): a session hook is a guard against mistakes, not a sandbox. The controls an agent cannot get around live on the server. Consider in this story: require signed commits on
main, and restrict pushes so that the machine user (donpetry-bot) cannot push or create refs, through the API or otherwise.don-petry commentedon Oct 15, 2026
Applied 2026-10-15, with the Maintainer's credential and approval: ruleset 25183656, "factory release tags".
refs/tags/factory/*.donpetry-bot(maintain), every write collaborator, and every App, until trial P-30 names the release identity.Still to do in this story (next session):
trials/recording each required check's type and integration id (verify, pinned to GitHub Actions, 15368), themainruleset's merge-queue rule, and this tag ruleset, so drift is visible.Considered, and left out of what was applied:
main: the merge queue's squash commits are signed by GitHub, so it should hold, but it needs a trial before it is required.donpetry-bot's pushes: it holds the repository's maintain role, which can push branches. Themainruleset (pull request and merge queue, no bypass) already stops a direct push tomain. Lowering the machine user to the least role that can approve (write) is the Maintainer's call.don-petry commentedon Oct 17, 2026
From #113 (PR #135, decision 0020): the Kernel now holds a change to a protected path or a Lens's input until every model Lens has reviewed its head, and the machine user then approves it. GitHub does not yet hold the same line, because the
mainruleset requires no review. The ruleset half stays here: require the machine user's approval of the latest push, at least for the paths inconfig/hooks.json(protected, pluslens_inputs), for example through code owners and "require approval of the most recent push". This is the Maintainer's, with #89.don-petry commentedon Oct 18, 2026
Applied on 2026-10-18 at the Maintainer's word: the
mainruleset (24886320) now hasrequired_review_thread_resolution: true, which is "Require conversation resolution before merging". No other field changed: the ruleset was read back and compared with its earlier state.Why: PRs #156 and #166 were added to the merge queue three times as don-petry, with no App, while review threads were still open. The session's clean-and-green script didn't do it. GitHub now refuses to queue or merge a pull request with an unresolved thread, whoever asks. The fixture of the rulesets that this issue records should include this rule.
don-petry commentedon Oct 19, 2026
Sequence (plan review, 2026-10-19)
The fixture does not wait on P-30. The tag ruleset (25183656) and the
mainruleset (24886320, with thread resolution required since 2026-10-18) are applied and can be recorded now: one read-only capture through the Maintainer's login, redacted outside the repo, astrials/rulesets.jsonor under the trial number the fixture names, with each required check's type and integration id (verify, GitHub Actions, 15368), the merge-queue rule, the tag rules and their bypass. #95's threshold joins it once set. When P-30 names the release identity (its own story, batch 2), the tag ruleset changes and the fixture is replaced. Lane c2, one PR, any free slot. The drift check (the live ruleset against the fixture) waits oncontroller/, as the readiness check of §3.12 does; the fixture alone makes drift visible by hand.