@daniellins/power-claude 0.16.3

package/template/pods/dev-ia/agents/ux-architect.md

@@ -0,0 +1,29 @@
+---
+name: ux-architect
+description: "Arquiteto de UX/UI — fluxos de usuário, revisão UX de stories e telas, acessibilidade essencial e design system leve. Use para: desenhar fluxo e wireframe textual de feature, revisar UX de story/tela, rodar checklist de acessibilidade, decidir tokens/espaçamento/tipografia."
+model: sonnet
+budget_tokens: 1200
+---
+
+# ux-architect
+
+## Papel
+
+Arquiteto de UX/UI do pod dev-ia. Guardião da experiência: mobile-first, todo estado desenhado, acessível por default. Critério de qualidade: nenhuma tela chega ao papel Dev sem os 4 estados (loading/empty/error/success) especificados e sem funcionar em 360px.
+
+## Missões
+
+| Missão | O que faz |
+|---|---|
+| `*flow` | Fluxo de usuário e wireframe textual de uma feature: jornada passo a passo (entrada → ações → saídas), wireframe em blocos/ASCII por tela, estados de cada passo, pontos de fricção e de decisão. Entrada: story ou SPEC; saída: seção UX anexável à story, consumível pelo Dev sem ferramenta de design. |
+| `*review` | Revisão UX de story/tela: hierarquia visual (1 ação primária por tela), estados vazios/erro/carregando especificados, mobile-first ≥ 360px, feedback visual < 200ms em toda interação (resposta otimista ou skeleton), consistência com padrões já existentes no produto. Veredito com lista acionável por severidade. |
+| `*a11y` | Checklist de acessibilidade essencial: contraste (4.5:1 texto, 3:1 componentes/ícones), foco visível com ordem lógica, semântica (landmarks, hierarquia de headings, labels em inputs, alt em imagens), operável 100% por teclado, alvos de toque ≥ 44px, erros anunciados (`aria-live`). PASS/FAIL por item, com evidência. |
+| `*ds` | Decisões de design system leve: tokens semânticos (nunca hex soltos no código), escala de espaçamento (base 4/8px), tipografia com escala e pesos limitados, raio/elevação e estados de componente (hover/focus/active/disabled). Saída: tabela de tokens. Estende o DS do projeto quando existir — nunca cria um paralelo. |
+
+## Regras de ouro
+
+- **Mobile-first sempre:** desenhe para 360px e expanda; layout que só funciona em desktop é NO-GO.
+- **Todo estado da UI desenhado:** loading, empty, error e success especificados antes do dev — "só o caminho feliz" reprova a revisão.
+- **Acessibilidade não é opcional:** item FAIL do `*a11y` bloqueia como bug funcional, não como melhoria futura.
+- **Segue o design system do projeto quando existir;** sem DS, propõe o mínimo via `*ds` antes de inventar estilo tela a tela.
+- **Não implementa nem publica:** especifica e revisa; código é do papel Dev, push é do devops.

package/template/pods/dev-ia/knowledge/db/migration-protocol.md

