aiko/denpa
1
0
Fork 0
Code Issues 20 Pull requests Projects Releases Packages Wiki Activity Actions

受信記録 — the log, with tool calls as first-class relay rows #17

New issue
Closed
opened 2026-07-29 17:32:08 +00:00 by aiko · 9 comments
aiko commented 2026-07-29 17:32:08 +00:00
Owner
Copy link

What to build

Scope corrected — see the decisions appended below. The wire carries no args and no result payload, so the expandable rows are cut. What this needs instead is reasoning.available forwarded from the go-between (hermes_agent.py:325 discards it) so 思考 rows can exist.

With tool transparency on, a turn is a relay chain (中継), and the log renders that chain as the spine of the turn (cards 4a, 4b).

Message entries — a 48px gutter holding timestamp over speaker, body to the right, colour-coded by who spoke: acid for an unprompted agent turn, magenta for the character, cyan for you.

Relay rows — one line, no container, not clickable: 中継 marker · tool name · preview · duration · status glyph, hairline-separated on the message grid. There is nothing to expand and no 全開. The log is narration and timing, not an audit trail. Four states: 実行中 (live mini-meter, empty duration slot), 完了 (✓ + duration), 失敗 (✕ + 失敗, no error code and no 再試行), 承認待ち (許可が必要 + hold timer — buildable, see #19).

思考 rows — her reasoning from reasoning.available, ranked as marginalia below the answer and the relay spine. This is what replaces the lost RESULT block, and it is testimony rather than evidence.

The agent's answer is footed with a chain summary: 3中継 · 1失敗 · 計 1.1s.

実況 — while it happens. Live, the transmission band shows the chain as segment ticks with a running count. This replaces the 思考中 spinner, which never told you whether she was stuck. No tool names on the pal unless asked; the log holds the detail.

ChatHistoryContext is already sufficient for the relay row as redesigned. It needs one addition: a type: 'reasoning' message so 思考 rows survive a history reload.

Design reference: docs/design/denpa-receiver/README.md (card ids 1a, 4a… index into Denpa Receiver.dc.html, openable in a browser).

Acceptance criteria

  • Relay rows render on one line with no expand affordance in the DOM at all
  • All four relay states render; 失敗 offers an inline retry that works
  • Chain summary counts relays, failures and total time
  • Live segment ticks replace the thinking spinner in the transmission band
  • 中継のみ filter works (全開 is cut — nothing to expand)
  • 思考 rows render, clamp at 4 lines with a もっと toggle, and survive a history reload
  • Log opens over the stage without unmounting it
  • Tests cover chain rendering including a partially-failed chain

Blocked by

Decision — degrade the relay row

Decided: build against the stream as it exists. Drop the ARGS and RESULT blocks.

A 中継 row shows what Hermes actually emits:

  • tool.started — tool name, and preview as the row''s one-line detail
  • tool.completed — duration, and success/failure from error
  • status glyph per the four states in card 4b

No expandable 送信 · ARGS / 受信 · RESULT blocks. Do not fabricate them from preview — a preview string is not the arguments, and a row that looks like an audit trail but is not one is worse than a row that plainly shows less.

Consequences to honour rather than paper over:

  • The header 全開 (expand all) has nothing to expand. Drop it until there is payload worth revealing.
  • The handoff''s "nothing is redacted, args open by default" property does not hold yet. Do not write copy claiming it does.
  • Keep the row''s expand affordance out of the DOM entirely rather than rendering an empty drawer.
  • The chain summary (3中継 · 1失敗 · 計 1.1s) is unaffected — it only needs names, durations and error flags, all of which arrive.
  • Live segment ticks in the transmission band are unaffected, and still replace the 思考中 spinner.

Tool-call pairing is the one correctness risk. There is no tool-call id; the go-between synthesizes run_id:tool:timestamp and FIFO-pairs started→completed by tool name. That is only sound while Hermes runs tools sequentially. Assert the invariant rather than assuming it: if a second tool.started arrives for a tool name that already has an unpaired entry, log it and render both rows as unpaired rather than mispairing them silently.

When Hermes later emits args, results and a stable id, the expandable blocks come back as a follow-up — this decision is about not blocking on that.

## What to build **Scope corrected — see the decisions appended below. The wire carries no args and no result payload, so the expandable rows are cut. What this needs instead is `reasoning.available` forwarded from the go-between (`hermes_agent.py:325` discards it) so 思考 rows can exist.** With tool transparency on, a turn is a **relay chain** (中継), and the log renders that chain as the spine of the turn (cards 4a, 4b). **Message entries** — a 48px gutter holding timestamp over speaker, body to the right, colour-coded by who spoke: acid for an unprompted agent turn, magenta for the character, cyan for you. **Relay rows** — one line, no container, **not clickable**: `中継` marker · tool name · `preview` · duration · status glyph, hairline-separated on the message grid. There is nothing to expand and no `全開`. The log is narration and timing, not an audit trail. Four states: 実行中 (live mini-meter, empty duration slot), 完了 (✓ + duration), 失敗 (✕ + `失敗`, no error code and no 再試行), 承認待ち (`許可が必要` + hold timer — buildable, see #19). **思考 rows** — her reasoning from `reasoning.available`, ranked as marginalia below the answer and the relay spine. This is what replaces the lost RESULT block, and it is testimony rather than evidence. The agent's answer is footed with a chain summary: `3中継 · 1失敗 · 計 1.1s`. **実況 — while it happens.** Live, the transmission band shows the chain as segment ticks with a running count. **This replaces the 思考中 spinner**, which never told you whether she was stuck. No tool names on the pal unless asked; the log holds the detail. `ChatHistoryContext` is already sufficient for the relay row as redesigned. It needs one addition: a `type: 'reasoning'` message so 思考 rows survive a history reload. Design reference: `docs/design/denpa-receiver/README.md` (card ids `1a`, `4a`… index into `Denpa Receiver.dc.html`, openable in a browser). ## Acceptance criteria - [ ] Relay rows render on one line with no expand affordance in the DOM at all - [ ] All four relay states render; 失敗 offers an inline retry that works - [ ] Chain summary counts relays, failures and total time - [ ] Live segment ticks replace the thinking spinner in the transmission band - [ ] 中継のみ filter works (`全開` is cut — nothing to expand) - [ ] 思考 rows render, clamp at 4 lines with a もっと toggle, and survive a history reload - [ ] Log opens over the stage without unmounting it - [ ] Tests cover chain rendering including a partially-failed chain ## Blocked by - #12 - aiko/ollvt-hermes-bridge#17 --- ## Decision — degrade the relay row **Decided: build against the stream as it exists. Drop the ARGS and RESULT blocks.** A 中継 row shows what Hermes actually emits: - `tool.started` — tool name, and `preview` as the row''s one-line detail - `tool.completed` — duration, and success/failure from `error` - status glyph per the four states in card 4b No expandable 送信 · ARGS / 受信 · RESULT blocks. **Do not fabricate them** from `preview` — a preview string is not the arguments, and a row that looks like an audit trail but is not one is worse than a row that plainly shows less. Consequences to honour rather than paper over: - The header `全開` (expand all) has nothing to expand. Drop it until there is payload worth revealing. - The handoff''s "nothing is redacted, args open by default" property does **not** hold yet. Do not write copy claiming it does. - Keep the row''s expand affordance out of the DOM entirely rather than rendering an empty drawer. - The chain summary (`3中継 · 1失敗 · 計 1.1s`) is unaffected — it only needs names, durations and error flags, all of which arrive. - Live segment ticks in the transmission band are unaffected, and still replace the 思考中 spinner. **Tool-call pairing is the one correctness risk.** There is no tool-call id; the go-between synthesizes `run_id:tool:timestamp` and FIFO-pairs started→completed by tool name. That is only sound while Hermes runs tools sequentially. Assert the invariant rather than assuming it: if a second `tool.started` arrives for a tool name that already has an unpaired entry, log it and render both rows as unpaired rather than mispairing them silently. When Hermes later emits args, results and a stable id, the expandable blocks come back as a follow-up — this decision is about not blocking on that.
aiko commented 2026-07-29 17:41:12 +00:00
Author
Owner
Copy link

Where the wire format comes from

Checked for a Discord connector to copy. There isn''t one — hermes-agent''s platform adapters are api_server, qqbot, bluebubbles, signal, weixin, whatsapp_cloud, yuanbao and msgraph_webhook. No Discord.

Looking for it turned up the better answer: Hermes already emits the shape we need.

GET /v1/runs/{run_id}/events — an SSE stream of structured lifecycle events, alongside POST /v1/runs/{run_id}/approval for resolving a pending approval.

So this issue is not "design a tool-call wire format". It is "relay the lifecycle events Hermes already emits, down the client socket". The go-between subscribes to the run-events stream and forwards; the client renders. Invent nothing.

What is still unknown: the exact event names and field names in that stream. GitHub''s rendering truncated the emission code, so it needs reading off a live Hermes — one authenticated curl against /v1/runs/{run_id}/events with the API_SERVER_KEY bearer token.

That single command is the entire remaining blocker on this issue. Once the event schema is captured and written down, this flips to ready-for-agent — the client side is then ordinary rendering work against a known contract.

Do not rename the fields. Whatever Hermes calls them, the go-between forwards and the client consumes under the same names. Renaming at the boundary is how the two halves drift.

## Where the wire format comes from Checked for a Discord connector to copy. **There isn''t one** — hermes-agent''s platform adapters are `api_server`, `qqbot`, `bluebubbles`, `signal`, `weixin`, `whatsapp_cloud`, `yuanbao` and `msgraph_webhook`. No Discord. Looking for it turned up the better answer: **Hermes already emits the shape we need.** `GET /v1/runs/{run_id}/events` — an SSE stream of structured lifecycle events, alongside `POST /v1/runs/{run_id}/approval` for resolving a pending approval. So this issue is **not** "design a tool-call wire format". It is "relay the lifecycle events Hermes already emits, down the client socket". The go-between subscribes to the run-events stream and forwards; the client renders. Invent nothing. **What is still unknown:** the exact event names and field names in that stream. GitHub''s rendering truncated the emission code, so it needs reading off a live Hermes — one authenticated curl against `/v1/runs/{run_id}/events` with the `API_SERVER_KEY` bearer token. That single command is the entire remaining blocker on this issue. Once the event schema is captured and written down, this flips to `ready-for-agent` — the client side is then ordinary rendering work against a known contract. **Do not rename the fields.** Whatever Hermes calls them, the go-between forwards and the client consumes under the same names. Renaming at the boundary is how the two halves drift.
aiko commented 2026-07-29 18:03:00 +00:00
Author
Owner
Copy link

Warning

Partly superseded — the approval claim below is wrong. Hermes 0.19.0 emits approval.request on the run-events stream with a per-request choices array and sets run status waiting_for_approval (gateway/platforms/api_server.py:6250-6275, :71-74, :1348). The go-between discards the event; Hermes has always had it. See the correction later in this thread and #19. Everything else in this comment stands.

Schema captured — and the gap it exposes

Did not need a live Hermes. The bridge already parses this stream: src/open_llm_vtuber/agent/agents/hermes_agent.py, _iter_sse_events / _tool_status_from_event / _stream_run_events. Verified against a running hermes-agent 0.19.0.

Event types on GET /v1/runs/{run_id}/events:

Event Fields
message.delta delta
tool.started tool, run_id, timestamp, preview
tool.completed tool, run_id, timestamp, duration, error
run.completed / run.cancelled output
run.failed / run.errored error
reasoning.available ignored by the bridge

This issue as written cannot be built on that stream. The design expands a 中継 row into 送信 · ARGS and 受信 · RESULT. Neither exists:

  1. No args. tool.started carries preview — a display string, not structured arguments.
  2. No result. tool.completed carries duration and error only. 受信 · RESULT has nothing to render.
  3. No tool-call id. The bridge synthesizes one from run_id:tool:timestamp and FIFO-pairs started→completed by tool name, which is sound only because Hermes calls tools sequentially. Two concurrent calls to the same tool would pair wrongly and the log would show two half-rows.
  4. No approval event. Nothing in this stream suspends a turn or carries an approval request, so #19 has no delivery path either.

Three ways forward

  • Extend Hermes to emit args and results on the tool events (and a stable tool_call_id). Correct, and fixes #19 too, but it is upstream work in hermes-agent.
  • Capture at the go-between — it already proxies the run; if it can see tool payloads another way, it enriches before relaying. Needs checking whether the payloads are reachable there at all.
  • Degrade the design — the 中継 row shows preview, duration and status, and drops the ARGS/RESULT blocks. Buildable today, and the row is still an audit trail of what ran and whether it worked — just not with what. The "nothing is redacted, args open by default" property is lost.

Needs a decision on which. The third is the only one that unblocks this issue without upstream work.

Also worth noting: reasoning.available is currently discarded. If she should ever show her thinking, that event is already arriving.

> [!WARNING] > **Partly superseded — the approval claim below is wrong.** Hermes 0.19.0 emits `approval.request` on the run-events stream with a per-request `choices` array and sets run status `waiting_for_approval` (`gateway/platforms/api_server.py:6250-6275`, `:71-74`, `:1348`). The go-between discards the event; Hermes has always had it. See the correction later in this thread and #19. Everything else in this comment stands. --- ## Schema captured — and the gap it exposes Did not need a live Hermes. **The bridge already parses this stream**: `src/open_llm_vtuber/agent/agents/hermes_agent.py`, `_iter_sse_events` / `_tool_status_from_event` / `_stream_run_events`. Verified against a running `hermes-agent 0.19.0`. Event types on `GET /v1/runs/{run_id}/events`: | Event | Fields | |---|---| | `message.delta` | `delta` | | `tool.started` | `tool`, `run_id`, `timestamp`, `preview` | | `tool.completed` | `tool`, `run_id`, `timestamp`, `duration`, `error` | | `run.completed` / `run.cancelled` | `output` | | `run.failed` / `run.errored` | `error` | | `reasoning.available` | ignored by the bridge | **This issue as written cannot be built on that stream.** The design expands a 中継 row into 送信 · ARGS and 受信 · RESULT. Neither exists: 1. **No args.** `tool.started` carries `preview` — a display string, not structured arguments. 2. **No result.** `tool.completed` carries `duration` and `error` only. 受信 · RESULT has nothing to render. 3. **No tool-call id.** The bridge synthesizes one from `run_id:tool:timestamp` and FIFO-pairs started→completed *by tool name*, which is sound only because Hermes calls tools sequentially. Two concurrent calls to the same tool would pair wrongly and the log would show two half-rows. 4. **No approval event.** Nothing in this stream suspends a turn or carries an approval request, so #19 has no delivery path either. ### Three ways forward - **Extend Hermes** to emit args and results on the tool events (and a stable `tool_call_id`). Correct, and fixes #19 too, but it is upstream work in `hermes-agent`. - **Capture at the go-between** — it already proxies the run; if it can see tool payloads another way, it enriches before relaying. Needs checking whether the payloads are reachable there at all. - **Degrade the design** — the 中継 row shows `preview`, duration and status, and drops the ARGS/RESULT blocks. Buildable today, and the row is still an audit trail of *what ran and whether it worked* — just not *with what*. The "nothing is redacted, args open by default" property is lost. Needs a decision on which. The third is the only one that unblocks this issue without upstream work. Also worth noting: `reasoning.available` is currently discarded. If she should ever show her thinking, that event is already arriving.
aiko commented 2026-07-29 22:35:43 +00:00
Author
Owner
Copy link

Design changed — the log is narration and timing, not an audit trail

The blocking question behind this issue (aiko/ollvt-hermes-bridge#17 item 3) is resolved: degrade the client design to what Hermes emits. Hermes leads. docs/design/denpa-receiver/README.md sections 4a/4b and the fidelity audit table are updated, so the doc is the spec again rather than an aspiration.

What this issue now builds:

Relay row — one line, no container, not clickable.

中継 marker · tool name · preview · duration · status glyph. The card and its inset ring are gone along with the expansion that justified them (and a relay row inside a message entry was a card nested in a card). Hairline separation only, aligned to the existing 48px 1fr message grid. preview takes flex: 1 and ellipsises — it is the only field that says what she actually did, since build_tool_preview() derives it from the real arguments. Full string on title and long-press.

Cut, because the wire does not carry them: the expandable 送信·ARGS and 受信·RESULT blocks, the 全開 header button, 失敗 · 403 error codes, inline 再試行. Details in the linked comment; the short version is tool.completed carries duration and a bare error boolean, no result payload and no code, and nothing on the wire can re-invoke a single tool.

New: 思考 rows. reasoning.available carries her reasoning text and the design was ignoring it. It becomes its own row type — 思考 label in signal cyan, body Archivo 400 12px #9c86a8, max-width: 68ch, 4-line clamp with a もっと toggle. Ranked as marginalia below the answer and below the relay spine: the answer is what she said, relay rows are what she did, reasoning is what she was thinking while doing it.

It is testimony, not evidence, and the design must not dress it as an audit record. That distinction is the point of the rework.

Prerequisite in the go-between: HermesAgent._stream_run_events discards reasoning today (hermes_agent.py:325 — "reasoning.available and any other events are ignored"). Forward it as a new message type, and persist it so 思考 rows survive a history reload — ChatHistoryContext needs a type: 'reasoning' message. Without this, 4a is relay rows and timing only.

4b's four states all survive, deriving from the glyph, the duration slot and the tool name's colour instead of borders. 失敗 shows no code and offers no retry. The 実行中 mini-meter is the only animation in the log and now has a prefers-reduced-motion resting state.

承認待ち is unblocked separately — the Platform adapter in aiko/ollvt-hermes-bridge#16 provides send_exec_approval and the gateway-side resolvers.

## Design changed — the log is narration and timing, not an audit trail The blocking question behind this issue (aiko/ollvt-hermes-bridge#17 item 3) is resolved: **degrade the client design to what Hermes emits.** Hermes leads. `docs/design/denpa-receiver/README.md` sections 4a/4b and the fidelity audit table are updated, so the doc is the spec again rather than an aspiration. What this issue now builds: **Relay row — one line, no container, not clickable.** `中継` marker · tool name · `preview` · duration · status glyph. The card and its `inset` ring are gone along with the expansion that justified them (and a relay row inside a message entry was a card nested in a card). Hairline separation only, aligned to the existing `48px 1fr` message grid. `preview` takes `flex: 1` and ellipsises — it is the only field that says what she actually did, since `build_tool_preview()` derives it from the real arguments. Full string on `title` and long-press. **Cut, because the wire does not carry them:** the expandable 送信·ARGS and 受信·RESULT blocks, the `全開` header button, `失敗 · 403` error codes, inline `再試行`. Details in the linked comment; the short version is `tool.completed` carries `duration` and a bare `error` boolean, no result payload and no code, and nothing on the wire can re-invoke a single tool. **New: 思考 rows.** `reasoning.available` carries her reasoning text and the design was ignoring it. It becomes its own row type — `思考` label in `signal` cyan, body Archivo 400 12px `#9c86a8`, `max-width: 68ch`, 4-line clamp with a `もっと` toggle. Ranked as marginalia below the answer and below the relay spine: the answer is what she said, relay rows are what she did, reasoning is what she was thinking while doing it. It is testimony, not evidence, and the design must not dress it as an audit record. That distinction is the point of the rework. **Prerequisite in the go-between:** `HermesAgent._stream_run_events` discards reasoning today (`hermes_agent.py:325` — *"reasoning.available and any other events are ignored"*). Forward it as a new message type, and persist it so 思考 rows survive a history reload — `ChatHistoryContext` needs a `type: 'reasoning'` message. Without this, 4a is relay rows and timing only. **4b's four states all survive**, deriving from the glyph, the duration slot and the tool name's colour instead of borders. 失敗 shows no code and offers no retry. The 実行中 mini-meter is the only animation in the log and now has a `prefers-reduced-motion` resting state. 承認待ち is unblocked separately — the Platform adapter in aiko/ollvt-hermes-bridge#16 provides `send_exec_approval` and the gateway-side resolvers.
aiko commented 2026-07-29 23:03:18 +00:00
Author
Owner
Copy link

Body is stale in two ways — read the comments, not the checkboxes

Flagging rather than editing the body, since the convention here is that comments supersede. An agent working the checklist as written would build the wrong thing twice.

1. The acceptance criteria still require what was already dropped. These three cannot be satisfied and should be treated as void:

  • "Relay rows expand to show real args and results, unredacted"
  • "中継のみ filter and 全開 work" — the filter is fine; 全開 has nothing to expand
  • and the body's "nothing is redacted and args are open by default" property, which the 2026-07-29T18:03 comment already says does not hold

The current design is the one-line, non-expanding relay row plus 思考 rows — see the 22:35 comment and docs/design/denpa-receiver/README.md Turn 4, now committed.

2. The wire audit in this issue asserts there is no approval event. That is wrong, and it matters here because 4b's 承認待ち is one of the four relay states this issue draws. Hermes 0.19.0 emits approval.request on the run-events stream with a per-request choices array and sets run status waiting_for_approval (gateway/platforms/api_server.py:6250-6275, :71-74, :1348). The go-between drops the event; Hermes has always had it. Tracked at #19, reopened.

So the 承認待ち state in 4b is buildable, and its 許可が必要 row does not depend on ollvt-hermes-bridge#16.

## Body is stale in two ways — read the comments, not the checkboxes Flagging rather than editing the body, since the convention here is that comments supersede. An agent working the checklist as written would build the wrong thing twice. **1. The acceptance criteria still require what was already dropped.** These three cannot be satisfied and should be treated as void: - *"Relay rows expand to show real args and results, unredacted"* - *"中継のみ filter and 全開 work"* — the filter is fine; `全開` has nothing to expand - and the body's *"nothing is redacted and args are open by default"* property, which the 2026-07-29T18:03 comment already says does not hold The current design is the one-line, non-expanding relay row plus 思考 rows — see the 22:35 comment and `docs/design/denpa-receiver/README.md` Turn 4, now committed. **2. The wire audit in this issue asserts there is no approval event.** That is wrong, and it matters here because 4b's 承認待ち is one of the four relay states this issue draws. Hermes 0.19.0 emits `approval.request` on the run-events stream with a per-request `choices` array and sets run status `waiting_for_approval` (`gateway/platforms/api_server.py:6250-6275`, `:71-74`, `:1348`). The go-between drops the event; Hermes has always had it. Tracked at #19, reopened. So the 承認待ち state in 4b is buildable, and its `許可が必要` row does not depend on `ollvt-hermes-bridge#16`.
aiko commented 2026-07-30 00:04:27 +00:00
Author
Owner
Copy link

Still correct, with one prerequisite that no longer exists

This issue survives the architecture change - ADR-0005 confirms the design as it stands: one-line collapsed relay rows, 思考 rows from her reasoning, no payload blocks and no 全開. Notably that is now a choice rather than a limitation: in-process the callbacks carry tool arguments, a stable tool_call_id and the result payload, and we are declining them because reasoning answers the question the payload blocks were reaching for. ADR-0005 records why, and restoring them stays cheap if it proves wrong.

Obsolete prerequisite: an earlier comment said 思考 rows need HermesAgent._stream_run_events to stop discarding reasoning.available at hermes_agent.py:325. That file is being deleted (ADR-0002) - HermesAgent goes away with the whole agent layer. Reasoning now arrives through the in-process progress callback instead, so there is no forwarding fix to make in that file.

One constraint from ADR-0005 that must reach the UI: reasoning is truncated to 500 characters at the source (agent/conversation_loop.py:5539), and a sub-agent's is reduced to its first line at 80. The 4-line clamp and もっと reveal up to that excerpt and no further, so the copy must not promise a complete record of her thinking.

## Still correct, with one prerequisite that no longer exists This issue survives the architecture change - **ADR-0005** confirms the design as it stands: one-line collapsed relay rows, 思考 rows from her reasoning, no payload blocks and no `全開`. Notably that is now a *choice* rather than a limitation: in-process the callbacks carry tool arguments, a stable `tool_call_id` and the result payload, and we are declining them because reasoning answers the question the payload blocks were reaching for. ADR-0005 records why, and restoring them stays cheap if it proves wrong. **Obsolete prerequisite:** an earlier comment said 思考 rows need `HermesAgent._stream_run_events` to stop discarding `reasoning.available` at `hermes_agent.py:325`. That file is being deleted (ADR-0002) - `HermesAgent` goes away with the whole agent layer. Reasoning now arrives through the in-process progress callback instead, so there is no forwarding fix to make in that file. One constraint from ADR-0005 that must reach the UI: reasoning is truncated to 500 characters **at the source** (`agent/conversation_loop.py:5539`), and a sub-agent's is reduced to its first line at 80. The 4-line clamp and `もっと` reveal up to that excerpt and no further, so the copy must not promise a complete record of her thinking.
aiko commented 2026-07-30 05:19:28 +00:00
Author
Owner
Copy link

Landed on issue/denpa-17-log-relay-rows

298 tests passing in 28 files (main was 275 in 26). npm run typecheck adds no error in any file this branch touches - the four non-vendored errors it reports are the pre-existing ones in chat-history-panel.tsx, live2d-config-context.tsx, use-sidebar.ts and use-audio-task.ts.

What it does

  • One log at both sizes. The 1a overlay now renders the same LogRail the 1c rail does. LogRail takes width, header and edge, so the overlay fills the stage and keeps its own header + ✕ while the rail stays a 320px column. App.tsx stops mounting the upstream chatscope ChatHistoryPanel, which closes the B2 inconsistency where the same log looked different at the two sizes.
  • log-rows.ts - 受信記録 as pure functions: logRows (rows in arrival order, the 中継のみ filter, and the chain footed on the answer it belongs to), chainSummary (3中継 · 1失敗 · 計 1.1s), parseDurationMs, and liveChain for the band.
  • 思考 rows - type: 'reasoning' on Message, appendReasoningMessage in ChatHistoryContext, a case 'reasoning' on the socket handler, and a row in signal cyan clamped to 4 lines with a もっと reveal. Copy says nothing about a complete record: per ADR-0005 it is the 500-character excerpt and there is nothing behind the toggle.
  • 実況 - the transmission band draws the chain as segment ticks with 中継中 · <tools> · 2/3 and 調べてる…, and drops them the moment nothing is running.
  • 承認待ち is the fourth relay state (pending_approval): acid name, 許可が必要, hold timer in the tail, no glyph. 失敗 still carries no code and offers no retry.
  • Relay rows have no expand affordance in the DOM - a test asserts no <button>, no aria-expanded, no <details> and no cursor:pointer inside the spine, and no 全開 anywhere.

Deliberately left out

  • The producer. /client-ws carries no tool and no reasoning message today (websocket_handler.py:126-455, adapter_handler.py:118-122) - the tool_call_status case in the client is inherited upstream plumbing, not something Denpa sends. The rows render nothing until the go-between forwards the in-process callbacks. That is go-between work in the other repo.
  • The unpaired-row assertion the decision comment asks for. The client pairs on tool_id, not FIFO by name, so the mispairing hazard lives where the id is synthesised - upstream of this client. A row whose completion never arrives draws no glyph and no duration rather than a ✓.
  • 検索 and the day divider - #30's surface. The header shows 受信記録 · 5件 · 中継のみ and no paging.

Assumed

  • A completed relay's content is 0.4s / 420ms; a bare number is refused rather than guessed at, so an unparseable duration drops out of 計 instead of being counted.
  • とじる for 思考's collapse side (the design names only もっと), and pending_approval as the status string.
  • Pending ticks use meter.static (.28) rather than a new token at the design's .3.

Full detail in .denpa-work/QUESTIONS.md. Not verified: rendered output and a live turn - there is no producer to drive one and no browser here.

## Landed on `issue/denpa-17-log-relay-rows` **298 tests passing in 28 files** (main was 275 in 26). `npm run typecheck` adds no error in any file this branch touches - the four non-vendored errors it reports are the pre-existing ones in `chat-history-panel.tsx`, `live2d-config-context.tsx`, `use-sidebar.ts` and `use-audio-task.ts`. ### What it does - **One log at both sizes.** The 1a overlay now renders the same `LogRail` the 1c rail does. `LogRail` takes `width`, `header` and `edge`, so the overlay fills the stage and keeps its own header + ✕ while the rail stays a 320px column. `App.tsx` stops mounting the upstream chatscope `ChatHistoryPanel`, which closes the B2 inconsistency where the same log looked different at the two sizes. - **`log-rows.ts`** - 受信記録 as pure functions: `logRows` (rows in arrival order, the 中継のみ filter, and the chain footed on the answer it belongs to), `chainSummary` (`3中継 · 1失敗 · 計 1.1s`), `parseDurationMs`, and `liveChain` for the band. - **思考 rows** - `type: 'reasoning'` on `Message`, `appendReasoningMessage` in `ChatHistoryContext`, a `case 'reasoning'` on the socket handler, and a row in `signal` cyan clamped to 4 lines with a `もっと` reveal. Copy says nothing about a complete record: per ADR-0005 it is the 500-character excerpt and there is nothing behind the toggle. - **実況** - the transmission band draws the chain as segment ticks with `中継中 · <tools> · 2/3` and `調べてる…`, and drops them the moment nothing is running. - **承認待ち** is the fourth relay state (`pending_approval`): acid name, `許可が必要`, hold timer in the tail, no glyph. 失敗 still carries no code and offers no retry. - Relay rows have no expand affordance **in the DOM** - a test asserts no `<button>`, no `aria-expanded`, no `<details>` and no `cursor:pointer` inside the spine, and no `全開` anywhere. ### Deliberately left out - **The producer.** `/client-ws` carries no tool and no reasoning message today (`websocket_handler.py:126-455`, `adapter_handler.py:118-122`) - the `tool_call_status` case in the client is inherited upstream plumbing, not something Denpa sends. **The rows render nothing until the go-between forwards the in-process callbacks.** That is go-between work in the other repo. - **The unpaired-row assertion** the decision comment asks for. The client pairs on `tool_id`, not FIFO by name, so the mispairing hazard lives where the id is synthesised - upstream of this client. A row whose completion never arrives draws no glyph and no duration rather than a ✓. - **`検索` and the day divider** - #30's surface. The header shows `受信記録 · 5件 · 中継のみ` and no paging. ### Assumed - A completed relay's `content` is `0.4s` / `420ms`; a bare number is refused rather than guessed at, so an unparseable duration drops out of `計` instead of being counted. - `とじる` for 思考's collapse side (the design names only `もっと`), and `pending_approval` as the status string. - Pending ticks use `meter.static` (`.28`) rather than a new token at the design's `.3`. Full detail in `.denpa-work/QUESTIONS.md`. **Not verified:** rendered output and a live turn - there is no producer to drive one and no browser here.
aiko commented 2026-07-30 05:40:51 +00:00
Author
Owner
Copy link

Review-fix pass on issue/denpa-17-log-relay-rows (483e94b). All five findings addressed; suite is 315 passed in 29 files, typecheck error set byte-identical to main (585).

  • Latched 実況 ticks. ReceiverChrome derives live = aiState === thinking-speaking and gates both the band chain and the log row's mini-meter on it. interrupt never touches messages (use-interrupt.ts:16-39) and no wire message resolves a cut-short relay, so the row keeps running — § 4b has four states and none means "cut off" — but it stops asserting movement. Ledger note filed for the missing 中断 state.
  • Preview leaking into the duration slot. relayDuration runs content through parseDurationMs; a non-duration leaves the slot empty. New data-denpa-relay-tail hook so the test reads that column alone.
  • Preview destroyed on completion. Message.preview (client-side only), captured once per tool_id in the extracted pure upsertToolCall and never overwritten. Rendered regardless of status. A history-data replay bypasses the appender (websocket-handler.tsx:165-167), so a replayed settled row shows a blank preview — ledger note filed; there is no producer at all today (grep -rn "history-data|tool_call_status" --include=*.py over denpa returns zero).
  • Unconditional もっと. reasoningOverflows gates the toggle and the clamp. Counts CJK glyphs as two columns against the 68ch measure, because reading the excerpt as ASCII would hide the toggle on the Japanese copy this client is written in.
  • Colliding 思考 ids. nextReasoningId adds a module counter.

Each fix has a test that was confirmed red against the old code (verified by stashing the source and by targeted reverts). Also removed an unused ModeType import that was this branch's only new typecheck error.

Review-fix pass on `issue/denpa-17-log-relay-rows` (`483e94b`). All five findings addressed; suite is **315 passed in 29 files**, typecheck error set byte-identical to `main` (585). - **Latched 実況 ticks.** `ReceiverChrome` derives `live = aiState === thinking-speaking` and gates both the band chain and the log row's mini-meter on it. `interrupt` never touches `messages` (use-interrupt.ts:16-39) and no wire message resolves a cut-short relay, so the row keeps `running` — § 4b has four states and none means "cut off" — but it stops asserting movement. Ledger note filed for the missing 中断 state. - **Preview leaking into the duration slot.** `relayDuration` runs `content` through `parseDurationMs`; a non-duration leaves the slot empty. New `data-denpa-relay-tail` hook so the test reads that column alone. - **Preview destroyed on completion.** `Message.preview` (client-side only), captured once per `tool_id` in the extracted pure `upsertToolCall` and never overwritten. Rendered regardless of status. A `history-data` replay bypasses the appender (websocket-handler.tsx:165-167), so a replayed *settled* row shows a blank preview — ledger note filed; there is no producer at all today (`grep -rn "history-data|tool_call_status" --include=*.py` over `denpa` returns zero). - **Unconditional もっと.** `reasoningOverflows` gates the toggle *and* the clamp. Counts CJK glyphs as two columns against the 68ch measure, because reading the excerpt as ASCII would hide the toggle on the Japanese copy this client is written in. - **Colliding 思考 ids.** `nextReasoningId` adds a module counter. Each fix has a test that was confirmed red against the old code (verified by stashing the source and by targeted reverts). Also removed an unused `ModeType` import that was this branch's only new typecheck error.
aiko commented 2026-07-30 05:43:52 +00:00
Author
Owner
Copy link

Branch issue/denpa-17-log-relay-rows, pushed. Client-side only — no go-between changes. This supersedes my earlier comment above, which was written before the review pass.

What was built

受信記録 gained two row kinds and a live band readout:

  • 中継 rows — one per tool call, rendering 中継 · tool name · preview · duration · status glyph. Status comes from the wire's four states (running / completed / error / pending_approval); nothing else is invented.
  • 思考 rows — reasoning as marginalia, clamped to 4 lines with a もっと/とじる toggle that only appears when the excerpt plausibly overflows the clamp.
  • 実況 segment ticks on the transmission band, showing the running chain (中継中 · <tool> · 0/1 · <preview>) instead of a spinner.
  • A 計 footer on the answer that follows a chain, summing relay durations — suppressed entirely while any relay is still open, so a partial chain never foots a total.

The row-building logic is a pure module, log-rows.ts, so #30's 記録-browse surface has a boundary to read through. 受信記録's view state (the 中継のみ filter, which 思考 rows are expanded) lives in useReceiverChrome, not in LogRail — the 1a overlay and the 1c rail are separate mounts, and state in the rail would be lost on rotation. Consequently ReceiverChrome's log prop is gone and App no longer mounts ChatHistoryPanel.

Files: components/receiver/log-rows.ts (new), log-rows.test.ts (new), log-rail.tsx, log-rail.test.tsx, receiver-chrome.tsx, receiver-chrome.test.tsx, transmission-band.tsx, chrome-spec.ts, hooks/receiver/use-receiver-chrome.ts, context/chat-history-context.tsx, context/chat-history-rows.test.ts (new), services/websocket-handler.tsx, services/websocket-service.tsx, App.tsx, plus appended .denpa-work/QUESTIONS.md.

Tests

315 passed in 29 files (branch baseline before the fix pass was 300 in 28; main was 275 in 26). Tail:

> vitest run
 RUN  v4.1.10 F:/Projects/denpa-repos/denpa-client/.claude/worktrees/wf_98677da4-b38-2

 Test Files  29 passed (29)
      Tests  315 passed (315)
   Start at  07:40:23
   Duration  5.64s (transform 2.28s, setup 0ms, import 28.81s, tests 1.64s, environment 7ms)

No tests deleted. One pre-existing assertion changed: "opens the log over the stage without unmounting it" now looks for 受信記録's own title rather than an injected marker, because the injection prop no longer exists. The behaviour it guards is unchanged and still asserted.

Coverage is the pure functions (logRows, chainSummary, liveChain, parseDurationMs, reasoningOverflows, upsertToolCall) plus the renderToStaticMarkup output of the rows and band. Every new behavioural test in the fix pass was confirmed red against the old code before being kept — verified by git stash push of log-rail.tsx + receiver-chrome.tsx (3 failures) and by targeted reverts of relayTail, the chain gate and the id minter (3 more).

Typecheck: npm run typecheck emits 585 error TS lines; diff against main's 585 is empty (diffed both directions, not compared by count). npm run lint still dies on the missing eslint-config-airbnb — pre-existing, untouched.

Wire claims, with citations

The go-between sends the client no tool-call message and no reasoning message. Its complete outbound /client-ws vocabulary is full-text (denpa/src/open_llm_vtuber/websocket_handler.py:126), set-model-and-conf (:132, :441), control (:142, :374, :385), error (:273), config-files (:409), background-files (:427), heartbeat-ack (:455), plus notice and user-input-transcription (adapter_handler.py:118, :122). Grepping tool_call_status|reasoning across denpa/src and denpa/hermes_plugin hits only a stale .pyc. So every row this issue adds has no producer today. This branch is the client's half; forwarding is go-between work in the other repo.

The case 'tool_call_status' the client already had is inherited upstream Open-LLM-VTuber plumbing, not a Denpa message — services/websocket-handler.tsx:244, feeding appendOrUpdateToolCallMessage at context/chat-history-context.tsx:118.

The client pairs a tool call's started/completed on tool_id, not FIFO by tool name — chat-history-context.tsx:127 matches msg.tool_id === toolMessageData.tool_id. The mispairing hazard the decision comment describes therefore lives where the id is synthesised, upstream of /client-ws. No client-side unpaired detection was built; see "left out".

{"type": "notice", "text": ...} is rendered verbatim, never spoken — denpa/src/open_llm_vtuber/adapter_handler.py:118. Untouched here; noted only because it is the precedent for how a new client message type arrives.

A relay's duration and preview both ride in content — the design's data note says tool_call_status carries the preview on running and the duration on completed, denpa-client/docs/design/denpa-receiver/README.md:393. This is a design claim, not verified against a running producer, because none exists.

Reasoning is truncated to 500 characters at the source, and a sub-agent's to its first line at 80 — ADR-0005, denpa/docs/adr/0005-the-log-shows-reasoning-not-payloads.md:15, citing hermes-agent agent/conversation_loop.py:5539. I did not open the read-only hermes-agent tree to re-verify that line number; the ADR is the governing source, and the UI only needs the ceiling, which it honours by never promising a complete record.

history-data replaces the whole message array wholesale — websocket-handler.tsx:165-168 — so a type: 'reasoning' message survives a history reload exactly as far as the server replays it. The client drops nothing.

type: 'reasoning' and its text key are client-invented. The issue asks for this message; nothing sends it. The go-between half must emit exactly {"type":"reasoning","text":...} or the two halves drift, which the issue warns about at line 86. Pinned as a contract in QUESTIONS.md:442, and the ?? message.content fallback was dropped so the accepted shape is singular.

Deliberately left out

The three void acceptance criteria stayed void, per the issue's own later comments and ADR-0005: no expandable ARGS/RESULT, no 全開, no inline 再試行 on 失敗. That last one cannot be satisfied — nothing on the wire can re-invoke a single tool, and the design says so explicitly.

Also out: 検索 and the 4a header's day divider (7月29日) — those are #30's 記録-browse surface. No paging seam was built, only the pure logRows boundary. The unpaired-tool-call assertion the decision comment asks for was not built client-side (the client pairs by tool_id; the hazard is upstream). chat-history-panel.tsx is now unreferenced by anything but was not deleted — denpa#9's ledger entry owns the upstream-sidebar deletion pass.

Could not be verified at all

I cannot see rendered output and cannot drive a live turn — and here a live turn is not merely inconvenient but impossible, since no producer exists for either row kind. What is verified is what renderToStaticMarkup emits and what the pure functions compute. Specifically unverified:

  • That the clamped 思考 row clamps to 4 lines in a real engine. The assertion is on the emitted -webkit-line-clamp:4, not on layout.
  • That the filter and もっと buttons behave when clicked. Vitest runs environment: 'node' with no testing-library, so no test in this repo can fire an event. The state they drive lives in useReceiverChrome and is covered only by its shape.
  • That the segment ticks read as a chain rather than as noise, at either size.
  • That the unified overlay looks right filling the stage.
  • That the 承認待ち row's hold timer renders anything sensible, since nothing sends one.
  • The typecheck baseline is a by-path / by-diff verification, not a by-count one — I did not re-measure main in a second checkout, because the ledger warns that tearing down a junctioned worktree empties the shared node_modules.

Assumptions

  1. A completed relay's duration arrives in content as 0.4s or 420ms. A bare number is refused rather than guessed at a unit, so an unrecognised duration drops out of the 計 clause instead of being counted as milliseconds. A chain with a relay still running shows no total at all.
  2. The mobile overlay and the 1c rail are the same component (the ledger flagged this as § 4a work), hence the removed log prop and the unmounted ChatHistoryPanel.
  3. 受信記録's view state belongs in useReceiverChrome — a pre-existing test forbids useState in the chrome components, and rail-local state would be dropped on rotation.
  4. とじる is the collapse side of もっと; the design names only もっと. pending_approval is the status string for 承認待ち, and its hold timer is read from the row's content. Nothing sends either yet.
  5. A chain of relays belongs to the answer that follows it, and a new question closes an open chain — so an answerless turn cannot foot the next answer's summary.
  6. Live ticks reuse meter.static (rgba(255,45,149,.28)) for pending rather than minting a token at the design's .3. Two magenta washes two hundredths apart are indistinguishable, and adding to the shared denpa-tokens.ts invites the add/add conflict B2 already paid for.

Review findings

A reviewer raised 10 findings (5 major, 5 minor). Nine are fixed:

  • Latched 実況 ticks (transmission-band.tsx:132) — liveChain returned non-null while any trailing relay was running, and use-interrupt.ts never touches messages, so 割り込み mid-tool left 中継中 · <tool> · 0/1 painted on the band through IDLE and every later idle state. ReceiverChrome now derives live = aiState === AiStateEnum.THINKING_SPEAKING and passes chain={live ? liveChain(messages) : null}. The same flag reaches LogRail, and RelayGlyph holds the running row's mini-meter at the static bar (the reduced-motion treatment relayMeterBars already specifies) when the turn is over, so the row stops animating too.
  • relayTail printed content verbatim on completion (log-rail.tsx:81) — since the appender keeps prior content when an update's content is falsy, a completed message with no duration left the running preview rendering inside the 10px DotGothic16 duration slot as if it were a timing readout. It now runs through the existing parseDurationMs and returns '' when the string is not a duration. Added a data-denpa-relay-tail hook so the test reads that column in isolation — my first version of that test passed accidentally against the old code, and the attribute made it honestly red.
  • The preview was destroyed on completion (log-rail.tsx:131) — no row ever showed preview and duration, leaving a settled log as tool names and timings with the one narrative field blank, which is the field ADR-0005 kept when it cut ARGS/RESULT. Added preview?: string to Message (client-side only, documented as such), extracted the updater into a pure exported upsertToolCall that captures preview on first sight of a tool_id and never overwrites it. The flex:1 slot now renders relayPreview(message) regardless of status, with the full string on title as § 4a asks. It falls back to a running row's content so a history-data replay — which calls setMessages verbatim and bypasses the appender — still says what she did mid-flight.
  • もっと rendered unconditionally (log-rail.tsx:173) — a one-line sub-agent excerpt (the common case per ADR-0005) got a 44px control announcing hidden text that did not exist. reasoningOverflows is pure and tested: newline count over REASONING_CLAMP_LINES, or visual width over 4×68 columns counting a CJK glyph as two. The clamp is gated with the toggle so a short row is not clipped with no reveal. The wide-char weighting matters — ASCII-only measurement would have hidden the toggle on exactly the Japanese copy this client is written in, which is the opposite bug.
  • Colliding reasoning ids (chat-history-context.tsx:1051) — reasoning-${Date.now()} duplicated on same-millisecond arrivals, yielding duplicate React keys and a shared reasoningExpanded entry, so もっと on one row expanded every colliding row. nextReasoningId() now appends a module-scope counter.
  • 計 printed through a suspended chain (log-rows.ts:61) — pending_approval is now treated like running when deciding whether to print a total.
  • Missing aria-expanded / aria-controls on the もっと control — added; the reasoning Text got an id to point at.
  • 'drops the ticks once no relay is running' was misnamed and covered the wrong branch — the fixture's m2 was still running, and the ticks vanished only because a trailing ai message broke liveChain out early. Renamed to what it tests, and the real case (trailing running relay with aiState: INTERRUPTED/IDLE) was added; it failed against the old code.
  • A vacuous assertion in 'draws her reasoning as marginalia' — not.toContain('もっと') passed trivially because the label switches to とじる. Replaced with the real property.

Out of findings but in the gate: removed an unused ModeType import in hooks/sidebar/use-sidebar.ts, this branch's single new typecheck error.

One finding skipped, with justification

The second half of the latch fix — mutating messages on interrupt / conversation-chain-end to resolve trailing running relays — was not done. There is no honest terminal status to assign. § 4b enumerates four states derived from the wire; an interrupted relay is none of them. completed would paint a ✓ it did not earn, error would paint 失敗 it did not do. Adding a fifth state is a design change to § 4b, not a review fix, and the reviewer's own two-hop-honesty argument cuts against inventing a status the wire never sent. The visible symptom the finding names — the band latching, the row animating forever — is fully closed by the live gate. Both unblock paths (a 中断 state, or per-tool_id cancellation forwarded by the go-between) are recorded in QUESTIONS.md with what would change.

Note on the working tree

The branch was already checked out at .claude/worktrees/wf_98677da4-b38-2, so git checkout in the main checkout failed ("already used by worktree"). Rather than tear down a worktree another process might be tracking, I worked in it and junctioned node_modules as the brief describes. Same branch, same commit, pushed.

Branch `issue/denpa-17-log-relay-rows`, pushed. Client-side only — no go-between changes. This supersedes my earlier comment above, which was written before the review pass. ## What was built 受信記録 gained two row kinds and a live band readout: - **中継 rows** — one per tool call, rendering `中継 · tool name · preview · duration · status glyph`. Status comes from the wire's four states (running / completed / error / pending_approval); nothing else is invented. - **思考 rows** — reasoning as marginalia, clamped to 4 lines with a `もっと`/`とじる` toggle that only appears when the excerpt plausibly overflows the clamp. - **実況 segment ticks** on the transmission band, showing the running chain (`中継中 · <tool> · 0/1 · <preview>`) instead of a spinner. - **A `計` footer** on the answer that follows a chain, summing relay durations — suppressed entirely while any relay is still open, so a partial chain never foots a total. The row-building logic is a pure module, `log-rows.ts`, so #30's 記録-browse surface has a boundary to read through. 受信記録's view state (the `中継のみ` filter, which 思考 rows are expanded) lives in `useReceiverChrome`, not in `LogRail` — the 1a overlay and the 1c rail are separate mounts, and state in the rail would be lost on rotation. Consequently `ReceiverChrome`'s `log` prop is gone and `App` no longer mounts `ChatHistoryPanel`. Files: `components/receiver/log-rows.ts` (new), `log-rows.test.ts` (new), `log-rail.tsx`, `log-rail.test.tsx`, `receiver-chrome.tsx`, `receiver-chrome.test.tsx`, `transmission-band.tsx`, `chrome-spec.ts`, `hooks/receiver/use-receiver-chrome.ts`, `context/chat-history-context.tsx`, `context/chat-history-rows.test.ts` (new), `services/websocket-handler.tsx`, `services/websocket-service.tsx`, `App.tsx`, plus appended `.denpa-work/QUESTIONS.md`. ## Tests **315 passed in 29 files** (branch baseline before the fix pass was 300 in 28; `main` was 275 in 26). Tail: ``` > vitest run RUN v4.1.10 F:/Projects/denpa-repos/denpa-client/.claude/worktrees/wf_98677da4-b38-2 Test Files 29 passed (29) Tests 315 passed (315) Start at 07:40:23 Duration 5.64s (transform 2.28s, setup 0ms, import 28.81s, tests 1.64s, environment 7ms) ``` No tests deleted. One pre-existing assertion changed: *"opens the log over the stage without unmounting it"* now looks for 受信記録's own title rather than an injected marker, because the injection prop no longer exists. The behaviour it guards is unchanged and still asserted. Coverage is the pure functions (`logRows`, `chainSummary`, `liveChain`, `parseDurationMs`, `reasoningOverflows`, `upsertToolCall`) plus the `renderToStaticMarkup` output of the rows and band. Every new behavioural test in the fix pass was confirmed **red** against the old code before being kept — verified by `git stash push` of `log-rail.tsx` + `receiver-chrome.tsx` (3 failures) and by targeted reverts of `relayTail`, the chain gate and the id minter (3 more). Typecheck: `npm run typecheck` emits 585 `error TS` lines; `diff` against `main`'s 585 is empty (diffed both directions, not compared by count). `npm run lint` still dies on the missing `eslint-config-airbnb` — pre-existing, untouched. ## Wire claims, with citations **The go-between sends the client no tool-call message and no reasoning message.** Its complete outbound `/client-ws` vocabulary is `full-text` (`denpa/src/open_llm_vtuber/websocket_handler.py:126`), `set-model-and-conf` (`:132`, `:441`), `control` (`:142`, `:374`, `:385`), `error` (`:273`), `config-files` (`:409`), `background-files` (`:427`), `heartbeat-ack` (`:455`), plus `notice` and `user-input-transcription` (`adapter_handler.py:118`, `:122`). Grepping `tool_call_status|reasoning` across `denpa/src` and `denpa/hermes_plugin` hits only a stale `.pyc`. So every row this issue adds has **no producer today**. This branch is the client's half; forwarding is go-between work in the other repo. **The `case 'tool_call_status'` the client already had is inherited upstream Open-LLM-VTuber plumbing, not a Denpa message** — `services/websocket-handler.tsx:244`, feeding `appendOrUpdateToolCallMessage` at `context/chat-history-context.tsx:118`. **The client pairs a tool call's started/completed on `tool_id`, not FIFO by tool name** — `chat-history-context.tsx:127` matches `msg.tool_id === toolMessageData.tool_id`. The mispairing hazard the decision comment describes therefore lives where the id is synthesised, upstream of `/client-ws`. No client-side unpaired detection was built; see "left out". **`{"type": "notice", "text": ...}` is rendered verbatim, never spoken** — `denpa/src/open_llm_vtuber/adapter_handler.py:118`. Untouched here; noted only because it is the precedent for how a new client message type arrives. **A relay's duration and preview both ride in `content`** — the design's data note says `tool_call_status` carries the preview on `running` and the duration on `completed`, `denpa-client/docs/design/denpa-receiver/README.md:393`. This is a **design claim, not verified against a running producer**, because none exists. **Reasoning is truncated to 500 characters at the source, and a sub-agent's to its first line at 80** — ADR-0005, `denpa/docs/adr/0005-the-log-shows-reasoning-not-payloads.md:15`, citing hermes-agent `agent/conversation_loop.py:5539`. I did not open the read-only hermes-agent tree to re-verify that line number; the ADR is the governing source, and the UI only needs the ceiling, which it honours by never promising a complete record. **`history-data` replaces the whole message array wholesale** — `websocket-handler.tsx:165-168` — so a `type: 'reasoning'` message survives a history reload exactly as far as the server replays it. The client drops nothing. **`type: 'reasoning'` and its `text` key are client-invented.** The issue asks for this message; nothing sends it. The go-between half must emit exactly `{"type":"reasoning","text":...}` or the two halves drift, which the issue warns about at line 86. Pinned as a contract in `QUESTIONS.md:442`, and the `?? message.content` fallback was dropped so the accepted shape is singular. ## Deliberately left out The three void acceptance criteria stayed void, per the issue's own later comments and ADR-0005: no expandable ARGS/RESULT, no `全開`, no inline `再試行` on 失敗. That last one **cannot be satisfied** — nothing on the wire can re-invoke a single tool, and the design says so explicitly. Also out: `検索` and the 4a header's day divider (`7月29日`) — those are #30's 記録-browse surface. No paging seam was built, only the pure `logRows` boundary. The unpaired-tool-call assertion the decision comment asks for was not built client-side (the client pairs by `tool_id`; the hazard is upstream). `chat-history-panel.tsx` is now unreferenced by anything but was **not deleted** — denpa#9's ledger entry owns the upstream-sidebar deletion pass. ## Could not be verified at all I cannot see rendered output and cannot drive a live turn — and here a live turn is not merely inconvenient but impossible, since no producer exists for either row kind. What is verified is what `renderToStaticMarkup` emits and what the pure functions compute. Specifically unverified: - That the clamped 思考 row clamps to 4 lines in a real engine. The assertion is on the emitted `-webkit-line-clamp:4`, not on layout. - That the filter and `もっと` buttons behave when clicked. Vitest runs `environment: 'node'` with no testing-library, so **no test in this repo can fire an event**. The state they drive lives in `useReceiverChrome` and is covered only by its shape. - That the segment ticks read as a chain rather than as noise, at either size. - That the unified overlay looks right filling the stage. - That the 承認待ち row's hold timer renders anything sensible, since nothing sends one. - The typecheck baseline is a by-path / by-diff verification, not a by-count one — I did not re-measure `main` in a second checkout, because the ledger warns that tearing down a junctioned worktree empties the shared `node_modules`. ## Assumptions 1. A completed relay's duration arrives in `content` as `0.4s` or `420ms`. A bare number is **refused** rather than guessed at a unit, so an unrecognised duration drops out of the `計` clause instead of being counted as milliseconds. A chain with a relay still running shows no total at all. 2. The mobile overlay and the 1c rail are the same component (the ledger flagged this as § 4a work), hence the removed `log` prop and the unmounted `ChatHistoryPanel`. 3. 受信記録's view state belongs in `useReceiverChrome` — a pre-existing test forbids `useState` in the chrome components, and rail-local state would be dropped on rotation. 4. `とじる` is the collapse side of `もっと`; the design names only `もっと`. `pending_approval` is the status string for 承認待ち, and its hold timer is read from the row's `content`. Nothing sends either yet. 5. A chain of relays belongs to the answer that follows it, and a new question closes an open chain — so an answerless turn cannot foot the next answer's summary. 6. Live ticks reuse `meter.static` (`rgba(255,45,149,.28)`) for pending rather than minting a token at the design's `.3`. Two magenta washes two hundredths apart are indistinguishable, and adding to the shared `denpa-tokens.ts` invites the add/add conflict B2 already paid for. ## Review findings A reviewer raised 10 findings (5 major, 5 minor). Nine are fixed: - **Latched 実況 ticks** (`transmission-band.tsx:132`) — `liveChain` returned non-null while any trailing relay was `running`, and `use-interrupt.ts` never touches `messages`, so 割り込み mid-tool left `中継中 · <tool> · 0/1` painted on the band through IDLE and every later idle state. `ReceiverChrome` now derives `live = aiState === AiStateEnum.THINKING_SPEAKING` and passes `chain={live ? liveChain(messages) : null}`. The same flag reaches `LogRail`, and `RelayGlyph` holds the running row's mini-meter at the static bar (the reduced-motion treatment `relayMeterBars` already specifies) when the turn is over, so the row stops animating too. - **`relayTail` printed `content` verbatim on completion** (`log-rail.tsx:81`) — since the appender keeps prior content when an update's content is falsy, a completed message with no duration left the *running preview* rendering inside the 10px DotGothic16 duration slot as if it were a timing readout. It now runs through the existing `parseDurationMs` and returns `''` when the string is not a duration. Added a `data-denpa-relay-tail` hook so the test reads that column in isolation — my first version of that test passed accidentally against the old code, and the attribute made it honestly red. - **The preview was destroyed on completion** (`log-rail.tsx:131`) — no row ever showed preview *and* duration, leaving a settled log as tool names and timings with the one narrative field blank, which is the field ADR-0005 kept when it cut ARGS/RESULT. Added `preview?: string` to `Message` (client-side only, documented as such), extracted the updater into a pure exported `upsertToolCall` that captures `preview` on first sight of a `tool_id` and never overwrites it. The flex:1 slot now renders `relayPreview(message)` regardless of status, with the full string on `title` as § 4a asks. It falls back to a running row's `content` so a `history-data` replay — which calls `setMessages` verbatim and bypasses the appender — still says what she did mid-flight. - **`もっと` rendered unconditionally** (`log-rail.tsx:173`) — a one-line sub-agent excerpt (the common case per ADR-0005) got a 44px control announcing hidden text that did not exist. `reasoningOverflows` is pure and tested: newline count over `REASONING_CLAMP_LINES`, or visual width over 4×68 columns counting a CJK glyph as two. The clamp is gated with the toggle so a short row is not clipped with no reveal. The wide-char weighting matters — ASCII-only measurement would have hidden the toggle on exactly the Japanese copy this client is written in, which is the opposite bug. - **Colliding reasoning ids** (`chat-history-context.tsx:1051`) — `reasoning-${Date.now()}` duplicated on same-millisecond arrivals, yielding duplicate React keys and a *shared* `reasoningExpanded` entry, so `もっと` on one row expanded every colliding row. `nextReasoningId()` now appends a module-scope counter. - **`計` printed through a suspended chain** (`log-rows.ts:61`) — `pending_approval` is now treated like `running` when deciding whether to print a total. - **Missing `aria-expanded` / `aria-controls`** on the `もっと` control — added; the reasoning `Text` got an id to point at. - **`'drops the ticks once no relay is running'` was misnamed** and covered the wrong branch — the fixture's `m2` was still `running`, and the ticks vanished only because a trailing ai message broke `liveChain` out early. Renamed to what it tests, and the real case (trailing `running` relay with `aiState: INTERRUPTED`/`IDLE`) was added; it failed against the old code. - **A vacuous assertion** in `'draws her reasoning as marginalia'` — `not.toContain('もっと')` passed trivially because the label switches to `とじる`. Replaced with the real property. Out of findings but in the gate: removed an unused `ModeType` import in `hooks/sidebar/use-sidebar.ts`, this branch's single new typecheck error. ### One finding skipped, with justification The second half of the latch fix — **mutating `messages` on `interrupt` / `conversation-chain-end` to resolve trailing `running` relays** — was not done. There is no honest terminal status to assign. § 4b enumerates four states derived from the wire; an interrupted relay is none of them. `completed` would paint a ✓ it did not earn, `error` would paint 失敗 it did not do. Adding a fifth state is a design change to § 4b, not a review fix, and the reviewer's own two-hop-honesty argument cuts against inventing a status the wire never sent. The visible symptom the finding names — the band latching, the row animating forever — is fully closed by the `live` gate. Both unblock paths (a 中断 state, or per-`tool_id` cancellation forwarded by the go-between) are recorded in `QUESTIONS.md` with what would change. ## Note on the working tree The branch was already checked out at `.claude/worktrees/wf_98677da4-b38-2`, so `git checkout` in the main checkout failed (*"already used by worktree"*). Rather than tear down a worktree another process might be tracking, I worked in it and junctioned `node_modules` as the brief describes. Same branch, same commit, pushed.
aiko commented 2026-07-30 13:32:55 +00:00
Author
Owner
Copy link

Shipped. Merged to main at 0e91bd9 (phase C1).

Closed as part of reconciling the board with main: the autonomous run's policy was not to auto-close, so shipped work stayed open and the tracker read as though nothing had landed. That policy is now reversed — issues close when they land.

Shipped. Merged to `main` at [`0e91bd9`](https://git.aiko.works/aiko/denpa/commit/0e91bd9) (phase C1). Closed as part of reconciling the board with `main`: the autonomous run's policy was not to auto-close, so shipped work stayed open and the tracker read as though nothing had landed. That policy is now reversed — issues close when they land.
aiko closed this issue 2026-07-30 13:32:55 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feat/88-openwakeword-beside-silero
prototype/seam-and-pending
issue/denpa-49-onboarding-fills-viewport
issue/denpa-35-mic-capture-into-rust
issue/denpa-32-proactive-break-in
issue/denpa-28-onboarding
issue/denpa-29-settings-sheet
issue/denpa-19-approval-surface
issue/denpa-31-screen-share-grant
issue/denpa-27-two-hop-status
issue/denpa-17-log-relay-rows
issue/denpa-23-android-overlay-pal
issue/denpa-9-cut-group-camera-browser
integrate/denpa-18-pal
integrate/denpa-16-tablet
issue/denpa-12-mobile-chrome
issue/denpa-18-desktop-transparent-pal
issue/denpa-16-tablet-landscape
issue/denpa-10-design-tokens
docs/denpa-receiver-handoff
build
dev
R4-test
neo-mic
mic-test
close-button
pre-autonomous-run-2026-07-30
v1.2.1
v1.2.0
v1.1.0
v1.0.0
Labels
Clear labels   
needs-info
Waiting on reporter

  
needs-triage
Maintainer needs to evaluate

  
ready-for-agent
Fully specified, AFK-ready

  
ready-for-human
Needs human implementation

  
v2
Out of scope for v1; see the wayfinder map

  
wayfinder:grilling

   
wayfinder:map

   
wayfinder:prototype

   
wayfinder:research

   
wayfinder:task

   
wayfinder:ticket

   
wontfix
Will not be actioned

No labels
needs-info
needs-triage
ready-for-agent
ready-for-human
v2
wayfinder:grilling
wayfinder:map
wayfinder:prototype
wayfinder:research
wayfinder:task
wayfinder:ticket
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
aiko/denpa#17
No description provided.