As quatro falhas que este capítulo precisa resolver

Falha 1 — retry infinito

Sintoma: a entrega de um evento (suggestion.reviewed, para o outbox) que falha continua sendo tentada para sempre — sem teto, sem backoff, sem sinal visível de que está em curso.

Causa: naiveRedeliverForever, mantido no código só para o teste comparar, nunca chamado em nenhum caminho real:

export async function naiveRedeliverForever(repo, sink, event, nowIso) {
  let attempts = 0;
  for (;;) {
    attempts += 1;
    try {
      await sink.deliver(event);
      await repo.markOutboxDelivered(event.id, nowIso);
      return { attempts };
    } catch {
      // sem teto, sem backoff, sem dead-letter: tenta de novo imediatamente
    }
  }
}

O detalhe mais perigoso não é o laço sem fim — é que, enquanto ele roda, o contador attempts da linha na tabela nunca é atualizado, porque essa função nem chama o método que faria isso. Um engenheiro de plantão olhando o painel veria uma linha parada em pending, attempts=0, sem nenhum sinal de que uma tempestade de retry está em curso contra ela.

Resposta: drainOutboxOnce, com uma política explícita de tentativas, backoff exponencial com teto, e dead_letter obrigatório quando o teto é atingido:

export async function drainOutboxOnce(repo, sink, opts) {
  const policy = opts.policy ?? DEFAULT_RETRY_POLICY; // maxAttempts: 5
  const due = await repo.listDueOutboxEvents(opts.tenantId, opts.nowIso, opts.limit);
  for (const event of due) {
    try {
      await sink.deliver(event);
      await repo.markOutboxDelivered(event.id, opts.nowIso);
    } catch (err) {
      const attemptsAfter = event.attempts + 1;
      const terminal = attemptsAfter >= policy.maxAttempts;
      await repo.markOutboxFailed(event.id, {
        nowIso: opts.nowIso,
        nextAttemptAtIso: terminal ? null : backoffFrom(opts.nowIso, attemptsAfter, policy),
        terminal,
        error: (err as Error).message,
      });
    }
  }
}

O teste que prova a diferença roda os dois lado a lado contra o mesmo sink, configurado para falhar dez vezes seguidas: a versão corrigida, com maxAttempts: 3, desiste na terceira tentativa e marca a linha como dead_letter — nunca mais tentada automaticamente. A versão ingênua insiste até a décima primeira chamada, quando o sink finalmente aceita, sem nunca ter dado sinal de dead-letter no caminho. Onze tentativas contra três é a diferença entre um evento perdido de forma visível e recuperável, e um evento perdido de forma invisível.

Falha 2 — dashboard sem ação

Sintoma: um painel de operação mostra suggestion_quality_sli: 0,40 e para por aí. Quem está de plantão precisa já saber de memória se esse número é bom ou ruim, e o que fazer a respeito.

Causa: naiveDashboard, também mantido só para comparação:

export function naiveDashboard(input) {
  return {
    ticket_flow_sli: ratio(input.ticketFlow),
    suggestion_quality_sli: ratio(input.suggestionQuality),
  };
}

Dois números, zero contexto.

Resposta: buildDashboard, usado de fato por GET /ops/slo. Cada métrica carrega um status (ok/warning/breach/no_data), a fração de budget de erro já consumida, e — sempre que o status não é ok — uma ação literal, nunca um número solto:

{
  "name": "suggestion_quality",
  "status": "breach",
  "sli": 0.2,
  "burnedFraction": 2.67,
  "action": "runbook:suggestion-quality-breach -- confirm ticket_flow is unaffected, then trip kill switch for the affected tenant(s)..."
}

O texto de action não é decorativo: é o mesmo texto documentado em examples/runbook.md, na tabela de alertas acionáveis, então o painel e o runbook nunca podem divergir silenciosamente um do outro — um é gerado a partir da mesma lógica que valida o outro.

Falha 3 — backup sem restore

Sintoma: um backup existe — o comando rodou, o arquivo .dump tem bytes — mas ninguém nunca testou se ele volta a ser um sistema funcionando de verdade.

