standards/guides/adjudicate.md

# Adjudicate — debate low-priority backlog items to a verdict

*Substance file per the portability protocol. Vendor wrappers (e.g.
`adapters/claude/commands/adjudicate.md`) point here; this guide is self-contained
and written as plain prose any orchestrating agent could follow.*

You are running inside one project repo. Low-priority technical/backend items pile up on its
`ROADMAP.md` that the owner can't easily judge the necessity of — and shouldn't have to spend
expertise on, precisely *because* they're low priority. Your job is to run a grounded debate
over each eligible item and reach a verdict, so the owner ratifies decisions instead of
researching them.

**Recommend-only.** You never execute, build, or ship anything here. Your output is verdicts
and a single batch of ROADMAP edits the owner approves. The most you change is the backlog
itself.

**Autonomy is gated by blast radius, not priority.** A low-priority item can still be
dangerous (it touches data, auth, money, an external surface, or changes observable app
behavior). You may autonomously recommend *dropping* such an item, but you may never recommend
silently *doing* it — anything above the blast-radius line goes to the owner as a brief.

## Phase 1 — Orient & select (no fan-out yet)

1. Read this repo's `ROADMAP.md` and `AGENTS.md` (especially `## Current state`) for context.
2. **Inbox nudge (don't triage).** Do the session-start inbox-check: if
   `~/Projects/standards/INBOX.md` has unchecked items tagged for this repo, tell the owner
   *"N untriaged inbox items for this repo — run `/triage` first to land them on the ROADMAP,
   or proceed with just what's there."* You operate on ROADMAP only; never read raw inbox items
   into the debate — that is `/triage`'s routing job, and duplicating its rules invites drift.
3. **Select candidates.** Eligible = parked, low-priority backlog items: P2/P3 where items
   carry an explicit priority; otherwise items that read as nice-to-have / deferred.
   **Exclude:** P0/P1 or clearly-active items, anything already marked done/built, and
   `(new:…)`-style new-repo seeds. If `$ARGUMENTS` names specific items (e.g. a ROADMAP number
   or `P3`), scope to those.
4. **Confirm the set before spending agents.** Show the owner the list you intend to adjudicate
   (one line each) and let them trim or confirm. A full run is ~4 subagents per item — this gate
   controls cost and catches any item that's more important than its placement suggests.

## Phase 2 — Per item: investigate → debate → judge

For each confirmed item, run this pipeline (items may run in parallel where your tooling
allows; within an item the stages are sequential):

1. **Investigator** (read-only). Grounds the debate in reality so it isn't two models
   speculating. Reads the actual code and reports: does the problem this item describes actually
   exist, or is it already handled? What would the change touch (files, surfaces)? **Classify
   blast radius:** LOW (reversible, internal, test-covered, no observable behavior change) or
   HIGH (touches data/auth/money/an external surface, or changes observable app behavior). When
   unsure, classify HIGH.
2. **Build-advocate** and **Drop-advocate** (in parallel). Each receives the item text and the
   investigator's findings and argues one side honestly, citing the findings — not speculation:
   - *Build-advocate*: the concrete benefit, the cost or risk of leaving it undone, who or what
     it helps.
   - *Drop-advocate*: YAGNI, added complexity and maintenance, opportunity cost, whether it's
     bells-and-whistles for its own sake.
3. **Judge.** Receives the item, the investigator's findings (incl. blast radius), and both
   briefs. Decides against the rubric = `how-i-work.md` + this repo's `AGENTS.md`. **Bias to
   DROP on a tie or low confidence** — these items are already low-priority, so death is the
   default unless a clear case is made. Emits a structured verdict (next section).

## The three verdicts

- **DROP** — not worth doing. The only autonomously-applied call. (Still ratified in one batch
  by the owner per Phase 4 — "autonomous" means the owner needn't understand the tech, not that
  files change unseen.)
- **DO** — worth doing **and** blast radius LOW. Annotate the ROADMAP item with the decision and
  a short ready-to-act plan; surface it for the owner's go-ahead to schedule. You do **not**
  execute it (recommend-only).
- **ESCALATE** — worth doing **but** blast radius HIGH, **or** the judge's confidence is low,
  **or** the item is really an epic that should be split first. Produce a balanced brief: the
  build case, the drop case, the judge's lean, and why it's above the line. This is the owner's
  real judgment call — made cheap because they're ratifying reasoning, not generating it.

## Phase 3 — Report (inline, no file written)

Show the owner one report. No new tracked artifact — the ROADMAP diff and the commit message
are the durable record (same convention as `/triage`).

```
# Adjudication — <repo> — <date>
Adjudicated N of M eligible items.

## DROP (ratify to remove)
- <item> — one-line why-not + judge confidence

## DO (low blast radius — your go-ahead to schedule)
- <item> — one-line why + the ready plan

## ESCALATE (your call — balanced brief)
- <item> — build case / drop case / judge's lean / why it crosses the line
```

## Phase 4 — Approve, apply, commit

1. **One approval gate.** Wait for the owner to confirm the batch. Never edit `ROADMAP.md`
   before they approve — it's a durable file (same rule as `/triage`).
2. **Apply** the approved changes to `ROADMAP.md`: delete DROP items outright (git history is
   the record — don't leave tombstones); annotate DO items with the decision + plan; annotate
   ESCALATE items with the judge's lean so the brief isn't lost.
3. **Commit.** Present the proposed message and wait for confirmation (one approval covers
   commit + push, per `how-i-work.md`). The message records the verdicts and the why for each
   drop — that *is* the audit trail. No AI-attribution trailer.
4. **Report** what was dropped, what's queued as DO, and what's waiting on the owner as
   ESCALATE.

## Rules

- Recommend-only. Never execute, build, or ship — your single write is the ROADMAP edit, after
  approval.
- Never auto-recommend *doing* a HIGH-blast-radius item; route it to ESCALATE. When blast radius
  is unclear, treat it as HIGH.
- Ground every argument in the investigator's findings. If the investigator can't read the code
  or the item is too vague to investigate, say so and ESCALATE it rather than debating in a
  vacuum.
- Don't read raw inbox items into the debate — nudge the owner to `/triage` first. ROADMAP is
  the only input.
- Preserve the owner's judgment as the gate: propose verdicts, apply only on approval, and
  surface anything consequential rather than deciding it.
- If blocked at any point, report exactly what blocked you — never fabricate a verdict.