Fluxo de trabalho dos agentes — evidências, testes e revisão

O objetivo é implementar uma interface observável, não somente código que compila. Nenhuma ferramenta dessa especificação foi declarada já instalada ou operacional.

As tarefas podem usar os agentes e skills selecionados e receitas em docs/development/recipes/. Não invocar todos os especialistas por padrão: reservar revisão independente para mudanças sensíveis e registrar o que foi realmente testado.

Checklist de cada alteração

Ler AGENTS.md, decisões e documento funcional aplicável.
Trabalhar em incremento isolado; registrar critérios de aceite e risco.
Executar Rust fmt/clippy/test ao existir workspace.
Se altera Slint: usar preview ou viewer, inspecionar UI pelo MCP e realizar interações.
Registrar capturas de tela reais (Light, Dark, teclado/foco e erro, quando aplicável).
Se afeta Wayland Layer Shell, testar no Swirl nested ou na VM.
Se altera boot, paquetes, rede, energia, login, armazenamento, testar na VM descartável.
Para GPU e bateria, só usar o ThinkPad Edge E430 após aprovação e backup.
Reportar testes executados, não executados, falhas e limites. Nunca afirmar que “viu” uma screenshot que não conseguiu inspecionar.

Evidências

Salvar como anexos de CI ou relatórios por commit, sem dados pessoais:

reports/<feature>-<commit>/
  summary.md
  environment.json
  cargo-check.txt
  slint-light.png
  slint-dark.png
  accessibility-checks.md
  vm-console.png
  performance.json

Não gravar chave de provider, token, MAC, SSID, serial de hardware ou ambiente bruto em artifacts.

Segurança e consentimento

Agente nunca acessa disco de host em modo escrita por padrão durante teste de ISO.
Slint MCP em localhost e somente para testes; desativado fora da sessão de desenvolvimento.
Agent executa dentro do projeto e VM autorizada, não como root universal.
Login/lockscreen verdadeiro exige protocolos seguros, não é substituído por overlay.
Screenshots de janelas privadas não são capturadas por padrão.
Comparação visual só deve usar imagens geradas pela implementação em teste, sem fingir evidência.

Relatório mínimo do PR

Mudança feita; versões/ambiente; screenshots inspecionadas; testes automatizados e manuais; consumo medido se relevante; regressões, funcionalidades não implementadas e plano de rollback.

Entrega inicial sugerida: primeiro protótipo Rust+Slint do gerenciador de temas Sakura, com um controle interativo validado por MCP e modo headless quando disponível.