Problem
Engine is trending toward a god object (~1,200 lines): document state, history, mutation ops, structural diff, the items() read model, and canonicalization plumbing. The identity layer in particular is a concept without an owner: the keyMap (Map<string, string> of stringly-typed patterns) lives as private engine state and gets threaded as a parameter into loose functions in src/paths.ts (canonicalizeSegs, plus the pattern helpers it depends on).
v1 had this right once before (7d2c949, "keyed-internal arrays for stable op targeting"): identity addressing as an explicit internal layer, translation at the boundary. The v2 simplification removed it; 0.13–0.15 rebuilt the behavior but as scattered machinery rather than a layer.
Proposed shape
An IdentityIndex (name negotiable) constructed from the schema, owning:
- the pattern→key map (today
extractKeyMap output),
- key lookup for a location (
keyFor(pattern)),
- canonicalization (
canonicalize(doc, segments) — today canonicalizeSegs),
- resolution (
resolve(doc, segs) — today resolveCanonical),
- the per-call key-override mechanics that
diff(path, { key }) currently does by swapping the whole map.
Engine holds one instance and stops knowing about patterns entirely.
Why before ordered arrays
Ordered keyed arrays (move op emission, position anchors — discussed but deliberately deferred) will add more identity-layer logic. Better to give the layer a home first than to scatter a third feature across the same five seams.
Origin: self-review finding #5 on the identity-paths change set (0.13–0.15, branch claude/practical-shannon-jr19ie).
Problem
Engineis trending toward a god object (~1,200 lines): document state, history, mutation ops, structural diff, theitems()read model, and canonicalization plumbing. The identity layer in particular is a concept without an owner: thekeyMap(Map<string, string>of stringly-typed patterns) lives as private engine state and gets threaded as a parameter into loose functions insrc/paths.ts(canonicalizeSegs, plus the pattern helpers it depends on).v1 had this right once before (
7d2c949, "keyed-internal arrays for stable op targeting"): identity addressing as an explicit internal layer, translation at the boundary. The v2 simplification removed it; 0.13–0.15 rebuilt the behavior but as scattered machinery rather than a layer.Proposed shape
An
IdentityIndex(name negotiable) constructed from the schema, owning:extractKeyMapoutput),keyFor(pattern)),canonicalize(doc, segments)— todaycanonicalizeSegs),resolve(doc, segs)— todayresolveCanonical),diff(path, { key })currently does by swapping the whole map.Engineholds one instance and stops knowing about patterns entirely.Why before ordered arrays
Ordered keyed arrays (
moveop emission, position anchors — discussed but deliberately deferred) will add more identity-layer logic. Better to give the layer a home first than to scatter a third feature across the same five seams.Origin: self-review finding #5 on the identity-paths change set (0.13–0.15, branch
claude/practical-shannon-jr19ie).