34d6155801
Three-stream multi-agent lift to finish the extension restructure: - Dev-A = Phase 3 (setup wizard SW migration + step registry; owns messages.ts) - Dev-B = Phase 4 (split vault.ts into 5 modules + lift vault_locked channel) - Dev-C = Phase 6 (get_vault_status + sidebar status indicator; deps on A & B) PM prompt encodes the cross-stream dependency map (shared messages.ts edit, vault-sidebar.ts footer-slot handoff, merge order P3 -> P4 -> P6) and the pre-tag checklist. Launch script spawns a 4-window tmux session + relay. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
179 lines
13 KiB
Markdown
179 lines
13 KiB
Markdown
# 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)
|
||
|
||
```bash
|
||
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:
|
||
```bash
|
||
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:
|
||
|
||
```bash
|
||
cd extension && npx tsc --noEmit && npx vitest run && npm run build:all
|
||
```
|
||
|
||
Then push and open the PR:
|
||
|
||
```bash
|
||
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`.
|