Mvsep Rs Rewrite

---
name: mvsep-rs-rewrite
description: Coordinate the mvsep-rs gradual backend rewrite. Use when the user asks to continue, plan, implement, audit, or route work for replacing the old Tauri backend with the rewritten Rust backend; when updating migration state, project constraints, rewrite docs, or multi-agent rewrite workflow; or when deciding the next mvsep-rs migration batch.
---

# mvsep-rs Rewrite

## Overview

Drive the project-specific rewrite loop for mvsep-rs. This skill treats the repo like a stateful engineering workspace: mission, resources, notes, rewrite records, architecture, manifest and reviews are the durable handoff.

## Start Here

1. Confirm the current workspace is `mvsep-rs`; if not, locate it or ask for the repo path.
2. Read these files before making decisions:
   - `docs/INDEX.md`
   - `docs/mission.md`
   - `RESOURCES.md`
   - `Note.md`
   - `CONTEXT.md`
   - `rewrite-records/README.md`
   - `manifest/rewrite-status.yaml`
   - `docs/architecture/backend-rewrite.md`
3. Read `docs/references/high-confidence-sources.md` when touching Tauri, Tailwind, Vite, Tokio, reqwest, rusqlite, or MVSep API behavior.
4. Read the compiled DAG snapshot, graph revision, Git baseline, active locks,
   worktree assignments and integration waves when present.
5. If the task is only a review, use the review workflow in `mvsep-rs-review-gate` instead of writing production code.
6. If the task is implementation, use the writer workflow in `mvsep-rs-batch-writer` or follow its rules directly.

## Batch Selection

- If the user names a batch, select only a dependency-ready node for it.
- Otherwise compile the manifest and admit critical-path ready nodes whose
  dependencies, approvals, locks and capacity permit execution.
- Do not skip a behavior gate to do later optimization.
- Run disjoint batch phases concurrently only through DAG admission and isolated worktrees.
- Treat each batch as a minimum boundary: one useful slice that can be understood, tested, reviewed and resumed.

## Borrowed Ideas Boundary

- Borrow from `teach`: mission-grounded work, resource records, notes, rewrite records and minimum scoped progression.
- Borrow from `py2rs`: behavior-first migration, reversible state, manifest-driven progress, role-separated agents and review gates.
- Do not borrow py2rs architecture: no `py/` and `rs/` split, no Python runtime router, no script-as-unit migration rule and no py2rs stage numbering as this project's architecture.
- If this boundary changes, update `RESOURCES.md` and add a `rewrite-records/` entry before changing implementation.

## Rewrite Loop

1. Ground in state: read resources, rewrite records, manifest, architecture, relevant source files and existing tests.
2. Define the batch's public interface: command names, event names, TypeScript payloads, DB paths and rollback route.
3. Add or update tests that prove behavior before changing implementation when practical.
4. Compile the phase DAG and admit ready nodes by critical path, locks and capacity.
5. Run mutating nodes in isolated worktrees through the chosen backend seam.
6. Collect atomic candidate commits and run relevant checks from `docs/INDEX.md`.
7. Let the coordinator update factual manifest/graph state and merge an integration wave.
8. Run R0 first, then required gates serially per batch by explicit dependencies and risk.
9. Run integration R0 before promotion.

## Non-Negotiables

- Preserve existing Tauri command names and progress event names unless a batch explicitly changes protocol.
- Do not let frontend pages call database/repository shapes directly.
- Do not replace the accepted Tauri command facade architecture with py2rs runtime/router architecture.
- Do not place blocking HTTP or nested Tokio runtimes in Tauri async command paths.
- Keep errors structured until the Tauri command edge stringifies them.
- Do not let a code-writing agent review its own code.
- Do not mix review themes in one reviewer pass.
- Do not run multiple review gates or reviewer agents against the same batch concurrently.
- Do not let workers edit the canonical graph/manifest, merge candidate commits
  or resolve integration conflicts.

## Multi-Agent Rules

- Use a writer for implementation and separate reviewers for behavior, error tracing, async ergonomics, data/algorithm, Rust style and frontend UX.
- If subagents are available and explicitly requested, assign disjoint ownership and tell workers they are not alone in the codebase.
- Reviewers may write review reports, but must not edit production code.
- Behavior review is the first gate for every batch.
- Review gates are serial per batch even when writers are parallel: finish and
  persist one report before starting or delegating the next gate for that batch.
  Reviews of disjoint batches may run concurrently only when their checks,
  report paths, and state writes cannot race. Separate roles are logical scopes
  and may reuse one reviewer context sequentially.

## Completion Criteria

- The next action is obvious from the manifest or final response.
- Any code changes have tests or a clear statement of untested risk.
- Any review outcome has a report in `reviews/`.
- The final response names changed files and checks run.