nexus-core-v3 3.0.0

package/knowledge/marketing/funil-e-jornada.md

@@ -0,0 +1,36 @@
+# Funil e jornada — a mensagem certa na etapa certa
+
+A pessoa não acorda querendo comprar. Ela percorre uma jornada — da dor que ainda não nomeou até a
+decisão de pagar — e cada etapa precisa de uma mensagem diferente. A campanha que fala de compra para
+quem ainda descobre a dor desperdiça a melhor peça no público errado.
+
+## As etapas da jornada
+
+| Etapa | Estado mental | Mensagem que funciona | Métrica |
+|---|---|---|---|
+| **Descoberta (topo)** | "tenho um problema?" | conteúdo que nomeia e educa sobre a dor | alcance qualificado, tempo de leitura |
+| **Consideração (meio)** | "quais são as opções?" | comparação, prova, casos, critérios de escolha | leads, inscrições, retorno ao site |
+| **Decisão (fundo)** | "esta é a escolha certa?" | copy de conversão, remoção de objeção, oferta | conversão, receita |
+| **Retenção (pós)** | "valeu a pena?" | onboarding, primeiro valor, sucesso do cliente | ativação, churn, expansão |
+
+Peça no funil errado = orçamento desperdiçado. O conteúdo de fundo (oferta, urgência) empurra quem
+ainda está descobrindo; o de topo (educação) entedia quem já quer comprar.
+
+## Coerência de mensagem entre canais
+
+A promessa central é a MESMA em todo canal — o que muda é a língua (formato nativo), não o fundo. O
+anúncio, o post e a landing dizem a mesma coisa, adaptada. Contradição entre canais quebra a confiança
+e mata a conversão.
+
+## Métrica real vs vaidade
+
+- **Vaidade:** curtida, impressão, alcance bruto, seguidores. Sobem sem mover o negócio.
+- **Real:** lead qualificado, ativação, receita, retenção. Ligam-se ao resultado.
+- Regra: se o número não muda a próxima decisão, ele não entra no relatório como sucesso.
+
+## Anti-padrões
+
+- Uma mensagem única para toda a jornada — a dor de cada etapa é diferente.
+- Comemorar vaidade — curtida não paga conta.
+- Cross-post idêntico — cada canal tem sua língua; copiar e colar o algoritmo pune.
+- Campanha sem métrica-alvo definida antes de ir ao ar — vira opinião com orçamento.

package/knowledge/negocios/proposta-vencedora.md

@@ -0,0 +1,38 @@
+# A proposta que vende a transformação
+
+Uma proposta comercial não é um catálogo de features com preço no fim. É um argumento: o cliente tem
+uma dor, ela custa caro, e existe um caminho para resolvê-la que vale mais do que custa. Tudo o mais
+é embalagem.
+
+## A estrutura que fecha
+
+1. **A dor do cliente (não a nossa empresa).** Abra pelo custo real de não resolver — tempo perdido,
+   dinheiro vazando, risco correndo. Se o primeiro parágrafo fala de "nós", o cliente parou de ler.
+2. **A transformação (não a feature).** Cada capacidade relevante vira o que muda na vida do cliente.
+   "Dashboard em tempo real" é feature; "você para de descobrir o problema no dia seguinte" é venda.
+3. **A oferta.** O que ele recebe, por quanto, com qual garantia ou risco reduzido.
+4. **A prova.** O retorno quantificado (ROI), casos, ou a redução de risco que torna o "sim" seguro.
+5. **A única ação seguinte.** Um próximo passo claro, sem atrito. Cinco call-to-actions = nenhuma decisão.
+
+## Feature → benefício → transformação
+
+| Feature (o que faz) | Benefício (o que muda) | Transformação (quem ele vira) |
+|---|---|---|
+| Relatório automático | Economiza 4h/semana | Deixa de ser refém da planilha |
+| Alerta em tempo real | Erro pego na hora | Para de apagar incêndio no dia seguinte |
+| Integração com X | Fim do retrabalho manual | Confia no dado sem reconferir |
+
+O rascunho para na coluna 1. A proposta chega na coluna 3.
+
+## Anti-padrões (o que rasgar)
+
+- Abrir com "somos líderes de mercado" — o cliente compra a dor dele, não o nosso currículo.
+- Vender a lista de features — ninguém compra capacidade, compram resultado.
+- Prometer o que o produto não entrega hoje — proposta é contrato moral; overselling é churn assinado.
+- Terminar sem ação seguinte — a proposta perfeita sem próximo passo não converte.
+
+## Retenção começa na proposta
+
+A venda só fecha de verdade quando o cliente ativa e fica. O caminho até o primeiro valor (o cliente
+sentir que valeu antes de duvidar) faz parte da oferta, não é um "depois". Venda que não ativa é
+receita emprestada.

