0.59.1

A forwarded question can be followed

The 2026-11-05 box trial looked as if the box forwarded nothing: its server.log had no dialog-* line, and the question was not in Zen. The box had forwarded both questions, and the controller’s holder took them. A forward that worked wrote no line at all, so a forward that worked and one that never ran looked the same.

• The box says each step of a forward. server.log has dialog-forwarder (started, or skipped with the reason) at the start; dialog-controllers (count, known, open) at the first look and whenever the controllers the forwarder sees change; dialog-seen when it takes a question up; dialog-sent for each envelope it hands to the outbox (kind, dialog, team, to); dialog-ended (by, sent) when the question leaves the hub; dialog-full when 32 questions are open and a new one waits. The controller’s link.log has dialog-in for each dialog-open it takes. Ids and counts only, never a word of a question. The table says which file each is in; dialog-unrouted and the forwarder’s drop lines were documented as link.log and are in server.log.
• A forwarder pass that stops answering is said, then let go. A pass that has not finished after a minute (a call that never returns) logs dialog-pass-stuck with the step it waits at (read, dispatcher, notice, post), and the next look, which comes every 15 seconds, starts a pass of its own; the one let go stops where it stands. Before, one call that never came back ended forwarding for good with no line.
• A pass let go does not lose a close. A dialog-close (a question ended, or a controller withdrawn) the stuck pass had not posted is kept and posted by the next pass, up to five tries and not after the card has expired at the controller (25 minutes); a close given up is dialog-close-dropped (failed, stale or full). Before, such a card stayed answerable until it expired. A post of the pass let go that fails late no longer erases the new pass’s mark, so the question is not sent twice. At most one pass let go is outstanding: while it has not returned, a second stuck pass is left running with one dialog-pass-hung line, so a call that never returns leaves one pending pass and not one a minute.
• The log lists of the answer checks are complete. unattended-device.md names every drop the forwarder writes (dialog-answer-unknown, -malformed, -invalid, -digest, -id, -late, -not-recipient, -here-only) and dialog-answered.

A question names the unit that asked

• The owner of a forwarded question is the unit, not the package. A controller was told asks a question (rpiv), the package that opened the dialog, which names nothing. The box now tells main - <session name>, subagent - <name>, member - …, or ally run - … (a tower or an outside pi by its name alone), scrubbed as a board label is (the name is cut at 40 characters, so the whole label is at most 51). Only the separator is ASCII: the card and the Link row show the label whole, and the controller’s notice restricts it to letters, digits, space, ., _ and - (cut at 40), so Mei's Mac reads Mei_s Mac there and a CJK name reads as underscores. The same text is in the controller’s notice, the Link button’s row, Zen’s card, and the 30-minute and oversize notices. A unit with no name left, and a box older than this release, still send the package. The wire format does not change.
• Where the card is. In Zen the card is the whole page as soon as the snapshot carries it (title <box label> asks you, then the sentence, the questions, Send, Cancel, Maybe later), with no tap. In Standard and Geek it is a row under the header’s Link button. Two tests pin the same shape: a controller’s server snapshot carries the box’s dialog-open as one dialog notice (tests/server-link-dialogs.test.ts), and Zen draws such a notice as a card at rest (tests/zen-layer.test.ts).