agent-engineering-skills 1.0.0

package/skills/audit/business-logic-audit/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: business-logic-audit
+description: Identifies business rules, invariants, limits, ownership, transitions, and rewards and for each asks where it is enforced, whether it can be bypassed, repeated, reversed, or raced.
+category: audit
+triggers:
+  - "audit business rules"
+  - "review invariants and limits"
+  - "check ownership and permissions logic"
+  - "audit a reward or scoring system"
+  - "verify rule enforcement server-side"
+priority: high
+---
+
+# Business Logic Audit
+
+## Objective
+
+Ensinar o agente a extrair as **regras de negócio** implícitas em um sistema e, para
+cada uma, aplicar um protocolo de cinco perguntas que expõe onde a regra é frágil:
+
+```text
+Where is it enforced?
+Can it be bypassed?
+Can it be repeated?
+Can it be reversed?
+Can it race?
+```
+
+A diferença entre "o código faz X" e "o negócio exige X e o código garante X" é onde
+moram os bugs de lógica.
+
+## When to Use
+
+* Quando o sistema tem regras: limites, cotas, ownership, permissões, transições de
+  estado, economia interna (XP, pontos, moedas, estoque).
+* Antes de lançar features que envolvem valor transferível ou contável.
+* Quando o pedido menciona "rules", "limits", "quotas", "ownership", "rewards",
+  "permissions", "state transitions".
+* **Composição:** núcleo de quase toda auditoria de lógica. Pareia com
+  `gamification-audit` (regras de recompensa), `idempotency-audit` (repetições de
+  regra), `race-condition-hunter` (regras que dependem de read-then-write),
+  `authorization-audit` (ownership = autorização), `data-integrity-audit` (regras que
+  o banco deve impor), `input-trust-audit` (valores de regra confiados ao cliente).
+
+## Mental Model
+
+Toda regra de negócio é, no fundo, um **invariant** — uma asserção que deve ser sempre
+verdadeira. "Um usuário não pode dar XP a si mesmo." "O saldo nunca fica negativo."
+"Um item deletado não pode ser editado." "Limite de 5 por dia."
+
+O bug de lógica acontece quando o sistema *acredita* no invariant sem *garanti-lo*. O
+modelo é:
+
+```text
+regra (invariant)  →  onde é enforcement?  →  bypass? repeat? reverse? race?
+```
+
+Se o enforcement está só no frontend, ou só em uma camada, ou em read-then-write sem
+lock, o invariant é uma *crença*, não uma *garantia*. A skill transforma crenças em
+perguntas e perguntas em evidência.
+
+Classes de regra a procurar:
+
+```text
+rules        — o que deve/não deve acontecer
+invariants   — o que deve ser sempre verdadeiro
+limits       — cotas, máximos, mínimos, por-tempo
+ownership    — de quem é o recurso; quem pode agir
+transitions  — estados permitidos e proibidos
+rewards      — o que concede valor e sob quais condições
+```
+
+## Investigation Procedure
+
+1. **Inventariar regras.** Leia o fluxo e liste todas as regras implícitas. Para cada,
+   rotule a classe (rule/invariant/limit/ownership/transition/reward).
+2. **Para cada regra, responder às 5 perguntas:**
+   * **Where is it enforced?** — frontend? API? server handler? DB constraint? nenhuma?
+   * **Can it be bypassed?** — existe um caminho alternativo (outro endpoint, campo
+     extra, manipulação de ID) que contorna o enforcement?
+   * **Can it be repeated?** — executar a ação N vezes viola a regra? (limite diário
+     resetável por retry? reward por repetição?)
+   * **Can it be reversed?** — desfazer + refazer viola a regra? (reward concedida de
+     novo ao refazer?)
+   * **Can it race?** — a regra depende de ler estado e depois escrever? Dois requests
+     concorrentes passam pela checagem?
+3. **Triar por severidade** — regras sobre valor transferível (dinheiro, XP, estoque)
+   e ownership são mais graves que regras cosméticas.
+4. **Confirmar com evidência** — para cada "yes" nas perguntas, reproduzir ou apontar o
+   mecanismo no código.
+5. **Reportar** via `templates/audit-report.md`.
+
+## Questions to Ask
+
+* Quais são todas as regras de negócio deste fluxo? (liste explicitamente)
+* Para cada regra: onde exatamente ela é enforcement? É a única camada?
+* A regra confia em algum valor enviado pelo cliente (price, role, xp, ownerId)?
+* Se eu repetir a ação, a regra ainda vale? Ou o contador/limite é inconsistente?
+* Se eu desfazer e refazer, o efeito é concedido duas vezes?
+* A checagem lê estado e depois escreve baseada no que leu? Há janela de race?
+* A regra é imposta por constraint do banco (unique, FK, check)? Ou só em código?
+* Quem é o owner do recurso? A checagem de ownership é no servidor?
+* Existem transições de estado que deveriam ser proibidas mas não são validadas?
+
+## Attack Patterns
+
+```text
+bypass — alternative endpoint
+    fluxo oficial: POST /reward {reactionId}   (valida regra "não self-reward")
+    endpoint direto: POST /admin/grant {userId, xp}   (valida? ou é interno confiável?)
+
+bypass — extra field / mass assignment
+    POST /update {name: "x"}
+    POST /update {name: "x", role: "admin"}   (campo extra aceito → regra de role violada)
+
+repeat — daily limit reset
+    POST /claim   → +1 (contador "hoje": 1/5)
+    retry rápido   → o contador é por-calendário ou por-janela? manipular timestamp?
+
+reverse — reward refund + regrant
+    react → +10 XP
+    unreact → -10 XP (ou não?)
+    react → +10 XP
+    → se unreact não removeu XP, refazer = farming
+
+race — check-then-act on a limit
+    request A: read "hoje: 4/5"  → ok
+    request B: read "hoje: 4/5"  → ok  (mesma leitura)
+    request A: write "hoje: 5/5" + reward
+    request B: write "hoje: 5/5" + reward   → 6/5, regra do limite violada
+
+transition — illegal state reachable
+    DELETE /item   → state: "deleted"
+    PUT /item {state: "active"}   → permitido? transição proibida não checada?
+
+ownership — authenticated ≠ authorized
+    GET /order/123   → 200   (é meu? ou só preciso estar logado?)
+```
+
+## Evidence Requirements
+
+* **Nomear a regra e sua classe** (ex: "invariant: saldo não negativo").
+* **Responder as 5 perguntas explicitamente** no finding — onde enforced, bypass,
+  repeat, reverse, race — mesmo que a resposta seja "não". Isto mostra que o protocolo
+  foi aplicado.
+* **Mostrar o mecanismo da violação** — o endpoint/campo/sequência que contorna, ou o
+  read-then-write que abre race.
+* **Escalar confiança:**
+  * `CONFIRMED` — reproduziu a violação da regra (ex: claim além do limite, reward
+    dupla).
+  * `HIGH CONFIDENCE` — código mostra enforcement faltando em um caminho claro.
+  * `POSSIBLE` — regra parece não enforced em um caminho plausível, não confirmado.
+  * `SPECULATIVE` — "deveria haver uma regra aqui" sem evidência de violação.
+
+## False Positives
+
+* **Enforcement em múltiplas camadas** — se a regra é checada no handler E no banco
+  (constraint), um bypass aparente no handler é defendido pelo banco. Confirmar ambas
+  antes de reportar.
+* **Regra é de UI, não de negócio** — "campo obrigatório no form" pode ser só UX; se o
+  backend aceita vazio legitimamente, não é bug de lógica.
+* **Limite é soft por design** — alguns limites são orientativos, não duros. Verificar
+  a intenção de produto antes de reportar como defeito (marcar `POSSIBLE`).
+* **Self-reward prevenido por design diferente** — talvez o sistema permita "self-XP"
+  em um contexto (admin) e proíba em outro. Não reportar bypass sem entender o modelo
+  de papéis.
+* **Regra não existe** — se você *assume* uma regra que o produto não definiu, qualquer
+  "violação" é falso positivo. Liste a regra como hipótese e marque `SPECULATIVE` se
+  não há evidência de que ela deveria existir.
+
+## Output Format
+
+Para cada regra com um "yes" em qualquer uma das 5 perguntas, um finding via
+`templates/audit-report.md`. Em **Affected flow**, nomeie a regra violada. Em
+**Reproduction**, mostre o caminho do bypass/repeat/reverse/race. Em **Root cause**,
+diga *onde* o enforcement falta (camada, endpoint, ausência de constraint). Em
+**Recommendation**, indique a camada que deve garantir o invariant (idealmente o banco,
+ou lock/transaction no servidor).
+
+Apresente o inventário de regras como tabela (regra | classe | onde enforced |
+bypass? | repeat? | reverse? | race?), marcando as vulnerabilidades. Regras sobre valor
+transferível e ownership primeiro.

