agent-engineering-skills 1.0.0

package/examples/authorization-bypass.md

@@ -0,0 +1,191 @@
+# Example — Authorization Bypass (IDOR + Vertical Escalation)
+
+*Demonstração concreta de uma auditoria de autorização. Ilustra:
+`authorization-audit` + `api-abuse-audit` + `input-trust-audit`. Modelo: autenticado ≠
+autorizado (ver `plan.md` §20).*
+
+---
+
+## Target
+
+Um sistema com recursos de usuário (pedidos, documentos, perfil) e endpoints de
+moderação (banir usuário, deletar post). Os endpoints exigem autenticação, mas a
+autorização (ownership / role) é inconsistente.
+
+## Hypotheses
+
+```text
+GET /resource/123
+
+authenticated ≠ authorized
+```
+
+- **IDOR (horizontal):** usuário A acessa pedido de usuário B apenas trocando o ID.
+- **Vertical escalation:** usuário comum chama endpoint de admin/moderator.
+- **Role from client:** o payload do request contém `role` que o servidor confia.
+
+---
+## Finding 1 — IDOR: GET /order/{id}
+
+### Reproduction
+
+```http
+POST /auth/login {email: "userA@example.com", password: "..."}
+→ token: eyJ...
+```
+
+```http
+GET /api/orders/1000  (pedido do userA)
+Authorization: Bearer eyJ...
+→ 200 { id: 1000, userId: "userA", items: [...], total: 250 }
+```
+
+```http
+GET /api/orders/1001  (tentativa — pedido do userB)
+Authorization: Bearer eyJ...
+→ 200 { id: 1001, userId: "userB", items: [...], total: 500 }
+```
+
+**Resultado:** servidor retornou o pedido `1001` de outro usuário. A única checagem é
+autenticação (token válido). **Não há checagem de ownership.**
+
+### Root cause
+
+```javascript
+// router.get('/api/orders/:id', auth, async (req, res) => {
+//   const order = await Order.findById(req.params.id);  // ← sem .where({ userId: ... })
+//   res.json(order);
+// });
+```
+
+O middleware `auth` só valida o token (quem é). O handler não adiciona
+`req.user.id` ao filtro.
+
+### Recommendation
+
+```javascript
+router.get('/api/orders/:id', auth, async (req, res) => {
+  const order = await Order.findOne({
+    _id: req.params.id,
+    userId: req.user.id,  // ← ownership check
+  });
+  if (!order) return res.status(403).json({ error: 'Forbidden' });
+  res.json(order);
+});
+```
+
+---
+## Finding 2 — Vertical escalation: POST /admin/ban
+
+### Reproduction
+
+```http
+POST /api/admin/ban
+Authorization: Bearer eyJ... (token de user comum)
+Content-Type: application/json
+
+{ "userId": "userC", "reason": "spam" }
+```
+
+```http
+→ 200 { ok: true }
+```
+
+**Resultado:** usuário comum banou outro usuário. Nenhuma checagem de `role` no
+handler.
+
+### Root cause
+
+```javascript
+// router.post('/api/admin/ban', auth, async (req, res) => {
+//   await User.updateOne({ _id: req.body.userId }, { banned: true });
+//   res.json({ ok: true });
+// });
+```
+
+O middleware `auth` só valida o token. O prefixo `/admin` na rota é só convenção de
+nomenclatura — não há middleware de RBAC separado.
+
+### Recommendation
+
+```javascript
+// middleware de role
+const requireRole = (...roles) => (req, res, next) => {
+  if (!roles.includes(req.user.role)) return res.status(403).json({ error: 'Forbidden' });
+  next();
+};
+
+router.post('/api/admin/ban', auth, requireRole('admin'), async (req, res) => {
+  // ...
+});
+```
+
+---
+## Finding 3 — Role from client (mass assignment)
+
+### Reproduction
+
+```http
+PUT /api/profile
+Authorization: Bearer eyJ...
+Content-Type: application/json
+
+{ "bio": "new bio", "role": "admin" }
+```
+
+```http
+→ 200 { bio: "new bio", role: "admin" }
+```
+
+**Resultado:** o campo `role` foi aceito do body e gravado.
+
+### Root cause
+
+```javascript
+// router.put('/api/profile', auth, async (req, res) => {
+//   const user = await User.findByIdAndUpdate(req.user.id, req.body, { new: true });
+//   res.json(user);
+// });
+```
+
+O bind de `req.body` é genérico. O modelo `User` tem o campo `role`, então o `$set`
+aceita qualquer valor.
+
+### Recommendation
+
+```javascript
+// Allowlist de campos atualizáveis
+const ALLOWED_FIELDS = ['bio', 'displayName', 'avatar'];
+
+router.put('/api/profile', auth, async (req, res) => {
+  const updates = {};
+  for (const field of ALLOWED_FIELDS) {
+    if (req.body[field] !== undefined) updates[field] = req.body[field];
+  }
+  const user = await User.findByIdAndUpdate(req.user.id, updates, { new: true });
+  res.json(user);
+});
+```
+
+---
+## Summary
+
+| # | Finding | Type | Severity | Confidence |
+|---|---|---|---|---|
+| 1 | IDOR horizontal — `GET /order/{id}` sem ownership check | authorization | Critical | CONFIRMED |
+| 2 | Vertical escalation — `POST /admin/ban` sem role check | authorization | Critical | CONFIRMED |
+| 3 | Mass assignment — `role` aceito do body | input-trust | High | CONFIRMED |
+
+## Matriz de autorização
+
+| Recurso × Ação | Papel exigido | Onde imposto | ✓/✗ |
+|---|---|---|---|
+| order × read | owner | middleware `auth` só | ✗ |
+| order × delete | owner | middleware `auth` só | ✗ |
+| order × update | owner | middleware `auth` só | ✗ |
+| /admin/ban | admin | handler não checa | ✗ |
+| /admin/delete-post | moderator/admin | handler não checa | ✗ |
+| profile × update | owner | handler não checa role | ✓ (userId do token) |
+| profile × role | N/A (nunca do body) | `req.body` direto → | ✗ |
+
+*Ver skills: `authorization-audit`, `api-abuse-audit`, `input-trust-audit`.*