Esta é a única das quatro falhas que este capítulo não precisou simular: ela aconteceu de verdade, nesta sessão, durante o próprio drill que deveria só confirmar que o backup funcionava.

docker exec series-ai-pe07-pg pg_dump -U postgres -d deskpilot -Fc -f /tmp/deskpilot.dump
docker stop series-ai-pe07-pg   # simula perda
docker run -d --rm --name series-ai-pe07-pg-restore -e POSTGRES_PASSWORD=*** \
  -e POSTGRES_DB=deskpilot -p 0:5432 postgres:17.6
docker exec series-ai-pe07-pg-restore pg_restore -U postgres -d deskpilot \
  --no-owner --role=postgres /tmp/deskpilot.dump

pg_restore: error: could not execute query: ERROR:  role "deskpilot_app" does not exist
Command was: GRANT USAGE ON SCHEMA public TO deskpilot_app;
pg_restore: warning: errors ignored on restore: 9

Causa real: pg_dump de um único banco não inclui papéis — eles vivem no nível do cluster, não do banco. Um cluster de restore vazio simplesmente não tem deskpilot_app, o papel de aplicação que src/db/pg-repository.ts usa para conectar. Os dados das tabelas restauraram corretamente — confirmado por uma consulta direta como superusuário —, mas a aplicação não teria conseguido autenticar até esse ponto ser corrigido. Um restore que "parece ter funcionado" porque os dados estão visíveis para o superusuário é exatamente o tipo de falso positivo que só aparece testando de verdade, nunca supondo.

Resposta e verificação: reexecutar node src/db/migrate.ts contra o alvo de restore recria o papel (o bloco do $$ if not exists ... end $$ de migrations/0001_init.sql, inalterado desde o capítulo 03, já era idempotente o suficiente para isso) e reaplica os GRANTs. Depois disso, uma leitura através do papel real da aplicação — não do superusuário — confirmou o ticket recuperado (triaged, version: 1) com seu evento de auditoria intacto (ticket.triage). O runbook agora documenta restore como duas etapas, não uma: pg_restore sempre seguido de migrate.ts antes de apontar a aplicação para o alvo.

Falha 4 — demo rotulada produção/PMF

Sintoma: uma demonstração interna — dados sintéticos, um ticket bem escolhido, um agente treinado especificamente para a demo — vira "piloto validado" ou "clientes adoram" na boca de alguém, e uma decisão de negócio real (investir, prometer a um cliente, escalar) é tomada em cima disso.

Causa: confundir "o sistema roda sem erro" com "o mercado quer isso" — são perguntas diferentes, respondidas por evidências diferentes. Nenhum teste automatizado, por mais verde que fique, responde a segunda. É o mesmo erro, em escala maior, que o capítulo 06 já nomeou para uma métrica: tratar aceite de sugestão como sucesso de negócio.

Resposta: a matriz de examples/release-checklist.md separa as duas perguntas em linhas diferentes — 13 gates técnicos, e uma linha 15 rotulada "não aplicável a este gate técnico" para PMF, especificamente para que ninguém confunda uma coisa com a outra. examples/pilot-protocol.md abre com "Status: piloto não executado" em negrito, na primeira linha, antes de qualquer outro conteúdo. Nenhum artefato deste pacote contém um número de cliente, receita ou satisfação real — porque nenhum existe.

Avaliação: o que os números provam e o que não provam

76 testes automatizados offline (domínio, API, IA e módulos de ops/) e 16 testes contra Postgres real, incluindo RLS pelo papel de aplicação, rollback/replay da revisão e admissões concorrentes. Nos cenários testados, o kill switch bloqueia antes da chamada ao adaptador; o drenador limita tentativas; o painel separa os dois SLIs; as consultas testadas isolam tenants; revisão, auditoria e outbox compartilham transação no Postgres; o restore local recupera ticket e auditoria através da aplicação. Isso não prova teto rígido de custo faturado nem reconciliação de jobs interrompidos.

