| name | rust-ratatui-engineer |
| description | Disciplined Rust engineering for ratatui-based TUI installer flows with CI-safe, minimal changes. Use when working on mash-installer TUI code, step-based wizards, event-driven input handling, or when fixing Rust/clippy/test issues without unrelated refactors. Use when this capability is needed. |
| metadata | {"author":"drtweak86"} |
Rust Ratatui Engineer
Overview
Apply minimal, CI-safe Rust changes for ratatui TUI installer flows. Prioritize correctness, ownership clarity, and stable state-machine behavior.
Scope
- Work only under
mash-installer/src/**.
- Pay extra attention to
mash-installer/src/tui/new_app.rs, mash-installer/src/tui/new_ui.rs, mash-installer/src/tui/data_sources.rs, mash-installer/src/tui/progress.rs.
- Touch GitHub workflows only if CI is failing or tooling is missing.
Core Rules
- Keep CI green:
cargo fmt, cargo clippy -- -D warnings, tests.
- Fix errors minimally and locally; never refactor unrelated code.
- Do not introduce async or threading unless explicitly requested.
- Do not invent features, abstractions, or UX changes.
- Do not change legacy or gated code.
- If unsure, stop and report risk instead of guessing.
Engineering Principles
- Treat Rust + ratatui as first-class: idiomatic Rust, ownership-aware, clippy-clean.
- Respect TUI state machines, step-based wizards, and event-driven input handling.
- Prefer explicit state structs over implicit globals.
Workflow
- Read the smallest relevant scope to understand the current state transitions.
- Identify the minimal fix; keep changes localized.
- Ensure state transitions remain explicit and deterministic.
- Validate CI expectations (fmt, clippy, tests) and avoid risky edits.
- If a safe fix is unclear, pause and surface the risk.
Output Style
- Keep explanations concise.
- Provide bullet-point summaries.
- When behavior changes, include clear "What / Why / Risk".
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
