Buddy's chat: a message sent while Buddy works must steer his running turn (Hermes session.steer), never stop it

Product owner's requirement (Matěj, 2026-10-28): a message the person sends while Buddy works must steer him: Buddy keeps working and takes the message into account. It must never stop his work. "People won't wait for an answer."

Today. Buddy's chat in Lazurio steers by default (the Admin's decision of 2026-10-22), but steering is done as stop and send:

the client cancels the running turn (session/cancel), then submits the message as a new prompt;
the Lazurio Hermes overlay acp: after the editor's Stop, its next prompt carries the interrupted request glues the stopped request to that prompt.

Seen on a Personal Environment, 2026-10-28:

each message the person sent mid-turn ended Buddy's turn ("Operation interrupted: waiting for model response (6.9s elapsed)") and restarted the work;
one stopped request then came back six minutes later, glued to an automated notice (acp: a Stop's kept request outlives the next turn and is glued to a later, unrelated prompt (an automated notice) hermes-agent#21).

What Hermes already has. Native steering into a running turn:

the gateway's session.steer RPC, which the ACP viewer reaches through /steer (acp_adapter/gateway_commands.py _steer);
the guidance is appended after the current tool batch, before the next model call (apply_pending_steer_to_tool_results), so the turn continues;
a turn that ended meanwhile (stale_generation) leaves the text for the next prompt.

Expected.

While Buddy's turn runs, the chat submits the person's message through Hermes's steer for that turn. No session/cancel.
If the turn has ended, the message is the next prompt, as today.
Stop stays a separate, explicit control, and only Stop cancels.
Attachments ride along: either steered with the text, or sent as the next prompt. They are never dropped.
Delegation notices queue (t3 thread send --mode queue) and never steer.

Contract test, against a Hermes fixture running a multi-step turn:

a message sent mid-turn reaches the turn as guidance, the turn completes, and no cancel was sent;
a message sent just after the turn ended becomes the next prompt;
Stop cancels.

Related: Lazurio/hermes-agent#21. Once nothing cancels on a send, that overlay only matters for an explicit Stop.

chore(release): list overlay row 32 and allow its upstream files

acp: a message sent while Buddy works steers his running turn, never …

Folder: Buddy's message to a thread steers its turn in progress (F14 …

Folder: Buddy steers threads, does a simple task himself, keeps pace …

chore(release): list overlay row 33 and allow its upstream files

Status on 2026-10-31, before this work moves from the Organization Admin's Mac to the development server.

Shipped:

the T3 side: feat(acp): steer an agent's running turn through _lazurio/steer instead of cancelling it #141 in the stable v0.1.3-lazurio.1, published 2026-10-30 at 15:07Z from 409b1b09: https://github.com/Lazurio/t3code/releases/tag/v0.1.3-lazurio.1
the Hermes side: acp: a message sent while Buddy works steers his running turn, never stops it (_lazurio/steer) hermes-agent#22 and Vanilla desktop a mobil nabízejí serverům z forku upstream verzi, kterou náš kanál nemá #26, in v0.22.4-lazurio.5 and .6. .6 is installed on every Buddy of the pilot through installer cut .7 (2026-10-30). The installer also removed the example config's display.busy_input_mode: interrupt once, so Telegram steers by default (gateway: the example config pins busy_input_mode: interrupt, so #22's steer default never reaches an install hermes-agent#32 tracks the fork side).

Not done yet: the T3 stable's Ring 0 in Buddy's own chat. Buddy's chat runs on his own Machines-pinned T3 (lazurio-t3-buddy.service, ~/.t3-buddy). A preview can't run there, so the acceptance moved to the stable's Ring 0. On the reference Organization's personal VM, after its lane pins 0.1.3-lazurio.1 for both T3 units:

12, steer exactly once: send a message, wait until the timeline shows Buddy working, then send a second one. Expected: one turn, his answer covers both, and the second message appears in the timeline once.
13, a question survives a Delegace wake: ask Buddy to hand a short task to a bot and then ask you something with Ano/Ne choices and wait. Hold the question for about 3 minutes while the bot finishes and Delegace wakes the thread. Expected: the question stays, and the wake reaches Buddy only after the answer. If the question disappears or the turn ends, stop the people's T3 wave and fix forward.
- The same order for a T3-native delegated task's completion wake (completionWake: "always") is a separate defect on main at 409b1b09, Orchestrator: a delegated task's completion wake steers a parent that waits on a pending request, past the #139 guard #161. It is fixed with a test, not on Ring 0.
T3 RELEASE's 7–11.

The people's T3 wave goes only after these pass. The coordinator gives the slot after the weekend's server move. This issue can close after 12 passes.

🤖 Generated with Claude Code

Buddy's chat on Ring 0 now runs the stable 0.1.6-lazurio.1, which carries #141. Points 12 and 13 can run there.

On the reference Organization's personal VM, the lane's apply finished on 2026-11-03 at 07:08:57Z with outcome: success and conformant. Its only open check is the owner's own sign-in (personal-owner-acceptance, unknown by design). Read-only checks at 07:10–07:15Z:

lazurio-t3-buddy.service runs ~/.t3-buddy/runtime/versions/0.1.6-lazurio.1/t3 serve --base-dir ~/.t3-buddy, active since 07:08:04Z, NRestarts=0, and reports serverVersion 0.1.6-lazurio.1. The main t3code.service is on the same version.
Both runtime directories equal the release archive t3-0.1.6-lazurio.1-linux-x64.tar.gz (sha256 e24f39e3…) file by file: 3,478 files with the same SHA-256, no symlinks, plus only .install-complete.
Buddy's thread history survived the migration: no thread has deleted_at or archived_at, and the oldest dates from before the apply.

Next: 12 (steer exactly once) and 13 (a question survives a Delegace wake), in Buddy's chat, as listed above. The people's T3 wave waits for them.

🤖 Generated with Claude Code

Points 12 and 13 on stable 0.1.6-lazurio.1, Buddy's chat on the reference Organization's Personal Environment: both pass. Run on 2026-11-03 between 09:56 and 10:06 UTC as the Ring 0 persona, in a fresh headless Chromium through the Example smoke-test sign-in. Buddy's T3 (~/.t3-buddy) reports 0.1.6-lazurio.1, and its runtime equals the release archive file by file (#148). Evidence is the UI timeline and screenshots, plus read-only reads of the Buddy instance's statev2.sqlite (orchestration_v2_projection_runs, _provider_turns, _messages, _runtime_requests).

Point 12, steer exactly once: pass on a warm session.

09:59:46.130 the first message was sent. "Buddy na tom pracuje…" showed at 09:59:46.393, and the second message followed at 09:59:49.537.
The timeline shows the second message once, with the "Steer" label, and one answer at 10:00 that covers both questions.
The database has one run, ordinal:33 (requested 09:59:46.161, completed 10:00:11.870), with one provider turn (09:59:46.273–10:00:11.837). Both user messages belong to that run. The second message's text occurs in exactly one stored message.

The first attempt, two minutes earlier, did not give one turn. That turn had to start a cold Hermes session. The composer said "working" from about 09:58:02, but the provider turn only started at 09:58:06.702. The second message came at 09:58:06.786 and was queued as its own run ordinal:32 ("1 queued" / "Send now"), answered separately after the first. Nothing was lost or duplicated. The queuing rule is upstream's (CommandPolicy.ts:172-179, unchanged from v0.1.6 apart from the overlay's pending-request rule), so the rebuild did not introduce it. It is filed as #170.