Isso não prova: que algum tenant real vai usar o sistema dessa forma; que o teto de US$ 5,00/dia ou o limiar de 5 falhas consecutivas são os números certos para um cliente de verdade (são cenários didáticos, nunca uma negociação real); que a UI de revisão humana está pronta — a leitura direta de src/web/app.js nesta sessão confirmou que ela não renderiza nenhum campo de sugestão, nem categoria nem suggestionDetail, mais grave do que o README do capítulo 05 registrava ("só mostra a categoria"). Essa é a lacuna que bloqueia de verdade o gate 8 da matriz go/no-go — não um exercício retórico de "sempre existe algo a melhorar", mas um bloqueador nomeado, com responsável e critério de fechamento.

E, mais uma vez, nenhum desses números mede se uma sugestão de IA de fato ajuda um tenant real — essa é a pergunta que o capítulo 06 já tinha isolado, e que só um piloto real, ainda não executado, pode responder.

Custo, segurança e reversibilidade

Custo: produto, IA e suporte exigem orçamentos separados. checkAndReserveRequest reserva capacidade atomicamente por tenant/dia antes da chamada ao adaptador. Vinte requisições concorrentes com teto sintético de US$ 0,20 admitem quatro reservas de US$ 0,05. O gasto real é registrado após a chamada e pode superar a reserva; uma execução interrompida pode deixá-la pendente. Cobrança real está fora do exemplo. Limite faturado no provedor, alertas e reconciliação de reservas são gates pendentes.

Segurança: o threat model nomeia seis vetores e controles parciais — entrada não confiável (validação de schema), vazamento entre tenants (RLS testada nas duas tabelas novas), injeção (citação de evidência conferida contra o texto autorizado), alteração de dados (versão otimista, chave de comando), permissões (papel ai não autoriza comandos; reset exige manager/system) e abuso de consumo (teto diário, limite de requisições, kill switch). Esses testes não certificam segurança. examples/privacy-data-map.md registra as lacunas: redação automática de logs, exportação/exclusão self-service e revisão legal/contratual.

Reversibilidade: todo container Docker desta sessão foi descartável (--rm, sem volume nomeado) e removido ao final. Toda migração é aditiva — nenhuma tabela, coluna ou política do capítulo 03 ao 05 foi alterada. O kill switch reverte com um ator nomeado, nunca sozinho. O que não reverte fácil é uma decisão de negócio tomada sobre um número inflado — motivo pelo qual a Falha 4 existe nesta lista ao lado de três falhas de infraestrutura.

Checklist de saída deste capítulo

• suggestion.reviewed — lacuna real do capítulo 05/06 — fechado: dois eventos emitidos na rota de revisão, um síncrono (auditoria), um enfileirado (analytics).
• Outbox com teto de tentativas, backoff e dead-letter; versão sem teto mantida só para prova em teste, nunca em caminho real.
• ticket_flow e suggestion_quality medidos separadamente, nunca combinados em um score.
• Todo status de dashboard abaixo de ok carrega uma ação, ligada ao runbook.
• Teto de custo diário, rate limit e kill switch por tenant, testados e verificados antes de qualquer chamada ao provedor.
• RLS testada em toda tabela nova, através do papel de aplicação, contra Postgres real.
• Backup e restore testados de ponta a ponta — não só o comando de dump, o restore inteiro, com achado real corrigido.
• Threat model simples, com mitigação real por categoria, lacunas nomeadas.
• Matriz go/no-go com pelo menos um bloqueador genuíno, não uma lista de "tudo pronto".
• Piloto real desenhado, com critério de parada, explicitamente não executado.

Exercícios

Básico. Rode node --test test/ops/outbox.test.ts em examples/deskpilot/. Mude DEFAULT_RETRY_POLICY.maxAttempts de 5 para 1 em src/ops/outbox.ts e explique, sem rodar nada, o que muda no teste "dead-letters after the policy's attempt ceiling". Critério de aceite: prever corretamente que a linha vai para dead_letter na primeira falha, sem nenhuma tentativa de retry. Solução comentada: com maxAttempts: 1, attemptsAfter = event.attempts + 1 = 1, e terminal = (1 >= 1) = true já na primeira falha — o teto de uma tentativa remove o retry por completo, o que é válido para um evento onde qualquer atraso é inaceitável, mas geralmente forte demais para um sink que só está lento, não quebrado.