@@ -0,0 +1,95 @@
+# Protocolo de Migration Segura (PostgreSQL/Supabase)
+
+Toda mudança de schema segue este protocolo. Fases são gates: não avança sem passar na anterior.
+
+## Fase 0 — Plano
+
+Antes de escrever SQL, documentar:
+
+- **Propósito** da migration e ACs que atende.
+- **Objetos afetados** (tabelas, funções, triggers, policies, índices).
+- **Breaking changes** e impacto na aplicação (o app precisa de deploy antes/depois?).
+- **Plano de rollback** (obrigatório — ver Fase 6). Migration sem rollback documentado não executa.
+- **Janela**: precisa de downtime? Se sim, quanto e quando; se não, qual padrão zero-downtime cobre.
+- **Idempotência**: usar `IF NOT EXISTS`, `CREATE OR REPLACE`, `DROP ... IF EXISTS` — a migration deve ser segura de rodar duas vezes.
+
+## Fase 1 — Verificação de ordem (verify-order)
+
+DDL na ordem certa evita falha no meio da execução:
+
+```
+extensions → types/enums → functions → tables (pais antes de filhos/FKs)
+→ indexes → triggers → RLS enable → policies → grants → seeds
+```
+
+Checks heurísticos: função chamada antes de criada? RLS/policy antes da tabela existir? Trigger antes da função? View sobre view na ordem errada? FK para tabela ainda não criada?
+
+Automático: `tools/db-ops/migration-runner.sh {path} --verify-order`
+
+## Fase 2 — Dry-run (obrigatório)
+
+Executar a migration inteira dentro de transação revertida:
+
+```bash
+psql "$DB_URL" -v ON_ERROR_STOP=1 <<'SQL'
+BEGIN;
+\i {path}
+ROLLBACK;
+SQL
+```
+
+Valida: sintaxe, dependências, ordem de execução, violações de constraint. NÃO valida: correção dos dados, performance. Automático: `migration-runner.sh {path} --dry-run`.
+
+## Fase 3 — Snapshot pré-migration
+
+```bash
+TS=$(date +%Y%m%d%H%M%S)
+pg_dump "$DB_URL" --schema-only --clean --if-exists > "supabase/snapshots/${TS}_before.sql"
+```
+
+Sem snapshot recente (<24h para produção), não aplica. `tools/db-ops/backup-manager.sh` automatiza snapshot/restore.
+
+## Fase 4 — Aplicação
+
+1. **Advisory lock** — impede migrations concorrentes:
+   `SELECT pg_try_advisory_lock(hashtext('dbops:migrate'))` → se falso, outra migration em curso: PARAR.
+2. Aplicar com `psql -v ON_ERROR_STOP=1 -f {path}` (transação; falha = rollback automático do PostgreSQL).
+3. Snapshot pós-migration + diff (`before` vs `after`) para auditoria.
+4. Liberar o lock: `SELECT pg_advisory_unlock(hashtext('dbops:migrate'))`.
+
+Automático (lock + snapshots + diff): `migration-runner.sh {path}`.
+
+## Fase 5 — Smoke-test e pós-checks
+
+- Contagens de linhas batem com o esperado; integridade de FKs verificada.
+- `*rls` audit: nenhuma tabela nova sem RLS; policies bloqueiam acesso não autorizado.
+- `ANALYZE` nas tabelas afetadas; checar slow query log e hot paths.
+- Aplicação funciona (queries reais, não só o schema).
+
+## Fase 6 — Rollback (estratégias, em ordem de preferência)
+
+1. **Roll-forward (preferida):** NOVA migration que desfaz a mudança; testar em staging; aplicar pelo mesmo protocolo.
+2. **PITR:** restaurar para ponto anterior à migration (parar writes → restore → validar integridade → retomar). Para emergências com perda de dados.
+3. **Manual (última opção):** backup de emergência ANTES; rodar rollback script em transação; arquivar dados antes de dropar; dropar objetos em ordem reversa; smoke-test.
+
+Pós-rollback: app funcional, RLS ok, performance normal, `ANALYZE`, documentar incidente + causa-raiz.
+
+## Padrões zero-downtime
+
+| Mudança | Padrão seguro |
+|---|---|
+| Adicionar coluna | `ADD COLUMN ... DEFAULT ...` (seguro em PG moderno) |
+| Remover coluna | Expand/contract: app para de usar → deploy → só então `DROP COLUMN` |
+| Renomear coluna | Nunca `RENAME` direto: add nova → backfill → app lê ambas → app só nova → drop antiga |
+| Criar índice | `CREATE INDEX CONCURRENTLY` (fora de transação) |
+| Adicionar constraint | `ADD CONSTRAINT ... NOT VALID` (sem scan) → `VALIDATE CONSTRAINT` depois (cancelável) |
+| Backfill grande | Em lotes com pausa; nunca UPDATE de tabela inteira em uma transação |
+
+## STOPs críticos — NÃO aplicar se
+
+- RLS ausente em tabela exposta sem justificativa documentada.
+- Sem backup/snapshot nas últimas 24h (produção).
+- Não testada em staging / dry-run não executado.
+- Sem plano de rollback preparado.
+- Mudança breaking sem plano de deploy coordenado com o app.
+- Ninguém disponível para suportar caso algo quebre.

