Name the required checks on the default branch

[iderex]

Depends on every check issue in this milestone and in the scaffolding milestone.
Two of those are still open, #12, which lands Analyze (go), and #44:

gh issue list --repo Flowfin/site --state open --limit 200 \
  --json number,title,milestone \
  --jq '.[]|select(.milestone.title=="Quality parity"
        or .milestone.title=="Scaffolding and the gate")|"\(.number)\t\(.title)"'
12	Add code scanning under the check name Analyze (go)
18	Add the LICENSE file once the licence is chosen
44	Mutation testing on the generator
47	Name the required checks on the default branch
62	Add the code of conduct this repository does not have
135	Default branch: Required check names did not succeed

Run 2026-08-23. Of the six, #18 and #62 land a document rather than a check,
#47 is this issue, and #135 reports a run rather than landing one. The
dependency was written here as a description of a set rather than as numbers,
so nothing could follow it and nothing could tell when it stopped being true.

Today nothing is required to merge here, re-taken 2026-08-31 because the paste
that stood here showed three rule types and was undated, and the branch gained a
fourth on 2026-08-28:

gh api repos/Flowfin/site/rulesets/20572614 --jq '[.rules[].type]'
["deletion","non_fast_forward","pull_request","required_signatures"]
gh api repos/Flowfin/site/rulesets/20572614       --jq '[.rules[]|select(.type=="required_status_checks")|.parameters.required_status_checks[].context]'
[]

The fourth rule is the signature one and is the paragraph further down rather
than this one. What this paragraph is about is the rule that is still absent, and
the empty list above is what the last clause of the done condition compares
against.

The pull request rule is in place and asks for zero approvals, so a change can
land with no check having reported at all. Every workflow in the tree could be
red and the merge button would still be green. Until the contexts are named in
the ruleset, the gate is a set of workflows that run rather than a gate.

The contexts to require, once each one exists and has been shown to bite:
build, Reproducible build, Analyze (go), DCO sign-off,
Deterministic PR-hygiene checks, Enforce greppable invariants,
Reject Trojan Source Unicode, Audit workflows (zizmor), prettier,
dependency-review, Package (site) / Build bundle,
Package (site) / Generate SBOM, Static analysis (semgrep).

Every name on that list is either a workflow already in this tree or an issue in
this plan that lands one, and the parity ledger is where the mapping is argued.
A name here with neither behind it is the failure this issue exists to avoid.

Two notes on sequencing. A context named in a ruleset before the workflow
reports it blocks every pull request forever, so each name goes in after its
first green run on a real pull request. And a check that is skipped by a path
filter never reports, which a ruleset reads as never satisfied, so no required
check may sit behind a path filter.

Signature verification and the bypass list belong to the same change, and they
are not the same kind of thing. The empty bypass list is parity, and the value
of having none is that the gate applies to everyone. Signature verification
would have been an addition rather than parity, and it arrived on both branches
before this issue did anything:

gh api repos/Flowfin/jellyfin-plugin-sso/rulesets/18802863 --jq '{bypass:.bypass_actors,types:[.rules[].type]}'
{"bypass":[],"types":["deletion","non_fast_forward","required_status_checks","pull_request","required_signatures"]}
gh api repos/Flowfin/site/rulesets/20572614 --jq '{bypass:.bypass_actors,types:[.rules[].type]}'
{"bypass":[],"types":["deletion","non_fast_forward","pull_request","required_signatures"]}

Run 2026-08-30. So there is no difference for the ledger to record in either
direction, and what is left of this clause is the empty bypass list, which both
branches already carry. The paste that stood here showed the target with four
rule types and carried no date; where that was found is the comment of
2026-08-30.

Done when

The command above prints required_status_checks among the rule types, the
context list matches the names above, bypass_actors is empty, and a pull
request with one failing check cannot be merged.

[iderex]

The context list in the body is one name short of what reports, and the missing
one is a check that already refuses.

Static analysis (semgrep) landed with #45 and is not among the twelve names
above. It reports on every pull request and on every push to main:

gh api repos/Flowfin/site/commits/06cb59cec5cddd37d27ba2034de8e5a33887113b/check-runs \
  --jq '[.check_runs[].name] | sort | .[]'
Analyze (go)
Audit workflows (zizmor)
Enforce greppable invariants
Package (site) / Build bundle
Package (site) / Generate SBOM
Reject Trojan Source Unicode
Reproducible build
Scorecard analysis
Static analysis (semgrep)
build
prettier