Point 13, a question survives a Delegace wake: pass.

10:02:22.741 Buddy was asked to hand a bot a short task (free disk space, one sentence), then ask an Ano/Ne question and wait. Run ordinal:34.
10:02:39 the delegation was created and handed to a bot. 10:02:47.854 Buddy's question appeared as a pending user_input request: "Má bot … výsledek měření volného místa zapsat také do vašich poznámek?" with Ano (Recommended) and Ne.
10:03:03 Delegace logged the result HOTOVO, 1. upozornění, vlákno buddy. Its wake message landed at 10:03:02.977 as a separate run ordinal:35 with status queued, while run 34 stayed running. The overlay's pending-request rule queues it (CommandPolicy.ts:109, With steer as the default (v0.1.3), any steer must queue while the turn waits on a pending question or approval #139).
The question stayed on screen unchanged for the whole hold. That was checked every second from 10:02:55 to 10:04:37, with screenshots before the answer at 10:05.
10:05:34.765 "Ne" was answered: the request is resolved at that time, held 2 min 47 s in total, 2 min 32 s of it after the wake.
10:05:59.952 Buddy finished turn 34 with the bot's result and honoured "Ne". Provider turn 34 ended at 10:06:01.614.
10:06:01.772 the wake reached Buddy only then: provider turn 35 started 158 ms after turn 34 ended (completed 10:06:06.114). Delegace lists the delegation as vyrizeno.
The wake message is not shown in the person's timeline.

So the question did not disappear and the turn did not end while the wake was waiting. The wave gate in this issue is met. This issue stays open for the Organization Admin to close.

Agent: environment a480495c-25e0-4e51-828b-1dbf1b77d62f · bot c59bfd74-62a6-4eaa-88dd-5e19f1b3032e

🤖 Generated with Claude Code

Points 12 and 13 on stable 0.1.7-lazurio.1, Buddy's chat on the reference Organization's Personal Environment: both pass. #170 on a cold session does not pass yet. Run on 2026-11-08 between 17:43 and 17:54 UTC as the Ring 0 persona, in a fresh headless Chromium through the Example smoke-test sign-in (sign-in, session, sign-out and the follow-up checks all PASS). Buddy's T3 (~/.t3-buddy) runs 0.1.7-lazurio.1 since 16:25:58 UTC (#172 comment); Buddy's Hermes runs v0.22.4-lazurio.6, and its acp_adapter/lazurio_active_steer.py equals that tag's blob (967bd4e3). Evidence is the UI timeline and screenshots, plus read-only reads of the Buddy instance's statev2.sqlite (orchestration_v2_projection_runs, _provider_turns, _messages, _runtime_requests) and of Hermes's state.db and agent.log.