package/template/pods/dev-ia/knowledge/db/rls-patterns.md

@@ -0,0 +1,101 @@
+# Padrões de RLS (Row Level Security)
+
+Princípio: **RLS habilitada por default em toda tabela acessível por cliente.** Exceções (tabelas operacionais service-role-only) são decisão documentada. Defense in depth: RLS + constraints + defaults + triggers.
+
+## Padrões canônicos
+
+### Dados do próprio usuário (owner) — o padrão KISS
+```sql
+ALTER TABLE t ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "t_owner" ON t FOR ALL TO authenticated
+USING ((SELECT auth.uid()) = user_id)
+WITH CHECK ((SELECT auth.uid()) = user_id);
+```
+
+### Acesso por time
+```sql
+team_id IN (SELECT team_id FROM team_members WHERE user_id = (SELECT auth.uid()))
+```
+
+### Por papel (role) — sempre app_metadata, NUNCA user_metadata
+```sql
+(auth.jwt() -> 'app_metadata' ->> 'role') = 'admin'
+```
+
+### Leitura pública, escrita autenticada
+```sql
+CREATE POLICY "public_read" ON t FOR SELECT TO anon, authenticated USING (true);
+CREATE POLICY "auth_write" ON t FOR INSERT TO authenticated
+WITH CHECK ((SELECT auth.uid()) = user_id);
+```
+
+### Multi-tenant (isolamento por organização)
+```sql
+CREATE POLICY "org_isolation" ON t FOR ALL TO authenticated
+USING (org_id = (auth.jwt() ->> 'org_id')::uuid)
+WITH CHECK (org_id = (auth.jwt() ->> 'org_id')::uuid);
+```
+
+### Temporal (conteúdo publicado)
+```sql
+published_at IS NOT NULL AND published_at <= now()
+```
+
+### Hierárquico (acesso via pai)
+```sql
+EXISTS (SELECT 1 FROM parent p WHERE p.id = t.parent_id AND p.user_id = (SELECT auth.uid()))
+```
+
+### SECURITY DEFINER (checagens complexas, rápido)
+```sql
+CREATE FUNCTION user_has_access(uuid) RETURNS boolean
+LANGUAGE sql SECURITY DEFINER STABLE AS $$ ... $$;
+-- policy: USING (user_has_access(id))
+```
+
+## Armadilhas (custam caro)
+
+- ❌ `auth.uid()` sem embrulhar em `(SELECT ...)` → reavaliado por linha, ordens de magnitude mais lento.
+- ❌ `user_metadata` em policy → editável pelo próprio usuário = escalação de privilégio. Só `app_metadata`.
+- ❌ Colunas de policy sem índice → full scan em toda query.
+- ❌ Sem tratamento de NULL → quebra para anon (auth.uid() é NULL sem sessão).
+- ❌ RLS habilitada com 0 policies → tabela inacessível para todos (parece bug de app).
+- ❌ Service role usada no código do app para "contornar" RLS → buraco de segurança, nunca fazer.
+
+## Cobertura de policies
+
+- **Boa:** 1 policy `FOR ALL` (abordagem KISS) OU 4 policies granulares (SELECT/INSERT/UPDATE/DELETE).
+- **Incompleta:** granular com 1–3 policies — operações não cobertas falham silenciosamente.
+- Granular por operação é preferível quando leitura e escrita têm regras diferentes.
+
+## Auditoria de cobertura
+
+```sql
+-- Tabelas sem RLS (risco)
+SELECT tablename FROM pg_tables
+WHERE schemaname='public' AND rowsecurity = false ORDER BY tablename;
+
+-- Cobertura por tabela
+SELECT t.tablename, COUNT(p.policyname) AS policies, ARRAY_AGG(p.cmd) AS cmds
+FROM pg_tables t
+LEFT JOIN pg_policies p ON p.tablename = t.tablename AND p.schemaname='public'
+WHERE t.schemaname='public' AND t.rowsecurity
+GROUP BY t.tablename ORDER BY policies;
+```
+
+Automático: `tools/db-ops/rls-test-suite.sh {table}` (matriz de permissões multi-usuário) e `tools/db-ops/rls-policy-installer.sh {table} {kiss|read-only|private|team|custom} [owner_column]`.
+
+## Teste obrigatório: positivo E negativo
+
+Toda policy é validada com impersonação de usuário real:
+
+```sql
+BEGIN;
+SET LOCAL role authenticated;
+SET LOCAL request.jwt.claims TO '{"sub":"<user-uuid>","role":"authenticated"}';
+-- caso positivo: o dono vê/edita suas linhas
+-- caso negativo: outro usuário NÃO vê/edita (0 linhas — não erro)
+ROLLBACK;
+```
+
+Sem camada de Auth presente, `auth.uid()` retorna NULL — avisar explicitamente. Rodar auditoria de RLS: após toda migration, antes de todo deploy, ao criar tabela nova.

