Squad Front

Appearance

Guia de RFC (Request for Comments) ​

O processo de RFC (Request for Comments) é o mecanismo oficial para propor, discutir e documentar mudanças significativas na arquitetura ou em padrões técnicos do projeto. Em um ecossistema de saúde que atende 100 milhões de pessoas, decisões técnicas precisam ser deliberadas e registradas para garantir a continuidade e o alinhamento entre múltiplos times.

Objetivo ​

  • Transparência: Permitir que todos os desenvolvedores entendam o "porquê" de uma decisão.
  • Colaboração: Coletar feedback de diferentes perspectivas (performance, segurança, experiência do usuário) antes da implementação.
  • Registro Histórico: Servir como documentação viva para novos membros do time.
  • Consistência: Garantir que o sistema de 26 estados evolua de forma coesa.

Quando abrir uma RFC? ​

Nem toda mudança precisa de uma RFC. Ela é necessária quando a proposta:

  1. Introduz uma nova biblioteca ou framework (ex: novo adaptador de vídeo).
  2. Altera um padrão arquitetural existente (ex: mudar como os Domain Events são despachados).
  3. Cria um novo módulo transversal de larga escala (ex: Telemetria Nacional).
  4. Afeta o fluxo de trabalho de todos os times.

Estrutura Sugerida do Documento ​

Ao criar uma nova RFC (em docs/rfcs/), utilize os seguintes tópicos:

1. Resumo (Abstract) ​

Uma explicação breve (1 parágrafo) do que é a proposta em linguagem acessível.

2. Motivação (Motivation) ​

Qual problema estamos tentando resolver? Por que a solução atual não é mais suficiente? Use dados ou exemplos de gargalos encontrados na escala de 100M.

3. Proposta Técnica (Detailed Design) ​

Explicação técnica detalhada:

  • Novas APIs ou interfaces.
  • Mudanças em packages/core ou packages/contracts.
  • Diagramas ASCII demonstrando o fluxo.

4. Impacto e Riscos (Drawbacks & Risks) ​

  • Como isso afeta a performance em dispositivos de baixo custo?
  • Existe risco de quebra de compatibilidade (Breaking Changes)?
  • Como isso afeta o isolamento de módulos?

5. Alternativas Consideradas (Alternatives) ​

Quais outras hipóteses técnicas foram avaliadas e por que foram descartadas? (Similar ao nosso documento de Hipóteses Técnicas).

6. Plano de Rollout (Adoption Plan) ​

Como essa mudança será implementada? Será um "Big Bang" ou uma migração gradual módulo por módulo?

Ciclo de Vida de uma RFC ​

  1. Draft: O autor cria o documento e compartilha com o time para feedback inicial.
  2. Review: Discussão técnica via comentários ou reuniões de arquitetura.
  3. Approved/Rejected: A decisão é tomada com base no consenso técnico e alinhamento com os Fundamentos Teóricos.
  4. Implemented: A proposta é codificada e integrada ao repositório.
  5. Deprecated: Se a tecnologia for substituída no futuro.

Exemplo: RFC de Nova Estratégia de Cache Regional ​

text
RFC: #001 - Cache Regional em CDNs
Autor: Arquiteto Senior
Status: Draft
Data: 2026-02-19

1. Resumo: Proposta de utilizar Edge Computing para cachear dados de vacinação por estado.
2. Motivação: Reduzir a latência para usuários no Norte e Nordeste.
3. Proposta: Implementar um cabeçalho de cache específico na camada de Core/API...

Conclusão ​

O uso de RFCs garante que nossa arquitetura não se torne um "acidente geológico", mas sim uma construção planejada e resiliente, capaz de suportar a magnitude de um sistema de saúde nacional.