Take the two pins the index has published past [#224]

[iderex]

Closed: this branch cannot carry the trailer the DCO gate requires

Superseded by #228, which carries the same one-line change to pins.json with a
Signed-off-by trailer.

The gate on this pull request refused the head for the trailer being absent:

gh pr checks 227 --repo Flowfin/site | grep '^DCO'
DCO sign-off	fail	5s	https://github.com/Flowfin/site/actions/runs/33599436191/job/100149640691

Run 2026-09-02. A trailer is part of the commit message, so adding one to a
commit that is already pushed rewrites the branch, and this project does not
force-push. The correction is therefore pushed under a new name and this one is
closed rather than repaired in place, which costs one branch name and destroys
nothing.

The two heads carry the same tree:

git diff --stat 3692a5a 37782bf ; echo "exit=$?"
exit=0

Run 2026-09-02.

What was wrong, kept rather than removed

Everything below is the body as it stood, so the reason this change was made is
readable here as well as on #228.

---

What was wrong

The newest completed run of Pins on the default branch concluded failure,
and #224 is the entry that records it. What it refused on is two of the four
pins in pins.json sitting behind what the index publishes:

gh run view 33388004039 --repo Flowfin/site --log | sed -n '/Run go run . pins/,/Process completed/p'
pins: 4 declared in pins.json
  prettier: current at 3.9.6, npm says the same
  zizmor: BEHIND, pinned 1.29.0, pypi says 1.30.0
  semgrep: BEHIND, pinned 1.174.0, pypi says 1.175.0
pins: 2 pin(s) are behind their upstream
  golang-image: current at sha256:53eeac89074db483fdf0ab3be1df32bf6e47562263d2d0d6baa7f26acb4957dd, docker-hub says the same
4 pin(s) declared, 4 compared, 2 behind, 0 unresolved.

Run 2026-09-02, elided for length. That run is from 2026-08-31, and the index
has moved once more since: semgrep is at 1.176.0 rather than the 1.175.0 the run
above read.

git checkout 6541274 -- pins.json && go run . pins
pins: 4 declared in pins.json
  prettier: current at 3.9.6, npm says the same
  zizmor: BEHIND, pinned 1.29.0, pypi says 1.30.0
  semgrep: BEHIND, pinned 1.174.0, pypi says 1.176.0
  golang-image: current at sha256:53eeac89074db483fdf0ab3be1df32bf6e47562263d2d0d6baa7f26acb4957dd, docker-hub says the same
4 pin(s) declared, 4 compared, 2 behind, 0 unresolved.
pins: 2 pin(s) are behind their upstream

Run 2026-09-02 against 6541274. Nothing but a change to pins.json clears
that verdict: the comparison reports and never bumps, and it runs on a weekly
schedule, so the refusal stands until somebody writes the versions.

What this does

zizmor moves from 1.29.0 to 1.30.0 and semgrep from 1.174.0 to 1.176.0.
Nothing else in the file changes. Neither entry gains a checksum, because both
are resolved against what the index publishes rather than against the wheel,
which is what each why field already states.

The two versions are read by their workflows out of this file with jq, so
there is no second copy of either to keep in step, and the invariant that
refuses a version written into a workflow step is what keeps it that way. Both
of those workflows run on this pull request, so the check that the new releases
still pass over this tree is made here rather than after the merge.

Why the drift is worth clearing rather than waiting out. The two why fields
name the same failure from two directions: an audit that has stopped
understanding the syntax it audits, and a rule engine release that turns a
pattern which refuses something into one that refuses nothing. Both leave every
run green, so this is the drift with no other witness in this tree.

The means

pins.json and the verb that already reads it. The change is two values in the
file the comparison is written against, so it is decided by the same run that
found the drift, needs no language, runtime or dependency this tree does not
carry, and the claim above carries the command that produced it in both
directions. Writing the versions into the two workflow steps instead would be
refused by the invariant gate, which is the same rule read from the other side.

No second reader

Nothing on this board reviewed this change but the account that wrote it. The
evidence in place of one is the run below and the checks on this pull request,
which include the two tools whose versions this changes.

Closes

Closes #224.

What was run

go run . ci
gate: 7 legs, in order: format, vet, test, build, links, sitemap, invariants
  needs-network was not asked for. Asking costs a request to the public name from whatever machine runs it, and a verdict that moves when somebody else's service does rather than when this tree changes. Ask with: go run ./harness/needs-network
  format: ok, 74 file(s)
  vet: ok
  test: ok, 37 test file(s)
  build: ok, 22 file(s)
  links: every reference that stays inside this site resolves to a file the build wrote
  sitemap: every page the build wrote is listed once, and every entry has a page behind it
  invariants: ok, 39 rule(s) decided, 2 owed and not decided
7 of 7 legs ran. None was skipped.

go run . pins
pins: 4 declared in pins.json
  prettier: current at 3.9.6, npm says the same
  zizmor: current at 1.30.0, pypi says the same
  semgrep: current at 1.176.0, pypi says the same
  golang-image: current at sha256:53eeac89074db483fdf0ab3be1df32bf6e47562263d2d0d6baa7f26acb4957dd, docker-hub says the same
4 pin(s) declared, 4 compared, 0 behind, 0 unresolved.

Both run 2026-09-02 at 3692a5a.