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.