Fase 9: smoke externo do staging e fechamento

brain/PENDING_UPDATES.md

@@ -6,10 +6,7 @@ Fila FIFO de lacunas que precisam ser confirmadas para manter o Brain fiel ao pr
 
 - [ ] Confirmar o nome do owner a ser usado no front-matter dos documentos canonicos. Valor inicial usado: `LuanTrindade95`.
 - [ ] Decidir se o pacote operacional de prompts deve ser versionado dentro do repositorio ou continuar como referencia externa em `Downloads`.
-- [ ] Definir backlog tecnico inicial pos-Fase 8.
+- [ ] Definir backlog tecnico inicial pos-Fase 9.
 - [ ] Confirmar como Obsidian sera usado na pratica: apenas templates dentro do repositorio ou tambem vault/configuracao local fora do Git.
-- [ ] Decidir se vulnerabilidades dev-only apontadas por `npm audit` completo devem ser tratadas em hardening futuro ou aceitas enquanto `npm audit --omit=dev` estiver limpo.
-- [ ] Aprovar explicitamente, por plataforma, qualquer criacao externa em Netlify, Render, Aiven ou equivalente.
-- [ ] Definir politica de reset do banco demo para staging futuro.
-- [ ] Confirmar Git remoto e workspace antes de qualquer deploy externo.
-- [ ] Validar template Render com CLI/Dashboard apenas apos Gate PO.
+- [ ] Planejar o upgrade major do Angular que encerra as advisories aceitas em `ADR-020` e devolve `npm run fitness` ao verde.
+- [ ] Decidir como tratar a hibernacao do plano free na primeira visita antes de divulgar a URL para avaliadores.

brain/canonico/CURRENT_STATE.md

@@ -1,5 +1,5 @@
 ---
-updated: 2026-09-18
+updated: 2026-09-20
 owner: LuanTrindade95
 status: canonico
 ---
@@ -131,13 +131,16 @@ Existe no repositorio:
   - Render Blueprint real `render.yaml` foi materializado e validado
   - Aiven criou `flowcore-valkey` em free tier
   - Aiven bloqueou segundo MySQL free por limite da organizacao; FlowCore usa banco `flowcore_staging` e usuario `flowcore_app` isolados no servico MySQL existente `portfolio`
-  - Netlify permanece pendente ate existirem URLs publicas de API/Reverb
+  - Blueprint aplicado no Render: `flowcore-api` em `https://flowcore-api-urkx.onrender.com` e `flowcore-reverb` em `https://flowcore-reverb.onrender.com`, ambos web services free com `autoDeploy: false`
+  - Netlify no ar em `https://flowcore-luantrindade.netlify.app`, servindo `/config.json` com as URLs publicas de API e Reverb
+  - Smoke externo completo executado contra as URLs publicas: `/health`, `/config.json`, login, catalogo, criacao de solicitacao, inbox, decisao e evento realtime no canal privado
+  - `render.yaml` define `LOG_CHANNEL=stderr` e `LOG_LEVEL=error` para que excecoes apareçam nos Logs do Render
 
 Ainda nao existe:
 
 - Fluxos completos do produto fora do roadmap faseado.
 - Backlog tecnico.
-- Deploy publico/staging real aplicado no Render/Netlify.
+- Escalonamento de SLA em staging, que depende de scheduler ausente no plano free.
 
 ## Contexto Confirmado
 
@@ -181,12 +184,15 @@ Ainda nao existe:
 - A Fase 8 definiu que templates Render/Aiven permanecem documentais ate Gate PO especifico.
 - A Fase 9 definiu que o limite gratuito da Aiven impede segundo MySQL; o banco demo FlowCore deve ficar isolado em `flowcore_staging`, sem operar sobre `defaultdb`.
 - A Fase 9 definiu `flowcore-valkey` como Redis-compatible gerenciado para cache, sessoes, filas e Horizon/Reverb no staging.
+- A Fase 9 definiu que o staging free roda sem Horizon e sem scheduler, com `QUEUE_CONNECTION=sync`, o que desliga o escalonamento de SLA fora do ambiente local.
+- A Fase 9 definiu `LOG_CHANNEL=stderr` como requisito do staging: sem ele a excecao fica em arquivo dentro do container e o diagnostico externo se torna cego.
+- A Fase 9 aceitou as advisories de `@angular/*` 19.2.25 para a demo de staging, conforme `ADR-020`, mantendo `npm run fitness` vermelho no passo `audit`.
 
 ## Em Progresso
 
-Fase 9 em andamento em `main`.
+Nenhuma fase em andamento. A Fase 9 foi concluida em 2026-09-19/20 na branch `feature/phase-9-external-smoke`, com smoke externo reproduzido e aprovado em auditoria adversarial.
 