package/knowledge/negocios/roi-e-unit-economics.md

@@ -0,0 +1,46 @@
+# ROI e unit economics — a conta honesta
+
+ROI não é um argumento de venda — é uma conta que o cliente reconhece como dele. O ROI que fecha a
+venda com premissa inflada é o mesmo que abre o ticket de cancelamento seis meses depois. A régua é
+simples: todo número tem origem, e a origem é o cliente.
+
+## A conta do ROI
+
+```
+ROI (%) = (ganho − custo) / custo × 100
+ganho   = economia gerada + receita nova (no horizonte de análise)
+custo   = preço + implantação + custo de operação
+payback = tempo até o ganho acumulado igualar o custo
+```
+
+- **Horizonte explícito.** ROI de 12 meses e de 36 meses são histórias diferentes — diga qual.
+- **Premissa marcada.** Cada número: dado do cliente, benchmark citável, ou estimativa marcada COMO
+  estimativa. Número sem origem é chute com casa decimal.
+
+## Análise de sensibilidade (o que mata a conta)
+
+Não basta o ROI ser positivo. Pergunte: se a premissa-chave errar 20%, a conta ainda fecha?
+
+| Cenário | Premissa-chave | Payback |
+|---|---|---|
+| Otimista | volume alto | 14 meses |
+| Base | volume esperado | 18 meses |
+| Conservador | volume −20% | 22 meses |
+
+Apresente os três. O cliente confia mais em quem mostra o cenário ruim do que em quem só mostra o bom.
+
+## Unit economics — a pergunta antes da escala
+
+Se a conta não fecha em UMA unidade (um cliente, um pedido, um mês), escalar só multiplica o prejuízo.
+
+- **LTV** (lifetime value) — quanto um cliente gera enquanto fica.
+- **CAC** (custo de aquisição) — quanto custou trazê-lo.
+- **Regra:** `LTV > CAC` (idealmente 3×), e o CAC se paga dentro de um horizonte curto (payback de CAC).
+- Se `LTV < CAC`, cada venda nova aprofunda o rombo — o crescimento é o problema, não a solução.
+
+## Anti-padrões
+
+- Usar a premissa que fecha a venda em vez da que o cliente confirma.
+- Esconder a sensibilidade — o retorno frágil precisa aparecer frágil.
+- ROI sem horizonte — "3x de retorno" sem prazo não significa nada.
+- Escalar antes de a unidade fechar — multiplicar prejuízo não é growth.

package/knowledge/pipeline/1-descobrir.md

@@ -0,0 +1,26 @@
+---
+fase: descobrir
+titulo: Descobrir
+agentesAtivos: [analyst, pm]
+outputs:
+  - project-brief.md
+  - achados de pesquisa
+gate:
+  gateKeeper: analyst
+  checklistRef: discovery-checklist
+  criterios:
+    - criterio: Problema real e usuário/segmento nomeado
+      evidenciaExigida: entrevista, dado, ticket ou observação que comprove a dor
+    - criterio: Valor da solução articulado
+      evidenciaExigida: impacto x frequência x alcance estimados
+    - criterio: Riscos e incógnitas listados
+      evidenciaExigida: lista explícita do que ainda não se sabe
+---
+
+# Fase 1 — Descobrir
+
+Entende-se o problema antes de propor solução. O Alex conduz a pesquisa e o Morgan traduz o achado em
+direção. Nada de código, nada de arquitetura — só a verdade sobre a dor, o usuário e o valor.
+
+**Gate:** o `discovery-checklist` guarda a saída. Sem problema real, usuário nomeado e evidência da dor,
+não se avança — descoberta rasa vira produto errado construído com perfeição.

package/knowledge/pipeline/2-estrategizar.md

