fix(core): reset steps for promoted prompts (#33452)

specs/v2/schema-changelog.md

@@ -138,7 +138,7 @@ Change:
 Reason:
 
 - Prompt admission and model-visible promotion must be separate durable operations.
-- Steering must promote at safe provider-turn boundaries while queued prompts remain separate FIFO activities.
+- Steering must promote at safe provider-turn boundaries while queued prompts remain pending in FIFO order until continuation would otherwise end.
 
 Compatibility:
 

specs/v2/session.md

@@ -42,7 +42,7 @@ SessionExecution.resume(sessionID)
 
 `SessionExecution` and the read-side `SessionStore` are process-global. `SessionRunner`, catalog, model resolver, tool registry, permission state, and filesystem are cached per Location. No layer takes a Session ID. An omitted `Location.workspaceID` means implicit-local placement; explicit workspace identity remains reserved for future placement semantics.
 
-The local runner issues one explicit `llm.stream(request)` per provider turn, projects each complete local tool call durably before eagerly starting its structured child execution, awaits every started tool fiber after provider-stream closure, reloads projected history once before continuation, and fails after 25 provider turns within one local drain activity only when work remains. Tool settlement events carry the owning assistant message ID because provider-local call IDs may repeat across turns. Before assembling a provider request, the runner durably fails any local tool still projected as `running` from a previous process with `Tool execution interrupted`; abandoned side effects are never silently replayed.
+The local runner issues one explicit `llm.stream(request)` per provider turn, projects each complete local tool call durably before eagerly starting its structured child execution, awaits every started tool fiber after provider-stream closure, and reloads projected history once before continuation. Promoting any new user input resets the selected agent's configured provider-turn allowance; multiple steers promoted at one boundary reset it once. Tool settlement events carry the owning assistant message ID because provider-local call IDs may repeat across turns. Before assembling a provider request, the runner durably fails any local tool still projected as `running` from a previous process with `Tool execution interrupted`; abandoned side effects are never silently replayed.
 
 Projected hosted tools preserve call-side and settlement-side provider metadata separately so settlement and interruption recovery cannot erase continuation identifiers. Provider-native reasoning and provider metadata replay only while the historical assistant model matches the selected continuation model; after a model switch, visible reasoning text remains ordinary assistant text and provider-native metadata is omitted.
 
@@ -96,7 +96,7 @@ Ambient project discovery canonicalizes and contains traversal within the projec
 Current Context Epoch follow-ups:
 
 - Add configured, remote, and nested instruction sources with explicit precedence and removal semantics.
-- Add durable post-crash activity recovery for promoted or provider-dispatched work.
+- Add durable post-crash continuation recovery for promoted or provider-dispatched work.
 - Add explicit manual compaction on top of automatic request-budget compaction.
 - Add operational metrics for observation latency, unavailable sources, contention, baseline size, and chronological-update growth.
 - Consider watcher-backed per-file caching only if measurements show direct safe-boundary observation is too expensive.
@@ -113,7 +113,7 @@ Compaction keeps the full transcript durable while replacing its active model re
 
 Repeated compactions update the previous structured summary with newly compacted messages. The runner then reloads projected history and executes the original pending turn.
 
-When a provider rejects a request as context overflow before durable assistant output or tool activity, the runner attempts one overflow-triggered compaction even when the local estimate did not predict pressure. A completed checkpoint rebuilds the same logical provider turn with one remaining physical attempt. A second overflow, unavailable compaction, or overflow after durable output becomes the ordinary terminal failure; recovery never loops or replays partial side effects. Deterministic old tool-result pruning remains a separate follow-up.
+When a provider rejects a request as context overflow before durable assistant output or tool execution, the runner attempts one overflow-triggered compaction even when the local estimate did not predict pressure. A completed checkpoint rebuilds the same logical provider turn with one remaining physical attempt. A second overflow, unavailable compaction, or overflow after durable output becomes the ordinary terminal failure; recovery never loops or replays partial side effects. Deterministic old tool-result pruning remains a separate follow-up.
 
 ## V1 Runtime Context Parity
 
@@ -150,18 +150,18 @@ Provider timeout, retry, and watchdog policy is intentionally deferred. The runn
 Inbox delivery is explicit:
 
 - `steer` inputs promote at the next safe provider-turn boundary, including continuation inside the current drain.
-- `queue` inputs form a FIFO of future activities. When the current activity settles, the runner promotes exactly one queued input to open the next activity. Multiple queued inputs remain separate activities.
+- `queue` inputs remain in a FIFO while the current drain requires continuation. When the Session would otherwise become idle, the runner promotes exactly one queued input, then reevaluates continuation before promoting another.
 
 Execution has two entry points:
 
 - `run` is an explicit resume. It joins any active execution or starts a forced drain while idle. A forced drain bypasses the no-eligible-input guard, but preparation may still fail before a provider attempt.
 - `wake` reports newly recorded durable inbox work. Repeated wakes coalesce. A wake calls the provider only when it can promote eligible input.
 
-Post-crash activity recovery is intentionally deferred. A wake does not infer that ambiguous provider work is safe to retry after an input has already been promoted. Explicit `run` may deliberately continue from durable projected history. A future recovery slice should model durable activity identity, provider-dispatch ambiguity, required continuation, queue-opener reservation, retry policy, and visible recovery status together.
+Post-crash continuation recovery is intentionally deferred. A wake does not infer that ambiguous provider work is safe to retry after an input has already been promoted. Explicit `run` may deliberately continue from durable projected history. A future recovery slice should model provider-dispatch ambiguity, required continuation, queued-input promotion, retry policy, and visible recovery status together. It must not assume an enclosing durable execution identity that the Session model does not otherwise need.
 
 A process-global `SessionRunCoordinator` serializes execution for each local Session while allowing different Sessions to run concurrently. Resumes join active execution, overlapping wakes coalesce into one follow-up, and interruption stops current process-local execution without deleting durable inbox work. The runner enters the Session's current Location when execution starts and fences each new provider turn against that Location.
 
-Inbox promotion coalesces pending steers in durable admission order and opens one queued activity at a time in FIFO order. Add explicit inbox backlog and steering-batch limits before exposing broad multi-caller admission or untrusted queue growth.
+Inbox promotion coalesces pending steers in durable admission order. Once continuation would otherwise end, it promotes one queued input at a time in FIFO order. Add explicit inbox backlog and steering-batch limits before exposing broad multi-caller admission or untrusted queue growth.
 
 Eager local-tool execution is intentionally unbounded in the current local slice. This minimizes tool latency but does not increase SQLite settlement throughput: Session-event publication remains serialized per provider turn. Before broadening exposure, revisit per-turn call limits, output truncation, and operational backpressure using observed workloads. The `session.next.*` event schemas remain experimental and unshipped; databases created by earlier experimental builds are disposable rather than compatibility targets.
 

specs/v2/todo.md

@@ -26,14 +26,14 @@ through legacy `SessionPrompt.loop(...)`:
   tool results, and assistant output
 - a scoped `ToolRegistry` advertises definitions and the first permission-checked
   `read` built-in
-- local continuation reloads projected history and stops after 25 provider turns within one local drain activity
+- local continuation reloads projected history, and promoting new user input resets the selected agent's configured provider-turn allowance
 - concurrent resumes for one Session join one process-local run while different
   Sessions remain concurrent
 
 Prompt admission now uses a durable `session_input` inbox rather than immediate
-transcript projection. `steer` inputs coalesce into the active activity at the
-next safe provider-turn boundary. `queue` inputs form a FIFO of future activities
-that open one at a time.
+transcript projection. `steer` inputs promote at the next safe provider-turn
+boundary while the current drain requires continuation. `queue` inputs remain in
+a FIFO until the Session would otherwise become idle and then promote one at a time.
 
 Next reviewed slices:
 
@@ -53,16 +53,16 @@ Next reviewed slices:
 - add durable/clustered interruption, retries, and stale-owner fencing only as
   their slices become concrete
 
-### Deferred durable activity recovery
+### Deferred durable continuation recovery
 
 Do not infer that ambiguous provider work is safe to retry from an advisory wake.
 The first inbox-driven runner intentionally omits outer provider-attempt markers
 until they have a concrete consumer and a complete recovery policy.
 
-Design post-crash activity recovery as one explicit slice. It should model:
+Design post-crash continuation recovery as one explicit slice. It should model:
 
-- durable activity identity and settlement
-- queue-opener reservation and steer assignment
+- promoted input and projected-history state
+- queued-input promotion and steering assignment
 - provider-attempt preparation versus provider-dispatch ambiguity
 - required post-tool continuation across process loss
 - explicit `retry` and `abandon` decisions for unknown outcomes
@@ -70,6 +70,9 @@ Design post-crash activity recovery as one explicit slice. It should model:
 - retry budget, backoff, visible recovery status, startup discovery, and future
   clustered ownership fencing
 
+Do not introduce an enclosing durable execution identity solely to group these
+facts; a process-local Session drain has no durable transcript boundary.
+
 ## Plugin API design - James?
 
 We need to figure out how we want server plugins to work and what hooks are useful.