docs(unstable-v2): report follow-up work with the removal only when the Agent knows of it (#2745)

The Background Work rules asked the Agent to report `running` in the
snapshot that removes finished background work when that work starts new
foreground work, and not to send `idle` with an empty list followed by
`running`. An Agent often learns of the follow-up only after the work
ends: Claude Code decides to start a follow-up turn after a background
task's end, so claude-agent-acp cannot report it with the removal. The
RFD's FAQ already says adapters can't reliably know this ahead of time,
and Clients already wait a grace period before treating a session as
quiet.

Limit the SHOULD to an Agent that knows of the follow-up when it removes
the item, drop the SHOULD NOT, and point to the Client grace period, in
the stable and draft v2 prompt lifecycle pages and the RFD.

Author: benbrandt

docs/protocol/v2/draft/prompt-lifecycle.mdx

@@ -195,7 +195,7 @@ Background work is work the user can reason about: something the user or the mod
 - **Omitted or `null` means not reported**, not that nothing is running. An Agent that reports background work **MUST** include `background` on every `state_update` for the session. If a later snapshot omits it, or it is malformed, the Client treats background work as unknown until a list is reported again.
 - **The Agent re-sends the state when the list changes.** When background work starts or ends, the Agent **SHOULD** send a repeated `state_update` with the current state and the updated list. A repeated snapshot is not a [state transition](#state-transitions), and a repeated `idle` without a new stop reason is not a new completion.
 - **Items are announced before they are listed and finalized before they are removed.** The Agent **MUST** send a `terminal_update` for a terminal, a `tool_call_update` for a tool call, or a `subagent_update` for a child, before the first snapshot that lists it. It **MUST** send a terminal's `exitStatus` or a tool call's final status before the snapshot that removes it.
-- **Follow-up work is reported with the removal.** When finished background work starts new foreground work, the Agent **SHOULD** report `running` in the same snapshot that removes the item, or earlier. It **SHOULD NOT** send `idle` with an empty list followed immediately by `running`.
+- **Known follow-up work is reported with the removal.** When finished background work starts new foreground work and the Agent knows this when it removes the item, the Agent **SHOULD** report `running` in the same snapshot that removes the item, or earlier. An Agent that only learns of the follow-up later, for example because the underlying agent decides after the work ends, reports `running` when that work starts. Clients cover that gap with the grace period described below.
 - **Only background work is listed, and only once.** A terminal or tool call that foreground work is waiting on is foreground work and is not listed. Process-backed work is listed as its terminal, and the Agent **MUST NOT** also list a tool call whose only live work is a listed terminal.
 - **Unknown items still count.** An item with an unknown `type` does not invalidate the list. It still means background work is running.
 - **A background child is listed while it has anything running.** A detached child is listed while its state is not `idle`, or while its own `background` list is non-empty or not reported. An `idle` child with no background work of its own is not listed, even though it remains associated.

docs/protocol/v2/prompt-lifecycle.mdx

@@ -122,7 +122,7 @@ Background work is work the user can reason about: something the user or the mod
 - **Omitted or `null` means not reported**, not that nothing is running. An Agent that reports background work **MUST** include `background` on every `state_update` for the session. If a later snapshot omits it, or it is malformed, the Client treats background work as unknown until a list is reported again.
 - **The Agent re-sends the state when the list changes.** When background work starts or ends, the Agent **SHOULD** send a repeated `state_update` with the current state and the updated list. A repeated snapshot is not a [state transition](#state-transitions), and a repeated `idle` without a new stop reason is not a new completion.
 - **Items are announced before they are listed and finalized before they are removed.** The Agent **MUST** send a `terminal_update` for a terminal or a `tool_call_update` for a tool call before the first snapshot that lists it. It **MUST** send a terminal's `exitStatus` or a tool call's final status before the snapshot that removes it.
-- **Follow-up work is reported with the removal.** When finished background work starts new foreground work, the Agent **SHOULD** report `running` in the same snapshot that removes the item, or earlier. It **SHOULD NOT** send `idle` with an empty list followed immediately by `running`.
+- **Known follow-up work is reported with the removal.** When finished background work starts new foreground work and the Agent knows this when it removes the item, the Agent **SHOULD** report `running` in the same snapshot that removes the item, or earlier. An Agent that only learns of the follow-up later, for example because the underlying agent decides after the work ends, reports `running` when that work starts. Clients cover that gap with the grace period described below.
 - **Only background work is listed, and only once.** A terminal or tool call that foreground work is waiting on is foreground work and is not listed. Process-backed work is listed as its terminal, and the Agent **MUST NOT** also list a tool call whose only live work is a listed terminal.
 - **Unknown items still count.** An item with an unknown `type` does not invalidate the list. It still means background work is running.
 

docs/rfds/v2/background-work.mdx

@@ -192,7 +192,7 @@ Rules for the field:
 - **Omitted or `null` means the agent is not reporting background work.** It does not mean "nothing is running". An agent that reports background work **MUST** include `background` on every `state_update` for the session. If a later snapshot omits it anyway, or it is malformed, the Client treats background work as unknown until a list is reported again: it does not keep the previous list, consider the session quiet, or treat unfinished tool calls or running terminals as abandoned.
 - **The agent re-sends the state when the list changes.** When background work starts or ends, the Agent **SHOULD** send a repeated `state_update` with the current state and the updated list. A repeated snapshot is not a state transition ([State Transitions](/protocol/v2/prompt-lifecycle#state-transitions)), and a repeated `idle` without a new stop reason is not a new completion.
 - **Items are announced before they are listed and finalized before they are removed.** The Agent **MUST** send a `terminal_update` for a terminal, a `tool_call` or `tool_call_update` for a tool call, or a `subagent_update` for a child, before the first snapshot that lists it. When a terminal exits or a tool call ends, the Agent **MUST** send its `exitStatus` or final status before the snapshot that removes it from the list, so a Client never treats finished work as abandoned.
-- **Follow-up work is reported with the removal.** When the end of background work starts new foreground work, for example a follow-up response to a finished background task, the Agent **SHOULD** report `running` in the same snapshot that removes the item, or earlier. It **SHOULD NOT** send `idle` with an empty list followed immediately by `running`.
+- **Known follow-up work is reported with the removal.** When the end of background work starts new foreground work, for example a follow-up response to a finished background task, and the Agent knows this when it removes the item, the Agent **SHOULD** report `running` in the same snapshot that removes the item, or earlier. An Agent that only learns of the follow-up later, for example because the underlying agent decides after the work ends, reports `running` when that work starts. Clients cover that gap with the grace period below.
 - **Items reference existing entities.** `terminal` items reference a terminal by `terminalId` in this session. `tool_call` items reference a tool call by `toolCallId` in this session. `subagent` items reference a child session associated with this session through `subagent_update`. The list is extensible through the usual enum variant extension rules.
 - **Unknown items still count.** An item with an unknown `type` does not invalidate the list. It still means background work is running, even when the Client cannot show what it is, so a list of only unknown items is not empty.
 - **Paused and pending tool calls stay listed.** A `pending` or `paused` tool call is live background work: closing the session discards it, and the Client should not treat it as abandoned.
@@ -368,6 +368,7 @@ Not in this RFD. The `background` list belongs on the session-level `state_updat
 
 ## Revision history
 
+- 2026-11-02: The rule that reports follow-up work with the removal applies only when the Agent knows of the follow-up at that point. An Agent that learns of it later, as `claude-agent-acp` does when Claude Code starts a follow-up turn after a background task ends, may send `idle` with the updated list and then `running`, and Clients rely on the grace period.
 - 2026-11-02: On `session/cancel`, the Agent cancels the permission requests of the cancelled foreground work with `$/cancel_request` instead of the Client choosing them by `subject`. `session/close` cancels every pending permission request the same way.
 
 - 2026-10-30: Phase 1 landed: the schema changes are in the v2 schema, with the item types named `BackgroundTerminal`, `BackgroundToolCall`, `BackgroundSubagent`, and `OtherBackgroundWork` and the cancel capability types pluralized to `ToolCallCancelCapabilities` and `TerminalCancelCapabilities` to match the other capability types, and the protocol docs describe the `background` list, `paused`, and both cancel methods.