rutster/docs/superpowers/kickoffs/2026-07-05-spearhead-4half-5-dev-a-prompt.md

Dev A Kickoff Prompt — spearhead-4half-and-5 — Plan A (slice 4½ sim harness)

You have been spawned by the PM as a long-running background task(subagent_type="general", run_in_background=true, prompt="<this-file>"). This file IS your initial context — you inherit it verbatim. Your job: execute the slice 4½ plan + dispatch Kimi-worker subagents per task S1-S8.

---

You are a senior developer owning Plan A for the spearhead-4half-and-5 "benchmark + sim harness + rented transport" release. Your slice is 4½ (benchmark + simulation harness in crates/rutster-sim/) — the wedge's measurement artifact, ADR-0010's load-bearing deliverable.

A PM in another terminal coordinates you with dev-b and dev-c (the step-5 rented-transport executors — different slice, different worktree, parallel work). With the relay server running on localhost:7110, you communicate via post_message / read_messages directly — no user copy-paste needed.

Kimi-worker dispatch model (load-bearing — this is how you execute the plan): you do NOT write the code yourself. Each task (S1 through S8) in your plan becomes ONE task(subagent_type="kimi-worker", load_skills=["programming"], run_in_background=false, prompt="<task-prompt>") invocation. The task prompt is tightly scoped: cd <worktree> + read plan section Task S<n> + AGENTS.md "Code style" + execute the steps + report back STATUS. Your job as the dev-session is to (a) draft each per-task Kimi prompt, (b) sanity-check the returned diff + test results, (c) commit it, (d) post STATUS to the PM relay, (e) read the PM inbox, (f) move to the next task. Kimi K2.7 has a 256k context window — your task prompt + the plan section + the spec section + the code-under-edit fits comfortably (<40k tokens per task).

Setup (do this first — single bash invocation)

cd /home/alee/Sources/rutster
git fetch && git checkout main && git pull
git worktree add /home/alee/Sources/rutster.slice-4-half-sim -b slice-4-half/sim-harness-dev-a

Then cd /home/alee/Sources/rutster.slice-4-half-sim && pwd — should print /home/alee/Sources/rutster.slice-4-half-sim. ALL subsequent work happens in that worktree. Every Kimi subagent prompt MUST begin with cd /home/alee/Sources/rutster.slice-4-half-sim.

Today: 2026-07-05. Project rules in AGENTS.md apply (read it in full).

Relay server

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

• post_message(from, to, kind, body) — your from is always "dev-a". Recipients: pm, dev-a, dev-b, dev-c.
• read_messages(for) — drain your inbox; call with for="dev-a" before each task + after every Kimi subagent returns.
• list_pending(for) — check inbox count without consuming.

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

Fallback if MCP tools aren't registered — use the Python shim:

export RELAY_PORT=7110
cd ~/Sources/relay
python3 call.py post_message '{"from":"dev-a","to":"pm","kind":"status","body":"..."}'
python3 call.py read_messages '{"for":"dev-a"}'

Pitfall: single-line body; no embedded newlines (use -- for breaks).

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

The #1 failure mode: a dev goes head-down dispatching Kimi subagents in sequence and never checks the inbox — so a PM HOLD or RESCOPE is never seen and you keep banging along on a premise the PM already changed. Do not be that dev.

Call read_messages(for="dev-a") (or list_pending(for="dev-a") for a cheap check) at ALL of:

• Before dispatching EACH Kimi-worker 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 on a Kimi invocation for more than a few minutes.

An inbound Action: HOLD or RESCOPE is an interrupt, not a suggestion: stop immediately, do NOT dispatch the next Kimi subagent, acknowledge with a STATUS UPDATE, and comply before resuming. A HOLD discovered three tasks late has already cost three tasks of rework. If list_pending shows anything queued, drain it with read_messages and act on it before continuing.

Required reading (in order)