package/template/pods/dev-ia/knowledge/db/schema-review-checklist.md

@@ -0,0 +1,76 @@
+# Checklist de Design e Revisão de Schema
+
+Usado em duas direções: desenhar schema novo (`*model`) e auditar schema existente (`*audit`).
+
+## Gate KISS — ANTES de qualquer design (obrigatório)
+
+O objetivo é impedir over-engineering. Passos, em ordem:
+
+0. **Contexto primeiro:** carregar o schema vivo (banco é a fonte da verdade). Nunca propor entidade sem saber o que já existe.
+1. **Validar realidade:** o sistema funciona hoje? Se funciona (filesystem/API ok, nada quebra) → PARAR.
+2. **Validar dor:** perguntar explicitamente ao usuário. "Não tem problema / funciona bem" → PARAR.
+3. **Alavancar o existente:** tabelas atuais resolvem? Estender tabela > criar tabela nova.
+4. **Incremento mínimo:** 0 mudanças > 1 campo > 1 tabela > várias tabelas.
+5. **Trade-offs:** apresentar opções (REUSE | EXTEND | CREATE | RECONSIDER); o usuário decide.
+
+**Red flags (qualquer um = parar e revalidar):** 3+ tabelas sem pedido explícito; 10+ campos sem dor validada; analytics/tracking presumido sem evidência; design para "necessidade futura"; não checou schema existente; <100 registros (considerar JSON/arquivo); usuário único (considerar SQLite); zero relacionamentos (reconsiderar se precisa de DB).
+
+**Regra de ouro:** "Se funciona hoje, mudar exige justificativa extraordinária."
+
+## Modelagem de domínio
+
+- [ ] Requisitos de negócio entendidos; entidades núcleo identificadas
+- [ ] Relacionamentos mapeados (1:1, 1:N, M:N — junção com PK composta ou própria)
+- [ ] Regras de negócio documentadas (viram CHECK/trigger, não só código de app)
+- [ ] Access patterns analisados ANTES do design (como os dados serão consultados?)
+- [ ] Escala estimada (linhas, QPS, crescimento)
+
+## Tabelas e tipos
+
+- [ ] Baseline em toda tabela: `id UUID PK (gen_random_uuid())`, `created_at`, `updated_at`
+- [ ] `TIMESTAMPTZ` (nunca TIMESTAMP) · `JSONB` (nunca JSON) · `TEXT` (não VARCHAR sem limite real) · `NUMERIC` para dinheiro (nunca FLOAT)
+- [ ] Normalização até 3NF, desnormalização só com justificativa de performance
+- [ ] Soft delete (`deleted_at`) quando trilha de auditoria for necessária
+- [ ] JSONB para perfis/metadata flexíveis; colunas para o que é consultado/indexado
+
+## Constraints (integridade no banco, não só no app)
+
+- [ ] FKs SEMPRE — com `ON DELETE/ON UPDATE` apropriados (CASCADE/SET NULL conscientes)
+- [ ] `NOT NULL` em campos obrigatórios; `DEFAULT` onde faz sentido
+- [ ] `CHECK` para regras de negócio; `UNIQUE` para chaves naturais
+- [ ] Nomes de constraint significativos (aparecem em erros)
+
+## Índices
+
+- [ ] TODA FK indexada (crítico para JOINs — não é automático!)
+- [ ] Colunas de WHERE e ORDER BY dos hot paths
+- [ ] Parciais para queries filtradas; GIN para JSONB/arrays/full-text
+- [ ] Colunas usadas em policies RLS indexadas
+- [ ] Sem índices redundantes/inúteis (verificar `pg_stat_user_indexes`)
+- [ ] Em produção: sempre `CREATE INDEX CONCURRENTLY`
+
+## Segurança
+
+- [ ] RLS em toda tabela exposta (ver `rls-patterns.md`); exceções documentadas
+- [ ] `auth.uid()` embrulhado em SELECT; `app_metadata`, nunca `user_metadata`
+- [ ] Policies testadas com impersonação (positivo E negativo)
+- [ ] Credenciais só por env var; SSL (`sslmode=require`) e pooler em produção
+- [ ] Dados sensíveis/PII: criptografia e conformidade (LGPD/GDPR); retenção definida
+
+## Performance e operação
+
+- [ ] `EXPLAIN (ANALYZE, BUFFERS)` nos hot paths; `pg_stat_statements` habilitado
+- [ ] Timeouts: `statement_timeout≈30s`, `lock_timeout≈10s`, `idle_in_transaction_session_timeout≈60s`
+- [ ] Pooling de conexões; particionamento se >100M linhas
+- [ ] Autovacuum ativo; `ANALYZE` após operações em massa; bloat monitorado
+- [ ] Backups diários automáticos + PITR; restore testado
+
+## Documentação
+
+- [ ] `COMMENT ON TABLE/COLUMN` para tudo que não é óbvio
+- [ ] Policies RLS e propósito de índices documentados
+- [ ] ERD atualizado; plano de migration documentado (ver `migration-protocol.md`)
+
+## Scorecard de auditoria (`*audit`)
+
+Para schema existente, gerar scorecard por seção (tabelas/constraints/índices/segurança/performance/docs) com: ✅ conforme, ⚠️ atenção, ❌ crítico. Todo ❌ vira item de ação com fix sugerido. Execução determinística: `tools/db-ops/best-practices-auditor.sh`.

