review-pr

# Review PR Review the PR from the user's point of view: make the decision easy, then provide detail only when it changes the decision. ## Workflow 1. Inspect PR metadata, files, diff, and checks. 2. Read the touched code and nearby architecture boundaries. 3. Identify whether the change is a behavior change, performance change, refactor, test-only change, docs-only change, or CI/infrastructure change. 4. Run the required review passes: - architecture fit: does the change match existing module boundaries and project patterns; - adversarial review: what breaks under edge cases, bad inputs, scale, concurrency, cancellation, cache misses, offline mode, or hosted runner differences; - security review: secrets, tokens, path traversal, unsafe downloads, sandbox escapes, user-controlled file paths, network exposure, dependency risk, and data leakage; - docs review: local docs, public site docs, README translations, CLI help, model tables, benchmark pages, and migration notes when behavior is user-visible. 5. Assess regression risk from the changed behavior and blast radius. 6. Decide whether existing tests are enough. Include E2E coverage for runtime/model/user-facing behavior, or explicitly state why E2E is not applicable. Add or request tests only when they protect a real risk. 7. Run the smallest meaningful validation: - unit tests for logic and data structures; - focused E2E for model/runtime behavior; - CLI probe or benchmark only when the PR changes user-facing runtime behavior or performance. 8. End with a short merge recommendation. ## Output Shape Start with this format unless the user asks for a detailed code review: ```md Status: ready / not ready / needs follow-up What changed: ... Architecture fit: ... Adversarial/security/docs: Adversarial: ... Security: ... Docs: ... Regression risk: Low / medium / high, with one-sentence reason. Tests: Unit: ... E2E: ... Needed: ... Recommendation: Merge / request changes / investigate first. ``` ## Review Rules - Lead with blockers if any exist. - Keep conceptual summary above command details. - Do not paste logs unless asked. - Be adversarial about failure modes, but do not invent blockers without evidence. - Treat security and docs as explicit review passes, even when the conclusion is "no impact." - Always report E2E tests run. If none were run, state the reason and whether that is acceptable. - Do not add slow permanent E2E tests just to prove a local probe; add permanent tests when they guard realistic future regressions. - Prefer same-input comparison against `main` for performance or refactor PRs when output preservation matters. - Treat model download, cache, and hosted runner failures as infrastructure unless code behavior caused them. - For public API, CLI flags, model variants, or docs-visible behavior, call out required docs updates. - For README changes, verify all translated README files are updated.