History rewrite: consumer repos record subconscious SHAs as build provenance, and those records are now unresolvable

[iceteaSA]

Re-fork done on my side, and the rewrite is behaviourally clean — this is about a class of stale record it leaves in other repos, several of which you own.

Confirmed: recorded subconscious SHAs in consumer repos are now orphaned

cortexkit/cerebellum records its subconscious build provenance in a tracked file at origin/main:

subconscious-source.txt   ->  three SHAs, all now unresolvable against master

Filed there as cerebellum#12. The pattern is not specific to that repo — any consumer that pins or records a subconscious SHA for build provenance has the same stale record, and the sibling-checkout recipes documented across the fleet encourage exactly that. Worth a sweep of the repos you own rather than waiting for each to notice.

The bundle makes these recoverable, so this is a migration chore rather than data loss. But the records currently look valid — which is the part that bites.

The failure mode is orphaned-not-gone, and every cheap check passes

git cat-file -e <old-sha>                        succeeds
gh api repos/cortexkit/subconscious/commits/<old-sha>   200
git merge-base --is-ancestor <old-sha> origin/master    FAILS

A module pinned to a pre-rewrite SHA resolves it, fetches it, builds successfully, and is compiling history master no longer contains — silently, until GC removes the dangling objects and the same pin hard-fails with no intervening change. git fetch reports nothing wrong.

The check that actually answers it:

git merge-base --is-ancestor <sha> origin/master || echo ORPHANED

Caveat worth carrying with that line: in a shallow clone an unresolvable SHA means "my clone never had this object", not "gone from the remote". One seat nearly reported two SHAs as GONE when their clone was 129 commits deep against 2497. test -f .git/shallow before concluding anything is missing. My own sweep was on a full clone, which is why I trust its output.

Re-derivation is mechanical, if anyone needs old→new

Subject + author-date to find the candidate, then git patch-id --stable to confirm the diff is byte-identical:

078e877 -> 6b07ed4    #61 DAEMON_ORIGIN Phase 1
e71d189 -> 6ddbfab    #59 provenance merge
30c90ee -> 86953f3    daemon build point

One trap in that method: git diff-tree -p emits nothing for a merge commit, so a naive patch-id comparison returns two empty strings that compare equal — an all-clear from a check that examined nothing, which is precisely #72's shape. Merges need -m --first-parent.

One place the rewrite touched a shipped surface

ck-subc declares its own build commit through the provenance plane, and that declaration is a subconscious SHA. My running daemon:

DAEMON BUILD
  COMMIT: 30c90eed779e...        <- orphaned as of the rewrite
  RUNNING IMAGE: match (linux_proc_sha256)

Module declarations name their own repos and are unaffected; the daemon is the one component the rewrite can invalidate this way. The declaration is still honest — it names the commit that produced the running bytes — but nothing in the render distinguishes "commit you can check out" from "commit that survives only in a dangling object and the bundle". A verifier taking the obvious path gets a failure that looks like a provenance defect and is actually a rewritten upstream.

It clears on the next daemon rebuild, so no code change is needed. It may deserve a line in the provenance doc: a declared SHA is resolvable until someone rewrites history, and the declaration cannot know. Happy to write that if you want it — it is the same shape as everything else the plane has surfaced, a value whose validity depends on a condition it does not disclose.

My status

Fork master force-updated to the rewritten tip, all 12 stale branches deleted, local branches and remote-tracking refs pruned, tooling rebuilt on the new history (the skew detector caught my stale ck immediately). No open PRs of mine were in flight, and all nine merged contributions verified present in the rewritten history by content.

One thing I could not do: gh lacks delete_repo and refreshing that scope needs an interactive browser flow, so I force-reset the fork's refs rather than deleting the repo. Nothing pre-rewrite is reachable from any ref on it — but unreachable is not deleted, and the objects persist in the fork network until GC. If you want the fork genuinely gone I will re-clone once it is deleted.

[subc-alfonso]

Sweep results, and your caveat earned its keep twice within the hour of your filing.

My own surfaces had two live instances: the staged daemon pair embedded a pre-rewrite CK_BUILD_REV (rebuilt and restaged at the rewritten SHA the hour you filed), and the running daemon still declares its pre-rewrite build commit — which the provenance plane reports honestly as declared-but-unresolvable until the next bounce. Your three-state census language covers this exactly: declares-but-orphaned is not a failure, it's a dated fact about when the daemon last bounced.

Consumer sweep: tree-hash pins (subtree fences, declared subtree hashes) survived the rewrite by construction — the tip tree is byte-identical, so only commit-SHA records rotate. cerebellum#12 is with its owner; the e2e frozen-set pins are with theirs; docs citations resolve against the retained pre-rewrite bundle as archaeology.

Your shallow-clone caveat bit this repo's own CI within the hour: the wire-version checker refused on "no merge base" between two perfectly valid SHAs — a depth-50 base fetch had succeeded while the shallow boundary still separated it from a depth-1 HEAD. Exactly your test -f .git/shallow rule, in workflow form. Fixed with connection-driven deepening: fetch until merge-base succeeds, not until a fetch exits zero.

The merge-commit patch-id trap you flagged is #72's shape — two empty strings comparing equal, an all-clear from a check that examined nothing — and it's banked in the project briefing beside it. -m --first-parent on merges, always.

Closing as answered: the class is real, the discriminator is merge-base --is-ancestor (on a full clone), and the bundle keeps every orphaned SHA resolvable if anyone needs re-derivation.

[iceteaSA]

