# Modelo do Projeto Integrador de Desenvolvimento Web

> Substitua todos os campos entre colchetes. Preserve os links das fontes consultadas e nunca registre senhas, tokens ou chaves reais neste documento.

## Identificação

- Nome do aplicativo: [nome]
- Frase curta: [o que o aplicativo faz em uma frase]
- Integrantes e responsabilidades: [nomes e papéis]
- Repositório: [URL]
- Protótipo: [URL]
- Aplicação publicada: [URL HTTPS]
- Release ou tag apresentada: [versão]

---

## Etapa 1 — Descoberta, pesquisa e protótipo

### Problema

- Quem enfrenta o problema? [público]
- Em qual contexto? [contexto]
- Como o problema é resolvido atualmente? [alternativas]
- Qual prejuízo ou dificuldade ele produz? [impacto]
- Qual evidência sustenta a existência do problema? [entrevista, observação, dados ou fonte]

### Proposta de valor

Para [público], que precisa de [necessidade], o [nome do aplicativo] é [categoria do produto] que [benefício principal]. Diferentemente de [alternativa], ele [diferencial].

### Identidade

- Significado do nome: [explicação]
- Logo e versões: [link ou caminho]
- Ferramenta/chat usado: [nome]
- Prompt principal: [prompt]
- Ajustes humanos realizados: [descrição]
- Paleta e contraste: [cores e resultado da verificação]
- Tipografia: [fontes]
- Licenças de fontes, ícones e imagens: [fontes]

### Pesquisa de 10 bibliotecas

| # | Biblioteca | Problema resolvido | Licença | Manutenção/comunidade | Custo ou impacto | Usaria? Por quê? | Fonte e data |
|---|---|---|---|---|---|---|---|
| 1 | | | | | | | |
| 2 | | | | | | | |
| 3 | | | | | | | |
| 4 | | | | | | | |
| 5 | | | | | | | |
| 6 | | | | | | | |
| 7 | | | | | | | |
| 8 | | | | | | | |
| 9 | | | | | | | |
| 10 | | | | | | | |

### Pesquisa de 3 frameworks

| # | Framework | Escopo e convenções | Licença | Curva de aprendizagem | Build/renderização | Adequação ao app | Fonte e data |
|---|---|---|---|---|---|---|---|
| 1 | | | | | | | |
| 2 | | | | | | | |
| 3 | | | | | | | |

### Decisão tecnológica inicial

- Opções comparadas: [lista]
- Critérios mais importantes para este projeto: [critérios]
- Escolha: [tecnologia]
- Por que ela foi escolhida? [justificativa]
- Qual risco essa escolha introduz? [risco]
- O que faria a equipe rever a decisão? [gatilho]

### Plano de negócios enxuto

| Bloco | Resposta |
|---|---|
| Segmentos de clientes | |
| Proposta de valor | |
| Canais | |
| Relacionamento | |
| Atividades principais | |
| Recursos principais | |
| Parceiros principais | |
| Estrutura de custos | |
| Receita ou sustentabilidade | |
| Métricas de sucesso | |

### Funcionalidades e escopo

#### Jornada principal

1. [passo]
2. [passo]
3. [passo]
4. [resultado]

#### Backlog do MVP

| Prioridade | História ou funcionalidade | Critério de aceite | Fora do escopo? |
|---|---|---|---|
| Deve | Como [perfil], quero [ação], para [resultado]. | Dado/Quando/Então | Não |
| Deve | | | |
| Deveria | | | |
| Poderia | | | |

#### Requisitos não funcionais

- Acessibilidade: [meta]
- Desempenho: [meta]
- Segurança e privacidade: [meta]
- Disponibilidade: [meta]
- Responsividade: [meta]
- Compatibilidade: [meta]

### Protótipo

- Ferramenta: [Figma ou equivalente]
- Link: [URL]
- Telas desktop: [lista]
- Telas mobile: [lista]
- Estados vazio, carregando, erro e sucesso: [onde aparecem]
- Teste realizado com outra pessoa: [resultado]
- Mudanças depois do teste: [mudanças]

### Checklist da etapa 1

- [ ] Problema, público e evidência documentados
- [ ] 10 bibliotecas pesquisadas
- [ ] 3 frameworks pesquisados
- [ ] Nome, logo, prompt e licenças registrados
- [ ] Plano de negócios preenchido
- [ ] MVP priorizado
- [ ] Protótipo desktop e mobile navegável
- [ ] Estados alternativos desenhados

---

## Etapa 2 — Git, Docker, Node, Express e front-end próprio

### Repositório e execução

- Estratégia de branches: [descrição]
- Convenção de commits: [descrição]
- Comando para desenvolvimento: `[comando]`
- Comando para testes: `[comando]`
- Comando Docker/Compose: `[comando]`
- Portas expostas: [portas]
- Variáveis documentadas em `.env.example`: [lista sem valores secretos]

### API Express

| Método | Rota | Objetivo | Entrada | Saídas/status | Autenticação? |
|---|---|---|---|---|---|
| GET | /health | Verificar saúde | — | 200 | Não |
| | | | | | |
| | | | | | |

### Front-end próprio

- Páginas/rotas: [lista]
- Recursos consumidos com `fetch`: [lista]
- Manipulações do DOM: [lista]
- Validações no cliente: [lista]
- Carregamento, vazio, sucesso e erro: [descrição]
- Acessibilidade por teclado: [evidência]

### Docker

- Imagem base e justificativa: [imagem]
- Contexto de build: [pasta]
- Uso de `.dockerignore`: [itens excluídos]
- Usuário não-root: [configuração]
- Health check: [configuração]
- Persistência de dados: [volume ou serviço externo]
- Tamanho final da imagem: [valor]

