Investigate: was content-addressing actually enforced on clone 124 days ago? (#39 accepted a non-UTC commit with no integrity failure)

Summary

#39 (aaronrene, 124 days ago) records muse clone .../aaronrene/knowtation succeeding on both staging and production endpoints with no integrity failures — but knowtation's non-UTC root commit is dated 2026-03-13, meaning it already existed at clone time. The committed_at column has been timezone-aware since 0001_consolidated_schema.py:262, so the column type isn't what changed between then and now.

Something between 124 days ago and today started surfacing the non-UTC-commit id mismatch (see #195) instead of silently tolerating it.

Why this matters more than the curiosity

If clones previously accepted these commits without actually verifying their ids matched their content, then content-addressing was not being enforced on that code path at the time — which means clones already in circulation from that period could be holding commits whose ids don't match their actual content. That's a much bigger concern than one ticket's blast radius: it's a question of whether historical clones are trustworthy at all.

aaronrene's framing: "You'd know instantly whether that's possible; I don't." — this needs someone with visibility into what changed in the verification path between 124 days ago and now.

Suggested investigation

1. Find what changed in the clone/verify path (staging + production) between ~124 days ago and now that would have started rejecting what it previously accepted. Likely candidates: a new integrity check added, a change to how wire_fetch_mpack reconstructs commit bytes, or a change to the id-computation formula itself.
2. Determine whether the old behavior means content-addressing was never actually verified for commits on that path (as opposed to being verified but the non-UTC case simply didn't trigger a mismatch back then for some other reason, e.g. the reconstruction happened to be lossless before some later change).
3. If content-addressing was genuinely unenforced historically: assess whether any clones taken during that window could hold commits with mismatched ids, and what (if anything) can retroactively verify or repair that.

Related

• #39 — the original successful-clone report this references.
• #63 — the structural object-store issue (DB-only commits, reconstructed rather than served as canonical bytes).
• #195 — the specific non-UTC committed_at identity-mismatch bug this ticket's mystery is adjacent to.

Source

Reported by aaronrene, 2026-09-10 (relayed via message to gabriel, processed 2026-09-11).

Mirrored from staging#196.