Self Review

Self-review

Review the whole change, not only its latest commit. Keep the report proportional to the diff; a small fix does not need a technical essay.

Report-only — do not edit, commit, or push as part of reviewing. Once the contributor makes fixes, load commit-and-pr for the commit/PR conventions and run-cpu-tests for tests.

1. Establish scope

Identify the intended base and its remote; a stacked PR may not target main. Record the exact base and head SHAs, then inspect the whole three-dot diff:

git remote -v
git fetch <base-remote> <base-branch>
git rev-parse <base-ref> HEAD
git diff <base-ref>...HEAD

Do not replace this with a last-commit review. A two-dot comparison against newer main includes main-only changes; check the merge base before calling those regressions. Use individual commits for history, not to omit parts of the final diff. For local uncommitted work, also inspect git diff --cached and git diff. Re-check affected evidence if the reviewed head changes.

2. Read the applicable rules

AGENTS.md is the top-level contract. Read the current guides, not a remembered copy. Formatting and project-specific conventions belong to these sources:

3. Review and report in four parts

A. Purpose and technical background

Summarize the problem, the mechanism being changed, and why the change is needed. Trace the relevant callers and consumers: e.g. config → allocation → worker, rollout → replay → loss, or adapter export → binding → forward. Check whether an existing implementation already solves it before recommending another abstraction.

B. Code quality and correctness

Inspect changed lines and their execution context, using the code-style rules. Classify findings by subject; these categories are not severity levels:

Mark an issue blocking or non-blocking from its impact, independently of category. Missing critical validation can block; a naming preference usually cannot. Do not invent findings to avoid saying the code is sound, or impose source-line limits, blanket bans on framework hooks, or formatter-only nits.

Project-specific checks:

• Wire compatibility: for protocol-preserving refactors, keep valid prompt_token_ids, multi_modal_data and extra_fields intact end to end. Unsupported or conflicting fields must not disappear silently.
• Media contracts: use DiffusionIOSpec / media_kind rather than guessing modality from ndim or a dimension equal to three.
• Distributed paths: verify actual replica/rank allocation, sample ordering and loss normalization, not just a parsed config or a printed parallel degree.
• Weight sync: trace export, name/shape/scaling conversion, binding and use. A tensor count or active adapter ID alone cannot prove value-correct binding.
• Surgical scope: flag unrelated cleanup and orphaned code caused by this change; do not demand refactoring pre-existing debt unrelated to the goal.

Each finding needs: severity + category + evidence tag → path:line → triggering input/path → impact and why → concrete fix or next verification step.

C. Goal completeness

Compare the final diff with the issue and PR description. List unmet requirements, unsupported configurations, prerequisite PRs and changed defaults/compatibility. An intentional limitation is not a proven bug, but must not be presented as implemented or validated support. Check that examples and docs use the same contract as the code.