Type Precision Review

One question, asked everywhere: where the project already offers a precise type, does the change use it?

A loose type is not a style preference. A domain value travelling as a bare string is a value nobody validated, carried through code that cannot tell valid from invalid. The precise type exists to make that visible, so every place it has been widened, cast away, or redeclared is a defect with a reader cost and usually a latent bug.

Target

Scope comes from $ARGUMENTS: a path, commit, range, branch, or PR number; empty means uncommitted changes plus the current branch's diff vs its base. For a single commit, compare against its first parent. Run git status --short first and do not report problems already fixed in the worktree.

Scope discipline. Report only what the change introduced or made load-bearing. A pre-existing loose signature is out of scope however bad it looks; note it rather than reporting it. Without this rule a repeated review re-raises the whole codebase every round.

Orient First

Before judging anything, find out what the project actually offers. A finding that recommends a type the codebase does not have is noise.