ln-12-delivery-reviewer

name	ln-12-delivery-reviewer
description	Reviews a completed scoped change and its affected runtime and contract paths. Use to find change-caused defects and verify readiness; not for codebase audit, implementation, or repair.

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: Treat the ordered checkbox workflow below as this skill's Definition of Done. Before reviewing, create an internal coverage ledger with one PENDING row per checkbox, using the heading's ID range in printed order. Change a row only to PROVEN with a concrete evidence reference, CLEARED with evidence that its conditional trigger is absent, or UNPROVEN; reading, mentioning, delegating, skipping, or tool failure is not proof. At the end of each numbered section, reconcile its ledger rows and resolve every PENDING. Before verdict, run exactly one closure pass over the ledger, evidence, and draft: challenge unsupported PROVEN or CLEARED states, surface every accepted finding, and align matrices, limitations, and verdict. Correct the report or downgrade the verdict; do not rescan the repository, restart the review, or launch another subagent round. Before returning, derive the count from the ledger with only PROVEN and CLEARED rows complete, apply this skill's verdict rules to every UNPROVEN, allow no PENDING, and prepend Checklist: X/Y complete
Incomplete: None | ID — reason; outcome impact; exact next action; list every UNPROVEN row.

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 a finding needs its practice reference	Reputable primary engineering material; otherwise mark the decision or correction UNVERIFIED
Independent review	Native subagents in separate contexts	One scope-scaled initial review; at most one selective follow-up	Use the smallest panel that can change the verdict within the two-round budget; report reduced confidence or BLOCKED only when missing selected independence leaves required evidence unproven

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

Every finding must name the affected business behavior, change-causal path, violated contract, evidence, impact, and smallest credible correction. Repository evidence proves the defect; external practice sources justify the correction mechanism and cannot invent a local requirement. 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 Panel

Use Six Thinking Hats as evidence lenses, not personalities. The Blue lead scopes the review, selects agents, verifies claims, resolves conflicts, and issues the verdict.

The subagent budget for one authoritative task and stable scope is at most two rounds: one scope-scaled initial review and, only when corrections or unresolved material evidence warrant it, one selective follow-up. Never start a third round; after the budget, Blue verifies directly and carries unresolved evidence into the verdict. Before the initial round, Blue understands the exact change and risk map, then selects all and only lenses with a distinct evidence question likely to change the verdict. Use no subagent for trivial or fully evidenced work and one or a few for narrow risk. In the worst case, a full panel may exceed four subagents: include every applicable non-Blue hat plus every distinct risk-triggered specialist; full means complete for this change, not every table row. Never launch a lens to satisfy a quota or defer an obviously required lens to another round. Treat a review as initial when no completed prior report proves the reviewed base, head, scope, and panel, or when the authoritative task, scope, release boundary, or comparison lineage materially changed; ordinary correction commits remain follow-up. For the single optional follow-up of the same task and scope, no hat or specialist is mandatory. Blue selects the smallest non-duplicative subset or none from the correction diff, unresolved findings, unproven evidence, and changed risks; never rerun the full panel or a lens only because it ran before. Apply the same risk-based freedom to non-code delivery and record Independent review panel: None when no lens adds value.

Hat	Question
White — facts	What changed, which outcome and paths are affected, and what scoped evidence is missing?
Red — human response	What will surprise or mislead a user, developer, reviewer, or operator? Treat intuition as a hypothesis.
Black — caution	How can the change regress, corrupt state, breach trust, or fail at edges and partial failure?
Yellow — value	Which intended value, compatibility, and sound tradeoffs must be preserved; which concerns are false positives?
Green — surgical simplicity	AI slop is prohibited. Is this the smallest sufficient diff and simplest efficient algorithm for the evidenced need without sacrificing safety, clarity, testability, or operability?

Specialist	Trigger	Focus
Security and privacy	Trust boundaries, untrusted input, secrets, sensitive data, destructive action	Guards, isolation, recovery, and sensitive-data flow
Data and concurrency	Schemas, transactions, queues, caches, events, async work, locks	Atomicity, races, ordering, duplicates, wiring, and orphan channels
API and compatibility	Public interfaces, protocols, serialization, configuration, mixed versions	Producers, consumers, removals, and supported compatibility
Architecture and migration	Approved design, replacement, refactor, cutover, or deprecation	Plan traceability, owning boundary, root-cause resolution, target completeness, old paths, and unmigrated callers
Tests and oracles	Changed tests, test strategy, or material behavior needing oracle review	Material business risks, trustworthy oracles, E2E-first coverage, and removal or consolidation of low-value tests
Performance and reliability	Hot paths, I/O, retries, timeouts, load, resource ownership	Amplification, measurement, leaks, storms, and degradation
UI and accessibility	A user-facing surface is changed or causally reached, even when UX change is not requested	Existing-experience preservation, stable selectors, keyboard, focus, names, motion, copy, and rendered behavior
Operations and release	Deployment, configuration, observability, rollback, recovery	Safe rollout, useful signals, and recovery steps

