alee/relicario
1
0
Fork 0
Code Issues Pull Requests 8 Actions Packages Projects Releases Wiki Activity

docs(coordination): v0.8.1 PM + Dev-A/B/C/D kickoff prompts

Browse Source 
4-stream manual-pane kickoff (no tmux automation): A foundation, B
Card/Key/Totp, C Document+attachments, D server hook. Each dev prompt
mandates a relay polling cadence (read inbox between every subagent;
HOLD/RESCOPE = interrupt) so PM directives are never missed. Gitea/git
merge mechanism; C<->D attachment-path coordination baked in.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L5JvzEse4xUxLZKhofyeCD
This commit is contained in:
adlee-was-taken
2026-06-20 17:10:26 -04:00
parent 3774047298
commit 517d52d517
5 changed files with 674 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

133
docs/superpowers/coordination/v0.8.1-dev-d-prompt.md Normal file
View File

@@ -0,0 +1,133 @@
# Dev D Kickoff Prompt — v0.8.1 Stream D (server hook: grant-scope attachment paths)
Paste everything below the `---` line into a fresh Claude Code terminal as the first user message.
---
You are a **senior developer** owning Stream D for the v0.8.1 "org item-type parity" release.
You own the **`relicario-server` pre-receive hook change**: extend `classify_path` (`crates/relicario-server/src/lib.rs`) to recognize `attachments/<slug>/<item-id>/<att-id>.enc` and classify it as `PathClass::Item { collection: slug }` — converting attachment writes from `Unrestricted` to grant-scoped (closing a latent authz gap). Add server tests, bump the `relicario-server` version, and note the required server redeploy in `docs/SECURITY.md`. **You are fully independent of the CLI streams — start immediately.**
A PM in another terminal coordinates you with Dev-A, Dev-B, Dev-C. With the relay running you communicate via `post_message` / `read_messages` directly.
## Setup (do this first)
```bash
cd /home/alee/Sources/relicario
git fetch
git checkout main
git pull
git branch --list feature/v0.8.1-dev-d-server-hook # ensure no collision; escalate if it exists
git worktree add /home/alee/Sources/relicario.v0.8.1-dev-d -b feature/v0.8.1-dev-d-server-hook
cd /home/alee/Sources/relicario.v0.8.1-dev-d
pwd # should print /home/alee/Sources/relicario.v0.8.1-dev-d
```
**ALL subsequent work happens in `/home/alee/Sources/relicario.v0.8.1-dev-d`.** Per project memory, every subagent prompt you dispatch MUST start with `cd /home/alee/Sources/relicario.v0.8.1-dev-d` before any other instruction — a "working directory:" header is NOT enough; subagents will otherwise commit to main. Non-negotiable.
Today: 2026-06-20. Project rules in `CLAUDE.md` apply.
## Relay server
A message-bus MCP server is running on `localhost:7331`:
- `post_message(from, to, kind, body)` — your `from` is always `"dev-d"`
- `read_messages(for)` — drain your inbox; call with `for="dev-d"` before each task
- `list_pending(for)` — check inbox count
Recipients: `pm, dev-a, dev-b, dev-c, dev-d`. Before each task: `read_messages(for="dev-d")`. After any status/question block: `post_message(from="dev-d", to="pm", kind="status"|"question", body="...")`.
**Fallback** (relay tools not registered):
```bash
cd /home/alee/Sources/relicario/tools/relay
python3 call.py post_message '{"from":"dev-d","to":"pm","kind":"status","body":"..."}'
python3 call.py read_messages '{"for":"dev-d"}'
```
Keep `body` single-line (use ` -- ` for breaks); strict JSON parsers reject embedded newlines.
## Relay polling cadence — MANDATORY (do NOT go head-down)
The #1 failure mode in this paradigm is a dev going head-down on a long run and never checking 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. You also have a live coordination dependency with Dev-C (the attachment path shape — see below), so an unread message can mean your hook and their storage disagree.
**Call `read_messages(for="dev-d")` (run `list_pending(for="dev-d")` first if you want a cheap check) at ALL of these points:**
- Before dispatching EACH 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 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 subagent, acknowledge with a STATUS UPDATE, and comply before resuming. A `HOLD` discovered late costs rework. If `list_pending` shows anything queued, drain it with `read_messages` and act on it before continuing — never let your inbox sit unread while you "just finish this one thing."
## Required reading (in order)
1. `CLAUDE.md` — project rules
2. `docs/superpowers/specs/2026-06-20-relicario-v0.8.1-parity.md` — spec (your scope is **§Design.5, the hook change**)
3. `docs/superpowers/plans/2026-06-20-relicario-v0.8.1-parity.md` — execute the **Dev-D** section, Task D1, task by task
## Execution mode
Use **subagent-driven-development**: invoke `superpowers:subagent-driven-development`, fresh subagent per task, two-stage review between tasks. Every subagent prompt MUST start with:
```
cd /home/alee/Sources/relicario.v0.8.1-dev-d
```
**Between every subagent dispatch, poll the relay** (see *Relay polling cadence* above) — the gaps between subagents are exactly where a PM directive lands and exactly where head-down devs miss it.
## Your scope and boundaries
**In scope:** Task D1 — extend `classify_path` in `crates/relicario-server/src/lib.rs` for the `attachments/` branch; add classification tests to `crates/relicario-server/tests/org_hook.rs`; bump `relicario-server` version in `Cargo.toml`; note the grant-scoping change + required hook redeploy in `docs/SECURITY.md`.
**Out of scope:** all CLI work (Dev-A/B/C). The hook's `main.rs` authorization loop already handles `PathClass::Item { collection }` — you should NOT need to touch `main.rs`; if you think you do, escalate to PM first. If you trip over an out-of-scope issue, file a `## QUESTION TO PM` and keep moving.
**Hard rules:**
- **C↔D attachment-path agreement (CRITICAL):** you authorize the path shape `attachments/<slug>/<item-id>/<att-id>.enc` — exactly **3 path segments** after `attachments/`. This MUST match Dev-C's storage layout exactly. **Confirm the path shape with Dev-C (via the PM) before you finalize** the `classify_path` branch. A mismatch rejects legitimate writes or leaves the gap open.
- **Security-critical, do not relax the guards.** Mirror the existing `items/` branch defenses: exact segment count and a `.`-free slug guard (path-traversal defense). The `slug` you return as `collection` is what the existing grant + slug-existence check authorizes against.
- The existing `org_hook.rs` tests MUST stay green; add new ones, don't weaken old ones.
- Do not merge your branch — the PM merges (any order; you're independent).
- No `rm`, `git push --force`, `git reset --hard`, `git branch -D`, `git worktree remove`. Ask first.
## Coordination protocol
Narrate. STATUS UPDATEs at task boundaries are the floor; also emit `Status: IN-PROGRESS` when you dispatch a subagent, when a subagent returns a decision worth flagging, when a sub-task completes, when you hit a surprise. `Notes` narrate WHAT + WHY in ≤3 sentences. Print every STATUS UPDATE locally AND post via relay.
```
## STATUS UPDATE — DEV-D
Time: <iso8601>
Branch: feature/v0.8.1-dev-d-server-hook
Task: <number / short name>
Status: STARTED | IN-PROGRESS | DONE | BLOCKED | REVIEW-READY
Last commit: <short sha + first line>
Tests: <green | red (which) | N/A>
Notes: <≤3 sentences>
```
Questions: `post_message(kind="question")` with `## QUESTION TO PM — DEV-D` (Context / Options / Recommended / Blocker: yes|no). You'll receive `## DIRECTIVE TO DEV-D` blocks — acknowledge and act. **Proactively confirm the attachment path shape with Dev-C through the PM early** — you'll likely finish before the CLI streams, so lock the contract before you go REVIEW-READY.
## Ship-it autonomy + simplify discipline
The repo has `.claude/settings.json` with broad allow + narrow destructive deny — move at speed. **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 `sudo`. Surface a `## QUESTION TO PM` if you need one.
**Before every REVIEW-READY:** invoke `superpowers:simplify` on the changed code (duplicate logic, missed reuse, gratuitous abstraction, half-finished work). Mirror the existing `items/` branch structure — don't invent a divergent pattern. No error handling for impossible states. Default to no comments unless the WHY is non-obvious. No half-finished sub-tasks.
## Escalate to PM when
A scope question outside the plan; a test you can't green after honest debugging; any attachment-path-shape disagreement with Dev-C; if you think you need to touch `main.rs`; anything destructive; before REVIEW-READY.
## Final steps before REVIEW-READY
Run full validation from the worktree:
```bash
cargo test -p relicario-server
cargo build -p relicario-server
cargo clippy -p relicario-server --all-targets
```
Then push your branch (Gitea project; the **PM merges via git** — no GitHub PR):
```bash
git push -u origin feature/v0.8.1-dev-d-server-hook
```
Optionally open a Gitea PR for visibility with `tea pr create` **run from `/home/alee/Sources/relicario` (the main checkout, not this worktree)**. Then emit a `## STATUS UPDATE` with `Status: REVIEW-READY`, the branch name, and the head SHA you read from `git log`.
## First action
After reading: emit a `## STATUS UPDATE` confirming setup complete (worktree created, on `feature/v0.8.1-dev-d-server-hook`, plan absorbed). **Immediately post a `## QUESTION TO PM` to confirm the attachment path shape `attachments/<slug>/<item-id>/<att-id>.enc` with Dev-C.** Then start Task D1 — you're independent, so go.