Maya

Contexto

Maya é um gerenciador de produtividade — não um app de tarefas a mais. A ideia central é inverter o fluxo habitual: em vez de escolher o que fazer primeiro, o sistema ajuda você a decidir o que não fazer, mede o que foi feito e trata consistência de longo prazo como o produto, não como um extra.

É um produto comercial ainda não publicado, construído por dois desenvolvedores na Rikagaku — eu entre eles. O licenciamento e os builds desktop já existem; falta o lançamento.

O problema

O desafio de engenharia não estava em nenhuma feature isolada, e sim na combinação:

• quatro superfícies — API, CLI, aplicação web e app desktop — que precisam compartilhar o mesmo núcleo de semântica;
• um domínio não-trivial: tarefas, recorrência, tempo, estatísticas, undo, importação de dados de outros sistemas;
• qualidade como requisito de produto: o que se pretende vender não pode viver quebrado;
• e uma equipe de dois desenvolvedores. Sem testes, cada refatoração viraria roleta.

A verificação não estava lá no dia zero: virou política depois de uma grande refatoração, quando o custo de mexer sem rede de segurança ficou evidente. Daí em diante, TDD como política de repositório, contrato compartilhado entre as superfícies e gates automáticos de qualidade.

Como foi construído

O coração é um workspace Rust com sete crates organizados em camadas:

• núcleo — traits marcadoras de rota, sem nenhuma dependência, que definem o vocabulário de operações;
• macros — uma proc-macro própria que transforma anotações de rota em contrato, gerado em tempo de compilação;
• biblioteca de contrato — tipos de requisição e resposta, erros e cliente HTTP, com feature flags para backend e para o navegador;
• API — servidor sobre Rocket, persistência em SQLite via Diesel, semântica de tarefas construída sobre o ecossistema Taskwarrior/Timewarrior, e WebSocket para eventos em tempo real;
• CLI — cliente de terminal, com internacionalização; a interface interativa (TUI) ainda não existe;
• frontend — SPA em WebAssembly, escrita no mesmo Rust do backend;
• desktop — shell Tauri fino: ativa licença e hospeda a aplicação localmente, sem duplicar lógica de negócio.

O contrato entre as superfícies não é documentação que envelhece: a proc-macro gera o contrato a partir do próprio código, então API, CLI, web e desktop não podem divergir sem o build quebrar.

Decisões e trade-offs

• Rust até no frontend (WebAssembly). O ecossistema é menor que o de JavaScript, mas o custo de aprender um segundo modelo mental desaparece: as quatro superfícies compartilham tipos, erros e rotas. Tipos de domínio errados viram erro de compilação, não bug de runtime.
• Um contrato, gerado em build-time. Em vez de OpenAPI escrito à mão, a macro de rotas é a fonte única; drift entre superfícies é impossível por construção.
• TDD obrigatório por política — adotado depois da grande refatoração. O repositório proíbe teste depois do fato; testes de contrato rodam contra mais de uma implementação de repositório, o que dá segurança para refatorar a persistência.
• Desktop fino. Toda a lógica vive na API local; o app desktop é um casco com empacotamento e licenciamento. Menos superfície, menos lugar para bug caro.
• Verificação comercial pronta antes do lançamento. Licenciamento com assinatura criptográfica vinculada à máquina, validado no servidor de pagamento — infraestrutura de produto, não só de código.

Qualidade e verificação

Os números do último ciclo documentado do repositório:

• 1156 testes passando;
• 95,3% de cobertura de linhas;
• mutação com piso de 70% — na medição, 100% dos mutantes mortos, ou seja, os testes não só executam o código: eles de fato asseguram o comportamento;
• CI multiplataforma (Linux, macOS e Windows) com lint tratado como erro — nenhum aviso entra;
• testes de UI rodando em navegador headless (WASM), além de testes de contrato da camada de dados;
• ambiente de testes em Docker, com o mesmo Dockerfile para qualquer máquina.

O próprio repositório é guardado pelo mido, a ferramenta de verificação que construí — inclusive com ajustes específicos de meta de mutação para o frontend.

Resultados

Maya ainda não está publicado. O que existe é o produto construído e verificado de ponta a ponta — builds para Windows, macOS e Linux e licenciamento prontos para o lançamento. Mais do que um app funcionando, o resultado é um sistema em que eu consigo mexer rápido sem medo: a combinação de contrato compartilhado + TDD + gates de qualidade significa que as mudanças ou passam na verificação, ou são barradas antes de virar problema.

O que aprendi

Verificação chegou tarde, e a conta veio junto: foi uma grande refatoração que mostrou quanto custa mexer sem rede. Por isso ela virou política, não campanha — é a única forma sustentável de uma equipe de dois manter quatro superfícies vivas. E as ferramentas de verificação que faltavam para o Maya viraram um projeto à parte: às vezes o caminho mais curto é construir a ferramenta que está faltando.