[bong-water-water-bong]

Closes #1092. Cycle 26 item 1, the console half (~/briefs/TOS3-C26.md: tty1 came back garbled from the cycle-25 take -
"1EShow the API key", "engint: o ebit", duplicated MENU blocks).

Two defects in os/v3/puppy/console-tui, both measured on the take's own evidence, neither a substitute for the other.

1. The frame is rebuilt in full once a second

draw() runs ~4x/s, but ratatui writes only the cells whose content changed since its own last frame. That is correct
only while the screen still holds that frame, and nothing keeps other writers off tty1 on this appliance:

writer	evidence
kernel printk	the board's cmdline is console=ttyS0,115200 console=tty0 with no loglevel=, so kern.info and up are painted on tty1 - the c25 take's dmesg.log has usbcore: deregistering interface driver snd-usb-audio at t=1759 and an amdxdna TDR dump at t≈697
1bit-release-check	npu_note() writes "\n 1bit check: is holding the NPU" to /dev/tty1
a handoff / anything else on this terminal	1bit-console-menu --action N runs a dialog program on tty1

Reproduced on the shipped c25 artifact (2fc6909c…, what the c25 image embeds): a real pty (tmux pane,
TERM=linux), one printf of three printk-shaped lines to the pane's own tty, then capture the pane:

size	clean	+0.15 s	+1.0 s	+2.2 s	after a keypress
80x25	0 stray lines	2	2	2	2
240x67	0	4	4	4	-

Permanent, and a keypress does not heal it: the diff has nothing to notice. That is the owner's screenshot - and because
the stray write ends with a newline on the last row, the VT scrolls and the log pane's LEM lines are left painted over the
CONNECT rows and the MENU, which is what "engint: o ebit" looks like:

> 1 Show the API key                                                          8020
> 26-11-05 04:47:05.123 [Debug] (Server) GET /api/v1/models
> 3 Network (DHCP, static, hostname)                       2026-11-05 04:47:05.456
>  [Debug] (Server) POST /chat/completions

