set-row-state's 240-character cap counts bytes under a C locale, and the comment above it says characters #234

lanes-edit.sh's row_state_check (the gate set-row-state uses) caps the state cell's line at ratified decision O1's 240 CHARACTERS, but counts it with ${#ROW_STATE_LINE}, which is BYTES under LC_ALL=C (and POSIX). The comment above the check says the opposite, and so does the refusal's own wording.

lanes-edit.sh lines 1516-1521 (on main 2732d59):

  # ${#s} COUNTS CHARACTERS and the cap is O1's 240 of them — these lines are
  # full of `·`, `—` and `→`, so a byte count would refuse a line that is inside
  # the cap and accept one that is not.
  [ "${#ROW_STATE_LINE}" -le "$ROW_STATE_CAP" ] ||
    die "the line is ${#ROW_STATE_LINE} characters and the cap is $ROW_STATE_CAP ...

That holds in a UTF-8 locale only.

Reproduction

A register with one row, lanes-edit.sh set-row-state on a line of exactly 240 characters (— and → alternating, 720 bytes), in the lane-start test sandbox (tests/test_lane_start_claude_current.py's Sandbox):

LC_ALL=C:      240 chars, 720 bytes -> exit 2: lanes-edit: the line is 720 characters and the cap is 240 (Amendment 13, ratified decision O1). ...
LC_ALL=C.utf8: 240 chars, 720 bytes -> exit 0: lanes-edit: pushed origin/main (attempt 1)

So a valid line is refused as "720 characters" under a C locale, and the message says characters. The cap is wrongly tight, not loose: a line past 240 bytes but inside 240 characters is refused, and no over-cap line is accepted.

Why it matters

Any writer that reaches set-row-state with a minimal environment (a hook, a container, a LC_ALL=C shell) refuses lines the same writer accepts elsewhere. lane-start, lane-end and lane-handoff cut their lines at 230 with cut_to_line, whose own comment already says ${s:0:n} counts bytes outside a UTF-8 locale, so they are cut shorter there, not refused.

Possible fix

Count code points the same way in every locale. lane-end's cell_for_scan (PR #202, part (a) of #90) does it for its own 240 check: when ${#x} is over 240, and only if the text is valid UTF-8 (iconv -f UTF-8 -t UTF-8), recount with LC_ALL=C tr -d '\200-\277' | wc -c | tr -d ' '; text that is not valid UTF-8 keeps the byte count, which can only over-count. The comment at line 1516 needs correcting whichever way it is fixed.

Found by lane openRepoTools-4's check of PR #202. Not claimed.

🤖 Generated with Claude Code