// SPDX-License-Identifier: CC-BY-SA-4.0
// SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell (hyperpolymath)

= Central Reusable actions/cache SHA Corruption — 2026-06-21
:toc:
:toclevels: 2
:source-highlighter: rouge
:icons: font

Companion machine-readable manifest: `audit-hypatia-cache-sha-corruption-2026-06-21.a2ml`.
Sibling to `audit-hypatia-pin-orphan-2026-05-27.adoc` — a *different* SHA-pin
failure class on the same two reusables (that one was the orphaned
`@<standards-sha>` reference to the reusable; this one is a corrupt
third-party action SHA *inside* the reusable).

== Summary

From 2026-06-20/21 the estate-wide `scan / Hypatia Neurosymbolic Analysis`
job failed at the *"Prepare all required actions"* stage — before any scan
step ran — with:

----
Unable to resolve action `actions/cache@d4373f267a887d77f9eb0683a479ec60b1fe5b2b`
(unable to find version d4373f267a887d77f9eb0683a479ec60b1fe5b2b)
----

The corrupt SHA was **not** present in any consumer workflow. It was pinned
once, centrally, in the two reusable workflows that every estate repo calls:

* `.github/workflows/hypatia-scan-reusable.yml`
* `.github/workflows/governance-reusable.yml`

Observed failing on `nextgen-databases#41`, `KnotTheory.jl#29`,
`nextgen-typing#67` (and, per PR #394, `wokelangiser`).

== Root cause

`d4373f267a887d77f9eb0683a479ec60b1fe5b2b` does not correspond to any
`actions/cache` ref. It is a corruption of v4.2.2's real commit
`d4323d4df104b026a6aa633fdb11d772146be0bf` — the version comment read
`# v4.2.0`, but the hash matched neither v4.2.0 nor v4.2.2. GitHub Actions
resolves a `uses:` SHA as a commit; an unknown SHA fails the whole job at
parse stage, so no consumer scan ever started.

== Verification

Upstream resolution via `git ls-remote https://github.com/actions/cache`:

[cols="2,3,1", options="header"]
|===
| SHA | Upstream ref | Resolves?

| `d4373f26…` (the corrupt pin)              | (none)                     | ✗ bogus
| `d4323d4d…` (v4.2.2 — the likely typo source) | `refs/tags/v4.2.2`      | ✓
| `1bd1e32a…` (the repair pin)               | `refs/tags/v4.2.0`         | ✓
| `0057852b…` (estate "most common")         | `refs/tags/v4` + `v4.3.0`  | ✓
| `27d5ce7f…` (estate, used across hypatia)   | `main` + `v5` + `v5.0.5`   | ✓
|===

`git grep d4373f267a887d77f9eb0683a479ec60b1fe5b2b` across standards and
hypatia → zero matches after the fix.

== Fix — standards#394 (merged 2026-06-21T10:52Z, commit `d72fe5a`)

Both reusables re-pinned, preserving the documented version:

[source,diff]
----
-        uses: actions/cache@d4373f267a887d77f9eb0683a479ec60b1fe5b2b # v4.2.0
+        uses: actions/cache@1bd1e32a3bdc45362d1e726936510720a7c30a57 # v4.2.0
----

`1bd1e32a…` is the genuine immutable `v4.2.0` commit, so the `# v4.2.0`
comment is now accurate. This is a surgical hash repair, not a version bump
to the moving `v4` tag.

== Propagation caveat — necessary but not yet sufficient

Consumers do **not** pin these reusables to `@main`. They pin a specific
`standards` commit SHA, e.g.:

----
uses: hyperpolymath/standards/.github/workflows/hypatia-scan-reusable.yml@5eb28d7d…   (hypatia itself)
uses: hyperpolymath/standards/.github/workflows/governance-reusable.yml@861b5e91…     (most consumers)
----

Because the repair landed as a *new* `standards` HEAD (`d72fe5a`), every
consumer still pinned at a pre-#394 SHA keeps dereferencing the broken cache
pin until it is re-enrolled to a post-#394 SHA. This is exactly what
`scripts/check-workflow-staleness.sh` reports — it fails any consumer whose
pinned SHA != current standards HEAD ("Workflow pins Hypatia reusable before
cache/baseline-delay fix. Refresh to current standards SHA.").

Therefore the post-#394 `governance / Check Workflow Staleness` red is
**expected drift**, not a new defect: it is the signal that the estate
re-enrollment pass (gitbot-fleet `enroll-repos`, repinning consumers to
`d72fe5a` or later) is still pending. Re-enrollment is the propagation
mechanism; until it runs, an affected consumer sees both the cache failure
(if its pinned SHA predates #394) and the staleness failure.

== Companion findings — out of scope (central), recorded for the backlog

These surfaced on `nextgen-databases` alongside the central failure. They are
**repo-internal**, pre-existing, and not addressed by #394:

. *K9 pedigree validation.* `verisimdb/connectors/test-infra/deploy.k9.ncl`
  fails "Pedigree block missing 'name'". In `k9-svc/pedigree.ncl`,
  `Metadata.name | String` is the only metadata field with no `default`, so
  it is mandatory. Fix: add `metadata.name`; per the canonical
  `k9-svc/pandoc/container/deploy.k9.ncl` sample, ideally also
  `metadata.version` + `validation.pedigree_version` and a leash level —
  `trust_level`/`security_level` ∈ `'Kennel | 'Yard | 'Hunt` (a
  shell-running `deploy.k9.ncl` is `'Hunt`).
. *Trusted-base reduction policy.* The `governance / trusted-base` job (per
  `docs/TRUSTED-BASE-REDUCTION-POLICY.adoc` + `scripts/check-trusted-base.sh`)
  is red: a soundness-relevant escape hatch in a proof-bearing file in
  `nextgen-databases` is undocumented. Disposition is per-repo — discharge,
  budget (`// TRUSTED:`), axiom (`// AXIOM:`), or a dated debt entry in that
  repo's `docs/proof-debt.md`.

== What this audit does NOT discharge

* The consumer re-enrollment pass (gitbot-fleet `enroll-repos` → repin
  consumers to `d72fe5a`+). Out of scope for standards + hypatia; tracked on
  hypatia#464.
* The two `nextgen-databases` repo-internal findings above. Out of scope
  (that repo); flagged for its maintainers via hypatia#464 / nextgen-typing#69.

== Cross-references

* Fix PR: `hyperpolymath/standards#394` (merged 2026-06-21).
* Estate CI-health umbrella: `hyperpolymath/hypatia#464`.
* "Out of scope — central" list: `hyperpolymath/nextgen-typing#69`.
* Sibling SHA-pin audit: `audit-hypatia-pin-orphan-2026-05-27.adoc`.
