b7d2b15a

docs: the restore rule reaches the browser wall

a73x 2026-08-26 06:51

Commit message

docs: the restore rule reaches the browser wall

README.md

Old		New
@@ -267,6 +267,11 @@ line, so the next bare `muxweb` comes back to the same wall. That saved
267	spelling — `--sock PATH` in one piece — is also accepted on the command	267	spelling — `--sock PATH` in one piece — is also accepted on the command
268	line, so a line from the file can be pasted back verbatim.	268	line, so a line from the file can be pasted back verbatim.
269		269
		270	A daemon restart is survived here the same way it is on the CLI wall: a
		271	saved line on a local socket (`--sock PATH#NAME`) comes back as a fresh
		272	session, a remote one (`HOST#NAME`, `quic://HOST#NAME`) is joined only and
		273	its tile reads `refused`.
		274
270	Localhost only, deliberately: to see it from another machine, forward it —	275	Localhost only, deliberately: to see it from another machine, forward it —
271	`ssh -L 7681:127.0.0.1:7681 HOST`.	276	`ssh -L 7681:127.0.0.1:7681 HOST`.
272		277

docs/decisions.md

+that test pins. On a bar too narrow for `marker + " [state]"` the status is what
+the final `text[0..cols]` cut loses, exactly as before the digit; a two-digit
+tile reaches that width one column sooner.
+## 2026-08-26 — the browser wall restores a saved local line too
+The 2026-08-25 ruling above ("a saved local line attaches-or-creates") was a CLI
+ruling only. `muxweb` reads the same file and put up the same tiles, and every
+one of them attached at 0×0 — the passivity contract, so that a browser can
+never move a grid a human is looking at. The daemon reads 0×0 as JOIN, so after
+a restart the browser wall was exactly the thing the CLI had just stopped being:
+a grid of dead local tiles.
+Ruled: the same predicate, both doors. It moved out of `wallview` and down into
+`client.hydratedCreates` — what the entry above calls `wallview.hydratedCreates`
+lives there now. Not into `wall.zig` with the spelling grammar, though the
+spelling is where the distinction is visible: `wall.Spec` is resolved away in
+both doors (`wallview.resolveSpelling`, `webhub.resolveTile`) long before either
+decides, and a predicate neither caller could reach without carrying a derived
+flag alongside the target is two owners wearing one name. `client.Target` is
+what both hold at the moment of the decision, so that is where the rule lives.
+The hub does NOT get there the way the CLI does. A wall stripe can simply put
+its rect on the attach, because a stripe owns a rect; a browser tile owns
+nothing and must not start. So the hub reads the refusal instead — `exit_status`
+as the FIRST daemon frame after the browser's attach, which is mux.js's own
+discriminator mirrored one layer down — and calls `client.birthSession` on a
+connection of its own: one sized attach at the daemon's own default 80×24, wait
+for the snapshot, detach. Then it tears the tile's connection and re-dials
+exactly as a network tear does. The browser sees `reconnecting` → `up`, which it
+has always handled, re-attaches at 0×0 on its own, and is never told a refusal
+happened. Nothing in the page decides anything about creation, which is the
+point: the page is a stand-in for native UIs to come, and a rule living in it
+would have to be written again in each of them.
+The side connection is not incidental. A tile that claimed a size to get its
+session made would go on claiming it, and the shared grid would then follow
+whichever browser reloaded last — the passivity contract broken to fix a
+symptom of it. Paying one attach and leaving hands the session back at a size
+nobody is bound to.
+The bound is NOT per connection, and the first cut of this got that wrong. Every
+refusal closes the hub's connection — `serviceObserver` answers an unseated
+attach with `exit_status` and then `dropObserver`, which closes the fd — so a
+flag cleared on the tear bounds nothing: refuse, redial, re-attach, refuse
+again, and the hub would birth once per turn of a spin it cannot end. The flags
+that matter therefore outlive the dial. `birth_tried` is cleared by a GRID
+arriving, so one birth per healthy period: a daemon that refuses the birth too
+(a full table, a name it will not make) is answered once and then believed,
+while a second daemon restart still heals because the tile was healthy in
+between.
+The other half of that is `ended`, and it is the same bug wearing the user's
+clothes. A shell the user ends with `exit` reaches the hub as exactly the
+restore case: the daemon reaps the session and drops its clients, the hub
+redials, mux.js re-attaches on `up`, and the attach is refused because the
+session is gone. Nothing in those frames distinguishes "this session never came
+back from a reboot" from "I just closed this". So the pump remembers that it
+watched this session die and stops creating — `wallview`'s ruling, which ENDS
+its pump on an exit_status and leaves the tile dead, reached by a pump that
+cannot end because it still serves a browser. Without it, `exit` hands the user
+a new shell, and a short-lived one forks a process per turn.
+The name the hub creates is the TILE's, off the wall spelling, not one read out
+of the browser's attach frame — a page cannot talk the hub into making a session
+it was not already standing in front of.
+A remote tile is untouched throughout: no birth, refusal forwarded, and it reads
+`refused` for the same reason the CLI stripe reads `[refused]`.
+That word is new. The page said `session full`, which was a guess at WHY, and
+the daemon never says why: a missing session and a full table refuse with the
+same `exit_status 1`. Most of the time the guess was wrong. It says `refused`
+now — the CLI's word, for the CLI's reason.