tomevault-io Code Review
Blocker-first review. Lead with what must change, not with praise.
Procedure
- Restate the slice's acceptance criteria from the approved spec. If none are visible, stop and ask for them — do not review against a guessed intent.
- Walk the diff and classify every finding as BLOCKER, SHOULD, or NOTE. Only BLOCKERs gate approval.
- Check, in this order:
- Correctness vs spec — does it meet each acceptance criterion?
- Evidence discipline — no invented package facts; inference labeled;
missing evidence explicit. (See the
evidence-disciplineskill.) - Security — no secrets/keys/
.env; input validated at boundaries; no command/SQL injection or unsanitized interpolation. - Scope — nothing beyond the spec (no speculative abstractions, features, or error handling for impossible cases).
- Consistency — matches existing patterns and the language's modern idioms; names carry intent; no dead/half-finished code.
- Tests — behavior is covered; determinism where relevant; no live APIs in unit tests; pass/fail reported truthfully.
- Output: a pass/fail verdict, then the BLOCKER list with
file:lineand the specific required change, then SHOULD/NOTE items.
Constraints
- Do not modify application code in this pass; produce the blocker list.
- Do not approve with open BLOCKERs.
- No overclaim language in the review summary.
Source: ChiromboKenT/oss-preflight — distributed by TomeVault.