Beagle SCM

URI-018: cat <path>?#<commit> resolves to a blob that is neither the commit's tree entry nor in the store

Input

Context

Found 2026-07-19 during the STATUS-008 re-investigation, in //STATUS-008-f21 (be clone at base c32ddd17):

• jab cat 'verbs/mark/render.js?#c32ddd17' returns blob ce2d06c8, 19107 B.
• c32ddd17's ACTUAL tree entry for that path is 2ea3e1bf, 19078 B (verified via store readTreeRecursive; the blob is in the store and equals the on-disk file).
• ce2d06c8 is not resolvable via getObject in the store at all — cat fabricated or mis-derived content (~29 B larger; provenance unknown).
• Consequence: cat ?#rev cannot be trusted for baseline byte comparisons — it actively misled the STATUS-008 manual verification (and the same idiom was used for the loop.js check earlier the same day, saved only by an independent store-API cross-check).

Goals

<path>?#<commit> in cat (and any view sharing the leg) returns EXACTLY the commit's tree-recorded blob bytes, or fails loudly — never other content.

• Repro-first: pin the c32ddd17/render.js case shape in a fixture (path whose blob differs between the pinned rev and another rev/wt state); assert cat's bytes hash to the tree entry.
• Root-cause where the resolution diverges: views/cat vs URI-016's resolve_hash unification — is cat reading a woven/patched reconstruction instead of the tree blob?

Constraints

• Resolution through be/core/resolve_hash.js only (the mandatory single path) — if cat bypasses or post-processes it, that IS the bug class URI-016 exists to end; fix by unifying, not by a cat-local patch.
• The 19107 vs 19078 delta (~29 B) smells like a banner/trailing artifact or an EOL/normalization pass — establish, don't guess.

WIP

Design decisions

TODOs

• repro fixture + red golden: cat'd bytes vs tree-entry blob sha
• trace cat's ?#rev leg to the divergence point; name file:line
• route through resolve_hash / tree entry; green; note in URI-016

Blockers and bummers

Outcome