# v0.13.0 P1 — rc client-side paste (ctrl+V + right-click; doyle 2026-06-19)

**Operator HITL:** in an `spt rc` session neither ctrl+V nor right-click paste works (CC explicitly supports ctrl+V). Builder: todlando (folds into the bug-2 rc Windows event path). Gate: doyle. **Depends on P0** (a paste chunk must not wedge the broker).

## Root (doyle, code-grounded)
- `RawGuard::enable()` (rc.rs:248) does ONLY `enable_raw_mode()` — no bracketed paste, no mouse capture, no clipboard interception.
- On the Windows console a paste arrives as a stream of synthetic per-char KEY EVENTs (crossterm surfaces no `Event::Paste` on the Windows console). ctrl+V → translates to bare `^V` (0x16) forwarded to CC.
- **CC runs daemon-side and has NO access to the operator's LOCAL clipboard** — remote paste is fundamentally **client-originated**. So forwarding `^V` can never paste; rc must read the local clipboard itself and inject the content.
- A multi-line paste arriving as char events also becomes a `\r` **submit-storm** (each newline = Enter).

## Decision: rc reads the LOCAL clipboard on a paste gesture → emits a BRACKETED PASTE
On a paste gesture (ctrl+V or right-click), rc reads the local clipboard and forwards `ESC[200~` + content + `ESC[201~`. CC has bracketed-paste mode enabled on its broker PTY (its TUI sets `ESC[?2004h`), so it recognizes the synthesized markers as a PASTE — content lands intact, **no submit-storm**, and it is harness-AGNOSTIC (bracketed paste is the standard xterm contract, not a CC-specific assumption). cfg(windows) only (the event path); **Unix is unchanged** — a Unix terminal's own paste already injects bytes (incl. its native bracketed markers) straight through the byte pump.

## Architecture (cfg(windows), in the bug-2 event path)
- **ctrl+V:** in `key_event_step` / the event loop, intercept `Char('v') + CONTROL` BEFORE translation → `read_clipboard()` → `StdinMsg::Bytes(ESC[200~ + content + ESC[201~)`. (Detach arming takes precedence — ctrl+V is not the detach prefix, so no interaction.)
- **right-click:** `RawGuard` additionally does `execute!(stdout, EnableMouseCapture)` — on Windows this disables console QuickEdit + enables `ENABLE_MOUSE_INPUT`, so a right-click surfaces as `Event::Mouse` on legacy `cmd`/`powershell` consoles (today QuickEdit consumes it before the app sees it). In the event loop: `Event::Mouse` with the RIGHT button (Down) → `read_clipboard()` → same bracketed paste. **Drop ALL other mouse events** — CC has no mouse features (operator-confirmed), so nothing is lost; capturing mouse deprives CC of nothing.
- `RawGuard::drop` also `DisableMouseCapture` (restore the console) alongside `disable_raw_mode`.
- `read_clipboard()`: the **`clipboard-win`** crate (Windows-only, minimal, no X11 baggage), cfg(windows). Empty/failed read → no-op (never panic, never inject garbage).
- Bracketed-paste wrap is a tiny helper: `[ESC,[,2,0,0,~] ++ content ++ [ESC,[,2,0,1,~]`. Content forwarded VERBATIM (no per-char translation — it is literal pasted text, not keystrokes).

## Notes / caveats
- Disabling QuickEdit removes the console's native right-click paste + native mouse text-selection. We REPLACE right-click with our own clipboard paste; native selection on WT stays available via Shift-drag. Acceptable per operator (right-click paste is the goal).
- A paste chunk is one large `StdinMsg::Bytes` → one `send_attach_input` → P0's single-writer thread carries it without wedging. **Hard dependency on P0.**
- Unix ctrl+V is NOT intercepted (byte path) — a Unix terminal pastes natively through the byte stream; if a future Unix remote-clipboard need arises, mint a follow-up. In scope here = Windows (the reported platform).

## REQ + gates
- **Mint `REQ-RC-WIN-PASTE`** (registry-first), stages **impl, unit** (NO int — live clipboard + console mouse = HITL, REQ-RUN-PICKER/RC-1 precedent; the pure pieces are unit-tested).
- unit: the bracketed-paste wrap (exact `ESC[200~`/`ESC[201~` framing around content) + the gesture→paste decision (ctrl+V event ⇒ clipboard-wrap; right-mouse ⇒ clipboard-wrap; other mouse ⇒ drop; injected clipboard reader, no real clipboard) + content forwarded verbatim (no translation).
- doc: KNOWN-HAZARDS entry + CONTEXT note (rc Windows paste is client-originated: ctrl+V/right-click read the local clipboard and inject a bracketed paste; Unix rides the terminal-native byte stream).
- clippy --workspace -D warnings = 0 (new `clipboard-win` dep clean); traceable EXIT=0; docs-drift xtask check; Cargo.lock updated.
- HITL acceptance (operator): ctrl+V AND right-click both paste clipboard content (incl. multi-line, no submit-storm) into a real CC rc session; no wedge (P0).

## doyle gate criteria
Bracketed-paste framing exact (unit) · ctrl+V + right-mouse both route to clipboard-paste, other mouse dropped · content verbatim (no translation) · RawGuard enables+restores mouse capture · clipboard-read failure is a clean no-op · Unix untouched (cfg(windows)) · P0 landed first (no wedge on a paste chunk) · clippy/traceable/docs-drift + Cargo.lock. Then operator HITL.
