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.
"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.
---
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.