agent-engineering-skills 1.0.0

package/skills/meta/research-router/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: research-router
+description: Decides where to research based on the problem type (animation, UX, architecture, security, product, implementation), routing to the right sources in references/ and the right research skills.
+category: meta
+triggers:
+  - "where should I research"
+  - "route a problem to sources"
+  - "which references to consult"
+  - "select research sources"
+  - "research router"
+priority: high
+---
+
+# Research Router
+
+## Objective
+
+Decidir **onde pesquisar** com base no tipo de problema. O `skill-router` decide *quais
+skills*; o `research-router` decide *quais fontes*. É o estágio "RESEARCH ROUTER" do
+workflow de auditoria (ver `AGENTS.md` § 4).
+
+## When to Use
+
+* Quando uma tarefa não-trivial precisa de pesquisa antes de implementar (estágio
+  "RESEARCH" do workflow).
+* Quando o `skill-router` ativou skills de research ou sinalizou que pesquisa é
+  necessária.
+* Quando você precisa saber a que fontes de `references/` recorrer.
+* **Composição:** despacha para `reference-research` (catálogo), `github-reference-research` (GitHub), `market-research` (produtos), `implementation-research`
+  (problemas técnicos). Consome o catálogo em `references/*.yaml`.
+
+## Mental Model
+
+O router usa **o tipo de problema** para escolher as fontes. Cada tipo de problema tem
+uma combinação de fontes que o resolve melhor:
+
+| Tipo de problema | Fontes (da mais para menos relevante) |
+|---|---|
+| **Animation** | Animate UI, Impeccable, Interfaces, GitHub, real products |
+| **UX** | Laws of UX, Interfaces, real products, design systems |
+| **Visual / craft** | Impeccable, Impeccable Slop, Interfaces, Dribbble, dark.design |
+| **Architecture** | GitHub, official documentation, production implementations, technical literature |
+| **Security** | OWASP, PortSwigger, CWE, GitHub (middleware real) |
+| **Engineering/reliability** | OWASP Cheat Sheet, PortSwigger, GitHub (production), Google Testing Blog |
+| **Product/gamification** | Reforge, Product Hunt, GitHub (reward systems real) |
+| **Implementation técnica** | official documentation → GitHub/issues → production code → articles |
+| **Discovery de fontes** | LazyWeb, Shoogle, Hacker News |
+
+E a **classes de conhecimento** determina como usar a fonte (do `plan.md` §12):
+
+```text
+methodology    — fundamento (Laws of UX, OWASP)     → pesa como base
+heuristic      — princípios (Impeccable, Interfaces) → calibra decisão
+inspiration    — estética (Dribbble, dark.design)    → inspira, não decide
+implementation — código (Animate UI, GitHub)         → referência, não cópia
+discovery      — descoberta (LazyWeb, Shoogle)       → acha mais fontes
+```
+
+Não tratar todas como igualmente confiáveis (ver `docs/reference-authoring.md` para
+`authority`).
+
+## Investigation Procedure
+
+1. **Classificar o problema** — animation / ux / visual / architecture / security /
+   engineering / product / implementation / discovery.
+2. **Consultar o catálogo** — abrir os `references/*.yaml` do domínio. Cruzar o
+   `use_when` de cada entrada com o problema.
+3. **Selecionar as fontes** — pela tabela acima + `authority` (established primeiro).
+4. **Determinar a classe de uso** — o que cada fonte oferece (metodologia/princípio/
+   inspiração/código/descoberta) e como usá-la.
+5. **Despachar** — para as research skills apropriadas (`reference-research` para o
+   catálogo, `market-research` para produtos, etc.).
+6. **Priorizar** — começar por established/vendor, depois community/curated.
+7. **Justificar** a seleção — quais fontes, por quê, e quais foram descartadas.
+
+## Questions to Ask
+
+* Qual é o tipo de problema? (animation/ux/visual/architecture/security/engineering/
+  product/implementation/discovery)
+* Quais arquivos de `references/` cobrem este domínio?
+* Qual `use_when` corresponde ao problema?
+* Qual a classe de conhecimento necessária? (metodologia/princípio/inspiração/código/
+  descoberta)
+* Qual a autoridade de cada fonte candidata? (established > community > curated)
+* Que research skill executa a coleta? (reference/github/market/implementation)
+* Quais fontes NÃO ajudam este problema? (evitar ruído — ver `AGENTS.md` § 6)
+
+## Attack Patterns
+
+O router não "ataca", mas decide. Os padrões de despacho (do `plan.md` §15):
+
+```text
+Animation problem
+        ↓
+Animate UI
+Impeccable
+Interfaces
+GitHub
+real products
+
+UX problem
+        ↓
+Laws of UX
+Interfaces
+real products
+design systems
+
+Architecture problem
+        ↓
+GitHub
+official documentation
+production implementations
+technical literature
+
+Security problem
+        ↓
+OWASP (Top 10 + Cheat Sheets)
+PortSwigger
+CWE
+GitHub (middleware real)
+
+Implementation problem
+        ↓
+official documentation
+GitHub issues/PRs
+production code
+technical articles
+
+Discovery problem (fontes insuficientes)
+        ↓
+LazyWeb
+Shoogle
+Hacker News
+```
+
+## Evidence Requirements
+
+O router produz uma **decisão de despacho**, não um finding. Mas a decisão deve ser
+rastreável:
+
+* **Listar as fontes selecionadas**, com `type` e `authority`.
+* **Citar o tipo de problema** que levou à seleção.
+* **Listar as fontes descartadas** e por quê (não ajuda o problema / autoridade baixa /
+  fora de escopo).
+* **Indicar a research skill** que executará a coleta.
+* **Indicar o nível de pesquisa** (nenhuma / proporcional / completa) — ver `AGENTS.md`
+  § 6.
+
+## False Positives
+
+* **Consultar tudo sempre** — viola a proporcionalidade. Um problema de UX não precisa
+  de OWASP; um problema de segurança não precisa de Dribbble.
+* **Inspiração tratada como evidência** — fontes `type: inspiration` (Dribbble,
+  dark.design) calibram gosto, não justificam decisão técnica.
+* **Fonte de baixa autoridade como base** — community/curated não substitui
+  established/vendor para decisões críticas.
+* **Despachar para fonte inexistente no catálogo** — o router só pode despachar para o
+  que existe em `references/`. Verificar antes.
+* **Ignorar o catálogo** — o catálogo existe justamente para não espalhar URLs pelas
+  skills; consultá-lo primeiro.
+
+## Output Format
+
+```markdown
+## Research Router — Routing
+
+**Problem type:** <animation | ux | visual | architecture | security | engineering |
+  product | implementation | discovery>
+**Research level:** <none | proportional | full>
+
+### Sources selected (ordered)
+1. <fonte> — <type> / <authority> — <por quê: use_when corresponde>
+2. ...
+
+### Sources discarded
+- <fonte> — <razão>
+
+### Research skill to execute
+<reference-research | github-reference-research | market-research |
+  implementation-research>
+```
+
+Após o despacho, a research skill executa a coleta e sintetiza no formato obrigatório
+(ver `AGENTS.md` § 5 e o "Output Format" de `reference-research`).

