Ln 33 Plan Reviewer

4. Review from Every Applicable Perspective

• Intent and traceability: Every proposed change and source of complexity maps to the intended outcome, an acceptance criterion, a safety need, or an evidenced constraint; combine work serving the same outcome, and remove speculative or merely ceremonial steps.
• Repository fit: The plan respects actual project structure, conventions, supported stack, existing capabilities, maturity, current scale, team and operational capacity, and current work without overwriting unrelated changes. For each applicable current project policy or ADR in the ledger, trace the affected plan surface to compliance or an explicitly approved and justified deviation; include project-defined logging, error taxonomy and boundary mapping, configuration, observability, security, persistence, testing, and release rules only when the change reaches them.
• Architecture, ownership, and traceability: Layers, modules, orchestration, side effects, dependency direction, and resource ownership remain explicit, coherent, and proportionate. The plan respects confirmed constraints, accepted decisions, target boundaries, and the active migration phase; expose stale or contradictory artifacts instead of silently selecting the convenient one.
• Root cause and completeness: Trace the owning correction across in-scope entrypoints, producers, consumers, registration, state transitions, and material failure/recovery paths. Reject symptom masking, caller special cases, side channels, and accidental ordering/timing/data dependencies. Tactical containment requires explicit intent or immediate safety, an owner, removal condition, and durable follow-up; stop at the causal business scope.
• Interfaces and data: Public APIs, events, schemas, configuration, persistence, serialization, compatibility, and migration paths are named wherever they change. 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--plan 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). Do not demand extraction of a harmless one-off local literal with no duplication, invalid-state, or drift risk.
• Scenario completeness: For each critical flow, trace actor trigger -> entrypoint -> runtime discovery or wiring -> usage context -> observable outcome; include first meaningful use, failure, recovery, and repetition when they can change the intended experience.
• Correctness and failure modes: Cover boundaries, invalid state, partial failure, retries, idempotency, concurrency, cancellation, timeouts, rollback, and cleanup where applicable.
• Security and privacy: Cover trust boundaries, authentication, authorization, validation, secrets, sensitive data, logging, destructive actions, and abuse paths in proportion to risk.
• Dependencies and sequencing: Use the fewest dependency-ordered steps that can reach acceptance safely; parallel steps have no same-wave dependency or shared mutable output, and migrations, producers, consumers, deployments, and compatibility transitions remain ordered correctly.
• Capacity and degradation: Bound user- or data-controlled work and state load from evidenced demand; state rate assumptions and failure behavior without introducing scaling machinery for hypothetical traffic.
• Testing and acceptance: For each material business risk and affected test, require its basis, existing proof, independent oracle, level and gate rationale, and one action: KEEP, ADD, UPDATE, MERGE, DELETE, or justified NO_TEST. Require unique defect signals and completion evidence, not test counts or raw coverage; give temporary proof a review or retirement trigger without redesigning unrelated tests.
• Test value and boundary: Require every test to detect a concrete defect in this product's business logic and name the protected business outcome. Prefer E2E through user or external-system boundaries; use integration or unit tests only for business scenarios difficult to exercise reliably through E2E. Reject platform, trivial-wiring, implementation-detail, and duplicate proof with no distinct business failure signal.
• Delivery and operations: Include documentation, configuration rollout, observability, deployment, rollback, and operator actions only where the change requires them.
• Simplicity and alternatives: Evaluate NO_CHANGE, DELETE_OR_CONFIGURE, REUSE_LOCAL, USE_PLATFORM_OR_STDLIB, REUSE_INSTALLED, ADOPT_DEPENDENCY, then MINIMAL_CUSTOM; justify the selected rung and rejected applicable simpler options. New code, dependencies, layers, services, configuration, extensibility, or operational machinery need a concrete capability or lifecycle-cost reason. Consolidation must preserve ownership, verification, correctness, safety, compatibility, testability, and reversibility.
• Subtractive completeness: For changed logic, constraints, configuration, schemas, routes, states, or operations, identify obsolete code, branches, flags, keys, defaults, shims, data paths, documentation, tests, permissions, metrics, and rollout scaffolding. Plan removal only when evidence proves it superseded and in scope; otherwise record retention evidence or a temporary path's owner and removal condition.

5. Challenge Material Uncertainty When Needed