After (same pty, same single write, this branch's artifact): the stray text is gone at +1.0 s and stays gone, at
both 80x25 and 240x67.

Cost, measured by counting the bytes off a pty for 5 s (TERM=linux, idle dashboard):

size	shipped 2fc6909c…	this branch
80x25	0.4 KiB/s	1.7 KiB/s
240x67 (tty1)	1.0 KiB/s	4.5 KiB/s

Clear is one escape the repaint lands behind, so the VT shows no visible blank (a 240x67 frame is 4.5 KiB, i.e.
sub-frame on the console) - and a full frame per second is worth it: it bounds what any stray line can cost the person
standing at the box to one second.

2. The log pane drops the poll lines

The take's own log (/data/logs/lemond-c25-take.log, 2039 lines) is 549 × GET /api/v1/models - one every ~3 s from
the open demo pages - against 61 chats, 12 /internal/config, 6 image generations. The pane is three rows at 80x25 and
~40 at 240x67, so the polls were the pane, and every chat/load/error had scrolled out of it.

facts::poll_line drops the timer-driven GETs (/api/v1/models, /api/v1/health, /api/v1/stats). The method and the
exact path are both required, so a POST to the same path and /api/v1/models/<name>/options are kept. A tail that is
nothing but polls is shown unfiltered rather than blanked - an empty pane would print "no Lemonade log and no kernel
GPU/NPU lines yet" over a log that exists.

Measured on that same file, rendered at 240x67 (the take log staged at /var/log/lemond-onebit.log, then removed):

	poll rows in the pane	what the pane shows
shipped 2fc6909c…	29	GET /api/v1/models
this branch	0	POST /api/v1/images/generations - 200, the vae decode graph … 11.12s / generate_image completed in 15.75s lines, the POSTs

Tests

cargo test 53/53 (52 + the_log_pane_drops_the_polls_and_keeps_the_chats, which uses lines copied out of that log,
including two that only look like polls, and asserts the fallback for an all-poll tail). Removing the filter makes it red
(measured, then restored).

Also on the artifact this branch builds (0995cc95dffaa48c, 1,582,424 B, static, no PT_INTERP):

• --snapshot 80x25 --fixture and --snapshot 240x67 --fixture are byte-identical to the committed snapshots - the
  heal changes when cells are written, not what the frame says, so no baseline churn for the next cut;
• the eight strings vm-check.sh / menugate grep on tty1 are all on the 80x25 frame (CONNECT, web UI http://,
  api http://, ssh root@, Lemonade Mobile, Show the API key, Reboot / power off, 1-9 actions);
• the 78-run pty sweep (13 sizes × 6 key states) gives the same 15 documented small-window notes as the shipped build
  and no new ones - diff of the two runs is empty, so nothing about the degradation floors (os/v3/puppy: the console TUI's MENU rule gives way before an action does #1014/os/v3/puppy: a console-TUI message costs the legend a word, not an action #1026/os/v3/puppy: a console-TUI dialog loses its question before its hint #1028) moved;
• q over ssh still exits 0; on the console q and Ctrl-C still stay, with their message, and nine actions drawn;
• clippy --all-targets clean, cargo fmt --check clean, tools/copyright.py --check rc 0, no new files, no gate file
  touched.

What this does NOT fix, on purpose

The writers. This is insurance for the console, not a licence to paint tty1: silencing printk (loglevel= on the
command line, mkimage.sh) and the two console notes (1bit-release-check, puppy-check.sh) are os/v3's files and are
being reported to pi-os3/pi-release with these measurements rather than edited from here. One measured fact worth their
time: the take's config.json has log_level: debug but no log_file, and Lemonade's log_file: auto means its
file sink is off (resolve_logging_targets: auto → targets.file = false), so the log_max_file_size_mb: 8 /
log_max_files: 3 keys in that file are inert and the only copy of lemond's log is 10lemonade's >> redirect.

Notes

• Nothing else touches the console tree: git log 2fc6909c…origin/main -- os/v3/puppy/console-tui is empty between the
  c25 artifact and this base.
• No image build, no QEMU, no board run, no device ticket, no GPU/NPU hold; :18097 and npu-serve-keeper untouched.

[bong-water-water-bong]

For review, and one thing that is not this diff: the branch reads BEHIND because main moved to eb66dcd8
(10 files, tests/laya_*). git log bd7d451a..origin/main -- os/v3/puppy/console-tui is empty, so Update branch
is conflict-free and a no-op for the reviewed diff; I am not rebasing on my own tonight (each rebase restarts a ~6-minute
build and the fleet is merging every few minutes - this lane's strict_required_status_checks_policy means it has to be
current at merge anyway).

The artifact for the next cut is 0995cc95dffaa48c (1,582,424 B, static) if this merges; until then c25's
2fc6909c… stays correct. The two committed snapshots are byte-identical to the c25 baseline, so a c26 frame check
diffing against 2fc6909c… sees no movement at all from this PR.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 43861a7)

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1092 - Partially compliant Compliant requirements: The console-TUI frame is now rebuilt in full at most once a second The fix is measured on hardware and shows the cost is +3.5 KiB/s at 240x67 Stray lines written to tty1 are cleared within 1 second The screen is healed without relying on keypresses Non-compliant requirements: None Requires further human verification: The exact hardware measurements and screen capture verification (as described in the issue) should be confirmed by a human reviewer 1014 - Partially compliant Compliant requirements: The MENU rule now gives way before an action does when there's insufficient space The footer still shows "1-9 actions" even when the rule is not drawn The layout at normal sizes is unchanged Non-compliant requirements: None Requires further human verification: None 1026 - Partially compliant Compliant requirements: The message now gives way before an action does when space is tight The message is never cut mid-word The message is drawn whole or not at all Non-compliant requirements: None Requires further human verification: None

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Frame Rebuild Logic The frame rebuild logic introduces a new last_heal variable to track when the screen was last cleared. While this addresses the issue of persistent console artifacts, the timing of the clear operation (once per second) may introduce a slight delay in screen recovery. However, this is acceptable given the hardware constraints and the measured performance impact. let mut last_heal = Instant::now(); let rc = loop { while let Ok(f) = rx.try_recv() { let keep = app.log_scroll; app.facts = f; app.log_scroll = keep.min(app.facts.logs.len().saturating_sub(1)); } if let Some((_, at)) = &app.message { if at.elapsed() > Duration::from_secs(12) { app.message = None; } } if !app.facts.reachable() && last_spin.elapsed() >= Duration::from_millis(250) { app.spin = app.spin.wrapping_add(1); last_spin = Instant::now(); } // Nothing keeps other writers off tty1: kernel printk (the board's cmdline is `console=ttyS0,115200 console=tty0`, // so every amdgpu/amdxdna line is painted here), `1bit-release-check`'s NPU notice, a program the dialog menu ran. // ratatui writes only the cells whose CONTENT changed since its own last frame, so one of those lines is a wrong // screen that a keypress does not fix - measured: three stray lines and a keypress left every panel row showing // the log pane's text. So the frame is rebuilt in full, from a cleared screen, once a second: the write is a // Clear plus absolute positions (no full-screen flash on the VT) and the cost is one frame per second, which is // what a stray line can then cost the reader. if last_heal.elapsed() >= Duration::from_secs(1) { if term.clear().is_err() { break 1; } last_heal = Instant::now(); } Documentation Clarity The README.md documentation provides good detail about the problem and solution, but could be slightly more precise in describing the exact conditions under which the full frame rebuild occurs. Specifically, it mentions that the frame is rebuilt "at most once a second" but doesn't clarify that this is a rate limit rather than a guaranteed frequency. **A frame is rebuilt in full once a second, because a tty cannot be made private.** Anything holding this terminal open can write to it, and ratatui writes only the cells whose *content* changed since its own last frame - correct only while the screen still holds that frame. So one stray line leaves a wrong screen that **a keypress does not fix**: measured on the shipped c25 artifact (`2fc6909c…`) in real ptys, three printk-shaped lines were still there at +2.2 s and after a keypress, at 80x25 and at 240x67 - and when the write ends on the last row the VT scrolls, which is how the log pane's own lines end up painted across the CONNECT block and the MENU (the cycle-25 screenshot: "`engint: o ebit`"). Who writes: kernel messages while `console_loglevel` allows them, `1bit-release-check`'s "holding the NPU" line and `puppy-check.sh`'s console note (both `/dev/tty1` on purpose), and any program a handoff runs. So the frame is rebuilt in full, from a cleared screen, at most once a second: the same write is gone at **+1.0 s**, and the cost is measured - `+3.5 KiB/s` at 240x67 (4.5 KiB/s, was 1.0). **Measured on a booted appliance, not just a pty** (QEMU, the frozen c25 image, its own `tty1::respawn:/usr/local/bin/1bit-console`, the guest's VGA text console at 160x50, screen read through `1bit-tty1` -> `/dev/vcsa1` the way the gates read it, plus QEMU `screendump`s): with the shipped `2fc6909c…` two stray lines written to `/dev/tty1` were still on the screen 4.3 s later **and after a keypress sent through QEMU's own keyboard**; with this binary the same write was gone by the next frame (0 stray rows at +0.3 s, +1.5 s, +3.5 s and after a keypress) and the healed frame was byte-identical to the clean one except the log pane's own new lines. What a screendump cannot catch is a sub-frame blank, so "the Clear is invisible" remains arithmetic (one escape plus 4.5 KiB) - a person at the monitor or a 60 fps capture is the only judge of that. This is insurance, not the fix for a noisy writer: a writer that paints this screen is still a defect in the writer.

[bong-water-water-bong]

CI on the head f532d0f5 (README-only commit on top of the reviewed diff): all green - build pass 6m34s,
Analyze ×5 pass, CodeQL pass, pr_agent pass 47s, hw_gate skipped (TUI-only change, no device ticket). 0 review
threads.

mergeStateStatus is BEHIND because main moved to 22c833cb; git log bd7d451a..origin/main -- os/v3/puppy/console-tui
is empty, so Update branch at merge time is conflict-free and a no-op for the reviewed diff. The committed snapshots
are byte-identical to the c25 baseline (2fc6909c…), so a c26 frame check sees no movement from this PR; the artifact if it
lands is 0995cc95dffaa48c (1,582,424 B, static - unchanged by the README commit, re-derived with build-static.sh).

[bong-water-water-bong]

Re-scoped, and why (also said on #1088, comment 6655549807): #1088 (pi-os3, opened 15 minutes before this one) is the
c26 item 1 PR and owns the pane filter and the kernel console level. I dropped both from this branch in its favour -
their filter labels how many lines it hid, and they measured a fact my draft had missed (Ubuntu's
/usr/lib/sysctl.d/55-console-messages.conf re-raises console_loglevel to 4 after rc.sysinit, so 1bit-console's own
dmesg -n was being overruled and the drop-in is the half that sticks). This PR is now src/main.rs + one README
paragraph (+28/−0) and closes the repaint half of #1092, which is the half #1088 does not cover (their QEMU repro shows the
layout intact under polling - polling writes nothing to tty1; the permanence needs a writer, which is what the take's printk
and the two check hooks are).

• Test-merged onto os/v3 puppy: the console's screen belongs to the console (c26 item 1) — TUI panes stop being a poll log, and printk stops painting tty1 #1088's head af356fca: "Automatic merge went well", aborted - either order is free.
• Artifact on the committed tree 9963252f: da5f6763c74a15a5, 1,581,384 B, static. Committed snapshots
  byte-identical, the eight gate strings still on the 80x25 frame, 52 tests, clippy/fmt/copyright clean, 78-run pty
  sweep identical to the shipped build's notes.
• Heal re-measured on that artifact: a 3-line stray write is gone at +1.0 s at 80x25 and 240x67 (permanent on the
  shipped 2fc6909c…); cost 1.7 KiB/s at 80x25 and 4.5 KiB/s at 240x67 (was 0.4 / 1.0).
• os/v3/puppy: a console-TUI frame is never repainted, so one line written to tty1 is a wrong screen for ever #1092 re-scoped to the repaint defect; ~/briefs/TTUI-NOTE-c26-console-writers.md §5 has a paste-ready
  U2 console heals row for whoever owns vm-check.sh after os/v3 puppy: the console's screen belongs to the console (c26 item 1) — TUI panes stop being a poll log, and printk stops painting tty1 #1088 - it is red on the shipped artifact by design, so it
  must land in a tree that contains this PR.

[bong-water-water-bong]

CI on 9963252f (the re-scoped branch): build pass 5m28s, Analyze ×5 pass, CodeQL pass, hw_gate skipping (no
device code) — everything the ruleset requires is green. pr_agent is red again but its run reads
conclusion: cancelled in 1m51s (gh run view 42010099494) — the workflow concurrency group, not a review, and not a
required context; re-run requested. It reviewed the earlier 4-file head green in 47 s, so this is the same pattern.

mergeStateStatus=BEHIND (main moved); git log bd7d451a..origin/main -- os/v3/puppy/console-tui is empty, so Update
branch is conflict-free and a no-op for the diff. Merge order with #1088 is free (test-merged, "Automatic merge went well").

[bong-water-water-bong]

VERDICT: READY at 3752ebcb — the mechanism is right for the reason given, and the crate's tests pass at this head.

The claim, checked against the code: the loop ticks at event::poll(Duration::from_millis(250)), so "draw() runs ~4x/s" is accurate, and the new heal is if last_heal.elapsed() >= Duration::from_secs(1) { term.clear() } before the draw. That is the correct instrument for this bug: ratatui diffs against its own previous buffer, so a stray line written by anything else leaves the screen wrong until a cell's content changes again — Terminal::clear() discards that buffer, so the next draw() repaints every cell. Without it, no amount of extra drawing fixes a screen someone else painted on.

cargo test --offline --release in os/v3/puppy/console-tui at this head: 52 passed, 0 failed, including the snapshot/size cases (the_mdns_name_is_on_screen_at_both_sizes, the_qr_is_drawn_beside_the_block_only_where_it_fits, the_menu_sits_between_the_facts_and_the_log). The error paths are handled the same way as the draw (break 1), so a terminal that cannot be cleared still exits the TUI rather than looping.

Two notes, neither blocking:

1. The cost is a full repaint every second for as long as the TUI runs, which is the right trade for a screen nobody else may paint on — but it is also the reason the first half of item 1 (#1088: stop the writers) matters, and the two PRs should land together to be worth their cost.
2. term.clear() clears the backend's screen; if it ever needs to be cheaper, the usual refinement is to clear only when a writer is known to exist. I would not do that now — a stray line you cannot see is worse than a repaint you cannot see.

I did not boot an appliance for this; the repaint is a Rust/VT mechanism and the crate tests plus the code are the evidence available off-device.

[github-actions]

Persistent review updated to latest commit 43861a7

[bong-water-water-bong]

Merged as 3eebaa1f — one record-keeping note and the artifact for the next cut.

The squash took the branch's tree exactly (git diff 3752ebcb 3eebaa1f -- os/v3/puppy/console-tui is empty; main
ad472533 builds da5f6763c74a15a5, 1,581,384 B, byte-identical to the branch head), and it does not carry the two
halves I dropped: git show main:.../src/facts.rs | grep -c poll_line = 0 and the 1bit-console printk block is absent -
those are #1088's.

But the squash title is the PR's first title ("…and its log pane is not poll noise"), while the merged diff is only the
repaint (src/main.rs + one README paragraph, +35/−0). Nothing to fix in the tree - just so the merge record is not read as
"the pane filter landed". #1088 (opened 15 min before this one) is still the PR that carries the pane filter and the kernel
console level, and its build is still red on one copyright notice (head dc9705f9; the fix is two lines, patch at
~/briefs/TTUI-PATCH-1088-copyright.diff, both ways spelled out in my comment 6656201051).

So c26 item 1 as it stands on main ad472533: the console heals (a stray line costs ≤1 s instead of the screen - measured
on a booted c25 image's own VT, table in the body above), and the pane is still poll noise + printk still paints tty1
until #1088 lands. If the cut happens before that, that is the honest state to describe.