Every specialist is optional in both rounds. Select only the smallest set justified by impact, likelihood, rollback difficulty, and missing evidence; avoid duplicate questions and record selection, omission, or merge reasons.

Give each subagent the same frozen packet: authoritative task, required plan items, business thesis, acceptance criteria, user-experience baseline and authorized changes, maturity evidence, base and head, changed/supporting/excluded scope, non-goals, approved approach, repository instructions, risk class, and allowed commands. Add exactly one lens, read-only and scope boundaries, and the result schema. Do not include provisional or sibling findings.

Run each round in parallel or bounded blind batches within host limits; batches remain one analytical round and never receive sibling outputs. Allow read, search, code intelligence, official-source research, and non-mutating verification; forbid tracked edits, commits, pushes, deployments, external writes, and nested subagents. Retry a technically failed selected lens once only when a concrete cause changes, within the same round and question. Wait for all selected lenses and resolve material conflicts through direct evidence; never add a verifier round.

Each subagent returns coverage, candidate findings with change-causal evidence and smallest correction, rejected hypotheses that resolve material ambiguity, and open questions. No findings is valid; never manufacture comments to justify a lens.

Checklist

1. Establish Business and Change Scope (SCOPE-1 through SCOPE-8)

• Before reading implementation detail, 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 baseline, current-state, target-design, policy, decision, diagram, and migration artifacts by repository convention. Record authority, owner, status, freshness, and supersession, and keep one policy and decision ledger of applicable sources and implementation evidence for compliance, explicit approved deviation, or an unresolved gap.
• Map changed, causally supporting, and explicitly excluded surfaces. Read outside the diff only to trace affected behavior; do not hunt unrelated code for findings.
• Classify change-triggered risk from trust, money, destructive action, migration, public contracts, concurrency, distributed coordination, and rollback difficulty; define acceptance evidence before implementation review.
• Classify the pass as initial, selective follow-up, or Blue-only from a completed prior report and stable task, scope, and comparison lineage. Freeze the thesis and scope, select only verdict-relevant lenses within the two-round budget, and record the round, selection rationale, and omissions while keeping preliminary conclusions private.
• Keep the review read-only. Permit only host-approved caches or build artifacts; do not edit tracked files, create tasks, commit, push, deploy, or repair findings.

2. Trace Requirements into Implementation (TRACE-1 through TRACE-9)

• Enumerate every authoritative task requirement and acceptance criterion, plus every required approved-plan item. Map each to concrete implementation and independent behavioral evidence; mark task and plan items COMPLETE, DEVIATED, OMITTED, or UNPROVEN and acceptance PASS, FAIL, or UNPROVEN. Author claims, checked boxes, commits, and code presence are not completion evidence.
• Inspect changed files and only the unchanged definitions, consumers, interfaces, tests, migrations, and registration needed to prove an affected path.
• Verify the change serves the protected outcome, including first meaningful use, material failure, recovery, and repetition where relevant.
• Verify each required plan item was implemented and works in its intended runtime path. Treat unexplained omissions as unmet; accept DEVIATED only when explicit evidence proves the alternative fully preserves the task, protected outcome, constraints, and acceptance. Distinguish justified deviation from stale or proposed documentation.
• Compare the user-observable baseline with the delivery. Existing screens, copy, styles, navigation, interaction order, focus, accessibility, and user scenarios may change only when a specific task requirement authorizes that change; otherwise treat any delta as a regression. New screens, copy, controls, or additional scenarios may be accepted as additive surfaces when existing elements and paths remain unchanged, but list each explicitly with its trigger, rationale, and evidence.
• Trace each critical scenario from actor trigger through entrypoint, runtime wiring, usage context, and observable outcome.
• Confirm new components, routes, commands, handlers, jobs, events, and configuration are registered and discoverable at runtime.
• Within affected behavior, inspect applicable boundaries, collections, state transitions, duplicates, ordering, numeric behavior, empty and maximum inputs, errors, retries, idempotency, cancellation, timeouts, rollback, and cleanup.
• Within affected async paths, inspect shared state, transactions, races, lock ordering, and blocking work.

3. Review Safety, Contracts, and Simplicity (DESIGN-1 through DESIGN-11)