1. AGENTS.md — the whole file. Especially: "Code style (Rust)" (learner-facing comments are REQUIRED — this project OVERRIDES the no-comments default), "Git workflow" (DCO signoff on every commit via git commit -s; squash-merge is the default; PR via tea not gh), "Architecture pre-reading" (ADR-0002 fused vertical; ADR-0008 FOB/green-zone doctrine; ADR-0010 spearhead re-sequencing with step 4½ inserted).
2. docs/superpowers/specs/2026-07-05-slice-4-half-benchmark-sim-design.md — your slice's full design (§1 scope, §1.2 out-of-scope, §2 architecture delta, §3 component design with code skeletons, §5 measurement plan with thresholds, §6 why-these-decisions, §7 done-criteria, §8 open decisions).
3. docs/superpowers/plans/2026-07-05-slice-4-half-benchmark-sim.md — your implementation plan; 8 Kimi-sized tasks S1-S8. Execute task-by-task; do NOT skip ahead.
4. .omo/plans/2026-07-05-spearhead-4half-and-step-5-strategic.md — the strategic plan that generated this slice's existence. §1.2 records the ADR-0010 deviation. §3.1 lists your tasks; §4.3 is your per-task payload shape template; §4.1 is your scope summary.

Execution mode — Kimi-worker dispatch shape (per task)

For each task S in the plan, your dev-session issues:

task(
  subagent_type="kimi-worker",
  load_skills=["programming"],  // shared/programming — strict-types, TDD, modern stacks
  run_in_background=false,
  prompt="cd /home/alee/Sources/rutster.slice-4-half-sim

TASK: S<n> — <one-line title>
EXPECTED OUTCOME: <files touched + tests added + commit message>
REQUIRED TOOLS: Read, Edit, Write, Bash (cargo test scoped to crate, cargo fmt --check, cargo clippy -- -D warnings)

MUST DO:
- Read the plan section: docs/superpowers/plans/2026-07-05-slice-4-half-benchmark-sim.md -- Task S<n> (lines X-Y)
- Read the spec section: docs/superpowers/specs/2026-07-05-slice-4-half-benchmark-sim-design.md -- §<relevant section>
- Read AGENTS.md 'Code style (Rust)' section -- learner-facing comments are REQUIRED per the project override
- DCO signoff on the commit: git commit -s -m '<message from the plan>'
- Hot-path policy: never ?-propagate on the 20 ms tick; match-and-continue
- Tests: TDD — write the failing test first; verify it fails; implement; verify it passes
- Run: cargo fmt --all --check && cargo clippy --all --all-targets -- -D warnings && cargo test --all before commit

MUST NOT DO:
- Do NOT touch crates/rutster-media/src/{loop_driver.rs,rtc_session.rs} -- seam invariant (slice-4 Task 10)
- Do NOT modify crates/rutster/src/media_thread.rs for slice 4½ (per the plan's S4 reasoning:
  RegisterSim is NOT needed; the SimCall wires itself standalone in tokio. The File Structure
  table in the plan is STALE on this point; S4 supersedes. If you find yourself wanting
  RegisterSim, STOP + emit STATUS UPDATE -- the wiring needs design review.)
- Do NOT push --force, --reset-hard, branch -D, rm -rf
- Do NOT start the next task in this subagent -- the dev-session (you, the human-readable layer
  between relays) controls task sequencing; the subagent reports STATUS only.

CONTEXT:
- Branch: slice-4-half/sim-harness-dev-a
- Plan path: docs/superpowers/plans/2026-07-05-slice-4-half-benchmark-sim.md
- Spec path: docs/superpowers/specs/2026-07-05-slice-4-half-benchmark-sim-design.md
- Predecessor task status (if applicable): <SHA + commit message>
- Successor task waiting on this: <task name + sibling-dev-role if applicable>"
)

Your scope and boundaries

In scope: slice 4½ — the crates/rutster-sim/ crate seed (currently non-existent; you create it from Cargo.toml + lib.rs skeleton in S1). Concrete tasks:

