chore: consolidate /dispatch to global command, add Commands section to CLAUDE.md

- Remove project-local /dispatch (now global at ~/.claude/commands/dispatch.md)
- Add Commands section to CLAUDE.md documenting /review → /dispatch cycle
- Note review label as single source of truth (not title prefixes or handoff files)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.claude/commands/dispatch.md

@@ -1,100 +0,0 @@
-# Dispatch Review Findings — /dispatch
-
-Package review findings into Gitea issues and a retrievable handoff for the target project. Run this after `/review` or after any conversation in adversarial-reviewer that produced actionable findings.
-
-## Arguments
-
-$ARGUMENTS is optional. It can be:
-- A project name: `server-management`, `music-management`, `ersatztv`, `wiim-now-playing`, `media-management`, `homelab-docs`
-- Empty — deduce from conversation context (which project was reviewed, which project has findings)
-
-## Steps
-
-### 1. Identify the Target Project
-
-If no argument given, determine the target from conversation context:
-- Which project was just reviewed?
-- Which project has the open findings or action items?
-- If findings span multiple projects, ask which to dispatch first (run `/dispatch` once per target)
-
-Map project name to Gitea repo owner/name and local path:
-- `server-management` → `timothy/server-management`, `~/server-management`
-- `music-management` → `timothy/music-management`, `~/music-management`
-- `ersatztv` → `timothy/ersatztv`, `~/ersatztv`
-- `wiim-now-playing` → `timothy/wiim-now-playing`, `~/wiim-now-playing`
-- `media-management` → `timothy/media-management`, `~/media-management`
-- `homelab-docs` → `timothy/homelab-docs`, `~/homelab-docs`
-
-### 2. Collect Findings
-
-Gather all actionable findings from the current conversation:
-- Review findings (from `/review` or ad-hoc discussion)
-- Bug reports, feature requests, or operational issues identified
-- Cross-project requests (e.g., "needs an NFS mount" → server-management)
-
-For each finding, determine:
-- Title (concise, imperative)
-- Body (what's wrong, why it matters, what to do)
-- Severity/priority
-- Whether it needs `[PLAN-MODE]` tag
-
-### 3. File Gitea Issues
-
-For each finding that doesn't already have an issue:
-- Create an issue in the target repo via `mcp__gitea__create_issue`
-- Note the issue number
-
-Skip findings that already have open issues — just reference the existing issue number.
-
-### 4. Create Dispatch Handoff
-
-Write (or overwrite) a handoff file at:
-`~/.claude/projects/-Users-timothy-adversarial-reviewer/memory/handoff_dispatch_[project].md`
-
-Use this format:
-
-```markdown
----
-name: Dispatch to [project]
-description: Review findings dispatched to [project] on [date]
-type: project
----
-
-# Dispatch to [project] — [date]
-
-## Source
-adversarial-reviewer — [brief context: what review triggered this, conversation topic]
-
-## Issues Filed
-- [repo]#[N]: [title] [PLAN-MODE if tagged]
-- [repo]#[N]: [title]
-
-## Priority Order
-1. [issue ref] — [why this is first, what it unblocks]
-2. [issue ref] — [context]
-
-## Context the Implementer Needs
-- [key context that isn't in the issue body — operational state, dependencies, gotchas]
-- [vault doc references if relevant: "see Docker/Music Pipeline.md#beets for current config"]
-
-## Acceptance Criteria
-- [what "done" looks like for this dispatch — all issues closed? specific state achieved?]
-```
-
-### 5. Update MEMORY.md
-
-If this is a new handoff file, add a pointer to it in adversarial-reviewer's MEMORY.md.
-
-### 6. Close Review Request (if applicable)
-
-If this dispatch originated from a review request issue (filed by `/review` from another project), close that adversarial-reviewer issue with a comment linking to the dispatched issues.
-
-### 7. Output Resume Instruction
-
-Tell the user:
-
-```
-Dispatched [N] findings to [project] ([N] new issues, [N] existing).
-
-Run /resume dispatch in ~/[project] to pick up this work.
-```

CLAUDE.md

@@ -50,11 +50,21 @@ Given completed work (commits, changed files, SSH state), find:
 - **Side effects**: Were there unintended changes to other services?
 - **Fragility**: Will this break on reboot? On Docker restart? On network blip?
 
+## Commands
+
+- **`/review`** — From adversarial-reviewer: conduct a review (specific target or scan all projects). From any other project: flag something for adversarial review.
+- **`/dispatch`** — From adversarial-reviewer: file review findings as Gitea issues with `review` label. From any other project: pick up and work through open `review`-labeled issues.
+- **`/done`** — Mark a task complete (works in any project).
+
+The full cycle: `/review` (find problems) → `/dispatch` (file issues) → `/dispatch` in auditee project (work issues) → `/review` (verify fixes).
+
 ## Workflow
 
 ### Reviewer (this project)
 Every review session — whether a plan review, post-implementation audit, or ongoing findings — **ends with an implementer prompt**. The prompt collects all open/new findings into a single actionable block with priority order and concrete steps. Don't make the implementer hunt across issues.
 
+Review findings are tracked via the `review` label on Gitea (not title prefixes, not handoff files). This is the single source of truth for dispatch status.
+
 ### Implementer contract
 Implementers are expected to:
 1. **Comment on issues** as they work — note what they found, what approach they're taking, any deviations from the suggested fix