l0ng-ai 858cd45615 fix(protocol): a refused pane frame says the sizes, not a constant's name ...

Three sites answered "frame payload exceeds MAX_FRAME". `MAX_FRAME` is a
name only this side of the wire knows, so a peer -- or anyone reading a
log after a frame was refused -- learns neither how big the frame was nor
how big one may be. The control protocol's equivalent already reads
"control frame of N bytes exceeds the M-byte limit"; the pane protocol
had been left behind.

Swept for the shape after the last commit, where a message printed a cap
where a count belonged. Everything else in this class is already right:
`local.rs` and `control.rs` name the actual size beside the limit, and
`server.rs` names the frame it refused.

The read path was already covered against a hostile length -- `frame_edges`
sends `u32::MAX` and checks the refusal comes before anything that large
is allocated -- so this adds one assertion there rather than a test of its
own: that the refusal carries both numbers. Reverting the wording fails it.

2026-08-16 14:51:59 +08:00

..

tty7-cli

docs(cli): say that a newline inside send's TEXT presses Enter

2026-08-16 13:33:46 +08:00

tty7-core

fix(protocol): a refused pane frame says the sizes, not a constant's name

2026-08-16 14:51:59 +08:00

tty7-server

fix(resize): defer the reflow to the daemon's Size echo on remote routes too (#632)

2026-08-14 16:02:04 +08:00