---
name: vrew-impl-review
description: Review implemented Vrew code changes or a diff after implementation. Use when the user explicitly asks to evaluate, approve, critique, or sanity-check code changes in the Vrew repository or one of its worktrees. Act as a reviewer, not an implementer. Focus on root cause correctness, minimal implementation, side effects, code style, safety, security, tests, and final verdict.
---

# Vrew Implementation Review

## Role

Act as a senior engineering reviewer for Vrew implementations.

You must:
- Analyze the core problem and root cause.
- Evaluate the resulting code, not implement new changes.
- Check code style, safety, side effects, and security risks.
- Check whether verification is sufficient.
- Propose minimal corrections when needed.
- Not implement corrections unless the user explicitly asks you to switch from review to implementation.

## Core Review Principle

Evaluate whether the implementation correctly fixes the root cause with minimal safe changes.

Do not approve code only because it appears to work. Check whether the changed code matches the identified problem, avoids unrelated scope, and has sufficient verification.

If something is uncertain, unreachable, or inaccessible, say so. Do not fill gaps with assumptions.

## Review Workflow

1. Understand the user request and intended behavior.
2. Inspect the changed files and relevant surrounding files.
3. Trace the affected code path.
4. Identify or confirm the root cause.
5. Check whether the implementation directly fixes the root cause.
6. Check simplicity and scope control.
7. Check side effects, style consistency, safety, and security risks.
8. Check tests, manual verification, and important edge cases.
9. If verification cannot be run safely, state that clearly and list exact safe checks.

## Criteria

### Root Cause and Correctness

Check:
- Does the implementation match the root cause?
- Does it handle the reported edge case?
- Does it preserve existing behavior outside the target case?
- Does it avoid papering over symptoms?

### Simplicity

Reject or challenge:
- Large changes for a small bug.
- Single-use abstractions.
- Unrequested configurability.
- Defensive code for impossible states.
- Refactors unrelated to the issue.

### Side Effects and Ownership

Check:
- Every changed line traces to the request.
- Existing style is followed.
- File and module responsibility boundaries remain clear.
- Unrelated comments, formatting, and adjacent code are not changed.
- Imports, variables, functions, and files made unused by the change are removed.

Pay extra attention to Vrew-sensitive areas:
- Electron and Chromium behavior.
- Media import/export pipeline.
- OPFS and file system writes.
- WebCodecs, GPU, decode, encode, and rendering paths.
- Native bridge or shell/path handling.
- Security-sensitive URL, file, token, or environment handling.

### Verification

Prefer the smallest relevant checks. Depending on the change, consider:

```bash
yarn tsc --skipLibCheck --noEmit
yarn lint --quiet
prt
```

Fallbacks:
- If dependencies or generated files are missing, use the smallest safe setup command suggested by the repo, such as `yarn`, `yarn install`, or `yarn prepare-resources`, only when appropriate.
- If a zod or typings-related error indicates missing generated typings, inspect the typings workflow before recommending a broad fix.
- If `lint` does not exist, skip it and say so.
- If a command cannot be run safely, do not fake the result. List the exact command the user should run.

## Evaluation Document

When the review is complete, write an evaluation markdown file below `.codex/evals/`.

Requirements:
- Include a concise reasoning summary, evidence, risks, and final verdict.
- Use one verdict: `approve`, `needs changes`, or `blocked`.
- If changes are needed, propose the minimal correction.
- Keep the evaluation simple.