Beagle SCM

COMMIT-003 MED: 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.