ci(secret-scanner): pin reusable to standards@516bd724 (no-op today, correctness later)

[hyperpolymath]

What this changes

One line in .github/workflows/secret-scanner.yml:

-    uses: hyperpolymath/standards/.github/workflows/secret-scanner-reusable.yml@bd914b34349a8ad78ba1c4e9919b60b1c9b8bd39
+    uses: hyperpolymath/standards/.github/workflows/secret-scanner-reusable.yml@516bd724d2f4820c822d94af2b3b523dd0a87ae3

This is a NO-OP today, and I want to be precise about why

Not "low risk" — measurably zero behavioural change, for a reason worth writing down.

bd914b34 and 516bd724 are byte-identical except one line, in the step that fetches the
estate gitleaks baseline:

ref: ${{ github.job_workflow_sha }}   # bd914b34 — NOT a valid context
ref: ${{ job.workflow_sha }}          # 516bd724 — correct

(github has workflow_sha, not job_workflow_sha. An unknown property evaluates to the empty
string rather than erroring, so actions/checkout silently falls back to the default branch.)

That line sits inside a step this repository never reaches. The reusable stages the estate
baseline in two places:

	gen 1 (L161-188)	gen 2 (L214-255)
gate	none — always runs	if: referenced == 'true'
ref	ref: main (hardcoded)	the line above

referenced is true only when the repo has a .gitleaks.toml carrying
path = ".gitleaks-estate.toml". This repository has no .gitleaks.toml, so gen 2 is skipped
and gen 1 serves it — on both SHAs, identically.

And 516bd724 is hyperpolymath/standards' current main HEAD (verified 2026-09-04), so
gen 1's ref: main is already resolving to exactly this commit. Same reusable, same baseline,
same result.

Both SHAs also arm exactly the same jobs — gitleaks, rust-secrets, shell-secrets — so
nothing new runs. The AsciiDoc mirror pass is present in both; this repo's .adoc files are
already being scanned.

Then why land it

1. It stops being a no-op the moment this repo gains a .gitleaks.toml. At that point gen 2
   activates, and on bd914b34 it would pull the baseline from a moving branch instead of the
   pinned SHA. Fixing the pin before that is free; fixing it after means debugging a gate that
   changed without a diff.
2. A pin should mean what it says. The comment above that line in bd914b34 claims "a caller
   pinned to an old SHA gets that SHA's baseline, not a moving one" — which was not true of the
   code beneath it.
3. Three pin generations across six sibling repos is itself the defect. This is part of
   converging them.

What this does NOT fix

Gen 1 hardcodes ref: main, so a consumer without a .gitleaks.toml — including this one —
still re-derives its allowlist from standards' moving default branch on every run, whatever
SHA it pins. The job.workflow_sha fix only ever reached the gen-2 path. That is an upstream
one-line change in hyperpolymath/standards and is tracked separately; it is out of scope here
and this PR does not claim to address it.

Verification

• 516bd724 confirmed = standards main HEAD: gh api repos/hyperpolymath/standards/commits/main -q .sha
• Two-generation staging traced by reading secret-scanner-reusable.yml@516bd724 lines 150-295
  directly, not inferred from another repo's CI log (a repo with a .gitleaks.toml takes the
  other branch and would prove nothing about this one).
• No actions.lock in this repository, and the lockfile format does not track reusable-workflow
  uses: lines regardless — so no same-PR lock regeneration is required.
• Assertion, not assumption: the Secret Scanner run on this PR must reach the same verdict as
  the last run on main. If it differs, this analysis is wrong and the PR should be held.

[gitar-bot]

Important

You are using the Gitar free plan. Upgrade to unlock code review, CI analysis, auto-apply, custom automations, and more.

_Gitar

[hyperpolymath]

Confirmed in CI — and the green is load-bearing

Run 33824031713, job 100872727996.
All three jobs pass (gitleaks, rust-secrets, shell-secrets). Real output:

No reference to .gitleaks-estate.toml; nothing staged.
Using estate baseline allowlist.
INF scan completed
INF no leaks found
Scanning 29 AsciiDoc file(s) via mirror.
Using estate baseline allowlist.
INF no leaks found
No leaks found in AsciiDoc files.

Three things this proves, none of which "the check is green" would have:

1. A real config was loaded. Using estate baseline allowlist. is the branch taken when a
   repo has no .gitleaks.toml — the scan ran against the 171-line estate baseline, not
   against nothing. A missing config would have produced FTL failed to load extended config.
2. Real files were scanned. 29 AsciiDoc file(s) via mirror — matching the local
   measurement exactly.
3. The two-generation staging behaves as analysed. nothing staged and
   Using estate baseline allowlist appear together, which is only consistent if the
   reusable's ungated first staging block supplied the file while the second (gated on
   referenced == 'true') correctly skipped. Worth stating because a proposal existed to
   delete that first block as dead code — it is not dead, and deleting it would have broken
   every consumer without a .gitleaks.toml.

Merge posture

Self-merged under the standing --admin grant, noted here for the audit trail.

This is CI-workflow work, not an allowlist and not a cryptographic change: no
.gitleaks.toml is added and nothing is exempted repo-locally. It moves the repo onto the
shared estate baseline and changes no finding (measured 0 → 0, with a positive control proving
the gate can still fail). By contrast metadatastician/cerro-torre#35, which does land an
allowlist, remains owner-gated and unmerged.