Run 2026-08-11. It also meets the condition this issue puts on a name before it
goes in, which is that the check exists and has been shown to bite: run
31475636799 refused a commit carrying one instance of each shape its rules name,
and runs 31475222126 and 31476053436 are the neighbours that did not.
docs/near-miss.md carries the pair.

Two names in that output are not candidates and are worth saying so about rather
than leaving for somebody to work out. Scorecard analysis reports on a
schedule, so requiring it would block every merge, which is the sequencing note
already in the body. The code scanning uploads report under the tool's own name
rather than a job name, which is why CodeQL, zizmor and Semgrep OSS appear
on a pull request and not here.

Nothing else about the issue moves. The rule types on the branch are unchanged:

gh api repos/Flowfin/site/rulesets/20572614 --jq '[.rules[].type]'
["deletion","non_fast_forward","pull_request"]

Run 2026-08-11.

[iderex]

The reading above was taken on a commit on main, and three of the names it does
not carry only ever report on a pull request head. Read on a head instead, every
name this issue lists reports and succeeds, so the condition the body puts on a
name before it goes into the ruleset is met for all of them.

That commit is the merge commit of a pull request rather than its head:

gh api repos/Flowfin/site/commits/06cb59cec5cddd37d27ba2034de8e5a33887113b/pulls \
  --jq '[.[]|{number, merge_commit_sha, head:.head.sha}]'
[{"head":"8eda873c9dc4e523bb655a1bf7a6d9357130ffeb","merge_commit_sha":"06cb59cec5cddd37d27ba2034de8e5a33887113b","number":140}]

and three of the candidates are declared under a pull request trigger alone:

for f in dco pr-hygiene dependency-review; do
  printf '%-18s' "$f"
  sed -n '/^on:/,/^[a-z]/p' .github/workflows/$f.yml | grep -E '^  [a-z_]+:'
done
dco               pull_request:
pr-hygiene        pull_request:
dependency-review  pull_request:

So their absence from that list is the commit it was read on rather than a check
that does not report.

On the head of the most recently merged pull request all thirteen are there and
all of them are green:

head=$(gh api 'repos/Flowfin/site/pulls?state=closed&base=main&sort=updated&direction=desc&per_page=100' \
  --jq '[.[]|select(.merged_at!=null)]|sort_by(.merged_at)|reverse|.[0]|[.number,.merged_at,.head.sha]|@tsv')
echo "$head"
167	2026-08-16T20:30:16Z	a7d3b31690dc219fc310550b6ab66792b73d719d
gh api "repos/Flowfin/site/commits/$(echo "$head" | cut -f3)/check-runs?per_page=100" \
  --paginate --jq '.check_runs[]|"\(.name)\t\(.conclusion)"' | sort -u
Analyze (go)	success
Audit workflows (zizmor)	success
build	success
CodeQL	success
DCO sign-off	success
dependency-review	success
Deterministic PR-hygiene checks	success
Enforce greppable invariants	success
Package (site) / Build bundle	success
Package (site) / Generate SBOM	success
prettier	success
Reject Trojan Source Unicode	success
Reproducible build	success
Semgrep OSS	success
Static analysis (semgrep)	success
zizmor	success

Scorecard analysis is absent from that head and present on the earlier one,
which is the schedule the comment above already names. CodeQL, Semgrep OSS
and zizmor are the tool names the same comment rules out.

The other sequencing note in the body is that no required check may sit behind a
path filter. Nothing in the tree carries one:

