Experimental agent<->human console: feedback/commands in, clickable suggestions out (toggle)

[ivanmkc]

Concept (from the maintainer)

An experimental, toggleable two-way console on the dashboard:

• The human can add feedback, next steps, and type commands that the agent reads from the UI.
• The agent can push suggestions the human just clicks in the UI.

This is the headline use case of the bidirectional-state work in #105 — the "interactive surfaces" substrate, applied to free-text + actions instead of just checkboxes.

Why it's a natural fit

The pieces already exist or are planned:

• agent → human is what the viewer already does (push/patch content). "Clickable suggestions" = an agent-pushed list of action chips.
• human → agent is the new direction designed in Feature: mutable/interactive surfaces — checklists toggled by agent or user (bidirectional state) #105: a bounded, URL-gated POST /interact that persists + broadcasts. A console message is just {kind:"message", text} or {kind:"action", ref} on that channel.
• The agent isn't a browser, so it reads via polling: a new termchart inbox --project --agent [--wait] (or pull returning a messages[]/actions[] array). Low-frequency / only-when-waiting keeps token+latency cost down.

Proposed shape

• Console panel (toggle: off by default — "experimental"): a text box ("feedback / next steps / command") + a send button, plus an agent-suggestions strip of clickable chips the agent pushes (termchart suggest --project --agent --items '["Re-run tests","Switch to LR","Ship it"]'). Clicking a chip or sending text posts to /interact (URL-gated, bounded to text+action — no content injection).
• Agent loop: when an agent wants input, it pushes suggestions, then termchart inbox --wait (long-poll with a timeout) and acts on whatever comes back. When not waiting, it ignores the channel (zero overhead).
• Durability + multi-screen: messages persist with the scope and broadcast over SSE so every screen stays in sync (same as content).

Open questions

• Delivery to the agent: poll vs long-poll vs a since-cursor. (Lean long-poll inbox --wait with a short timeout — cheap, responsive, no busy-loop.)
• Command semantics: free-text the agent interprets, vs a constrained set the agent advertises (safer, clickable). Probably both: chips for common actions, free-text for the rest.
• Toggle scope: per-workspace flag vs a UI-only local toggle.

Builds directly on #105. Behind an experimental flag so it can ship incrementally.

[ivanmkc]

Implemented in #113 (merged) and deployed (rev 00041): experimental, off-by-default agent↔human console. human→agent via tokenless append-only POST /inbox (read with termchart inbox [--wait long-poll]); agent→human via token-gated POST /suggest (termchart suggest chips). In-memory ring (transient, not persisted); tokenless inbox is provably append-only (cannot touch the view spec — test asserts byte-unchanged content); long-poll has leak-free cleanup. Plugin bumped to 0.10.0.