post detached-wt handling wrong TWICE — POSTDET MISFIRES on an attached ?#<sha>/trunk wt (status says trunk, post says detached), and POSTDET REFUSES a genuinely-detached post (contradicts GET "a bare sha will stay detached on commit"); root cause: status and post read attachment from DIFFERENT routines. Fix: ONE wtlog.attachedBranch reader (recentmost GET record) + let a detached post commit-and-hop.
be/ JS post mishandled the detached/attached axis two ways, both surfaced while landing DIS-057 (a jab post of the classifier work threw POSTDET on a trunk-pinned wt). (1) DETECTION DIVERGENCE: status labels the branch from baselineTip().rawQuery (views/status/status.js) while post's DIS-009 detached guard read curTip().query-is-40-sha + a separate backward curHasFragment scan (verbs/post/post.js) — two routines deriving attachment differently, so a ?#<sha> (trunk PINNED at a sha — ATTACHED) read trunk in status but DETACHED in post → spurious POSTDET. (2) WRONG POLICY: even a genuinely-detached ?<sha> wt was REFUSED, contradicting GET pt 3 "a bare sha detaches (will stay detached on commit)". The rule (ruling 2026-06-29): a wt is attached as per the RECENTMOST get record — ?master/?/?branch#sha/?#sha ATTACHED, only a bare ?<sha> (full-sha in the query, no branch) DETACHED — and there must be exactly ONE routine reading it. FIX (in ~/todo/DIS-057, uncommitted): added shared/wtlog.js::attachedBranch() (the single recentmost-GET reader → {branch, detached, rawQuery, sha}); rerouted the three readers (status label, post detach-guard, post curBranch); and let a detached post COMMIT — the FF pre-flight and advanceRef are gated on !att.detached, so it builds the commit on cur, advances only the cur wtlog row, and moves NO branch ref (git detached-HEAD "hop to the next hash"). be/ only; method per CLAUDE. See GET, POST, DIS-009, DIS-057, DIS-058, DIS-055.
jab post 'DIS-057: unifying the classifier part II' threw POSTDET: refusing on detached wt on a wt whose recentmost get is ?#da7fa5a7 (trunk PINNED at a sha) — while BOTH C and JS status reported trunk (?). Verified by probe: curTip().query='', recentmost get ?#da7fa5a7 → branch trunk.status reads baselineTip().rawQuery (status.js:218 — folds patch rows); post read curTip().query-length-40 + isFullSha + a separate curHasFragment(wtl) scan (post.js old :363-364,:550). Two readers, divergent answers → status trunk, post detached.POSTDET refused ALL detached posts; GET pt 3 says a bare-sha get "will stay detached on commit" — a detached post must COMMIT and hop to the next hash, not refuse.get record (NOT get/post/patch); there must be exactly ONE routine reading it, shared by status + post + divergence — so they cannot disagree.theirsParents, post.js:424) — same file, different defect; reconcile on land.attachedBranch(wtl) reader (recentmost GET) → {branch, detached, rawQuery, sha}; status label, post detach-guard, post curBranch (and divergence) all route through it.?<sha> post COMMITS and hops to the new hash; NO branch ref advanced; the wt stays detached (GET pt 3).status byte-parity.be/ (JS ext / JABC) ONLY — do not touch beagle/.test/parity/status + the status/post corpora green; keep human-readable string throws.attachedBranch reads get rows ONLY (not get/post/patch): posts/patches advance the tip but do NOT change which branch you are ON. This is why status (baselineTip, folds patch) and post (curTip) drifted.refOf finds no branch; ?#<sha> (sha in the FRAGMENT) is ATTACHED-trunk, ?<sha> (sha in the QUERY) is DETACHED.?#<commit.sha> (so curTip advances → next post's parent) but SKIPS advanceRef; attachedBranch (GET-only) keeps the wt detached at the original get — status shows it ahead of the detach point, trunk untouched.attachedBranch in shared/wtlog.js (+ export); reroute status label (status.js:218 → attachedBranch().rawQuery), post detach-guard (post.js → att.detached), post curBranch (→ att.branch); delete the dead curHasFragment.POSTDET throw; gate the FF pre-flight (!att.detached) and advanceRef (if (!att.detached) advanceRef(...)).attachedBranch() = trunk/attached (POSTDET no longer fires); detached-post repro green — jab post on ?<A> commits, new parent = the detached sha A, cur hops to the new hash, resolveRef('') (trunk) UNMOVED, wt still detached; full be-js 97/97 serially (parity-status, post-agree, get-detach, refs-trunk-sigil intact).be/test/ detached-post case (the manual repro: detach ?<sha> → change → jab post → assert the commit lands, parent = the detached sha, trunk ref unmoved, wt still detached). Only be-js-get-detach (get-side row shape) exists today.0a8c42f3 "DIS-057: unifying the classifier part II" (be, 29Jun) carries wtlog.attachedBranch (shared/wtlog.js:118-172, verified in code 2026-07-07); detached-hash reporting refined by 78571401 (Thu02).be/test/ case above must lock it in before close.post.js is touched by THREE in-flight efforts (this, DIS-057 stamp, DIS-058 D17 patch-recursion + the POSTNOFF FF bug) — land-time reconcile needed.?#<commit.sha> makes curTip trunk-ish while attachedBranch stays detached; intentional (hop-the-hash), but confirm status divergence reads sensibly for a long detached chain.jab post POSTDET incident while landing the classifier work.0a8c42f3 (be, 29Jun) — wtlog.attachedBranch (shared/wtlog.js:118-172) is the ONE attach/detach reader, the three readers rerouted, a detached post commits-and-hops (no branch ref moved); 78571401 "report the correct hash in detached state" (Thu02) refined the reporting.be/test/ detached-POST case — only test/get/detach (get-side row shape) exists (verified 2026-07-07); add the detach → edit → jab post → parent==detached-sha, trunk-unmoved, still-detached assertion, then close.