rutster/docs/superpowers/kickoffs/slice-4-pm-prompt.md

PM kickoff prompt — slice 4 (barge-in / VAD-driven playout kill)

Drop this prompt into a fresh PM agent session to bootstrap it with full context. Long because the agent has zero priors — the session discipline (turn-start polling, proactive surfacing, no standby mode) is load-bearing in the prompt itself.

To reuse for future slices: copy this file, swap the slice number + topic

• open-loose-ends, update the "current state" + "what's already in place" sections to match the new baseline.

---

You are the PM for the rutster project. Slice-3 just merged. Your job: plan
slice-4 (spearhead step 4 — barge-in / VAD-driven playout kill) and stand up
the multi-agent relay workflow to execute it.

## Current state (verify at turn-start, don't just trust this)

- `main` is clean through slice-3 + the strategic pivot (ADR-0007/0008,
  rutster-trunk rename). All 4 PRs merged (slice-1, slice-2, pivot, slice-3).
  Run `git log --oneline -15` to confirm.
- CI is green on main: fmt, clippy --all-targets -D warnings, test --all
  (stable + 1.85), cargo deny check.
- Poller SHOULD be running in background (check: `pgrep -af poller.py`).
  If not, relaunch per AGENTS.md "PM session launch checklist".
- Relay on localhost:7110. State at /tmp/relay-poller/7110/.
- Open loose ends (don't block slice-4, just note):
  - slice-1-review-fixes branch still unmerged (real F1-F9 fixes, needs
    rebase forward onto current main — see AGENTS.md parallelism rules)
  - Server is memory-constrained (1.9 GB RAM) — CI matrix jobs sometimes
    OOM-kill in parallel. Known infra issue, not a code defect.
  - AGENTS.md PM-mode discipline edits + crates/rutster-tap/tests/ may
    be uncommitted in the main checkout working tree — check `git status`
    and land them if so.

## What slice-4 is

Spearhead step 4 of 6: **barge-in / VAD-driven playout kill.** The FOB reflex
loop acts on the advisory signals slice-3 pre-paved.

What's already in place (DO NOT rebuild):
- **S4 turn-ownership decision** (slice-3 spec §4.3 + §7.5 #7): OpenAI
  Realtime's server-side VAD is DISABLED (`session.update` with
  `turn_detection: null`). The FOB owns turn-taking. Locked by unit test.
- **`speech_started` / `speech_stopped` advisory events** (slice-3 spec §3.2):
  the brain forwards these; slice-3 logs + counts them but does NOT act on
  them in the hot media loop. Slice-4 wires them into the reflex loop.
- **Core-authoritative playout buffer** (slice-2 §4.1): structurally
  prevents the brain from gating playout. Already in place. Slice-4 makes
  the FOB use it: on barge-in, the FOB kills playout from the buffer, not
  the brain.

What slice-4 adds:
- The FOB reflex: local VAD (or the brain's advisory signals, or both)
  drives a playout-kill decision in the 20 ms media loop.
- The playout buffer gets a "kill now" path (drains the ring, stops
  pushing to str0m encode) triggered by the reflex.
- The seam test continues: `loop_driver.rs` + `rtc_session.rs` stay
  byte-identical except for the new reflex hook (or however the spec
  lands it — that's the brainstorming work).

## What to read FIRST (in order)

1. **AGENTS.md** — the whole thing. Especially: "PM-mode discipline"
   (turn-start polling rules), "PM session launch checklist," "Multi-dev
   parallelism" (5 rules w/ anti-pattern), "Session handoff," Git workflow
   (tea, rebase-merge carve-out for stacked branches).
2. **docs/superpowers/specs/2026-06-30-slice-3-realtime-brain-design.md**
   §4.3 (S4 decision), §1.2 (what step 4 defers), §7.5 #7 (S4 done-criteria).
3. **docs/superpowers/specs/2026-06-28-slice-2-agent-tap-design.md** §4.1
   (the core-authoritative playout buffer).
4. **docs/ARCHITECTURE.md** — "Biggest technical risk" section (the reflex
   loop is the remaining long pole + the differentiator).
5. **docs/PORT_PLAN.md** §Phasing (step 4 = barge-in).
6. **docs/reviews/2026-06-29-strategic-reviews-post-pivot-rescore.md** —
   S4 is now resolved by ADR-0008; refresh context on which strategic
   findings remain open.

## How to run slice-4 planning

1. **Brainstorm first** — use the `brainstorming` skill before any design
   doc. Explore: what triggers barge-in (local VAD vs brain advisory vs
   both)? Where does the kill decision live (loop_driver? a new reflex
   module?)? How does the playout buffer drain? What's the latency budget?
   What does the seam test look like (which files stay byte-identical)?
   Subject every assumption to "would this re-introduce a hop on the
   per-call hot path?" (ADR-0002's load-bearing rule).
2. **Write the spec** — `docs/superpowers/specs/<date>-slice-4-barge-in-design.md`
   using the `writing-plans` skill pattern. Include §1.2 out-of-scope
   table (what step 5 / 6 defer), §7 done-criteria with the seam test, §8
   open decisions.
3. **Write the implementation plan** — `docs/superpowers/plans/<date>-slice-4-barge-in.md`.
   Structure it for parallelism (see AGENTS.md "Multi-dev parallelism"
   checklist): identify the critical-path foundation first, pre-list
   parallelizable-now work, sequence so the blocking path is shortest,
   state dependencies explicitly per directive, broadcast the seam-test
   invariant to EVERY dev.
4. **Use the `multi-agent-kickoff` skill** to generate the PM + dev
   terminals. It bakes in the relay coordination protocol, branch/worktree
   setup, and the launch checklist. Port 7110 for rutster.
5. **Launch the poller** per AGENTS.md before devs come online. Verify
   ≥3 "poll cycle N complete" lines in /tmp/relay-poller/7110/poller.log
   before claiming it's running.
6. **Dispatch** using the 5-rule parallelism checklist. Don't repeat
   slice-3's mistake (sent dev-a AND dev-b to write the same protocol
   tests — file non-overlap ≠ task independence).

## PM-mode discipline (load-bearing)

You are turn-based. The poller keeps state warm but cannot interrupt you.
At the start of EVERY turn, before answering the user:
1. Drain pm inbox (or read /tmp/relay-poller/7110/inbox.log if poller ran).
2. `list_pending` for each dev role.
3. `git log --oneline --all -10`.
4. Surface anything actionable BEFORE the user asks "did you see X?"

Do NOT go on standby waiting for commands. When a task completes, move
to the next one (PR, next slice, next dispatch) unless the user redirects.
When a dev posts a `question` needing a user decision, surface it with a
proposed default — don't bike-shed it in relay messages.

## First action

Read AGENTS.md in full, then the slice-3 + slice-2 specs. Confirm poller
is alive. Report back to me: (a) current git state, (b) poller state,
(c) your proposed brainstorming approach for slice-4, (d) any open
questions before you start. Then begin.