docs: registrar o recorte do lançamento e adiar as Fases 2 a 5 (#41)

A SPEC §4.1 declarava CRM de leads, conversão de lead em evento, eventos,
tarefas, fornecedores, orçamento, pagamentos manuais, documentos,
dashboard e auditoria como parte do MVP. O projeto do lançamento aprovado
com a dona do produto é o site institucional — Fases 0 e 1 — e o
repositório reflete isso: não existe model, migration ou tela para
nenhuma dessas capacidades.

Nada disso estava registrado em lugar nenhum, então a §1 e a §25 seguiam
instruindo qualquer agente que lesse o documento a implementar as Fases 2
a 5. A divergência era silenciosa e a §0.2 proíbe justamente isso.

O que muda:

- §4 ganha nota de recorte apontando para a ADR-016, e a §4.1 separa o
  que entra no lançamento do que fica adiado. A distinção entre adiado e
  fora do MVP fica explícita: os itens adiados seguem sendo o produto
  pretendido, enquanto a §4.2 lista o que não deve ser implementado nunca.
- §18 ganha nota equivalente e as Fases 2 a 5 passam a ser marcadas como
  ADIADA no próprio título.
- §21 registra a ADR-016.
- §23 é dividida em dois recortes. Sem isso o documento passaria a dizer
  que o MVP nunca pode ser concluído: das dezoito condições originais,
  nove pertencem às fases adiadas. A §23.1 fecha por conta própria e a
  §23.2 não bloqueia o lançamento.

Uma condição foi corrigida no caminho, não só movida: a original dizia
"briefing cria leads de forma segura". Criar Lead é Fase 2. O formulário
atual envia e-mail e não persiste nada, então a condição do lançamento
passa a ser enviar o pedido com proteção contra abuso e aceite de
privacidade registrado — o que o código realmente faz.

Marca também o hello-world em staging na §18, agora que existe evidência:
o deploy passou em 7e68c0e depois da correção do PR #38, com smoke verde.
Com isso o critério de saída da Fase 0 está cumprido.

O openspec/config.yaml recebe a linha de stack corrigida que ficou de
fora do PR #35. A afirmação sobre a cidade de atuação permanece: São
Paulo está correto e é garantido por teste — a suspeita de que também
estivesse desatualizada não se confirmou.

Co-Authored-By: Claude noreply@anthropic.com
AI-Assisted: yes
AI-Tool: claude-code

Co-authored-by: manoel.neto <manoel.neto@creditas.com>

SPEC.md

@@ -194,11 +194,24 @@ Não instalar sistema de permissões granular no MVP.
 
 ## 4. Escopo
 
+> **Recorte vigente do lançamento (ADR-016).** O escopo aprovado para o lançamento de 31/08/2026 é o **site institucional**: Fases 0 e 1. As Fases 2 a 5 — CRM de leads, conversão de lead em evento, eventos, tarefas, fornecedores, orçamento, pagamentos manuais, documentos, dashboard orientado a exceções e auditoria — permanecem especificadas neste documento mas ficam **adiadas**, sem data.
+>
+> A §4.1 abaixo descreve o produto completo, não o recorte do lançamento. Os itens marcados como adiados estão fora do que se constrói agora. Ver §18 para a divisão por fase e §23 para as condições de conclusão de cada recorte.
+
 ### 4.1 Incluído no MVP
 
+No recorte do lançamento (Fases 0–1):
+
 - site público;
 - CMS interno do site;
 - formulário de briefing;
+- usuários internos e papéis simples;
+- SEO básico;
+- acessibilidade e testes visuais;
+- CI/CD e deploy em contêiner com FrankenPHP.
+
+Adiados para depois do lançamento (Fases 2–5, ver ADR-016):
+
 - CRM de leads;
 - conversão de lead em evento;
 - cadastro e visão consolidada de eventos;
@@ -208,12 +221,10 @@ Não instalar sistema de permissões granular no MVP.
 - pagamentos inseridos manualmente;
 - documentos vinculados a leads e eventos;
 - dashboard orientado a exceções;
-- usuários internos e papéis simples;
 - notificações internas e por e-mail para novos leads;
-- auditoria de ações críticas;
+- auditoria de ações críticas.
-- SEO básico;
+
-- acessibilidade e testes visuais;
+Adiado **não** é o mesmo que fora do MVP: os itens acima seguem especificados neste documento e continuam sendo o produto pretendido. A §4.2 lista o que **NÃO DEVE** ser implementado em nenhum momento.
-- CI/CD e deploy em contêiner com FrankenPHP.
 
 ### 4.2 Fora do MVP
 
@@ -2325,6 +2336,8 @@ Para visual e browser tests:
 
 ## 18. Backlog de implementação
 
+> **Recorte vigente (ADR-016).** Fases 0 e 1 são o escopo do lançamento e estão concluídas. **Fases 2 a 5 estão adiadas, sem data.** Não iniciar nenhuma delas sem uma decisão nova do responsável pelo produto — a §1.1 manda trabalhar uma fase por vez, e a fase corrente é o acabamento e a publicação do site.
+
 O agente deve implementar na sequência, salvo instrução explícita.
 
 ### Fase 0 — Fundação
@@ -2351,7 +2364,7 @@ O agente deve implementar na sequência, salvo instrução explícita.
 - [x] npm audit no `composer quality` e no job `static`;
 - [x] gate de cobertura `Domain`/`Application` ≥ 80%;
 - [x] serviço de aplicação FrankenPHP no Compose local;
-- [ ] hello-world implantado em staging (critério de saída).
+- [x] hello-world implantado em staging (critério de saída) — run [31395107465](https://github.com/manoel-freitas/amore-site/actions/runs/31395107465) em `7e68c0e`, com `Dokploy deployment succeeded` e smoke verde em `/up`, `/` e `/admin/login`.
 
 > Os itens pendentes acima são tratados pela mudança OpenSpec `complete-foundation-parity`; o critério de saída da fase só é atingido com staging implantado.
 
@@ -2375,7 +2388,7 @@ O agente deve implementar na sequência, salvo instrução explícita.
 
 **Critério de saída:** conteúdo gerenciável no Filament e site público aprovado visualmente (baselines em `tests/.pest/snapshots/`; aprovação humana do diff visual no PR).
 
-### Fase 2 — Leads
+### Fase 2 — Leads — ADIADA (ADR-016)
 
 - [ ] migration/model/factory de Lead;
 - [ ] LeadActivity;
@@ -2392,7 +2405,7 @@ O agente deve implementar na sequência, salvo instrução explícita.
 
 **Critério de saída:** jornada visitante → lead → tratamento interna totalmente verde.
 
-### Fase 3 — Eventos e tarefas
+### Fase 3 — Eventos e tarefas — ADIADA (ADR-016)
 
 - [ ] Event;
 - [ ] EventTask;
@@ -2407,7 +2420,7 @@ O agente deve implementar na sequência, salvo instrução explícita.
 
 **Critério de saída:** lead é convertido e evento pode ser administrado.
 
-### Fase 4 — Fornecedores e financeiro
+### Fase 4 — Fornecedores e financeiro — ADIADA (ADR-016)
 
 - [ ] Vendor;
 - [ ] EventVendor;
@@ -2423,7 +2436,7 @@ O agente deve implementar na sequência, salvo instrução explícita.
 
 **Critério de saída:** assessora acompanha orçamento e pagamentos sem integração bancária.
 
-### Fase 5 — Documentos, hardening e lançamento
+### Fase 5 — Documentos, hardening e lançamento — ADIADA (ADR-016)
 
 - [ ] documentos privados;
 - [ ] auditoria completa;
@@ -2515,6 +2528,7 @@ Toda operação financeira deve:
 | ADR-013 | Design system Heritage Editorial para o site público | Aceita |
 | ADR-014 | Deploy via Dokploy Compose com imagem imutável por SHA no GHCR | Aceita |
 | ADR-015 | Site público permanece Blade + JS vanilla; Livewire e Alpine ficam restritos ao Filament até o gatilho de §22. Emenda o texto da ADR-002 | Aceita |
+| ADR-016 | Lançamento de 31/08/2026 entrega apenas o site institucional (Fases 0–1); Fases 2–5 seguem especificadas e adiadas, sem data | Aceita |
 
 ---
 
@@ -2539,24 +2553,39 @@ Toda operação financeira deve:
 
 O MVP está concluído somente quando:
 
+A ADR-016 divide estas condições em dois recortes. Cada um se fecha por conta própria; o segundo não bloqueia o lançamento.
+
+### 23.1 Lançamento do site (Fases 0–1)
+
+O lançamento está concluído somente quando:
+
 - site público está publicado e visualmente aprovado;
 - assessora edita os conteúdos essenciais sem desenvolvedor;
-- briefing cria leads de forma segura;
+- briefing envia o pedido de proposta de forma segura, com proteção contra abuso e aceite de privacidade registrado;
+- usuários e Policies estão corretos;
+- testes unit, feature, visuais e arquitetura estão verdes;
+- CI bloqueia regressões;
+- imagem FrankenPHP é reproduzível;
+- staging e produção usam a mesma imagem promovida;
+- backup, restauração e monitoramento estão documentados;
+- nenhum item explicitamente fora do MVP (§4.2) foi introduzido.
+
+Note a diferença em relação à versão anterior desta seção: o critério do briefing é **enviar o pedido**, não "criar leads". Criar Lead é Fase 2 e está adiado; o formulário atual envia e-mail e não persiste nada.
+
+### 23.2 Produto completo (Fases 2–5, adiado)
+
+Além de tudo em §23.1:
+
 - pipeline e próxima ação funcionam;
+- briefing cria leads de forma segura e persistente;
 - lead é convertido uma única vez em evento;
 - checklist é criado automaticamente;
 - evento possui visão consolidada;
 - fornecedores podem ser cadastrados e vinculados;
 - orçamento e pagamentos manuais possuem totais consistentes;
 - dashboard mostra pendências do dia;
-- usuários e Policies estão corretos;
 - auditoria registra operações críticas;
-- testes unit, feature, E2E, visuais e arquitetura estão verdes;
+- jornadas E2E das fases correspondentes estão verdes.
-- CI bloqueia regressões;
-- imagem FrankenPHP é reproduzível;
-- staging e produção usam a mesma imagem promovida;
-- backup, restauração e monitoramento estão documentados;
-- nenhum item explicitamente fora do MVP foi introduzido.
 
 ---
 

openspec/config.yaml

@@ -3,7 +3,7 @@ schema: spec-driven
 context: |
   Fonte de verdade: SPEC.md na raiz. Precedência: instrução do dono do produto > SPEC.md > ADRs > testes > convenções.
   Produto: plataforma de assessoria de eventos, single-tenant, MVP. UI em pt-BR, timezone America/Fortaleza, atuação em São Paulo (capital), BRL.
-  Stack: Laravel 13, Filament 5 (/admin), Livewire 4 + Blade + Alpine + Tailwind (site público),
+  Stack: Laravel 13, Filament 5 (/admin), Blade + Tailwind + JS vanilla progressivo (site público; sem framework reativo — Livewire 4 é dependência do Filament, ver SPEC ADR-015),
   PostgreSQL, FrankenPHP regular mode (sem worker mode), Vite, Pest 4 + Pest Browser, database queue.
   Arquitetura: monólito modular. Interface -> Application (Actions/Queries) -> Domain (Enums/VOs) -> Infrastructure.
   Domain não depende de Filament/Livewire. strict_types em todo PHP próprio.