Metodologia de Evolução & Release Train (2+1)

1. Arquitetura do Release Train (Ciclo 2+1: 5 a 6 Semanas)

O ciclo de vida de uma release de evolução no e-SUS AF é estruturado em uma esteira temporal sincronizada de 5 a 6 semanas, dividida em três fases complementares:

1. Sprint 1 — Desenvolvimento (2 semanas): Foco na implementação do primeiro lote de Histórias de Usuário (HUs) priorizadas no Backlog do Produto, acompanhadas de seus respectivos testes automatizados e revisões de código.
2. Sprint 2 — Desenvolvimento (2 semanas): Foco na conclusão do lote de funcionalidades do ciclo, débitos técnicos prioritários e integração contínua na branch main. Ao final da Sprint 2, ocorre o Code Freeze e o corte da branch de release (release/vX.Y.0).
3. Sprint 3 — Estabilização & Homologação (1 a 2 semanas): Fase dedicada à homologação negocial por PO/Negócio, testes intensivos de regressão pelo time de QA, correção cirúrgica de defeitos encontrados na branch de release e preparação técnica para o próximo ciclo de desenvolvimento.

Macrofluxo do Release Train

flowchart TD
    subgraph S1["Sprint 1: Desenvolvimento (2 Semanas)"]
        P1["Sprint Planning 1
(Seleção do Backlog com DoR)"] --> D1["Desenvolvimento de Features & Débitos Técnicos"]
        D1 --> T1["Testes Automatizados
(Unitários & E2E)"]
        T1 --> CR1["Code Review por Pares & Tech Lead"]
        CR1 --> M1["Merge na main via PR (--no-ff)"]
    end

    subgraph S2["Sprint 2: Desenvolvimento (2 Semanas)"]
        P2["Sprint Planning 2
(Seleção do Backlog com DoR)"] --> D2["Desenvolvimento de Features & Débitos Técnicos"]
        D2 --> T2["Testes Automatizados
(Unitários & E2E)"]
        T2 --> CR2["Code Review por Pares & Tech Lead"]
        CR2 --> M2["Merge na main via PR (--no-ff)"]
        M2 --> FREEZE["Code Freeze na main
Corte da branch release/vX.Y.0"]
    end

    subgraph S3["Sprint 3: Estabilização & Homologação (1 a 2 Semanas)"]
        FREEZE --> HOMOLOG["Homologação Funcional PO/Negócio
& Testes de Regressão por QA"]
        HOMOLOG --> Q_BUG{"Bugs Encontrados?"}

        Q_BUG -->|"Sim (Sev 1 / Sev 2)"| DECISAO{"Correção viável
no prazo?"}
        DECISAO -->|"Sim"| FIX["Correção de Bugs direto na branch release/vX.Y.0"]
        FIX --> HOMOLOG
        DECISAO -->|"Não (Risco de Prazo)"| DROP["Feature Drop Policy
Reversão da Feature Instável"]
        DROP --> HOMOLOG

        Q_BUG -->|"Não / Aprovado"| DOD_REL["Validação do Definition of Done (DoD) de Release"]

        subgraph Dev_Paralelo["Atuação Paralela dos Desenvolvedores na Estabilização"]
            direction TB
            D_PAR1["• Refinamento Técnico & BDD do Próximo Ciclo"]
            D_PAR2["• Pagamento de Débitos Técnicos & Refatoração"]
            D_PAR3["• Spikes Arquiteturais & Otimizações"]
            D_PAR4["• Sincronização Anti-Regressão de Hotfixes da main"]
        end
    end

    DOD_REL --> MERGE_FINAL["Merge da release na main + Tag Oficial vX.Y.0"]
    MERGE_FINAL --> PROD["Deploy em Produção (Ambiente Oficial)"]
    PROD --> CEREM_END["Review da Release & Retrospectiva do Ciclo (4L)"]

2. Dinâmica das Sprints de Desenvolvimento (S1 e S2) vs. Sprint de Estabilização (S3)

2.1. Sprints de Desenvolvimento (S1 e S2 — 4 Semanas)

Nas duas primeiras Sprints do ciclo, a equipe de engenharia atua na construção direta dos itens compromissados no Planejamento:

• Escopo Permitido:
  • Histórias de Usuário refinadas que atendam 100% ao Definition of Ready (DoR);
  • Débitos técnicos, refatorações e melhorias de performance priorizadas junto à liderança técnica;
  • Defeitos leves ou moderados (Sev 3 e Sev 4) inseridos no planejamento da Sprint.
• Ciclo de Trabalho por Item:
  1. Criação de branch temporária a partir da main no formato feature/<issue>-<descricao>;
  2. Desenvolvimento da funcionalidade orientado pelo modelo BDD estabelecido na história;
  3. Construção concomitante de testes unitários e testes de integração/E2E;
  4. Abertura de Pull Request (PR) direcionado à main contendo checklist técnico preenchido e evidências de testes;
  5. Revisão de código obrigatória por pares e aprovação formal do Líder Técnico;
  6. Execução com sucesso da esteira de Integração Contínua (CI);
  7. Merge na branch main utilizando --no-ff.

2.2. Sprint de Estabilização & Homologação (S3 — 1 a 2 Semanas)

A Sprint de Estabilização é a salvaguarda de qualidade que impede que código instável alcance o ambiente de produção:

• Marco Inicial — Code Freeze:
  • Ao término da Sprint 2, a branch main entra em congelamento de novas features para a release;
  • É criada a branch temporária release/vX.Y.0 a partir da main;
  • O ambiente de Homologação/Staging é atualizado exclusivamente com a versão da branch de release.
• Frentes de Atuação na Estabilização:
  1. Homologação Negocial (Equipe de Negócio / PO):
     • Execução de roteiros de validação funcional baseados nos cenários de negócio;
     • Validação de conformidade regulatória, regras de cálculo e fluxos assistenciais;
     • Emissão formal de aceite funcional (Sign-off) ou abertura de defeitos na branch de release.
  2. Testes de Regressão e Validação Técnica (QA):
     • Execução da bateria completa de testes de regressão (automatizados e manuais exploratórios);
     • Validação de fluxos críticos: dispensação de medicamentos, controle de estoque, migrações de banco e integrações RNDS;
     • Testes de carga e estresse em módulos de alta volumetria.
  3. Correções de Defeitos de Release (Desenvolvedores alocados em correções):
     • Tratamento de bugs Sev 1 e Sev 2 identificados por PO ou QA durante a estabilização;
     • Commits de correção realizados diretamente na branch release/vX.Y.0;
     • Revalidação imediata pelo QA/PO a cada novo build de release candidate.
  4. Atividades Paralelas dos Desenvolvedores Livres:
     • Refinamento Técnico e BDD: Apoio ao PO e Negócio na especificação técnica e elaboração de critérios BDD para as histórias do próximo ciclo;
     • Pagamento de Débito Técnico: Refatoração interna de componentes legados, atualização de dependências e eliminação de code smells;
     • Spikes Arquiteturais: Provas de conceito para novas tecnologias, arquiteturas de microsserviços ou otimizações de banco;
     • Sincronização Anti-Regressão: Vigilância e replicação (cherry-pick) de eventuais correções emergenciais publicadas na main pela Sustentação.

3. Política de Descarte de Funcionalidades (Feature Drop Policy)

flowchart TD
    BUG_DETECT["Defeito Crítico / Pendência Detectada na Estabilização"] --> AVALIACAO{"Avaliando Viabilidade Técnica & Prazo"}

    AVALIACAO -->|"Correção Simples & Segura
(Tempo <= 24h)"| FIX_REL["Dev aplica Fix cirúrgico na branch release/vX.Y.0"]
    FIX_REL --> REVALIDA["Revalidação por QA e Aceite PO"]
    REVALIDA -->|"Aprovado"| MANTEM["Funcionalidade Mantida no Trem"]

    AVALIACAO -->|"Correção Complexa / Risco Alto
ou Sem Homologação até marco T-48h"| REVERT["Aplicação da Feature Drop Policy"]
    REVERT --> GIT_REV["1. Executar git revert do PR na branch release/vX.Y.0"]
    GIT_REV --> TEST_REG["2. Reexecutar testes de regressão na release"]
    TEST_REG --> BACKLOG["3. PO retorna História ao Backlog para próximo ciclo"]
    BACKLOG --> NOTA_REL["4. Registrar descarte na ata e Release Notes"]

3.1. Critérios Objetivos para Descarte de Feature

3.2. Procedimento Operacional de Reversão

1. Reversão no Git:

   # Na branch de release ativa
   git checkout release/vX.Y.0
   git pull origin release/vX.Y.0
   git revert -m 1 <hash-do-merge-commit> -m "revert(release): drop feature #102 due to stability issues"
   git push origin release/vX.Y.0
   

2. Reexecução dos Testes: A esteira de CI/CD é acionada e o time de QA reexecuta a suíte de regressão na branch de release para confirmar que a remoção restaurou a estabilidade.
3. Gestão do Backlog: O PO atualiza o status da história no Jira/GitLab, move o item de volta para o Product Backlog e registra os apontamentos técnicos para novo refinamento e inclusão em ciclo futuro.
4. Comunicação: O Líder Técnico registra formalmente o descarte no relatório da Sprint e notifica os stakeholders.

4. Cerimônias e Ritos Ágeis do Ciclo

A frente de Evolução adota um conjunto estruturado de cerimônias ágeis para garantir sincronização contínua, governança e melhoria iterativa:

4.1. Sprint Planning (Planejamento da Sprint)

• Entrada: Backlog de Produto priorizado pelo PO, contendo histórias que cumprem integralmente o Definition of Ready (DoR).
• Dinâmica:
  1. O PO apresenta o objetivo de negócio da Sprint e as histórias candidatas;
  2. O time técnico analisa a viabilidade, dependências arquiteturais e define a estratégia de implementação;
  3. Estimativa com Planning Poker: O time pontua as tarefas utilizando a escala de complexidade/tempo de referência:
     • 1 ponto: Tarefa trivial (até 1 hora);
     • 2 pontos: Tarefa simples (um período — manhã ou tarde);
     • 3 pontos: Tarefa média (um dia de trabalho);
     • 5 pontos: Tarefa complexa (dois dias de trabalho);
     • 8 pontos: Tarefa de alta complexidade (uma semana de esforço); itens com 8 ou mais pontos devem ser avaliados para divisão em subtarefas menores.
  4. O time compromissa o Sprint Backlog e registra a meta da Sprint.

4.2. Daily Scrum (Reunião Diária)

• Horário Padronizado: Diariamente, das 9h00 às 9h15.
• Dinâmica das Três Perguntas:
  1. O que eu realizei ontem que ajudou o time a atingir a meta da Sprint?
  2. O que eu vou realizar hoje para ajudar o time a atingir a meta da Sprint?
  3. Existe algum impedimento bloqueando meu progresso ou o de outro colega?
• Regras de Conduta:
  • Reunião objetiva e pontual (máximo 15 minutos);
  • Discussões técnicas aprofundadas ou debates de arquitetura são direcionados para sessões paralelas (pós-daily) entre os envolvidos;
  • Impedimentos levantados são imediatamente tratados pelo Líder Técnico ou PO.

4.3. Sessão de Refinamento Técnico Contínuo (Backlog Refinement)

• Objetivo: Garantir que as histórias do ciclo subsequente alcancem maturidade plena antes da reunião de planejamento.
• Atividades Executadas:
  • Quebra de épicos em Histórias de Usuário atômicas e independentes;
  • Escrita e validação dos cenários de teste em formato BDD (Dado / Quando / Então / E / Mas);
  • Especificação do Modelo de Dados relacional, regras de validação e restrições de integridade;
  • Validação de protótipos de tela e fluxos de navegação junto ao time de UX/Negócio;
  • Verificação detalhada de todos os itens do Definition of Ready (DoR).

4.4. Review da Release (Revisão da Release)

• Momento: No encerramento da Sprint de Estabilização, antecedendo o deploy em produção.
• Pauta:
  • Apresentação dos marcos atingidos no ciclo de release;
  • Demonstração funcional em ambiente espelho das histórias aprovadas e homologadas;
  • Apresentação das métricas de qualidade da release (cobertura de testes, bugs resolvidos, performance);
  • Comunicação de eventuais funcionalidades descartadas via Feature Drop Policy;
  • Validação formal do Sign-off de publicação com os stakeholders.

4.5. Retrospectiva do Ciclo (Técnica 4L)

A Retrospectiva ocorre ao término de cada ciclo completo de release (5 a 6 semanas) e utiliza a técnica estruturada 4L (Liked, Lacked, Learned, Longed For):

quadrantChart
    title Retrospectiva 4L - Avaliação do Ciclo de Release
    x-axis "Foco no Passado (O que aconteceu)" --> "Foco no Futuro (O que faremos)"
    y-axis "Pontos de Atenção / Negativos" --> "Pontos Fortes / Positivos"
    quadrant-1 "4. Longed For (O que Desejamos)"
    quadrant-2 "1. Liked (O que Amamos)"
    quadrant-3 "2. Lacked (O que nos Faltou)"
    quadrant-4 "3. Learned (O que Aprendemos)"

• 1. Liked (O que amamos?):
  • Quais foram os pontos fortes e práticas de sucesso do ciclo?
  • O que funcionou com excelência na engenharia, homologação ou comunicação?
  • Momentos de celebração e conquistas técnicas/negociais da equipe.
• 2. Lacked (O que nos faltou?):
  • Quais ferramentas, ambientes, documentações ou alinhamentos fizeram falta?
  • Onde ocorreram gargalos no fluxo de desenvolvimento, testes ou code review?
  • Que impedimentos recorreram durante as Sprints?
• 3. Learned (O que aprendemos?):
  • Quais lições técnicas e de negócio tiramos dos problemas enfrentados?
  • Que novas tecnologias, padrões arquiteturais ou regras do SUS assimilamos?
  • Como podemos compartilhar esse conhecimento com o restante do time?
• 4. Longed For (O que desejamos para os próximos ciclos?):
  • Quais melhorias de processo queremos experimentar no próximo trem?
  • Que automações, testes ou refatorações desejamos priorizar?
  • Quais são as aspirações de qualidade e colaboração do time?

5. Modelo Padronizado de História de Usuário (HU)

Toda demanda de evolução deve ser registrada no Jira/GitLab utilizando o template padronizado abaixo:

# [HU-XXX] [Título Claro e Sucinto da Funcionalidade]

**Épico / Módulo**: [Ex: Módulo de Dispensação / Integração RNDS / Gestão de Estoque]
**Prioridade**: [Alta / Média / Baixa]
**Product Owner (PO)**: [Nome do PO]
**Tech Lead**: [Nome do Líder Técnico]
**Desenvolvedor(es)**: [Nome do Desenvolvedor]
**QA Responsável**: [Nome do QA]

---

### 1. Narrativa de Usuário
* **Como** [papel do usuário no SUS: ex. Farmacêutico Municipal, Operador de Almoxarifado, Gestor de Saúde]
* **Eu quero** [funcionalidade ou ação que desejo realizar no e-SUS AF]
* **Para que** [benefício de negócio, justificativa assistencial ou conformidade regulatória]

---

### 2. Contexto e Regras de Negócio
- **RN01**: [Descrição da regra de negócio fundamental. Ex: Apenas usuários com perfil Farmacêutico podem autorizar dispensações de medicamentos controlados da Portaria 344/98].
- **RN02**: [Ex: O sistema não deve permitir saída de medicamentos com lote vencido ou quantidade superior ao saldo físico em estoque].
- **RN03**: [Ex: Toda dispensação deve registrar auditoria com CPF do operador, data/hora e identificador do estabelecimento de saúde].

---

### 3. Critérios de Aceite (BDD — Behavior-Driven Development)

> **Diretrizes de Escrita BDD**:
> * **Dado (Given)**: Pré-condição ou estado inicial do sistema (escrito no passado ou particípio);
> * **Quando (When)**: Ação executada pelo usuário ou evento de sistema (escrito no presente);
> * **Então (Then)**: Resultado esperado ou reação verificável do sistema (escrito no futuro do presente);
> * **E (And)**: Conexão de passos complementares de pré-condição, ação ou validação;
> * **Mas (But)**: Validação de restrição ou cenário negativo de exceção.
>
> *Regra de Ouro*: Cada História de Usuário deve conter no **máximo 5 cenários BDD**. Histórias com mais de 5 cenários devem ser divididas em histórias menores.

#### Cenário 1: [Cenário Principal de Sucesso / Caminho Feliz]
* **Dado** que o farmacêutico está autenticado no sistema com perfil de dispensação ativo
* **E** existe saldo disponível de 50 unidades do medicamento "Amoxicilina 500mg" no estoque do estabelecimento
* **Quando** o farmacêutico informa a receita válida e confirma a dispensação de 20 unidades para o paciente
* **Então** o sistema deve registrar a dispensação com sucesso
* **E** o saldo do medicamento no estoque deve ser atualizado para 30 unidades
* **E** um comprovante de dispensação deve ser gerado com identificador único.

#### Cenário 2: [Cenário Alternativo / Tentativa de Saída com Saldo Insuficiente]
* **Dado** que o saldo disponível do medicamento "Paracetamol 500mg" em estoque é de 5 unidades
* **Quando** o operador solicita a dispensação de 10 unidades do medicamento
* **Então** o sistema deve bloquear a operação
* **E** deve exibir a mensagem de alerta: "Saldo em estoque insuficiente para atender à quantidade solicitada (Disponível: 5 unidades)."
* **Mas** nenhuma alteração de saldo ou registro de dispensação deve ser persistida no banco de dados.

#### Cenário 3: [Cenário de Exceção / Tentativa de Dispensação de Medicamento com Validade Vencida]
* **Dado** que o lote "LOTE-2023-A" do medicamento possui data de validade anterior à data atual do sistema
* **Quando** o operador seleciona este lote para inclusão na dispensação
* **Então** o sistema deve impedir a seleção do lote vencido
* **E** deve exibir a notificação de erro: "O lote selecionado está vencido e não pode ser dispensado."

---

### 4. Modelo de Dados e Dicionário de Atributos

| Nível | Atributo | Descrição | Cardinalidade | Tipo de Dado | Tamanho | Formato | Obrigatoriedade | Regra de Validação / Observação |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| **Entidade** | `id_dispensacao` | Chave primária da dispensação | 1..1 | BigInt | 19 | Numérico | Obrigatório | Auto-incremento / Chave Primária |
| **Entidade** | `codigo_receita` | Código identificador da prescrição | 1..1 | Varchar | 50 | Alfanumérico | Obrigatório | Formato `REC-[0-9]{8}` |
| **Entidade** | `data_dispensacao` | Data e hora exata da operação | 1..1 | Timestamp | - | ISO-8601 | Obrigatório | Valor padrão `CURRENT_TIMESTAMP` |
| **Item** | `id_medicamento` | Identificador do medicamento | 1..1 | BigInt | 19 | Numérico | Obrigatório | Chave estrangeira para `tb_medicamento` |
| **Item** | `numero_lote` | Lote físico do medicamento | 1..1 | Varchar | 30 | Alfanumérico | Obrigatório | Deve existir no estoque ativo |
| **Item** | `quantidade` | Quantidade dispensada | 1..1 | Integer | 6 | Numérico | Obrigatório | Valor inteiro maior que zero (`> 0`) |
| **Auditoria**| `cpf_operador` | CPF do profissional responsável | 1..1 | Varchar | 11 | Numérico | Obrigatório | Validação matemática de CPF padrão SUS |

---

### 5. Regras de Interface e Design Conceitual
- **Protótipo de Tela**: [Link para o Figma / Anexo de Wireframe];
- **Diretrizes de Layout**:
    - Utilizar os componentes padronizados do Design System do e-SUS AF;
    - Exibir mensagens de validação em linha (*inline validation*) nos campos de entrada;
    - Garantir atalhos de teclado para navegação rápida entre campos de dispensação;
    - Suportar leitores de código de barras para preenchimento automático do lote e medicamento.

---

### 6. Checklist de Tarefas Técnicas (Subtarefas)
- [ ] **[Front-end]** Implementar componentes de tela de dispensação e integração com formulário reativo;
- [ ] **[Back-end]** Desenvolver endpoints REST de validação e persistência de dispensação;
- [ ] **[Back-end]** Implementar validações de estoque concorrente com *pessimistic/optimistic locking*;
- [ ] **[Banco de Dados]** Criar script de migração Flyway com as alterações de DDL/DML;
- [ ] **[Testes Automatizados]** Criar testes unitários no back-end (cobertura dos cenários BDD 1, 2 e 3);
- [ ] **[Testes Automatizados]** Criar testes ponta a ponta (E2E) no front-end para o fluxo de dispensação;
- [ ] **[Documentação]** Atualizar especificação OpenAPI/Swagger e notas de release.

6. Definition of Ready (DoR) para Histórias de Usuário

O Definition of Ready (DoR) estabelece o critério mínimo de maturidade técnica e negocial que uma História de Usuário deve obrigatoriamente satisfazer antes de ser aceita no Sprint Planning:

flowchart LR
    BACKLOG["Backlog Bruto"] --> REFINA["Sessão de Refinamento
(PO + Negócio + Tech Lead + Devs + QA)"]
    REFINA --> CHECK_DOR{"Checklist DoR
100% Atendido?"}
    CHECK_DOR -->|"Sim"| READY["História READY
(Apta para Sprint Planning)"]
    CHECK_DOR -->|"Não"| PENDENTE["Pendência / Devolução
(Permanece no Backlog para ajustes)"]

Checklist Oficial do DoR

• [ ] 1. Alinhamento de Negócio Claro: O objetivo de negócio, o público-alvo no SUS e a justificativa de valor estão descritos sem ambiguidades na narrativa da história;
• [ ] 2. Critérios BDD Estruturados: Critérios de aceite especificados rigorosamente no formato Dado / Quando / Então / E / Mas, contemplando fluxo principal de sucesso, fluxos alternativos e validações de exceção (máximo de 5 cenários);
• [ ] 3. Modelo de Dados Definido: Tabela de modelo de dados preenchida com especificação de atributos, tipos, cardinalidades, restrições de integridade e regras de validação;
• [ ] 4. Design e Telas Disponíveis: Protótipos de tela, fluxogramas de navegação ou diretrizes visuais anexados e validados para histórias que envolvam interface de usuário;
• [ ] 5. Dependências Técnicas Mapeadas e Resolvidas: Dependências de infraestrutura, serviços externos, migrações prévias de banco ou APIs de terceiros (ex.: RNDS) estão identificadas, testadas e desbloqueadas;
• [ ] 6. Estimativa de Esforço Validada: A história foi discutida com o time técnico e recebeu pontuação de esforço consensual via Planning Poker;
• [ ] 7. Tamanho Adequado (Invest): A história é atômica e factível de ser totalmente desenvolvida, testada e revisada dentro de uma única Sprint de Desenvolvimento.

7. Definition of Done (DoD) de Engenharia e Release

O e-SUS AF adota dois níveis rigorosos de Definition of Done (DoD): o DoD Técnico (aplicado item a item durante as Sprints de Desenvolvimento) e o DoD de Release (aplicado ao final da Sprint de Estabilização para publicação oficial da versão).

7.1. DoD Técnico (Sprint de Desenvolvimento — Por História / PR)

Para que uma história de usuário ou tarefa de desenvolvimento seja considerada concluída na Sprint de Dev e receba merge na branch main:

• [ ] Padrões de Código: O código-fonte foi desenvolvido em conformidade com as diretrizes de arquitetura, Clean Code, boas práticas REST e padrões de front-end/back-end do projeto;
• [ ] Cobertura de Testes Automatizados:
  • Testes unitários implementados e cobrindo todas as novas regras de negócio;
  • Testes de integração/E2E cobrindo os cenários BDD especificados no DoR;
  • Cobertura de código satisfaz as metas mínimas estabelecidas pela liderança técnica;
• [ ] Pipeline de CI Verde:
  • Compilação do projeto 100% bem-sucedida;
  • Linter sem advertências ou erros impeditivos;
  • Análise estática de segurança (SonarQube/SAST) sem vulnerabilidades críticas ou altas;
• [ ] Code Review Formal:
  • Revisão realizada por no mínimo 1 desenvolvedor par;
  • Aprovação final obrigatória do Líder Técnico (Tech Lead);
  • Todos os comentários e apontamentos da revisão devidamente resolvidos;
• [ ] Integração no Git:
  • Pull Request integrado na branch main com parâmetro --no-ff;
  • Mensagem de commit estruturada no padrão Conventional Commits com referência à issue (feat(modulo): mensagem #issue).

7.2. DoD de Release (Sprint de Estabilização — Publicação da Versão)

Para que a branch temporária release/vX.Y.0 seja finalizada, integrada na main e publicada oficialmente como uma nova versão do e-SUS AF:

• [ ] Suíte Completa de Testes Automatizados: 100% dos testes unitários, de integração e ponta a ponta da suíte global executando com status de sucesso na esteira de CI;
• [ ] Aprovação de Regressão por QA: Bateria de testes de regressão manual e automatizada executada pelo time de QA em ambiente de Homologação/Staging, com aprovação formal;
• [ ] Homologação Negocial Formal (Sign-off): Todas as histórias de usuário da release homologadas e aprovadas formalmente pela Equipe de Negócio / Product Owner;
• [ ] Critério de Bugs Zero (Sev 1 e Sev 2):
  • Zero defeitos bloqueantes (Sev 1) abertos;
  • Zero defeitos graves (Sev 2) abertos;
  • Defeitos leves remanescentes (Sev 3 e Sev 4) formalmente catalogados e aceitos pelo PO para o backlog futuro;
• [ ] Aplicação da Feature Drop Policy: Todas as funcionalidades com pendências técnicas, negociais ou de estabilidade foram revertidas com sucesso da branch de release;
• [ ] Scripts de Banco de Dados Validados: Migrações de banco de dados (Flyway / scripts DDL e DML) executadas e validadas em ambiente espelho sem falhas ou inconsistências de dados;
• [ ] Documentação e Release Notes:
  • Notas de Release (Release Notes) detalhando novas features, melhorias e correções;
  • Manuais de Usuário e documentação no ManualOnBoarding devidamente atualizados;
  • Documentação de APIs (Swagger/OpenAPI) sincronizada;
• [ ] Tag Semântica Oficial no Git: Tag semântica vX.Y.0 criada na branch main e assinada digitalmente;
• [ ] Pacote de Publicação Gerado: Artefatos binários, imagens Docker e instaladores gerados, auditados e disponibilizados para deploy nos ambientes de produção do Ministério da Saúde e municípios.