-Proxima etapa recomendada: aplicar o Blueprint no Render Dashboard, preencher segredos `sync: false`, capturar URLs publicas de API/Reverb e entao criar/configurar o site Netlify.
+Proxima etapa recomendada: definir o backlog tecnico pos-Fase 9, com o upgrade major do Angular como candidato prioritario por causa das advisories aceitas em `ADR-020`.
 
 ## Bloqueios
 

brain/canonico/DECISIONS.md

@@ -1,5 +1,5 @@
 ---
-updated: 2026-06-12
+updated: 2026-09-19
 owner: LuanTrindade95
 status: canonico
 ---
@@ -265,3 +265,9 @@ Por que: Netlify config nao provisiona recurso por si so; Render Blueprint e Aiv
 Decisao: adicionar `/health` com resposta JSON simples para checks de plataforma.
 
 Por que: Render e outras plataformas precisam de liveness HTTP sem autenticar, sem tocar banco e sem acoplar health check ao dominio runtime.
+
+## 2026-09-19 - Aceite das advisories do Angular 19 no staging
+
+Decisao: aceitar as 7 advisories de `@angular/*` 19.2.25 para a demo de staging; `npm run fitness` fica vermelho no passo `audit` enquanto elas existirem, sem bloquear a Fase 9. O upgrade major do Angular e tarefa propria.
+
+Por que: nao existe correcao dentro da linha 19, a superficie e demo de portfolio sem dado real de usuario e sem SSR, e puxar migracao de framework para dentro do smoke externo trocaria um risco conhecido por um risco maior. Detalhes em `brain/decisions/ADR-020-angular-19-advisory-acceptance.md`.

brain/canonico/KNOWN_ISSUES.md

@@ -1,21 +1,26 @@
 ---
-updated: 2026-09-18
+updated: 2026-09-19
 owner: LuanTrindade95
 status: canonico
 ---
 
 # Known Issues
 
-Nenhum bug funcional aberto registrado nas fases concluidas ate a Fase 8.
+Nenhum bug funcional aberto registrado.
 
 ## Limitacoes Atuais
 
 - Fluxos completos do produto ainda nao foram especificados.
 - Backlog tecnico ainda nao foi criado.
-- Deploy publico/staging real ainda nao foi provisionado por decisao do PO.
+- Staging externo esta no ar: frontend Netlify `https://flowcore-luantrindade.netlify.app`, API Render `https://flowcore-api-urkx.onrender.com`, Reverb Render `https://flowcore-reverb.onrender.com`, MySQL/Valkey Aiven no projeto `portfolio-01`.
+- Os web services Render em plano free hibernam por inatividade; a primeira resposta apos hibernacao ja foi medida em 24,6 s e 84,5 s. Qualquer divulgacao do link precisa avisar sobre essa espera.
+- O servico MySQL Aiven `portfolio` desliga sozinho (`Powered off`) e, enquanto desligado, seu hostname deixa de resolver em DNS. A API continua respondendo `/health` 200, mas toda rota que toca o banco retorna 500. Religar o servico no console Aiven restaura o acesso.
+- O staging Render roda `QUEUE_CONNECTION=sync` sem Horizon e sem scheduler: o escalonamento de SLA (`workflow:escalate-overdue`) nao executa em staging, so em ambiente local.
+- Logo apos religar o MySQL Aiven, chamadas isoladas a API podem falhar com 500 ou 520 de borda antes de estabilizar; repetir a chamada resolve. Um 500 nessa janela nao caracteriza bug de aplicacao.
+- A API em staging roda `php artisan serve`, servidor de desenvolvimento de processo unico, adequado apenas para demo.
 - O host Windows possui PHP 8.2.26; a referencia de runtime para PHP 8.3 e Docker/CI.
 - O token frontend permanece somente em memoria por decisao de seguranca do MVP; recarregar a SPA exige novo login.
-- `npm audit --omit=dev` esta limpo; auditoria completa do npm ainda pode apontar vulnerabilidades em dependencias dev do toolchain Angular/Jest.
+- `npm audit --omit=dev` acusa 7 vulnerabilidades (3 high) em `@angular/*` 19.2.25, ultima versao da linha 19; a correcao exige upgrade major. Enquanto nao houver decisao, `npm run fitness` termina vermelho nesse passo.
 - Se `backend/.env` local existir com `DB_CONNECTION=sqlite`, o servidor HTTP Docker pode autenticar contra banco errado. Alinhar `.env` local ao `.env.example` antes de smoke HTTP.
 - O versionamento imutavel da Fase 3B usa endpoint explicito `/draft`; update direto em publicado e recusado com 422.
 - A tabela `instance_steps` possui apenas `assigned_to`; para steps por role/multiplos aprovadores, a Fase 3C deixa `assigned_to=null` e resolve os aprovadores dinamicamente a partir de `step_approvers` no momento da decisao.
