Coordinate bounded multi-perspective code reviews

This is a procedure for coordinating a bounded code review of a defined diff or subsystem from several relevant perspectives - for example correctness, authorization, and performance. It describes a review process; it does not install an orchestration engine or prove compliance, and it does not bundle any agent-routing code, compliance validator, or quality-score calculator. Execution starts by pinning the repository, base and head revisions, the changed paths, the intended behavior, and the available tests. Independent reviewing agents are used only if the user authorizes delegation and the host supports it; otherwise the perspectives are worked through sequentially - the presence of "multi-agent" in this callable's ID is not itself a reason to spawn agents. Read-only review is the default: fixes, external posts, and deployment stay within the user's actual task authority. The review itself: read the complete diff plus the directly affected call paths and tests; choose only the perspectives relevant to the change, and give each authorized reviewer a bounded question, owned paths, a time/effort limit, and an expected evidence format; record findings with exact locations, trigger, consequence, and reproduction, keeping hypotheses separate from demonstrated failures and never inventing confidence scores; reproduce important findings centrally and deduplicate them by root cause rather than wording; resolve disagreement through code or tests, since weighted votes or multiple agents repeating a claim are not evidence of correctness; and return blockers first, then material improvements and untested areas, preserving the original failing result even if a rerun does not reproduce it. Its own worked example: for a tenant-scoped cache change, review key construction, authorization context, and invalidation, and reproduce two tenants requesting the same prompt plus different prompt versions within one tenant - a finding is valid only if an actual cross-scope hit or stale result can be shown, with the smallest case demonstrating it; a general style opinion must not be presented as a data-exposure defect.

Use it to review a defined diff or subsystem from several relevant angles at once. Do not treat the "multi-agent" name as license to spawn agents by default - only delegate to independent agents when the user has authorized it and the host supports it, and keep review strictly read-only: any fix, external post, or deployment needs its own, separately granted authority. The procedure cannot prove whole-repository safety from a diff, and it does not authorize production load tests or messages.

Input: the repository, base/head revisions, the changed paths, intended behavior, and available tests. Output: findings ordered blockers first, then material improvements and untested areas, each with an exact location, trigger, consequence, and reproduction - hypotheses kept explicitly separate from demonstrated failures, with no invented confidence scores.

None are bundled: no agent-routing code, compliance validator, or quality-score calculator. It is a compatibility alias of error-debugging-multi-agent-review - new references should use that ID when no existing contract requires this one.

Reviewers coordinating a focused, multi-perspective look at a specific diff or subsystem who need reproducible, deduplicated findings rather than opinion or vote-counted claims.