@@ -0,0 +1,26 @@
+---
+fase: estrategizar
+titulo: Estrategizar
+agentesAtivos: [pm, po]
+outputs:
+  - prd.md
+  - épicos priorizados
+gate:
+  gateKeeper: pm
+  checklistRef: pm-checklist
+  criterios:
+    - criterio: PRD com FRs/NFRs rastreáveis
+      evidenciaExigida: cada requisito numerado e ligado a uma dor da Descoberta
+    - criterio: Escopo e não-escopo explícitos
+      evidenciaExigida: lista do que fica de fora desta versão
+    - criterio: Épicos priorizados por valor x risco
+      evidenciaExigida: ordenação justificada, não intuição
+---
+
+# Fase 2 — Estrategizar
+
+Transforma-se a dor validada em direção de produto. O Morgan escreve o PRD (FRs/NFRs, escopo, épicos) e
+o Pax garante que cada item rastreia a um problema real e cabe no backlog.
+
+**Gate:** o `pm-checklist` guarda a saída. Estratégia sem rastreabilidade ao problema é invenção — cada
+requisito tem de puxar de uma dor da Descoberta (Article IV — No Invention).

package/knowledge/pipeline/3-estruturar.md

@@ -0,0 +1,27 @@
+---
+fase: estruturar
+titulo: Estruturar
+agentesAtivos: [architect, data-engineer]
+outputs:
+  - architecture.md
+  - schema-design.md
+  - ADRs
+gate:
+  gateKeeper: architect
+  checklistRef: foundation-checklist
+  criterios:
+    - criterio: NFRs quantificados e fronteiras definidas
+      evidenciaExigida: números-alvo de escala/latência/segurança/custo
+    - criterio: Dados modelados e propriedade definida
+      evidenciaExigida: entidades, relações e estado inicial documentados
+    - criterio: Decisões estruturais registradas
+      evidenciaExigida: ADRs com alternativas rejeitadas
+---
+
+# Fase 3 — Estruturar
+
+Desenha-se a fundação técnica. A Aria decide arquitetura e tecnologia; a Dara modela os dados e as
+migrações. É aqui que a fundação nasce reta — ou o dia 30 cobra o retrabalho.
+
+**Gate:** o `foundation-checklist` guarda a saída. NFRs quantificados, segurança na fundação e
+rastreabilidade total (No Invention) são críticos — sem eles, "construir" vira aposta.

package/knowledge/pipeline/4-construir.md

@@ -0,0 +1,27 @@
+---
+fase: construir
+titulo: Construir
+agentesAtivos: [dev, ux-design-expert]
+outputs:
+  - código implementado
+  - testes
+  - evidência de execução
+gate:
+  gateKeeper: dev
+  checklistRef: story-dod-checklist
+  criterios:
+    - criterio: Todos os ACs implementados e testados
+      evidenciaExigida: teste verde por AC (Given-When-Then)
+    - criterio: Suíte e lint verdes
+      evidenciaExigida: saída real de npm run check exit 0
+    - criterio: File List completa
+      evidenciaExigida: todo arquivo tocado listado na story
+---
+
+# Fase 4 — Construir
+
+Implementa-se a story seguindo o spec. O Dex escreve o código com testes; a Uma garante que a interface
+segue o design system (rota design-primeiro para entregável visual). Cada AC vira código + teste.
+
+**Gate:** o `story-dod-checklist` (DoD) guarda a saída. O Dex se auto-verifica antes de entregar ao QA —
+suíte verde, ACs cobertos, File List real. "Feito" sem teste não é feito.

package/knowledge/pipeline/5-endurecer.md

@@ -0,0 +1,28 @@
+---
+fase: endurecer
+titulo: Endurecer
+agentesAtivos: [qa]
+outputs:
+  - QaVerdict
+  - evidência visual
+  - QA Results na story
+gate:
+  gateKeeper: qa
+  checklistRef: reality-check-checklist
+  checklistRefsExtra: [design-quality-checklist]
+  criterios:
+    - criterio: Executado, não lido — suíte + fluxo exercitados
+      evidenciaExigida: log da execução real, não impressão do diff
+    - criterio: Evidência anexada a cada afirmação de pronto
+      evidenciaExigida: teste verde, screenshot, console limpo
+    - criterio: Regressão para todo bug corrigido
+      evidenciaExigida: teste que reproduzia o bug (red antes do green)
+---
+
+# Fase 5 — Endurecer
+
+A Quinn ataca o que vai falhar em produção: executa, coleta evidência visual, roda o reality-check e
+emite o `<verdict>`. O default é NEEDS WORK — READY só com evidência esmagadora.
+
+**Gate:** o `reality-check-checklist` guarda a saída. Reprovar 2–3 vezes aqui é o processo funcionando.
+Sem execução e sem evidência, não há PASS — o gate não atesta o que não viu.

package/knowledge/pipeline/6-lancar.md

@@ -0,0 +1,27 @@
+---
+fase: lancar
+titulo: Lançar
+agentesAtivos: [devops]
+outputs:
+  - release assinado
+  - changelog
+  - rollback ensaiado
+gate:
+  gateKeeper: devops
+  checklistRef: launch-checklist
+  criterios:
+    - criterio: Gate de qualidade verde antes do tráfego
+      evidenciaExigida: Endurecer com PASS + npm run check exit 0
+    - criterio: Rollback exercitado, não só documentado
+      evidenciaExigida: registro do ensaio de volta
+    - criterio: Assinatura de release verificada
+      evidenciaExigida: verificação fail-closed da assinatura do artefato
+---
+
+# Fase 6 — Lançar
+
+O Gage leva à produção com rede de segurança: assinatura verificada, rollback ensaiado, observabilidade
+de pé ANTES do tráfego, rollout gradual atrás de flag. Lançar é irreversível na prática.
+
+**Gate:** o `launch-checklist` guarda a saída. Sem gate verde, sem volta garantida e sem alertas ativos,
+o lançamento segura — um dia de preparo custa menos que um incidente com o usuário.

package/knowledge/pipeline/7-operar.md

@@ -0,0 +1,27 @@
+---
+fase: operar
+titulo: Operar
+agentesAtivos: [devops, architect]
+outputs:
+  - métricas e alertas em produção
+  - runbooks de incidente
+  - relatório de operação
+gate:
+  gateKeeper: devops
+  criterios:
+    - criterio: Observabilidade viva (métricas, logs, alertas)
+      evidenciaExigida: dashboards e alertas respondendo a dados reais
+    - criterio: Resposta a incidente ensaiada
+      evidenciaExigida: runbook executável + dono de plantão definido
+    - criterio: Dívida e aprendizados capturados
+      evidenciaExigida: itens registrados para a próxima Descoberta
+---
+
+# Fase 7 — Operar
+
+O dia 2 em diante: o Gage cuida da saúde em produção e a Aria avalia o que a realidade ensinou. Aqui
+não há checklist único — o gate é a operação REAL respondendo (observabilidade viva, incidente
+ensaiado), e o aprendizado volta a alimentar a Descoberta (o ciclo fecha).
+
+**Gate:** critérios de operação, sem checklist fixo. Produção que não se observa não se opera — e
+aprendizado que não se captura é retrabalho futuro.

package/knowledge/security/lgpd-conformidade-basica.md

@@ -0,0 +1,35 @@
+# Conformidade de dados — o essencial (LGPD/GDPR)
+
+Conformidade de dados pessoais não é o departamento jurídico dizendo "não" — é o contrato entre o
+produto e o titular do dado. O essencial cabe em cinco perguntas que todo sistema que toca dado
+pessoal precisa responder com FUNÇÃO, não com promessa.
+
+## As cinco perguntas
+
+1. **Base legal** — por que temos o direito de coletar isto? (consentimento, execução de contrato,
+   obrigação legal, legítimo interesse). Sem base declarada, a coleta é indevida.
+2. **Finalidade** — para que este dado específico é usado? A finalidade precede a coleta; dado sem
+   finalidade é passivo.
+3. **Minimização** — coletamos só o necessário para a finalidade? Campo "por via das dúvidas" viola.
+4. **Retenção** — por quanto tempo guardamos, e existe descarte automático quando a finalidade acaba?
+   Retenção sem prazo é não-conformidade.
+5. **Direitos do titular** — acesso, correção, exclusão e portabilidade EXISTEM como operação real?
+   Prometer na política e não implementar é pior que não prometer.
+
+## Dados sensíveis (tratamento reforçado)
+
+Saúde, biometria, origem racial/étnica, convicção religiosa/política, orientação sexual, dados de
+crianças e adolescentes: base legal mais estrita, minimização agressiva, e exposição = severidade P0.
+
+## Sinais de não-conformidade (achados comuns)
+
+- PII em logs/telemetria (nome, CPF, e-mail em texto plano no log).
+- Retenção infinita (nunca se apaga nada "por segurança").
+- Consentimento amarrado — "aceite tudo ou não use" para finalidades separáveis.
+- Direito do titular como promessa sem função (não há endpoint que exclui/exporta).
+- Compartilhamento com terceiro sem base nem registro.
+
+## Como emitir o parecer
+
+Cada não-conformidade cita: o dado concreto, o princípio/artigo violado, o risco (exposição/multa/
+quebra de confiança) e a correção mínima. Severidade amarrada ao risco: exposição de PII sensível = P0.

