The dock stays live underneath fault screen 6a, so 送信 raises an error into a fault #65

New issue

Closed

opened 2026-07-30 21:52:48 +00:00 by aiko · 1 comment

aiko commented

2026-07-30 21:52:48 +00:00

Owner

denpa#59 shipped fault screen 6a — the socket will not open. The dock's keys are not held while it is up, so 送信 is still pressable underneath it and raises error.websocketNotOpen.

That is an error thrown by pressing a key that the app is currently drawing a full-screen explanation of. The operator is told the socket is down and then told again, less well, when they touch anything.

An approval already holds the mic keys (micHeld), so the pattern exists and the fault case simply does not use it. The likely fix is that a fault holds the same keys an approval does, but it is worth deciding deliberately which keys a fault holds — 文 compose, for instance, is just as dead as 送信 when the socket is shut, whereas the fault screen's own actions must obviously stay live.

Acceptance

Under 6a, keys that cannot work are held rather than raising
The decision about which keys a fault holds is written down where the next reader finds it, not just implemented
A test pins that pressing a held key under a fault raises nothing
5a (she could not answer) is checked for the same problem — it may or may not want the same treatment, since the socket is fine there

`denpa#59` shipped fault screen 6a — the socket will not open. The dock's keys are not held while it is up, so 送信 is still pressable underneath it and raises `error.websocketNotOpen`. That is an error thrown by pressing a key that the app is currently drawing a full-screen explanation *of*. The operator is told the socket is down and then told again, less well, when they touch anything. An approval already holds the mic keys (`micHeld`), so the pattern exists and the fault case simply does not use it. The likely fix is that a fault holds the same keys an approval does, but it is worth deciding deliberately which keys a fault holds — 文 compose, for instance, is just as dead as 送信 when the socket is shut, whereas the fault screen's own actions must obviously stay live. ## Acceptance - [ ] Under 6a, keys that cannot work are held rather than raising - [ ] The decision about *which* keys a fault holds is written down where the next reader finds it, not just implemented - [ ] A test pins that pressing a held key under a fault raises nothing - [ ] 5a (she could not answer) is checked for the same problem — it may or may not want the same treatment, since the socket is fine there

aiko added the

ready-for-agent

wayfinder:ticket

labels

2026-07-30 21:52:49 +00:00

aiko commented

2026-07-31 14:33:46 +00:00

Author

Owner

This was generated by AI during triage.

Merged to main in ee25aaa.

Fix. A fault holds the keys that cannot work under it. receiver-chrome.tsx derives socketHeld from fault.kind === 'socket-closed' and threads it into Dock, TransmissionBand and KeyRow, so 送信, ハンズフリー and 文 go disabled instead of raising an error into a fault screen.

Tests. Gate on merged main: 62 files / 854 tests passing.

Not covered here. PalBar never got the same rule, so pet mode and the Android overlay still keep those keys live under the same fault. Filed as #71, which asks for one shared predicate over TwoHopStatus rather than a third hand-derived flag.

> *This was generated by AI during triage.* Merged to `main` in `ee25aaa`. **Fix.** A fault holds the keys that cannot work under it. `receiver-chrome.tsx` derives `socketHeld` from `fault.kind === 'socket-closed'` and threads it into `Dock`, `TransmissionBand` and `KeyRow`, so 送信, ハンズフリー and 文 go disabled instead of raising an error into a fault screen. **Tests.** Gate on merged main: 62 files / 854 tests passing. **Not covered here.** `PalBar` never got the same rule, so pet mode and the Android overlay still keep those keys live under the same fault. Filed as [#71](https://git.aiko.works/aiko/denpa/issues/71), which asks for one shared predicate over `TwoHopStatus` rather than a third hand-derived flag.

aiko closed this issue

2026-07-31 14:33:46 +00:00

aiko referenced this issue from a commit

2026-08-07 08:57:15 +00:00

Merge the #62-#68 batch

aiko referenced this issue from a commit

2026-08-07 08:57:15 +00:00

fix(pal): one rule decides whether a fault stops transmission