Route checkpoint reads by ID kind across git backends

main

Commit

Soph2mo ago

Follow-up #1 from the ULID-emission review: reads resolved only against the configured primary store, so after a git-branch⇄git-refs flip (or during coexistence) a checkpoint stored in the other backend was reported missing. Now checkpoint.Open returns a kind-routing store that resolves id-keyed reads by the checkpoint's format:

  • A ULID is read from the git-refs store only — never the branch (any backend).
  • A hex ID is read from the active primary first; under a git-refs primary it also falls back to the git-branch store (a hex checkpoint may still sit on the pre-migration v1 branch, or have been migrated into refs).
  • List unions both backends; GetCheckpointAuthor routes the same way (AuthorReader preserved). Writes are NOT kind-routed — they stay on the configured primary (+ mirrors); the minted ID already matches the primary's format.

The router is built once in Open, reusing the primary for its kind and building the sibling read store. All the general read paths (resume, explain, attribution, blame, tokens, attach) inherit routing for free.

Tests: routing_store_test.go covers ULID→refs (incl. "a ULID never reads from the branch"), hex→branch, hex-fallback and migrated-hex-in-refs under a refs primary, List union, session-read routing, and author routing. Updated open_config_test to the new "Persistent is always the routing store" invariant.

Verified: unit + integration (390) + canary both backends (git-branch, git-refs).

Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com Entire-Checkpoint: fe977d819cd6

Checkpoints

Build Checkpoints Store Based on Design

Claude CodeOpus 4.8[1m]
View session
Checkpoint 1