rutster/docs/superpowers/kickoffs/2026-07-01-slice-4-dev-b-prompt.md

# Dev B Kickoff Prompt — slice-4 Plan B (TapAudioPipe + advisory + MockRealtimeBrain)

Paste everything below the `---` line into a fresh Claude Code terminal as the first user message.

---

You are a **senior developer** owning the tap + advisory chain for the slice-4 "barge-in / VAD-driven playout kill" release. A PM in another terminal coordinates you with dev-a. With the relay server running, you communicate via `post_message` / `read_messages` directly — no user copy-paste needed.

## Your scope (the tap + advisory chain)

You own the **brain↔FOB advisory plumbing + the mock brain's VAD schedule** — the pieces that wire brain-side advisories into dev-a's Reflex. Tasks:
- **Task 3** (`TapAudioPipe::barge_in_flush` override + `TapMetrics.barge_drained_inflight`)
- **Task 4** (`advisory_tx` through `run_tap_client` + `handle_brain_frame`)
- **Task 5** (`spawn_tap_engine` signature change — takes `advisory_tx` as a parameter)
- **Task 8** (`MockRealtimeBrain` advisory schedule)
- Possibly **Task 9** + **Task 10** (shared — PM assigns; likely dev-a since their chain finishes Task 7 first, but you might pick these up if your Task 8 lands before dev-a's Task 6 coordination point)

**You HOLD until dev-a's Task 1 merges** (the critical-path foundation — `AdvisoryEvent` enum + `ReflexMetrics` + `barge_in_flush` trait). Your Task 3 depends on Task 1's `barge_in_flush` trait method. While you wait, read the plan + the slice-2/3 code for context.

Your work wires the SECONDARY/confirmation trigger path (the brain's ASR-quality VAD). The PRIMARY trigger is dev-a's `LocalVadReflex` — but your advisory plumbing IS the path the wedge-#1 e2e test's secondary case exercises.

## Setup (do this first)

```bash
cd /home/alee/Sources/rutster
git fetch
git checkout main
git pull
git worktree add /home/alee/Sources/rutster.slice-4-dev-b -b slice-4-dev-b-tap
cd /home/alee/Sources/rutster.slice-4-dev-b
pwd  # should print /home/alee/Sources/rutster.slice-4-dev-b
```

**ALL subsequent work happens in `/home/alee/Sources/rutster.slice-4-dev-b`**. Force-cd subagents into this directory.

Today: 2026-07-01. Project rules in `AGENTS.md` apply — READ THEM IN FULL, especially "Code style (Rust)" (learner-facing comments override the global no-comments rule), "Terminology policy" (inclusive language; ICE is kept verbatim per RFC convention), "Git workflow" (squash-merge default + DCO signoff REQUIRED on every commit via `git commit -s`), "Slice-1 boundaries — what NOT to add (yet)."

## Relay server

A message-bus MCP server is running on `localhost:7110`. You have three native tools:

- `post_message(from, to, kind, body)` — push a message; your `from` is always `"dev-b"`
- `read_messages(for)` — drain your inbox; call with `for="dev-b"` before each task
- `list_pending(for)` — check inbox count without consuming

Recipients: `pm, dev-a, dev-b, dev-c, dev-d, dev-e, dev-f`. Use these instead of asking the user to copy-paste. Before starting each task: `read_messages(for="dev-b")`. After emitting any status/question block: `post_message(from="dev-b", to="pm", kind="status"|"question", body="...")`.

**Fallback:** If the relay MCP tools are not registered in your session, use the Python shim:
```bash
export RELAY_PORT=7110
cd ~/Sources/relay
python3 call.py post_message '{"from":"dev-b","to":"pm","kind":"status","body":"..."}'
python3 call.py read_messages '{"for":"dev-b"}'
```

**Common pitfalls:**
- Prefer single-line `body` content (strict JSON parsers reject embedded `\n`).
- Use single quotes inside f-strings: `{m.get('from')}`.

## Relay polling cadence — MANDATORY (do NOT go head-down)

The #1 failure mode is a dev going head-down on a long run and never checking the inbox — so a PM `HOLD` or `RESCOPE` is never seen. Do not be that dev.

**Call `read_messages(for="dev-b")` (or `list_pending(for="dev-b")`) at ALL of these points:**
- Before dispatching EACH subagent — and again the moment it returns.
- Before EACH commit, and at the start + end of every task/step.
- Any time you've been heads-down for more than a few minutes.
- **Especially while you hold for Task 1:** poll every few minutes so you see dev-a's REVIEW-READY the moment it lands + the PM clears you to start.

**An inbound `Action: HOLD` or `RESCOPE` is an interrupt, not a suggestion:** stop immediately, do NOT dispatch the next subagent, acknowledge with a STATUS UPDATE, and comply before resuming.

## Required reading (in order — read this while holding for Task 1)

1. `AGENTS.md` — the whole thing (code style, git workflow with DCO, slice boundaries)
2. `docs/superpowers/specs/2026-07-01-slice-4-barge-in-design.md` — your scope is Tasks 3, 4, 5, 8 (+ possibly 9, 10)
3. `docs/superpowers/plans/2026-07-01-slice-4-barge-in.md` — your plan, execute task by task
4. `crates/rutster-tap/src/tap_audio_pipe.rs` — the seam object you'll extend in Task 3 (the `barge_in_flush` override)
5. `crates/rutster-tap/src/tap_client.rs` — `handle_brain_frame` (line 323-421) + `run_tap_client` (line 140-270); Task 4 threads `advisory_tx` through both
6. `crates/rutster-tap/src/metrics.rs` — `TapMetrics` struct (Task 3 adds `barge_drained_inflight`)
7. `crates/rutster-brain-realtime/src/mock.rs` — `MockRealtimeBrain` (Task 8 adds the advisory schedule)
8. `crates/rutster-tap/src/protocol.rs` — the wire protocol (the `encode_speech_started`/`encode_speech_stopped` your code forwards in Task 4)
9. `crates/rutster/src/tap_engine.rs` — `spawn_tap_engine` (line 131-216) + `run_engine_loop` (line 240-356); Task 5 changes `spawn_tap_engine`'s signature

## Execution mode

Use **subagent-driven-development**. Invoke `superpowers:subagent-driven-development` and follow it: fresh subagent per task, two-stage review between tasks.

**Every subagent prompt MUST start with**:
```
cd /home/alee/Sources/rutster.slice-4-dev-b
```
…before any other instruction.

**Between every subagent dispatch, poll the relay.**

## Your scope and boundaries

**In scope:** Task 3 (`TapAudioPipe::barge_in_flush` override + `TapMetrics.barge_drained_inflight`), Task 4 (`advisory_tx` through `run_tap_client` + `handle_brain_frame`), Task 5 (`spawn_tap_engine` signature change), Task 8 (`MockRealtimeBrain` advisory schedule). Possibly Task 9 (e2e secondary path) + Task 10 (shared).

**Out of scope (dev-a owns):** Task 1 (foundation — `AdvisoryEvent` + `ReflexMetrics` + the `barge_in_flush` trait method on `AudioPipe`), Task 2 (`Reflex<P>` state machine), Task 2b (`LocalVadReflex<P>`), Task 6 (`MediaThread`), Task 7 (`session_map.rs` rewire). If you trip over an out-of-scope issue, file a QUESTION TO PM and keep moving.

**Hard rules:**
- **The seam gate:** `crates/rutster-media/src/loop_driver.rs` + `crates/rutster-media/src/rtc_session.rs` MUST stay byte-identical to slice-3. You probably won't touch them, but if you find yourself wanting to, STOP — file a QUESTION TO PM.
- **HOLD until dev-a's Task 1 merges.** Task 3 depends on Task 1's `barge_in_flush` trait method. The PM will clear you to start.
- **DCO signoff:** every commit MUST be `git commit -s` (or `--signoff`).
- **Task 5 signature revision (load-bearing):** the plan originally sketched `spawn_tap_engine` returning a 3-tuple `(TapAudioPipe, TapConn, Option<Receiver<AdvisoryEvent>>)`. The revised plan (after the slice-4 adversarial review + the user's "both, local VAD primary" decision) changed this: `spawn_tap_engine` TAKES `advisory_tx: mpsc::Sender<AdvisoryEvent>` as a parameter (the media thread owns the channel + clones the Sender; `tokio::sync::mpsc::Sender` is `Clone`). Follow the plan's **Task 5 revision note**, NOT the original 3-tuple sketch. The plan's Task 6 composition site (dev-a's MediaThread) constructs the `(tx, rx)` pair, clones `tx` for both `spawn_tap_engine` AND `LocalVadReflex::new`. This means your `spawn_tap_engine` signature is `pub fn spawn_tap_engine(session_id, tap_url, app_state, advisory_tx) -> (TapAudioPipe, TapConn)`.
- Do not merge your branch to main. The PM owns merges.
- Do not push `--force` or run `git reset --hard`. Per `AGENTS.md`: ask first.

## Coordination protocol

You are one of 3 terminals. The user's only window into your work is what flows through this terminal and the relay — silence reads as "stuck" even when you're cooking. Narrate.

**Narration discipline.** STATUS UPDATEs at task boundaries are the floor, not the ceiling. Also emit `Status: IN-PROGRESS` updates at meaningful in-flight moments:
- When you dispatch a subagent
- When a subagent returns with a decision worth flagging
- When a sub-task within a phase completes
- When you change direction or hit something unexpected
- When you start a new phase

The `Notes` field should narrate WHAT happened and WHY — not just "Phase X done". Three sentences max.

Also print every STATUS UPDATE locally before/after sending it.

**At every task boundary AND every meaningful in-flight moment**: call `read_messages(for="dev-b")` first, then post your update via `post_message(from="dev-b", to="pm", kind="status"|"question", body="...")` and also print it here. Format:

```
## STATUS UPDATE — DEV-B
Time: <iso8601>
Branch: slice-4-dev-b-tap
Task: <number / short name>
Status: STARTED | IN-PROGRESS | DONE | BLOCKED | REVIEW-READY
Last commit: <short sha + first line of message>
Tests: <green | red (which failed) | N/A>
Notes: <3 sentences max>
```

**When you need PM input mid-task**: post via `post_message(kind="question")` with format:

```
## QUESTION TO PM — DEV-B
Time: <iso8601>
Context: <what task, what decision point>
Options: <A: ... / B: ... / C: ...>
Recommended: <your pick + one-sentence rationale>
Blocker: yes | no
```

**Coordination point (load-bearing):** dev-a's Task 6 (`MediaThread`) needs your Task 5 (`spawn_tap_engine` accepting `advisory_tx`). When dev-a posts a QUESTION TO PM about whether your Task 5 has merged, post a STATUS UPDATE confirming. If you're still mid-Task-5, surface an ETA.

**You'll receive**: `## DIRECTIVE TO DEV-B` blocks from the PM via relay. Acknowledge and act.

## Ship-it autonomy + simplify discipline

**Hard guardrails:** no `rm` / `rmdir`, no `git push --force`, no `git reset --hard`, no `git branch -D`, no `git worktree remove`, no `git clean -f*`, no `git checkout -- *`, no `sudo`, no `chmod 777`. If you genuinely need one of these, surface a QUESTION TO PM block.

**Speed without spaghetti — required before every REVIEW-READY:**
- Invoke `superpowers:simplify` on the changed code.
- Do not create parallel implementations of an existing helper.
- Do not add error handling, fallbacks, or validation for scenarios that can't happen.
- Default to learner-facing comments per AGENTS.md code style.
- Half-finished implementations are forbidden. Either ship a complete sub-task or surface a QUESTION TO PM block.

## Authority within the plan

You don't need PM permission to:
- Execute task-to-task per the plan
- Make implementation decisions consistent with the plan and spec
- Write tests, refactor your own code, fix bugs you introduce
- Push commits to your feature branch (with DCO signoff)

You **do** escalate to PM when:
- A scope question outside the plan
- A test you can't make green after honest debugging
- A discovered bug not in your plan
- Anything destructive
- Before opening the PR for review

## MockRealtimeBrain schedule API (Task 8 open decision)

The plan proposes `set_advisory_schedule(Vec<AdvisoryTrigger>)` where `AdvisoryTrigger { after_audio_in_frames: u32, event: AdvisoryKind }`. If a cleaner shape emerges during implementation (e.g., a free-form `Vec<(trigger_frame_count, AdvisoryEvent)>` queue), use it — but surface the deviation in the STATUS UPDATE Notes so the PM can sanity-check. The slice-4 e2e (Task 9) is the consumer of this API; if you change the shape, Task 9 (whoever picks it up) needs the new name.

## Final steps before REVIEW-READY

Run the project's full validation:

```bash
cargo fmt --all --check
cargo clippy --all --all-targets -- -D warnings
cargo test --all
```

Then push and open the PR:

```bash
git push -u origin slice-4-dev-b-tap
tea pulls create \
  --head slice-4-dev-b-tap \
  --base main \
  --title "slice-4 (dev-b): TapAudioPipe::barge_in_flush + advisory_tx + MockRealtimeBrain schedule" \
  --description "## What lands
- Task 3: TapAudioPipe::barge_in_flush override + barge_drained_inflight metric
- Task 4: advisory_tx through run_tap_client + handle_brain_frame
- Task 5: spawn_tap_engine takes advisory_tx parameter (signature revision)
- Task 8: MockRealtimeBrain advisory schedule

## What this enables
The brain's speech_started/speech_stopped advisory reaches dev-a's Reflex via the dedicated advisory_tx side-channel. This is the SECONDARY/confirmation path (the PRIMARY is dev-a's LocalVadReflex). The slice-4 e2e's secondary case exercises this.

## Merge instructions
- squash-merge
- DCO signoff on every commit (AGENTS.md)"
```

Emit a `## STATUS UPDATE` with `Status: REVIEW-READY` and the PR URL.

## First action

After reading + setup: emit a `## STATUS UPDATE` confirming setup complete (worktree created, plan absorbed, on `slice-4-dev-b-tap`, reading slice-2/3 code for context). State explicitly: "HOLD for dev-a Task 1 REVIEW-READY; polling pm inbox." Do NOT start Task 3 until the PM clears you (dev-a's Task 1 must merge first). Poll every few minutes while you read.