grep -n -E '^\s*(paths|paths-ignore):' .github/workflows/*.yml; echo "exit=$?"
exit=1

All run 2026-08-16 at 9fcaa0d.

So both conditions this issue puts on a name hold for every name on the list, and
what the done condition still waits on is the rule itself:

gh api repos/Flowfin/site/rulesets/20572614 --jq '[.rules[].type]'
["deletion","non_fast_forward","pull_request"]

Run 2026-08-16.

[iderex]

The name the reading of 2026-08-11 found missing is in the list now

That reading says the context list in this body is one name short of what
reports, and that the missing one is a check that already refuses. The list still
carried twelve names. I have put Static analysis (semgrep) into it, so the done
condition here compares against the set that reports rather than against one name
fewer.

It is the same class as two names already on the list rather than one of the tool
names the same reading rules out. All three are job names declared in their
workflows:

grep -n '    name: ' .github/workflows/semgrep.yml .github/workflows/codeql.yml .github/workflows/zizmor.yml | head -3
.github/workflows/semgrep.yml:34:    name: Static analysis (semgrep)
.github/workflows/codeql.yml:42:    name: Analyze (go)
.github/workflows/zizmor.yml:41:    name: Audit workflows (zizmor)

Run 2026-08-30 at 951bcb1.

The condition this issue puts on a name before it goes into the rule holds for
all thirteen today, re-taken on the head of the most recently merged pull request
rather than cited from the reading of 2026-08-16:

head=$(gh api 'repos/Flowfin/site/pulls?state=closed&base=main&sort=updated&direction=desc&per_page=100' \
  --jq '[.[]|select(.merged_at!=null)]|sort_by(.merged_at)|reverse|.[0]|[.number,.merged_at,.head.sha]|@tsv')
echo "$head"
215	2026-08-29T11:47:24Z	aab94345cc82ead8ef9d177e0a6e31b8e255330a
gh api "repos/Flowfin/site/commits/$(echo "$head" | cut -f3)/check-runs?per_page=100" \
  --paginate --jq '.check_runs[]|"\(.name)\t\(.conclusion)"' | sort -u
Analyze (go)	success
Audit workflows (zizmor)	success
build	success
CodeQL	success
DCO sign-off	success
dependency-review	success
Deterministic PR-hygiene checks	success
Enforce greppable invariants	success
Package (site) / Build bundle	success
Package (site) / Generate SBOM	success
prettier	success
Reject Trojan Source Unicode	success
Reproducible build	success
Semgrep OSS	success
Static analysis (semgrep)	success
zizmor	success

Run 2026-08-30. Scorecard analysis is absent from that head and CodeQL,
Semgrep OSS and zizmor are the tool names, which is the reading of 2026-08-11
holding rather than being re-argued.

Nothing else moves. The rule on the branch is unchanged and no change to this
tree reaches it, which is what this issue waits on beside the four open issues the
walk names.

[iderex]

Correcting the last line of the comment above, and what re-running it found

That comment ends by saying the rule on the branch is unchanged. It is not, and I
wrote the sentence without running the command under it, which is the defect the
rest of that comment is careful about. The branch carries a fourth rule:

gh api repos/Flowfin/site/rulesets/20572614 --jq '{enforcement, bypass: .bypass_actors, required: [.rules[].type]}'
{"bypass":[],"enforcement":"active","required":["deletion","non_fast_forward","pull_request","required_signatures"]}
gh api repos/Flowfin/site/rulesets/20572614 --jq '.updated_at'
"2026-08-28T14:22:58.455+02:00"

Run 2026-08-30. So required_signatures arrived two days ago, and every reading
on this issue was taken before it: 2026-08-11, 2026-08-16 and the paste in the
body all show three rule types.

The signature paragraph in the body is now wrong in both directions

The body says signature verification is an addition rather than parity, because
the target does not require it either, and pastes the target's rule types with no
date on them. Both halves have moved. This branch requires it, and so does the
target:

gh api repos/Flowfin/jellyfin-plugin-sso/rulesets/18802863 --jq '[.rules[].type]'
["deletion","non_fast_forward","required_status_checks","pull_request","required_signatures"]

Run 2026-08-30. So it is parity rather than an addition, it has already arrived on
both branches, and what the body asks for is a ledger line saying it was added and
why. The why is not readable from any of these commands and I have not guessed at
one.

What the done condition still waits on, unchanged

The rule this issue is about is still absent, and the empty context list beside it
is what the last clause here compares against:

gh api repos/Flowfin/site/rulesets/20572614 --jq '[.rules[]|select(.type=="required_status_checks")|.parameters.required_status_checks[].context]'
[]

Run 2026-08-30. bypass_actors is empty, which is one clause of the done
condition met and read above rather than assumed.

Three tracked documents paste the rule types of one or other of these rulesets and
all four of those pastes now show a set that no longer reproduces. That is a
separate topic from naming the required checks, so it is #217 rather than a change
carried here.

[iderex]

The comment of 2026-08-30 names the paste in the body as one of the readings
taken before required_signatures arrived, and repairs the signature paragraph
further down while leaving that paste as it was. I have re-taken it, dated it,
and put the empty context list beside it so the line the last clause of the done
condition compares against is in the body rather than only in a comment:

gh api repos/Flowfin/site/rulesets/20572614 --jq '[.rules[].type]'
["deletion","non_fast_forward","pull_request","required_signatures"]
gh api repos/Flowfin/site/rulesets/20572614 \
  --jq '[.rules[]|select(.type=="required_status_checks")|.parameters.required_status_checks[].context]'
[]

Run 2026-08-31. Nothing else on this issue moves. The rule this issue is about is
still absent, the bypass list is still empty, and what ends this is still a change
to the rules on the branch rather than to this tree.