arquitetura.md

@@ -50,22 +50,23 @@ Os AGES III se comprometem a revisar os PRs o mais rápido possível, garantindo
 Foram definidas algumas regras usadas durante o processo de code review dos PRs abertos nos repositórios:
 
 - _app_:
-    - a funcionalidade desenvolvida deve funcionar conforme os critérios de aceitação definidos na especificação da user story relacionada, _obrigatoriamente_ em Android e _preferencialmente_ em iOS;
-    - a interface desenvolvida está em conformidade com as telas desenvolvidas no Figma (quando a task é relacionada a interface);
-    - a interface desenvolvida deve funcionar corretamente nos tamanhos de tela suportados pela aplicação (quando a task é relacionada a interface);
-    - o PR deve implementar _preferencialmente_ apenas uma task, e _obrigatoriamente_ apenas tasks da mesma user story;
-    - a adição de novas dependências deve ser previamente validada pelos AGES III;
-    - o código desenvolvido deve conformar com as regras de linter estabelecidas (presentes no repositório _app_);
-    - o código desenvolvido deve possuir documentação apropriada.
+    - funciona obrigatoriamente em Android, preferencialmente em iOS;
+    - interface funciona nos tamanhos de tela suportados;
+    - interface segue especificação no Figma;
+    - conforme critérios de aceitação para a tarefa;
+    - passa nos testes funcionais definidos para a tarefa/story;
+    - documentação atualizada;
+    - código dentro dos padrões;
+    - código sem warnings ou erros de linter.
 
 - _api_:
-    - a funcionalidade (rota) desenvolvida deve funcionar conforme contrato APP-API definido (formato dos requests e responses, pré- e pós-condições); se o contrato APP-API for modificado, a documentação no Postman deve estar atualizada;
-    - a funcionalidade deve estar coberta por testes de unidade e integração, com pelo menos 50% de cobertura;
-    - a funcionalidade deve seguir a arquitetura e projeto documentados;
-    - o PR deve implementar _preferencialmente_ apenas uma task, e _obrigatoriamente_ apenas tasks da mesma user story;
-    - a adição de novas dependências deve ser previamente validada pelos AGES III;
-    - o código desenvolvido deve conformar com as regras de linter estabelecidas (presentes no repositório _app_);
-    - o código desenvolvido deve possuir documentação apropriada.
+    - funciona conforme especificação no Postman;
+    - possui testes de unidade associados;
+    - mantém cobertura de pelo menos 50%;
+    - dependências externas adicionadas aprovadas pelos AGES III;
+    - documentação atualizada;
+    - código dentro dos padrões;
+    - código sem warnings ou erros de linter.
 
 Essas regras foram adicionadas como template de PR em cada projeto.
 
@@ -83,7 +84,6 @@ funcional)
 * [ ]  Documentação sobre aplicação de
 Design do Projeto
 * [ ]  Análise dos principios SOLID
-* [ ]  Plano de code review
 
 Devem ser apresentados das seguintes formas: