Review Checklist

Review bijux-gnss-dev as maintainer workflow tooling. The crate may validate reviewed governance files, prove nextest-roster policy, run curated benchmark comparisons, and emit evidence into governed locations. It should not own product behavior merely because a maintainer command can call or inspect it.

flowchart LR
    change["maintainer change"]
    workflow["name governed workflow"]
    io["identify governed inputs and outputs"]
    proof["run command, roster, or benchmark proof"]
    boundary["confirm product crates keep product ownership"]

    change --> workflow --> io --> proof --> boundary

Review Gates

changed surface	accept only when	inspect before accepting
command meaning	The command owns a reviewed maintainer workflow, not product runtime behavior.	Command surface and command guide
governed input file	The file is named as reviewed repository input and has typed validation or guarded test proof.	Governed input contracts and governance file guide
evidence output	The output path is stable, documented, and tied to a maintainer workflow.	Output contracts and output guide
benchmark comparison	The curated package set, raw output, normalized snapshot, and baseline comparison remain explicit.	benchmark guide and workflow guide
slow-test roster policy	The roster still resolves to real tests and stays outside make test.	Repository test policy and nextest suite-selection proof

Blocking Signs

• A maintainer command starts making product decisions instead of inspecting repository evidence.
• A new input or output path is introduced without being named in the interface docs.
• Benchmark evidence moves into an ad hoc location or loses the baseline/current distinction.
• A roster change is justified by runtime convenience rather than by repository test-lane policy.

Evidence To Require

• Read the workflow guide, governance file guide, output guide, and maintainer test guide before accepting broad changes.
• Run cargo test -p bijux-gnss-dev --test integration_nextest_suite_selection when the slow roster or test-lane policy changes.
• State honestly when full benchmark execution is too expensive for the current review; do not present command-shape proof as benchmark-performance proof.
• Update governed input, workflow, output, or test-policy docs in the same change set as the maintained contract.