add tech spec#12794
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
5b1e645 to
cf427d4
Compare
| A **headless, view-tree-free** test drives the TUI agent core. It: | ||
| - Initializes the TUI singleton graph in a test app context. | ||
| - Constructs a synthetic `AgentSessionOwnerId` from a fresh `EntityId` — no `TerminalView`, no `RootTuiView`, no runtime/driver. This proves conversation ownership is fully decoupled from views. | ||
| - Submits prompt `"first"` and feeds a fake streamed response. |
There was a problem hiding this comment.
Why are we feeding a fake streamed response? This should be wired to the server
(we might need to reuse the warp-dev auth credential since we are not building the auth flow in the prototype)
| GUI terminal call sites keep working by passing an `AgentSessionOwnerId::new(terminal_view_id)`. This is a sizable but mechanical change; it should land as its own PR ahead of the TUI model. | ||
|
|
||
| ### 3. Split app initialization into phases | ||
| Today `initialize_app` (`app/src/lib.rs:1142-2175`) is a ~1000-line monolith run for every non-TUI mode; afterwards `launch` (`app/src/lib.rs:2627`) builds the GUI workspace. `LaunchMode::Tui` bypasses **both** via an early short-circuit (`app/src/lib.rs:1079-1084`) that just calls `tui::init`. To give the TUI a real singleton graph, we decompose `initialize_app` into ordered phases, share the backend-neutral + agent phases, and give GUI and TUI their own final phase. |
There was a problem hiding this comment.
For this prototype, I think it's fine for us to initialize all these singleton models that the main app uses (these should be cheap)
We just need to skip the heavy weight ones like terminal_server process
| /// concurrent sessions work out of the box even though the root view is the | ||
| /// only owner today. | ||
| pub struct CoreTuiModel { | ||
| sessions: HashMap<AgentSessionOwnerId, TuiAgentSession>, |
There was a problem hiding this comment.
For the prototype -- we can assume there is only one session (we're not gonna prototype orchestration today)
| /// only owner today. | ||
| pub struct CoreTuiModel { | ||
| sessions: HashMap<AgentSessionOwnerId, TuiAgentSession>, | ||
| } |
There was a problem hiding this comment.
Shouldn't we hold the agent controller and action model here? We shouldn't hand roll our own logic around action dispatching / streaming etc
db79a25 to
9ab0f32
Compare
9ab0f32 to
9b40b7c
Compare
Co-Authored-By: Oz <oz-agent@warp.dev>
Co-Authored-By: Oz <oz-agent@warp.dev>
Co-Authored-By: Oz <oz-agent@warp.dev>
Co-Authored-By: Oz <oz-agent@warp.dev>
ab44945 to
93ca9b5
Compare

Description
Linked Issue
ready-to-specorready-to-implement.Testing
./script/runScreenshots / Videos
Agent Mode