A plain member is launched with no placement record, so nothing can reach, repair or tear it down

[fujibee]

Not a measured defect at filing time; updated on 2026-09-13 to what the tree does after #1163 landed, so the open question is stated against the current code rather than the original one.

What is true today

spawn writes no placement record for a plain member. The tmux and herdr branches of spawn.sh call _record_placement <terminal> <id> after launching; the plain branch launches the window, requires the driver to return -, and returns without recording anything. So run/spawn.<team>__<agent> does not exist for a plain member, and despawn --force, peek and poke — which all begin by reading that file — answer "no placement record" before any driver is asked.

The driver can now address a plain seat, when someone knows where it is. #1163 gave the plain driver emulator-qualified references, plain:iterm:/dev/ttysNNN and plain:terminal:/dev/ttysNNN, with a measured adapter per emulator and a runtime capability hook (terminal_capability) that can only narrow the static manifest: spawn is supported; peek and poke are supported once a reference parses and the adapter probe finds that tty in that emulator; despawn answers unsupported: plain window teardown needs an owner process witness. ITERM_SESSION_ID and TERM_SESSION_ID are deliberately not used, because live seats on distinct ttys were measured inheriting the same launcher value.

What no one knows at launch is the tty. terminal_spawn on plain opens the window through open -g -a …, a {cmd} template, or a Linux/Windows emulator, none of which return a handle; it prints - because that is all it has. terminal_detect prints - for the same reason. The seat itself is the first thing that can know its tty (its own controlling terminal), which is why the reference grammar exists without a producer for it in spawn.

Teardown is unchanged. terminal_despawn still prints ok and returns 0, and terminal_pane_state still returns 13 with "unknown", on the same reasoning as before: an OS window holds no pid the driver can kill, and a spurious error would be worse than "nothing to tear down". The capability hook's despawn → unsupported is the honest statement of the same fact one layer up.

The question, restated

The original question stands and is still unmeasured: after despawn on a plain member, is the window still on screen? If the boot command exits with the seat and the window closes itself, "ok, nothing to tear down" is exactly right. If the window survives, nothing can reach it afterwards — and after #1163 that is no longer because the driver cannot address a plain seat, but because no record names it: the address (plain:<emulator>:<tty>) is only known to the seat.

Where this connects

• The self-write path (Two canonical facts: the seat's agmsg id and its current pane. Everything else is derived, and the seat writes it #1152, self-write: the seat's own identity writer, its fence, and a seat-local lock (#1152) #1157) is the seat writing its own placement record from a location handed to it. For plain that is the natural — and only — producer of a plain:<emulator>:<tty> record, and self-write: the seat's own identity writer, its fence, and a seat-local lock (#1152) #1157 implements it: the plain driver's fence observes the seat's tty through the seat's own CLI process (ps -o tty= on its pid, never the environment), refuses by name when the process has no controlling tty or sits on a different tty than the locator names, carries the owning pid and its start time as the anchor (so a recycled /dev/ttysNNN cannot pass as an old match), and treats the emulator half as delivered, not as evidence. On any of those refusals the seat writes nothing. Label, key and session are reported as unsupported in the driver's own words (feat(terminal): address measured plain emulators #1163: no adapter in this implementation, not "the emulator cannot").
• Once such a record exists, peek/poke work through feat(terminal): address measured plain emulators #1163's adapters, and despawn --force has a reference to hand the driver — which is where "needs an owner process witness" becomes a concrete thing the record can carry.

How to settle it

Unchanged: spawn a plain member, despawn it, look at the screen. It opens a real window on someone's desktop, so it is a thing to do with permission, not in passing. Until then this issue records two facts, not one: no record is written at launch, and the driver would now know what to do with one.

[fujibee]

Measured. The window survives, and the cause is upstream of the one-line teardown
this issue was about.

spawn (plain)     window count 0 -> 1, "launched ... in a new terminal window"
placement record  absent, from the moment of spawn
despawn --force   "no placement record ... nothing to force"
window count      still 1

So terminal_despawn's echo ok never runs. despawn stops before reaching the
driver, because plain has no addressable pane and spawn therefore writes no
record -- and the teardown path is built on the record being the retry authority
(#625).

The rationale I questioned was sound on its own terms and is not the defect. The
defect is that a plain member can be launched and then cannot be addressed,
repaired or torn down by anything, because the one artifact every path keys on is
never created for it.

The window had to be closed by hand afterwards. osascript targeting Terminal.app
did not find it either, so whichever emulator open chose is not the one the
cleanup assumed.

Where this belongs

Not a fix to the teardown line. Under #1152 a seat writes its own record from two
canonical facts, and the second one -- its current pane -- does not exist for
plain. That makes plain the boundary case the design has to state explicitly
rather than the case it quietly fails on: either a plain member is addressable by
something other than a pane, or spawn should refuse to create one it can never
reach.

Worth deciding before the inversion lands, since "the seat derives its own pane"
has no answer here and the current behaviour is to proceed anyway.

[fujibee]

A fourth option, which I think is better than the three above: write the record, with the pane explicitly marked unsupported.

The three options on the table were framed as a choice between letting a member exist unreachably, refusing to create it, or finding another identifier for it. That framing assumes the problem is reachability. It is worth separating two things that are currently bundled:

• Messaging does not use the placement record. send.sh has zero references to it. A plain member joins, sends and receives normally.
• Terminal operations do. peek, poke, repair and teardown all key on the record, and all of them need a pane.

So a plain member is not unreachable; it is unreachable by pane operations, which is a coherent capability tier and not in itself a defect. The defect is that the record is absent, which makes the member invisible to everything, including the paths that would otherwise report the limitation honestly.

If spawn writes a record whose pane field says unsupported rather than writing none:

• the member appears in the roster and in status output, so an operator can see it exists;
• despawn reaches the driver and can say "this member has no addressable pane; its window must be closed by hand" instead of stopping earlier with "no placement record, nothing to force";
• --fix can report unsupported for it instead of skipping it silently;
• under Two canonical facts: the seat's agmsg id and its current pane. Everything else is derived, and the seat writes it #1152 the seat still has both canonical facts: its agmsg id, and a current pane whose honest value is "there is not one."

This is also the one place where unsupported is the correct word rather than undecided. Elsewhere in this work the rule is that a failed or empty observation is undecided:not_observed, because zero hits cannot prove absence. For plain the absence is structural and established by construction, not inferred from a search that came back empty — there is positive ground for the stronger word.

What this does not do is make a plain member repairable. It cannot be. The change is that every path says so, in a form the caller can act on, rather than each one failing in its own way at a different depth. The comparison is not "reachable vs unreachable" but "a limitation that is stated once vs a limitation each caller rediscovers."

The capability declaration should be corrected alongside it: plain currently advertises spawn despawn, and measurement shows only spawn is reachable.

[fujibee]

Verified live on integration/terminal-driver-v1 (f97d792) with a throwaway team in isolated storage on macOS iTerm2: a member spawned with --terminal-driver plain records its placement as plain:iterm:<tty>; peek reads its screen through the emulator adapter; despawn --force closes exactly that window (its tty disappears) and removes the record, without touching any other placement. A graceful despawn of a member that never acquired its lock reports needs-force and leaves the window open, which is the intended refusal. Fixed by #1207; reaches main with the integration merge.