• Within affected paths, inspect applicable authentication, authorization, ownership, validation, injection, secrets, sensitive data, logging, and destructive-operation guards.
• For changed destructive behavior, require recovery, rollback, blast-radius, environment or authorization, and preview or dry-run evidence; justify infeasible controls.
• Verify changed API, event, schema, configuration, serialization, and storage producers and consumers, including names, payloads, registration, ordering, and compatibility. For changed semantic values and closed sets--such as states, roles, permissions, event names, error codes, configuration keys, feature identifiers, limits, timeouts, and routing keys--require one authoritative owner shared by every in-scope producer and consumer through the repository-standard mechanism (for example a typed union, enum, constant set, value object, schema, typed configuration, or generated contract). Accept a harmless one-off local literal when it creates no duplication, invalid-state, or drift risk.
• Verify migrations, backfills, defaults, indexes, deployment ordering, and mixed-version behavior when persisted or distributed state changes.
• Check ownership and cleanup of files, streams, sessions, connections, processes, subscriptions, and temporary artifacts on success and failure.
• Inspect only architecture and policy boundaries crossed or changed. Verify that responsibility, dependency direction, contracts, state, lifecycle, and failure ownership remain coherent with the approved architecture or the simplest established repository mechanism. Apply every current authoritative project policy or ADR in the change-scoped ledger, including project-defined logging (logger, structured fields, levels, correlation, and redaction) and error handling (taxonomy, types or codes, boundary mapping, propagation, retry, and recovery) when affected; accept deviation only with explicit approval and evidence that scoped acceptance remains intact. Do not turn adjacent architecture or policy compliance into an audit.
• Prove that the delivered mechanism resolves the causal defect or need at its owning boundary across every in-scope entrypoint, producer, consumer, runtime registration, state transition, and material failure or recovery path. Reject symptom masking, caller-specific special cases, duplicated side channels, and accidental ordering, timing, or data dependencies. Accept tactical containment only when explicitly authorized or required for immediate safety and bounded by an owner, removal condition, and durable follow-up; completeness ends at the causal business scope, not the repository.

4. Verify Tests, Documentation, and Operations (VERIFY-1 through VERIFY-15)

• Build one change-scoped test decision ledger from requirements, approved plan, changed behavior, and affected tests. For every material risk and affected test, record existing proof, independent oracle, gate and result, level rationale, and KEEP, ADD, UPDATE, MERGE, DELETE, or justified NO_TEST; verify planned actions were actually completed and explain evidence-backed deviations.
• Rank only changed business risks by likelihood, impact, blast radius, reversibility, and regression history. Prohibit tests that merely re-prove language, framework, package, database-vendor, pass-through, or other trivial behavior; crossing a real dependency is valid only for a repository-owned rule, configuration, wiring, contract, query, schema, permission, transaction, recovery path, or journey. NO_TEST must name existing proof, another control, or accepted residual risk.
• Prefer deterministic E2E evidence through the user-observable boundary for material business risk. Require an explicit reason for integration or contract coverage; permit a unit test only for material isolated local logic when broader evidence is less deterministic, precise, or useful. Recommend the fewest tests with distinct failure signals, never test count, raw coverage, or one-test-per-acceptance-row targets.
• Require UI and other interaction tests to locate elements only through stable repository-owned contracts such as durable IDs or dedicated test hooks, never visible copy, translated text, CSS styling or layout, position, or incidental DOM structure. When exact copy is an explicit acceptance contract, assert it separately as an outcome but never use it as a locator; assign UPDATE, DELETE, or MERGE to affected tests that violate this rule.
• Validate each ledger decision against defect sensitivity, assertions, success and failure paths, authorization, boundaries, data integrity, over-mocking, snapshots, flakes, shared state, time, randomness, order dependence, and CI placement. Assign DELETE to obsolete, duplicate, trivial, implementation-detail, or immaterial proof and MERGE when its unique value survives consolidation; preserve replacement traceability and never retain superseded tests, fixtures, helpers, snapshots, or gates by inertia.
• Check required versus diagnostic gate placement, visible skips, retries and quarantine, and any review or retirement trigger for temporary characterization, migration, compatibility, incident, or workaround evidence. Quarantine is an execution state, not a portfolio action, and must not become a silent pass.

5. Challenge and Synthesize (CLOSE-1 through CLOSE-11)