package/skills/audit/edge-case-hunter/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: edge-case-hunter
+description: Generates edge cases around null, empty, zero, negative, huge values, duplicates, Unicode, stale data, deleted data, expired data, and repeated valid actions, then checks whether the system handles each.
+category: audit
+triggers:
+  - "find edge cases"
+  - "test boundary values"
+  - "what about null empty zero negative huge"
+  - "stress inputs with edge values"
+  - "unicode and duplicate handling"
+priority: high
+---
+
+# Edge Case Hunter
+
+## Objective
+
+Ensinar o agente a **gerar sistematicamente** casos de fronteira e verificar se o
+sistema trata cada um. Ao contrário de skills que atacam lógica ou fluxo, esta ataca
+**valores** — as entradas nos limites onde suposições sobre formato, magnitude e
+conteúdo quebram.
+
+## When to Use
+
+* Ao auditar qualquer função/campo que recebe input (formulários, APIs, imports,
+  parseadores, cálculos).
+* Antes de confiar em um cálculo (saldo, XP, preço, contador, posição, índice).
+* Quando o pedido menciona "edge cases", "boundary", "what about X values", "stress
+  inputs".
+* **Composição:** complementar, não substitutiva. Rode junto com
+  `input-trust-audit` (esses valores viriam do cliente?), `business-logic-audit`
+  (limites que são regras), `error-flow-audit` (o que acontece quando o edge case
+  quebra), `data-integrity-audit` (o banco aceita esses valores?).
+
+## Mental Model
+
+A maioria do código é testada no happy path com valores "redondos" (1, 10, "hello").
+Bugs vivem nas **fronteiras** — onde o input deixa de ser "normal" e expõe uma suposição
+não escrita: "não será nulo", "não será vazio", "será positivo", "cabe em um int",
+"é ASCII", "é único", "ainda existe".
+
+A skill usa uma lista canônica de eixos de fronteira e, para cada campo/entrada
+relevante, pergunta "o que acontece se este valor for `<eixo>`?". É exaustivo por
+intenção, mas **triado por relevância**: nem todo eixo aplica a todo campo.
+
+Eixos canônicos (do `plan.md` §6):
+
+```text
+null              empty             zero             negative
+huge values       duplicates        Unicode          stale data
+deleted data      expired data      repeated valid actions
+```
+
+## Investigation Procedure
+
+1. **Listar entradas.** Identifique todos os campos/parâmetros/entradas que o
+   componente recebe (do cliente, de outra camada, de um job, de um import).
+2. **Para cada entrada, mapear o tipo e as suposições** — número? string? referência a
+   entidade? data? Enumerar o que o código assume sobre ele.
+3. **Gerar casos por eixo.** Para cada entrada × eixo aplicável, formule o caso.
+   Ex: `balance` × `negative` → "saldo -50"; `name` × `Unicode` → "nome com
+   zero-width/emoji/RTR"; `parentId` × `deleted data` → "referencia entidade deletada".
+4. **Executar/verificar cada caso.** O que o sistema faz? Erro limpo? Silent fail?
+   Estado corrompido? Crash? Comportamento errado sem erro?
+5. **Triar.** Descarte casos onde o eixo não aplica (ex: `negative` em um enum).
+   Priorize casos que corrompem estado ou causam comportamento errado silencioso.
+6. **Confirmar com evidência** — reproduza o input e observe a saída/estado.
+7. **Reportar** via `templates/audit-report.md`.
+
+## Questions to Ask
+
+* O que acontece se este campo for `null`? E vazio (`""`)? E só whitespace?
+* E se for `0`? E `-1` / negativo?
+* E se for enorme (overflow de int, string de 1MB, array de 10⁶ itens)?
+* E se houver duplicata (dois iguais onde deveria ser único)?
+* E se tiver Unicode exótico (zero-width joiner, RTL, emoji, combinando)?
+* E se o dado referenciado foi deletado? (FK pendente, soft-deleted mas ainda usado)
+* E se o dado está expirado? (token, sessão, oferta, cupom)
+* E se for stale (cache desatualizado vs fonte)?
+* E se a mesma ação válida for repetida N vezes? (limite, contador, reward)
+* O erro (quando ocorre) é limpo e tratado, ou vaza crash/stack trace?
+
+## Attack Patterns
+
+```text
+null
+    field: null           → NullPointerException? 500? ou tratado como default?
+
+empty
+    name: ""              → validado? ou aceito e quebra display/sort?
+
+zero
+    quantity: 0           → cálculo de total = 0 ok? ou divisão por zero downstream?
+    price: 0              → checkout grátis "válido"?
+
+negative
+    amount: -50           → transfere -50 (inverte fluxo)? saldo fica negativo?
+
+huge
+    count: 2147483648     → overflow int? loop eterno? OOM?
+    file: 10GB            → limite de upload?
+
+duplicate
+    POST /create {slug:"x"} twice   → 409? ou cria dois?
+
+Unicode
+    name: "a​​b"          → zero-width; igual a "ab"? duplicata invisível?
+    name: "‮"                  → RTL override; rendering invertido
+
+deleted data
+    POST /comment {postId: <deleted>}   → cria comentário órfão?
+
+expired data
+    redeem code expired   → ainda resgata? ou checa expiração?
+
+stale data
+    cache: balance=100, db: balance=50   → usa cache e permite gastar 100?
+
+repeated valid action
+    claim reward 5×       → limite por-janela respeitado? ou farming?
+```
+
+## Evidence Requirements
+
+* **Nomear o eixo e o campo** testados.
+* **Mostrar o input exato** usado (valor literal, não "um valor grande").
+* **Mostrar a saída/estado resultante** — não só "quebra", mas *como* (erro 500,
+  silent success com estado errado, crash, comportamento correto).
+* **Escalar confiança:**
+  * `CONFIRMED` — reproduziu com o input literal e observou o resultado.
+  * `HIGH CONFIDENCE` — código mostra caminho que não trata o eixo, sem reprodução.
+  * `POSSIBLE` — eixo plausível, caminho não confirmado.
+  * `SPECULATIVE` — "pode quebrar com X" sem rastrear.
+* Priorize `silent success com estado errado` — é pior que crash, porque não alerta.
+
+## False Positives
+
+* **Validação de tipo no boundary do framework** — se o ORM/schema rejeita null/empty
+  antes do handler, o caso é tratado. Confirmar antes de reportar.
+* **Default intencional** — alguns campos legitimamente defaultam null/0 e o código
+  trata downstream. Não reportar "aceita null" se o nulo é intencional e tratado.
+* **Unicode normalizado por design** — se o sistema normaliza (NFC) e colapsa
+  zero-width de propósito, "duplicata invisível" é tratada, não bug.
+* **Soft delete intencional** — referenciar entidade "deletada" (soft) pode ser
+  desejado (histórico). Verificar se é hard ou soft delete antes de reportar.
+* **Limite enorme não é defeito** — se o sistema *deve* aceitar arquivos grandes,
+  "aceita 10GB" não é bug; "não limita e dá OOM" seria.
+* **Caso não aplica** — `negative` em um boolean/enum não aplica; não force.
+
+## Output Format
+
+Para cada caso que produz comportamento errado (não só erro), um finding via
+`templates/audit-report.md`. Em **Reproduction**, dê o input literal e o comando
+request. Em **Actual behavior**, descreva exatamente o resultado observado. Em
+**Recommendation**, indique validação (onde: schema vs handler vs sanitização).
+
+Apresente a matriz de cobertura como tabela (entrada × eixos aplicáveis, marcando
+✓ tratado / ✗ falha / — não aplica). Isto documenta quais eixos foram testados e
+previne retrabalho. Silenciosos (estado errado sem erro) primeiro; crashes depois.

