DIS-052: verbs disagree on a clean file with a drifted mtime; no path re-stamps it

A tracked file whose bytes EQUAL the baseline but whose mtime was changed out-of-band (an external cp, an editor no-op save, a touch) lands in a state where the verbs flatly disagree, and NO documented operation re-stamps it. be status/be diff content-compare → clean (ok, empty diff); be delete mtime-checks → DELDIRTY "unstamped changes" (DIS-004); be put → PUTNONE "no eligible paths" (content == baseline); be get <path> → "overwritten from ? (no staging)" rewrites with a NEW mtime, still unstamped. So the DELDIRTY message's "stage with be put or revert" advice is unachievable. Hit live 2026-06-23 after an out-of-band cp onto bin/lib/store.js. Related DIS-023 (status non-idempotent). Method: Issues.

Issues

The ..be.idx worktree stamp set is keyed per-file by exact mtime, but only some write paths record it; the read verbs use different dirtiness tests, so they diverge on a drifted-but-identical file.

Blockers

None; needs the stamp-set write threaded through the scoped be get <path> (and/or an idempotent re-stamp), plus the DIS-004 content double-check to align delete with status.

Planned

Make a content-clean file re-stampable and make the verbs agree.

WIP

Design decisions

Mirror PUT.c's content-equal re-stamp: a no-staging be get <path> overwrite stamps the written file to SNIFFAtBaseline's ts (the latest get/post row, already in the wtlog index) — no new row, just mtime ∈ stamp-set so SNIFFAtKnown fast-paths it.

TODOs

Blockers and bummers

The verbs already AGREED at the surface (status/delete content-rehash since DIS-023/004) so the bug was invisible to verb-level asserts; the repro instead checks the file's mtime equals the baseline stamp ts (a sibling untouched file's mtime).

Outcome

LANDED (audited 2026-07-07): committed as b7149f85 "DIS-052: file restamping" (beagle, 26Jun).

Landed

Nothing yet (pending-commit; see Outcome).