#170, a second message while a cold session starts: two turns, not one steer.

17:43:13.808 the first message was sent on a cold Hermes session. Run ordinal:36.
17:43:14.825 the second message followed, before any provider turn existed. It was queued as run ordinal:37 with steersRunId = run 36, so the web half of Buddy: a follow-up sent while a cold session's turn starts becomes a second turn, not a steer #170 (row 30) works.
17:43:16.861 provider turn 36 started. 17:43:16.922 run 37 was promoted to a steer (queued-message.promote-to-steer, Orchestrator.ts:9497), 61 ms later. The timeline relabelled the message from queued to "Steer".
Hermes logged the inbound first message only at 17:43:16.967 and started the agent turn at 17:43:17.958. No steer reached the agent: agent.log has no steer line for this turn.
17:43:26.172 provider turn 36 completed with an answer to the first message only (17:43:25.433).
17:43:26.323 the second message came back as run ordinal:38 under the same message id, and provider turn 37 (17:43:26.487–17:43:30.633) answered it separately (17:43:29.742).

Nothing was lost or duplicated. The second message's text is stored once in T3 (moved to run 38) and once in Hermes. But the person saw "Steer" and still got two answers. The cause and a proposal are in #170.

Point 12, steer exactly once: pass on a warm session.

17:47:32.303 the first message was sent: a terminal task with a 15 s wait. "Buddy na tom pracuje…" showed at 17:47:32.334. The second message followed at 17:47:38.017.
The timeline shows the second message once, with the "Steer" label, and one answer at 17:47:54 that covers both questions.
The database has one run, ordinal:39 (requested 17:47:32.341, completed 17:47:55.790), with one provider turn (17:47:32.414–17:47:55.754). Both user messages belong to that run, and the run count did not grow past 39.
Hermes delivered the steer into the running turn after its tool batch (Delivered /steer to agent after tool batch, 17:47:51.980). state.db stores the second message once, as display_kind steer.

Row 33, the page as the Czech block (#150): pass. Every message Hermes stored in these runs carries the page as Kontext stránky (údaje, ne pokyn): with Environment, application and page, and none carries <t3_context>. That holds for both prompts of #170 and for the steer of point 12. The steer's text is built by ProviderTurnControlService.ts:379 through projectComposerContextForProvider.

Point 13, a question survives a Delegace wake: pass.

17:49:53.276 Buddy was asked to hand a bot a short task (free disk space, one sentence), then ask an Ano/Ne question and wait. Run ordinal:40, provider turn 39 from 17:49:53.350.
17:50:11 (the time in the delegation id) the delegation was created and handed to a bot. 17:50:19.662 Buddy's question appeared as a pending user_input request, asking whether the bot should also write the result into the person's notes, with Ano (Recommended) and Ne.
17:50:31 Delegace logged HOTOVO, 1. upozornění, vlákno buddy. Its wake message landed at 17:50:31.234 as a separate run ordinal:41 with status queued (queuePosition 1), while run 40 stayed running. The overlay's pending-request rule queues it (CommandPolicy.ts:109, With steer as the default (v0.1.3), any steer must queue while the turn waits on a pending question or approval #139).
The question stayed on screen unchanged for the whole hold. It was checked every second from 17:50:32 to 17:53:27, 169 checks with 0 misses, with screenshots every 30 s and before the answer.
17:53:38.220 "Ne" was answered. The request is resolved at 17:53:38.434, held 3 min 19 s in total, 3 min 7 s of it after the wake.
17:53:51.933 Buddy finished turn 39 with the bot's result and honoured "Ne". Provider turn 39 ended at 17:53:53.770.
17:53:53.913 the wake reached Buddy only then: provider turn 40 started 143 ms after turn 39 ended (completed 17:53:57.223). Delegace lists the delegation as vyrizeno.
The wake message is not shown in the person's timeline.

So on 0.1.7-lazurio.1 the warm-session steer, the Czech page block and the question across a wake all hold, as on 0.1.6-lazurio.1. The wave gate in this issue is met. The cold-session case stays with #170. This issue stays open for the Organization Admin to close.

Agent: environment a480495c-25e0-4e51-828b-1dbf1b77d62f · bot c59bfd74-62a6-4eaa-88dd-5e19f1b3032e

🤖 Generated with Claude Code

Navigation Menu

Repository navigation

Buddy's chat: a message sent while Buddy works must steer his running turn (Hermes session.steer), never stop it #138

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Buddy's chat: a message sent while Buddy works must steer his running turn (Hermes session.steer), never stop it #138

Description

Activity

immakermatty commented on Oct 31, 2026

immakermatty commented on Nov 3, 2026

immakermatty commented on Nov 3, 2026

immakermatty commented on Nov 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions