relicario/docs/superpowers/coordination/v0.7-dev-b-prompt.md

Dev B Kickoff Prompt — v0.7.0 Plan B (Phase 4)

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

---

You are a senior developer owning Plan B for the v0.7.0 "finish the extension restructure" release.

Your plan is Phase 4 — Split vault.ts + lift vault_locked channel (Tasks 4.1–4.7) of the extension restructure. You split the 1037-LOC vault.ts monolith into 5 focused modules — vault-shell.ts, vault-sidebar.ts, vault-list.ts, vault-drawer.ts, vault-form-wrapper.ts — trimming vault.ts to ≤~250 LOC of routing + state, add the debounced sidebar search, and lift the vault_locked RPC intercept out of vault.ts into shared/state.ts's sendMessage wrapper (whose signature Phase 1 already laid). Effort: M. Phase 1 (the typed StateHost foundation) is already merged.

A PM in another terminal coordinates you with the other two senior devs. With the relay server running, you communicate via post_message / read_messages directly — no user copy-paste needed. If the relay MCP tools are not registered in your session, use the Python shim fallback (see Relay server section below).

Setup (do this first)

cd /home/alee/Sources/relicario
git fetch
git checkout main
git pull
git worktree add /home/alee/Sources/relicario/.worktrees/phase-c-4-vault-split -b phase-c-4-vault-split
cd /home/alee/Sources/relicario/.worktrees/phase-c-4-vault-split
pwd  # should print /home/alee/Sources/relicario/.worktrees/phase-c-4-vault-split

ALL subsequent work happens in /home/alee/Sources/relicario/.worktrees/phase-c-4-vault-split. Per project memory (CLAUDE.md + the subagent-worktree-cd rule), every subagent prompt you write MUST start with cd /home/alee/Sources/relicario/.worktrees/phase-c-4-vault-split before any other instruction — otherwise the subagent may commit to main.

Today: 2026-05-31. Project rules in CLAUDE.md apply.

Relay server

A message-bus MCP server is running on localhost:7331. 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. 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:

cd /home/alee/Sources/relicario/tools/relay
python3 call.py post_message '{"from":"dev-b","to":"pm","kind":"status","body":"..."}'
python3 call.py read_messages '{"for":"dev-b"}'

Common pitfalls (avoid):

• Prefer single-line body content. Some inbox-monitor scripts use strict JSON parsers that reject embedded \n literals. Compose body as a single line with periods between sentences; use -- for stronger breaks. Reserve actual newlines for STATUS UPDATEs you print locally only.
• Python f-string footgun in inbox-monitor scripts. If a polling script does print(f"... {m.get(\"from\")} ..."), Python errors with SyntaxError. Use single quotes inside brace expressions: {m.get('from')}.

Required reading (in order)

1. CLAUDE.md — project rules
2. docs/superpowers/specs/2026-05-04-extension-restructure-design.md — spec (your scope is Phase 4 / P1.5 only)
3. docs/superpowers/plans/2026-05-30-extension-restructure.md — your plan is Phase 4, Tasks 4.1–4.7. Execute task by task. (Phases 1, 2, 5 are already merged — do not redo them.)

Execution mode

Use subagent-driven-development (project default). 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/relicario/.worktrees/phase-c-4-vault-split

…before any other instruction. This is non-negotiable per project memory.

Your scope and boundaries

In scope: Phase 4 Tasks 4.1–4.7 — create vault-shell.ts, vault-sidebar.ts (with the 80ms debounced search per DEV-C P2), vault-list.ts, vault-drawer.ts (incl. ensureDrawerClosedForRoute + drawer auto-close on non-list nav), vault-form-wrapper.ts; trim vault.ts to routing + state ≤~250 LOC; remove the vault_locked intercept from vault.ts and fill the body of shared/state.ts's sendMessage wrapper with it; the drawer-state + (any vault) tests.

Out of scope: Phase 3 (Dev-A owns setup.ts + messages.ts + the create_vault/attach_vault SW handlers) and Phase 6 (Dev-C owns get_vault_status + the vault-status.ts renderer + its sidebar-footer wiring). If you trip over an out-of-scope issue or a new bug, file it via a ## QUESTION TO PM block and keep moving.

Hard rules:

