A seat can find its own pane by emitting a token and seeing where it appears

[fujibee]

A seat that was started by hand — no spawn, so no placement record and no pane
label — cannot be repaired. --fix skips it with no_placement_record, and when
it names itself the environment answers with the pane the shared app-server was
launched from. Every route we have depends on something that seat does not have.

There is a route that depends on none of them, and it was measured on the live
workstation with a control.

The measurement

A seat always knows who it is: it was started with actas <name>, so it holds
its team and agent. What it does not know is where it is. It can establish that
by emitting a value and finding which pane displays it.

before      the token was absent from every pane          (control)
seat A      asked to echo token 1   ->  appeared in pane P
seat B      asked to echo token 2   ->  appeared in pane Q

Two seats, two different panes. So this is not "all codex output renders in the
daemon's pane" — each seat's output reaches its own pane. The control rules out
the token having been there beforehand, which is the failure this same session
walked into elsewhere: a confirmation line already in the scrollback reads as
proof of the act that was supposed to produce it.

Why this route is different from the ones we have

route	depends on
environment	the process tree, which for a shared app-server is the daemon's
session id	the terminal's session-to-pane map, measured to disagree with what is running
pane label	the naming mechanism that is itself the thing being repaired
emit and observe	nothing but the seat's own output reaching its own pane

The third row is worth stating plainly, because it was the basis for the label
route and it is weaker than it first appears: the label is written by spawn, by
--fix, and by the seat itself. It is not an independent authority. What it does
have is that it is written per pane rather than read from an inherited
environment, so it does not fail identically for every seat under one daemon.

Cost, and what is not established

One read per pane, once, at the point a seat cannot resolve itself any other way
— not on every action. On this workstation that is a few dozen reads.

