feat(unic-archon-dlc): the review angles become a Method of ours, harvested from unic-pr-review and rewritten stack-agnostic

Decided with the maintainer in a /grill-with-docs session on 2026-08-28, against
WI 42991. This issue carries the decision and
its evidence; it does not point at a conversation.

The problem

/pr-review reviews from two angles. unic-dlc-pr-review.yaml:211 hosts the code-review Method
and its own two-axis fan-out, Standards and Spec. Two axes needed six iterations to reach 40
findings on PR 5807, and the documentation-staleness class only surfaced at iteration 6 — four
criticals on a diff that had already been reviewed five times. The pattern is a new class per pass, not
diminishing returns.

The sibling plugin unic-pr-review gets that spread in one pass, from six specialised agents:
code-reviewer, code-simplifier, comment-analyzer, pr-test-analyzer, silent-failure-hunter,
type-design-analyzer.

Why the obvious fix is blocked

Copying those agents into the Box collides with two accepted decisions of this plugin's own.

• ADR-0026's title: /pr-review "harvests unic-pr-review's learnings, not its code".
• ADR-0026's 2026-08-04 amendment: seven hand-written aspect nodes already existed and were
  deliberately collapsed into one node by #281. #281's stated reason was maintenance ownership —
  "ground the plugin currently maintains itself and upstream now maintains."
• ADR-0030: procedure belongs to a Method, never to the Harness. Aspect prompts in the Box is the
  Harness owning procedure, which is the drift ADR-0030 was written to stop.

A configuration-only route was considered and rejected in the session: passing angle names and no
briefs leaves a general-purpose sub-agent with nothing to review against. The brief is the review.

The decision

Write a Method of our own and read it beside code-review. The angle briefs live in a Method,
because they are procedure and a Method is procedure's home. The Harness stays clean.

Harvest unic-pr-review's six agents as a starting draft, then rewrite each brief to be
stack-agnostic. Those agents assume Azure DevOps and TypeScript; the Harness serves any Consumer and
must assume neither. A rewritten draft is a harvested learning, which ADR-0026 permits. A copied file is
code, which it forbids.

Add one angle neither list has: documentation staleness. That class produced the iteration-6
criticals — a document claiming coverage the code had falsified.

Acceptance criteria

1. A Method exists in the Bundle holding one brief per review angle, read by the Box at a literal
   repo-relative path the way code-review is read.
2. Each brief states its angle without naming a tracker, a language or a framework. A reader can apply it
   to a Consumer that uses neither Azure DevOps nor TypeScript.
3. A documentation-staleness angle is among them, and its brief says what makes a document stale against
   a diff.
4. The manifest records that this Method is ours, not upstream's, so a reader does not assume every
   Method under .archon/methods/ came from Matt. ADR-0026 is amended to say the same.
5. The review node no longer names seven aspects as a forbidden state. Its current text says "do NOT
   silently restructure the review into something else (not one axis, not seven aspects)" — change it in
   the same commit, or the Box contradicts itself.
6. No brief is copied verbatim from apps/claude-code/unic-pr-review/agents/. A reviewer can diff the two
   and see rewriting, not transcription.

Notes for whoever takes it

Mechanically this is cheap and needs no new machinery. The Method already instructs the Box to send one
message with two Agent calls, general-purpose for both, pasting each brief in full because the
sub-agent reads nothing else. More angles is more calls with more briefs.

One old objection is weaker than #281 assumed: ADR-0031's 2026-08-20 amendment deleted the automated
upstream tripwire, so a Bundle upgrade is already a hand diff against the upstream tag. "Upstream
maintains it" is less true today than when the collapse was chosen.

Reference any new ADR by slug, never by number — in-flight branches claim numbers.

---

Open questions — this issue does not decide these, and an implementer must not decide them alone

Added 2026-08-28 after reading the criteria above as one set. Each is a hole where a defensible-sounding
choice would produce a green pull request that implements the wrong thing.

1. Does code-review still run, or does this Method replace it? The decision above says "read it
   beside code-review" and never resolves this. Beside means nine angles, with Standards and Spec
   overlapping the six harvested ones. Replace drops the twelve-item Fowler smell baseline and the
   intent-grounded Spec axis — and the Spec axis is what renders the Intent Check section, which is how
   acceptance-criterion coverage survived the collapse of the old intent-check node. Neither reading is
   obviously wrong, which is exactly the problem.
2. How many angles, and which? The prose names unic-pr-review's six plus documentation staleness.
   Criterion 1 says only "one brief per review angle". An implementer could ship three and satisfy it.
   Fix the list or say plainly that the list is the implementer's to propose and the maintainer's to
   approve.
3. What is the Method called, and where exactly does it live? Criterion 1 says "a literal
   repo-relative path the way code-review is read", which is .archon/methods/<name>/SKILL.md. The
   <name> is undecided.
4. What installs it into a Consumer? A Method read by path needs something to put it there, and
   /unic-archon-dlc:setup is what installs the Bundle today. No criterion above mentions setup. A
   Method the Box reads and nothing installs is a reader with no writer.
5. Does the Agent-tool constraint survive seven calls? The review node already refuses to run when
   the Agent tool is unavailable in an Archon prompt node. Whether seven parallel calls behave the way
   two do in that container is unmeasured. Measure it before the briefs are written, not after.

The tension in this issue's own cure, stated rather than buried

The problem above is that the plugin drifted by maintaining its own procedure prose, and #281 deleted
seven hand-written aspect prompts to stop that. This issue's cure is to write our own procedure prose
again. Moving it from the Box into a Method makes it architecturally correct under ADR-0030, and it does
not make it free: the briefs become ours to maintain, and that is the cost #281 was avoiding.

The trade is accepted deliberately, on two grounds. Breadth was measurably lost — six iterations to reach
40 findings, with a whole class arriving only at iteration 6. And "upstream maintains it" is weaker than
#281 assumed, because ADR-0031's 2026-08-20 amendment deleted the automated upstream tripwire, so a Bundle
upgrade is already a hand diff against the upstream tag.

Anyone reopening this decision should argue against those two grounds, not against the shape.

Start by resolving the five open questions with the maintainer, then inspect unic-dlc-pr-review.yaml:211, the existing code-review Method, the Bundle manifest, and ADR-0026. Check how /unic-archon-dlc:setup installs Methods and measure the Agent-tool behavior before drafting. Done means an approved Method path, rewritten angle briefs, manifest and ADR updates, and consistent review-node wording.