baratihd/skills

Planejador do Backend Treatment

Esta é uma skill de planejamento, compartilhada entre Codex, OpenCode e Claude Code. Produza um design acionável baseado em evidências verificadas do repositório; não modifique código da aplicação nem execute migrações no modo de planejamento, a menos que solicitado explicitamente.

Descobrir e verificar contexto

1. Identifique o resultado solicitado, critérios de aceitação, branch de trabalho, branch de destino (se relevante) e ambiente de implantação pretendido. Não assuma nomes de branch production ou development. Verifique git status e referências antes de comparar. Nunca sobrescreva trabalho não commitado.
2. Leia os documentos existentes de produto/negócios (em persa) e documentos técnicos/de qualidade (em inglês) relevantes, quando disponíveis. Se estiverem faltando, sinalize exatamente qual documentação está faltando; não invente requisitos de negócio.
3. Se o Graphify estiver instalado e um grafo atual aplicável estiver disponível, use opcionalmente graphify query, path ou explain para se orientar; nunca exija o Graphify. Se estiver indisponível ou desatualizado, pesquise diretamente no código-fonte, migrações, configurações e testes relevantes. Trate grafos como dicas, não como evidências.
4. Verifique classes, pontos de chamada, permissões, fluxos de dados, configuração, restrições de banco de dados e dependências externas no código-fonte real.
5. Determine as versões do Python/Django/ambiente de execução a partir da configuração ativa do projeto e arquivos de bloqueio. Relate inconsistências; não codifique versões históricas do framework.
6. Para comparações de branch, use as referências de origem e destino especificadas pelo usuário; distinga o histórico de commits das alterações na árvore de trabalho. Não busque referências remotas sem considerar a autorização do usuário/disponibilidade de rede.

Revisão de arquitetura e impacto de mudanças

• Identifique a aplicação proprietária e seus limites; evite abstrações desnecessárias ou acoplamento entre aplicações. Aplique SOLID e camadas limpas de forma pragmática, não mecânica.
• Verifique contratos de API pública (rotas, serializadores, tipos de campo, formatos de status/erro, paginação, filtragem), compatibilidade com frontend/PWA e autenticação/autorização/isolamento de inquilino.
• Analise custos de consulta ORM, N+1, transações e locks, restrições, concorrência, consistência de dados, ordenação de migrações e reversibilidade.
• Inclua efeitos assíncronos e externos (retentativas e idempotência do Celery, transaction.on_commit, invalidação de cache, sincronização Elasticsearch/índice, timeouts e erros HTTP, gateways SMS).
• Analise observabilidade, segurança e segredos, operações, rollout, rollback, feature flags e sequenciamento de implantação conforme relevante.
• Separe comportamento atual verificado, comportamento pretendido documentado, mudança proposta e perguntas em aberto. Identifique claramente qualquer incompatibilidade.
• Considere testabilidade e infraestrutura de teste existente; nenhum envio real de terceiros/SMS/Celery em testes automatizados de rotina.

Saída necessária

Produza um plano com decisões completas contendo:

1. Escopo, objetivo, restrições e critérios de aceitação.
2. Evidências e caminhos de origem relevantes, além da revisão de origem/destino quando usado.
3. Arquitetura/fluxo de dados atual e arquitetura/fluxo de dados proposto, com propriedade dos componentes.
4. Etapas de implementação ordenadas, interfaces públicas afetadas e medidas de compatibilidade.
5. Estratégia de migração/preenchimento retroativo, tratamento de falhas, observabilidade, rollout e rollback (se aplicável).
6. Cenários explícitos de Teste Unitário/Integração/API/E2E/Fumaça (FireTest), migração, segurança e desempenho proporcionais ao risco.
7. Atualizações de documentação necessárias e páginas de documentação afetadas.
8. Incertezas, suposições, trade-offs e decisões bloqueadas; faça perguntas direcionadas apenas quando necessário.

Colaboração entre skills

• Quando treatment-django-engineer invocar esta skill, retorne o plano primeiro; o engenheiro é responsável pela implementação, integração e relatório final.
• Recomende django-product-documentation para atualizar a documentação impactada e treatment-backend-testing para implementar testes, mas não afirme que essas skills foram executadas a menos que sejam encontradas e realmente invocadas/lidas.
• Se uma skill dependente estiver ausente, registre a dependência ausente e forneça um plano alternativo utilizável sem fabricar suas regras.
• Esta skill não é executada automaticamente em cada erro de digitação ou alteração de formatação trivial; adapte o esforço de planejamento ao impacto.

Salvaguardas inegociáveis

Nunca invente políticas de domínio, modelos de dados, comportamento de API não documentado ou resultados de teste. Nenhuma operação destrutiva silenciosa de banco de dados, commits, implantação ou alterações em arquivos não relacionados. Não afirme cobertura, build, migração ou sucesso de integração sem executar e medir isso.