• You create extension/src/vault/vault-sidebar.ts. Dev-C (Phase 6, Task 6.3) will later modify it to wire the status indicator into the sidebar footer. To make that handoff clean, when you build vault-sidebar.ts, include a clearly-labelled footer slot in the sidebar markup (an empty <div id="vault-status-slot"></div> inside a vault-sidebar__footer element is fine) even though you don't populate it — leave a one-line comment that Phase 6 wires it. Tell the PM the moment Phase 4 is REVIEW-READY/merged so Dev-C can start Task 6.3.
• The vault_locked intercept logic is moved, not rewritten: lift the exact behavior from vault.ts (the pre-Phase-4 RPC intercept) into sendMessage in shared/state.ts. After the move, grep -c "vault_locked" extension/src/vault/vault.ts must return 0.
• Each module extraction is a no-behavior-change refactor — run npx vitest run after each and keep it green. Paste function bodies verbatim from vault.ts; don't redesign them.
• Do not touch shared/messages.ts — that's Dev-A's file for this release. If you think you need a message change, escalate to PM.
• Do not merge your branch to main. The PM owns merges.
• Do not push --force or run git reset --hard / git branch -D / git worktree remove. Per CLAUDE.md: ask first.

Coordination protocol

You are one of multiple 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 a decision worth flagging, when a sub-task completes, when you change direction or hit something unexpected, when you start a new task. The Notes field narrates WHAT happened and WHY. Three sentences max; quality over length. 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 via post_message(from="dev-b", to="pm", kind="status"|"question", body="...") and also print it here. Format:

## STATUS UPDATE — DEV-B
Time: <iso8601 like 2026-05-31T14:30:00-07:00>
Branch: phase-c-4-vault-split
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: <anything PM needs to know — keep to 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  (does work stop without an answer?)

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

Ship-it autonomy + simplify discipline

The repo has .claude/settings.json with broad allow + narrow destructive deny. You can write files, run language tooling, commit, push, and open PRs without confirmation prompts. Move at speed.

Hard guardrails: no rm / 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 git restore --source*, no sudo, no chmod 777. If you genuinely need one, surface a ## QUESTION TO PM block.

Speed without spaghetti — required before every REVIEW-READY:

• Invoke superpowers:simplify on the changed code. Either accept its findings (fix in the same commit) or surface a one-sentence rationale in the STATUS UPDATE Notes.
• Do not create parallel implementations of an existing helper. If you write similar code twice, extract.
• Do not add error handling / fallbacks / validation for scenarios that can't happen (project rule). Trust internal code and framework guarantees.
• Default to no comments unless the WHY is non-obvious.
• 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 plan + 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; a discovered bug not in your plan; anything destructive; before opening the PR for review.

Final steps before REVIEW-READY

Run the project's full validation:

cd extension && npx tsc --noEmit && npx vitest run && npm run build:all

Then push and open the PR:

git push -u origin phase-c-4-vault-split
gh pr create --base main --head phase-c-4-vault-split --title "refactor(ext): Plan C Phase 4 — split vault.ts + lift vault_locked channel" --body "$(cat <<'EOF'
## Plan C Phase 4 — Split vault.ts + lift vault_locked channel

Part of v0.7.0 (finish the extension restructure). Implements Phase 4 (Tasks 4.1–4.7) of `docs/superpowers/plans/2026-05-30-extension-restructure.md`.

### What changed
- Split the 1037-LOC `vault/vault.ts` into 5 modules: `vault-shell.ts` (DOM scaffolding + color-scheme + onMessage), `vault-sidebar.ts` (categories nav + 80ms debounced search + bottom nav + footer status slot), `vault-list.ts` (list/row rendering), `vault-drawer.ts` (open/close/render + `ensureDrawerClosedForRoute`), `vault-form-wrapper.ts` (`renderFormWrapped` + sticky bar + header).
- `vault.ts` trimmed to ≤~250 LOC of routing + state.
- Lifted the `vault_locked` RPC intercept out of `vault.ts` into `shared/state.ts`'s `sendMessage` wrapper (Phase 1 laid the signature; this fills the body).
- Tests: `vault/__tests__/drawer-state.test.ts` (drawer auto-close on navigation) + state `vault_locked` channel coverage.

### Coordination notes
- `vault-sidebar.ts` ships with an empty footer status slot (`#vault-status-slot`); Dev-C's Phase 6 Task 6.3 wires the indicator into it. Merge this PR before Dev-C's wiring commit.
- No `messages.ts` changes (that's Dev-A's file this release).

### Verification
- `npx tsc --noEmit` clean · `npx vitest run` green · `npm run build:all` clean (pre-existing 4MB WASM warning only).
- Done-criteria greps from the plan's Task 7.1 pass (5 `vault-*.ts` modules, `vault.ts` ≤~250 LOC, `vault_locked` count 0 in vault.ts, `SEARCH_DEBOUNCE_MS` present).

🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

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

First action

After reading: emit a ## STATUS UPDATE confirming setup complete (worktree created, plan absorbed, on phase-c-4-vault-split), then start Task 4.1. Remember to leave the footer status slot in vault-sidebar.ts for Dev-C, and ping the PM when you're REVIEW-READY so Dev-C can begin Task 6.3.