diff --git a/work-items/open/20260530-053721-tui-inflight-composer-injection/item.md b/work-items/open/20260530-053721-tui-inflight-composer-injection/item.md new file mode 100644 index 00000000..f25d938f --- /dev/null +++ b/work-items/open/20260530-053721-tui-inflight-composer-injection/item.md @@ -0,0 +1,74 @@ +--- +id: 20260530-053721-tui-inflight-composer-injection +slug: tui-inflight-composer-injection +title: Support immediate in-flight TUI composer injection +status: open +kind: feature +priority: P2 +labels: [tui, worker, interrupt, ux] +created_at: 2026-05-30T05:37:21Z +updated_at: 2026-05-30T05:38:11Z +assignee: null +legacy_ticket: null +--- + +## Background + +The TUI currently lets the user press Enter while a Pod is executing, but that input is queued for the next turn. This is useful when the user wants to continue the task after the current run finishes. + +There is a separate UX need: while the model is in the middle of a long run with tool calls, the user may want to send urgent supplemental context that should be seen as soon as possible, ideally between tool calls / LLM calls during the current run. This is different from ordinary queued input. + +We want both modes: + +- **after-run queue**: “when this task finishes, continue with this next request.” +- **in-flight injection**: “while you are still working, please incorporate this additional context as soon as safe.” + +This ticket is for designing and implementing an explicit TUI path for the second mode without breaking the existing queued-input behavior. + +## Requirements + +- Preserve the current Enter-while-running behavior as the after-run queue. +- Add an explicit user action / keybinding / command for immediate in-flight injection while a run is active. +- In-flight injected text must be delivered through the Pod/Worker history path, not as hidden context-only injection. It must satisfy the project principle that new input placed into LLM context is first appended to `worker.history` / persisted history. +- In-flight injection should be consumed at safe boundaries, such as before the next LLM request or between tool-call cycles, not by mutating an already-open provider stream. +- The UI must make the distinction visible: queued-for-next-turn vs injected-into-current-run. +- If no run is active, the immediate-injection action should either behave like normal submit or clearly report that there is no in-flight run to inject into. +- If the current turn cannot accept in-flight input at a safe boundary, the UI should fail closed or fall back to explicit queued mode with a visible notice; do not silently drop input. +- Preserve TUI-local input history behavior for submitted/queued text. + +## Non-goals + +- Do not interrupt/cancel the current run as part of this ticket. +- Do not mutate provider streams already in progress. +- Do not introduce hidden system-reminder/context-only messages that are not recorded in history. +- Do not remove the existing queued composer behavior. +- Do not redesign the entire Pod notification/input protocol unless a small typed Method/Event extension is required. + +## Open design questions + +- What should the TUI action be? + - Separate command such as `:inject`? + - Modified Enter keybinding such as Ctrl+Enter / Alt+Enter? + - Action menu entry? +- What Pod protocol shape is best? + - Existing `Method::Notify` may already represent in-flight user-visible context, but semantics must be checked. + - A new typed method such as `Method::InjectInput` may be clearer if `Notify` is too generic. +- What history item should represent the injected text? + - User item? + - System item with user-originated note? + - Existing Notify / PodEvent item? +- What exact safe boundaries are supported in `Worker` / controller today? + - before the next LLM request; + - before resuming after tool results; + - while a tool call is running; + - while provider stream is open. +- How should the UI display pending in-flight injection versus after-run queue? + +## Acceptance criteria + +- TUI users can choose between after-run queued submit and immediate in-flight injection while a Pod is running. +- In-flight injected input is recorded in history before it can influence an LLM request. +- In-flight injection is consumed only at safe boundaries and never mutates an active provider stream. +- The TUI visibly distinguishes queued-next-turn input from injected-current-run input. +- Existing queued Enter behavior remains intact. +- Tests cover TUI input routing, protocol/controller handling, worker history append behavior, and safe-boundary behavior. diff --git a/work-items/open/20260530-053721-tui-inflight-composer-injection/thread.md b/work-items/open/20260530-053721-tui-inflight-composer-injection/thread.md new file mode 100644 index 00000000..524ad457 --- /dev/null +++ b/work-items/open/20260530-053721-tui-inflight-composer-injection/thread.md @@ -0,0 +1,33 @@ + + +## Created + +Created by tickets.sh create. + +--- + + + +## Plan + +## Initial preflight + +Classification: requirements-sync-needed. + +The user requirement is clear at the UX level: Enter while running remains an after-run queue, and a separate action should inject supplemental context into the current in-flight run as soon as safe. The exact protocol/history representation is not decided yet and must be designed before implementation. + +Critical constraints: +- Do not place injected text into LLM context unless it has first been appended to Worker history / persisted history. +- Do not mutate an active provider stream. +- Consume injected text only at safe boundaries such as before a later LLM request or between tool-call cycles. +- Do not silently drop text; if the active turn cannot accept injection, report/fail closed or explicitly queue. + +Design questions to settle before coding: +- TUI action/keybinding/command name. +- Whether existing `Method::Notify` is semantically sufficient or a new typed method is needed. +- Which history item represents user-originated in-flight supplemental context. +- Which Worker/controller boundaries can actually observe injected input before the next LLM call. +- How queued-next-turn vs injected-current-run is displayed. + + +---