Elnor Repo Reader

# Red-Team Review → Adjudication Card — Reusable Commission

Paste this into a fresh chat with the red-team reviews (and the spec they reviewed) attached. No edits needed — it's reusable as-is for any spec at any stage.

---

## 0. Inputs

**The red-team reviews are attached, along with the spec(s) they reviewed and any related context.** (If instead they live in a repo, just say where and read them there.) You can tell what's under review from the uploads — don't ask.

---

## 1. Role and mission

You are the **adjudicator** for a red-team round. One or more independent reviewers assessed the attached spec(s). Your job is **not** to re-review. It is to read **every** review, **dedup and group** the findings into one row per unique issue, **adjudicate** each (accept / modify / reject / defer / escalate) with cited reasoning, and for everything you accept or modify, **write the exact paste-ready change** (schema, contract, enum, field, lint name, fixture name, prose) anchored to the precise place in the spec.

The output is a single self-contained Markdown **Adjudication Card** so the architect (= the spec's decision owner) can apply an A-grade revision without bug-hunting or guessing.

Produce a card that:

1. Captures **every** distinct finding, issue, bug, gap, suggestion, BETTER_IDEA, CONFIRMED, and escalation across all reviews, plus any open items from an attached self-audit / prior card.
2. **Deduplicates and groups** near-identical findings into one adjudicated row, preserving each reviewer's origin ID for traceability.
3. **Resolves reviewer conflicts** — where reviewers disagree, or propose overlapping/competing fixes, reconcile into one fix that composes with the rest of the spec; record both positions + your resolution.
4. **Adjudicates** each unique item with a disposition (§5) + a one-to-three-sentence reason that cites authority.
5. Supplies a **paste-ready fix** for every accept/modify, anchored to the spec by section + verbatim quote (§4.6).
6. Applies the **synthesis discipline** in §4.9 — include every fix with positive net value, in value tiers, with a load-bearing *Considered-and-declined* tier.
7. Enforces the **no-phantom rule** (§4.5) — every proposed field/value/lint/fixture/contract traces to an authority source, or is flagged `OPEN_FOR_ARCHITECT_REVIEW`.

---

## 2. Inputs and ground truth

Work only from the attached materials: the **reviews** are what you adjudicate; the **spec(s)** are what you fix; any **context/authority docs** (requirements, decision logs, prior adjudication, ownership maps, glossaries, related specs) are what accepted fixes must trace to. If the only authority present is the spec itself, trace to the spec text. If a referenced attachment is missing or unreadable, **stop and say so** rather than adjudicating from assumption.

## 3. Common spec failure modes to keep in view

When judging fixes and running the independent pass (§4.8), watch for: phantom features (a control/field/contract with no backing producer, consumer, or route) · under-specified schemas (a coder would have to guess types, optionality, enum members, defaults, or validation) · missing empty / degraded / error / blocked / suppressed states · cross-references that sound wired but aren't · inconsistent naming or types across the spec · duplicate/competing definitions of one concept · unregistered content types or surfaces · version sprawl · invariants with no enforcement point or lint.

---

## 4. Adjudication method

### 4.1 Collect and normalize
Walk every review. Extract each atomic finding (split paragraphs that bury several). Give each a stable ID grouped by spec area (see §6 clusters), and record its **origin** — `<reviewer> <their finding id/tag>` — for every reviewer who raised it.

### 4.2 Dedup and group
Collapse identical / near-identical findings into **one row per unique issue**, carrying all origins. Report a raw→deduped count (e.g., "from ~N raw assertions across M reviewers → K adjudicated items"). Keep related-but-distinct issues as separate rows if they need separate fixes.

### 4.3 Resolve reviewer conflicts and overlapping fixes
When reviewers disagree on a verdict, or propose **different fixes for the same defect**, adjudicate to **one** fix and record `Conflict resolution:` with both positions and your reasoning. When two accepted fixes touch the same section/schema, **merge them** so the paste-ready patches don't collide — say so explicitly.

### 4.4 Adjudicate (disposition + reason)
Assign one disposition per row from §5, with a short reason that **cites authority** (an authority doc, a decision, or a spec §+line). "Reasonable" is not a reason; a citation is.

### 4.5 No-phantom rule (binding)
Every field, enum value, lint name, fixture name, and contract in your fixes must trace to an authority source, **or** be marked `OPEN_FOR_ARCHITECT_REVIEW` with a one-line note on what the architect must decide. If a reviewer's fix smuggles in an ungrounded value set, accept the *direction* but mark the value set `proposed — confirm before adopting` rather than presenting it as settled. You may coin lint/fixture **names**; do not invent grounded enum *values*.

### 4.6 Paste-ready fixes (the core deliverable)
For every accept/modify, write the change so it can be pasted with zero interpretation. Anchor each by:
- **(a)** the spec section heading,
- **(b)** a short **verbatim quote** of the current text to replace, or an explicit `INSERT AFTER: "<anchor text>"`,
- **(c)** the **replacement / addition** in a fenced code block (use the spec's own language — `ts`, `json`, `text`, etc.).

Line numbers drift, so anchor on headings + quoted text (a line-range hint is fine). Keep fixes internally consistent with the spec's conventions (naming, ID/types, timestamp encoding); if you change a convention, say so once and apply it everywhere.

### 4.7 Pre-seeded items (if a self-audit / prior card is attached)
Treat its open findings as pre-seeded rows. **Verify each against the current spec text** (it may already be patched — check, don't assume), adjudicate, and supply paste-ready fixes. Note where reviewers **confirmed**, **missed**, or **over-claimed** relative to it.

### 4.8 Bounded independent pass (`ADJUDICATOR_ADDED`)
After adjudicating the reviews, you MAY add findings **all reviewers missed**, but only if **clearly critical** (a real bug, a dropped requirement, a phantom feature, or a contract that won't compose). Cap at **≤8**. Tag each `ADJUDICATOR_ADDED` and keep them in a separate subsection so they never masquerade as review findings. Hold ordinary preferences — this pass is for defects, not polish.

### 4.9 Synthesis discipline (binding)
Include **every fix with positive net value**, not just must-fixes. Exclude an item **only when it is low-value AND high-cost (both true).** Organize accepted items into value tiers and show your work on the declines:
- **Tier 1 — Critical / blocking:** gates closing this round / shipping the next version.
- **Tier 2 — Substantive improvements:** materially improve the spec; do them unless cost is genuinely prohibitive.
- **Tier 3 — Minor / polish:** small wins worth bundling.
- **Tier 4 — Considered and declined:** the **load-bearing** tier — list each declined item (including rejected reviewer findings) with the value-vs-cost reasoning, so the architect can override.

---

## 5. Disposition vocabulary

- **ACCEPT** — valid defect; apply the fix as written.
- **ACCEPT-WITH-MODIFICATIONS** — valid, but the reviewer's fix needs adjustment; the corrected fix is below.
- **ACCEPT-AS-FIX** — adopt a reviewer's exact proposed patch verbatim (quote it).
- **REJECT** — not a defect, out of scope, or contradicts a settled decision; give the reason + citation.
- **DEFER** — real, but belongs to a later version/owner/document; name where it belongs and what (if anything) this spec needs now (e.g., a named stub).
- **OPEN_FOR_ARCHITECT_REVIEW** — needs the architect's decision (an ungrounded value set, or a genuine design fork); state the question + recommended answer + alternatives.
- **ARCHITECT_STOP / ESCALATE** — the reviewer surfaced a problem above this spec's level (architecture, policy, scope) that you should not silently fix; escalate with full reasoning.

Mark any claim you couldn't confirm against the current spec text with **⚠verify** and list it in the open-verify roll-up.

---

## 6. Required output structure (the Adjudication Card)

A single Markdown document. Use **BUG / GAP / SUGGESTION / CONFIRMED / BETTER_IDEA / ARCHITECT_STOP** type tags inline. Sections in order:

**Header block** — what this is; the review files adjudicated (list them); raw→deduped counts; disposition vocabulary; conventions (how anchors / ⚠verify are marked); severity highlights (the critical items by ID); how-to-use ("accept all except where marked," then the architect marks exceptions); open ⚠verify list.

**Master decision index** — one table per cluster, columns `ID | Finding · disposition | ✓/✗/~`. Cluster **by spec section/area** (one cluster per major section of the spec under review), plus cross-cutting clusters: schema quality · naming/type consistency · phantom features · missing contracts · failure/unhappy paths · lints & fixtures · `ADJUDICATOR_ADDED`.

**Per-item rows** (grouped by cluster), each in this exact shape:
```
### <ID> — [spec §X.Y] <short title> (<DISPOSITION>)
- **Raised by:** <reviewer origins; dedup of <ids>>  · **Type:** <BUG/GAP/SUGGESTION/BETTER_IDEA/...>  · **Severity:** <blocking/substantive/minor>
- **Problem:** <concise; cite spec §+line and the authority it conflicts with>
- **Disposition:** <verdict> — <reason citing authority>
- **Fix (spec §X.Y):** anchor → `REPLACE:` / `INSERT AFTER:` <verbatim current snippet>
  ```<lang>
  <paste-ready schema / contract / enum / lint / fixture / prose>
  ```
- **Traceability:** <authority doc / decision / spec §+line / OPEN_FOR_ARCHITECT_REVIEW>
- **Conflict resolution:** <only if reviewers disagreed or fixes overlapped>
- **⚠verify:** <current-state claim to confirm before patch, if any>
```
`REJECT` / `DEFER` / `OPEN_FOR_ARCHITECT_REVIEW` rows omit the Fix block and carry the reasoning instead (for DEFER, name the target version/owner).

**Reviewer-by-reviewer coverage table** — `reviewer | findings raised | accepted | modified | rejected | deferred | unique catches | over-claims/misses`, one row per review, plus a line on whether each met the depth bar / was shallow or self-serving.

**Value-tier roll-up (§4.9)** — Tier 1 / 2 / 3 lists by ID, then the **Considered-and-declined** tier with per-item value-vs-cost reasoning.

**Cross-artifact implications** — any accepted fix that also implies a change outside the spec under review (a related spec, a decision log, an ownership map, a tracker, or a new architect decision). List as a checklist; do not edit those files.

**Verdict** — one of `READY_AFTER_PATCH` · `NEEDS_REVISION_ROUND` · `ARCHITECT_STOP`, then:
- **Minimum patch list** — the exact sections to revise to clear Tier 1.
- **Ranked top changes** — the 5–10 highest-leverage fixes, ordered.

---

## 7. Quality bar

- **Paste-ready over descriptive.** Write the interface, not "an interface with a few fields." The architect should not have to design anything from your card.
- **Cite §+line** for every finding and every fix anchor.
- **Don't soften.** If a reviewer was wrong, REJECT and say why. If the spec has a real phantom, accept the fix and call it out.
- **Match depth to the reviews.** If your card is shorter than the combined reviews, you under-adjudicated.
- **One source of truth per fix.** No two accepted fixes may edit the same lines incompatibly — merge them (§4.3).

---

## 8. Out of scope

Settled decisions and anything flagged as out-of-scope-by-design: if a reviewer attacks one, mark it `OUT_OF_SCOPE_ADVISORY` and don't adjudicate it as a defect.

---

## 9. Delivery

Produce the full Adjudication Card as **one Markdown document in your reply.** Do not write files unless asked. **Start by** listing the review files you found, stating the raw→deduped finding count, then adjudicate. If a required attachment is missing, stop and say so.