### Checklist da etapa 2

- [ ] Histórico Git compreensível
- [ ] README permite reproduzir a execução
- [ ] Front próprio executa o fluxo principal
- [ ] API valida entradas e usa status HTTP coerentes
- [ ] Dockerfile, `.dockerignore` e Compose funcionam
- [ ] Nenhum segredo foi versionado
- [ ] Testes essenciais executam com um comando

---

## Etapa 3 — Front-end com framework

- Escolha: [Angular, Vue, React ou Next.js]
- Fonte oficial consultada: [URL e data]
- Motivo da escolha: [justificativa ligada ao aplicativo]
- Estratégia de renderização: [CSR, SSR, SSG ou combinação]
- Estratégia de estado: [local, compartilhado, servidor]
- Roteamento: [rotas]
- Componentes reutilizáveis: [lista]
- Formulários: [abordagem]
- Integração com Express: [URL/configuração]

### Comparação com o front próprio

| Dimensão | HTML/CSS/JS próprio | Framework escolhido | Conclusão |
|---|---|---|---|
| Estrutura do código | | | |
| Reutilização | | | |
| Estado | | | |
| Roteamento | | | |
| Build e tamanho | | | |
| Testes | | | |
| Acessibilidade | | | |
| Experiência de desenvolvimento | | | |

### Checklist da etapa 3

- [ ] API Express continua funcionando por contrato HTTP
- [ ] Rotas podem ser abertas e recarregadas
- [ ] Componentes representam responsabilidades claras
- [ ] Estados de rede possuem feedback
- [ ] Layout é responsivo e navegável por teclado
- [ ] Comparação entre as duas implementações foi documentada

---

## Etapa 4 — Segurança, Vertical Slice e cloud

### Arquitetura Vertical Slice

| Slice/caso de uso | Rota | Validação | Handler | Dados | Teste |
|---|---|---|---|---|---|
| | | | | | |
| | | | | | |
| | | | | | |

- Elementos realmente compartilhados: [banco, autenticação, erros, logs]
- Acoplamento removido: [descrição]
- Trade-off introduzido: [descrição]

### Modelo de ameaças enxuto

| Ativo | Ameaça | Impacto | Controle | Evidência/teste | Risco restante |
|---|---|---|---|---|---|
| | | | | | |
| | | | | | |
| | | | | | |

### Controles de segurança

- [ ] Validação de entrada no servidor
- [ ] Autorização por recurso/caso de uso
- [ ] Headers de segurança
- [ ] CORS restrito aos consumidores necessários
- [ ] Rate limiting em rotas sensíveis
- [ ] Limite de payload, paginação e timeouts
- [ ] Erros sem stack trace ou dados internos para o cliente
- [ ] Segredos fora do Git e da imagem
- [ ] Dependências auditadas
- [ ] Logs sem tokens, senhas ou dados pessoais desnecessários
- [ ] HTTPS no ambiente publicado
- [ ] Backup/recuperação ou limitação documentada

### Publicação em cloud via Docker

- Provedor/plataforma: [nome]
- Região: [região]
- Registry: [nome/URL sem credenciais]
- Imagem e tag: [imagem:tag]
- URL HTTPS: [URL]
- Banco/armazenamento: [serviço]
- Configuração de segredos: [mecanismo]
- Health check: [rota e intervalo]
- Logs e métricas: [onde consultar]
- Processo de nova publicação: [passos]
- Processo de rollback: [passos]
- Custo estimado: [valor e condições]

### Checklist da etapa 4

- [ ] Casos de uso estão organizados como slices reconhecíveis
- [ ] Controles de segurança possuem evidência
- [ ] Imagem é versionada e reproduzível
- [ ] Deploy responde por HTTPS
- [ ] Variáveis e segredos estão fora da imagem
- [ ] Health check e logs estão acessíveis
- [ ] Limitações e riscos restantes foram documentados

---

## Etapa 5 — Apresentação final

### Roteiro

| Parte | Responsável | Tempo planejado | Evidência usada |
|---|---|---|---|
| Problema e proposta de valor | | | |
| Pesquisa e protótipo | | | |
| Demonstração do fluxo | | | |
| Arquitetura e requisição ponta a ponta | | | |
| Segurança, testes e cloud | | | |
| Aprendizados e próximos passos | | | |

### Demonstração

- Conta/dados preparados: [descrição]
- Fluxo feliz: [passos]
- Estado de erro ou recuperação: [passos]
- Evidência dos logs/health check: [passos]
- Plano B: [vídeo, capturas e execução local]

### Reflexão

- Melhor decisão do projeto: [decisão e evidência]
- Decisão que seria revista: [decisão e motivo]
- Maior risco atual: [risco]
- Próxima funcionalidade: [funcionalidade]
- Próxima melhoria técnica: [melhoria]

### Checklist da etapa 5

- [ ] Repositório e tag/release final acessíveis
- [ ] Protótipo e aplicação publicada acessíveis
- [ ] Slides ou roteiro entregues
- [ ] Diagrama arquitetural atualizado
- [ ] Demonstração e plano de contingência preparados
- [ ] Todos os integrantes dominam uma parte e compreendem o todo
- [ ] Nenhum segredo aparece em slides, logs, vídeo ou repositório

---

## Referências

Liste apenas fontes realmente consultadas.

| Título | Autor/organização | URL | Data de acesso | Onde foi usada |
|---|---|---|---|---|
| | | | | |
| | | | | |
| | | | | |