Submodule pins drift to orphaned commits — re-pin done; harden against recurrence

[hyperpolymath]

Context

membership-integrity (in .github/workflows/anchor-drift.yml) was failing on main because member submodule gitlinks pointed at commits that no longer exist on the member remotes — orphaned when those member repos' histories were rewritten (squash-merged PRs produce new SHAs). The job aborted with fatal: remote error: upload-pack: not our ref <sha>.

What was fixed

PR #13 (merged) re-pinned the 2 dangling in-scope members to each member's current origin/main HEAD so the recorded pins are reachable again:

k9-validate-action, pandoc-k9

The same PR also switched the submodule-resolution step to a full (non-shallow) fetch so non-tip pins resolve. membership-integrity is now green.

Residual risk / why this recurs

Static gitlink pins re-orphan every time a member repo squash-merges or force-pushes, so the gate will silently go red again on the next member history rewrite. members/tooling/k9iser is outside the current automation scope (it couldn't be re-pinned in the session that fixed the others) but resolved cleanly in CI.

Proposed (ties into #7 — member rollout)

• Decide a drift-resistant pin policy — e.g. pin members to tags/releases instead of branch-tip commits, or add a scheduled job that re-pins members/* to current main and opens a PR, or treat membership-integrity as the early-warning gate (it now catches this on every PR/push).
• Track the k9iser pin under whoever owns that repo.

Refs #7.

[hyperpolymath]

RULING D200 (2026-09-30T14:25Z) · scope: repo · basis: applied-unless-struck (D113; owner approved the full table, none struck)

Pin submodules to reviewed SHAs and gate pin changes via membership-integrity with full fetch.

surface: hyperpolymath/standards#787 (comment)

The open question in this issue is answered by the ruling above; future agents should act on it rather than re-ask.