mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-09-22 00:02:23 +00:00
l0ng-ai
8a7302ae34
The reaper's test was "the registry is running it and no workspace holds it". A window restoring a layout spawns each pane, attaches to it, and only then files it into the tree — so for a moment every pane it is adopting answers to that description. Not theoretical. Polling `pane ls --all` through a cold start of a seven-tab window reported one, then two, then three, then six, then seven live panes as held by no workspace, and the restore afterwards was correct: all seven were wanted. `--orphans` at any point in that window takes the whole session, and a script that reaps on a timer will eventually sit in it. Attachment is the missing half, and it is the daemon's own fact rather than a guess about timing: `attach` takes the pane's seat and the connection closing calls `detach`, which clears it. A window adopting a pane is attached to it. A pane whose layout was thrown away had its view dropped, which closed the connection, which emptied the seat. Nothing else in the registry tells the two apart, which is why the GUI had to ask its windows and the CLI could not. `pane ls --all` counts the same set, because the line it prints tells the reader to run the reaper. Same race after the change: zero false positives across 300 polls, restore intact. And a stray with nobody attached is still reaped — checked by deleting the new filter, which fails both tests.