Deploy

Nome do projeto:
Versão do documento:
Status: [rascunho | revisando | aprovado]
Documentos base: Docs/stack.md, Docs/architecture.md, Docs/structure.md, Docs/contract.yaml
Data de criação:
Última atualização:

Estratégia de hospedagem: [VPS | cloud provider | PaaS | serverless | híbrido]
Estratégia inicial: [ex.: integração automatizada e deploy semi-automático para prod]
Princípios operacionais:
- [ex.: previsibilidade e simplicidade]
- [ex.: baixo tempo de rollback]

Local:       Trabalho individual (execução local / variáveis locais / dependências simuladas)
Development: Validação contínua (integração inicial / testes internos)
Staging:     Sandpit pré-release, idêntico a produção (validação de release / teste smoke)
Production:  Santuário do real, blindado (estabilidade / controle de release)

Plataforma de hospedagem principal: [Ex.: Hostinger VPS, Vercel, AWS]
Modelo de hospedagem: [ex.: Múltiplos contêineres Docker]
Topologia inicial: [descrever distribuição dos serviços]
Serviços gerenciados:
- [ex.: AWS RDS PostgreSQL]
Serviços autogerenciados:
- [ex.: Redis cache na própria VPS]

Aplicação principal. CPU: [x] Memória: [x] Armazenamento: [x] Tráfego: [x] Concorrência: [x]
Banco de dados. CPU: [x] Memória: [x] Armazenamento: [x]
Serviços auxiliares (cache/fila/storage/CDN): [Definir se sim/não + tipo de plano]

Estratégia de configuração: [ex.: .env por ambiente injetado via pipeline]
Onde os segredos ficam armazenados: [ex.: GitHub Secrets e Vault, nunca localmente limpos]
Regras vitais:
1. Jamais faça log ou versionamento do arquivo contendo os segredos verdadeiros
2. Documentação não recebe tokens originais

Ferramentas: husky, lint-staged, ESLint, TypeScript compiler
Regras (Pre-commit):
- lint sem erro
- formatação leve / checagens rápidas
Regras (Pre-push ou Pull Request check):
- typechecks
- testes obrigatórios passando
Critérios Bloqueantes: build quebrado ou reprovação em CI cancelam a aprovação

main: Fonte principal, blindada contra push direto.
staging / release: Canais conectados as esteiras automatizadas.
feature/[nome], task/[TASK-001]: Fluxo ativo dos desenvolvedores.
hotfix/[nome]: Rota expressa emergencial e rastreável.

Plataforma: [ex.: GitHub Actions]
Etapas mínimas CI:
- Checkout, npm install, lint, test, build completo
Etapas mínimas CD:
- Auth no alvo, cópia artefatos, deploy (reload app/docker), validação saúde (smoke)
Gatilhos principais: Push nas branches centrais ou Pull Requests com alvo nestas branches.
Critérios de bloqueio de deploy: CI anterior falhou / Migração corrompeu.

Estratégia de versionamento: [ex.: semver simplificado v1.0.0]
Quando gerar tag: Na merge manual que representa um milestone do Docs/plan.md.
Notas de release (Changelog): [Sim, descritas dentro da Tag ou Pull Request]

Obrigatório em produção (JSON log ou padrão traceável).
Campos requeridos:
- timestamp, nível (info, warn, error)
- ambiente, serviço (frontend, daemon, api)
- reqId/correlationId
Conteúdo bloqueado para Logs: Senhas, Tokens JWT, payloads vazados brutos.

Health check obrigatório: Sim (ex.: endpoint GET /api/health-check retornando 200)
Exigência final para pós-deploy manual ou automático:
- Aplicação deve subir portas lógicas
- Nenhuma falha severa pode nascer nos primeiros 5 minutos de tracking

Estratégia de Migrate: [ex.: ORM Prisma / Alembic, roda-se apenas etapa CD, ANTES da App em si]
Seed Inicial: [Descrever, ex: seed.ts injetado nos mocks]
Backups: [Qual servidor / Quem executa / Qual periodicidade]
Regra de ouro: Evitar migração destrutiva de banco (Drop Tables sem Drop Columns faseados)

Estratégia de Rollback: [ex: Trigger GitHub Action "Revert Commit" ou Restore Container versão X]
Gatilho: App Offline por 2+ mins via Health Check pós build; quebra central no primeiro fluxo base de telas.
Plano B absoluto (contingência): [ex.: Restaurar droplet / DB backup diário 00h].

Acesso remoto restrito (SSH fechados, rede via IP bloqueada)
Princípio Mínimo de Permissões para chaves do IAM de Deploy (CD).
Logs monitorados constantemente de acesso.

Quem pode fazer deploy: [Tech Lead e Automação GitHub]
Quem responde incidentes: [Plantão e Líder devOps]

Docs/stack.md: A tecnologia exige a modelagem do runner/VPS na plataforma descrita neste doc.
Docs/architecture.md: O fluxo técnico dita quantos micro-apps e filas precisamos levantar de fato.
Docs/structure.md: Garante que os caminhos /tests /scripts batam com o job de Deploy (Seção 10).
Docs/contract.yaml: As APIs documentadas aqui garantem os endpoints validados pelo Health Check.

Para DEVs e AI:
- NÃO se logue manualmente via SSH para executar `git pull` a não ser em desespero não mapeado; utilize pipeline escrito nesta DOC.
- Nenhuma automação será aceita se o rollback falhar a etapa conceitual.

20.1 Hospedagem: [Resumo de 1 frase do cloud model]
20.2 Pipeline e Branches: [Resumo 1 frase]
20.3 Regras Críticas: Hooks prévios (Lint/Build obrigatório) evitam commits sujos.
20.4 Indefinições (temporário): [O que não sabemos de monitoria ainda e precisamos definir FASE 2]

Status atual: [aprovado]
Data: [dd/mm/aaaa]

Atue como SystemAgent.
Objetivo: criar Docs/deploy.md documentando a malha e regras de lançamento.
 
Carregue contexto base:
- Docs/stack.md
- Docs/architecture.md
- Docs/structure.md
- Templates/Full/deploy.md
 
Preencha rigorosamente as 21 seções do template Full.
Não re-junte passos nem comprima seções. Seja literal para que os DEV ops possam parametrizar o real pipeline de acordo com a Seção "10 e 15". Delimite um rollback crível baseado na Cloud do stack.md.
Atesse os gatilhos e Quality Gates corretos (Seções 8 e 13).