Proposal: Dogfood Vite Task in this repository (self-host the repo tasks)

A proposta menciona a configuração atual do just e os workflows do repositório, mas não nomeia arquivos nem testes. Comece revisando como as tarefas existentes estão organizadas e comparando isso com os recursos do Vite Task para este monorepo com foco em Rust. Para considerar o trabalho concluído, seria necessário definir de comum acordo o escopo da migração e os critérios de sucesso, que o issue não define.

First of all, sorry if this is a noisy or unnecessary suggestion.

I just wanted to share this with a lot of respect: Vite Task already feels extremely well designed, and I genuinely think it has the potential to be useful beyond the JS/TS ecosystem, including repositories with a strong Rust focus like this one.

At the moment, this repository appears to use just for task orchestration. Since Vite Task itself is a monorepo task runner, I was wondering whether it might be interesting to dogfood it here and gradually self-host the repository tasks with Vite Task itself.

I think this could have a few benefits:

• It would serve as a strong real-world example of Vite Task managing its own development workflows.
• It would demonstrate that the tool is not limited to JS/TS-heavy repositories, but can also fit mixed or Rust-centric monorepos.
• Dogfooding could help uncover UX gaps, missing features, or rough edges earlier.
• It would make the project story even stronger: the tool is good enough to run itself.

I am not suggesting this as “Just is wrong” or that migration should be rushed. just is great, and there may be perfectly good reasons to keep the current setup. I only wanted to suggest that self-hosting could be a compelling direction if it aligns with the project goals.

Even a partial migration could be interesting at first, for example:

• introducing Vite Task for a subset of repository workflows,
• comparing ergonomics/performance with the current setup,
• and expanding only if it proves valuable.

In any case, thank you for building this. It already looks like a really promising piece of tooling, and I would love to see it adopted across ecosystem boundaries, not only in JS/TS projects but also in repositories that include Rust and other languages.