The catalogue pull request the publication run opens never gets its required checks without a hand

[iderex]

The publication run opens the catalogue pull request with the workflow token, and a pull request opened that way triggers no pull_request workflow, so the twelve required checks never arrive and the pull request stays BLOCKED until a hand closes and reopens it. That hand was mine twice tonight, on #164 and #166; the run itself was green both times.

$ gh pr view 166 --json mergeStateStatus,statusCheckRollup --jq '.mergeStateStatus+" checks="+(.statusCheckRollup|length|tostring)'
BLOCKED checks=0
$ gh pr close 166 && gh pr reopen 166
$ gh pr view 166 --json mergeStateStatus --jq .mergeStateStatus
CLEAN

A catalogue that waits for a hand is a catalogue that is stale until somebody notices, which is what the daily run exists to prevent. The run has to produce the checks itself: either it runs the gate legs on the branch it pushed and reports them as check runs on that head with the token it already holds, or it opens the pull request through a route that does trigger the workflows without a second credential in this tree. Done when a catalogue pull request opened by the scheduled run reaches CLEAN with no hand on it, shown by one such run.

[iderex]

One of the two routes this asks for is closed by the platform, and the other one is a decision about the ruleset rather than a repair. Here is the reading behind both.

The set is nineteen contexts now, not twelve, and every one of them is pinned to the Actions app:

$ gh api repos/Flowfin/hub/rulesets/20544694 \
    --jq '[.rules[] | select(.type=="required_status_checks") | .parameters.required_status_checks[]] | length'
19
$ gh api repos/Flowfin/hub/rulesets/20544694 \
    --jq '[.rules[] | select(.type=="required_status_checks") | .parameters.required_status_checks[].context] | .[]'
Gate: build
Gate: test
Gate: format
Gate: tests-reach-nothing
Gate: no-hardcoded-names
Gate: site-fetches-nothing-outside
DCO sign-off
dependency-review
Reject Trojan Source Unicode
Audit workflows (zizmor)
Gate: colour-stands-off-every-surface
Gate: coverage
Gate: editorconfig
Gate: install-address-is-answered
Gate: page-matches-the-token-file
Gate: pr-hygiene
Gate: site-declares-its-language
Gate: site-links-resolve
Code scanning (Go)

Run 2026-09-05.

The second route does not exist

There is no route that opens the request with the run's own token and triggers the workflows. GitHub states the rule and names its only exceptions:

With the exception of workflow_dispatch and repository_dispatch, other GITHUB_TOKEN-triggered events do not create workflow runs at all.

Read 2026-09-05 from the events reference, under pull_request. So closing and reopening the request from inside the run does nothing either, because a close and a reopen made with that token are two more events of the kind the sentence excludes. The hand in this issue's evidence is not incidental to the repair; it is the whole of what the platform is asking for.

push is in the same set, so the branch the run creates through the API starts nothing either, and that is why Gate: * and Reject Trojan Source Unicode are absent even though both workflows declare push: branches: ["**"].

The first route splits into two different things

"Report them as check runs with the token it already holds" is one sentence covering two, and only one of them is admissible.

A run that posts a check run named Code scanning (Go) without having run CodeQL manufactures a green for an analysis nobody did. That is not available here at any price.

A run that executes the jobs and reports what they said is admissible, and the only way it can execute them is the exception quoted above: dispatch each workflow at the pushed branch, with actions: write added to the publication job. Four of the six workflows would need workflow_dispatch added and nothing else - gate.yml, unicode-guard.yml, zizmor.yml, code-scanning.yml. The remaining two take their subject from the pull-request event and have no subject without one:

• dco.yml walks github.event.pull_request.base.sha..head.sha.
• dependency-review compares the pull request's diff. The action offers base-ref and head-ref, documented as "only used for event types other than pull_request and pull_request_target".

Both can be given inputs. What that costs is the thing to decide: a required check whose subject is named by whoever dispatched it is weaker than one whose subject is named by the platform, and once DCO sign-off accepts a base from its caller, a green on that context stops being evidence that the commits under review were signed off. That reaches every pull request on this board, not only the catalogue one.

What has to be decided, and by whom

Three answers are open and each one costs something different:

1. Make the six workflows dispatchable and hand two of them their subject. The catalogue request goes green on its own, and the ruleset gets a second route to a green on every branch.
2. Admit a second credential - an app installation token whose events do trigger workflows. This issue excludes it in its own body; excluding it is what leaves 1 and 3.
3. Keep the hand, and make the standing request's body say so louder than it does. internal/carry.Body already says it, and .github/workflows/publish.yml already carries the trap in its header comment.

Which of those the board takes is a judgement about the ruleset's posture rather than about this run, so I have not started it. The reading above is what I had to establish before saying that, and it is here so the next person does not pay for it again.

Done-when is untouched by any of this: it asks for one scheduled publication run whose request reaches CLEAN with no hand on it, and nothing short of that closes this.

[iderex]

Waiting for: decision - whether the six required-check workflows become dispatchable, or a second credential is admitted

What this waits on

decision - whether the six required-check workflows become dispatchable, or a second credential is admitted

A request opened with the run own token triggers nothing, which GitHub states with workflow_dispatch and repository_dispatch as its only exceptions, so the route the issue names second does not exist. What is left is dispatching the six workflows at the pushed branch, which asks dco.yml and dependency-review to take their subject from an input rather than from the pull-request event and so widens where a green on those contexts can come from, or admitting a credential whose events do trigger workflows, which the issue body excludes. Both change the ruleset posture rather than this run, and the reading behind them is in the issue.

[iderex]

Decided (2026-09-06): the run gets an identity whose events trigger workflows, a GitHub App installed on this repository with an installation token minted per run; the six required workflows stay as they are.

Making the workflows dispatchable would ask dco.yml and dependency-review to take their subject from an input rather than from the pull request, which widens where a green on those contexts can come from, and it would have to be repeated for every workflow the ruleset ever adds. An installation token is the route GitHub documents for exactly this case: the App is owned by this organisation, installed on this repository only, with contents: write and pull_requests: write and nothing else, its private key is an Actions secret here and never in the tree, and the token the run mints from it lives for one hour. A pull request opened with that token triggers the same nineteen checks a hand-opened one does, and the ruleset does not change.

What the tree does once the App exists: the publication run mints the token with the pinned actions/create-github-app-token, opens the catalogue pull request with it, and its own commit keeps the sign-off the DCO check reads. Done when one scheduled run opens a catalogue pull request that reaches CLEAN with no hand on it, pasted from that run. Creating the App and storing its id and key is the account holder's act, and the label stays until it is done.

[iderex]

Freed: the decision comment of 2026-09-06 on this issue chooses a GitHub App as the identity of the publication run; the App exists with its secrets, and #171 carries the workflow change, so nothing here waits on a decision any more

Removing blocked-on-decision

Answered by #167, which is open.

the decision comment of 2026-09-06 on this issue chooses a GitHub App as the identity of the publication run; the App exists with its secrets, and #171 carries the workflow change, so nothing here waits on a decision any more

The cited source is OPEN and carries no done-condition asking for a decision, so this clearing rests on what it says rather than on its state.

[iderex]

#172 landed at 00:49 and the first run after it, started by hand, went green with the publisher's token minted (run 33996982982, every step success). It opened no request, because the catalogue it built matched the one served: nothing had released since the last publication. So the Done-when is not yet measured. It is measured by the next run that has something to carry, which is the next plugin release or the next change to a declared source; that run's request is read for CLEAN with no hand on it and pasted here. Until then this stays open and needs nothing.