Beagle SCM

COMMIT-003: commit: view renders nothing in --plain (direct run)

The JS commit: view resolves its target and FEEDS a correct metadata hunk to ctx.sink, yet a direct jab commit commit:#<sha> emits ZERO bytes (rc=0, no error) while native be commit prints the full commit <sha40> / tree / author / … metadata. Surfaced verifying JS-082 (the be-js-hexviews-full-sha repro). Method: Issues.

Input

Context

• Reproduce: in a one-commit worktree, jab commit "commit:#<full-or-short-sha>" (and bare commit:) → 0 bytes, exit 0; native be commit "commit:#<sha>" → commit <sha40>\n + the raw ordered headers + body.
• Traced views/commit/commit.js: the handler DOES resolve the slot and build the hunk — instrumentation shows slot={sha,bannerHex} then feeding bytes=221 toks=15 into ctx.sink.feed("", bytes, toks, "", 0n) — but nothing reaches stdout. So resolution is fine; the RENDER is lost.
• Contrast views/blob/blob.js (same ctx.sink): it feeds a NON-empty uri (blob <key>#L<n>) and renders. commit.js feeds an EMPTY uri (intentional, to match the C keeper eliding the commit:?<sha> U-span) — the loop edge appears to drop the empty-URI content hunk in --plain.
• NOT caused by JS-082: the resolve fast-path works (full + short sha both resolve); the loss is downstream in the sink→edge render of an empty-URI hunk.

Goals

• jab commit commit:#<sha> (full/short/?<ref>/bare) emits the metadata hunk (commit <sha40> + ordered headers + blank + body), matching native byte-wise.
• A repro under test/ (or fold into be-js-hexviews-full-sha, dropping the JS-082 descope note) that asserts the commit <sha40> line is present.

Constraints

• Plain-mode content views must stay byte-exact with the C keeper; an empty-URI content hunk must render its TEXT (native shows no banner line for commit:).

WIP

Design decisions

• ROOT CAUSE (not the empty URI): commit.js fed a HAND-BUILT 15-span tok32 table; the HUNK binding hunk.feed writes that TOK TLV at 1/4 its byte length (JS-092), so HUNKu8sDrain/next() REJECTS the record (4 ∤ 15) → renderHunkLog walks 0 records → 0 bytes. (cat/blob dodge this: they feed EMPTY toks in --plain.)
• FIX (in scope, two leaves): (a) commit.js feeds EMPTY toks in --plain (the cat/blob gate) so the record drains; (b) view/bro.js renderHunkLog guards the log.uri.length read — the empty-URI getter throws RangeError (the SECOND, ticket-predicted edge bug, only reachable once (a) lets next() pass).
• Parity: plain output == native byte-for-byte + ONE trailing blank-line separator — the documented content-hunk constant every view shares (native be commit uses the keeper's own proj_emit_hunk renderer, no separator).
• The underlying binding bug is filed as JS-092 (own ticket, beagle C core).

TODOs

• Repro-first: failing jab commit commit:#<sha> (0 bytes) — test/commit/ render/run.sh asserts ZERO-bytes pre-fix; confirmed RED then GREEN.
• Trace _hunkSink feed → loop-edge render: commit.js plain → EMPTY toks + bro.js renderHunkLog uri-getter guard. Plain parity kept.
• Add the commit: assertion under be/test (no hexviews tree here): be-js-commit-render — asserts the commit <sha40> line + body + native byte-parity (modulo the separator). Full suite 59/59 green.

Blockers and bummers

• Pre-existing (the view never rendered for a direct run); not a JS-082 regress.
• --color toks still broken by JS-092 (binding); not byte-asserted, deferred.

Outcome

• LANDED b9315c6d ("COMMIT-003,004,005", be/). Touches be/views/commit/commit.js, be/view/bro.js, new be/test/commit/render/ run.sh. Spawned JS-092 (the HUNK-toks binding bug).
• Verified in-tree 2026-07-07 (ticket audit): COMMIT-003 markers at commit.js:296-299/:470 (plain = EMPTY toks) + view/bro.js:721 (empty-URI getter guard); test commit/render present; be/ wt clean.