Opt-In Input Recovery
Opt-In Assistant Input
Recovery and chat remain visible without taking keyboard input until the operator asks for it.
0 milestones 4 tasks
2 plan 4 execute 4 review
59m 37s total 12m 20s per task
This run changed two assistant-adjacent input surfaces that could otherwise surprise an operator. A recovery blocker still had to stop the engine and wait for a real answer, and a bare assistant session still had to make the chat pane visible, but neither surface was allowed to capture ordinary typing just because it appeared.
The work started in the prompt domain, moved through the recovery overlay and chat composer, then ended with compatibility cleanup. The current tree has since renamed some of the recovery vocabulary into blocker terminology, but the surviving behavior is the same contract the run set out to install: visible assistance is not the same thing as keyboard ownership.
How this walkthrough is structured
Feature
What did the run build and ship?
Gantry now keeps recovery blockers and assistant chat discoverable while requiring an explicit action before text input reaches either surface.
Build
How did Gantry structure the work?
The cut put the prompt marker before the two interface changes, then used the final sprint to verify that the integrated input contract had not left older assumptions behind.
Recovery Prompt Marker
2 agents 12m 32s wall time
The exact marker has been absorbed into the current investigation prompt model, so this sprint is no longer visible as a standalone variant named for recovery. What remains is the first-class prompt classification in `PromptKind::Investigation`, shared blocker choice tokens, and tests around prompt identity and answer routing. The engine still treats prompt answers as correlated commands, while front ends can recognize investigation prompts as different from plain text prompts.
This first sprint carried the engine-side distinction the interface work needed. The brief kept it small enough for a fresh agent by naming the contract boundary: prompt kinds, serialization, replay, mocks, headless handling, and the existing directive mapping. The gate and review stayed green, which matters here because later TUI work could depend on the marker without also reasoning about how recovery answers flow through the engine.
Passive Recovery Overlay
2 agents 17m 31s wall time
The current interface routes blocker prompts into the assistant transcript rather than the older stop-shaped modal language, but the passive contract still stands. Applying a blocker prompt opens an assistant entry, leaves the composer unfocused, keeps the original prompt pending, and exposes inline actions that can investigate, open a shell, proceed, or stop through the prompt answer path. Tests in the TUI state layer pin that routing, focus cursor, and prompt identity behavior.
This sprint turned the new prompt classification into the operator-facing recovery behavior. Its scope was intentionally a single interaction contract: show the recovery opportunity, leave normal shortcuts in control, provide an explicit path to recovery input, and preserve submit, blur, and quit behavior. The unit stayed green without a recorded repair, which left the chat work free to solve its own input-hijack surface instead of debugging recovery routing.
Chat Input Opt-In
2 agents 12m 8s wall time
The chat focus contract is still explicit in the live TUI. The initial chat-only app state restores the pane but leaves `chat_state.focused` false, expanding chat does not focus the composer, collapsing drops focus, and paste events only reach chat while the composer already owns focus. Tests cover expanded-but-unfocused startup, toggle behavior, submission, empty sends, and the composer retaining focus after an intentional submit.
This sprint handled the second keyboard ownership problem independently from recovery. The brief drew a clean boundary around chat visibility, composer focus, shortcut routing, mouse focus, draft preservation, menu copy, and snapshots. It passed its gate and review without a fix pass, which fits a state-model change whose risk was mostly whether visibility and focus had been separated everywhere the pane is opened or collapsed.
Compatibility Cleanup And Coverage
2 agents 8m 34s wall time
The surviving cleanup is visible more as consistency than as a separate subsystem. The legacy chat-focus plan is gone from the live plan queue, archived bare-chat documentation now describes expanded but unfocused startup, and README guidance tells users to focus the assistant pane explicitly. Some touched files have since been removed or rewritten, but the current tests and docs still teach that assistant surfaces do not automatically own the keyboard.
The closing sprint was a cleanup and verification pass after both opt-in surfaces existed. Its brief asked the agent to remove stale assumptions from comments, labels, snapshots, tests, and legacy planning material while preserving noninteractive recovery behavior and serialization compatibility. The run recorded a second gate at this boundary after review, so the stress landed where the integrated surface had to prove that old focus expectations were gone.