taOStalk slice 1: Tier 0 network push+poll session bridge (flagship)

[jaylfc]

Part of epic #1952. Spec: docs/design/taostalk-acp-bridge.md (PR #1949). Universal network transport: an agent posts turns/status/questions to its taOS channel via A2A/chat API with its registry token; reads operator replies by subscribe-or-poll. Session<->channel registry, presence/lifecycle. ACCEPTANCE: an existing REMOTE session (e.g. @taOS-dev on the Mac) shows live in taOStalk and can be replied to from taOS via the channel, with zero filesystem access. Reuse A2A bus + chat API + the poll sweeps. Tests: session<->channel mapping, reply round-trip, poll fallback when SSE unavailable.

[kilo-code-bot]

This issue appears to be a duplicate of #1952.

EPIC: taOStalk - live agent sessions in taOS chat (tiered transport + parity) (#1952)

Similarity score: 92%

This comment was generated by Kilo Auto-Triage.

[jaylfc]

Spec landed: docs/design/taostalk-slice1.md (PR #2029). Owner decisions locked 2026-07-19: transport = A2A bus + controller SessionEventTranslator (NOT a new chat scope - works day one for @taOS-dev and collab-epic delegated agents, agent auth surface stays closed); per-agent #session-{slug} channel; passive question blocks (no decisions_write dependency - it is unmerged); forward-all replies; minimal curl/bash+ps1 + one OpenClaw hook snippet; and a separate hardening issue for the unauthenticated POST /api/chat/messages handler.

Build split: lead does P0 (envelope schema + SessionEventTranslator + reply forwarder + channel binding + tests) and P1 (connect-a-session wizard backend). Fleet takes the 13 P2 frontend cards (block renderer dispatcher + TextBlock/ThinkingBlock/ToolCallBlock/StatusBlock + unknown-kind fallback + live badge + wizard modal + snippet UI + ps1 twin + component/e2e tests + a11y) - all independently landable, seeded on the taOS board. Minimal demo path: P0 + cards 1-4 + reply forwarder = a remote agent's session visible turn-by-turn and replyable. Full renderer registry is slice 2 (#1954).

[jaylfc]

Backend work order (P0 + P1), spec is docs/design/taostalk-slice1.md on dev - read it first, decisions there are locked.

P0 SessionEventTranslator + forwarder:

1. Controller-side translator consuming session events from the A2A bus (transport decision: reuse the bus, do NOT add a new chat scope). Model the write path on bridge_session.record_reply.
2. The 9-event envelope schema is in spec section 4 (turn_start, text_delta, thinking, tool_call, tool_result, status, question, turn_end, error) mapping onto existing chat_messages content_blocks fields - no schema migration.
3. Per-agent #session-{slug} channel, created lazily on first event; reuse ChatHub broadcast unchanged.
4. Reply forwarder: a human message typed into #session-{slug} is forwarded to the originating agent session (forward-all, no filtering in slice 1).
5. Question events render as passive blocks (no decisions_write dependency - that store is not on dev).

P1 wizard backend: the endpoints the setup wizard needs to enable/disable the bridge per agent and show bridge status. Frontend wizard UI itself is fleet cards, not this order.

Tests: translator unit tests per event kind (all 9), channel-creation idempotency, forwarder round-trip, and an integration test driving a fake session via the bus. The curl/bash session simulator snippet in spec section 8 is the reference driver.

Acceptance (minimal demo): a scripted fake session streams text/thinking/tool_call/status into #session-{slug} live in the Messages app, and a reply typed there reaches the fake session. Pitfalls doc #2040 items 1, 2, 8 and 15 apply.

[jaylfc]

Partial attempt exists and was diagnosed: what to reuse and what to avoid

A fleet lane attempted this slice as board card tsk-43msix and opened PR #2077 (now closed, branch deleted, but the commits remain fetchable via git fetch origin pull/2077/head at bafd7c1d). Recording the diagnosis so the next attempt starts ahead rather than repeating it.

What it produced (598 lines across 4 files):

• desktop/src/apps/chat/ConnectWizard.tsx (new, 393 lines) - connect wizard with bash and PowerShell snippet twins
• desktop/src/apps/chat/blocks.tsx (new, 166 lines) - content-block renderer
• desktop/src/apps/chat/MessageList.tsx - block rendering integration
• desktop/src/apps/MessagesApp.tsx - types plus wizard import

Why it failed CI, and it is not what it looked like. The PR showed 225 TypeScript syntax errors, which reads like incoherent output. It is not. Every one came from a single trap: the file embeds shell snippets inside JS template literals, and shell variables such as collide with JavaScript's own interpolation. Escaping 17 occurrences dropped it from 225 errors to 9. Three of the four files were clean throughout.

What the remaining 9 errors reveal, and this is the real gap. The slice is roughly two thirds done with the integration missing:

1. MessagesApp.tsx:77 imports ConnectWizard and never renders it. The wizard exists but is not wired into the UI.
2. MessageList.tsx:542-543 reads content_blocks off MessageRow, a property that type does not have. The block-rendering path was written against a type nobody extended.
3. ConnectWizard.tsx:89 calls a function with 0 arguments where 1 is required.
4. Unused imports in three files.

For whoever picks this up:

• The snippet twins and the block renderer are worth reading before rewriting; the structure is reasonable.
• Escape as in any shell or PowerShell snippet held in a template literal, or store the snippets as plain strings or separate asset files. This is invisible to anything that does not compile the file.
• Extend MessageRow with content_blocks before wiring the renderer, and actually render the wizard.
• The card is too large for one unattended pass. Split it: type extension plus renderer, then wizard plus snippets, then e2e.

Routing note: this should go to a capable implementer, not a free-model lane. Multi-file feature work with a type extension is exactly the shape those lanes fail on, and this attempt is the evidence.

The executor now runs tsc --noEmit before opening a PR, so this specific failure cannot reach review again.

[jaylfc]

Correction to the comment above: the two code examples in the "Why it failed CI" paragraph were themselves eaten by shell interpolation when I posted it, which is a fittingly exact demonstration of the bug being described. The paragraph should read:

Why it failed CI, and it is not what it looked like. The PR showed 225 TypeScript syntax errors, which reads like incoherent output. It is not. Every one came from a single trap: the file embeds shell snippets inside JS template literals, and shell variables such as ${TAOS_URL:-http://localhost:6969} collide with JavaScript's own ${...} interpolation syntax. Escaping 17 occurrences dropped it from 225 errors to 9. Three of the four files were clean throughout.

And the fix guidance: escape ${ as \${ inside any shell or PowerShell snippet held in a JS template literal, or keep the snippets as plain (non-template) strings or separate asset files.

The class generalises beyond TypeScript: any language that shares ${...} syntax with the shell will do this, and it is invisible to anything that does not actually compile or execute the file. I hit it writing this very comment.