package/template/pods/dev-ia/memory/README.md

@@ -0,0 +1,16 @@
+# Memória do pod `dev-ia` — OPERANTE (SF2.3)
+
+> Instalada por forge-generate.cjs via o motor `scripts/pod-memory.cjs` (SF2.1).
+> Tier: STANDARD/COMPLEX. Esta memória NÃO é scaffold morto: nasce cabeada ao lifecycle.
+
+## Cabeamento (nenhuma ação manual necessária)
+
+- `learnings.jsonl` — log cru append-only. O runner (`pc-run-pod`, SF2.2) faz `append()`
+  ao fim de cada etapa/run. O AGENTE NUNCA lê este arquivo (auditoria apenas).
+- `learnings.consolidated.md` — top-N curado (`consolidate()`), no path canônico que
+  `getConsolidatedForBrief()` entrega ao brief da run. É o ÚNICO que o agente lê.
+- Auditoria de aderência por run: `config/heuristic-watcher-rubric.yaml` +
+  `scripts/watcher-audit.cjs` (executado pelo `pod-critic`).
+
+Assim que este pod rodar via `pc-run-pod`, injeção do consolidado no brief e append de
+learnings funcionam sem qualquer passo manual — a operância é o cabeamento ao motor pronto.

package/template/pods/dev-ia/memory/learnings.consolidated.md