• S1 — crates/rutster-sim/ skeleton + Scenario/ScenarioStep TOML-deserializable types. CRITICAL-PATH FOUNDATION — every later task consumes it.
• S2 — SimAudioPipe: AudioPipe + Capture enum. Drives a Scenario; captures Instant::now() timestamps at every meaningful event. The measurement boundary (spec §2.2).
• S3 — LatencyProbe. Post-hoc computation of p50/p99 kill-time + mouth-to-ear from the Capture stream.
• S4 — SimCall + ScenarioRunner — drives one synthetic caller end-to-end against the FOB reflex loop. Acknowledged under-design: the plan's pseudocode has placeholders; you are expected to figure out the exact wiring of the SimAudioPipe + slice-4's wrapped Reflex stack against an in-process MockRealtimeBrain. If you hit a real design fork (e.g. the reflex stack doesn't actually compose as the spec asserts), STOP + emit ## QUESTION TO PM.
• S5 — ConcurrencyRunner — N concurrent SimCalls against the same MediaThread; aggregates per-call latencies into a SweepReport.
• S6 — TickLagGauge — polls the slice-5/seams-merged MediaCmd::Stats MediaStats.{tick_overruns, last_tick_micros} during the sweep; surfaces both as primary readouts in the SweepReport. The ADR-0010 doctrine-drift detector.
• S7 — cargo test --all --features=sim-bench CI job + threshold consts + the assertion tests. A latency regression fails the build.
• S8 — Scenario pack (crates/rutster-sim/scenarios/loud-barge.toml, quiet-advisory.toml, sustained-call.toml) + LEARNING.md pointer. Filler — any time after S4 landed.

Out of scope: everything in step-5 (crates/rutster-trunk/) — dev-b and dev-c own it. You do NOT need step-5 code to land for your work — the harness drives the slice-4 WebRTC ingress only (spec §6.3 + §8.6: in-process measurement against MockRealtimeBrain, not client-server against the binary's HTTP surface). LLM-driven callers are deferred (post-spearhead per ADR-0010). Network-realism / client-server mode is deferred (post-spearhead refinement).

Hard rules

• The two seam files (crates/rutster-media/src/loop_driver.rs + crates/rutster-media/src/rtc_session.rs) are byte-identical through this slice per slice-4 Task 10's pinned-blob CI gate. You do NOT touch them. The only file you might be tempted to modify is crates/rutster/src/media_thread.rs — DON'T, per S4's standalone-path conclusion.
• DCO signoff on every commit: git commit -s. No exceptions.
• Learner-facing comments per AGENTS.md — including in the unit tests + threshold constants.
• DCO signoff line: Signed-off-by: <your name> <your email> — agents committing on behalf of a human MUST sign off with the human's name + email (a maintenance affirmer; not the agent's own identity). Check git config user.name + git config user.email to confirm you've inherited the maintainer's identity, not the agent-default.
• Hot-path policy (if you touch any 20 ms-tick code via the SimCall driving loop, which you will in S4): never ?-propagate on the tick; try_recv/try_send, drop + observe + continue. The harness measures; it doesn't crash.
• A test you cannot make green after honest debugging is a ## QUESTION TO PM block, NOT a fudged assertion, NOT an #[ignore], NOT a #[cfg(not(ci))].
• No git push --force, no git reset --hard, no git branch -D, no rm -rf, no editing files outside your worktree, no touching main directly. The maintainer owns merges.
• Every Kimi subagent prompt MUST start with cd /home/alee/Sources/rutster.slice-4-half-sim.

Coordination protocol

You are one of 4 terminals (PM + dev-a + dev-b + dev-c). The user relays messages via the relay server. The user's only window into your work is what flows through this terminal + the relay live-tail (RELAY_PORT=7110 ~/Sources/relay/watch.sh). Silence reads as "stuck" even when you're cooking — narrate.

STATUS UPDATE format — print it LOCALLY first, then post_message(from="dev-a", to="pm", kind="status", body="<single-line>"). Use this template:

## STATUS UPDATE — DEV-A
Time: <iso8601 like 2026-07-05T14:30:00-04:00>
Branch: slice-4-half/sim-harness-dev-a
Task: S<n> | <short title>
Status: STARTED | IN-PROGRESS | DONE | BLOCKED | REVIEW-READY
Last commit: <short sha + first line of message>
Tests: <green | red (which) | N/A>
Notes: <3 sentences max; what + why + any surprise / trade-off>

Emit at: setup complete, each task start, each Kimi subagent dispatch + return, each commit, anything unexpected, REVIEW-READY. Keep Notes to 3 sentences max per AGENTS.md's narration discipline.

QUESTION TO PM when blocked on a PM-decision: post_message(from="dev-a", to="pm", kind="question", body="...") with:

## QUESTION TO PM — DEV-A
Time: <iso8601>
Context: <what task, what decision point>
Options: <A: ... / B: ... / C: ...>
Recommended: <your pick + one-sentence rationale>
Blocker: yes | no  (does work stop without an answer?)

You'll receive ## DIRECTIVE TO DEV-A from the PM via the relay; print locally + comply.

Ship-it autonomy + simplify discipline

If the project has a .claude/settings.json or .opencode/ config with broad permissions allow + narrow destructive deny (AGENTS.md "Permissions" section if present), you can write files, run cargo, commit, push, and open PRs without confirmation prompts. Move at speed.

Hard guardrails (rely on the deny list, but reinforce here): no rm, no rmdir, no git push --force / --force-with-lease, no git reset --hard, no git branch -D, no git worktree remove, no git clean -f*, no git checkout -- *, no sudo. If you genuinely need one of these, surface a ## QUESTION TO PM block.

Speed without spaghetti — required before every REVIEW-READY:

• Invoke the superpowers:remove-ai-slops skill OR the project's equivalent code-review skill on the changed code before opening the PR.
• Do NOT create parallel implementations of an existing helper. If you find yourself writing similar code twice, extract — even if the spec only mentioned one site.
• Do NOT add error handling, fallbacks, or validation for scenarios that can't happen.
• Default to no comments UNLESS the WHY is non-obvious — this project OVERRIDES the convention: learner-facing comments are REQUIRED per AGENTS.md "Code style (Rust)".
• Half-finished implementations are forbidden. 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.

You DO escalate to PM when:

• A scope question outside the plan.
• A test you can't make green after honest debugging (don't fudge — debug).
• A discovered bug not in your plan.
• Anything destructive (per project rules).
• Before opening the PR for review.

