Vocal2midi Rs Review Gate

---
name: vocal2midi-rs-review-gate
description: Review one Vocal2Midi Rust migration unit quality gate without writing production code. Use for Python/Rust behavior parity, dependency/seam, error tracing, data/algorithm, Rust style, architecture, ergonomics, or promotion readiness.
---

# Vocal2Midi Rust Review Gate

Run one independent review role for one migration unit and write a durable report
under `rewrite-in-rust/reviews/`.

Claim the selected unit before starting. Do not run or delegate another review
role against that unit until the current report is persisted and the unit is
released. Reviews of disjoint units may run concurrently only when their checks,
report paths, and state writes cannot race.

Review the exact candidate or integration-wave commit and graph revision. The
reviewer session must not have produced the candidate commit. Stop and mark the
evidence stale if the commit, manifest revision or artifact digest changed.

## Required Context

Read these first:

- `rewrite-in-rust/README.md`
- `rewrite-in-rust/manifest.yaml`
- `rewrite-in-rust/resources.md`
- `rewrite-in-rust/notes.md`
- `rewrite-in-rust/reviews/README.md`
- relevant records under `rewrite-in-rust/records/`
- relevant dependency/bootstrap records
- diff and files touched by the unit
- tests and fixtures relevant to the unit
- candidate/integration commit, graph revision and input artifact digests

Completion criterion: review findings cite code, fixtures, docs, or commands.

## Choose Exactly One Role

- `behavior_reviewer`: Python/Rust parity, public inputs, outputs, ordering,
  errors, fixtures, and rollback.
- `dependency_bootstrap_reviewer`: capability coverage, kept-legacy decisions,
  seam choice, provisional inventory changes, crate reuse plus semantic-delta
  adapter choices, first-layer source coverage, targeted transitive expansion,
  hand-written replacement choices, low-level boundary decisions, and missing
  crate/fixture risk.
- `error_tracing_reviewer`: structured errors, context, redaction, logs, and
  diagnosability.
- `data_algorithm_reviewer`: data structures, numeric behavior, complexity,
  benchmarks, and algorithmic assumptions.
- `rust_style_reviewer`: Rust module shape, ownership, visibility, tests,
  warnings, and maintainability.
- `architecture_reviewer`: owner boundaries, control-plane purity, bridge shape,
  and promotion risk.
- `product_ergonomics_reviewer`: CLI/Web/GUI workflow impact, user-visible
  messages, recovery, and operational ergonomics.

If the user asks for all reviews, run the R0 behavior role first, then choose
remaining roles from explicit dependencies and risk priority as separate serial
passes for that unit. One reviewer context may
be reused sequentially. Other disjoint units may be reviewed concurrently when
they cannot race on shared mutable state.

Completion criterion: one role and one unit are explicit.

## Review Workflow

1. Confirm unit id, review role, `behavior_verification` and legacy seam evidence.
2. Confirm the unit stayed inside its minimum boundary, or that dependency
   expansion justifies the re-cut boundary.
3. Confirm writer/reviewer separation.
4. For dependency reviews, judge coverage by capability, not package-name or
   top-level API parity. A Rust crate can be acceptable when it owns a stable
   lower layer and the dependency record names Python-specific gaps, reference
   source, semantic-delta adapter plan, and fixture evidence. Full hand-written
   replacement can also be acceptable when the record explains why crate reuse
   plus adapter is worse for this unit.
5. Inspect only the scope needed for the chosen role.
6. Run non-mutating checks where useful.
7. Report findings first, ordered by severity, with file/line references.
8. Write `rewrite-in-rust/reviews/YYYY-MM-DD-<unit-id>-<role>.md` with the exact input fingerprint.
9. Use decision `pass`, `pass-with-followups`, or `fail`.
10. Do not mark the manifest `verified`; the coordinator updates state after
   required reviews pass.

Completion criterion: the report can be used as durable promotion evidence.

## Boundaries

- Do not edit production code.
- Do not combine multiple review roles in one report.
- Do not rely on the writer's explanation when files or tests can answer.
- Do not approve a new bridge architecture without a matching record and
  rollback route.
- Do not approve a unit boundary merely because it appeared in the initial
  manifest; check dependency expansion evidence when that is in scope.
- Do not fail a dependency decision merely because no Rust crate is a perfect
  Python package drop-in. Fail it only when the selected crate-owned layer,
  semantic-delta adapter, Python-source reference, or fixtures are insufficient
  for the claimed behavior.
- Do not treat fewer Rust dependencies as a success metric. Challenge both
  unnecessary full hand-written rewrites and unnecessary crate integration.
- For dependency reviews, first-layer direct Python dependency source should be
  indexed or explicitly missing. Second-layer or deeper source expansion needs
  public-seam call path evidence; lockfile transitivity alone is not enough.
- For behavior reviews, review the selected public seam, not every transitive
  dependency or native implementation detail below it. Low-level differences
  such as NaN bit payloads, internal table layouts, allocator behavior, struct
  padding, SIMD branches, or kernel selection matter only when they affect
  public outputs, errors, serialization, persistence, memory/ABI contracts,
  security, or model/numeric correctness.
- For deep inference behavior reviews, require application fixtures for model
  loading, codecs, artifacts and tensor handoff whenever they cross the selected
  seam. Comparison is exact unless the manifest records an existing or explicitly
  approved model/numeric tolerance.
- Never replace a failed behavior review with compile or Rust-to-Rust evidence.
- Do not reuse a verdict after its candidate/integration commit or graph revision changes.
- If no issue is found, say so and document residual risk.

## Completion Response

Summarize decision, report path, highest-severity findings, checks run, and
whether the unit is ready for coordinator state update.