0.59.5

Zen: the head tower’s strip can rest

The strip under Zen’s breathing circle kept the head tower’s lines in front of the boss until they faded, and its own reports kept bringing them back. Boss decision 2026-11-05 (options ① and ②): the boss sends the strip away, and only what is owed to him calls it back.

• Esc, or a tap or click on the blank space, rests the strip. The head’s lines (and its “on it…” line) fade out, the mindfulness line comes back, and the folded input stays, so a phone can call the head back by tapping it. Esc takes its place in escStep after an open input, a field, and an item, and before the “press again for Standard” hint; a strip that has already faded to its rest level does not take it, so leaving still takes two presses there. A tap counts only on the blank space of the circle screen: not on a control, not on the strip, not the end of a drag that selected text, and not the press that folded an open input.
• Enter or H calls the head tower back. Enter wakes the strip and unfolds the input; the first H wakes it with the input folded, and a second H opens the whole conversation as before. H and Enter typed into a field or during IME composition are still the field’s, so a rested strip stays at rest.
• Its own lines do not wake it. A tower’s answer, the head’s report of it, a timer follow-up, and every other turn the boss did not ask for stay held back. A head line that answers something the boss sent (from this page or another), and a wait or question for the boss that was not open when the strip rested, wake it. headLines marks such a reply (HeadLine.reply).
• State. Page-local; Zen hiding ends it, so every visit starts with the strip awake. Reduced motion rests and wakes at once; forced colours hide a rested strip’s lines too.
• Demo. ?zen=head-rest presses Esc a moment after the page starts and sends an unasked report six seconds later.

Design: docs/specs/2026-11-04-head-tower.md, Resting the strip; Esc table: docs/specs/2026-11-01-zen-view.md, Esc in Zen.

Zen does not bring back a question that was answered in Standard

In the 2026-11-05 box trial (trial12) a question was answered in the ally base’s panel in Standard, which closed it, and the same tab then went back to Zen and showed the card (waydosoft asks you) for the closed question, with Already answered elsewhere for a moment; a fresh load showed none. The Zen model kept the item it held on the screen when the page left Zen, and on return it treated the item’s absence as a settlement that happened while Zen was shown. Now model.update(alerts, returning) drops such an item silently when Zen is shown again: the circle shows, with no card, no knock, and no line. An item the snapshot still lists stays the screen, and a question settled while Zen is shown is unchanged (tests/zen-model.test.ts, tests/zen-layer.test.ts; docs/specs/2026-11-01-zen-view.md, Leaving and coming back).

The map’s overview no longer covers an open question panel

The 2026-11-05 box trial found the opened panel on an ally base’s card (the forwarded question, answered in Standard) with its bottom row, Send answer and Cancel, under the map’s overview in the corner (.minimap, fixed at the foot of the window): the row sits at the foot of the window too, and a card in the right-hand column puts Cancel where the overview is. While such a panel is open the overview now fades out and takes no pointer, as it does under a terminal tile, and it comes back when the panel closes (gui/style.css; the rule is on a list that is open inside a box that shows, so a list left open in a box with no question changes nothing). On a phone the overview is not drawn, and the panel’s row was already clear of everything. The demo’s ?ally=ask opens the ci-box base with a two-question forwarded question for the picture.