# Guia de Fluxo da Sprint — Donc

> Referência para toda a equipe (@jessica, @tiago, @cassio) sobre o que fazer em cada dia da semana e para que serve cada comando da IA.

---

## Visão Geral da Sprint

| Período | Atividade |
|---------|-----------|
| Segunda (início) | Criar branches, iniciar sprint |
| Segunda a Sexta | Trabalhar nas tasks com a IA |
| Sexta (fim) | Fechar branches individuais |
| Segunda seguinte | Publicar a sprint |

---

## Segunda-feira — Início da Sprint

### 1. Dev responsável cria a branch da sprint

```bash
git checkout unificacao
git pull origin unificacao
git checkout -b sprint-{N}
git push -u origin sprint-{N}
```

### 2. Cada dev cria sua branch individual

```bash
git checkout sprint-{N}
git pull origin sprint-{N}
git checkout -b sprint-{N}-{dev}   # ex: sprint-15-jessica
git push -u origin sprint-{N}-{dev}
```

> **Ou:** digitar `inicio-sprint` — a IA faz tudo acima automaticamente, inclusive verificando se `sprint-{N}` já existe e perguntando se deve criar caso não exista.

---

## Segunda a Sexta — Trabalho Diário

### Início de cada dia

```bash
git fetch origin
git rebase origin/sprint-{N}
```

> Mantém sua branch individual atualizada com o que os outros devs pushararam.

### Fluxo com a IA

1. Dev descreve o bug ou feature
2. IA analisa o código e implementa
3. Dev testa
4. Dev digita **`resume task`** → IA documenta e pergunta se pode commitar
5. Dev confirma → IA faz commit + push
6. Próxima task → volta ao passo 1

### Comandos disponíveis durante o trabalho

| Comando | O que faz |
|---------|-----------|
| `nova-task` | Registra uma nova task no backlog, analisa o código e gera o resumo para o Asana |
| `resume task` | Documenta o que foi feito, marca a task como concluída e faz commit + push |
| `fix-task` | Gera apenas o resumo formatado para o Asana (sem implementar) |
| `status-sprint` | Mostra tasks concluídas e pendentes da sprint atual (e urgência, se houver) |

---

## Urgências durante a Sprint

Quando surge um bug crítico que precisa ir para produção antes do fim da sprint:

| Comando | O que faz |
|---------|-----------|
| `inicio-urgencia` | Cria branch `hot-{N}-{dev}` e worktree paralela em `../hot{N}` |
| `nova-task` | Durante a urgência, opera na pasta `../hot{N}` |
| `resume task` | Durante a urgência, commita na branch `hot-{N}-{dev}` |
| `fim-urgencia` | Encerra a urgência — próximas tasks voltam para `sprint-{N}-{dev}` |

> O merge de `hot-{N}-{dev}` → `sprint-{N}` acontece no `fim-sprint`, não no `fim-urgencia`.

---

## Sexta-feira — Fim da Sprint

Cada dev mergeia sua branch individual na sprint (apenas o que está pronto e testado):

```bash
git checkout sprint-{N}
git pull origin sprint-{N}
git merge sprint-{N}-{dev}
git push origin sprint-{N}
```

> **Ou:** digitar `fim-sprint` — a IA faz o merge, pergunta se inclui a branch de urgência, e faz o push.

Feature incompleta fica na branch individual e entra na sprint seguinte.

---

## Segunda seguinte — Publicação

### Ordem obrigatória dos comandos

```
resume-merge  →  [testes]  →  publica-sprint  →  [validação]  →  publica-producao
```

### 1. `resume-merge`

Consolida os arquivos de todos os devs e gera a documentação da sprint:
- `docs/sprints/sprint-{N}.md` — lista de tasks por dev
- `docs/sprints/sprint-{N}-release.md` — release notes + guia de QA + versões

Também pergunta se inclui branches de urgência (`hot-{N}-*`) de algum dev.

> **Deve ser executado ANTES do `publica-sprint`.**

### 2. Publicar em Teste

Fazer o deploy manual nos ambientes de teste para validação interna (Thaisi e Thomas):

| Projeto | Ambiente |
|---------|----------|
| Admin | `admin.donc.com.br` |
| DoncMobile.API | `apimobile.teste.donc.com.br` |
| WebHubDonc | `webhub.donc.com.br` |
| App (se novo) | APK com `BaseUrl = https://apimobile.teste.donc.com.br` → Drive |

### 3. Publicar em Homolog (se necessário)

| Projeto | Ambiente |
|---------|----------|
| App | APK com `BaseUrl = https://apimobile.homolog.donc.com.br` → Drive |

### 4. `publica-sprint`

Mergeia `sprint-{N}` → `unificacao` e faz push:
- Se houver mudanças no app: pergunta sobre bump de versão antes do push
- O push dispara o GitHub Actions → build AAB → Play Store Closed Testing (Alpha)
- Atualiza `docs/versoes.md` com as novas versões

> **Pré-requisito:** `resume-merge` deve ter sido executado antes.

### 5. `publica-producao`

Após validação no Closed Testing (Alpha):
- Cria a tag `v{versao}` e faz push
- GitHub Actions baixa o AAB do Alpha (mesmo binário) e envia para produção
- Todos os usuários recebem a atualização
- Lembrar de atualizar tabela `ContratoSaas` no banco após aprovação do Google

---

## Fluxo Completo Resumido

```
SEGUNDA (início)
  └── inicio-sprint
        └── cria sprint-{N} (se não existir)
        └── cria sprint-{N}-{dev}
        └── cria docs/sprints/sprint-{N}-{dev}.md

SEG A SEX (trabalho)
  └── git rebase origin/sprint-{N}   ← todo dia antes de começar
  └── nova-task → implementar → resume task → commit/push
  └── (urgência) inicio-urgencia → tasks → fim-urgencia

SEXTA (fim)
  └── fim-sprint
        └── merge sprint-{N}-{dev} → sprint-{N}
        └── merge hot-{N}-{dev} → sprint-{N} (se houver urgência)

SEGUNDA (publicação)
  └── resume-merge          ← gera sprint-{N}.md + sprint-{N}-release.md
  └── [deploy em teste]
  └── [aprovação]
  └── publica-sprint        ← merge sprint-{N} → unificacao + push + bump versão app
  └── [validação Alpha]
  └── publica-producao      ← tag + Play Store production
```

---

## Dicas Importantes

- **Nunca trabalhe direto na `sprint-{N}` ou `unificacao`** — sempre na sua branch individual
- **Rebase todo dia** para evitar conflitos acumulados
- **`resume task` ao fim de cada sessão** — não acumule tasks sem documentar
- **`resume-merge` antes do `publica-sprint`** — obrigatório para incluir a documentação no merge
- **Urgências vão para `hot-{N}-{dev}`**, nunca diretamente na sprint