# Dev B Kickoff Prompt — CLI Tail (Cycle 2) Stream B Paste everything below the `---` line into a fresh Claude Code terminal as the first user message. --- You are a **senior developer** owning Stream B of the CLI-tail cycle-2 release. Stream B is **Plan B Phases 4, 5, 6** — session/manifest discipline. Three phases, S-M effort each, total mid-day to multi-day: - **Phase 4** — `Vault::after_manifest_change(&self, manifest: &Manifest)` wrapper that funnels the seven manifest-mutation sites in `commands/{add,edit,trash,attach,settings,import}.rs` through one `save_manifest + groups-cache write` path. Marks `save_manifest` as `pub(crate)` (or renames it `save_manifest_raw`) so callers must use the wrapper. - **Phase 5** — Single canonical `ParamsFile` in `crates/relicario-cli/src/session.rs`, replacing the two-definition split between `commands/init.rs` (write side) and `session.rs:114` (read side). Adds `Serialize` + `Deserialize`, `for_new_vault` constructor, `into_kdf_params` inversion. On-disk JSON format must round-trip with current `params.json` files. - **Phase 6** — Batched purge in `cmd_purge` and `cmd_trash_empty`. Renames `purge_item` to `purge_item_filesystem` (filesystem mutation only); the callers accumulate paths and run a single `git_run(...["rm", "-rf", "--ignore-unmatch", paths...])` plus `git_run(...["add", "manifest.enc"])` plus one `git_run(...["commit"])` per batch. A 50-item `trash empty` should fire 3 git invocations total, not 150. The phases are defined in `docs/superpowers/specs/2026-05-04-cli-restructure-design.md` under "Phase 4", "Phase 5", "Phase 6". Internal sequencing: Phase 4 before Phase 6 (Phase 6 uses `after_manifest_change`); Phase 5 is independent of 4 and 6. A PM in another terminal coordinates you with Dev-A (Plan B Phase 3) and Dev-C (Plan B Phases 7, 8). With the relay server running, you communicate via `post_message` / `read_messages` directly — no user copy-paste needed. ## Setup (do this first) ```bash cd /home/alee/Sources/relicario git fetch git checkout main git pull git worktree add ../relicario.cli-tail-stream-b -b feature/cli-tail-stream-b-session-manifest cd ../relicario.cli-tail-stream-b pwd # should print /home/alee/Sources/relicario.cli-tail-stream-b ``` **ALL subsequent work happens in `/home/alee/Sources/relicario.cli-tail-stream-b`**. Force-cd subagents into this directory — `CLAUDE.md` has a memory rule that subagent prompts MUST start with `cd /home/alee/Sources/relicario.cli-tail-stream-b` so subagents don't accidentally commit to main. Non-negotiable. Today: 2026-05-09. 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: ```bash 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"}' ``` **Cycle-1 lessons baked in (read once):** - **Prefer single-line `body` content** when posting to the relay. Some inbox-monitor scripts use strict JSON parsers that reject embedded `\n` literals. Use periods between sentences and ` -- ` for stronger breaks; reserve actual newlines for STATUS UPDATEs you're printing locally only. - **If you build your own inbox-monitor in Python**: f-strings cannot contain backslash-escaped quotes inside brace expressions. Use single quotes inside: `{m.get('from')}` not `{m.get(\"from\")}`. Cycle-1 dev-a and dev-b both hit this; documenting once here. ## Required reading (in order) 1. `CLAUDE.md` — project rules 2. `docs/superpowers/coordination/2026-05-09-cli-tail-coordinator.md` — partition spec; confirms your scope is Phases 4, 5, 6 only 3. `docs/superpowers/specs/2026-05-04-cli-restructure-design.md` — Plan B (read the whole plan; execute Phases 4, 5, 6) 4. `docs/superpowers/reviews/2026-05-04-architecture-review.md` — synthesis (skim only) 5. `docs/superpowers/reviews/2026-05-04-dev-b-notes.md` — DEV-B's full notes; the relevant sections are `refresh_groups_cache` discipline, `ParamsFile` dedup, batched purge ## Execution mode Use **subagent-driven-development**. Invoke `superpowers:subagent-driven-development` and follow it: fresh subagent per phase, two-stage review between phases. **Every subagent prompt MUST start with**: ``` cd /home/alee/Sources/relicario.cli-tail-stream-b ``` …before any other instruction. ## Your scope and boundaries **In scope:** Plan B Phases 4, 5, 6. **Out of scope:** - Phase 3 (Dev-A owns) — `prompt_or_flag` + `build_*_item` compression - Phases 7, 8 (Dev-C owns) — parser migration to `relicario-core`, base32 dedup, WASM exports - Anything outside Plan B Phases 4-6. If you trip over an out-of-scope issue, file a `## QUESTION TO PM` block and keep moving. **Hard rules:** - Phase 5 must round-trip with existing on-disk `params.json` — write a fixture-string test that reads a known-current params.json and asserts the canonical struct parses it identically. On-disk format change would break existing vaults. - Do not change CLI external behaviour — all existing `crates/relicario-cli/tests/*` integration tests must pass without modification. - The `groups.cache` plaintext "failures silently swallowed" doc-comment from current `helpers.rs:90-93` must be preserved on the new `after_manifest_change` wrapper. Don't change the policy. - Do not merge your branch to main. The PM owns merges. - Do not push `--force` or run `git reset --hard`. Per `CLAUDE.md`: ask first. **Internal phase sequencing (within Stream B):** - Phase 5 (`ParamsFile`) is independent — ship first to get it out of the way, OR last for diff-locality with the session-touching Phase 4. Either is fine; pick whichever reviews more cleanly. - Phase 4 (`after_manifest_change`) before Phase 6 (`batched purge`). Phase 6's commit logic relies on the wrapper. ## Coordination protocol You are one of four terminals. The PM coordinates you with Dev-A and Dev-C. **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 with a decision worth flagging (a found-but-unexpected coupling, a trade-off taken) - When a sub-task completes (e.g. `after_manifest_change` wrapper landed; first manifest-mutation site converted; `ParamsFile` round-trip test green) - When you change direction or hit something unexpected - When you start a new phase The `Notes` field should narrate WHAT and WHY. Three sentences max. Examples of useful: "Phase 5 fixture test caught that `format_version` was previously emitted but never read; preserved the field but kept the read side tolerant"; "found one manifest-mutation site in `commands/import.rs` that did NOT call `refresh_groups_cache` historically (DEV-B notes flagged 7 sites; this is an 8th — surfacing as a question)." Print every STATUS UPDATE locally too. **At every task boundary AND every meaningful in-flight moment**: call `read_messages(for="dev-b")`, then post and print using: ``` ## STATUS UPDATE — DEV-B Time: Branch: feature/cli-tail-stream-b-session-manifest Task: Status: STARTED | IN-PROGRESS | DONE | BLOCKED | REVIEW-READY Last commit: Tests: Notes: ``` **For PM input mid-task**: ``` ## QUESTION TO PM — DEV-B Time: Context: Options: Recommended: Blocker: yes | no ``` ## Ship-it autonomy + simplify discipline The project's `.claude/settings.json` allows you to write files, run cargo/npm/bun/python3, commit, push, and open PRs without confirmation prompts. Move at speed. **Hard guardrails (the deny list blocks these — never bypass with workarounds):** 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`, no database drops. If you genuinely need one of these, surface a `## QUESTION TO PM` block. **Speed without spaghetti — required before every REVIEW-READY:** - Invoke `superpowers:simplify` on the changed code (it reviews for duplicate logic, missed reuse, gratuitous abstraction, half-finished implementations). Either accept its findings (and fix in the same commit) or surface a one-sentence rationale in the STATUS UPDATE Notes for why a flagged issue is intentional. - 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 (`CLAUDE.md` rule). Trust internal code and framework guarantees. - Default to no comments unless the WHY is non-obvious (`CLAUDE.md` rule). Don't explain WHAT well-named code already does. - Half-finished implementations are forbidden. Either ship a complete sub-task or surface a `## QUESTION TO PM` block. ## Authority within Phases 4-6 You don't need PM permission to: - Execute sub-steps per Plan B's Phases 4, 5, 6 - Make implementation decisions consistent with Plan B - Write tests, refactor your own code, fix bugs you introduce - Push commits to your feature branch You **do** escalate when: - A scope question outside Plan B Phases 4-6 - A test you can't make green after honest debugging - A discovered bug not in Plan B - Anything destructive (per `CLAUDE.md`) - Before opening the PR for review - If you find an unexpected manifest-mutation site beyond the seven DEV-B notes flagged (likely surfaces in Phase 4) ## Final steps before REVIEW-READY Run the project's full validation: ```bash cd /home/alee/Sources/relicario.cli-tail-stream-b cargo test --workspace cargo clippy --workspace cargo build -p relicario-wasm --target wasm32-unknown-unknown ``` All three must be green / clean. Then push and open the PR: ```bash git push -u origin feature/cli-tail-stream-b-session-manifest gh pr create --base main --head feature/cli-tail-stream-b-session-manifest --title "refactor(cli): session/manifest discipline (Plan B Phases 4, 5, 6)" --body "$(cat <<'EOF' ## Summary - Phase 4 — `Vault::after_manifest_change` wrapper funnels seven manifest-mutation sites; `save_manifest` made `pub(crate)` so callers can't bypass the wrapper - Phase 5 — Single canonical `ParamsFile` in `session.rs` replaces the two-definition split; on-disk JSON round-trips with existing vaults (fixture-string test) - Phase 6 — Batched purge: a 50-item `trash empty` now fires 3 git invocations instead of 150 ## Plan B Phases 4-6 Implements `docs/superpowers/specs/2026-05-04-cli-restructure-design.md` Phases 4, 5, 6. See `docs/superpowers/coordination/2026-05-09-cli-tail-coordinator.md` for cycle-2 partition. ## Test plan - [x] cargo test --workspace - [x] cargo clippy --workspace - [x] cargo build -p relicario-wasm --target wasm32-unknown-unknown - [x] params.json round-trip test against existing on-disk format - [x] `trash empty` with N items produces 1 commit (regression invariant) - [x] Existing crates/relicario-cli/tests/* pass without modification 🤖 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 `feature/cli-tail-stream-b-session-manifest`), then start Phase 4 (or Phase 5 if you prefer to ship the independent piece first — call it out in the status update).