Intermediário. Reproduza o teste de 20 reservas concorrentes para um tenant com teto sintético de US$ 0,20 e reserva de US$ 0,05. Critério de aceite: quatro admissões, 16 recusas e reserved_usd = 0.20 no Postgres. Solução comentada: mutateTenantBudget cria a linha (tenant, dia) se necessário, faz SELECT ... FOR UPDATE e decide/atualiza na mesma transação. Depois injete uma resposta de provedor com custo US$ 0,42: a reserva atômica continua correta, mas o valor faturado extrapola US$ 0,05. Explique por que o teste de admissão não prova teto de cobrança.

Avançado. O drill de backup/restore desta sessão usou pg_dump -Fc de um único banco e descobriu que papéis não vêm junto. Projete (sem implementar) uma segunda estratégia de backup que também capture papéis e suas senhas com segurança, considerando que DESKPILOT_APP_PASSWORD nunca deve aparecer em texto puro num arquivo de dump. Liste pelo menos dois trade-offs da sua estratégia contra o procedimento de duas etapas (pg_restore + migrate.ts) já documentado em examples/runbook.md. Critério de aceite: a estratégia proposta precisa nomear explicitamente como a senha do papel de aplicação seria protegida (nunca "apenas incluir no dump"), e comparar pelo menos complexidade operacional e superfície de exposição de segredo contra a solução mais simples já testada nesta sessão. Solução comentada: uma opção real é pg_dumpall --roles-only para um arquivo separado, com a senha do papel gerada de novo (não extraída do dump) a cada restore — mais simples de proteger, mas exige regenerar e redistribuir a senha da aplicação toda vez, uma operação manual a mais que o procedimento atual (migrate.ts idempotente) já resolve de graça, porque ele recria o papel com a senha do ambiente de destino, nunca com uma senha herdada do backup.

Glossário

• SLI (indicador de nível de serviço): um número, tipo razão, que mede uma propriedade do sistema — aqui, sempre "eventos bons / eventos totais", nunca uma métrica de negócio.
• SLO (objetivo de nível de serviço): a meta proposta para um SLI (98% para ticket_flow, 70% para suggestion_quality neste pacote) — meta, nunca resultado medido nem SLA negociado.
• Budget de erro: (1 - SLO) × total de eventos — quantos eventos ruins são tolerados antes de a meta ser violada.
• Outbox: trabalho pendente de entrega posterior. No caminho de revisão com Postgres, estado da sugestão, auditoria e enqueue agora compartilham uma transação. Entrega ao sink continua sujeita a retry e exige deduplicação downstream.
• Dead-letter: estado terminal de um item que esgotou suas tentativas — visível, revisável, nunca reprocessado automaticamente.
• Kill switch: interruptor que bloqueia uma capacidade (aqui, sugestão de IA por tenant) até reset humano explícito.
• RLS (row-level security): mecanismo do Postgres que filtra linhas por política, aplicado mesmo contra um papel de aplicação sem privilégio de dono.

Ponte para o capítulo 08

Este capítulo entrega ao capítulo 08 DeskPilot v0.3 com 76 testes offline e 16 testes de fluxo PostgreSQL registrados; revisão, auditoria e suggestion.reviewed atômicos no Postgres; reserva concorrente de admissão testada; matriz no-go com UI de sugestões bloqueada e teto de custo faturado ainda sem garantia; plano de piloto explicitamente não executado. Nenhum número de cliente, receita ou PMF é herdado, porque nenhum existe — ../product-designer-serie-08/prompt.md parte exatamente dessa ausência.

Fontes

• Google SRE Workbook — Implementing SLOs — método de indicador tipo razão e budget de erro; consultado em 2026-09-28.
• OWASP Top 10 for LLM & GenAI Apps (2025) — taxonomia de ameaças, não certificação; consultado em 2026-09-28.
• PostgreSQL 17 — Row Security Policies — comportamento de papéis e políticas relevante ao banco testado; link requer rechecagem antes da publicação.
• Stripe — Idempotent requests — exemplo de contrato específico de API; DeskPilot não herda expiração nem comparação de parâmetros da Stripe; consultado em 2026-09-28.