Investigate SQLite resource hash drift across registration and rehydration

[jacksenpierce]

Type and evidence status

Likely bug or resource-identity contract defect. Unverified external incident: the maintainer does not have the referenced workspace, database, provenance receipt, or source package. Do not treat the supplied hashes or semantic-equivalence claim as independently established.

Source: YHX3.2.2 PM4 fork/resource-rehydration incident

Reported behavior

A PM3-era SQLite authority was reportedly registered into PM4 from a disposable copy. The registration workflow changed that copy from WAL journal mode to DELETE without changing its reported semantic head or semantic table counts. The original database had SHA-256 2b36a6b4...; the normalized registration copy had SHA-256 4a056669.... The registered-resource stub retained only the normalized payload hash.

Later, an intentionally slim PM4 fork could not rehydrate the resource from the original source package because the original bytes no longer matched the registered canonicalized bytes, despite a provenance receipt reporting semantic-state equality.

Investigation questions

• Does current registration mutate or normalize a disposable SQLite copy before computing resource identity?
• Is a registered resource contractually identified by exact preserved bytes, canonicalized bytes, semantic state, or multiple explicitly named identities?
• If canonicalization is required, does registration emit a canonical resource bundle that can actually be retained and reattached?
• Should registration record both source_sha256 and canonical_payload_sha256, plus journal/checkpoint transformation provenance?
• Should rehydration deterministically canonicalize a candidate before comparison, or must it require the exported canonical bytes?

Safety constraints

Do not silently equate arbitrary SQLite files merely because selected semantic counts or heads agree. Do not mutate the user's original source. Raw-byte identity, canonical-payload identity, and any semantic/state fingerprint must remain separately named and inspectable.

Acceptance evidence

• Reproduce or falsify the report using a WAL-mode SQLite resource and a disposable registration copy.
• Specify the resource-identity contract in code and documentation.
• Ensure a resource registered from retained source material has a deterministic, supported rehydration path later.
• Test original bytes, canonicalized bytes, semantically different bytes, missing/nonempty WAL sidecars, and idempotent reattachment.
• Preserve provenance for every storage-level transformation.

[jacksenpierce]

Additional unverified corroborating field report: https://github.com/jacksenpierce/parmesan/blob/main/maintenance/incidents/2026-08-23-yhx4-first-divergent-pm4-composition.md

YHX4 reportedly encountered the same seq367 historical-attestation mismatch while preparing two slim workspaces for native composition. The agent preserved the stale attestation as historical evidence, registered the actually available payload under a fresh valid resource identity, and proceeded without rewriting the old claim. That is a useful candidate workflow for this issue: historical attestation preserved; available payload registered separately; mismatch remains explicit.

Investigation should decide whether this is the intended recovery pattern or merely a safe workaround. If supported, Parmesan should produce a structured receipt linking the historical attestation, rejected/mismatched payload identity, new registered resource identity, transformation provenance, and authority decision—without describing the new resource as proof that the old attestation was correct.