Quest Solution Review

Choose the implementation that fully solves the quest with the least ongoing complexity. Do not reward being first, large, or already up to date with main.

Review

1. Read the quest, acceptance criteria, and relevant current code.
2. Find every linked implementation from the issue timeline, closing keywords, cross-references, and PR search. Include closed and draft PRs when they are genuine submissions.
3. Inspect each complete diff and checks. Separate branch-age conflicts from the quality of the proposed change.
4. Verify changing external contracts against current primary documentation.
5. Apply the gates below, then test the strongest candidates in proportion to risk. Prefer focused tests of real code and a practical smoke test when one is feasible.

Correctness gate

A candidate must:

• Meet the quest's observable acceptance criteria.
• Use the real provider/API contract and the repository's existing architecture.
• Preserve required auth, permissions, security, accounting, and tracking.
• Bill from the provider's reported usage when the route reports it, not from a price formula rebuilt from request parameters.
• Handle failure modes that users can realistically encounter.

Reject a candidate that only appears to work, silently changes the public contract, or requires speculative fallback behavior to cover a defect.

Simplicity comparison

Among correct candidates, prefer:

• The smallest focused diff and fewest new concepts.
• Existing shared utilities and established data flow.
• Clear ownership and direct code over wrappers or generic frameworks for one use case.
• Focused tests that exercise the production implementation.
• Registry, schema, and documentation changes only when the public contract requires them.

Treat unrelated edits, generated noise, lockfile churn, duplicated helpers, hard-coded copies of dynamic data, mock infrastructure, and contaminated commit history as costs. Line count is evidence, not the decision by itself. Consider meaningful effort separately from the final diff: real testing, investigating failures, responding to feedback, and iterations that simplify the solution all count. Do not use lines of code or commit count as proxies; effort does not replace correctness or maintainability.

Report

Give a concise comparison containing:

• Candidate PRs reviewed and any submissions excluded, with the reason.
• Blocking correctness findings.
• Relative complexity and useful ideas found in alternatives.
• Tests, checks, and smoke tests actually run.
• A verdict: merge, request a small follow-up, combine a specific idea, or accept none.

Do not comment, close, edit, or merge contributor PRs unless the user asks. If a maintainer follow-up is authorized, keep it minimal and preserve contributor attribution. A small bonus for an alternative is exceptional: use it only when the alternative was independently strong, materially influenced the shipped solution, or contributed valuable testing and thoughtful iteration. State the actual reason; do not invent inspiration that did not occur.