Specs: block navigation (CMD-UP / arrow keys) in agent mode (GH-9959)#9962
Specs: block navigation (CMD-UP / arrow keys) in agent mode (GH-9959)#9962BravesDevs wants to merge 1 commit intowarpdotdev:masterfrom
Conversation
…vGH-9959) Adds specs/GH9959/{product.md,tech.md} per CONTRIBUTING.md's spec-first flow for ready-to-spec feature requests. What ---- Extend terminal-mode block navigation (CMD-UP/DOWN, arrow keys, SHIFT-CMD-UP/DOWN) into agent mode so users can navigate agent responses, agent-executed commands, and user prompts as blocks. Which item kinds count as navigable is a multi-toggle under Settings -> AI; the SHIFT-CMD-UP/DOWN scroll-to-edge semantic matches terminal mode. Selection mirrors terminal-mode behavior (visual border, copy on CMD-C) and adds agent-specific affordances: attach as context (CMD-SHIFT-K), plus per-block actions wired by item kind (rerun command, retry response, fork conversation from prompt). Why --- In long agent conversations the only way to revisit an earlier exchange today is manual scrolling, breaking the keyboard model that makes terminal mode pleasant. The underlying BlockList is already shared between terminal and agent modes (app/src/terminal/view.rs:2736), so the cost is mostly modeling rather than a parallel navigation system: introduce a NavigableItemId enum and a SelectedNavigableItems mirror of SelectedBlocks, broaden the existing keybinding context predicate to include agent mode, and reuse SelectPriorBlock/SelectNextBlock handlers against the new selection source. See specs/GH9959/tech.md for the full implementation plan, risks, and per-invariant test mapping. Implementation will continue on this branch once the specs are approved. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @BravesDevs on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment |
github-actions
Bot
added
the
external-contributor
|
I'm starting a first review of this spec-only pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
|
@cla-bot check |
|
The cla-bot has been summoned, and re-checked this pull request! |
![oz-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
There was a problem hiding this comment.
Overview
Reviewed the spec-only PR for bringing terminal-style block navigation to agent mode. The product and tech specs cover the main behavior surface, implementation entry points, settings, and validation strategy, but several requirements are contradictory or leave important implementation and security decisions unresolved.
Concerns
- SHIFT-CMD-UP has conflicting no-selection semantics between range selection and scroll-to-edge behavior.
- Zero-output / not-yet-rendered tool blocks are declared selectable without defining their selectable bounds, focus target, copy text, or action affordance.
- The tech plan does not specify how CMD-C and mixed terminal+agent selections read from the new selection model.
- The agent-mode keybinding predicate conflicts with the all-agent-types-disabled setting in inline mode.
Security
- Rerunning an agent command must explicitly go through the same approval, safety, and execution-context checks as the original command so the new shortcut cannot bypass command-execution policy.
Verdict
Found: 0 critical, 5 important, 0 suggestions
Request changes
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
| 18. Pressing UP at the top-most navigable block leaves selection on that block (no wrap-around). | ||
| 19. Pressing DOWN at the bottom-most navigable block clears selection and returns focus to the agent input field, mirroring the equivalent terminal-mode behavior. | ||
| 20. **CMD-UP / CMD-DOWN** with a block already selected jumps to the top-most / bottom-most navigable block in the conversation (jump to extremes), not just one step. | ||
| 21. **SHIFT-UP / SHIFT-DOWN** extends the selection by one navigable block in that direction, producing a multi-block selection. **SHIFT-CMD-UP** with no selection selects from the bottom of the conversation up to the top-most navigable block. |
There was a problem hiding this comment.
| 2. When agent mode is rendered inline inside a terminal block list (agent view is embedded rather than full-screen), all blocks in that block list — both terminal blocks and agent blocks — participate in the same navigation order. The user perceives one continuous block list, not two. | ||
| 3. When agent mode is rendered full-screen, only agent blocks are present and only they participate in navigation. | ||
| 4. A block that is still streaming (response being generated, or command still producing output) IS navigable and selectable. Its visible bounds may grow while selected; the selection remains attached to the same logical block as it grows. | ||
| 5. A tool-call block that has not yet produced any visible content (zero-output command, in-flight tool call with nothing rendered yet) IS still navigable — empty does not mean absent. |
There was a problem hiding this comment.
|
|
||
| `SelectedNavigableItems` mirrors `SelectedBlocks`'s API surface (`range_select`, `reset`, `reset_to_single`, `is_selected`, `is_empty`, `is_singleton`, `tail`, `cardinality`, `sorted`) but is keyed by `NavigableItemId`. Internally it stores a `Vec<NavigableItemRange>`; ranges are computed against the iterator from §2 so "extend selection by one" means "advance one position in `iter_navigable_items`". | ||
|
|
||
| When the selection contains only `NavigableItemId::Terminal(_)` entries, mirror them into `selected_blocks` so existing terminal-block consumers (copy, context attach, block actions) keep working unchanged. This avoids a sweeping refactor of every call site that reads `selected_blocks` today. |
There was a problem hiding this comment.
selected_navigable_items and materialize every selected item in display order.
| | id!("TerminalView_AgentMode_Navigable") | ||
| ``` | ||
|
|
||
| …where `TerminalView_AgentMode_Navigable` is a new context id raised by `TerminalView` whenever `agent_view_controller.is_active()` and `iter_navigable_items` yields at least one item. The disjunction guarantees agent-mode navigation works regardless of `AltScreen` (§42). |
There was a problem hiding this comment.
iter_navigable_items includes terminal blocks in inline mode, this predicate can remain true when all agent types are disabled but terminal blocks exist, contradicting product §10; base the agent clause on navigable agent items or clarify that terminal-only navigation remains active.
|
|
||
| The existing terminal-block action affordance lives alongside `block_list_element.rs`. Mirror it for agent items by: | ||
|
|
||
| - For `NavigableItemId::AgentCommand` — wire **Rerun command** to dispatch the same command through the agent's command-execution path. |
There was a problem hiding this comment.
1 participant
Description
Adds
specs/GH9959/{product.md,tech.md}for issue #9959 — extending Warp's terminal-mode block navigation (CMD-UP/DOWN, arrow keys, SHIFT-CMD-UP/DOWN) into agent mode so users can navigate agent responses, agent-executed commands, and user prompts as blocks.What ships in this PR (spec only):
product.md— 45 numbered behavior invariants covering the block model, configurable per-type filter (Settings → AI), single + multi-block selection mirroring terminal-mode, SHIFT-CMD scroll-to-edge semantics, copy / attach-as-context (CMD-SHIFT-K) / per-block actions (rerun command, retry response, fork conversation), focus interactions, edge cases (streaming, deletion mid-selection), accessibility, and cross-mode consistency.tech.md— implementation plan grounded in current code: introduces aNavigableItemIdenum and aSelectedNavigableItemsmirror ofSelectedBlocks, broadens the existing keybinding context predicate to include agent mode, reusesSelectPriorBlock/SelectNextBlockhandlers against the new selection source, adds three bool toggles toAISettings, and a newAttachSelectedBlocksAsContextcustom action.Why: in long agent conversations the only way to revisit an earlier exchange today is manual scrolling, breaking the keyboard model that makes terminal mode pleasant. The underlying
BlockListis already shared between terminal and agent modes (seeapp/src/terminal/view.rs:2736), so the cost is mostly modeling rather than a parallel navigation system.Implementation will continue on this same branch once the specs are approved (per
CONTRIBUTING.md§"Opening a Spec PR").Linked Issue
Closes #9959.
ready-to-specorready-to-implement.Note
Issue #9959 is currently labeled
enhancement/triagedbut does not yet haveready-to-spec. I've left a comment on the issue tagging@oss-maintainersto request label review. Happy to wait for the label before this PR moves forward — opening early to share the spec for async review.Screenshots / Videos
N/A — spec-only PR. The
## Figmasection inproduct.mdis an explicit placeholder; mocks will be linked before the spec is approved.Testing
N/A — no code changes in this PR. The per-invariant test mapping (unit + integration in
crates/integration+ manual accessibility pass) is enumerated inspecs/GH9959/tech.mdunder "Testing and validation" and will be implemented alongside the code on this same branch.Agent Mode