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

Dev C Kickoff Prompt — v0.7.0 Plan C (Phase 6)

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

---

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

Your plan is Phase 6 — get_vault_status SW handler + sidebar status indicator (Tasks 6.1–6.3) of the extension restructure. You add the get_vault_status service-worker handler (returning cached ahead/behind/lastSyncAt from state.gitHost plus a live pendingItems count — no network call), build the vault-status.ts renderer for the sidebar-footer indicator, and wire it into the sidebar (refresh on mount + a manual ↻ button, no timer polling). This closes the last relicario status CLI/extension parity gap. Effort: S-M.

⚠️ Your phase has cross-stream dependencies — read the coordination rules carefully. Phase 6 depends on Phase 3 (Dev-A) for the get_vault_status message type and on Phase 4 (Dev-B) for the vault-sidebar.ts module you wire into.

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-6-vault-status -b phase-c-6-vault-status
cd /home/alee/Sources/relicario/.worktrees/phase-c-6-vault-status
pwd  # should print /home/alee/Sources/relicario/.worktrees/phase-c-6-vault-status

ALL subsequent work happens in /home/alee/Sources/relicario/.worktrees/phase-c-6-vault-status. 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-6-vault-status 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-c"
• read_messages(for) — drain your inbox; call with for="dev-c" 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-c"). After emitting any status/question block: post_message(from="dev-c", 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-c","to":"pm","kind":"status","body":"..."}'
python3 call.py read_messages '{"for":"dev-c"}'

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 6 only)
3. docs/superpowers/plans/2026-05-30-extension-restructure.md — your plan is Phase 6, Tasks 6.1–6.3. 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-6-vault-status

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

Your scope and boundaries

In scope: Phase 6 Tasks 6.1–6.3 — handleGetVaultStatus in service-worker/vault.ts + cached ahead/behind/lastSyncAt fields on the git-host state + populating them in the sync handler + dispatch wiring in popup-only.ts; the vault-status.ts renderer + any new glyphs in shared/glyphs.ts; wiring the indicator into vault-sidebar.ts's footer (mount + manual refresh). Tests: service-worker/__tests__/vault-status.test.ts, vault/__tests__/status-indicator.test.ts.

Out of scope: Phase 3 (Dev-A owns setup.ts, ALL of messages.ts, and the create_vault/attach_vault handlers) and Phase 4 (Dev-B owns the vault.ts split, including creating vault-sidebar.ts). You only modify vault-sidebar.ts to add the wiring in Task 6.3. 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 — sequencing (this is the crux of your phase):

• Do NOT touch shared/messages.ts. Dev-A (Phase 3, Task 3.1) defines the get_vault_status request type + GetVaultStatusResponse interface. You import GetVaultStatusResponse from ../shared/messages; you never declare it. Before you can compile Task 6.1, Dev-A's Task 3.1 must have landed on main (or be available to merge). Confirm with the PM at kickoff. If it hasn't landed, ask the PM whether to wait or to proceed against a temporary local type and reconcile at merge — prefer waiting if Dev-A is close.
• Stage your tasks 6.1 → 6.2 → 6.3. Tasks 6.1 (SW handler) and 6.2 (renderer) are independent of Phase 4 and you can build them as soon as the get_vault_status type exists. Task 6.3 wires into vault-sidebar.ts, which Dev-B (Phase 4) creates — you MUST wait for Dev-B's Phase 4 PR to merge before doing Task 6.3. Ask the PM to confirm Phase 4 is merged, then pull main into your branch and do the wiring. Dev-B has been told to leave an empty #vault-status-slot footer element for you.
• Your get_vault_status handler is additive in service-worker/vault.ts alongside Dev-A's create_vault/attach_vault handlers. Expect a possible small merge conflict on the import block / dispatch switch in service-worker/vault.ts + popup-only.ts; the PM will sequence your SW handler merge after Dev-A's Phase 3.
• No network in get_vault_status — return cached state only. The spec is explicit: sync is user-initiated. No timer polling in the wiring — refresh on mount + manual ↻ button only.
• 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, and especially when you are blocked waiting on Dev-A's or Dev-B's merge (so the PM knows your idle is a dependency wait, not a stall). The Notes field narrates WHAT happened and WHY. Three sentences max. Print every STATUS UPDATE locally before/after sending it.

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

## STATUS UPDATE — DEV-C
Time: <iso8601 like 2026-05-31T14:30:00-07:00>
Branch: phase-c-6-vault-status
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 (e.g. "is Phase 3's get_vault_status type merged yet?" / "is Phase 4 merged so I can do 6.3?"): post via post_message(kind="question") with format:

## QUESTION TO PM — DEV-C
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-C 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 (reuse shared/relative-time.ts for the timestamp; reuse the existing glyph family in shared/glyphs.ts).
• 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; the dependency waits (Phase 3 type / Phase 4 sidebar); 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-6-vault-status
gh pr create --base main --head phase-c-6-vault-status --title "feat(ext): Plan C Phase 6 — get_vault_status + sidebar status indicator" --body "$(cat <<'EOF'
## Plan C Phase 6 — get_vault_status + sidebar status indicator

Part of v0.7.0 (finish the extension restructure). Implements Phase 6 (Tasks 6.1–6.3) of `docs/superpowers/plans/2026-05-30-extension-restructure.md`. Closes the `relicario status` CLI/extension parity gap.

### What changed
- `service-worker/vault.ts`: `handleGetVaultStatus` — returns cached `ahead`/`behind`/`lastSyncAt` from `state.gitHost` + live `pendingItems` from the manifest. No network call.
- `service-worker/git-host.ts`: cached `lastSyncAt`/`ahead`/`behind` fields, populated by the `sync` handler.
- `service-worker/router/popup-only.ts`: `get_vault_status` dispatch case.
- `vault/vault-status.ts`: sidebar-footer indicator renderer (in sync / N ahead / N behind / N pending / never synced); reuses `shared/relative-time.ts` + glyph family.
- `vault/vault-sidebar.ts`: wired the indicator into the footer slot — refresh on mount + manual ↻ button, no timer polling.
- Tests: `service-worker/__tests__/vault-status.test.ts`, `vault/__tests__/status-indicator.test.ts`.

### Coordination notes
- Consumes the `get_vault_status` message type defined by Dev-A's Phase 3 (`messages.ts`); does not redefine it.
- Task 6.3 wiring lands on top of Dev-B's Phase 4 `vault-sidebar.ts` (merged first).

### 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 (`get_vault_status` dispatched + rendered, no network in handler, no polling timer).

🤖 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-6-vault-status). Then immediately ask the PM (via ## QUESTION TO PM) whether Dev-A's Phase 3 get_vault_status type has landed yet — that gates Task 6.1. While you wait, you can prepare the Task 6.2 renderer (vault-status.ts) since it only needs the local VaultStatus shape, not messages.ts.