@@ -26,6 +31,8 @@ Nenhum bug funcional aberto registrado nas fases concluidas ate a Fase 8.
 - O CI exibe annotations de deprecacao: actions em runtime Node 20 (`actions/checkout@v4`, cache) e migracao de `ubuntu-latest` para Ubuntu 26 a partir de 2026-10-19.
 - Em Docker local, `backend/.env` ignorado precisa estar alinhado ao `.env.example` para `BROADCAST_CONNECTION`, `REVERB_APP_ID`, `REVERB_APP_KEY`, `REVERB_APP_SECRET` e `REVERB_BROADCAST_HOST`; caso contrario, o servidor `artisan serve` pode divergir dos processos CLI.
 - O deploy externo ainda depende de plataforma, workspace, Git remoto, secrets e URLs reais aprovados pelo PO.
-- `deploy/render/render.yaml.example` nao foi validado por Render CLI nem aplicado em Blueprint, por decisao de nao criar/provisionar recursos externos.
-- A politica de reset do banco demo para staging externo ainda precisa de aprovacao explicita por plataforma.
+- `deploy/render/render.yaml.example` permanece documental; o Blueprint real aplicado e `render.yaml`.
+- `render.yaml` define `LOG_CHANNEL=stderr` e `LOG_LEVEL=error` para que excecoes aparecam nos Logs do Render; sem elas o Laravel grava em arquivo dentro do container e o erro fica invisivel. O valor so vale apos novo deploy do Blueprint.
+- Os testes backend via `docker compose exec` rodam contra o MySQL do compose em vez do sqlite de `phpunit.xml`, porque o `env_file` do compose precede os `<env>` do PHPUnit; rodar a suite apaga os dados demo locais.
+- O banco demo resetavel e exclusivamente `flowcore_staging` no servico MySQL Aiven `portfolio`; `defaultdb` e qualquer outro banco estao fora da politica de reset.
 - O runner local do `godmode-plus` foi ajustado fora do repositorio para resolver `npx` no Windows via `cmd.exe`; uma atualizacao futura da skill pode sobrescrever esse ajuste.

brain/canonico/NEXT_ACTIONS.md

@@ -1,5 +1,5 @@
 ---
-updated: 2026-06-12
+updated: 2026-09-20
 owner: LuanTrindade95
 status: canonico
 ---
@@ -8,35 +8,28 @@ status: canonico
 
 ## Ordem Recomendada
 
-1. Aplicar o Blueprint Render publicado em `main`:
-   - repo: `https://github.com/LuanTrindade95/FlowCore`;
-   - arquivo: `render.yaml`;
-   - Dashboard: `https://dashboard.render.com/blueprint/new?repo=https://github.com/LuanTrindade95/FlowCore`.
-2. Preencher no Render os segredos `sync: false` fora do Git:
-   - `APP_KEY`;
-   - credenciais Aiven MySQL do usuario `flowcore_app`;
-   - credenciais Aiven Valkey do usuario `default`;
-   - `REVERB_APP_ID`, `REVERB_APP_KEY`, `REVERB_APP_SECRET`;
-   - `APP_URL`, `FRONTEND_URL`, `FRONTEND_URLS`, `REVERB_HOST`, `REVERB_BROADCAST_HOST`.
-3. Depois que `flowcore-api` e `flowcore-reverb` estiverem `live`, criar/configurar Netlify com as variaveis `FLOWCORE_*`.
-4. Rodar migracoes/seed apenas no banco Aiven `flowcore_staging`; nunca rodar reset em `defaultdb`.
-5. Executar smoke externo: `/health`, login, dashboard, runtime inbox/detalhe e realtime basico.
+1. Definir o backlog tecnico pos-Fase 9, usando `brain/canonico/KNOWN_ISSUES.md` como entrada.
+2. Planejar o upgrade major do Angular para encerrar as advisories aceitas em `ADR-020` e devolver `npm run fitness` ao verde.
+3. Corrigir o isolamento da suite backend: `docker compose exec` roda os testes contra o MySQL do compose em vez do sqlite de `phpunit.xml`, apagando os dados demo locais.
+4. Antes de divulgar a URL publica, confirmar que o MySQL Aiven `portfolio` esta `Running` e aquecer `flowcore-api` e `flowcore-reverb` com um `GET /health`.
+5. Avaliar como reduzir o impacto da hibernacao do plano free na primeira visita: aviso na tela de login, aquecimento agendado ou mudanca de plano.
 6. Manter seed demo idempotente como base obrigatoria de qualquer E2E local ou staging.
 7. Atualizar `docs/DECISIONS.md`, `docs/PROGRESS.md` e o Brain no fechamento de cada fase.
 
 ## Estado Atual
 
