Beagle SCM

STATUS-004 MED: classifier reports del for a staged delete of an UNTRACKED path — status shows 1 del, post says POSTNONE

be delete of an untracked path writes a delete row that the classifier buckets as del, so be status shows a pending deletion (139 ok, 1 del) — but the path was never in the baseline tree, so the committed tree is unchanged and be post refuses POSTNONE: no changes since base. status and post DISAGREE: a phantom del. The classifier must not bucket a delete row whose path is absent from the baseline as del (a no-op delete changes no tree). Reproduces in BOTH native be and jab — a shared classifier fault. be/ JS shared/classify.js. Spec Dirty / DELETE; method Issues.

Input

Context

• Repro (in ~/todo/GET-037/test, the beagle-ext-tests sub): sub/selflink/run.sh

  is UNTRACKED — absent from the baseline tree (be tree:?<tip> has no sub/selflink).

• be delete sub/selflink/ unlinked it and wrote delete sub/selflink/run.sh rows.
• be status → del sub/selflink/run.sh / 139 ok, 1 del; jab status identical.
• be post '…' → POSTNONE: no changes since base (Error: POSTNONE + Error: NONE);

  jab post → same POSTNONE. The deleted file was never in baseline, so the committed tree == baseline → genuinely no change.

• DISAGREEMENT: status reports 1 del (a pending change) while post finds none — the

  del is a phantom.

• Root cause: shared/classify.js::classifyMerge — the `if (d) { push({ bucket:

  "del", … }) } branch buckets a delete row del REGARDLESS of baseline presence. A delete row whose path is NOT in the baseline (!b) is a no-op (post's tree == baseline) and must not surface as del`.

• Native be status/be post show the SAME disagreement, so it is a shared

  classifier fault, not JS-only.

Goals

• The classifier (status) must NOT report del for a delete row whose path is absent

  from the baseline — status agrees with post (no phantom del, no surprise POSTNONE).

• A be delete of an untracked path leaves a clean status (nothing staged), matching

  that post sees no change.

Constraints

• be/ JS shared/classify.js. REUSE the existing base-tree lookup (b) — a delete

  is real only when the path is in baseline. Keep classifyDir (ls/lsr) consistent.

• Repro-first (CLAUDE §17): be delete <untracked> → status shows del but post

  POSTNONEs (RED); after the fix status is clean and matches post.

• Do NOT regress a real tracked-file delete: a baseline path deleted still shows del

  AND commits.

WIP

Design decisions

• In classifyMerge's if (d) branch, bucket del ONLY when the path is in baseline

  (b present); a delete row for a non-baseline path is dropped (no row), so status matches post's POSTNONE.

• Secondary (separate, link): be delete <untracked> arguably should not WRITE a

  delete row at all (nothing tracked to stage; DELETE: "an already-absent path is an OK no-op") — but the classifier must be robust regardless.

TODOs

• Repro: be delete <untracked> → status 1 del but post POSTNONE. RED.
• classify.js:327 (classifyMerge staged-del branch) already computes

  inBase: !!b — status must DROP the row when !b (today only fold-decide.js:131 consumes the flag, for unlink); keep the gitlink-del branch (:318, inBase:true) as-is.

• Mirror in classifyDir (classify.js:548 — the ls/lsr if (d) bucket

  lacks even the baseline lookup).

• (consider) DELETE: skip writing a delete row for an untracked path — separate.
• Green: real tracked-file delete still del + commits; phantom gone; native parity.

Blockers and bummers

• Native exhibits the same disagreement — decide whether to also fix native or only

  align the be/ JS classifier (the working scope here).

• Overlaps the DELETE-side question (write-the-row vs not) — keep the classifier fix

  self-contained.

Outcome

• OPEN — filed 2026-06-30 (reported by user; repro ~/todo/GET-037/test). Deliverable:

  a non-baseline delete row is never classified del; status agrees with post.

• Audit 2026-07-07: still present — classify.js:327 pushes bucket:"del" for any

  delete row (tags inBase:!!b but never gates on it); no fixing commit in the logs.