Skip to content

The Factory repo's rulesets hold the Release tags and each required check's App #62

Open

Description

@don-petry

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.

Activity

  1. don-petry commented on Oct 14, 2026

    @don-petry
    ContributorAuthor

    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.

  2. don-petry commented on Oct 15, 2026

    @don-petry
    ContributorAuthor

    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.
  3. don-petry commented on Oct 17, 2026

    @don-petry
    ContributorAuthor

    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.

  4. don-petry commented on Oct 18, 2026

    @don-petry
    ContributorAuthor

    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.

  5. don-petry commented on Oct 19, 2026

    @don-petry
    ContributorAuthor

    Sequence (plan review, 2026-10-19)

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions