Beagle SCM

JS-045 LOW: mirror the SUBS-030 adv status verb in the JS port (C/JS parity)

be status (C) now renders an advanced submodule (tip descends the gitlink pin, bump pending) as adv <sub>, distinct from a content mod (SUBS-030, landed 69f51bd3). The JS port (bin/lib/subs.js / bin/status.js) still maps an advanced sub to mod, so C/JS parity diverges once jabc is present — the oracle test/bin/sub-status-parity/run.sh asserts mod vendor/sub. Latent until a jabc runtime is available (the parity tests are jabc-gated). Method: Issues.

Input

Context

• C side (SUBS-030): new verb adv; advanced-only sub (SUBS_DIRTY_ADVANCED,

  EDITED clear) → adv, content edit → mod (sniff/SNIFF.exe.c gitlink arm).

• JS side unchanged: bin/lib/subs.js maps any advanced/dirty sub to mod;

  test/bin/sub-status-parity/run.sh (~line 92) greps mod vendor/sub.

• Surfaces only with jabc present; "no jabc" in this box, so it is latent.

Goals

• JS be status renders an advanced-only sub as adv (matching C), content

  edit as mod; update the parity oracle to expect adv.

Constraints

• Mirror the C advanced-vs-edited bit split in the JS subs classifier.
• Don't regress non-sub status parity. Repro-first (parity test, jabc-gated).

WIP

Design decisions

• (open) source the advanced-vs-edited distinction in JS the same way C does.

TODOs

• Mirror the adv/mod split in bin/lib/subs.js (+ any bin/status.js render).
• Update test/bin/sub-status-parity/run.sh to expect adv vendor/sub.

Blockers

• None (latent until jabc available).

Outcome

• Landed 7ef0bf70: advanced-sub bucket mod→adv in subs.js; status.js

  adds adv to ROW_ORDER/SUMMARY_ORDER right after mod (byte-matches native sniff/SNIFF.exe.c) + a counts.adv; test/bin/sub-status-parity arm 1 expects adv. be-bin-sub-status-parity green (all 4 arms); full suite 7/7.

• Follow-up (minor): arm 2's clean-check grep is now vacuous (an advanced sub

  reads adv, never mod) — could tighten it to adv.