[luisleo526]

Summary

Moves the release hub's credential and release jobs to the isolated pf-ci-release runner class (owner rulings CI-HOSTED = B and REL-HOSTED = B: no hosted exception for release jobs), makes every job on that class reachable only from a run at refs/heads/main, and makes publication an explicit operator step.

1. Runner class. 13 jobs across eight workflows now use the literal ["self-hosted","pf-ci","pf-ci-release"], no hosted fallback: facts-descriptions (descriptions), facts-fanout (web, license), handle-upstream (bump), publish (prepare, publish, failure-report), release-finalize (finalize, notify-consumers), release-receipts (plan, verify), release-reconcile (producers), release-rollback (restore). Strict runner and inventory pins are in tests/test_release_workflows.py.
2. Trigger conversion (L6 approved 2026-10-21 00:20). publish.yml no longer starts on a v* tag push. It is workflow_dispatch on main with one required tag input. A first, read-only tag-guard job (contents: read, no secrets, no job-level if) refuses unless the run is on refs/heads/main, validates the tag against ^v[0-9]+\.[0-9]+\.[0-9]+(-rc\.[0-9]+)?$ before any git command, fetches tags and main with full history, resolves the tag as refs/tags/<tag>^{commit} (never a short name), and requires that commit to be an ancestor of refs/remotes/origin/main (named in full: git resolves a short origin/main against refs/tags/ first, so a tag of that name on a side commit would otherwise pass). It outputs the verified 40-hex SHA. Every later job needs it and checks out that SHA with persist-credentials: false; the SHA also names the candidate image and feeds the revision/build arguments and the release bindings. A failed or skipped guard blocks finalization, and failure-report refuses before any checkout.
3. No workflow dispatches publish.yml (L6 route (a), 2026-10-21 01:34). A dispatch made with GITHUB_TOKEN runs as github-actions[bot], which the org's authz job refuses, and a dispatch with the App token depends on the App's selected repositories, which are not readable today. So handle-upstream.yml pushes the tag and prints the operator command (a ::notice, or a ::warning on the republish path, and the step summary); its App token keeps contents: write and loses actions: write. Tests pin that no workflow file dispatches publish.yml in any form.

release semantics change: a tag push no longer starts this workflow, and an upstream release no longer starts publication by itself.

OPERATOR STEP. A user with write access, after the tag exists on main and handle-upstream is green:

gh workflow run publish.yml --repo pineforge-4pass/pineforge-release --ref main -f tag=<vX.Y.Z or vX.Y.Z-rc.N>

The same command replays a release. The tag must exist and sit on main; a tag push alone publishes nothing. The republish recovery path of the handler now only prints this command.

Trigger audit: every workflow that uses pf-ci-release

No tag-push, release-event or workflow_run start remains. push appears only limited to branches: [main].

Workflow	Trigger declarations (file:line)
facts-descriptions.yml	:4 push with branches: [main] at :5; :13 workflow_dispatch; :20 schedule
facts-fanout.yml	:4 push with branches: [main] at :5; :8 workflow_dispatch; :15 schedule
handle-upstream.yml	:23 repository_dispatch
publish.yml	:17 workflow_dispatch with required tag; main-ref checks in tag-guard and prepare
release-finalize.yml	:4 workflow_call (inherits the guarded caller's main ref); :9 workflow_dispatch; :15 push with branches: [main] at :16; :18 schedule
release-receipts.yml	:4 repository_dispatch; :6 workflow_dispatch; :7 schedule
release-reconcile.yml	:4 workflow_dispatch; :5 schedule
release-rollback.yml	:4 workflow_dispatch

repository_dispatch and schedule run at the default branch; workflow_dispatch runs at the selected ref, which tag-guard and prepare require to be main. No timeout-minutes is added (owner #827). The runner group admits all of these workflows at refs/heads/main (laneboss).

Tests

tests/test_release_workflows.py extracts the real tag-guard run: script and executes it under bash against temporary real git repositories with literal expected results: a tag on main passes and the output SHA equals that commit; an annotated tag outputs the peeled commit; a bad pattern, a newline-bearing tag, a missing tag, a tree tag, a side-branch tag and a non-main ref all fail with the exact ::error:: text and emit no SHA. The fixture puts decoy tags named origin/main, main, heads/main and remotes/origin/main on the side commit, and the clone gets local branches named like tags (a branch named like a missing tag is refused; a branch named like an honest tag outputs the tag's commit). Mutants that remove the pattern, existence or reachability check, restore the short origin/main, or resolve the tag by its bare name must fail the table. Text pins and mutants cover job dependencies, SHA checkouts, shell interpolation, the failure refusal, and that no workflow file dispatches publish.yml (CLI, API and github-script forms) and that the App-token step has no permission-actions.

Verification record

• First run of the suites on the pool (PR ci: move release jobs to pf-ci-release and publish only from verified tags on main #91 at f908354f3): all checks green after the README pair-rule pin was moved with its text. Later heads add the decoy-ref fix, the route-(a) removal and a merge of main (release-receipts: discover scheduled evidence from repository artifacts (fix the red schedule at the source) #90); the PR's CI on the final head is the proof.
• TypeSafe diff guards (raw files kept): whole diff at 2afd7ef92 PASS; decoy-ref commit PASS; route-(a) commit PASS (lh 0.51, sc 0.44, dl 0.16, dw 0.51).
• Nothing from this repository runs on the authoring machine; do not merge before CI is green.

🤖 Generated with Claude Code