Workflow operation is admin-only: engineering branch protection vs commit-and-persist, and the branch mixes two trust classes

[m2ux]

Deferred. Recording the finding and the options; no change proposed for now. See Trigger for revisiting at the bottom.

Summary

Running any workflow requires repository admin, because commit-and-persist pushes to engineering after every completed activity and the Default ruleset requires a pull request on that branch. The admin bypass is load-bearing infrastructure rather than a safety valve.

Simply relaxing the rule is not obviously correct: engineering carries agent instructions and executable scripts alongside the machine-written artifacts, so the branch mixes two trust classes.

Observed configuration

Ruleset "Default" (id 11937302), enforcement active:

• conditions.ref_name.include — ~DEFAULT_BRANCH, refs/heads/workflows, refs/heads/registry, refs/heads/engineering
• rules — deletion, non_fast_forward, pull_request with required_approving_review_count: 1
• bypass_actors — RepositoryRole 5 (admin), bypass_mode: always

workflow-engine::commit-and-persist commits and pushes all changes under the planning folder to engineering after each completed activity, and requires the push to succeed before the operation returns. orchestrator-target-path-scope forbids creating a branch in the parent repo for those commits, so a direct push is the prescribed path.

One workflow-design session produced five such pushes. Each reported:

remote: Bypassed rule violations for refs/heads/engineering:
remote: - Changes must be made through a pull request.

That message is the configured allowance being exercised, as designed — it is not a warning, and because the allowance is always across all four refs, its presence carries no signal about whether a given push was appropriate.

Consequence

A collaborator with write but not admin access cannot complete a single activity. The post-activity push is mandatory and the pull_request rule rejects it, so the run halts at the first activity boundary. Workflow operation is effectively admin-only.

Why relaxing the rule is not obviously right

origin/engineering contains:

AGENTS.md  CLAUDE.md  scripts/  artifacts/  history/  proposals/  .gitmodules  README.md  result.json

Two distinct trust classes:

Class	Contents	Character
Machine-written	artifacts/, history/	Effectively append-only, per-slug folders, written many times per session by automation
Behaviour-steering / executable	AGENTS.md, CLAUDE.md, scripts/	Instructions agents are required to read (read-agents-md mandates consulting .engineering/AGENTS.md before committing) and shell utilities that run

Dropping pull_request from engineering would let any write-access collaborator change agent instructions and scripts with no review, leaving only deletion and non_fast_forward — the two protections least relevant to this content. That is a security regression, and one that is hard to notice after the fact.

Constraint on the clean fix

m2ux is a User account, not an organisation. Ruleset bypass actors on a personal repository are limited to repository roles and GitHub Apps: teams are unavailable, and an individual user cannot be named. The workflow currently runs from a local CLI on a user token, so granting a narrowly-scoped bypass to the automation identity is not available without changing how it runs.

Options, none chosen

1. Status quo. Automation runs as admin. Zero practical cost while the admin is the sole operator; blocks non-admin operators entirely.
2. Split the trust classes. Move AGENTS.md, CLAUDE.md and scripts/ off engineering, or move artifacts/ to a branch of its own, then unprotect only the machine-written side. This is the principled fix — the branch's mixed content creates the dilemma, not the ruleset. Touches submodule wiring.
3. Run workflows under a GitHub App and grant the App the bypass. Preserves human review on the reviewable content and removes the admin requirement for automation. Most work; best end state if non-admin operators are ever wanted.

Retaining the admin bypass is worth it under any option — direct correction of artifact history is occasionally needed. The problem is that it is currently the only way the workflow functions.

Also worth checking

refs/heads/registry sits in the same include list. If it is machine-written it has the identical problem; if it is human-curated it does not. Not investigated.

Trigger for revisiting

The moment a second, non-admin operator needs to run a workflow. Until then option 1 holds and no change is needed.

Provenance

Surfaced while resuming the 2026-07-27-conditional-session-resume workflow-design session, from the five engineering pushes that session's commit-and-persist hook performed. Unrelated to that session's scope.