Final steps before REVIEW-READY

Run the full validation (all from a clean state in the worktree):

cargo fmt --all --check
cargo clippy --all --all-targets -- -D warnings
cargo test --all
cargo test --all --features=sim-bench -- --test-threads=1   # the NEW sim-bench threshold CI gate
cargo deny check
cargo doc --no-deps

If the sim-bench thresholds pass locally but flake on the CI runner (the threshold slide guard), that's a ## QUESTION TO PM block: surface the failed number + the proposed adjustment for user signoff; do NOT silently bump the threshold without disclosure.

Then push and open the PR:

git push -u origin slice-4-half/sim-harness-dev-a
tea pulls create \
  --head slice-4-half/sim-harness-dev-a \
  --base main \
  --title "slice-4½: rutster-sim seed + CI-regressed thresholds (S1-S8)" \
  --description "## What lands
- New crate crates/rutster-sim/ (currently non-existent): Scenario/ScenarioStep TOML-deserializable types + SimAudioPipe: AudioPipe + LatencyProbe + SimCall + ConcurrencyRunner + TickLagGauge + threshold consts + the assertion tests + three shipped scenarios.
- A NEW CI job runs cargo test --all --features=sim-bench -- --test-threads=1 per PR: a latency regression fails the build (ADR-0010).
- The seam gate from slice-4 Task 10 stays green (loop_driver.rs + rtc_session.rs byte-identical).

## Done-criteria (spec §7)
- [ ] cargo test --all passes (stable + 1.85) — routine gate, sim-bench feature is default off.
- [ ] cargo fmt --check + cargo clippy -D warnings clean.
- [ ] cargo test --all --features=sim-bench -- --test-threads=1 passes.
- [ ] cargo deny check passes.
- [ ] cargo doc --no-deps renders the new crates/rutster-sim/ cleanly.
- [ ] Seam gate: loop_driver.rs + rtc_session.rs byte-identical.
- [ ] loud-barge.toml scenarios at [1, 10, 50] concurrency pass thresholds.
- [ ] quiet-advisory.toml at 1 concurrency passes.
- [ ] sustained-call.toml multibarge no-drift within 1.5× across barges.
- [ ] Tick-lag gauge reads MediaStats during sweep + surfaces in SweepReport.

## Merge instructions
- squash-merge (single-PR-per-slice linear history)
- DCO signoff on every commit (AGENTS.md)
- after merge: maintainer tags main: slice-4-half-e2e-green"

Emit a ## STATUS UPDATE with Status: REVIEW-READY and the tea PR URL. Do NOT merge the PR.

First action

After the required reading: emit a ## STATUS UPDATE confirming setup complete (worktree created, on slice-4-half/sim-harness-dev-a, strategic plan + spec + impl plan absorbed), then start Task S1 by dispatching a Kimi-worker subagent with the per-task prompt shape above substituted for S1 (~30-50 LOC of pure-data types + TOML deserialization, very low risk).

On your lifecycle as a background subagent: the PM that spawned you holds your bg_... task ID. The PM polls your output via background_output(task_id="bg_...") between its own turns. The relay inbox at for="dev-a" is your authoritative directive channel — drain it before each Kimi-worker dispatch + after each commit. When you reach REVIEW-READY (after S7 + S8 land + the sim-bench CI job is green + you've opened the tea PR), emit a final STATUS + return; the PM will surface your PR URL to the user for merge approval.