The dock's keys stay live under a fault screen #84

New issue

Closed

opened 2026-08-01 14:02:41 +00:00 by aiko · 1 comment

aiko commented

2026-08-01 14:02:41 +00:00

Owner

A fault screen covers the stage, not the dock. So with 6a up — the go-between unreachable — pressing 押して送信 or 送信 underneath still raises the error.websocketNotOpen toast.

#59 met its acceptance: that toast is no longer what you get when the socket is down. But it is still reachable, and a key that looks pressable while it cannot work is the same defect #58 fixed for 割り込み.

Decided 2026-08-01: the dock's send keys stand down while a fault screen is up — dimmed and unpressable, the treatment 割り込み already has. The toast stays for the pal at 0.7×, which has no fault screen to cover it and for which the toast is the only fault signal.

Deliberately not taken: making the press do the fault screen's own action (再同調, or opening 調整). One key meaning two things depending on state is worse than a key that is plainly stood down.

Acceptance

With 6a up, 押して送信 and 送信 are dim and do not fire
They come back the moment the fault clears — no relaunch, no manual reset
The pal at 0.7× still raises the toast, because it has nothing else
The 5a screen gets the same treatment as 6a, or the difference is deliberate and written down

denpa#59 (the fault screens, and the residue this closes), denpa#58 (the same call for 割り込み), denpa#72 (なぜ, still unwired from the pal)

A fault screen covers the stage, not the dock. So with 6a up — the go-between unreachable — pressing 押して送信 or 送信 underneath still raises the `error.websocketNotOpen` toast. `#59` met its acceptance: that toast is no longer *what you get* when the socket is down. But it is still reachable, and a key that looks pressable while it cannot work is the same defect `#58` fixed for 割り込み. **Decided 2026-08-01: the dock's send keys stand down while a fault screen is up** — dimmed and unpressable, the treatment 割り込み already has. The toast stays for the pal at 0.7×, which has no fault screen to cover it and for which the toast is the only fault signal. Deliberately not taken: making the press do the fault screen's own action (`再同調`, or opening 調整). One key meaning two things depending on state is worse than a key that is plainly stood down. ## Acceptance - [ ] With 6a up, 押して送信 and 送信 are dim and do not fire - [ ] They come back the moment the fault clears — no relaunch, no manual reset - [ ] The pal at 0.7× still raises the toast, because it has nothing else - [ ] The 5a screen gets the same treatment as 6a, or the difference is deliberate and written down ## Related `denpa#59` (the fault screens, and the residue this closes), `denpa#58` (the same call for 割り込み), `denpa#72` (なぜ, still unwired from the pal)

aiko added the

ready-for-agent

label

2026-08-01 14:02:41 +00:00

aiko referenced this issue

2026-08-01 14:03:07 +00:00

Wayfinder map — the conversation works (v1) #41

aiko commented

2026-08-01 14:41:53 +00:00

Author

Owner

This was generated by AI during triage.

Closing unbuilt: this was already done on main, and two of the acceptance items I wrote are wrong. The ticket was filed on 2026-08-01 from #59's close-out without checking the tree, and #59 was not the last word on it.

Already shipped

key-row.tsx's socketHeld prop, credited to #65, disables 文, ハンズフリー and 送信 while the socket will not open — "a fault holds one key more than an approval does, because 文 is dead to a shut socket even though it never touches the mic." keys-under-fault.test.tsx already pins the rule this ticket asks for, naming the same defect: "6a … the keys underneath it went on offering to cross it — 送信 answered the screen with error.websocketNotOpen." The prop is wired through dock.tsx, receiver-chrome.tsx and transmission-band.tsx.

Two things this ticket got wrong

"The pal at 0.7× keeps its toast, because it has no fault screen." Wrong now. #71 deliberately removed that exemption — the pal's 文 and 受信 stayed pressable in pet mode and in the Android overlay under the very socket the bar was drawing as 不通 — and #64 wired なぜ, so the pal is no longer the only fault signal at that size. keys-under-shut-socket.test.tsx asserts both surfaces against one TwoHopStatus so they cannot drift. Building what this ticket asked for would have regressed #71.
"5a gets the same treatment, or the difference is deliberate and written down." Already written down, in key-row.tsx: "5a never sets this: its socket is open, so 送信 and 文 reach the go-between exactly as they always did and holding them would take away the only way to find out she is back."

What that leaves

Nothing. The decision recorded on the map — that the dock's keys stand down under a fault screen — was already the shipped behaviour; it was made without knowing that. It stands, and it is what #65 built.

Found by an agent sent to implement this, which read the tree first. That is the check the ticket did not get when it was written.

> *This was generated by AI during triage.* **Closing unbuilt: this was already done on `main`, and two of the acceptance items I wrote are wrong.** The ticket was filed on 2026-08-01 from `#59`'s close-out without checking the tree, and `#59` was not the last word on it. ## Already shipped `key-row.tsx`'s `socketHeld` prop, credited to `#65`, disables 文, ハンズフリー and 送信 while the socket will not open — *"a fault holds one key more than an approval does, because 文 is dead to a shut socket even though it never touches the mic."* `keys-under-fault.test.tsx` already pins the rule this ticket asks for, naming the same defect: *"6a … the keys underneath it went on offering to cross it — 送信 answered the screen with `error.websocketNotOpen`."* The prop is wired through `dock.tsx`, `receiver-chrome.tsx` and `transmission-band.tsx`. ## Two things this ticket got wrong - **"The pal at 0.7× keeps its toast, because it has no fault screen."** Wrong now. `#71` deliberately removed that exemption — the pal's 文 and 受信 stayed pressable in pet mode and in the Android overlay under the very socket the bar was drawing as 不通 — and `#64` wired なぜ, so the pal is no longer the only fault signal at that size. `keys-under-shut-socket.test.tsx` asserts both surfaces against one `TwoHopStatus` so they cannot drift. Building what this ticket asked for would have regressed `#71`. - **"5a gets the same treatment, or the difference is deliberate and written down."** Already written down, in `key-row.tsx`: *"5a never sets this: its socket is open, so 送信 and 文 reach the go-between exactly as they always did and holding them would take away the only way to find out she is back."* ## What that leaves Nothing. The decision recorded on the [map](https://git.aiko.works/aiko/denpa/issues/41) — that the dock's keys stand down under a fault screen — was already the shipped behaviour; it was made without knowing that. It stands, and it is what `#65` built. Found by an agent sent to implement this, which read the tree first. That is the check the ticket did not get when it was written.

aiko closed this issue

2026-08-01 14:41:53 +00:00