shared/store.js god module split + ref writers take reader.shard
store.js is ~650 lines carrying five responsibilities: object store, LSM index, ref read, ref write, and tree descent. The ref WRITERS (createShard/set/tombstone, folded in from a former refs.js) are free functions exported separately from open()'s reader and key on a RAW fs shard path — so every mutating verb peels reader.shard off the reader and hands it back, leaking the on-disk layout into the verbs. Method: Issues.
ref writers (:9) + tree descent (descendPath) in ONE module.
set(shard,key,sha) / :632 tombstone(shard,key)
/ :618 createShard(shard,key) take a raw fs path, not a reader.
store.set(k.shard, branch, cur.sha); :75-76
store.createShard(k.shard,branch) + store.set(k.shard,…).
store.tombstone(k.shard, target).commitM.writePack(reader.shard,…); :246
advanceRef(reader, reader.shard, …) — shard threaded twice.
shared/store/objects.js (object store + LSM
index) + shared/refs.js (ref read + write), thin store.js facade re-exporting if callers need one import.
internally: store.set(reader,key,sha) etc.
.shard..be/refs across put/post/delete repeats(the DIS-050 dedup at put.js:68-72 must still hold).
shard; have set/tombstone read
reader.shard so callers never name the path.
store.js keeps open + re-exports refs writers tobound the blast radius of the require-site churn.
.be/refs bytes unchangedacross put/post/delete before and after the split.
/75-76, delete.js:230, post.js advanceRef (:246) call sites.
shared/refs.js/store/objects.js
split exists; shared/store.js:633 createShard/:640 set/:647 tombstone still take a raw shard; callers still peel .shard (put.js:90,104; delete.js:272; post.js:685,692).