# Strategic plan — spearhead step 4½ (benchmark + sim harness) AND step 5 (rented transport)

- **Status:** Draft (awaiting Momus review)
- **Date:** 2026-07-05
- **Spearhead footprint:** steps 4½ + 5 ([ADR-0010](../../docs/adr/0010-spearhead-benchmark-sim-harness.md) inserts 4½ between 4 and 5; [ADR-0007](../../docs/adr/0007-trunk-rented-transport.md) defines step 5)
- **Depends on (already merged):**
  - slice-1 WebRTC media core (PR #1)
  - slice-2 agent tap (PR #2)
  - slice-3 OpenAI Realtime brain (PR #4)
  - slice-4 barge-in / VAD-driven playout kill (PRs #7–#13)
  - slice-"5" scalability seams (librutster, NOT spearhead 5) — config.rs, event_sink.rs, MediaThread tick-lag gauge, drain lifecycle, advertised media address (PR #14)
  - ADR-0009 amendment shared spend accounting (PR #15)
- **Execution paradigm:** tmux-based multi-agent PM + N-dev, relay on port 7110, dev slots driven by Kimi K2.7 worker subagents (256k context window). See AGENTS.md "Multi-agent coordination — the relay".
- **Multi-agent-kickoff role count:** 1 PM + 3 devs (dev-a / dev-b / dev-c).
- **Branch prefix:** `slice-4-half/` and `slice-5/` (slice-level, not umbrella — see Git workflow).

---

## 1. Strategic scope

Two spearhead milestones bundled into one planning pass because (a) both ship on the same fused-vertical spine, (b) step 4½'s measurement harness is the proof artifact step 5's reflex claims depend on, and (c) bundling captures one PM setup + one relay poller lifecycle + one worktree layout.

### 1.1 What each slice IS

| Slice | Spearhead step | ADR | One-sentence goal | Output crate |
|---|---|---|---|---|
| 4½ — benchmark + sim | 4½ (inserted by ADR-0010) | ADR-0010 | A self-hostable simulation harness + CI-regressed latency thresholds that *measures* slice-4's ≤60 ms barge-in kill budget at 1/10/50 concurrency, exposing the single-thread HoL block debt with data not vibes. | `crates/rutster-sim/` (new) |
| 5 — rented transport | 5 of 6 | ADR-0007 | A real phone number via rented CPaaS raw-media fork (Twilio Media Streams MVP), no first-party SIP. PSTN audio enters the same reflex loop WebRTC legs use. | `crates/rutster-trunk/` (currently a stub; fills in this slice) |

### 1.2 The ADR-0010 sequencing fork (load-bearing — surface to user before execution starts)

[ADR-0010](../../docs/adr/0010-spearhead-benchmark-sim-harness.md) explicitly re-sequences the back half of the spearhead:

> **Sequencing after 4½:** rung-2 escalation (human takeover) is pulled forward ahead of steps 5–6. It is the white space no competitor ships… it works entirely on WebRTC ingress (no PSTN dependency), and it is the capability that answers "why not point the trunk at OpenAI directly?" before step 5 makes that question live. Steps 5 (rented transport) and 6 (spend cap) follow, unchanged in content.

Per ADR-0010, the canonical post-4½ order is:

```
4 (merged) → 4½ (this plan) → rung-2 escalation (deferred) → step 5 (this plan) → step 6 (spend cap)
```

This plan **bundles 4½ + step 5 per the user's explicit 2026-07-05 directive** ("write a plan to cover then implement 4.5 and 5"), which pushes step 5 AHEAD of rung-2 escalation. **This is a deliberate ADR-0010 deviation**, recorded here so it isn't a silent override. Reasons the user might choose this:
- The momentum value of a real phone number is the visceral demo the spearhead has been aiming at since slice-1.
- 4½'s simulation harness already proves the wedge; escalation's white-space argument ("why not point trunk at OpenAI") waits, but doesn't degrade.
- Rung-2 escalation is genuinely greenfield (no precedence in the codebase); step 5 is a more bounded integration against an existing slice-5-seams config. Risk profile favors 5 first.

**Default action:** proceed with this plan as written (4½ + step 5). If on review the user prefers to honor ADR-0010 literally, swap step 5 → rung-2 escalation in Phase 2; everything in Phase 1 + 3 still applies (Phase 1 = both specs, Phase 3 dispatch infra is ADR-agnostic).

### 1.3 Out-of-scope for THIS strategic plan

| Item | Returns in | Why out |
|---|---|---|
| rung-2 escalation (human takeover, whisper, warm handoff) | later, post-step-5 OR per ADR-0010 (preferred ordering) | ADR-0010 says first; this plan defers per §1.2 fork |
| Spend cap / abuse gate (spearhead step 6) | later (post-step-5) | sequenced last; needs trunk to spend against |
| Layer-2 out-of-tree SBC adapter | graduation rung | ADR-0007 explicitly defers — only the layer-1 CPaaS-fork MVP ships in step 5 |
| Twilio ConversationRelay / managed Voice-AI products | never in core | ADR-0007 forbids — they consume the reflex loop that is rutster's differentiation |
| LLM-driven synthetic callers (4½ extension) | post-4½ refinement | ADR-0010 says scripted scenarios are 4½; LLM callers are a later extension |
| VAD tuning framework | post-spearhead | slice-4 §1.2 defers; 4½ still ships the const threshold |
| Inbound endpoint registration (desk phones) | never | ADR-0007 green-zone, out-of-tree, never first-party |
| Per-session media threads / threadpool shard | later rung | slice-4 §1.2 defers; 4½'s concurrency sweep surfaces the debt with data |
| Barge-in across multi-party / conferencing | later rung | slice-4 §1.2 defers |
| Docker / `compose up` | later rung | not in spearhead |
| Browser-based Playwright e2e | post-spearhead | unchanged from slice-1's deferral |

### 1.4 FOB / green-zone classification (ADR-0008 application)

**Slice 4½** — entirely FOB. The sim harness:
- Hot-path-adjacent (it drives the same 20 ms media loop)
- Differentiating (the proof artifact; the wedge's measurement claim)
- Self-hosted, memory-safe Rust ⇒ FOB

The harness MAY link `str0m` and `tokio` (mature, actively-maintained) as trusted deps — same pattern as `rutster-media`. No green-zone members introduced.

**Step 5** — split:
- FOB: the WebSocket SERVER that ingests the provider's media fork, µ-law ↔ 24 kHz PCM transcoding, the `TrunkAudioPipe` (impl `AudioPipe`) that plugs into the existing media-leg seam, the reflex-loop wiring (slice-4's `Reflex`/`LocalVadReflex` apply transparently because they decorate `AudioPipe`, agnostic to leg type). All hot-path or differentiating ⇒ FOB.
- Green zone: Twilio REST API client (call control: answer/hangup/originate), credential storage, account-SID/account-token plumbing. This is a CPaaS dependency — ADR-0007 explicit. Lives in `crates/rutster-trunk/` at arm's length: behind a `CallControlClient` trait with a `TwilioCallControlClient` impl + a `MockCallControlClient` test double. The hot path never touches Twilio's REST API. The brain never holds provider credentials (ADR-0007 / ADR-0009).

### 1.5 The seam invariant (sacred)

`crates/rutster-media/src/loop_driver.rs` + `crates/rutster-media/src/rtc_session.rs` stay byte-identical through both slices. CI pinned-blob gate (slice-4 Task 10) keeps guarding. **Every dev directive broadcasts this.** The only exception: a future ADR explicitly says otherwise.

For slice 4½: no seam risk — the harness drives via existing media-leg path.
For step 5: the `TrunkAudioPipe` plugs into the existing `MediaThread` `HashMap<ChannelId, RtcSession>` shape; the existing RtcSession codepath (for WebRTC legs) is untouched. A new `MediaCmd::RegisterTrunk` variant routes through the existing command channel; the std thread accepts both WebRTC and trunk legs.

---

## 2. Phase 1 — Design specs (parallelizable)

Two design specs land before any code. Both can be written concurrently (different domains, no shared file between them).

### 2.1 Slice 4½ spec

**Path:** `docs/superpowers/specs/2026-07-XX-slice-4-half-benchmark-sim-design.md`

**Required sections (mirror slice-4 spec skeleton):**
- §1 Scope (1.1 in / 1.2 out — see §1.2 + §1.3 of this plan)
- §2 Architecture delta (the harness reusable across slices; measurement boundary; CI thresholds)
- §3 Component design (Scenario, SimAudioPipe, LatencyProbe, ConcurrencyRunner, TickLagGauge)
- §4 Data flow (caller-speech-onset → kill-fires path; the policy "drop + observe" for hot path)
- §5 Measurement plan (the budgets: ≤60 ms kill, p50/p99 mouth-to-ear, 1/10/50 concurrency targets)
- §6 Why these decisions (local vs LLM caller; scripted scenarios first; CI gate)
- §7 Done-criteria (CI threshold tables, regression fail-the-build contract)
- §8 Open decisions (threshold values; CI bench feature flag; machine-noise normalization)
- §9 Cross-references (ADR-0010, slice-4 §5.1 budget, slice-5/seams tick-lag gauge)

**Pre-decided design calls (to lock at spec time, not negotiate during impl):**
- The harness is a `cargo test --features=sim-bench` or `cargo bench`-style entrypoint; default `cargo test --all` does NOT trigger simulated benchmarks (they're opt-in to keep CI fast for code changes).
- A SECOND CI job runs `cargo test --features=sim-bench` per PR + nightly; failure fails the build (CI gate, ADR-0010).
- Scenario format is TOML or YAML (TBD at spec time). Each scenario = serialized caller PCM segments + timing + an expectation.
- Latency measurement uses `Instant::now()` (already monotonic) and aligned ring-buffer capture (`PcmFrame`-tagged timestamps at sink/source).
- Concurrency sweep asserts **p99 kill-time ≤ 80 ms at 1 / 10 / 50 calls** (80 ms = 60 ms budget + 20 ms observer slack; ADR-0010 explicitly allows the 60 ms kill + 1 tick).
- Tick-lag gauge (already in `media_thread.rs` from slice-5/seams) is the primary readout for "is the single-thread poll-loop under tension?" Expected at 1 call: ≤2 ms lag. At 50 calls: ≤10 ms lag. >20 ms ⇒ test fails (the HoL debt is real and needs a threadpool shard, slice-4 §1.2 explicitly deferred).

### 2.2 Step 5 spec

**Path:** `docs/superpowers/specs/2026-07-XX-slice-5-rented-transport-design.md`

**Required sections:**
- §1 Scope (1.1 in / 1.2 out — see §1.2 + §1.3 of this plan)
- §2 Architecture delta (the trunk as a media-leg ingress parallel to WebRTC; µ-law↔PCM transcoding; provider REST at arm's length; the `MediaThread` extension)
- §3 Component design (TwilioMediaStreamsServer, TrunkAudioPipe, G711Codec, CallControlClient trait + TwilioCallControlClient impl)
- §4 Data flow (provider WS connect → JSON "Start" → "Media" base64 µ-law frames → decode → PcmFrame → media-leg pipe → reflex loop → encode return)
- §5 Provider abstraction (the trait + the seam: config selects `twilio` | `telnyx` | `mock`; only Twilio ships in MVP, the trait locks the seam)
- §6 Why these decisions (no SIP, ever; raw-audio fork, not managed Voice-AI; FOB vs green-zone split)
- §7 Done-criteria (PSTN sim → reflex → barge-in e2e; media-leg abstraction works for both WebRTC + trunk; credential never leaks into the brain)
- §8 Open decisions (Twilio CallCtl vs raw-WS-only; Twilio chunk size / µ-law rate negotiation; account-SID storage — env vs KMS-backed Vault sidecar)
- §9 Cross-references (ADR-0007, ADR-0008, ADR-0009 spend-accounting amendment, slice-4 §3.1 reflex layering, slice-5/seams config surface)

**Pre-decided design calls:**
- MVP provider is **Twilio Media Streams** (raw-audio WSS fork at 8 kHz µ-law). Cleaner doc'd API than Telnyx; well-trodden.
- The provider REST call-control client (`answer`/`hangup`/`originate`) is **green-zone**: behind a trait, the Twilio impl uses `reqwest`. The FOB never holds Twilio credentials directly — they live in `crates/rutster-trunk` config behind a `TwilioCredentials` struct, scoped to the trunk crate only.
- µ-law (G.711) codec: build it in-core (~30 lines, table-driven, learner-facing comments — it's a fascinating piece of telephony history). The 8 kHz ↔ 24 kHz resampling uses linear interpolation (the slice-1 PcmFrame is 24 kHz; Twilio ships 8 kHz). No new dep.
- The trunk leg participates in `MediaThread`'s `MediaCmd` enum as `RegisterTrunk { provider, credentials, reply }` + `HangupTrunk { id, reply }`. The existing `Register`/`AcceptOffer`/`Delete`/`Shutdown` variants are unchanged. The std thread accepts the registration, opens a `TrunkAudioPipe`, wires `Reflex<TapAudioPipe>` (same composition as slice-4) and puts it in the same `HashMap<ChannelId, RtcSession-or-TrunkSession>`. Actually — to keep the seam clean, theEnum value carries the leg variant.
- The `AudioPipe` trait works as-is for trunk legs. The existing `TapAudioPipe` currently routes PCM over `tx_pcm_in` / `rx_audio_out` against the tap's WebSocket; for trunk legs, **the tap WS is the trunk WS** (provider raw-audio fork = the brain's audio_out / the caller's audio_in, swapped for the PSTN caller).

  Wait — that's a clean design: the trunk leg IS a TapAudioPipe where the WS endpoint is Twilio's media fork instead of OpenAI's WS endpoint. The tap protocol is replaced by Twilio's JSON framing. Different protocol on the WS, same `AudioPipe` shape on the FOB side. ✓.

### 2.3 Spec writing mode

Specs are written by the PM in the main session (not delegated). Rationale: they encode load-bearing decisions cross-referencing ADRs, prior slices, and the reflex-loop seam. Dev terminals consume specs; they don't write them.

After both specs land, both get a Momus review (one per spec — `.omo/plans/<spec-name>` invocation pattern is non-standard, see OpenCode Momus docs; use the `task(subagent_type="momus", prompt="<spec-path>")` form per AGENTS.md).

---

## 3. Phase 2 — Implementation plans

Two implementation plans, one per slice. Each derived from its spec.

### 3.1 Slice 4½ implementation plan

**Path:** `docs/superpowers/plans/2026-07-XX-slice-4-half-benchmark-sim.md`

**Tasks (Kimi-256k-sized — each fits comfortably, ≤4 files, ≤200 LOC, ≤6 tool calls per step):**

| Task # | Title | Files | Depends on | Parallelizable-now? |
|---|---|---|---|---|
| **S1** | `crates/rutster-sim/` skeleton + `Scenario`/`ScenarioStep` types + `PcmSegment` | new crate, `crates/rutster-sim/src/{lib.rs,scenario.rs}`, root `Cargo.toml` member | none | **FOUNDATION** — lands first |
| **S2** | `SimAudioPipe: AudioPipe` — scripted PCM playback on `next_pcm_frame`, captures received frames on `on_pcm_frame` (timestamps each) | `crates/rutster-sim/src/sim_audio_pipe.rs` | S1 | after S1 |
| **S3** | `LatencyProbe` — mouth-to-ear + barge-in kill-time probes; ring-buffer capture timestamps from `SimAudioPipe` | `crates/rutster-sim/src/latency.rs` | S2 | after S2 |
| **S4** | `ScenarioRunner` — drives one `SimCall` end-to-end against a target binary URL (or in-process via `MediaThread`) | `crates/rutster-sim/src/runner.rs` | S2, S3 | after S3 |
| **S5** | `ConcurrencyRunner` — N concurrent `SimCall`s, computes p50/p99 + aggregates per-call latencies | `crates/rutster-sim/src/concurrency.rs` | S4 | after S4 |
| **S6** | `TickLagGauge` — reads slice-5/seams tick-lag metric from `media_thread.rs` (already exposed via `MediaCmd::Stats`); exposes as primary readout in sweep report | `crates/rutster-sim/src/tick_lag.rs` | S5 | after S5 |
| **S7** | CI bench feature + 1/10/50 sweep thresholds — `cargo test --features=sim-bench`; CI job asserts thresholds | `.github/workflows/ci.yml`, `crates/rutster-sim/Cargo.toml` | S5, S6 | after S5 + S6 |
| **S8** | One shipped scenario pack (`scenarios/loud-barge.toml`, `scenarios/quiet-advisory.toml`, `scenarios/sustained-call.toml`) + LEARNING.md pointer | `crates/rutster-sim/scenarios/*`, `LEARNING.md` | S4 | filler; any time after S4 |

**Critical path:** S1 → S2 → S3 → S4 → S5 → S6 → S7 (linear). S8 is filler.

**Why linear:** each task consumes the prior task's types. Fanning out across this 8-task chain stalls. Instead, this slice is best executed by ONE Kimi dev (dev-a) doing the linear chain, while dev-b and dev-c work on the step-5 spec/plan + the step-5 fundamental tasks (see §3.2).

### 3.2 Step 5 implementation plan

**Path:** `docs/superpowers/plans/2026-07-XX-slice-5-rented-transport.md`

**Tasks:**

| Task # | Title | Files | Depends on | Parallelizable-now? |
|---|---|---|---|---|
| **T1** | `G711Codec` — µ-law encode/decode (table-driven, learner-commented) + 8 kHz↔24 kHz resampling | `crates/rutster-trunk/src/g711.rs`, `crates/rutster-trunk/src/lib.rs` | new `crates/rutster-trunk/Cargo.toml` deps (none — pure std) | **FOUNDATION** — lands first |
| **T2** | `CallControlClient` trait + `MockCallControlClient` (in-process test double) + `TwilioCredentials` config struct + env parser | `crates/rutster-trunk/src/provider/{mod.rs, mock.rs, twilio.rs}` | T1 (independent — provider module imports `g711` types? probably not — different file) | after T1 OR parallel |
| **T3** | `TwilioMediaStreamsServer` — accept inbound WSS connection, parse JSON Start/Media/Stop frames, decode base64 µ-law → PCM frames, encode return | `crates/rutster-trunk/src/twilio_media_streams.rs` | T1 | after T1 |
| **T4** | `TrunkAudioPipe: AudioPipe` — wraps the Twilio media-streams session as an `AudioPipe`; produces PCM frames on `next_pcm_frame` (decoded from Twilio "Media" frames), consumes PCM on `on_pcm_frame` (encoded to µ-law + sent as JSON "Media" frames back) | `crates/rutster-trunk/src/trunk_audio_pipe.rs` | T1, T3 | after T3 |
| **T5** | `MediaThread::RegisterTrunk` — extends `MediaCmd` enum (`Register`, `AcceptOffer`, `Delete`, `Shutdown`, `Stats`, `Drain` from slice-5) with `RegisterTrunk` variant; accepts a `TrunkAudioPipe`, wires `Reflex<TapAudioPipe>` (same composition as slice-4) and wraps `LocalVadReflex` outer; places in session map | `crates/rutster/src/media_thread.rs`, `crates/rutster/src/routes.rs` (new `POST /v1/sessions/trunk` route) | T4, + slice-4 (merged) + slice-5 (merged) | after T4 |
| **T6** | `TwilioCallControlClient` impl — REST API client (answer/hangup/originate); uses `reqwest`; credentials from env (slice-5/seams `config.rs` already has the parser pattern) | `crates/rutster-trunk/src/provider/twilio.rs` (extend), `crates/rutster/src/config.rs` (env parser) | T2 | parallel with T3/T4/T5 |
| **T7** | `Reflex applies to PSTN leg` — verify slice-4's `Reflex<TapAudioPipe>` + `LocalVadReflex` decorate the trunk `TrunkAudioPipe` transparently (or wire `Reflex<TrunkAudioPipe>` if the leg has its own pipe type) | `crates/rutster-trunk/tests/reflex_on_trunk.rs` | T4, T5 | after T5 |
| **T8** | PSTN sim e2e — `MockCallControlClient` + an in-process Twilio-media-streams simulator; verify barge-in fires on PSTN leg; CDR / `EventSink` emission | `crates/rutster-trunk/tests/sim_integ.rs` | T5, T7 | after T7 |
| **T9** | QUICKSTART update — env-var table for Twilio credentials; "make a real phone call" section | `docs/QUICKSTART.md`, `README.md` | T5, T6 | after T5 + T6 |
| **T10** | CI seam gate re-pin + cargo deny for any new Twilio dep | `.github/workflows/ci.yml`, `deny.toml` | T6 (introduces `reqwest` dep) | after T6 |

**Critical path:** T1 → T3 → T4 → T5 → T7 → T8. T2/T6 can start parallel with T1 if dev-b picks up T2 right away (provider trait doesn't depend on g711). T9 is filler (after T5 + T6 land). T10 is final sweep.

**Note on T2 ordering:** T2 is the spec'd out `CallControlClient` trait + mock + credential struct. It DOES NOT depend on T1 (g711 codec) — they live in different modules. Dev-b can pick up T2 in parallel with dev-c on T1.

### 3.3 Cross-slice dependency graph

```
4½ spec → 4½ plan → S1 → S2 → S3 → S4 → S5 → S6 → S7
                 ↘ S8 (filler; parallel after S4)

5 spec → 5 plan → T1 (foundation, parallel with T2) → T3 → T4 → T5 → T7 → T8
                                              ↘ T2 → T6 ↗
T9 (filler after T5 + T6)   T10 (final sweep)
```

**4½'s harness doesn't depend on step 5 code** (the sim harness drives any media leg; we'll bus it against the WebRTC ingress for the MVP latency thresholds — 4½'s tests run against WebRTC, not trunk, since slice-4 proved barge-in on WebRTC first). But the harness CAN test trunk legs once trunk lands — false dependency avoided.

**Step 5's reflex reuse depends on slice-4 (merged) — not on 4½.** So 4½ and step 5 implementation can run in PARALLEL across different dev terminals, in different worktrees.

---

## 4. Phase 3 — Multi-agent execution (tmux + Kimi K2.7 workers, 256k context)

### 4.1 Dev count + role assignment

**3 dev terminals:** `dev-a`, `dev-b`, `dev-c`. Each dev's terminal runs its own persistent agent (Claude Code or GLM session) which dispatches Kimi K2.7 Code worker subagents (`task(subagent_type="kimi-worker", load_skills=[...], run_in_background=false, prompt="...")`) for the unit-of-work tasks.

**Why Kimi-worker:** 256k context window is plenty for the per-task payloads above (each task's plan section + required reading + code ≅ 30–50k tokens). Kimi K2.7 Code is cheap + capable for slice-bound file-scoped Rust work. Each dev-session holds the cross-task context (worktree state, recent file edits, relay inbox); each Kimi-worker subagent does ONE task with TDD discipline.

**Dispatch shape:**

| Dev | Slice 4½ tasks | Step-5 tasks | Worktree path |
|---|---|---|---|
| `dev-a` | S1 → S2 → S3 → S4 → S5 → S6 → S7 → S8 (the linear chain) | — | `/home/alee/Sources/rutster.slice-4-half-sim` branch `slice-4-half/sim-harness-dev-a` |
| `dev-b` | — | T2 → T6 → T9 → T10 (the provider/REST + docs + final sweep chain) | `/home/alee/Sources/rutster.slice-5-trunk` branch `slice-5/rented-transport-dev-b` |
| `dev-c` | — | T1 → T3 → T4 → T5 → T7 → T8 (the media-streams + AudioPipe + MediaThread wiring chain) | `/home/alee/Sources/rutster.slice-5-trunk-b` branch `slice-5/rented-transport-dev-c` |

**Why split step-5 across two devs:** the file-set on the FOB side (`crates/rutster-trunk/src/{g711.rs, twilio_media_streams.rs, trunk_audio_pipe.rs}` + `crates/rutster/src/media_thread.rs`) is non-overlapping with the provider/REST + config side (`crates/rutster-trunk/src/provider/*` + `crates/rutster/src/config.rs` + `docs/QUICKSTART.md`). dev-c on FOB leg wiring, dev-b on provider/config/docs — same pattern as slice-4 (dev-a on reflex stack, dev-b on tap-client + mock brain).

### 4.2 Dispatch schedule (PM-side, derived after specs + plans land)

D-Day:

```
T+0    PM terminal opens (single tmux window — start.sh --tmux opens relay + pm only),
       scans .omo/plans + specs 4½ + step-5.
T+10m  PM applies multi-agent-kickoff skill → generates 4 kickoff prompts
       (saved under `docs/superpowers/kickoffs/2026-07-XX-spearhead-4half-5-{pm,dev-a,dev-b,dev-c}-prompt.md`).
T+15m  User pastes ONLY the PM prompt into the pm window. Relay + poller already running
       (PM launch checklist steps 1+2 done by the user before pasting).
T+30m  PM auto-spawns dev-a/b/c via 3 `task(subagent_type="general", run_in_background=true,
       prompt="<dev-prompt-file-content>")` calls. Each returns a `bg_...` task ID; PM
       retains them for `background_output(task_id="bg_...")` polling.
       Each dev subagent:
         - cd's into its worktree (creating it per the prompt's setup bash)
         - Reads plan + spec + AGENTS.md
         - Dispatches `task(subagent_type="kimi-worker", ...)` per plan task
         - Posts STATUS reports to the relay (`from="dev-X"`, `to="pm"`, `kind="status"`)
         - Returns REVIEW-READY + tea PR URL when its slice is complete
T+1h+  PM polls each dev's `bg_...` between its own turns + drains the relay inbox for
       kind=status messages. Surfaces actionable items to the user before they have to ask.
       Opens PR reviews (via tea) as each dev completes a task group.
T+5h ballpark EOL: all tasks merged, final CI sweep, Momus review of implementation,
       optional surfacing of any ADR-0010 escalation-vs-step-5 deviation for the user to ratify.
```

### 4.3 Per-task payload shape (what each Kimi-worker subagent receives)

Each task becomes one Kimi-worker invocation. The dev-session (holding context across tasks) calls:

```text
task(
  subagent_type="kimi-worker",
  load_skills=["programming"],      // shared/programming — strict-types, TDD
  run_in_background=false,
  prompt="<task-prompt>"
)
```

**Where `<task-prompt>` is the Kimi-sized work unit.** It carries six sections (matching AGENTS.md delegation protocol):

```
TASK: <S1 / T4 / etc. — short name>
EXPECTED OUTCOME: <files touched + tests added + commit message>
REQUIRED TOOLS: <Read/Grep/Edit/Bash + cargo test scoped to crate>
MUST DO:
  - Read the plan file: docs/superpowers/plans/<plan-path> -- section Task <N>
  - Read AGENTS.md "Code style (Rust)" section -- learner-facing comments REQUIRED
  - DCO signoff on every commit: `git commit -s`
  - Hot-path policy (if touching 20 ms tick code): NO ?-propagate; match-and-continue
  - Worktree: cd <dev-worktree-path> before any edit
MUST NOT DO:
  - Do NOT touch crates/rutster-media/src/{loop_driver.rs,rtc_session.rs} -- seam invariant
  - Do NOT cross-touch files owned by another dev (see plan: parallel-safe set per task)
  - Do NOT push --force, --reset-hard, branch -D, rm -rf
  - Do NOT start the next task in this subagent -- report STATUS only
CONTEXT:
  - Branch: <dev-branch>
  - Plan: docs/superpowers/plans/<plan-path>
  - Spec: docs/superpowers/specs/<spec-path>
  - Predecessor task status (if applicable): <SHA + commit message>
  - Successor task waiting on this: <task name + dev role>
```

**Task size validation (Kimi 256k constraint):** each `<task-prompt>` plus its required reading (plan section, spec section, AGENTS.md relevant section) plus the dev's code-write payload fits comfortably in **≤40k tokens**. The 256k ceiling gives 6× headroom for Kimi to read more broadly (other slice docs, str0m API exploration, etc.) if it benefits the work. Empirically kimi-worker is fast at file-scoped Rust work at this size.

### 4.4 Relay + worktree layout

| Item | Value |
|---|---|
| Relay path | `~/Sources/relay` (standalone, per AGENTS.md) |
| Relay port | `7110` (rutster's port per AGENTS.md table) |
| Poller command | `setsid env RELAY_PORT=7110 python3 ~/Sources/relay/poller.py >> /tmp/relay-poller/7110/poller.log 2>&1 < /dev/null & disown` |
| `watch.sh` window | `RELAY_PORT=7110 ~/Sources/relay/watch.sh` (live tail of inbox.log + poller.log) |
| Worktrees | `/home/alee/Sources/rutster.slice-4-half-sim` (dev-a) · `/home/alee/Sources/rutster.slice-5-trunk` (dev-b) · `/home/alee/Sources/rutster.slice-5-trunk-b` (dev-c) |
| Branch scheme | `slice-4-half/sim-harness-dev-a` · `slice-5/rented-transport-dev-b` · `slice-5/rented-transport-dev-c` |
| PM does NOT own a worktree | PM only reads main + reviews PRs (per multi-agent-kickoff role boundaries) |
| PR via `tea` | `tea pulls create --head <branch> --base main --title "..." --description "..."` (per AGENTS.md Git workflow) |
| Merge strategy | squash-merge for both slices (single-PR-per-task shape, linear history); carve-out for stacked branches (slice-4-half / slice-5 branch pair) → rebase-merge if SHAs carry to a dependent sibling branch |

### 4.5 Multi-agent kickoff — files this plan hands to the kickoff skill

After both specs + both impl plans land, the kickoff skill consumes:

- `<<SPEC_PATH>>` — there are TWO specs. The kickoff skill's `<<SPEC_PATH>>` placeholder is single-valued; we substitute with **both**, comma-separated, in the PM prompt's required-reading list (the kickoff skill's templates support explicit required-reading lists per role). Dev prompts reference ONLY their own slice's spec (dev-a → 4½ spec only; dev-b/dev-c → step-5 spec only).
- `<<PLAN_LIST_BULLETS>>` for the PM:
  - **Plan A:** `docs/superpowers/plans/2026-07-XX-slice-4-half-benchmark-sim.md` — slice 4½ sim harness; dev-a; S1→S8 linear; readouts feed ADR-0010's "is the wedge measured?" debt
  - **Plan B:** `docs/superpowers/plans/2026-07-XX-slice-5-rented-transport.md` — step-5 rented transport; dev-b (provider+docs) + dev-c (FOB media-streams + MediaThread wiring); 10 tasks T1→T10; Twilio Media Streams MVP per ADR-0007
- `<<DEV_COUNT>>` = 3
- `<<RELEASE_LABEL>>` = `spearhead-4half-and-5`
- `<<DEV_LETTERS_LIST>>` = `A, B, C`
- `<<ALL_ROLES_LIST>>` = `pm, dev-a, dev-b, dev-c`
- `<<RELAY_PORT>>` = `7110`
- `<<PROJECT_RULES_FILE>>` = `AGENTS.md` (not CLAUDE.md — rutster uses AGENTS.md)

### 4.6 Per-dev scope summaries (for the kickoff `<<DEV_SCOPE_SUMMARY>>` placeholders)

**dev-a (slice 4½):** Implements the entire `crates/rutster-sim/` crate (currently non-existent) — Scenario/ScenarioStep types, SimAudioPipe implementing rutster-media's AudioPipe trait, LatencyProbe with ring-buffer timestamp capture, ScenarioRunner for end-to-end call simulation, ConcurrencyRunner for N-concurrent-call p50/p99 latency measurement, TickLagGauge integration with slice-5/seams MediaThread::Stats metric, and a CI-regressed bench feature gating `cargo test --features=sim-bench`. Linear chain S1→S8; ships ADR-0010's "wedge is now measured by data, not arithmetic" closure.

**dev-b (step 5, provider + docs):** Implements the green-zone side of `crates/rutster-trunk/` — the `CallControlClient` trait + `MockCallControlClient` (in-process test double) + `TwilioCallControlClient` (REST client via `reqwest`), the `TwilioCredentials` config struct + env parser wired into `crates/rutster/src/config.rs`, the QUICKSTART + README updates for "make a real phone call", and the cargo-deny + CI seam-gate re-pinning after the new `reqwest` dep. Chain T2→T6→T9→T10; tightly bounded — never touches the FOB media-stream machinery.

**dev-c (step 5, FOB media + MediaThread wiring):** Implements the FOB side of `crates/rutster-trunk/` — the in-core µ-law (G.711) codec + 8kHz↔24kHz resampling (table-driven, learner-commented), the `TwilioMediaStreamsServer` (accept inbound WSS, parse JSON Start/Media/Stop frames, base64 decode → PCM frames), the `TrunkAudioPipe: AudioPipe` (wraps the WSS as an AudioPipe that produces PCM on next_pcm_frame / consumes + encodes on on_pcm_frame), the `MediaCmd::RegisterTrunk` extension to the existing MediaThread, the reflex-on-trunk-leg verification test, and the PSTN-sim e2e integration test. Chain T1→T3→T4→T5→T7→T8; the FOB hot-path / differentiating work.

---

## 5. Risks + open forks

### 5.1 ADR-0010 deviation (the load-bearing one)

§1.2 above. The user's directive ("4.5 and 5") pushes step 5 ahead of rung-2 escalation, contradicting ADR-0010's explicit pull-forward. Surfacing at user level with proposed default: **proceed with this plan as written; ratify the deviation by amending ADR-0010 (or leave ADR-0010 intact + note the deviation on the slice-5 PR description).** ADR-0010 doesn't strictly forbid the deviation — it states a default ordering. The user's call is legitimate; this plan records it loudly.

### 5.2 Twilio account credentials in CI

Slice 5's e2e needs Twilio credentials OR a Twilio simulator. The FOB-side TwilioMediaStreamsServer is testable in-process (simulator → real WSS→ real TrunkAudioPipe → real MediaThread → real Reflex); the green-zone-side TwilioCallControlClient needs either:
- (a) `cargo test --features=twilio-live` running against real Twilio (only on maintainer-triggered runs, not per-PR)
- (b) a `MockCallControlClient` for the per-PR sweep + a manual "live override" path

Default: **(b)**. CI runs the mock. The maintainer runs live e2e manually when validating a release. Documented in QUICKSTART.

### 5.3 Reflex re-composition for trunk legs

Slice-4's `Reflex<TapAudioPipe>` composes with `LocalVadReflex` outside. For trunk legs, the AudioPipe is `TrunkAudioPipe`. The composition is `LocalVadReflex<Reflex<TrunkAudioPipe>>` — same shape, different inner. The reflex trait + decorators are pipe-agnostic by design (slice-4 §3.2); the same wrappers instantiate against the new pipe.

**Risk:** if the trunk AudioPipe has different lifecycle semantics (e.g. needs explicit WebSocket close on barge), the slice-4 `barge_in_flush` interface might be too narrow. T7 (the reflex-on-trunk verification test) surfaces this. If it triggers, STOP + post `kind=question` to PM; do not silently widen the trait.

### 5.4 CI bench feature flag interaction with the existing test matrix

Slice-4's CI matrix runs `cargo test --all` on stable + 1.85. Adding `--features=sim-bench` to a separate job is fine; just ensure the bench feature doesn't ADD a default-on dependency (it must be opt-in only, or default `cargo test --all` stays fast for routine PRs).

### 5.5 Slice-5 / "scalability seams" naming collision

The merged infra-seams slice (PR #14) is internally labeled "slice-5" in its plan path (`docs/superpowers/plans/2026-07-04-slice-5-scalability-seams.md`) but the plan itself states: "this is *not* spearhead step 5 (rented-transport trunk)." That infra slice is the *pre-paver* for spearhead step 4½ + step 5. Newcomers may be confused. Mitigation: the new step-5 plan path uses `slice-5-rented-transport` (unambiguous); the existing one stays as-is (already merged). Document the distinction in the spec's §1.

### 5.6 Single-thread contention on trunk leg

Slice-4 §1.2 explicitly defers per-session media threads / threadpool shard. Slice 4½'s concurrency sweep (target: ≤10 ms tick-lag at 50 calls) reads the gauge but the trunk leg will be the first time a "second kind" of leg shares the std thread. If contention is observed during slice-5 dev-c e2e, the slice-4-half/seams debt pays off — the threadpool-shard graduation is the answer *with data*, not doctrine. Don't pull the graduation forward speculatively.

---

## 6. Phase order summary (PM cheat-sheet)

```
Phase A — Specs (PM, in main session, parallel):
  1a. Write `docs/superpowers/specs/2026-07-XX-slice-4-half-benchmark-sim-design.md`
  1b. Write `docs/superpowers/specs/2026-07-XX-slice-5-rented-transport-design.md`
  → Momus review both

Phase B — Impl plans (PM, in main session, parallel):
  2a. Write `docs/superpowers/plans/2026-07-XX-slice-4-half-benchmark-sim.md`
  2b. Write `docs/superpowers/plans/2026-07-XX-slice-5-rented-transport.md`
  → Momus review both

Phase C — Multi-agent kickoff (PM, in main session):
  3. Run `multi-agent-kickoff` skill — generate pm + dev-a + dev-b + dev-c prompts
     to `docs/superpowers/kickoffs/2026-07-XX-spearhead-4half-5-{pm,dev-a,dev-b,dev-c}-prompt.md`
  4. Verify relay (7110) is running; verify poller (≥3 cycle-complete lines)

Phase D — Execute (PM + dev terminals, separate windows):
  5. User opens 4 terminals, pastes prompts
  6. Each dev dispatches Kimi-worker subagents per task
  7. PM consolidates relay inbox + opens PRs as tasks finish
  8. Momus sweeps the merged stack
```

---

## 7. Stopping condition

This strategic plan is **done** when:

1. Both specs (4½ + step-5) are merged to main.
2. Both impl plans are merged to main.
3. The multi-agent-kickoff prompts exist + are committed (or the user opts to paste them ad-hoc).
4. Kimi-worker dispatch has executed every task in §3.1 + §3.2; all PRs merged.
5. CI is green on main: `cargo fmt --check`, `cargo clippy -- -D warnings`, `cargo test --all` (stable + 1.85), `cargo deny check`, the new `cargo test --all --features=sim-bench` job.
6. The seam gate still passes — `loop_driver.rs` + `rtc_session.rs` byte-identical.
7. Momus review of the merged stack passes.
8. ADR-0010 status reconciled (amend OR note deviation on the step-5 PR description).

At this point the spearhead has steps 1–5 complete; only step 6 (spend cap) + rung-2 escalation remain (in ADR-0010-recommended order: escalation first, then spend cap; per §1.2 fork, the user may re-confirm).

---

## 8. First action (PM-side, after plan ratification)

If this plan is ratified post-Momus:

1. Confirm the ADR-0010 deviation choice with the user (proceed as-written, swap step 5 → escalation, or amend ADR-0010).
2. Read AGENTS.md "Multi-agent coordination" + "PM-mode discipline" sections in full.
3. Start the poller if not running (verify ≥3 cycle-complete lines).
4. Begin Phase A (specs).