• Use an independent challenge only when an unresolved material question warrants it and the user permits it; clear the conditional challenge items otherwise. Select the smallest distinct set of execution-simulation, fresh-context, or adversarial perspectives that can change the verdict, without quotas. Keep the challenge to one bounded round; resolve resulting evidence gaps directly.
• Give every reviewer the same frozen packet—plan, real goal, relevant repository paths, constraints, assumptions, and evidence questions—without prior conversation history, the primary review's conclusions, or sibling outputs. If the host cannot provide fresh isolated contexts, use distinct self-review passes and disclose reduced independence.
• Launch the selected perspectives once in parallel or one blind wave, wait for all, and treat every suggestion as a candidate finding requiring repository or authoritative evidence. Resolve conflicts and verify candidates directly; never launch a verifier or another reviewer round.
• Classify pre-mortem concerns as evidence-backed risk, unsupported fear, or unstated assumption; dismiss unsupported fear, and give each accepted risk or assumption an invalidation impact and concrete validation or mitigation step.
• Treat reviewer unavailability, tool failure, rate limits, or questions as coverage limitations, not evidence that the plan is defective. Retry or replace one technically failed selected reviewer only when a concrete cause changes, using the same evidence question; this completes the original round and must not broaden it.

6. Synthesize a Decision-Complete Result

• Deduplicate findings from repository inspection, research, and independent review; keep the strongest evidence and preserve meaningful disagreements.
• Classify findings as BLOCKER, MAJOR, or MINOR: blockers prevent safe handoff, majors predict substantial rework or regression, and minors improve clarity without changing feasibility.
• Apply a materiality and acceptable-alternative gate to every candidate. Require a violated requirement or contract, or a concrete user, business, safety, operational, delivery, or lifecycle impact at evidenced scale. Reject unsupported or pre-existing unrelated problems, nitpicks, personal taste, theoretical purity, generic practice, hypothetical scale, and a merely different implementation when the current tradeoff is reasonable. For every accepted finding, explain why the compromise is unacceptable and require the smallest complete outcome while allowing equivalent solutions.
• Cite verified sources for externally dependent corrections; cite local evidence for repository-owned defects. Mark only unsupported claims UNVERIFIED; do not obscure an independently proven defect because an optional practice source is unavailable.
• Confirm that consequential interfaces, ownership, data flow, failure behavior, compatibility, verification, and rollout are decided or bounded by explicit constraints; leave equivalent implementation details to the implementer.
• For every material assumption, record confidence, what breaks if it is false, and who or what step validates it before dependent work begins.
• Verify the plan covers complete observable increments, dependency ordering, integration between increments, and required verification; expose consequential decisions deferred to the implementer.
• Map findings to verdicts: use BLOCKED when a required user choice, access, or authoritative fact is unavailable; use FAIL for any correctable BLOCKER or MAJOR; use CONCERNS only when the plan is safe and executable with no uncovered requirement or consequential decision, but bounded non-blocking MINOR amendments or explicitly accepted residual risks remain; use PASS only when no corrective finding or blocking evidence gap remains.
• For FAIL, provide exact local amendments when they make the plan coherent; provide a complete replacement only when changes span its structure or dependencies. Preserve intent, accepted corrections, and required implementation/verification outcomes.
• For CONCERNS, provide only the exact local plan amendments and accepted non-blocking risks; do not restate unchanged sections of the plan.
• For BLOCKED, ask only the smallest questions that materially unlock a different plan, and state what was already verified.

Self-Check

• Reconcile before returning. Check item-level evidence, requirement coverage, contradictions, scope, verdict, and applicable cleanup. Correct the report or authorized artifacts. Reuse valid evidence; do not automatically rescan the repository or rerun successful commands. Repeat checks only for relevant changes, failures, or unresolved evidence. Disclose remaining gaps.

Output Contract

Report in the user's language, in this order; label all five fields and state each fact once. Use controlled plain language: one fact per sentence, usually under 20 words, active voice, and one term per concept, with no synonyms for verdicts, IDs, or states. Small results may use one line per field; omit empty tables and do not copy linked artifacts:

1. Result: The exact skill-specific verdict token first, then the supported outcome.
2. Scope: Reviewed/changed scope, exclusions, baseline, and material assumptions.
3. Evidence: Skill-specific fields below; distinguish facts, inferences, and unverified claims. Link artifacts; use tables when useful.
4. Verification: Checks/results, unavailable evidence, and applicable cleanup/external state.
5. Completion: Checklist: X/Y complete; Incomplete: None or each UNPROVEN item's reason, outcome impact, and exact next action; residual risks and required decisions.

Skill-specific evidence: Plan decision, required corrections, acceptance and sequencing gaps; task/plan requirement → evidence → status. Include applicable policy/ADR compliance and approved deviations, root-cause completeness, retained or removed mechanisms, test and documentation actions, independent-challenge coverage, and authoritative references only for externally dependent corrections. Each finding needs priority, location, violated contract, material impact, and the smallest sufficient correction; allow equivalent valid solutions. Preserve the corrected plan or decision-changing amendments in the response only.