• Launch all selected lenses once for the current allowed round in separate contexts with the frozen packet, one primary question, read-only tools, and the required schema; keep them blind, wait for all, and record failures or same-round retries. Never create a third subagent round.
• Verify each candidate against code, commands, behavior, declared intent, or authoritative documentation; trace symptom to causal path and violated contract, and reject subjective or symptom-only claims.
• Accept a finding only when the diff introduced, exposed, or worsened it; it violates scoped acceptance; or the change caused a required-gate failure. Treat other issues only as limitations when they block acceptance; never recommend their repair.
• Apply a materiality and acceptable-alternative gate to every in-scope candidate. Ask whether it proves a concrete user, business, safety, operational, delivery, or lifecycle impact at the evidenced project scale. Reject nitpicks, personal taste, theoretical purity, generic best practice, hypothetical scale, and an implementation that is merely different when the current tradeoff is reasonable. When several approaches are valid, require the outcome or constraint rather than one preferred design.
• Research corrections only after proving a local defect, except that DESIGN-10 must research reuse candidates before deciding whether changed custom code is justified. For corrections outside that gate, prefer an existing repository mechanism. Open current official version-matched documentation, specifications, or authoritative package sources; use reputable primary engineering material only when official sources do not resolve the tradeoff. Put a directly relevant Markdown practice link in every required resolution and record the source date, verified claim, alternatives, and smallest complete fit. Reject search-result links, generic articles, and decorative citations; mark unsupported decisions UNVERIFIED. Review never authorizes repair, and an implementer must revalidate unstable facts.
• Deduplicate by root cause, preserve the strongest evidence and widest demonstrated impact, and recommend one smallest sufficient correction.
• Resolve contradictions by tracing behavior directly. Do not add a verifier round; carry genuinely unresolved material evidence into BLOCKED or residual risk according to the verdict rules.
• Classify findings P0 catastrophic, release-blocking, important non-blocking, or minor actionable.

Output Contract

# Delivery Review
**Verdict:** PASS | CONCERNS | FAIL | BLOCKED

## Scope and evidence
- Authoritative task, approved plan, business thesis, acceptance, non-goals, base, head, and exact delta
- Changed, supporting, and excluded surfaces
- User-experience baseline and explicit change authorization
- Root-cause and solution-completeness assessment, subtraction ledger, and relevant architecture-artifact status
- Commands, external sources, and limitations

## Task, plan, and acceptance matrix
| Source | Required item | Implementation evidence | Behavioral verification | Result |
|---|---|---|---|---|
| task / plan / acceptance | ... | ... | ... | COMPLETE / DEVIATED / OMITTED / PASS / FAIL / UNPROVEN |

## User-experience delta
- Existing experience changes: None | item - explicit task authorization and verification
- Additions: None | new screen, copy, control, or scenario - trigger, rationale, and evidence

## Policy and decision compliance
| Applicable policy or ADR | Affected implementation surface | Implementation evidence | Status |
|---|---|---|---|
| ... | ... | compliant path or explicitly approved deviation | COMPLIANT / DEVIATED / UNPROVEN |

Include only current authoritative sources that apply to the change; omit draft, superseded, and merely descriptive material. Use `None` when none applies.

## Reuse and custom-code decisions
| Mechanism | Alternatives and official evidence | Decision | Lifecycle rationale |
|---|---|---|---|
| None when no changed generic mechanism applies | platform / installed / maintained package / custom | REUSE_EXISTING / ADOPT_PACKAGE / KEEP_CUSTOM / DELETE / MERGE | contract fit and material tradeoffs |

## Independent review panel
Pass: initial scope-scaled / initial full / selective follow-up / Blue-only; subagent rounds consumed: 0 / 1 / 2
| Lens | Why selected | Coverage | Result |
|---|---|---|---|
| ... | required or triggered risk | inspected surfaces and checks | findings / none / failed |
Use `None` whenever Blue selects no lens, including fully evidenced trivial work.

## Findings
| Priority | Problem | Evidence and justification | Required resolution |
|---|---|---|---|
| P0 / P1 / P2 / P3 | Concrete scoped defect or violated requirement | Location, change-causal evidence, violated contract, material impact at evidenced scale, and why the current tradeoff is not acceptable | Smallest complete correction at the owning boundary; in-scope paths, states, removals, or bounded containment; existing mechanism; and a verified `[]()` to official or primary engineering guidance; allow equivalent valid solutions |

Use `None` when no candidate survives the evidence, causality, materiality, scope, and acceptable-alternative gates.

## Verification, test, and documentation actions
Passed, failed, skipped, and unavailable checks with reasons; list every affected test and material untested risk with test basis, existing proof, oracle or accepted exposure, level and gate rationale, result, and `KEEP`, `ADD`, `UPDATE`, `MERGE`, `DELETE`, or `NO_TEST`. Report net portfolio effect, replacement evidence, quarantine, and review or retirement triggers. List each affected documentation surface with its applicable action taxonomy.


Accepted tradeoffs and unavailable evidence within the scoped change; exclude unrelated repository health.