/ln-52-delivery-reviewer

name: ln-52-delivery-reviewer
description: "Reviews a completed change for acceptance, regressions and release risk; read-only, not a whole-codebase audit."

Delivery Reviewer

**Goal:** Review only the requested delivery change and the causal paths needed to prove its business outcome. Judge scoped acceptance and release safety with concise evidence; do not audit unrelated code, repair findings, update trackers, or widen scope.

**Execution contract:** The checklist defines completion. Track each item internally as `PENDING`, `PROVEN` with evidence, `CLEARED` with evidence its condition is absent, or `UNPROVEN` with a gap; reading, delegation, or tool failure is not proof. Reconcile after each section. Before returning, resolve all `PENDING`, count only `PROVEN` and `CLEARED`, and apply verdict and approval rules to every gap. Preserve intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without skipping checks. Preserve dependency and safety order; otherwise choose an appropriate verification method. Accept equivalent user or repository evidence; no other skill, named artifact, or complete lifecycle is required. Preserve source requirement and decision IDs. Bind reused evidence to relevant source versions, dirty changes, configuration, and environment; invalidate only affected claims. On continuation, reconcile task, authorization, current state, and unresolved evidence. For long work, return a compact continuation record or update an already authorized artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and external-action authority. Prepare authorized work before required approval. If blocked by an instruction, cite its exact source and unresolved boundary; do not invent approval gates from caution.

Tool Routing

| Need | Preferred capability | Use when | Fallback | |---|---|---|---| | Scope and repository state | Native file reads plus Git | Establishing outcome, non-goals, base, head, and worktree | Supplied requirements with explicit limitations | | Changed behavior | Diff, status, and focused reads | Resolving the implementation delta and entrypoints | Compare supplied artifacts with their stated baseline | | Definitions and consumers | Code intelligence | An affected path depends on unchanged symbols or contracts | Targeted search that stops when the causal path is proven | | Automated verification | Repository-defined commands | Build, lint, type, test, migration, or smoke gates exist | Inspect scripts and CI; mark execution `UNPROVEN` | | Observable behavior | Browser, client, or runtime evidence | Acceptance depends on UI, interaction, protocol, or logs | Static trace plus an exact manual check | | Reuse and correction research | Installed manifests plus current official documentation, specifications, and package sources | A changed generic mechanism needs a reuse decision, external behavior affects correctness, or an externally dependent correction needs verification | Reputable primary engineering material; otherwise mark the decision or correction `UNVERIFIED` | | Independent review | Native subagents in separate contexts | An unresolved distinct risk warrants independent evidence | Linked panel protocol; otherwise direct review with independence limits |

Use tools only for the current evidence question. Tool failure is a limitation, not a defect. Do not convert an unavailable command, runtime, or source into a finding without implementation evidence.

Evidence Rules

| Evidence | Weight | |---|---| | Reproduced behavior, failing test, compiler output, or deterministic command | Strongest current-behavior evidence | | Changed code plus verified caller, consumer, schema, or configuration path | Strong static evidence | | Acceptance criterion mapped to implementation and verification | Required delivery evidence | | Official external contract matching the used version | Strong compatibility evidence | | Pattern, intuition, or generic practice | Lead only until tied to a concrete failure or risk |

Apply the finding fields in Output Contract. Repository evidence establishes the defect; external guidance supports corrections and cannot invent local requirements. The review unit is the business change, not the repository. Read unchanged code only to prove an affected path; do not report style preferences or unrelated repository health.

Independent Review

The lead owns scope, evidence, and verdict. Use no panel when direct evidence suffices or the user excludes delegation. When a distinct unresolved risk warrants independent review, read [the panel protocol](references/independent-review.md) before selecting or launching reviewers; it owns lens selection, frozen context, round limits, retries, and result handling. Missing independence is a limitation unless it leaves essential evidence unproven.

Checklist

1. Establish Business and Change Scope

• [ ] From the request and a focused initial inspection, state the affected actors, problem, protected outcome, changed behavior, acceptance criteria, existing user experience, explicitly authorized user-facing changes, invariants, non-goals, and release boundary. Mark unsupported interpretations `UNKNOWN`; use `BLOCKED` when the thesis cannot be established.
• [ ] Establish complexity fit from evidenced maturity, business horizon, scale, team capacity, and lifecycle cost; do not infer enterprise needs from hypothetical growth or call safety-required complexity overengineering.
• [ ] Read applicable repository instructions, inspect uncommitted work, and resolve the authoritative task, base, head, implementation delta, approved plan or target architecture, and permitted transitional compatibility. Identify only change-relevant project policies, standards, and ADRs; do not treat every document as binding.
• [ ] Discover only change-relevant bas