gritzko's ask 2026-08-14: in lite log, the STRAIGHT CHAIN (the first-parent spine from the walked tip) keeps its normal columns and everything else — commits reachable only through a merge's 2nd+ parents, i.e. merged-in side chains — renders GREY, whole row. be already rules this: LOG-001 (be/views/log/log.js:175) walks the spine, seeds every non-first parent as a side root, and tags non-spine rows TAG_Q (grey in dog/THEME); spine rows paint normally. lite's index/log.js currently has NO such split — its LITE-013 capped walk pops ALL parents through one date-ordered max-heap and paints every row the same L/G/S/D palette. The port is the MARKING, not be's walk: lite's display order stays the strict date order it has; only membership decides the paint.
lite's log machinery, where the split plugs in:
index/log.js CPAR rows are commit_hl -> parent_hl|ord, FIRST PARENT FIRST (the row's own ord) — so the spine is one chain walk taking the ord-0 parent from the tip; no new index data needed.view/bro.js THEME; be greys a non-spine row by covering it whole with TAG_Q — LITE-017's tree already added a Q-capable slot set (E/X/Q) to lite's THEME table.lite log (live tip) and log <hex> (that commit's ancestors) get the split, spine anchored at the walked tip; log <path> rows are file REVISIONS, not a DAG listing — untouched.branchHistory (LOG-001) is the ruling precedent to read; its BFS side-root walk is NOT the thing to copy — lite's heap already collects the same set.lite log on a merge-bearing history shows the mainline crisp and the merged-in noise grey, at a tty and in --tlv/span terms; --plain bytes stay EXACTLY as today (greying is paint, not text).
--plain output byte-identical to today across all forms (pinned); the pty leg shows grey side rows and normal spine rows.be/test/ for LOG-001 legs and port what applies); new legs otherwise: linear history all-spine, one merge (side chain greys), spine-through-merge continuity, log <hex> anchored spine, log <path> untouched.//LITE-018/ (carries the LITE-017 THEME slots and LITE-018's tree — touch ONLY index/log.js, tests and README, no overlap with those tickets' files); jab put + report, never post; NEVER set Now: — only gritzko closes tickets.be/ and jab/ READ-ONLY precedent; never read beagle/; scratch/builds in ~/tmp; ZERO quickjab edits; sh tests dash-safe, no $'\t'.All three leads held; confirmed against the code and built as written.
spineOf(ix, seed, hls) in index/log.js: a Set of the collected hls, then chain parentsOf(ix, hl)[0] (CPAR ord-0, already ord-sorted) from the walked tip while the parent is IN that set. Membership only — O(rows) CPAR lookups, no second history walk, and a spine the cap cut short is still exactly right for the rows on screen.log <hex> anchors the spine at that commit; form === "path" passes null and greys nothing (file revisions are not a DAG listing). log() sets p.nonspine on each row part; hunk() reads it. Display order is untouched — the LITE-013 heap still decides it.TAG_Q (16), be's LOG-001 choice, which lite's THEME already carries from LITE-017: Q: aFgB(90) → *SGR ESC[90m*. It equals the D author-grey numerically, but the Q slot is the one named. An off-spine row keeps the SAME eight spans (QUQQQQQS vs the spine's LUGLGSDS) — only the tags change, the U click-target still opens commit <hexlet> and the trailing "\n" still rides S, so no colour bleeds onto the next row. The painter collapses the equal adjacent Q spans, so a grey row emits ONE ESC[90m for the whole row.--plain needed no guard: the plain sink writes out.rows, built by the untouched rowParts, which never sees nonspine. VERIFIED by a real before/after cmp, not only by reasoning (below).work/LITE-020, clone //LITE-018/, base check — //LITE-018/#d820d07e (LITE-017 tip, 10:37 today), clean--plain byte-parity pinned across bare/<hex>/<path> forms<hex> anchor, <path> untouched; pty leg showing the greyLITEJAB)README.mkd note (the log line gained a clause); suggested commit message in Outcome; Now: untouchedNone. be's be/test/log/nonspine.js (the LOG-001 leg) drives be's own keeper-pack store and cannot run against lite's index, so its four claims were PORTED into test/logspine/spine.js rather than reused verbatim: spine rows present and not grey, side rows present and grey, the grey row carries TAG_Q, a spine row carries none.
index/log.js + test/logspine/ (run.sh, spine.js, pty.js, spinelist.js) + one README clause. Put, not posted.
test/logspine: *41 checks green* — 6 shell legs (git --date-order parity, --plain == piped on a grey-bearing log, the same for <hex> and <path>, a grey row's plain bytes are the same 4 columns, a linear history greys nothing, and the marked spine cmp'd sha-for-sha against git log --first-parent), 24 headless spine legs, 9 pty legs.spine = null) 7 of them go red, including the git first-parent parity leg; every --plain leg stays green, which is the point.--plain BYTE PARITY proven against a real pre-change binary: index/log.js was swapped for the base copy, quickjab rebuilt, baselines captured, then restored — --plain bare / <merge hex> / s.txt / a.txt / 3 / 2 and the piped dump all came back IDENTICAL.Suggested commit message:
LITE-020: log greys everything off the straight chain