Beagle SCM

STATUS-008: status reported 91 ok over two files holding uncommitted work — unexplained, not reproduced

Input

Context

Observed 2026-07-14 on journal/be: jab status reported 91 ok (all clean) while core/loop.js and verbs/mark/render.js both held uncommitted local work. After an unrelated same-tip jab get reconcile the SAME command reported 89 ok, 2 mod. Nothing but the two files' mtimes changed. Uncommitted work was invisible to status for an unknown period — a get! would have discarded it with no warning.

• Reported by gritzko's own jab status | cat → 91 ok, and reproduced by a fresh-process jab status (so not a resident-loop artifact alone).
• The work is REAL: verbs/mark/render.js (19078 B) carries a <figure>/<figcaption> renderer the tip does not have; core/loop.js (29376 B) carries a small edit (+33 B, same 514 lines).
• The work is in NO commit: blob sha1 c72e6d54 (loop.js) and 2ea3e1bf (render.js) both miss store.open("/home/gritzko/.be","beagle-ext").getObject(h).
• Probe method validated: the clean committed render.js blob 06f9d7ab IS found by the same probe.
• Neither tip carries it: a clean checkout of f21f30f5 AND of the prior tip 33295788 both give render.js = 16770 B with zero figcaption hits.
• The get did NOT create the content: with oldTip == tip (same-tip reconcile) base == theirs, so weave3 returns ours verbatim (verbs/get/get.js:895-899) — the mrg rows were byte-identical rewrites that only bumped mtime to 14:53:52.
• Verified in a worktree: a dirty file carried through a same-tip reconcile is byte-identical after its mrg row (cmp clean) — so the pre-get bytes were the same dirty bytes status called ok.
• NOT reproduced: in a clean clone a dirty file reports mod immediately, and backdating the edit's mtime to before the last get record does NOT hide it (shared/classify.js:34 — hashes content, "never mtime alone").
• Same session, same tree, same 13:26 window as the silent sub unmount (SUBS-053) — a shared transient cause is plausible but unproven.

Goals

• Explain and fix the under-report: a file whose bytes differ from the baseline blob is ALWAYS mod, never counted ok.
• A regression test that pins the guarantee for whatever state triggered it.
• Until understood, treat get/get! over this tree as capable of discarding invisible work.

Constraints

• Repro FIRST — no fix without a failing case (work); this ticket is evidence-only so far.
• Fix in beagle-ext (JS), no C changes; minimal diff, no edits to unrelated tests.

WIP

Design decisions

• Nothing decided — root cause unknown. Hypotheses below are UNTESTED leads, ranked.

TODOs

• hypothesis: stale be/..be.idx (binary wtlog index, mtime 13:26:24) → wtlog.curTip() yields a baseline that is not the wtlog's last get record
• hypothesis: the 13:26 FF get (be/.be line 54) died part-way, leaving wtlog/index state inconsistent — same blip as SUBS-053
• hypothesis: shared/classify.js:90-95 nestedPrefixes wrongly excludes paths from the wt scan (a dir carrying .be/.git); note be/jsrc -> . is a self-symlink
• hypothesis: resident-loop stale require cache serving an old classify.js/status.js
• repro test: whatever state reproduces ok over edited bytes
• fix + regression test

Blockers and bummers

• The triggering state was DESTROYED by the recovery get (mtimes bumped, status now honest) — the tree can no longer be sampled in its broken form.
• Evidence preserved only as this ticket; no copy of the pre-get tree was taken.
• 2026-07-19 RETRACTION (opus read-only investigation of //STATUS-008-f21): the "live repro" claim was WRONG — status there is CORRECT. The figcaption render.js was COMMITTED upstream between Jul-14 and Sat-18: c32ddd17's tree entry for verbs/mark/render.js IS 2ea3e1bf (19078 B, in store after today's get fetched c32's objects); disk == baseline ⇒ clean is truthful (wtEqBase classify.js:143-177 full-hashes, no skip; the STATUS-011 stamp shortcut provably did NOT fire — mtime 26714D0000 is not in the stamp set). Earlier "in no commit / not in store" checks were made against the OLD f21 pin / pre-fetch store — the wiki de-jure-vs-de-facto lesson: verify against the CURRENT baseline.
• 2026-07-19 what REMAINS real: today's bare get (f21→c32, no mrg rows) replaced dirty core/loop.js (blob c72e6d54 ≠ either base, i.e. PENDING per GET-048) with c32's 422a2357 — no weave, no warning, edit unrecoverable. That is a GET data-loss vector (suspect the GET-050 stamp false-clean at get's pending check), NOT a status under-report → pursue in GET-050/GET-051.
• 2026-07-19 side find: jab cat 'verbs/mark/render.js?#c32ddd17' in that tree returns blob ce2d06c8/19107 B — NEITHER the commit's tree entry NOR in the store; the <path>?#<commit> cat/resolve misresolution also tainted the manual verification → URI-018.
• VERDICT PENDING (gritzko): with classify shown content-correct and skip-free, the Jul-14 "91 ok" needs the same re-examination — either its store probe hit the wrong store/project, or the same-tip reconcile's tree already carried the bytes; the under-report premise may not survive. The STATUS-008.evidence/ snapshot is retained but is now known to be the committed blob.

Outcome