arquitetura.md

@@ -5,6 +5,7 @@
 
 * [Fluxograma de funcionamento do aplicativo](#fluxograma-de-funcionamento-do-aplicativo)
 * [Git Branching Model](#git-branching-model)
+* [Code Review](#code-review)
 * [Próximos artefatos](#pr%C3%B3ximos-poss%C3%ADveis-artefatos)
 
 ## Fluxograma de funcionamento do aplicativo
@@ -40,6 +41,34 @@ Dessa forma, o fluxo usual de trabalho é o seguinte:
 7. mover o card da task no Trello para a lista _Code Review_ e avisar no Slack (canal #code-review) que a task está pronta para review;
 8. fim! 😃
 
+## Code Review
+
+Após o desenvolvimento de uma task, um _pull/merge request_ (PR) deve ser aberto com destino à branch _develop_ do repositório relativo à task: _app_ ou _api_. Todos os PRs são revisados por pelo menos dois AGES III, que se responsabilizam por garantir a qualidade do que foi desenvolvido e que os artefatos e estruturas se adequem aos padrões definidos neste documento.
+
+Os AGES III se comprometem a revisar os PRs o mais rápido possível, garantindo que PRs abertos até dois dias antes de uma entrega serão integrados (se cumprirem todas as regras do code review).
+
+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.
+
+- _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.
+
+Essas regras foram adicionadas como template de PR em cada projeto.
+
 ### Próximos possíveis artefatos:
 
 * [ ]  Segurança