package/knowledge/security/owasp-secure-coding-gates.md

@@ -0,0 +1,220 @@
+---
+id: owasp-secure-coding-gates
+domain: security
+agents: [qa]
+when: "ao revisar código quanto a segurança antes de commit/merge"
+---
+
+# OWASP Secure Coding Gates — o que reprova ou aprova um diff
+
+> Fonte: OWASP CheatSheetSeries (github.com/OWASP/CheatSheetSeries) — XSS Prevention,
+> SQL Injection Prevention, Password Storage, Authentication, Session Management,
+> Input Validation e CI/CD Security Cheat Sheets. As regras abaixo são citação/derivação direta
+> dessas folhas, não opinião.
+
+## O problema
+
+Code review de segurança vira teatro quando o revisor escreve "valide o input" e "cuidado com XSS"
+e aprova. Isso não é gate — é prosa. Um gate de verdade tem **critério binário**: olha-se o sink, o
+contexto e o construtor da query, e decide-se REPROVA ou APROVA com base num fato verificável no
+diff. Os tells de revisão fraca:
+
+- "Sanitize tudo" — sanitização global no input é a **defesa errada**; o certo é encoding por
+  **contexto de saída** e parametrização na query. Quem sanitiza no input deixa passar o que importa.
+- Aceitar `escape()` manual de aspas em SQL como mitigação ("STRONGLY DISCOURAGED" pela OWASP).
+- Aprovar hash de senha com SHA-256/MD5 "com salt" achando que resolve.
+- Pinar GitHub Action por tag (`@v4`) achando que é versão fixa — tag é mutável.
+- Confiar em validação client-side de input.
+
+## O conhecimento / os princípios
+
+### 1. XSS — encoding é por CONTEXTO de saída, não global
+
+A regra-mãe da OWASP: a mesma variável precisa de encoding **diferente** dependendo de **onde** ela é
+escrita no HTML. Não existe "encoding universal". Cada contexto tem seu sink seguro e seu esquema.
+
+| Contexto de saída | Encoding exigido | Sink seguro (aprova) | Sink perigoso (reprova) |
+|---|---|---|---|
+| Corpo HTML (`<div>$var</div>`) | HTML entity: `&`→`&amp;` `<`→`&lt;` `>`→`&gt;` `"`→`&quot;` `'`→`&#x27;` | `.textContent`, `createTextNode()`, `.insertAdjacentText()` | `innerHTML`, `outerHTML`, `document.write()` |
+| Atributo HTML (`<div id="$var">`) | HTML attribute encoding `&#xHH;` **+ aspas obrigatórias** em volta do valor | `.setAttribute(nomeFixo, var)`, `.className` | atributo sem aspas; nome de atributo dinâmico |
+| JavaScript (dentro de `<script>` ou `on*`) | JS encoding `\xHH`, **só em valor entre aspas** | `JSON.parse`/dados, nunca código | `eval()`, `setTimeout(str)`, `setInterval(str)`, gerar código com a var |
+| URL (`href`/`src`) | URL encoding `%HH`, **depois** HTML attribute encoding | `encodeURIComponent(x)` | concatenar em `href` sem validar esquema (`javascript:` passa) |
+| CSS (valor de propriedade) | só em **valor** de propriedade CSS | `style.property = x` | var em nome de propriedade ou seletor; `url(javascript:...)` |
+
+**Contextos perigosos — REPROVA sempre que a var entra direto neles** (encoding não protege):
+`<script>` diretamente, dentro de comentário HTML `<!-- -->`, `<style>` direto, nome de handler de
+evento, callback de função.
+
+**HTML autorado pelo usuário** (precisa permitir tags): único caminho aprovado é sanitização com
+**DOMPurify** — `let clean = DOMPurify.sanitize(dirty);` — e **nunca** modificar a string depois de
+sanitizada (re-mutação reabre o buraco).
+
+Framework com auto-escape (React/Angular/Lit) **aprova por padrão**, mas REPROVA se o diff usa o
+escape-hatch sem sanitização: `dangerouslySetInnerHTML` (React), `bypassSecurityTrustAs*` (Angular),
+`unsafeHTML` (Lit), `inner-h-t-m-l` (Polymer).
+
+### 2. SQL Injection — parametrização, não escaping
+
+A defesa primária é **prepared statement com query parametrizada**: o SQL é definido inteiro primeiro,
+e o valor entra como bind variable depois. Concatenar input na string da query é REPROVA imediata.
+
+```java
+// REPROVA — concatenação de input na query
+String query = "SELECT account_balance FROM user_data WHERE user_name = "
+             + request.getParameter("customerName");
+Statement statement = connection.createStatement();
+ResultSet rs = statement.executeQuery(query);
+
+// APROVA — prepared statement, valor via setString
+String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
+PreparedStatement pstmt = connection.prepareStatement(query);
+pstmt.setString(1, request.getParameter("customerName"));
+ResultSet rs = pstmt.executeQuery();
+```
+
+```java
+// ORM também: HQL concatenado REPROVA
+Query bad  = session.createQuery("from Inventory where productID='" + userParam + "'");
+// APROVA — named parameter
+Query good = session.createQuery("from Inventory where productID=:productid");
+good.setParameter("productid", userParam);
+```
+
+`escape()` manual de aspas é **"STRONGLY DISCOURAGED"** e "fragile compared to other defenses" — não
+aceitar como mitigação suficiente.
+
+**O que NÃO pode ser parametrizado** (bind variable não cobre): **nome de tabela, nome de coluna,
+e ordem `ASC`/`DESC`**. Nesses casos a única defesa aprovada é **allow-list mapeando para valores
+fixos**, nunca passar o input adiante:
+
+```java
+// APROVA — nome de tabela via allow-list (switch), nunca concatenado
+switch (param) {
+  case "Value1": tableName = "fooTable"; break;
+  case "Value2": tableName = "barTable"; break;
+  default: throw new InputValidationException("unexpected value provided for table name");
+}
+// APROVA — sort order mapeado a literal, não concatenado do input
+String sql = "... order by Salary " + (sortOrder ? "ASC" : "DESC");
+```
+
+### 3. Armazenamento de senha — ordem de algoritmo e parâmetros mínimos
+
+Hash genérico (MD5, SHA-1, SHA-256), mesmo com salt, **REPROVA**. A OWASP define ordem de preferência
+e parâmetros numéricos mínimos:
+
+| Ordem | Algoritmo | Parâmetros mínimos (OWASP) |
+|---|---|---|
+| 1º | **Argon2id** | `m=19456` (19 MiB), `t=2`, `p=1` (ou m=47104/t=1, ou m=7168/t=5) |
+| 2º | **scrypt** (se Argon2id indisponível) | `N=2^17` (128 MiB), `r=8`, `p=1` |
+| 3º | **bcrypt** (legado) | work factor **≥ 10**; limite de **72 bytes** de senha |
+| 4º | **PBKDF2** (só p/ FIPS-140) | SHA-256: **600.000** iter · SHA-512: **220.000** iter |
+
+bcrypt tem dois caveats que REPROVAM se ignorados: o limite de 72 bytes e o **null byte** truncando o
+hash. Pré-hash recomendado: `bcrypt(base64(hmac-sha384(data:$password, key:$pepper)), $salt, $cost)`.
+
+**Pepper** (opcional, reforça): é compartilhado entre as senhas, **não** é armazenado junto do hash —
+fica em secrets vault/HSM, separado do banco.
+
+### 4. Autenticação — lockout, mensagens genéricas, comprimento, MFA
+
+| Regra | Critério (REPROVA se violado) |
+|---|---|
+| Anti-brute-force | Lockout por **conta** (não por IP). Threshold + janela de observação + duração; ideal **exponencial** (1s dobrando a cada falha). CAPTCHA/throttling complementam. |
+| Mensagem de erro | **Genérica e idêntica** p/ usuário inexistente, senha errada ou conta desabilitada: `"Login failed; Invalid user ID or password."` Revelar qual falhou = enumeração = REPROVA. |
+| Recuperação de senha | Mensagem genérica: `"If that email address is in our database, we will send you an email to reset your password"`. |
+| Comprimento mínimo | **8** com MFA ativo · **15** sem MFA. Máximo **≥ 64** (permitir passphrase). Aceitar Unicode/espaço; sem regra de composição obrigatória. |
+| MFA | "by far the best defense" — teria prevenido **99.9%** dos comprometimentos. Exigir em fluxos sensíveis. |
+
+### 5. Gestão de sessão — atributos de cookie e ciclo de vida
+
+Cookie de sessão tem que carregar **todos** estes atributos — falta de qualquer um REPROVA:
+
+```
+Set-Cookie: __Host-SessionID=<value>; Secure; HttpOnly; SameSite=Strict; Path=/
+```
+
+| Atributo | Exigência |
+|---|---|
+| `Secure` | obrigatório — só trafega via HTTPS |
+| `HttpOnly` | obrigatório — JS não lê via `document.cookie` (corta roubo por XSS) |
+| `SameSite` | `Strict` (preferido) ou `Lax`. **Nunca** `None` sem `Secure`. |
+| Prefixo `__Host-` | recomendado p/ session ID (força Secure + Path=/ + sem Domain) |
+
+| Propriedade | Critério |
+|---|---|
+| Entropia do session ID | **≥ 64 bits** (≥ 16 chars hex); gerar via **CSPRNG** com saída ≥ 128 bits. Conteúdo "meaningless" — sem PII. |
+| Idle timeout | 2–5 min (alto valor) · 15–30 min (baixo risco) |
+| Absolute timeout | 4–8 h |
+| Regeneração | **Regenerar o ID após login / qualquer mudança de privilégio** (`session_regenerate_id(true)` em PHP). Não regenerar = fixação de sessão = REPROVA. |
+| Logout | Invalidar server-side (framework) **e** expirar o cookie no cliente (`Expires` no passado / `Max-Age=0`); `Cache-Control: no-store`. |
+
+### 6. Validação de input — allow-list, server-side, e não é defesa primária
+
+| Princípio | Regra |
+|---|---|
+| Allow-list > deny-list | Defina **o que É permitido**; tudo o mais é negado. Deny-list "é trivial de burlar" e bloqueia input válido (`O'Brian`). Deny-list só como camada extra, nunca primária. |
+| Onde validar | **Server-side, antes de processar.** Validação client-side (JS) "can be circumvented" — não conta como controle. |
+| Syntactic vs semantic | Syntactic: formato (SSN, data, moeda). Semantic: regra de negócio (start < end, preço na faixa). |
+| Escopo | Validação **não** é defesa primária contra XSS/SQLi — "should not be used as the primary method". Reduz impacto, mas **encoding por contexto e parametrização continuam sendo a defesa primária**. Aprovar input validation no lugar de parametrização = REPROVA. |
+
+### 7. Segurança de CI/CD — secrets, least-privilege, pin por SHA
+
+| Área | Critério (REPROVA se violado) |
+|---|---|
+| Secrets no código | **Nunca** hardcoded em repo ou config de pipeline. Detectar com **git-leaks/git-secrets**. Não imprimir/logar em console, log ou histórico de comando. |
+| Vault + credenciais curtas | Usar HashiCorp Vault / AWS Secrets Manager / CyberArk. Preferir **credenciais temporárias/OTP** (ou OIDC) a token longevo. |
+| Least privilege | "deny by default". Pipeline com mínimo de permissão; conta de OS do runner **sem root**. Não compartilhar credencial entre pipelines de sensibilidades diferentes. |
+| Pin de dependência/action | **Version pinning + verificação de hash/checksum** contra hash bom conhecido. Em lockfile (`package-lock.json`/`Pipfile.lock`) e **enforce o lockfile**. Para GitHub Actions, pinar por **commit SHA** (tag é mutável → REPROVA pinar por `@v4`). |
+| SCM | Branches protegidos; PR **revisado e não-bypassável** antes do merge; **sem auto-merge**; MFA habilitado; commits **assinados** (Sigstore/Signserver). |
+| Execução | Builds em nós isolados; comunicação SCM↔CI via **TLS 1.2+**; restringir acesso por IP; **aprovação manual** antes de deploy em produção; Docker **sem `--privileged`**. |
+| Logs | Formato parseável (JSON/syslog); **nunca** logar senha/token/API key em texto puro; centralizar em SIEM com alertas. |
+
+## Checklist (responda — qualquer "não" reprova o diff)
+
+XSS
+- [ ] Toda var dinâmica usa encoding do **contexto** correto (HTML body / attr / JS / URL / CSS)?
+- [ ] Nenhum `innerHTML`/`document.write`/`eval`/`setTimeout(string)` com dado de usuário?
+- [ ] HTML autorado pelo usuário passa por **DOMPurify** e não é mutado depois?
+- [ ] Nenhum escape-hatch de framework (`dangerouslySetInnerHTML`, `bypassSecurityTrustAs*`) sem sanitização?
+
+SQLi
+- [ ] Toda query usa **prepared statement / bind variable** (zero concatenação de input)?
+- [ ] Nome de tabela/coluna/`ASC|DESC` vem de **allow-list**, não do input?
+- [ ] Nenhuma mitigação baseada só em `escape()` de aspas?
+
+Auth & senha
+- [ ] Senha hasheada com **Argon2id/scrypt/bcrypt** nos parâmetros mínimos (não SHA/MD5)?
+- [ ] Lockout por conta + mensagem de erro genérica (sem enumeração)?
+- [ ] Mínimo 8 (c/ MFA) ou 15 (s/ MFA), máximo ≥ 64?
+
+Sessão
+- [ ] Cookie com `Secure; HttpOnly; SameSite=Strict/Lax` (e `__Host-` no session ID)?
+- [ ] ID com ≥ 128 bits de CSPRNG; **regenerado no login**; invalidado no logout?
+- [ ] Idle e absolute timeout definidos?
+
+Input & CI/CD
+- [ ] Validação **allow-list, server-side** — e não substituindo parametrização/encoding?
+- [ ] Zero secret hardcoded; vault + credencial curta/OIDC?
+- [ ] Actions/deps pinadas por **SHA + hash** em lockfile enforçado; runner sem root, sem `--privileged`?
+- [ ] PR revisado não-bypassável, sem auto-merge, aprovação manual p/ produção?
+
+## Tabela de decisão "use X quando Y"
+
+| Quando (Y) | Use (X) |
+|---|---|
+| Var vai dentro de `<div>`/corpo HTML | HTML entity encoding ou `.textContent` |
+| Var vai num atributo HTML (`id`, `class`...) | attribute encoding `&#xHH;` + aspas + `setAttribute(nomeFixo, var)` |
+| Var vai dentro de `<script>` / handler `on*` | JS encoding `\xHH` só em valor entre aspas; nunca gerar código |
+| Var vira `href`/`src` | `encodeURIComponent` + attribute encoding; validar esquema (bloquear `javascript:`) |
+| Usuário precisa enviar HTML rico | DOMPurify, sem mutar depois |
+| Valor de usuário num `WHERE`/`VALUES` | prepared statement + bind variable |
+| Parte da query é nome de tabela/coluna/sort | allow-list → literal fixo (switch/map) |
+| Armazenar senha nova | Argon2id (m=19456,t=2,p=1); senha longa → pré-hash bcrypt c/ HMAC |
+| Compliance FIPS-140 impede Argon2 | PBKDF2-HMAC-SHA256 600k iter |
+| Cookie de sessão | `__Host-`/`Secure; HttpOnly; SameSite=Strict; Path=/` |
+| Após autenticar / elevar privilégio | regenerar session ID |
+| Filtrar input de usuário | allow-list, server-side (complemento, não substituto de encoding/parametrização) |
+| Credencial no pipeline | vault + token curto/OIDC, nunca hardcoded |
+| Consumir GitHub Action / dependência externa | pin por commit SHA + hash em lockfile enforçado |
+| Pipeline acessa recurso de plataforma | least privilege, deny-by-default, runner sem root |