package/skills/meta/skill-router/SKILL.md

@@ -0,0 +1,206 @@
+---
+name: skill-router
+description: Analyzes a task and selects which audit, security, reliability, product, frontend, and research skills to activate, with composition tables mapping task phrases to ordered skill sets.
+category: meta
+triggers:
+  - "which skills should I run"
+  - "route a task to skills"
+  - "select skills for an audit"
+  - "compose skills for a feature"
+  - "start an audit"
+priority: high
+---
+
+# Skill Router
+
+## Objective
+
+Analisar uma tarefa e **selecionar quais skills ativar**. Nem toda tarefa precisa de
+todas as skills. O router é a camada de despacho: lê o pedido, classifica, e retorna um
+conjunto ordenado de skills a executar. É a porta de entrada do workflow de auditoria
+(ver `AGENTS.md` § 4).
+
+## When to Use
+
+* No início de qualquer auditoria ou revisão não-trivial — é o estágio "SKILL ROUTER"
+  do workflow.
+* Quando você precisa decidir *quais* skills aplicar a um pedido vago ("audit this
+  feature").
+* Para composição — combinar skills que se complementam.
+* **Composição:** o router *é* a composição. Ele referencia todas as outras skills e
+  despacha para elas. Não há skill "abaixo" dele; há as skills que ele seleciona.
+
+## Mental Model
+
+O router usa três sinais para despachar:
+
+1. **Categoria do problema** — lógica/estado vs UX/visual vs pesquisa vs segurança vs
+   confiabilidade.
+2. **Palavras-gatilho** — mapeadas aos `triggers` de cada skill.
+3. **Risco/impacto** — fluxos com valor transferível (pagamento, recompensa, permissão)
+   ativam mais skills; UI cosmética ativa menos.
+
+Princípio de **proporcionalidade** (ver `AGENTS.md` § 6): não ative todas as skills por
+default. Uma mudança trivial e reversível não precisa de auditoria completa; uma mudança
+em fluxo de pagamento, irreversível e de alto impacto, justifica o conjunto máximo.
+
+O router **não** executa as skills — ele só seleciona e ordena. A ordem importa: skills
+que geram hipóteses (ex: `adversarial-review`) vêm antes das que confirmam (ex:
+`race-condition-hunter`, `idempotency-audit`). Skills de frontend/research vêm depois
+das de lógica quando o problema é misto.
+
+## Investigation Procedure
+
+1. **UNDERSTAND** — reformule o pedido em uma frase precisa: qual sistema/fluxo, qual
+   mudança ou risco.
+2. **CLASSIFY** — determine a categoria dominante (audit / security / reliability /
+   product / frontend / research) e se há valor transferível, estado compartilhado, ou
+   permissões envolvidas.
+3. **MATCH triggers** — compare o pedido com os `triggers` de cada skill (listados no
+   frontmatter de cada `SKILL.md`).
+4. **APPLY a tabela de composição** abaixo para o conjunto base, depois ajuste pelos
+   sinais específicos.
+5. **ORDENE** — hipóteses primeiro, confirmação depois; lógica antes de visual quando
+   misto.
+6. **JUSTifique a seleção** — diga quais skills e por quê, e quais *não* foram
+   selecionadas e por quê (evita overengineering e mostra cobertura).
+7. **Despache** — entregue a lista ordenada; o executor roda cada skill e deduplica
+   findings.
+
+## Questions to Ask
+
+* Qual é a categoria dominante do problema?
+* Há valor transferível (dinheiro, XP, moeda, estoque)? → ativa lógica + reliability.
+* Há permissões/ownership? → ativa security.
+* Há estado compartilhado ou concorrência? → ativa reliability.
+* Há UI/visual envolvido? → ativa frontend.
+* Preciso pesquisar referências antes de concluir? → ativa research (via
+  `research-router`).
+* O risco/impacto justifica o conjunto completo, ou um subconjunto basta?
+
+## Attack Patterns
+
+O router não "ataca", mas despacha. Os padrões de composição são a sua saída:
+
+```text
+"Adicionar reações que dão XP"
+        ↓
+gamification-audit
+business-logic-audit
+idempotency-audit
+race-condition-hunter
+api-abuse-audit
+user-flow-audit
+
+"Melhorar a tela de criação de personagem"
+        ↓
+ux-review
+visual-quality-review
+interaction-design
+accessibility-review
+reference-research
+market-research
+
+"payment"
+        ↓
+business-logic-audit
+idempotency-audit
+race-condition-hunter
+data-integrity-audit
+error-flow-audit
+authorization-audit
+
+"social reactions"
+        ↓
+gamification-audit
+business-logic-audit
+idempotency-audit
+race-condition-hunter
+api-abuse-audit
+```
+
+### Tabela de composição por domínio
+
+| Sinal / palavra-gatilho | Skills a ativar (ordenadas) |
+|---|---|
+| recompensa, XP, pontos, streak, achievement | `gamification-audit`, `business-logic-audit`, `idempotency-audit`, `race-condition-hunter`, `api-abuse-audit`, `user-flow-audit` |
+| payment, cobrança, checkout, reembolso | `business-logic-audit`, `idempotency-audit`, `race-condition-hunter`, `data-integrity-audit`, `error-flow-audit`, `authorization-audit` |
+| permissão, role, ownership, admin, moderator | `authorization-audit`, `input-trust-audit`, `business-logic-audit`, `api-abuse-audit` |
+| API, endpoint, rate limit, bypass UI | `api-abuse-audit`, `input-trust-audit`, `authorization-audit`, `edge-case-hunter` |
+| concorrência, race, simultâneo, double-spend | `race-condition-hunter`, `idempotency-audit`, `data-integrity-audit`, `business-logic-audit` |
+| fluxo, onboarding, wizard, steps, dead end | `user-flow-audit`, `state-consistency-audit`, `error-flow-audit`, `edge-case-hunter` |
+| erro, rollback, retry, timeout, partial | `error-flow-audit`, `idempotency-audit`, `data-integrity-audit`, `state-consistency-audit` |
+| cache, stale, desync, refresh, back button | `state-consistency-audit`, `user-flow-audit`, `data-integrity-audit` |
+| UX, usabilidade, fluxo de usuário, hierarquia | `ux-review`, `interaction-design`, `accessibility-review`, `reference-research` |
+| visual, tipografia, spacing, AI slop | `visual-quality-review`, `ux-review`, `reference-research` |
+| animação, transição, motion, reduced motion | `animation-review`, `interaction-design`, `accessibility-review` |
+| acessibilidade, keyboard, screen reader, contraste | `accessibility-review`, `ux-review` |
+| regra de negócio, invariant, limite, cota | `business-logic-audit`, `data-integrity-audit`, `input-trust-audit` |
+| descoberta de referências, como outros fazem | `reference-research`, `market-research`, `implementation-research`, `github-reference-research` |
+| auditoria genérica / "ataque o sistema" | `adversarial-review` + o subconjunto relevante acima |
+
+### Quando ativar o conjunto mínimo vs completo
+
+| Risco | Conjunto |
+|---|---|
+| trivial + reversível (botão, label, cor) | nenhum, ou só o skill de domínio único |
+| médio, reversível, sem estado compartilhado | 1–2 skills do domínio |
+| alto, estado compartilhado, valor transferível | conjunto completo do domínio |
+| crítico, irreversível, valor transferível (pagamento, permissão) | conjunto máximo + `adversarial-review` + `research-router` |
+
+## Evidence Requirements
+
+O router produz uma **decisão de despacho**, não um finding. Mas a decisão deve ser
+rastreável:
+
+* **Listar as skills selecionadas** (ordenadas).
+* **Citar o gatilho** que levou a cada (qual palavra/sinal do pedido matchou qual
+  `trigger`).
+* **Listar skills NÃO selecionadas** e por quê (fora de escopo, risco insuficiente).
+* **Indicar o nível de pesquisa** (nenhuma / proporcional / completa) — conecta ao
+  `research-router`.
+* Se uma skill não existe no repositório, **dizer explicitamente** e marcar como gap —
+  nunca inventar uma skill.
+
+A "evidência" do router é a consistência entre o pedido, os triggers das skills, e a
+tabela de composição. Se a seleção não consegue ser justificada pelos triggers, o
+router errou.
+
+## False Positives
+
+* **Ativar tudo "por segurança"** — viola o princípio de proporcionalidade. Se o risco
+  é baixo, um subconjunto basta. Overengineering é um anti-padrão (ver `AGENTS.md` § 6).
+* **Despachar para skill inexistente** — o router só pode selecionar skills que existem
+  em `skills/`. Verificar antes de listar.
+* **Ignorar pesquisa quando o problema é novo** — para arquitetura nova ou padrão não
+  trivial, omitir research é um falso negativo. Conectar ao `research-router`.
+* **Duplicar findings por não ordenar** — sem ordem (hipóteses→confirmação), skills
+  redundantes produzem findings sobrepostos. A ordem e a dedup downstream importam.
+* **Confundir categoria** — despachar um problema de concorrência só para frontend, ou
+  um problema visual só para lógica. A classificação dominante guia; os sinais
+  secundários adicionam.
+
+## Output Format
+
+```markdown
+## Skill Router — Dispatch
+
+**Task:** <reformulação precisa>
+**Dominant category:** <audit | security | reliability | product | frontend | research>
+**Risk level:** <trivial | medium | high | critical>
+**Research level:** <none | proportional | full>
+
+### Selected skills (ordered)
+1. <skill> — <gatilho que matchou>
+2. <skill> — <gatilho>
+...
+
+### Not selected
+- <skill> — <razão: fora de escopo / risco insuficiente>
+
+### Research routing
+<delegar a research-router? quais fontes? ou "none — tarefa rotineira">
+```
+
+Após o despacho, o executor roda cada skill na ordem e consolida findings via
+`templates/audit-report.md`, deduplicando sobreposições (ver `AGENTS.md` § 7).

package/skills/product/gamification-audit/SKILL.md

@@ -0,0 +1,213 @@
+---
+name: gamification-audit
+description: Detects abuse of XP, points, coins, reputation, achievements, streaks, likes, reactions, and referrals using the TRIGGER → CONDITION → REWARD → REVERSAL model, including self-reward, multi-account, replay, concurrency, and automation.
+category: product
+triggers:
+  - "audit gamification"
+  - "xp points coins reputation abuse"
+  - "streak and achievement farming"
+  - "like reaction referral abuse"
+  - "reward loop manipulation"
+priority: high
+---
+
+# Gamification Audit
+
+## Objective
+
+Ensinar o agente a modelar qualquer sistema de gamificação como um **loop de
+recompensa** e a procurar onde o loop pode ser manipulado para produzir recompensa sem
+o comportamento que ele deveria incentivar:
+
+```text
+TRIGGER
+   ↓
+CONDITION
+   ↓
+REWARD
+   ↓
+REVERSAL
+```
+
+Abusos em foco (do `plan.md` §9): XP, pontos, moedas, reputação, achievements,
+streaks, likes, reactions, referrals.
+
+## When to Use
+
+* Em qualquer sistema com recompensa (XP, pontos, moedas, reputação, achievements,
+  streaks, likes, reactions, referrals, rank).
+* Quando uma recompensa tem valor real (rank, desbloqueio, moeda, status) — o incentivo
+  à fraude cresce com o valor.
+* Quando o pedido menciona "gamification", "XP farming", "streak", "referral abuse",
+  "reward loop", "self-reward", "multi-account".
+* **Composição:** núcleo de produto. Pareia com `business-logic-audit` (regras de
+  recompensa), `idempotency-audit` (recompensa duplicada), `race-condition-hunter`
+  (farming concorrente), `api-abuse-audit` (recompensa via API direta),
+  `input-trust-audit` (XP/reward do cliente), `user-flow-audit` (fluxo do loop).
+
+## Mental Model
+
+Um sistema de gamificação é uma **máquina que emite valor**. O eixo é o loop
+TRIGGER → CONDITION → REWARD → REVERSAL: algo dispara, uma condição é checada, uma
+recompensa é emitida, e (idealmente) há um caminho de reversão.
+
+Todo loop é manipulável quando uma destas quatro falha:
+
+1. **CONDITION frágil** — a condição que impede o abuso pode ser falsificada
+   (self-reward, multi-account, automação).
+2. **REWARD sem reversão** — a ação pode ser desfeita e refeita ganhando de novo sem
+   perder o ganho anterior (farming infinito).
+3. **REWARD não-idempotente** — o mesmo trigger disparado N vezes (replay, retry,
+   concurrency) concede N vezes.
+4. **TRIGGER fabricável** — o trigger pode ser gerado artificialmente (bot, request
+   direto, referral de si mesmo).
+
+O teste canônico (do `plan.md` §9):
+
+```text
+ACTION
+→ REWARD
+→ REVERSE
+→ ACTION
+→ REWARD     ← farming se a reward não foi removida na reversão
+```
+
+E os vetores de abuso:
+
+```text
+self-reward     — dar a recompensa a si mesmo quando deveria ser de outro
+multi-account   — contas paralelas para colher recompensas por-referral/conta
+replay          — repetir o trigger depois de já colhido
+concurrency     — disparar o trigger simultaneamente N vezes
+automation      — bots executando o comportamento "incentivado"
+```
+
+## Investigation Procedure
+
+1. **Mapear cada recompensa como um loop** TRIGGER → CONDITION → REWARD → REVERSAL.
+   Liste o trigger (ação), a condição (quem/quando), a reward (quantidade, como
+   emitida), e a reversão (existe? remove a reward?).
+2. **Para cada loop, aplicar o teste ACTION → REWARD → REVERSE → ACTION → REWARD.**
+   A segunda ACTION concede de novo? Se sim, farming.
+3. **Testar os vetores:**
+   * **self-reward** — posso conceder a mim mesmo (reagir ao meu post, votar em mim)?
+   * **multi-account** — posso criar contas paralelas e referir a mim mesmo?
+   * **replay** — posso repetir o trigger após colhido (mesma ação, mesma entidade)?
+   * **concurrency** — disparar o trigger N vezes simultâneas — N rewards?
+   * **automation** — um bot consegue gerar o trigger artificialmente (não há
+     proof-of-human / rate limit / captcha)?
+4. **Verificar a reversão** — quando a ação é desfeita, a reward é removida de fato?
+   (senão: reverse → action → reward = farming)
+5. **Verificar idempotência da reward** — a mesma entidade × mesma ação é protegida por
+   unique/check server-side? (dedup)
+6. **Verificar a fonte da reward** — é calculada server-side pelo evento, ou confiável
+   no payload? (input trust overlap)
+7. **Confirmar com evidência** — reproduza o farming e observe a reward dupla.
+8. **Reportar** via `templates/audit-report.md`.
+
+## Questions to Ask
+
+* Qual o loop completo de cada recompensa? TRIGGER → CONDITION → REWARD → REVERSAL?
+* ACTION → REWARD → REVERSE → ACTION → REWARD: a segunda ACTION concede de novo?
+* Self-reward é possível (reagir/curtir/votar no próprio conteúdo)?
+* Multi-account pode colher reward por-conta (referral, bônus de novo usuário)?
+* O mesmo trigger repetido (replay) concede de novo?
+* N requests simultâneos para o mesmo trigger — N rewards?
+* Um bot pode gerar o trigger artificialmente? (rate limit? captcha? assinatura?)
+* A reversão (unreact, cancel referral) realmente remove a reward?
+* A reward é determinada server-side ou aceita do cliente?
+* A mesma (entidade, ação) é deduplicada por unique constraint?
+
+## Attack Patterns
+
+```text
+farming infinito (reversal ausente)
+    react → +10 XP
+    unreact → -0 XP (reversão não remove!)
+    react → +10 XP   ← farming: XP acumula sem limite por uma única ação
+
+reversal que re-concede
+    react → +10 XP
+    unreact → -10 XP
+    react → +10 XP   ← correto SE unreact removeu de fato. Testar se removou.
+
+self-reward
+    react no próprio post → +XP? (deveria ser proibido ou sem reward)
+    vote em si mesmo → reputation?
+
+multi-account referral
+    criar conta B (via referral de A) → A ganha bônus
+    repetir com B, C, D... → A ganha N bônus
+    (defesa: restrição por IP/device/unique identidade — contornável?)
+
+replay
+    completar streak hoje → reward
+    repetir o request do streak → reward de novo?
+    (defesa: unique (user, day) no banco)
+
+concurrency farming
+    N requests simultâneos para /claim-streak
+    todos passam a checagem read-then-write → N rewards
+    (defesa: unique constraint, lock, ou idempotency key)
+
+automation
+    bot gera o "comportamento incentivado" artificialmente
+    (se o reward exige comportamento humano e não há prova, a economia infla)
+
+like/reaction abuse
+    curtir/descurtir repetidamente para manter "engajamento"
+    (se cada curti dá algo, o toggle é farming)
+
+achievement farm
+    condição de achievement forjável (ex: "compartilhe" sem share real)
+    → achievement concedido sem o comportamento real
+```
+
+## Evidence Requirements
+
+* **Mapear o loop completo** da recompensa (TRIGGER → CONDITION → REWARD → REVERSAL)
+  no finding.
+* **Nomear o vetor de abuso** (farming/reversal/self/multi-account/replay/concurrency/
+  automation) e a fase do loop que falha (condição frágil, reversão ausente, reward
+  não-idempotente, trigger fabricável).
+* **Mostrar o mecanismo** — onde a condição é checada (server-side? só na UI?),
+  onde a reversão não remove, onde o dedup falta.
+* **Escalar confiança:**
+  * `CONFIRMED` — reproduziu a recompensa dupla/injusta (ACTION→REWARD→REVERSE→
+    ACTION→REWARD observado).
+  * `HIGH CONFIDENCE` — código mostra condição frágil / reversão ausente em loop de
+    reward claro.
+  * `POSSIBLE` — loop plausivelmente manipulável, não confirmado.
+  * `SPECULATIVE` — "pode ser farmável" sem rastrear o loop.
+* Farming que infla economia com valor real (moeda/rank) = mínimo `HIGH CONFIDENCE`
+  se o loop for claro.
+
+## False Positives
+
+* **Reversão correta** — se unreact remove a XP de fato (e é idempotente), o teste
+  ACTION→REWARD→REVERSE→ACTION não concede de novo. Confirmar a remoção real.
+* **Dedup por (entidade, ação)** — se há unique constraint server-side, replay e
+  concurrency não concedem de novo. Confirmar antes de reportar.
+* **Self-reward proibido e enforced** — se o servidor rejeita reagir ao próprio
+  conteúdo, não há self-reward. Confirmar no handler.
+* **Multi-account é risco de negócio aceito** — alguns produtos toleram (sem valor
+  real). Marcar `POSSIBLE` se o valor da reward não justifica a defesa.
+* **Rate limit/anti-bot suficiente** — se bot é barrado por rate limit + captcha +
+  assinatura, automation é mitigado. Confirmar a barreira antes de reportar.
+* **Reward é cosmética** — se XP não compra nada e não afeta rank, o farming é
+  cosmetic; reportar com severidade baixa ou como nota de produto.
+* **Streak com janela intencional** — reset diário é o design; não é bug.
+
+## Output Format
+
+Para cada loop manipulável, um finding via `templates/audit-report.md`. Em
+**Affected flow**, nomeie a recompensa e o vetor. Em **Reproduction**, dê a sequência
+concreta (ACTION→REWARD→REVERSE→ACTION ou os N requests) e o saldo final observado. Em
+**Root cause**, diga qual fase do loop falha (condição frágil / reversão ausente /
+reward não-idempotente / trigger fabricável). Em **Recommendation**, indique a defesa
+(unique constraint por entidade+ação+janela; reversão que remove de fato; restrição de
+self; rate limit + anti-bot; cálculo server-side da reward).
+
+Apresente a tabela por recompensa (reward | trigger | condição | reversão? | dedup? |
+vetor vulnerável | ✓/✗). Farming infinito e abuso com valor real primeiro; self-reward
+e multi-account depois; automation e replay em seguida.