package/skills/audit/error-flow-audit/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: error-flow-audit
+description: Investigates partial success, timeouts, lost responses, retries, crashes, and rollback failures to find states left inconsistent or operations left half-done when something fails mid-flight.
+category: audit
+triggers:
+  - "audit error handling"
+  - "what happens on failure mid-flow"
+  - "partial success and rollback"
+  - "retry and timeout behavior"
+  - "crash recovery and lost responses"
+priority: high
+---
+
+# Error Flow Audit
+
+## Objective
+
+Ensinar o agente a parar de perguntar "isto funciona?" e perguntar **"o que acontece
+quando isto falha no meio?"**. Toda operação multi-passo pode falhar entre os passos;
+esta skill mapeia os pontos de falha e verifica se o sistema deixa o estado consistente
+ou abandona o sistema em um estado parcial.
+
+```text
+partial success   timeouts   lost responses   retries   crashes   rollback failures
+```
+
+## When to Use
+
+* Quando uma operação toca múltiplos recursos/serviços (DB + API externa + fila +
+  cache) e pode falhar entre eles.
+* Quando há retries, timeouts, circuit breakers, ou webhooks.
+* Quando uma falha pode deixar estado parcial (recurso criado mas notificação não
+  enviada; cobrança efetivada mas pedido não; metadados escritos mas arquivo não).
+* Quando o pedido menciona "error handling", "rollback", "retry", "timeout", "what if
+  it fails", "partial", "idempotent on retry".
+* **Composição:** pareia com `idempotency-audit` (retry de operação inteira),
+  `data-integrity-audit` (transação/rollback no banco), `state-consistency-audit`
+  (estado parcial = desync entre camadas), `user-flow-audit` (fluxo que falha num
+  passo intermediário), `race-condition-hunter` (falha concorrente com outra mutação).
+
+## Mental Model
+
+O happy path é fácil. O perigo é o **caminho parcial**: a operação completa passo 1,
+falha no passo 2, e agora o sistema tem o efeito do passo 1 sem o do passo 2 — um estado
+que o happy path nunca produziria e que ninguém projetou para existir.
+
+As duas armadilhas simétricas:
+
+1. **Sem rollback** — passo 1 efetivado, passo 2 falha, passo 1 não é desfeito. Estado
+   parcial persiste.
+2. **Rollback sem idempotência** — retry reexecuta passo 1 (já feito) e cria efeito
+   duplicado. Ou rollback desfaz e reexecuta do zero, mas o "efeito externo" (email,
+   cobrança) já ocorreu e não é reversível.
+
+O modelo: para cada operação multi-passo, pergunte *qual passo é idempotente*, *qual
+é reversível*, *qual tem efeito externo irreversível*, e *o que acontece se falhar
+após cada um*. Pontos de não-retorno (efeito externo já disparado) são os mais críticos.
+
+Classes de falha a investigar (do `plan.md` §6):
+
+```text
+partial success   — alguns passos efetivam, outros não
+timeouts          — chamada pendente; estado desconhecido (fez ou não fez?)
+lost responses    — servidor agiu mas o cliente não sabe; retry?
+retries           — reexecução; idempotente? ou duplica efeito?
+crashes           — processo morre mid-op; estado em disco consistente?
+rollback failures — tentou desfazer e o rollback também falhou; agora o quê?
+```
+
+## Investigation Procedure
+
+1. **Decompor a operação em passos.** Liste cada efeito (write DB, call API externa,
+   enqueue, send email, update cache, emit event).
+2. **Rotular cada passo:** idempotente? reversível? efeito externo (irreversível)?
+3. **Para cada ponto de falha (após passo k), perguntar:**
+   * O estado parcial é consistente ou corrompido?
+   * Há rollback? O rollback cobre todos os passos k?
+   * O rollback é idempotente (safe to retry)?
+   * Há efeito externo irreversível já disparado antes do ponto de falha?
+4. **Testar timeout/lost-response:** se a chamada pendente, o sistema trata como
+   "feito", "não feito", ou "desconhecido"? O retry é seguro?
+5. **Testar retry:** reexecutar a operação inteira após falha — duplica algum efeito?
+6. **Testar crash mid-op:** se o processo morre entre passos, o estado em disco é
+   consistente ao reiniciar? Há recuperação/reconciliação?
+7. **Testar rollback failure:** se o rollback também falha, o sistema fica em quê?
+   Há alerta/reconciliação, ou silencioso?
+8. **Confirmar com evidência** — injete falha no passo k e observe o estado final.
+9. **Reportar** via `templates/audit-report.md`.
+
+## Questions to Ask
+
+* Quais são os passos/efeitos desta operação? Qual ordem?
+* Qual passo é o ponto de não-retorno (efeito externo irreversível)?
+* Se falhar *após* o ponto de não-retorno, o que acontece?
+* Há transação? Ela cobre todos os writes ou só alguns?
+* Para chamada externa: timeout → estado desconhecido. Como o sistema resolve?
+* Retry da operação inteira é idempotente? Ou duplica um efeito?
+* Se o processo crashar entre passos, há reconciliação ao reiniciar?
+* O rollback, se existe, é idempotente? E se o rollback falhar?
+* Erros são tratados ou engolidos (empty catch)? Estado parcial é detectável?
+
+## Attack Patterns
+
+```text
+partial success — no transaction
+    step 1: write db order "created"     ✓ committed
+    step 2: charge payment               ✗ fails
+    → order exists, never paid, no rollback. Estado parcial.
+
+partial success — external effect before commit
+    step 1: call payment gateway          ✓ charged (irreversível)
+    step 2: write db order "paid"         ✗ db error
+    → cobrado, pedido não registrado. Ponto de não-retorno passado.
+
+timeout → unknown state
+    call external API: 30s, no response
+    → agiu ou não? retry agora duplica se agiu (não-idempotente).
+
+lost response → blind retry
+    server processes request, response lost in network
+    client retries → reexecuta → efeito duplicado se não-idempotente.
+
+retry that doubles
+    create + send welcome email
+    fails after create, before email
+    retry → create again (duplica) se create não-idempotente.
+
+crash mid-op, no recovery
+    step 1: decrement stock
+    crash
+    restart → stock decremented, order never created. Sem reconciliação.
+
+rollback failure, silent
+    try: step1, step2
+    catch: undo step1   ← undo also fails
+    → step1 efetivado, sem log/alerta. Corrupção silenciosa.
+
+empty catch / swallowed error
+    try { externalCall() } catch {}
+    → falha virou sucesso aparente; estado parcial não detectado.
+```
+
+## Evidence Requirements
+
+* **Nomear o ponto de falha** (após qual passo) e o **estado parcial resultante**.
+* **Rotular cada passo** (idempotente / reversível / efeito externo) no finding.
+* **Mostrar o mecanismo** — onde falta transação, onde retry não é idempotente, onde
+  rollback não cobre, onde catch engole. Ou reprodução com falha injetada.
+* **Escalar confiança:**
+  * `CONFIRMED` — injetou falha e observou estado parcial/corrompido.
+  * `HIGH CONFIDENCE` — código mostra ausência de transação/rollback/idempotência em
+    caminho claro.
+  * `POSSIBLE` — plausível, caminho não confirmado.
+  * `SPECULATIVE` — "pode falhar" sem rastrear.
+* Estados parciais **com efeito externo irreversível** (dinheiro cobrado, email
+  enviado) e **silenciosos** (empty catch) são os mais graves.
+
+## False Positives
+
+* **Transação cobre todos os writes** — se tudo está em uma DB transaction e nada de
+  externo ocorre antes do commit, "falha mid-op" é seguro (rollback automático).
+  Confirmar antes de reportar.
+* **Operação é idempotente por design** — retry seguro significa "duplica" não é bug.
+  Relacionado a `idempotency-audit`; não duplique o finding.
+* **Saga/outbox com reconciliação** — se há outbox + worker que reconcilia estado
+  parcial, a inconsistência é temporária e tratada. Reportar só se a reconciliação é
+  ausente/quebrada.
+* **Timeout tratado como "unknown" com query+decide** — se após timeout o sistema
+  consulta o estado real antes de retry, é correto. Não reportar.
+* **Empty catch é intencional e compensado** — raro, mas se há compensação downstream,
+  confirmar antes de reportar como defeito.
+
+## Output Format
+
+Para cada ponto de falha que deixa estado parcial/corrompido, um finding via
+`templates/audit-report.md`. Em **Reproduction**, descreva a falha injetada (qual
+passo falha, como) e o estado final observado. Em **Affected flow**, nomeie a operação.
+Em **Root cause**, diga o que falta (transação, rollback, idempotência no retry,
+reconciliação, detecção de erro). Em **Recommendation**, indique a estratégia (transação
+atómica, outbox/saga, idempotency key, query-on-timeout, alerta em rollback failure).
+
+Apresente a decomposição como tabela (passo | efeito | idempotente? | reversível? |
+efeito externo? | estado se falhar após). Pontos de não-retorno e estados silenciosos
+primeiro.