-Fase 9 esta em andamento e foi promovida para `main`.
+Fase 9 concluida. Staging externo no ar e validado de fora.
+
+Superficies publicas:
+
+- Frontend Netlify: `https://flowcore-luantrindade.netlify.app`
+- API Render: `https://flowcore-api-urkx.onrender.com`
+- Reverb Render: `https://flowcore-reverb.onrender.com`
+- Dados: MySQL Aiven `flowcore_staging` e Valkey Aiven `flowcore-valkey`, no projeto `portfolio-01`
 
 Evidencias registradas:
 
-- Commit funcional: `466f0f7 feat(deploy): prepare staging runtime configuration`
-- Blueprint Render: `14cdb59 feat(deploy): add staging blueprint`
-- Ajuste validado do Blueprint free-tier: `beb74e8 fix(deploy): validate render free-tier blueprint`
-- Root gate `npm run fitness` verde
-- `npm run guard:migrations` verde
-- `npm run check:enforcement` verde
-- `npm --prefix frontend run build:staging` verde
-- Browser local validou `/config.json`, login e dashboard sem erros de console
-- Docker seed `php artisan db:seed --force` usado para restaurar dados demo antes do smoke autenticado
-- veredicto `APROVADO` do verificador local
+- Smoke externo completo em 2026-09-19 e reproduzido por auditoria independente em 2026-09-20: login 200, criacao de solicitacao 201, payload fora do schema 422, inbox 200, decisao 200 com avanco de step, evento `runtime.workflow.updated` recebido em canal privado sem refresh
+- Veredito `APROVADO` da auditoria adversarial, com ressalvas de divulgacao registradas em `brain/canonico/KNOWN_ISSUES.md`
+- `npm run guard:migrations` e `npm run check:enforcement` verdes; `npm --prefix frontend run build:staging` verde
+- `npm run fitness` vermelho apenas no passo `audit`, conforme `ADR-020`

brain/decisions/ADR-020-angular-19-advisory-acceptance.md

@@ -0,0 +1,30 @@
+# ADR-020 - Angular 19 advisory acceptance in staging demo
+
+## Status
+
+Accepted on 2026-09-19.
+
+## Context
+
+`npm audit --omit=dev` reports 7 advisories (3 high, 4 moderate) against `@angular/common`, `@angular/compiler`, `@angular/core`, `@angular/forms`, `@angular/platform-browser*` and `@angular/router` at `19.2.25`, which is the last release of the 19 line. The advisories cover `HttpTransferCache` cache-key ambiguity and information leak, a `formatDate` denial of service and a two-way binding sanitization bypass. No patch exists inside the 19 line, so the only remediation is a major upgrade.
+
+The FlowCore staging surface is a portfolio demo: a single Angular SPA on Netlify talking to one Laravel API, with demo accounts, seeded data and no real user data. The SPA is client-rendered and does not run server-side rendering, which is the delivery mode the `HttpTransferCache` advisories target.
+
+`npm run fitness` chains `audit` as its last step, so the gate stays red while the advisories are open.
+
+## Options considered
+
+- Upgrade Angular to a supported major line before closing phase 9. Clears the advisories, but pulls a breaking framework migration into a phase whose scope is external smoke, and risks the builder surface built on `@foblex/flow`.
+- Drop `audit` from `npm run fitness`. Rejected: it hides the signal instead of deciding on it, and weakens a gate for every future task.
+- Accept the risk for the staging demo and keep the gate red until a dedicated upgrade task. Chosen.
+
+## Decision
+
+Accept the advisories for the staging demo. `npm run fitness` is expected to fail on its `audit` step while they are open, and that failure does not block phase 9. The Angular major upgrade is a separate task, not part of external smoke work.
+
+## Consequences
+
+- Any task that runs `npm run fitness` must read the audit step failure against this ADR before treating it as a regression, and must confirm the failing advisories are still only these Angular ones.
+- The acceptance covers the staging demo only. Real user data, authentication against a real identity provider or server-side rendering would each void it and require the upgrade first.
+- `brain/canonico/KNOWN_ISSUES.md` carries the open limitation while it lasts.
+- The upgrade task must revisit this ADR and supersede it once the advisories clear.