Beagle SCM

GET-052: get's pending check can stamp-false-clean a BASE-MOVED file — clean-overwrite leg destroys wt bytes

Input

Context

Split 2026-07-19 out of GET-050 (landed 64525364) and the STATUS-008 loop.js loss. GET-050 band-restamps carried files AFTER the get so dirt stays visible — but the DECISION input is untouched: get's pending detection consumes classify, whose STATUS-011 has(mtime) fast path answers "bytes unchanged since row X", never "clean vs the CURRENT base".

• The suspected hole (tip 9928a0be, unverified): file put-staged (restamp in the stamp set), bytes unchanged since the put (stamp VALID), upstream moves the file's base entry; bare get → fast path says clean → the clean-overwrite leaf checks out the new base blob over the wt bytes. Discard happens BEFORE GET-050's carrySweep could see dirt ("iff still dirty vs the new base" is false once overwritten) — silent, unrecoverable unless the staged blob rode the put row.
• The //STATUS-008-f21 loop.js casualty itself ran that tree's OWN f21-era (pre-GET-048) get code via the jsrc climb — it motivates but does not prove the tip hole; hence repro-first on the tip.

Goals

RED-first on the pristine tip: the shape above must show the discard (or prove the tip safe — a NO-REPRO with evidence closes this DONT).

• Fix: for files whose base entry CHANGED old→new, the pending check must not trust the stamp fast path alone — hash (or size-compare, GET-051) exactly that candidate set; dirty → weave leg, never checkout-over.
• The candidate set (base-moved files) is small — the added hashing cost stays negligible; the stamp fast path remains for base-unchanged files.
• Control case stays green: unstaged fresh-mtime dirt on a base-moved file must already weave (GET-048) — verify as the baseline.

Constraints

• GET-048 reset semantics, GET-049 row-ts stamps, GET-050 band rules in force — extend, don't fork; no log read-back (be.now/append-returned ts only).
• No put/post semantics changes; only the get decision + overwrite guard.
• Repro in a fixture clone, NOT in //STATUS-008-f21 (evidence tree).
• GET-051's size guard is the independent backstop at the write site — reference, don't duplicate; if size-compare suffices here, say so there.

WIP

Design decisions

TODOs

• control repro: unstaged dirty + base-moved + fresh mtime → tip weaves (GET-048 sanity)
• red repro: valid put stamp + base-moved + bare get → discard on tip? NO — weaves identically
• if red: pending check hashes/size-checks the base-moved candidate set; weave; green
• if no-repro: evidence + DONT

Blockers and bummers

Outcome

NO-REPRO on tip 9928a0be (opus worker //GET-052, 2026-07-19) — the hypothesis is structurally impossible in current get:

• get.js consults classify ONLY for the untracked sweep (classify.wtScan, get.js:1117); the clean-vs-dirty DECISION is content-based: checkout.leafUnchanged (checkout.js:122-134) full-reads + bytesEq vs the NEW blob (get.js:1024), and dirty = onDisk != baseBytes(oldSha) off full reads (get.js:1032-1038) — the STATUS-011 stamp set never gates it. Merkle prune (get.js:926) keys on tree-sha equality, so a base-moved file always reaches the content check.
• Fixtures: control (unstaged dirt) ...v weave-preserved; staged valid-stamp conflicting ...! with markers, non-conflicting ...v — nothing discarded. Suites test/get/{carry-stamp,divergent-dirty-weave,dirty,divergent-committed-add,restore-deleted} PASS.
• The //STATUS-008-f21 loop.js loss was that tree's OWN pre-GET-048 get code — not tip evidence. The generic write-seam backstop stays GET-051 (any misclassification, incl. old-code trees and post).