The Receiver ignores the three dismiss frames the go-between now sends #62

New issue

Closed

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

aiko commented

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

Owner

Found by the verification pass at the end of the 2026-07-30 board run, not by a failing test. This is a half-built path that this run created, and it has exactly the shape the project keeps getting caught by: nothing crashes, nothing fails, the signal simply never arrives.

What is true

ollvt-hermes-bridge#24 shipped ADR-0012 — an approval binds to the operator rather than to the socket it was offered to, so an ask goes to every authenticated connection and the first valid answer wins. The losing screens are told to clear their card by a dismiss frame.

The go-between emits all three:

src/open_llm_vtuber/adapter_handler.py:70 — approval-dismiss
:77 — clarify-dismiss
:84 — confirm-dismiss

Grepping denpa-client/src for all three returns nothing. There is no consumer.

What that costs

Answer an approval on the desktop and the tablet keeps showing the card. Press it there and the go-between refuses it — correctly, the ask is already resolved — and the operator gets "That request is no longer waiting for an answer." for a card the app is still drawing.

So the feature reads as broken precisely where it was supposed to feel seamless, and ADR-0001's "answering anywhere dismisses everywhere" is still only half true: it answers anywhere, it dismisses nowhere but locally.

Why nothing caught it

The go-between's suite passes — it emits the frame. The client's suite passes — it never claimed to handle it. Neither side is wrong on its own, which is why this needed a cross-repo grep rather than a test run. Same shape as the microphone that returned full-length buffers of zeros.

Acceptance

websocket-handler.tsx handles all three dismiss frames and clears the matching pending ask
A dismissed ask leaves no card on any surface — full card, pal cuff, and the ask drawn over onboarding
A test pins it: a dismiss for an ask this client is showing clears it; a dismiss for one it is not showing is a no-op rather than an error
Verified by answering an approval on one surface and watching it clear on another — this one genuinely needs two windows

ollvt-hermes-bridge#24, ADR-0012, ADR-0001

Found by the verification pass at the end of the 2026-07-30 board run, not by a failing test. **This is a half-built path that this run created**, and it has exactly the shape the project keeps getting caught by: nothing crashes, nothing fails, the signal simply never arrives. ## What is true `ollvt-hermes-bridge#24` shipped ADR-0012 — an approval binds to the operator rather than to the socket it was offered to, so an ask goes to every authenticated connection and the first valid answer wins. The losing screens are told to clear their card by a dismiss frame. The go-between emits all three: - `src/open_llm_vtuber/adapter_handler.py:70` — `approval-dismiss` - `:77` — `clarify-dismiss` - `:84` — `confirm-dismiss` Grepping `denpa-client/src` for all three returns **nothing**. There is no consumer. ## What that costs Answer an approval on the desktop and the tablet keeps showing the card. Press it there and the go-between refuses it — correctly, the ask is already resolved — and the operator gets *"That request is no longer waiting for an answer."* for a card the app is still drawing. So the feature reads as broken precisely where it was supposed to feel seamless, and **ADR-0001's "answering anywhere dismisses everywhere" is still only half true**: it answers anywhere, it dismisses nowhere but locally. ## Why nothing caught it The go-between's suite passes — it emits the frame. The client's suite passes — it never claimed to handle it. Neither side is wrong on its own, which is why this needed a cross-repo grep rather than a test run. Same shape as the microphone that returned full-length buffers of zeros. ## Acceptance - [ ] `websocket-handler.tsx` handles all three dismiss frames and clears the matching pending ask - [ ] A dismissed ask leaves no card on any surface — full card, pal cuff, and the ask drawn over onboarding - [ ] A test pins it: a dismiss for an ask this client is showing clears it; a dismiss for one it is not showing is a no-op rather than an error - [ ] Verified by answering an approval on one surface and watching it clear on another — this one genuinely needs two windows ## Related - `ollvt-hermes-bridge#24`, ADR-0012, ADR-0001

aiko added the

ready-for-agent

wayfinder:ticket

labels

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

aiko commented

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

Author

Owner

This was generated by AI during triage.

Merged to main in ee25aaa.

Fix. The Receiver now consumes the three dismiss frames the go-between sends, so an approval card clears on every screen once any screen answers — ADR-0001's 'answering anywhere dismisses everywhere', over ADR-0012's wire. New services/approvals.ts holds the frame handling; use-approvals.ts consumes it.

Tests. services/approvals.test.ts and hooks/receiver/approval-wiring.test.ts. Gate on merged main: 62 files / 854 tests passing.

Cross-seam review of the whole #62-#68 batch found no issues.

> *This was generated by AI during triage.* Merged to `main` in `ee25aaa`. **Fix.** The Receiver now consumes the three dismiss frames the go-between sends, so an approval card clears on every screen once any screen answers — ADR-0001's 'answering anywhere dismisses everywhere', over ADR-0012's wire. New `services/approvals.ts` holds the frame handling; `use-approvals.ts` consumes it. **Tests.** `services/approvals.test.ts` and `hooks/receiver/approval-wiring.test.ts`. Gate on merged main: 62 files / 854 tests passing. Cross-seam review of the whole #62-#68 batch found no issues.

aiko closed this issue

2026-07-31 14:33:34 +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(gate): stop the vendored SDK from drowning the typecheck