content.yml checks out string-audit unpinned, so this repo's content gate floats onto whatever main says

[bdelanghe]

The problem

.github/workflows/content.yml:21-24 checks out the gate with no ref::

      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
        with:
          repository: bounded-systems/string-audit
          path: string-audit

That resolves to string-audit's default branch at run time. The action itself is correctly SHA-pinned; the repository being checked out is not, so the gate's rules — the thing that decides whether this repo's content passes — change underneath this workflow whenever string-audit merges anything.

The org convention is to pin, and the sibling consumer already does: content-catalog's aggregate.yml pins ref: 59c38668e822410c989c614557f03eb30218402c (bounded-systems/content-catalog#18).

It already floated, and this time benignly

string-audit#73 changed the grounding matcher — namespaced-or-flat acceptance, and word-boundary rather than substring matching. This workflow picked that up with no change on this side and no review.

It happens to still pass: this repo's gate reads content/grounding.json directly as a flat, non-namespaced file, which #73 deliberately kept accepting, and its output is byte-identical. So this is a near miss, not an incident — but "the gate changed and we found out by it still being green" is the wrong way to learn it.

Worth being precise about what a float can do here: brand.thesis is claim-typed (string-audit's catalog.mjs:14 infers type from the key — /thesis|statement|claim/i), so a future change to grounding semantics can flip this repo red or, worse, quietly stop enforcing a claim, without a commit on this side.

Fix

Add a ref: pinned to a SHA, and bump it deliberately:

        with:
          repository: bounded-systems/string-audit
          ref: <sha>  # string-audit#NN (what changed)
          path: string-audit

59c38668e822410c989c614557f03eb30218402c is the current head of that work and is what content-catalog pins, so pinning here too puts both consumers of the gate on the same rules — which seems worth more than each floating independently.

Not filed as a PR

Choosing the pin is a judgment about which gate version this repo wants, and bumping it is a recurring cost someone owns. Raising it rather than deciding it. Found while investigating content-catalog#14; unrelated to that fix beyond sharing the dependency.