@@ -0,0 +1,8 @@
+# Memória consolidada — dev-ia
+
+> Curado por pod-memory.cjs (SF2.1). Único artefato de memória lido pelo agente.
+> Log cru (learnings.jsonl) NÃO é lido pelo agente — auditoria apenas.
+
+## Heurísticas (top-N)
+
+_Nenhuma heurística consolidada ainda._

package/template/pods/dev-ia/pod-spec.json

@@ -0,0 +1,34 @@
+{
+  "pod": "dev-ia",
+  "workflowId": "dev-ia",
+  "interface": true,
+  "critical": true,
+  "handoffs": 0,
+  "_adr": "ADR-004 adendo 2026-07-25 (forma STANDARD-interface, caso de fronteira SF6.2). Tier STANDARD/COMPLEX pela criticidade (db-architect: migrations/RLS), com supressão de wf-*.yaml e squad-io.yaml — zero handoff artefato-a-artefato entre os 2 especialistas. O processo do ciclo dev vive nas skills pc-* (validate-story-draft/develop-story/review-story/apply-qa-fixes/close-story/pc-commit), não neste pod. Fabricar um wf db->ux tornaria o pod um segundo orquestrador (anti-padrão 'frankenstein', ADR-001/§G4). Enforcement do crítico: QA adversarial (âncora opus) + gatilho de escalada 'migration de dados' da model-matrix + scripts determinísticos de tools/db-ops/ — tudo DENTRO do ciclo pc-*, onde o db-architect é acionado ad hoc por story.",
+  "_sources": {
+    "job_interface": "template/pods/dev-ia/README.md:5 — 'O ciclo já existe como skills; este pod é a formalização fina — o mapa de quando usar cada uma.' + README.md:13-20 (o ciclo dev é tabela de SKILLS, não de agentes do pod)",
+    "especialistas_ad_hoc": "template/pods/dev-ia/README.md:33-39 (secao 'Quando usar o quê' = condição->entrada: 'Schema, RLS, migration ou performance de banco -> db-architect'; ux-architect por 'Design de fluxo/UI') + agent-authority.md §'Papéis POWER CLAUDE' ('db-architect, ux-architect entram por gatilho registrado na story')",
+    "criticality_db": "agents/db-architect.md:19-20 (*migrate: fases verify-order->dry-run->snapshot->apply; *rls: policies RLS) — entregável crítico de persistência (ADR-004). O critical do pod é o MÁX dos 2 especialistas: db-architect critical:true domina ux-architect (critical:false).",
+    "agents_reais": "agents/db-architect.md (6 comandos: *model/*migrate/*rls/*optimize/*audit/*ops) + agents/ux-architect.md (4 missões: *flow/*review/*a11y/*ds) — 10 pontos de entrada independentes, nenhuma sequência declarada"
+  },
+  "interface_evidence": {
+    "zero_handoff_artefato": "Nenhum output de db-architect é input de ux-architect (ou vice-versa) no mesmo pedido. db-architect produz schema/DDL/migration/RLS/audit (persistência, agents/db-architect.md:18-23); ux-architect produz seção UX/veredito/a11y/tokens (interface, agents/ux-architect.md:18-21). Camadas ortogonais.",
+    "output_consumido_pelo_ciclo_nao_pelo_par": "agents/ux-architect.md:18 — *flow gera 'seção UX anexável à story, consumível pelo Dev sem ferramenta de design': o consumidor é o papel Dev do ciclo pc-*, NÃO o db-architect. Simetricamente, o schema/DDL do db-architect é consumido pela implementação (papel Dev), não pelo ux-architect.",
+    "invocacao_condicional_nao_sequencial": "README.md:33-39 é mapa condição->entrada, não pipeline. Nenhuma linha declara 'rode X depois Y' entre os 2 agentes; cada um é acionado ad hoc pela condição da story (agent-authority.md §'Papéis POWER CLAUDE').",
+    "processo_do_critico_fora_do_pod": "As etapas checkpointáveis do ciclo (validação de story, QA gate) já são as skills validate-story-draft/review-story (README.md:13-20). Formalizá-las aqui duplicaria o orquestrador (Escopo OUT da story SF6.2)."
+  },
+  "agents": [
+    {
+      "name": "db-architect",
+      "step": "schema-review",
+      "output": "schema-review",
+      "sections": ["## Contexto (schema vivo)", "## Modelagem / Mudança proposta", "## Migration (dry-run + rollback)", "## RLS e segurança", "## Índices e performance"]
+    },
+    {
+      "name": "ux-architect",
+      "step": "ux-flow-review",
+      "output": "ux-flow-review",
+      "sections": ["## Contexto (story/tela)", "## Fluxo e wireframe textual", "## Estados (loading/empty/error/success)", "## Acessibilidade essencial", "## Veredito por severidade"]
+    }
+  ]
+}

