Cut `v1.0.0` with `release-cut` — and settle which actor pushes the tag

[bdelanghe]

Correction to this issue's original premise

It was filed saying "a ruleset restricts tag creation, so a human must grant it in [settings]". Both halves of that look wrong, and the correction matters more than the issue did.

Rulesets in this org are code, not UI. They live in .github-private at org/rulesets/*.json and are applied by org-sync.yml. Nothing about them is a human clicking in a settings pane.

And none of them touch tags. Every committed ruleset is target=branch or target=repository:

ci-green*.json                 target=branch
default-branch-protection.json target=branch
critical-repo-protection.json  target=branch   (enforcement=disabled)
protect_important_repos.json   target=repository

A search across docs/, org/ and .github/ in .github-private for refs/tags, tag creation, protected tag returns nothing.

So what was the 403?

Almost certainly the Claude Code session git proxy, not a repository rule. The observed pattern, isolated at the time:

operation, from a session	result
create branch	allowed
delete branch	refused
create tag	refused

No GitHub ruleset produces that shape — a tag-creation rule does not also refuse branch deletes. A proxy permitting creates/updates under refs/heads/* and refusing everything else explains all three. mint#22 reached exactly this conclusion for an identical symptom, and explicitly separated it from mint#18's org ruleset: "Different mechanism from #18 — that's an org ruleset, this is a Claude Code session's git proxy — but the same shape."

A GitHub Actions runner is not behind that proxy. So release-cut.yml may be able to push the tag with github.token today, with no grant and no settings change.

This has never been tested: mint#23's release-cut has never cut a real tag either, so nobody in this org has yet observed a workflow attempting a tag push.

What to do

Dispatch release-cut with expect-version: 1.0.0, dry-run: false.

That is the test, and it is a safe one to run: all four guards pass already (verified against real repo state in #1071), and the only remaining step is the push. If no restriction exists, the tag lands, release-binary.yml is dispatched at it, and v1.0.0 ships — the outcome we want. If a restriction does exist, it fails closed at the push having created nothing but a local tag inside the runner. There is no half-released state between those.

Run dry-run: true first if you want the guard output on the record; it cannot tell you anything about the push.

The actor question still stands

Independent of whether a restriction exists today, it is worth deciding who should hold tag-creation, because the answer shapes the workflow:

• A — the repo's Actions actor (what the code does today). Cuts with github.token. Simplest; nothing to mint. If tag rules are ever introduced, they would have to name this actor, which is broad: any workflow with contents: write inherits it.
• B — a pinned App identity, minted from a capability-named broker entry pinned to release-cut.yml — the shape version.yml uses (/github/forge-version) and claim-ticket.yml uses (front-desk-claim). Narrower by construction. Costs an infra-side broker entry.

On mint#22's rejection of "a PAT or App token so the push looks human": that objection is about buying a trigger with a standing credential. release-cut.yml already solves triggering separately, by dispatching release-binary.yml at the new tag. B would be authorization, not triggering — related but not the same, and worth saying out loud if adopted.

If B is chosen, the dispatch step must be removed: an App-token push does fire on: push: tags, so release-binary.yml would otherwise run twice. Under A the dispatch is load-bearing, because a GITHUB_TOKEN push triggers nothing.

Acceptance

• v1.0.0 is cut and release-hashes.json on main moves off 0.29.0.
• The actor that pushes release tags is a deliberate choice, recorded.
• If a tag restriction is discovered to exist after all, it is added to org/rulesets/ as code — not applied by hand.

Related: #1068, #1069, #1071, #434, #1072, mint#18, mint#22.

[bdelanghe]

Decision: Option B — a pinned App identity via the broker

Recording the call and the reasoning, including the part that argues against it.

Why B, beyond least privilege

It removes a workaround instead of adding one. release-cut.yml's dispatch step exists solely because a GITHUB_TOKEN push triggers nothing. An App-pushed tag fires on: push: tags natively, so:

• the dispatch step is deleted
• release-binary.yml keeps one trigger, the obvious one
• mint#22's "two paths to the same outcome, document it loudly or it becomes the next stale record" problem never arises — there is one path

B is less machinery in the resulting system.

It is better attestation, not just narrower authorization. A capability-named broker entry is minted against job_workflow_ref — the credential is bound to reviewed, pinned code on protected main. That binds the capability to the program, which is a stronger form of the property mint#22 is arguing for than "the repository's Actions actor may create tags", where any workflow with contents: write inherits it.

The argument against, stated properly

With the dispatch removed, the App token is being used to make the push trigger downstream work. That is, plainly, what mint#22 rejected:

Not "give the workflow a PAT or App token so the push looks human."

An earlier framing in this issue drew a line between "authorization" and "triggering" to sidestep that. Under B as decided, the line does not hold — this is triggering.

The disagreement is with the premise rather than the conclusion. mint#22's objection is that such a token "reintroduces the standing credential the whole design exists to remove" and makes provenance "worse than the laptop tag it replaces". Both hold for a PAT, and for an App token minted from a PEM in repo secrets. Neither holds for a broker mint:

• Not standing. Short-lived, OIDC-gated; the App's key lives behind the broker, not in this repo. (Contrast release-binary.yml still mints its App token from the PRX_FORGE_APP_PRIVATE_KEY PEM; version.yml moved to the broker #1072 — release-binary.yml still reads PRX_FORGE_APP_PRIVATE_KEY. That is the standing credential mint#22 is right about, and it is in this repo today.)
• Not worse provenance. That claim assumes a general-purpose App identity. A capability-named entry pinned to one workflow attributes more precisely than a human's signing key, not less.

This is a real divergence from a merged design decision in another repo, so it should be argued there rather than quietly diverged from. Raised on mint#22.

Consequences for this repo

1. Infra dependency: a capability-named broker entry pinned to release-cut.yml — same shape as /github/forge-version (version.yml) and front-desk-claim (claim-ticket.yml). Not a change that can be made in this repo.
2. Delete the dispatch step from release-cut.yml when the App push lands, or release-binary.yml runs twice — once from the push, once from the dispatch.
3. Sequencing: release-binary.yml still mints its App token from the PRX_FORGE_APP_PRIVATE_KEY PEM; version.yml moved to the broker #1072 first is worth considering. It moves release-binary.yml off the PEM onto the broker, proving the pattern here for a second consumer before a release depends on it.
4. If tag rules are later introduced, they are added to .github-private org/rulesets/ as code, naming the App — not applied by hand.

Still true from the correction above

No committed ruleset targets tags today, and the 403 seen from a session is best explained by the session git proxy. So Option A would probably work right now with no infra change at all. B is the better destination; A is available if v1.0.0 needs to ship before the broker entry exists. That is a scheduling choice, not a reversal of this decision.

---

Generated by Claude Code