---
id: NVIM-ISSUE-8I3OSH4M
type: issue
title: Prompt accept auto-steers, diverging from explicit queued delivery
specs:
  - NVIM-SPEC-GMWDCMJZ
---

# Prompt accept auto-steers, diverging from explicit queued delivery

## Symptom

Accepting the prompt while the agent is working now delivers the text as a steer, chosen implicitly by the accept key rather than by an explicit delivery decision. A follow-up has its own keys, but a steer is injected into the live run immediately; it is not queued, listed, or clearable.

## Impact

Diverges from [NVIM-SPEC-GMWDCMJZ](../../specs/NVIM-SPEC-GMWDCMJZ-pivi-native-neovim-integration/index.md), which states:

- "While a session run is active, a new submission is queued with an explicit delivery choice and is never silently dropped."
- "Queued submissions remain listable and clearable before delivery."
- Acceptance: "A submission made during an active run is queued with explicit delivery and can be listed and cleared before delivery."

Two gaps against that contract:

- Delivery is now implicit for the accept key: pressing accept while working picks steer with no separate choice.
- A steer is injected into the active run, so it is neither queued nor listable nor clearable, unlike a follow-up.

Nothing is silently dropped, so that half of the contract still holds. The desired behavior (accept steers while working, as in pi) is intentional; the spec is what no longer matches.

## Evidence

`lua/bugabinga/pivi/command.lua`, the prompt `send`:

- When no delivery is passed and the session is busy, it sets delivery to `steer`.
- `<Plug>(pivi-submit)` and `<Plug>(pivi-accept)` call `send()` with no delivery, so the accept key auto-steers during a run.
- `<Plug>(pivi-follow-up)` calls `send('follow_up')`, which queues.

`lua/bugabinga/pivi/session.lua` maps `steer` to a `steer` command (immediate) and `follow_up` to a `follow_up` command (queued); only the latter appears in the status queue that `:Pi queue` lists and `:Pi clear` clears.

## Expected

Resolve the divergence one way:

- Amend the spec so an accept while working is a defined, visible steer (winbar hint states it), treating a bound, announced key as an explicit choice, and scope "queued, listable, clearable" to follow-ups; or
- Change the behavior so an accept during a run requires an explicit delivery choice and queues rather than injecting.

The spec's intent for steering versus follow-up delivery decides which; this issue records the mismatch, not the resolution.