Como trabalhamos

📹 Vídeo: Fluxo completo de uma demanda

Em breve — será gravado na sua primeira semana.

O fluxo obrigatório

Toda mudança — feature, bug, melhoria ou infra — percorre sempre este caminho:

mermaid

flowchart TD
    A([💬 Ideia ou bug reportado]) --> B
    B[Abrir GitHub Issue\nno repo relevante] --> C
    C[Issue adicionada ao\nProduct Backlog automaticamente] --> D
    D[Escrever PAV\nPlano de Ação Vigiado] --> E
    E{Usuário aprova\no PAV?} -->|APROVADO| F
    E -->|Não| D
    F[Criar branch\nfeature/N-descricao] --> G
    G[Implementar + testes] --> H
    H[Abrir PR com\nCloses #N no body] --> I
    I[CI passa ✅] --> J
    J[Merge para staging] --> K
    K[Merge para main\nsync automático] --> L
    L([✅ Issue fechada automaticamente])

    style A fill:#f0f4f8,stroke:#ccc
    style L fill:#d4edda,stroke:#28a745
    style E fill:#fff3cd,stroke:#ffc107

Regra de ouro

Sem Issue = sem PAV. Sem PAV aprovado = sem código.

Demandas que chegam por conversa, Slack ou e-mail precisam virar Issue antes de qualquer ação.

O que é um PAV?

Plano de Ação Vigiado — um documento que você preenche antes de escrever qualquer código, respondendo 3 perguntas obrigatórias:

Pergunta	Como responder
O que está acontecendo de fato?	Cole o trecho de código, log de erro ou output de comando que prova o problema. Nunca "acredito que..."
Quais componentes são afetados?	Liste cada repo, endpoint e tabela de banco que pode ser impactado
Qual é o menor conjunto de mudanças?	Descreva a solução mínima. Se tocar mais de 3 arquivos, questione se não há algo mais cirúrgico

→ Ver template PAV completo

Estratégia de branches

mermaid

gitGraph
   commit id: "main"
   branch staging
   checkout staging
   commit id: "staging base"
   branch feature/123-minha-feature
   checkout feature/123-minha-feature
   commit id: "implementação"
   commit id: "testes"
   checkout staging
   merge feature/123-minha-feature id: "PR → staging"
   checkout main
   merge staging id: "PR → main"

Regras:

feature/* → PR para staging (nunca direto para main)
staging → PR para main (automático após merge em staging)
Nunca push direto em main ou staging

Os 7 Gates de qualidade

Toda execução passa por estes gates obrigatórios. Não são sugestões.

Gate	Quando	O quê
Gate 1	Início de sessão	Consultar o status atual do projeto
Gate 1.5	Antes de qualquer trabalho	Criar Issue — sem Issue, não existe PAV
Gate 2	Antes de qualquer código	PAV aprovado com análise cross-repo
Gate 3	Durante execução longa	Reler o PAV a cada 5 interações
Gate 4	Antes do commit	Testes passando, zero mocks internos
Gate 5	Antes do push	`git diff --stat` — nada fora do Scope Fence
Gate 6	Sempre	Branch `feature/*` → staging → main

→ Ver todos os gates em detalhe

Premissas invioláveis

Premissa	Regra
Legado Intocável	Nunca altere `bankeiro-ib` ou `bankeiro-backoffice`
Banco Imutável	Read-only exceto tabela `device`. Zero migrations
Zero Credenciais	Tudo no AWS Secrets Manager
API First	Regras de negócio vivem exclusivamente na API
Compilou ≠ Funciona	Teste funcional real obrigatório antes de declarar sucesso

Como trabalhamos ​

O fluxo obrigatório ​

O que é um PAV? ​

Estratégia de branches ​