Revisão de Implementação Full-Stack

Quando Usar

Use quando uma funcionalidade abrange o navegador, o serviço de backend e o banco de dados, ou ao revisar uma implementação full-stack existente em busca de lacunas de integração.

Fluxo de Trabalho

1. Inspecione a pilha real do projeto, os comandos de build e as convenções. Trace uma jornada do usuário através do estado da interface, solicitação de API, autorização, acesso a dados e tratamento de resposta.
2. Defina o contrato de solicitação/resposta, verificações de permissão, validação de entrada e estados de falha antes de alterar o código. Mantenha as migrações de banco de dados e os efeitos colaterais externos explícitos.
3. Implemente a menor fatia coerente usando dependências existentes. Separe a apresentação da interface, a lógica de domínio e a persistência; use consultas parametrizadas e autorização no lado do servidor.
4. Execute verificações de propriedade do projeto para o comportamento alterado: testes unitários para regras, testes de integração para permissões e persistência, e testes de navegador para a jornada completa. Registre quais verificações realmente foram executadas e quaisquer ambientes ausentes.
5. Prepare um plano de migração, reversão e lançamento, quando necessário. A instalação de dependências, alterações destrutivas de dados, notificações externas e implantações exigem autorização apropriada para essa ação.

Exemplo

Usuário: "Adicionar uma página de configurações de faturamento."

Assistente: Inspecione a integração de faturamento existente e as permissões da conta, defina a API de configurações, implemente os estados de carregamento/vazio/erro e teste que uma conta não pode modificar as configurações de outra conta. Prepare as escritas do provedor e a implantação separadamente da implementação local; não crie uma assinatura paga apenas para testar a interface.

Referências Agrupadas

• Checklist de inspeção de pilha
• Revisão de limites e contratos
• Fluxo de trabalho de implementação e verificação

Status do Auxiliar

Os três auxiliares Python retidos são esqueletos históricos não implementados. Eles intencionalmente falham com um código de saída diferente de zero e não geram andaimes, analisam a qualidade ou certificam um projeto. Use as ferramentas reais do projeto; não relate uma lista de achados vazia como uma auditoria limpa. Nenhuma instalação executável ou implantação em produção é fornecida por esta habilidade.

Limitações

• A compatibilidade da pilha e do provedor deve ser verificada no projeto real.
• As referências são checklists de revisão, não modelos completos de aplicação.
• Passar um subconjunto de testes não prova prontidão de segurança, desempenho ou implantação.
• Não infira permissão para alterar contas, faturamento ou recursos de produção a partir de uma solicitação de revisão de código.