feat(memory): W3 parity harness (Layer 1) — on-disk format regression pins

[senamakel]

Summary

• First slice of W3 (store + chunks): the on-disk format parity harness, Layer 1 (spec §0.3) — the gate that guarantees existing user workspaces open unchanged after the store cutover.
• Fixture-free regression pins that lock the crate's deterministic on-disk contracts to the exact byte forms historical OpenHuman workspaces were written with.

Problem

W3 re-implements UnifiedMemory/MemoryClient over tinycortex::store + chunks. Before any storage flip, we need automated proof that chunk IDs, vector encoding, and vault paths are byte-identical to what real workspaces already contain — otherwise a flip silently strands existing data.

Solution

Layer-1 asserters (run on every PR, cheap, no fixture):

• chunk_id — golden SHA-256-first-32-hex (2be5fac1…) for a fixed input + per-field sensitivity (guards input drop / reorder / separator changes).
• vector encoding — little-endian packed f32 golden byte string + exact round-trip (vec_to_bytes/bytes_to_vec).
• content paths — chunk_rel_path sanitizes Windows-illegal : out of colon-laden chunk IDs, deterministic, .md.

Test-only module (#[cfg(test)]), placed in the seam so it can call the crate directly and count toward coverage.

Layer 2 — the golden-workspace differential harness (a real chunks.db + vault opened by pre- and post-migration builds and compared for recall/tree parity) — is the merge gate for the actual store flips and lands with the first flip PR.

Impact

• Runtime: none (test-only).
• This is the safety rail for every subsequent W3 storage flip.

Related

• Part of: plan docs: TinyCortex memory migration plan — audit, ownership split, workstreams #4513 · builds on docs(tinycortex): Phase 0 audit & baseline for the memory migration #4516 (Phase 0), feat(memory): W1 — TinyCortex adapter seam (facade, config + embedding adapters) #4526 (W1), feat(memory): W2 — re-export memory value types from TinyCortex (type-unification) #4529 (W2)
• Drift D3 (vectors count overflow) is closed upstream (tinycortex#59); the W3 store flips follow.

---

AI Authored PR Metadata

Validation Run

• Rust check: cargo check --lib clean; new module is #[cfg(test)]-only, compiled + run by CI

Validation Blocked

• command: local cargo test deferred to GitHub runners (per maintainer direction — slow local test-profile builds)

Behavior Changes

• None — test-only format pins

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 47 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a7170e13-d9f3-4ef4-8804-ac8fd8466f44

📥 Commits

Reviewing files that changed from the base of the PR and between 87f223b and bfbef53.

📒 Files selected for processing (2)

• src/openhuman/tinycortex/mod.rs
• src/openhuman/tinycortex/parity.rs

---

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: bfbef53e57

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Pin the exact legacy vault path

This only proves the crate path is deterministic, colon-free, and ends in .md; if tinycortex changes the slugging or layout while preserving those properties (for example sanitizing # too, or moving the source folder), this test still passes even though the legacy host path for this input is chat/slack-eng/chat-slack-#eng-0.md. That would let a store flip look in the wrong vault path for existing chunks, so the P6 parity guard should assert the exact legacy relative path or compare against memory_store::content::paths::chunk_rel_path for chat/email/document cases.

Useful? React with 👍 / 👎.