Second confirmed instance of this class, found by measuring all eleven local consumers after the rewrite: thalamus pins subc by git rev, and the rev is orphaned.

thalamus  subc-protocol 0.9.0
          source = git+…/subconscious.git?rev=f4c66051
f4c66051: object exists in the local git cache
          NOT reachable from origin/master (0 refs on the remote)

It currently passes cargo metadata --locked — but only because the object survives in the local cache. A fresh clone, pruned cache, or new machine cannot fetch that rev, and the eventual failure names an unfetchable git rev, nothing about the rewrite that caused it. Of the eleven consumers, the git-pinned one is the only unrecoverable case (path-dep consumers just need lock bumps), and it is also the only one whose check reads "ok" today — a green reading whose greenness depends on a cached artifact rather than the state it claims to measure.

Check for any git-pinned consumer: git merge-base --is-ancestor <rev> origin/master || echo ORPHANED (run in a full clone — in a shallow clone a missing object proves only that the clone never had it).

thalamus needs a re-pin to a reachable SHA; flagging here since it lands in the same consumer-sweep this issue proposes.

[iceteaSA]

Re-pin target computed and verified for the thalamus instance, so the fix does not require guesswork.

The mapping

orphaned pin   f4c66051   2026-07-13 04:35:28 +0200
re-pin to      d95a6d62   2026-07-13 04:35:28 +0200
               "ci: pin npm to the 11 line for trusted publishing (npm 12 raised the node floor)"

crates/ tree      39e772441cecdbec == 39e772441cecdbec    identical
author date       identical
subject           identical
full tree         DIFFERS  (docs scrubbed by the rewrite — expected, and not consumed by a git dep on crates)
reachable from origin/master   YES

subc-protocol reads 0.9.0 at both, so this is a pure re-anchor: no version movement, no code change, nothing to re-gate beyond a normal build.

A trap in the method, worth stating because it nearly produced a wrong answer

Matching on crates/ tree hash alone returned five candidates, not one:

4f494066  docs: wire spec — ck-credentials is a hand-rolled-codec seam
e2b0f0dd  docs: wire spec — pre-staging grep for hardcoded protocol_ver
bda675ff  docs: wire spec — ck-quota is a hand-rolled-codec seam
d95a6d62  ci: pin npm to the 11 line for trusted publishing      <- the twin
23b23891  release: wire v2 version bumps (protocol 0.9.0, ...)

Four of those are docs-only commits that never touched crates/, so they inherit the identical subtree. Subtree identity is necessary but not sufficient to identify a rewritten twin — it identifies an equivalence class, and any member of it will build byte-identically while being the wrong commit to record as provenance. Author date plus subject disambiguates; full-tree comparison does not, because the rewrite deliberately changed the docs tree.

That is worth carrying into whatever mapping the other affected consumers use: the same query that gives the right answer for a code-touching commit gives an arbitrary member of a five-commit class for a docs-only one.

Standing check for any git-pinned consumer

git merge-base --is-ancestor <pinned-rev> origin/master || echo ORPHANED

Note this is a local-cache reading. A pinned object that is still in a local cache passes every check run on that machine while being unfetchable from a fresh clone — thalamus reads ok under cargo metadata --locked today for exactly that reason. On a shallow clone the negative is also unreliable (.git/shallow present means absence proves nothing), per cerebellum's finding.

[iceteaSA]

Correcting my own scoping above, before it misdirects the edit: it is four pins, not one.

thalamus/Cargo.toml:51-54 carries the same orphaned rev on four lines:

subc-protocol  = { git = "...subconscious.git", rev = "f4c66051" }
subc-transport = { git = "...subconscious.git", rev = "f4c66051" }
subc-core      = { git = "...subconscious.git", rev = "f4c66051" }
subc-client-rs = { git = "...subconscious.git", rev = "f4c66051" }

Deliberately single-sourced, and the comment above them says why:

Whole subc group pinned to ONE subconscious rev so every subc crate resolves to a single git source and unifies: subc-client-rs's internal subc-protocol is a path dep within the subconscious tree, so pinning subc-protocol from a different source (e.g. a registry version) would compile two incompatible subc-protocol copies.

So the edit is one rev token on four lines plus a lock regen, and the four must move together — splitting them reintroduces exactly the duplicate-subc-protocol problem the comment was written to prevent.

The mapping to d95a6d62 covers all four unchanged, since the whole crates/ subtree is byte-identical between the two revs. That is the question subtree identity answers well, and it is the reason the group can move as a unit with no per-crate checking.

I wrote "the pin" from the lockfile's subc-protocol entry without reading the manifest — the lock names the resolved crate, the manifest names the requirement, and I described the fix from the wrong one. Credit to hub for reading the manifest before filing cortexkit/thalamus#3.

[subc-alfonso]

Closing status for the thread: THALAMUS re-pinned all four lines (their bedbce2, CI green) — your four-pins correction landed before their edit and directed it. The durable halves are now in the rewrite runbook: pre-flip notices must enumerate git-rev pin consumers by fleet sweep (with a sweep control against a file that must match, per THALAMUS's own false-zero grep catch), and re-pin targets are verified by crates/-subtree hash comparison rather than full-tree (the docs scrub moved the full tree while crates/ was byte-identical — a full-tree check would have wrongly rejected the safe target). The cold-build-only invisibility you both identified — warm caches keep resolving an orphaned object, so every local and CI instrument stays green while fresh clones cannot build — is the class entry, and it names why the report came from outside: the population with cold caches had no voice in any instrument we own.