package/examples/frontend-review.md

@@ -0,0 +1,244 @@
+# Example — Frontend Review of a Character Creation Screen
+
+*Demonstração concreta de uma revisão de frontend integrada. Ilustra: `ux-review` +
+`visual-quality-review` + `interaction-design` + `animation-review` +
+`accessibility-review` + `reference-research` + `market-research` (ver `plan.md`
+§20). Usa o template `design-review.md`.*
+
+---
+
+# Design Review — Character Creation Screen
+
+**Date:** 2026-08-28
+**Target:** Screen "Criação de Personagem" (multi-step wizard: class → attributes →
+appearance → confirm)
+**Skills used:** ux-review, visual-quality-review, interaction-design, animation-review,
+accessibility-review, reference-research, market-research
+**References consulted:** Laws of UX (methodology), Impeccable (heuristic), Interfaces
+(heuristic), Dribbble (inspiration)
+
+## Executive summary
+
+O fluxo de 4 passos funciona, mas tem três problemas sérios: (1) não há feedback de
+progresso nem caminho de volta claro no passo 3 (estado de confusão); (2) contraste
+insuficiente em texto de helper e estado focado removido — falha WCAG; (3) animação de
+transição entre passos é lenta (500ms) e não respeita reduced motion. Correção
+prioritária: acessibilidade e feedback.
+
+## Verdict
+
+**Fix first**
+
+## Dimensions
+
+| Dimension | Verdict | Findings |
+|---|---|---|
+| UX | ⚠️ | #1, #2, #3 |
+| Visual | ✅ | — |
+| Interaction | ⚠️ | #4, #5 |
+| Animation | ⚠️ | #6 |
+| Accessibility | ❌ | #7, #8 |
+
+---
+
+## Findings
+
+### Finding 1 — Sem feedback de progresso
+
+| Field | Value |
+|---|---|
+| **Severity** | Medium |
+| **Confidence** | CONFIRMED |
+| **Dimension** | UX |
+| **Affected component** | Wizard — passo 1-4 |
+| **Affected flow** | criação de personagem |
+| **Reproduction** | No passo 2, não há indicação de "passo X de 4"; usuário não sabe se vai continuar |
+| **Expected behavior** | Barra de progresso / stepper visível com estado atual |
+| **Actual behavior** | Apenas título do passo, sem contexto da posição no fluxo |
+| **Root cause** | Layout não inclui elemento de progresso (viola princípio de feedback/estado visível — Laws of UX, "Feedback") |
+| **Impact** | Usuário abandona ou clica "next" sem entender a jornada; retorno ao passo anterior confuso |
+| **Recommendation** | Adicionar stepper de 4 etapas com estado atual destacado |
+
+### Finding 2 — Empty state do atributo não orienta
+
+| Field | Value |
+|---|---|
+| **Severity** | Medium |
+| **Confidence** | CONFIRMED |
+| **Dimension** | UX |
+| **Affected component** | Passo 2 (atributos) — quando nenhum ponto distribuído |
+| **Reproduction** | 0 pontos distribuídos → área vazia sem instrução |
+| **Expected behavior** | Estado vazio guiado ("Distribua seus 10 pontos") |
+| **Actual behavior** | Área em branco |
+| **Root cause** | Empty state não implementado (princípio de empty states) |
+| **Impact** | Usuário não sabe o que fazer a seguir |
+| **Recommendation** | Adicionar empty state com instrução + CTA |
+
+### Finding 3 — Caminho de volta inconsistente
+
+| Field | Value |
+|---|---|
+| **Severity** | Low |
+| **Confidence** | HIGH CONFIDENCE |
+| **Dimension** | UX |
+| **Affected component** | Passo 3 (appearance) — sem "back" |
+| **Reproduction** | No passo 3, não há botão voltar (presente nos outros passos) |
+| **Expected behavior** | Navegação consistente entre passos |
+| **Actual behavior** | Passo 3 órfão — usuário precisa fechar e recomeçar |
+| **Root cause** | Botão back omitido no passo 3 (consistência de navegação violada) |
+| **Impact** | Usuário preso em um estado intermediário |
+| **Recommendation** | Adicionar back button consistente em todos os passos |
+
+### Finding 4 — Pressed state ausente
+
+| Field | Value |
+|---|---|
+| **Severity** | Low |
+| **Confidence** | HIGH CONFIDENCE |
+| **Dimension** | Interaction |
+| **Affected component** | Botão "Next" |
+| **Reproduction** | Clicar e segurar no botão — nenhuma mudança visual |
+| **Expected behavior** | Escurecer/efeito de pressionamento |
+| **Actual behavior** | Nada muda até o release |
+| **Root cause** | `:active` não estilizado |
+| **Impact** | Usuário não sabe se o clique foi registrado |
+| **Recommendation** | Estilizar `:active` (scale/color) |
+
+### Finding 5 — Loading de "save" congelado
+
+| Field | Value |
+|---|---|
+| **Severity** | Medium |
+| **Confidence** | POSSIBLE |
+| **Dimension** | Interaction |
+| **Affected component** | Confirmação (passo 4) — salvar personagem |
+| **Reproduction** | Ao salvar, tela congela ~2s sem feedback (verificar com rede lenta) |
+| **Expected behavior** | Skeleton/spinner + disable do botão |
+| **Actual behavior** | Nada acontece visualmente durante o request |
+| **Root cause** | Estado de loading não implementado |
+| **Impact** | Duplo-submit ou abandono |
+| **Recommendation** | Loading state no botão de salvar |
+
+### Finding 6 — Transição lenta + sem reduced motion
+
+| Field | Value |
+|---|---|
+| **Severity** | Medium |
+| **Confidence** | CONFIRMED |
+| **Dimension** | Animation |
+| **Affected component** | Transição entre passos do wizard |
+| **Reproduction** | Transição de 500ms com fade — com `prefers-reduced-motion: reduce`, continua animando |
+| **Expected behavior** | ≤ 200-300ms; desligada com reduced motion |
+| **Actual behavior** | 500ms sempre |
+| **Root cause** | Timing alto + ausência de `@media (prefers-reduced-motion)` |
+| **Impact** | Sensação de lentidão; desconforto vestibular |
+| **Recommendation** | Reduzir para 250ms + desligar/curtar em reduced motion |
+
+### Finding 7 — Contraste insuficiente (helper text)
+
+| Field | Value |
+|---|---|
+| **Severity** | High |
+| **Confidence** | CONFIRMED |
+| **Dimension** | Accessibility |
+| **Affected component** | Texto de ajuda sob campos (`#9CA3AF` em fundo branco) |
+| **Reproduction** | Inspeção: contraste calculado = **2.9:1** |
+| **Expected behavior** | ≥ 4.5:1 (WCAG AA) |
+| **Actual behavior** | 2.9:1 |
+| **Root cause** | Cor de texto gray-400 em branco |
+| **Impact** | Ilegível para baixa visão |
+| **Recommendation** | Usar `#6B7280` (4.6:1) ou escurecer mais |
+
+### Finding 8 — Focus ring removido
+
+| Field | Value |
+|---|---|
+| **Severity** | High |
+| **Confidence** | CONFIRMED |
+| **Dimension** | Accessibility |
+| **Affected component** | Todos os inputs e botões |
+| **Reproduction** | `*:focus { outline: none }` sem substituto — Tab não mostra posição |
+| **Expected behavior** | Focus ring visível (WCAG 2.4.7) |
+| **Actual behavior** | Nenhuma indicação de foco |
+| **Root cause** | `outline: none` global sem fallback |
+| **Impact** | Usuários de teclado/leitores de tela perdem a posição |
+| **Recommendation** | Remover `outline: none` global; adicionar focus ring visível |
+
+---
+
+## Research synthesis
+
+### Reference
+[Impeccable]
+
+### Relevant Pattern
+Contraste de texto legível, sistema de spacing consistente, sem decoração sem função.
+
+### Why It Matters
+A screen atual usa cores de baixo contraste e espaçamento irregular; Impeccable é o
+bar de referência.
+
+### Adaptation
+Aplicar o sistema de 4px no spacing e revisar a paleta de texto (≥ 4.5:1).
+
+### Trade-offs
+Requer revisão de todos os componentes visuais existentes.
+
+### Recommendation
+Adotar o padrão de contraste do Impeccable + remover animação decorativa.
+
+### Reference 2
+[Laws of UX — Feedback / State visibility]
+
+### Relevant Pattern
+"Feedback: o sistema deve sempre informar o estado atual." "Visibility of system
+status."
+
+### Why It Matters
+As findings #1 e #5 são exatamente a violação deste princípio (sem progresso, sem
+loading).
+
+### Adaptation
+Adicionar stepper + loading states ao wizard.
+
+### Trade-offs
+Nenhum — é padrão esperado.
+
+### Recommendation
+Adotar os princípios de feedback/estado visível no fluxo inteiro.
+
+---
+
+## Accessibility checklist
+
+| Check | Pass | Fail | N/A |
+|---|---|---|---|
+| Keyboard reachable | | ✗ (focus ring removido) | |
+| Focus visible | | ✗ (#8) | |
+| Focus trap correct in modals | | | (sem modal no fluxo) |
+| Alt text on informative images | ✓ | | |
+| aria-label on semantic icons | ✓ | | |
+| aria-live on dynamic content | | ✗ (sem aria-live em erros) | |
+| Semantic HTML | ✓ | | |
+| Text contrast ≥ 4.5:1 | | ✗ (#7) | |
+| Touch targets ≥ 44×44px | ✓ | | |
+| `<label>` on every form input | ✓ | | |
+| Errors text + aria-live | | ✗ (erro só por cor) | |
+| `prefers-reduced-motion` respected | | ✗ (#6) | |
+
+---
+
+## Out of scope
+
+- Mobile layout (não avaliado neste device).
+- Validação server-side do personagem (ver skills de backend).
+- Performance de assets.
+
+## Next steps
+
+1. **Fix first:** #8 (focus ring), #7 (contraste) — acessibilidade bloqueante.
+2. **Fix first:** #1 (stepper), #5 (loading) — feedback essencial.
+3. **Ship-with-fixes:** #6 (reduced motion), #4, #3, #2.
+
+*Ver skills: `ux-review`, `visual-quality-review`, `interaction-design`,
+`animation-review`, `accessibility-review`, `reference-research`, `market-research`.*

package/examples/race-condition.md

@@ -0,0 +1,128 @@
+# Example — Race Condition in Balance Checkout
+
+*Demonstração concreta de uma auditoria de race condition. Ilustra:
+`race-condition-hunter` + `business-logic-audit` + `idempotency-audit` +
+`data-integrity-audit`. Modelo: READ → DECISION → WRITE (ver `plan.md` §20).*
+
+---
+
+## Target
+
+Um sistema de checkout que verifica o saldo do usuário antes de debitar:
+
+```text
+READ    balance (≥ price?)
+DECIDE  yes → proceed
+WRITE   balance = balance - price
+```
+
+## Hypothesis
+
+```text
+check balance
+→ two requests
+→ both pass
+→ both deduct
+```
+
+Dois requests simultâneos lêem o mesmo saldo, ambos decidem "ok", e ambos debitam —
+resultando em saldo final menor que o permitido (ou negativo).
+
+## Mapeamento da race
+
+```javascript
+// src/services/checkout.js
+async function checkout(userId, price) {
+  const user = await User.findById(userId);          // ← READ
+  if (user.balance < price) throw new Error('...');  // ← DECISION
+  user.balance -= price;                             // ← WRITE
+  await user.save();
+  await createOrder(userId, price);
+}
+```
+
+**Janela:** entre o `findById` (READ) e o `save` (WRITE), outro request pode executar
+o mesmo bloco, ler o mesmo saldo, e aprovar.
+
+## Reprodução
+
+Simular dois requests simultâneos contra `GET /checkout`:
+
+| Request | Time | Ação |
+|---|---|---|
+| — | t0 | Saldo inicial: 100 |
+| A | t1 | `findById` → balance=100 (≥ 50? yes) |
+| B | t2 | `findById` → balance=100 (≥ 50? yes) ← mesma leitura, A ainda não salvou |
+| A | t3 | `save` → balance=50 |
+| B | t4 | `save` → balance=50 ← deveria ser 0, mas B usou a leitura de t2 |
+
+**Resultado:** saldo final = 50 (em vez de 0). Duas compras de 50, mas o saldo só
+reduziu uma vez. Se o preço fosse 60, o saldo ficaria -20 — estado impossível.
+
+## Evidência
+
+```javascript
+// Reprodução conceitual — dois requests paralelos
+const results = await Promise.all([
+  checkout(userId, 50),  // request A
+  checkout(userId, 50),  // request B
+]);
+// user.balance → 50, 2 orders created → saldo deveria ser 0
+```
+
+## Causa raiz
+
+O código executa um padrão **read-then-write sem atomicidade**. O MongoDB `.save()`
+substitui o documento inteiro — não é um `$inc` atômico — e não há `where` condicional
+que impeça a escrita se o saldo mudou.
+
+## Correção recomendada
+
+### Opção 1 — Atômico (preferida)
+
+```javascript
+// Usa $inc atômico + condicional
+const result = await User.findOneAndUpdate(
+  { _id: userId, balance: { $gte: price } },  // ← CAS: balance >= price
+  { $inc: { balance: -price } },               // ← atômico
+  { new: true }
+);
+if (!result) throw new Error('Insufficient balance');
+```
+
+### Opção 2 — Transação
+
+```javascript
+const session = await mongoose.startSession();
+session.startTransaction();
+try {
+  const user = await User.findById(userId).session(session);
+  if (user.balance < price) throw new Error('...');
+  user.balance -= price;
+  await user.save({ session });
+  await createOrder(userId, price, { session });
+  await session.commitTransaction();
+} catch {
+  await session.abortTransaction();
+}
+```
+
+**Nota:** transação sem `$inc` não fecha a janela de leitura se outro request lê antes
+do commit. Opção 1 (CAS) é mais segura.
+
+### Opção 3 — Unique constraint
+
+Se o pedido (`orderId`) for a chave de idempotência, uma unique constraint impede
+duplicação — mas não impede o *segundo* débito se o saldo foi lido antes do primeiro
+commit. Opção 1 é a defesa correta.
+
+## Checklist de aplicação
+
+| Invariant | Defesa atual | Defesa recomendada | Prioridade |
+|---|---|---|---|
+| balance ≥ 0 | `save()` sem condicional | `$inc` + `$gte` (CAS) | Critical |
+| saldo não negativo | nenhuma (sem CHECK) | `CHECK (balance >= 0)` no DB | High |
+| order única | nenhuma | UNIQUE (order_id) | High |
+
+*Ver skills: `race-condition-hunter`, `business-logic-audit`, `idempotency-audit`,
+`data-integrity-audit`.*

package/examples/xp-reward-loop.md

@@ -0,0 +1,123 @@
+# Example — XP Reward Loop Farming
+
+*Demonstração concreta de uma auditoria de loop de recompensa. Ilustra:
+`gamification-audit` + `business-logic-audit` + `idempotency-audit` +
+`race-condition-hunter` + `api-abuse-audit`. Modelo: TRIGGER → CONDITION → REWARD →
+REVERSAL (ver `plan.md` §20).*
+
+---
+
+## Target
+
+Um sistema de reações sociais em que **reagir dá +10 XP** ao autor do conteúdo. O
+usuário pode remover a reação (unreact).
+
+## Hypothesis (gerada por adversarial-review)
+
+```text
+reaction
+→ XP
+→ remove reaction
+→ reaction
+→ XP
+→ infinite farming
+```
+
+O farming acontece se a reversão (unreact) **não remove o XP concedido** — porque então
+reagir de novo re-concede XP sobre um saldo que nunca voltou.
+
+## Loop mapeado
+
+```text
+TRIGGER    → usuário reage a um post
+CONDITION  → usuário não é o autor (self-reward bloqueado); usuário ainda não reagiu
+REWARD     → autor do post recebe +10 XP
+REVERSAL   → usuário remove a reação → autor perde os 10 XP?
+```
+
+## Investigação
+
+### 1. O que acontece em `unreact`?
+
+```http
+POST /reactions/unreact {postId: 42}
+```
+
+**Resposta:** `200 OK`. O registro da reação é removido.
+
+**Pergunta:** o XP concedido na reação é *devolvido*?
+
+Rastreando o handler de unreact:
+
+```javascript
+// src/routes/reactions.js
+router.post('/unreact', auth, async (req, res) => {
+  const { postId } = req.body;
+  const exists = await Reaction.findOne({ postId, userId: req.user.id });
+  if (!exists) return res.status(404).json({ error: 'no reaction' });
+
+  await Reaction.deleteOne({ postId, userId: req.user.id });
+  // ⚠️ NENHUMA chamada para devolver XP ao autor
+  res.json({ ok: true });
+});
+```
+
+**Evidência:** `unreact` remove a reação mas **não** reverte o `+10 XP` dado ao autor
+em `react`.
+
+### 2. Confirmação — testar ACTION → REWARD → REVERSE → ACTION
+
+| Ação | XP do autor |
+|---|---|
+| (estado inicial) | 0 |
+| `react` | +10 → 10 |
+| `unreact` | **10** (deveria ser 0 — a reversão não remove) |
+| `react` (de novo) | +10 → **20** |
+
+Reproduzido: o autor acumula XP indefinidamente alternando react/unreact sobre o
+próprio conteúdo (ou sobre conteúdo de um parceiro).
+
+### 3. Vetores adicionais
+
+- **self-reward:** `react` ao *próprio* post é permitido? O handler de `react` checa
+  `post.authorId !== req.user.id`? (Rastrear.)
+- **concurrency:** dois `react` simultâneos — ambos passam na checagem "já reagiu?"
+  (read-then-write) e concedem 2× o XP? (sem unique constraint → `race-condition-hunter`.)
+- **replay:** `react` com a mesma combinação duas vezes — a checagem de existência
+  impede? (idempotência.)
+
+## Findings (resumo)
+
+| # | Severity | Confidence | Finding |
+|---|---|---|---|
+| 1 | High | CONFIRMED | Farming infinito: `unreact` não reverte o XP; `react`+`unreact` repetidos acumulam XP sem limite |
+| 2 | High | POSSIBLE | Self-reward possivelmente permitido (handler de `react` não checa `authorId` vs `userId`) |
+| 3 | Medium | HIGH CONFIDENCE | Race no dedup de reação: sem unique constraint, dois `react` simultâneos concedem XP 2× |
+
+## Causa raiz
+
+A **REVERSAL do loop é incompleta**: a ação que concede XP (`react`) e a que deveria
+removê-lo (`unreact`) não são transações acopladas. O XP é um efeito colateral do
+`react` sem o inverso no `unreact`. Falta também a constraint que faz da reação
+única por (user, post), e a checagem server-side de self-reward.
+
+## Correção recomendada
+
+1. **Reversão completa** — `unreact` deve executar a dedução dos 10 XP do autor, de
+   forma atômica (mesma transação que remove a reação).
+2. **Unique constraint** — `UNIQUE (user_id, post_id)` na tabela de reações. Impede
+   reação duplicada (fecha race e replay).
+3. **Self-reward server-side** — `react` rejeita quando `post.authorId === userId`.
+   Não confiar na UI.
+
+```sql
+-- migração
+ALTER TABLE reactions ADD CONSTRAINT uq_reaction UNIQUE (user_id, post_id);
+CREATE OR REPLACE FUNCTION grant_xp(author_id INT, delta INT)
+RETURNS void AS $$
+  UPDATE users SET xp = GREATEST(xp + delta, 0) WHERE id = author_id;
+$$ LANGUAGE sql;
+```
+
+*Ver skills: `gamification-audit`, `business-logic-audit`, `idempotency-audit`,
+`race-condition-hunter`, `api-abuse-audit`, `adversarial-review`.*