Not established: what a seat should emit so the token is not mistaken for content
(it must not collide with anything a person might type); how to bound the scan
when a pane's readable window is short — measured at 80 lines on one driver
(#1121), so a token can scroll out between emitting and scanning; and what
happens when two seats probe at the same time.

[fujibee]

Reopening the case for this. I closed it earlier as "no demonstrated need" -- the
seat it was written for turned out to sit in the very pane its inherited
environment named, so the route was not required to explain that one. That was
the wrong test: not required there is not the same as not required.

A second seat has since arrived at the same shape. It knows it is <seat> -- it
was started with actas and holds its own name -- and cannot be repaired,
because every route to its location is unavailable:

• its placement record names a pane another seat once held,
• its pane carries no label, so the label route has nothing to match,
• and repeated actas changes nothing, because the write happens only if the
  seat can already resolve where it is.

The user put it plainly: if it knows it is <seat>, why can it not just make the
data consistent from that? The answer is that identity is not location -- the
record is <terminal>:<pane> -- and every derivation of location we have depends
on something that is, in this case, absent or wrong.

Except this one. Emitting a token and reading the panes derives location from
identity, and depends on none of them: not the inherited environment, not the
terminal's session map, not a label the repair mechanism itself writes.

What is still not established

The costs listed above are unchanged and still unmeasured: what a seat should
emit so it cannot be confused with content a person typed, how to bound the scan
when a pane's readable window is short, and what happens when two seats probe at
once.

One correction to the report that prompted this

The diagnosis attributed the failure to the pane lacking a herdr agent session.
That is not what the resolver reads: agmsg_terminal_self_env consults
HERDR_ENV and HERDR_PANE_ID and never looks at the agent session. So the
cause is elsewhere, and worth re-measuring on a live seat rather than inferring
-- both panes involved are now empty, so the seats cannot be asked.

[fujibee]

Measured, and this was the one that could have killed the route.

The TUI folds tool output -- what a person sees is a collapsed Ran <command>
line, not the command's text. If folding also hid the output from a pane read,
a seat could emit all it liked and nothing outside would see it.

It does not. Asked to echo a token, the seat's pane read back both:

Ran echo <token>          the folded line
<token>                   the output itself

Four occurrences of the token in the pane, with nothing before the probe (checked
across every candidate pane first).

So the display path carries the token regardless of how the TUI chooses to
present it, which is what the route depends on.

The depth boundary, measured on the same tree

A token with 79 lines printed after it is inside both the fixed window and a
requested depth. With 399 lines after it, neither --lines 80 nor --lines 400
finds it, and --lines 1000 does -- the token was simply further back than 400
rendered lines, since the TUI's own chrome is counted too. herdr honours the depth
it is given; the driver on the installed tree drops it, which is what #1121 fixed
and is not yet in that build.

Practical consequence, and it matches the reading offered in review: what consumes
the window is not the elapsed time of a scan but the lines appended to that pane
after the token is rendered. A leader that asks one seat at a time, waits for it
to go quiet, and then reads, keeps fleet size out of the depth entirely -- it
costs latency, not window.

Still open

• whether a person typing the same string can be told apart from a seat emitting
  it, which decides whether the token alone is sufficient or the act needs
  context around it
• two seats probing at once

[fujibee]

(a) measured, and two of the four results constrain the design.

Four token shapes were emitted by one seat, after confirming all four were absent
from every pane (38 panes scanned):

	result
short opaque id	exact match, once
bracketed structured id	exact match, once
long id (~130 chars)	physically wrapped across three lines; exact match cannot find it
emitted as tool output rather than prose	readable, not collapsed away

What this rules out

Long tokens. Wrapping is physical, so a full-string match fails while the
token is plainly on screen. Any scheme that needs a long unique string fails on a
narrow pane, and pane width is not something the protocol controls.

Uniqueness as the test. A token found in exactly one pane was going to be the
decision rule. It does not survive anyone else emitting the same string -- and
that is not hypothetical: while measuring, I printed the same token into my own
pane and both panes then matched, one occurrence each, indistinguishable.

pane A   1 occurrence   (the seat emitted it)
pane B   1 occurrence   (I typed it)

Nothing in the text says which was which.

What that leaves

The token has to be short enough not to wrap, and the decision cannot rest on
"appears in exactly one pane". What distinguishes a seat's emission from a copy is
not the string but the act: the leader asked this seat, just now, for a value
only it was given. Freshness and the request-response pairing carry the proof,
not the token's rarity.

Which also means a stale match must never count. A token from a previous round
sitting in scrollback is exactly the copy problem in a different guise -- the
failure this same session walked into with a confirmation line.

Measurement note

My first scan reported all four absent, and they were present. The scan raced the
emission: "not found" meant "not yet". Worth stating because it is the same
mistake in reverse -- absence read as fact when it was only the moment of looking.

[fujibee]

(c) measured. All tokens confirmed absent from all 13 panes before each run.

One token, scanned across panes, falls out of the window. A shared token
placed before 399 lines of output, read when the leader reached that pane third:

--lines 400   absent
--lines 1000  present          (same pane, immediately after)

Control: a fresh token placed after the 399 lines, read immediately, is found at
--lines 400. So what consumed the window was the output appended after the
token, exactly as the review reading predicted -- not the scan's elapsed time.

That settles the shape: ask one seat, read that seat, move on. A single token
broadcast to everyone and then swept for is unreliable in proportion to how much
each seat says afterwards, which nothing controls.

Reading immediately does not work. A token poked to an idle seat was not
visible at 0-1.4s (12 polls) nor by ~5.8s (50 polls); it appeared roughly 3s after
the seat's own execution finished.

The honest part of that result: the wait is not separable into model execution and
render latency with the instruments available, so there is no minimum to quote. A
protocol cannot poll for a fixed duration and conclude absence -- it has to wait
for the seat to signal completion, and only then read.

Which fits how the leader already works: a seat replies over agmsg when it is
done, and that reply is the completion signal. The read follows the reply rather
than a timer.

Design, after (a), (b) and (c)

• short token, never long -- long ones wrap and defeat exact matching
• one seat at a time, read that seat's pane, not a fleet sweep
• read after the seat reports completion, never on a timer
• freshness and the request-response pairing carry the proof, not the token's
  rarity -- a token found in one pane proves nothing, since anyone can print the
  same string, and a stale one from a previous round is the same problem