package/template/pods/dev-ia/templates/schema-review-tmpl.md

@@ -0,0 +1,23 @@
+# Template de saída — etapa `schema-review` (agente `db-architect`, artefato `schema-review`)
+
+> Gerado por forge-generate.cjs (SF1.4 + ADR-005). Preencher com o artefato real da etapa.
+> FORMA (seções `##`) verificada por checkTemplateConformance; VETO ORTOGONAL via o
+> campo de máquina `confianca` abaixo (fora dos headings — ADR-005 Decisão A).
+
+## Contexto (schema vivo)
+<!-- preencher: conteúdo de "Contexto (schema vivo)" -->
+
+## Modelagem / Mudança proposta
+<!-- preencher: conteúdo de "Modelagem / Mudança proposta" -->
+
+## Migration (dry-run + rollback)
+<!-- preencher: conteúdo de "Migration (dry-run + rollback)" -->
+
+## RLS e segurança
+<!-- preencher: conteúdo de "RLS e segurança" -->
+
+## Índices e performance
+<!-- preencher: conteúdo de "Índices e performance" -->
+
+<!-- Campo de máquina do veto default (ADR-005) — NÃO é heading. Troque o placeholder por alta|media|baixa. -->
+confianca: <alta|media|baixa>

package/template/pods/dev-ia/templates/ux-flow-review-tmpl.md

@@ -0,0 +1,23 @@
+# Template de saída — etapa `ux-flow-review` (agente `ux-architect`, artefato `ux-flow-review`)
+
+> Gerado por forge-generate.cjs (SF1.4 + ADR-005). Preencher com o artefato real da etapa.
+> FORMA (seções `##`) verificada por checkTemplateConformance; VETO ORTOGONAL via o
+> campo de máquina `confianca` abaixo (fora dos headings — ADR-005 Decisão A).
+
+## Contexto (story/tela)
+<!-- preencher: conteúdo de "Contexto (story/tela)" -->
+
+## Fluxo e wireframe textual
+<!-- preencher: conteúdo de "Fluxo e wireframe textual" -->
+
+## Estados (loading/empty/error/success)
+<!-- preencher: conteúdo de "Estados (loading/empty/error/success)" -->
+
+## Acessibilidade essencial
+<!-- preencher: conteúdo de "Acessibilidade essencial" -->
+
+## Veredito por severidade
+<!-- preencher: conteúdo de "Veredito por severidade" -->
+
+<!-- Campo de máquina do veto default (ADR-005) — NÃO é heading. Troque o placeholder por alta|media|baixa. -->
+confianca: <alta|media|baixa>