Skip to content
C.W.K.
Stream
Lesson 06 of 08 · published

No Pane Left Dead

~12 min · restore, fallback, rematerialize, workflow, reboot

Level 0Spark
0 XP0/48 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Never open that useless panel, whatever happens. Why open a panel that can do nothing? Leave an ordinary shell open at least — then I can do something." — Dad, 2026-09-17

The Dead Panel

On 2026-09-17 the session owner on the office Mac was restarted to move it onto a new input contract. That restart ended the live jobs, as Dad had approved. What he did not approve was what three Anvil seats looked like afterwards: a pane that said the session was no longer owned by this daemon and told him to use a menu item to restart it. The pane could not take a keystroke. It could not start a shell. It was honest about the loss and useless about everything else.

The previous lesson's rule — rematerialize, never resurrect — was being followed. Native workflow reservations had been kept on an explicit-restart path on purpose, so a seat would never be relaunched behind the operator's back. The rule was right. The resting state it left behind was a dead end, and a dead end in a terminal is a reach for another terminal.

Every Path Ends at a Prompt

The repair walks every way a pane can lose its process and gives each one a live shell at the end:

  • A lost identity (daemon gone, logout, a tombstone) rematerializes the pane's declaration.
  • A restored command that ends within five seconds opens a shell in its folder.
  • A folder that no longer exists opens a shell at home and says so.
  • A create the owner refuses opens a shell at home and says so.
  • A dropped connection to the owner reconnects by itself, with backoff.
  • An owner that never comes back, or was never there, leaves the pane running an app-owned shell, labeled as one.

Each of those prints one line saying why this is the shell it is. Only an explicit close, or the user's own command exiting, leaves a pane sitting at an exit status. A regression test walks the whole list — a seat, a command that ends at once, a missing folder, an owner replaced under a live pane, no service at all — and fails if any path leaves a pane that cannot type.

Reboot Brings Back More Than Shells

The same day widened what a reboot restores. When the kernel's boot identity has changed, or a saved session identity turns out to be only a tombstone, the app now rematerializes every ordinary declaration: local shells, declared profile and fleet commands, and SSH or mosh sessions, each with a fresh session identity, the layout kept, and any foreground program re-checked against the restore list. Before that change only local shells came back after a reboot.

Workflow reservations are the deliberate exception. An Anvil seat or a Firebrand resume comes back as a plain login shell in its folder, wearing its badge and color, and its CLI is never restarted on its own. A seat belongs to Anvil's run; starting a fresh CLI there would invent a seat the run never asked for. The shell is there so the operator can act; the seat is not faked so the run stays true.

Honest and Usable Are Not Opposites

None of this bends the earlier rule. No fallback claims a process survived. Every fallback says what it is in its first line. What changed is the resting state: from a truthful pane that can do nothing to a truthful pane that can do something. Both halves were Dad's bar from the first day — sturdy, and no reason to open the other app.

Every failure path ends at a live shell that says why it is there. Rematerialize ordinary declarations; bring workflow seats back as plain shells in their folders; never leave a pane that can do nothing.

Code

Every path, and where it lands·text
cause                                   pane ends at
-----                                   ------------
lost identity (daemon gone, tombstone)  rematerialized declaration
restored command exits within 5 s       shell in its folder   (+ one line why)
folder missing                          shell at home         (+ one line why)
create refused by the owner             shell at home         (+ one line why)
owner connection dropped                reconnects by itself, with backoff
owner never answers / never existed     app-owned shell, labeled
explicit close / user's command exits   exit status (the only resting "done")

after a reboot (boot identity changed)
  local shell            -> fresh shell, same folder
  profile / fleet command -> declared command again, fresh session id
  ssh / mosh             -> same host again, fresh session id
  Anvil seat / Firebrand resume
                         -> plain login shell in its folder, badge + color
                            the CLI is never restarted on its own

External links

Exercise

List every way a pane in a terminal you use can lose its process (host asleep, folder deleted, service restarted, command exits). For each, write what the pane shows today and whether you can type into it. Then rewrite each row so it ends at a working prompt with one line of reason, without claiming that anything survived.
Hint
The test is two questions per row: can the operator act, and is the pane telling the truth? A row that answers only one of them is not done.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign in — Please sign in to comment.

No comments yet — be the first.