agent-engineering-skills 1.0.0

package/skills/research/reference-research/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: reference-research
+description: Discovers which external sources from the references catalog (methodology, heuristic, inspiration, implementation, discovery) are relevant to the current task and synthesizes findings into actionable patterns, not just a link list.
+category: research
+triggers:
+  - "research references"
+  - "find external sources for a task"
+  - "consult methodology and heuristics"
+  - "reference catalog lookup"
+  - "discover relevant sources"
+priority: high
+---
+
+# Reference Research
+
+## Objective
+
+Ensinar o agente a **consultar o catálogo centralizado de referências** (`references/`)
+para descobrir quais fontes externas são relevantes para a tarefa, e a sintetizar o que
+encontrou em um formato acionável, nunca apenas uma lista de links.
+
+## When to Use
+
+* No início de qualquer tarefa não-trivial que se beneficiaria de saber como outros
+  resolveram o mesmo problema.
+* Quando o `research-router` despacha para o catálogo de referências.
+* Quando o `skill-router` indica que pesquisa é necessária (tarefas de arquitetura,
+  UX, animação, segurança).
+* **Composição:** a skill de entrada de pesquisa. Ativa o `research-router` e alimenta
+  `github-reference-research`, `market-research`, e `implementation-research`. Skills
+  de frontend/UX/engenharia referenciam fontes que esta skill consulta.
+
+## Mental Model
+
+O catálogo em `references/*.yaml` é a primeira fonte de pesquisa. A pergunta é:
+
+> "Alguém já resolveu este problema?"
+
+E a resposta é uma busca no catálogo por `use_when` que corresponde ao problema, por
+`type` que corresponde ao tipo de conhecimento necessário (metodologia vs inspiração),
+e por `authority` que corresponde ao peso que a fonte deve ter.
+
+Classes de conhecimento (do `plan.md` §12 e `docs/reference-authoring.md`):
+
+```text
+methodology    — frameworks estruturados (Laws of UX, OWASP, Reforge)
+heuristic      — princípios aplicáveis (Impeccable, Interfaces)
+inspiration    — referência visual, não prescritiva (Dribbble, dark.design)
+implementation — padrões de código concretos (Animate UI, GitHub)
+discovery      — ferramentas para achar mais fontes (LazyWeb, Shoogle)
+```
+
+O `type` da fonte determina **como usar** o que ela oferece: metodologias são
+referenciadas como fundamento, inspiração só calibra gosto, implementações são
+referências de código (não para copiar cegamente — ver `AGENTS.md` § 1).
+
+## Investigation Procedure
+
+1. **Entender o problema** — qual domínio, qual tipo de conhecimento falta.
+2. **Consultar o catálogo** — ler os `references/*.yaml` relevantes para o domínio.
+   Para cada candidato, comparar `use_when` e `avoid_when` com o problema.
+3. **Selecionar as fontes** mais relevantes — priorizar pelo `authority`
+   (established > vendor > community > curated).
+4. **Visitar/acessar cada fonte** — ler o conteúdo relevante para o problema.
+5. **Extrair padrões, princípios, decisões, trade-offs** — nunca copiar código,
+   layout, branding, conteúdo, ou componentes proprietários (ver `AGENTS.md` § 1).
+6. **Sintetizar** no formato obrigatório (ver §17 do `plan.md` e "Output Format"
+   abaixo) — nunca apenas uma lista de links.
+7. **Fornecer recomendação** — o que deve ser adotado, adaptado, ou ignorado.
+
+## Questions to Ask
+
+* Qual domínio do problema? (ux/frontend/engineering/security/product/research)
+* Que tipo de conhecimento é necessário? (metodologia/heurística/inspiração/
+  implementação/descoberta)
+* Quais fontes no catálogo têm `use_when` correspondente?
+* Qual a autoridade de cada fonte? (established > community > curated)
+* A fonte oferece metodologia, princípio, código, ou inspiração?
+* O que é extraível sem copiar? (princípio, padrão, trade-off, decisão)
+* Como a fonte se aplica a este contexto específico?
+* Que problemas ela introduziria? (trade-offs)
+* Devo buscar mais fontes? (se necessário, despachar para `discovery` type)
+
+## Attack Patterns
+
+A skill de research não "ataca" o sistema, mas os padrões de investigação são as
+perguntas de despacho:
+
+```text
+problema não-trivial
+    ↓
+consultar catálogo (references/*.yaml do domínio)
+    ↓
+cruzar use_when × problema → selecionar fontes
+    ↓
+visitar fontes selecionadas
+    ↓
+extrair padrão/princípio/trade-off (não copiar)
+    ↓
+sintetizar (nunca lista de links)
+    ↓
+recomendar
+
+fontes insuficientes no catálogo
+    ↓
+despachar para discovery (LazyWeb, Shoogle, Hacker News)
+    ↓
+nova busca no catálogo (ou github/market/implementation-research)
+```
+
+## Evidence Requirements
+
+* **Nomear a fonte e seu `type`/`authority`** — para que o leitor saiba o peso.
+* **Mostrar o padrão extraído** — não só o link, mas o que a fonte diz.
+* **Explicitar a adaptação** — não é "copie isto", é "aplique assim".
+* **Escalar confiança (Research):**
+  * `CONFIRMED` — padrão replicável e verificado em fonte de alta autoridade.
+  * `HIGH CONFIDENCE` — padrão claro de fonte de autoridade média-alta.
+  * `POSSIBLE` — padrão sugestivo, fonte de autoridade baixa.
+  * `SPECULATIVE` — especulação sobre o que a fonte pode oferecer sem ter lido.
+
+## False Positives
+
+* **Fonte no catálogo mas irrelevante** — o `use_when` não corresponde à tarefa.
+  Não citar fontes irrelevantes só para mostrar cobertura.
+* **Inspiração tratada como evidência** — Dribbble é inspiração, não metodologia.
+  Não usar para justificar decisão técnica. Ver `AGENTS.md` § 1.
+* **Fonte de baixa autoridade citada como verdade** — community/curated são úteis
+  mas não substituem established/vendor para decisões críticas.
+* **Cópia em vez de adaptação** — extrair código pronto sem contexto ou adaptação
+  viola o princípio do repositório. Ver `AGENTS.md` § 1.
+* **Pesquisa excessiva para tarefa trivial** — um botão simples não precisa de
+  referências. Ver `AGENTS.md` § 6 (proporcionalidade).
+
+## Output Format
+
+Nunca retornar apenas uma lista de links. Usar o formato de síntese do `plan.md` §17:
+
+```markdown
+## Research
+
+### Reference
+[Name]
+
+### Relevant Pattern
+O que foi encontrado.
+
+### Why It Matters
+Por que este padrão é útil.
+
+### Adaptation
+Como ele poderia se aplicar ao projeto atual.
+
+### Trade-offs
+Que problemas ele introduz.
+
+### Recommendation
+O que deve de fato ser adotado.
+```
+
+Para cada fonte consultada, produza um bloco de síntese. Se múltiplas fontes dão a
+mesma recomendação, consolide em um bloco e cite as fontes.
+
+### Evidence Requirements
+
+* **Nomear a fonte e seu `type`/`authority`** — para que o leitor saiba o peso.
+* **Mostrar o padrão extraído** — não só o link, mas o que a fonte diz.
+* **Explicitar a adaptação** — não é "copie isto", é "aplique assim".
+* **Escalar confiança (Research):**
+  * `CONFIRMED` — padrão replicável e verificado em fonte de alta autoridade.
+  * `HIGH CONFIDENCE` — padrão claro de fonte de autoridade média-alta.
+  * `POSSIBLE` — padrão sugestivo, fonte de autoridade baixa.
+  * `SPECULATIVE` — especulação sobre o que a fonte pode oferecer sem ter lido.
+
+### False Positives
+
+* **Fonte no catálogo mas irrelevante** — o `use_when` não corresponde à tarefa.
+  Não citar fontes irrelevantes só para mostrar cobertura.
+* **Inspiração tratada como evidência** — Dribbble é inspiração, não metodologia.
+  Não usar para justificar decisão técnica. Ver `AGENTS.md` § 1.
+* **Fonte de baixa autoridade citada como verdade** — community/curated são úteis
+  mas não substituem established/vendor para decisões críticas.
+* **Cópia em vez de adaptação** — extrair código pronto sem contexto ou adaptação
+  viola o princípio do repositório. Ver `AGENTS.md` § 1.
+* **Pesquisa excessiva para tarefa trivial** — um botão simples não precisa de
+  referências. Ver `AGENTS.md` § 6 (proporcionalidade).

package/skills/security/api-abuse-audit/SKILL.md

@@ -0,0 +1,178 @@
+---
+name: api-abuse-audit
+description: Treats the API as directly accessible and investigates repetition, replay, ID manipulation, extra fields, alternative endpoints, missing rate limiting, and UI bypass to find abuse the server fails to prevent.
+category: security
+triggers:
+  - "audit api abuse"
+  - "treat api as directly accessible"
+  - "bypass the ui"
+  - "missing rate limiting"
+  - "replay and id manipulation"
+priority: high
+---
+
+# API Abuse Audit
+
+## Objective
+
+Ensinar o agente a **tratar a API como diretamente acessível**, ignorando a UI. O
+usuário malicioso não clica em botões; ele chama endpoints. Esta skill procura abuso
+que o servidor falha em prevenir quando o request é construído à mão: repetição, replay,
+manipulação de IDs, campos extras, endpoints alternativos, ausência de rate limiting, e
+bypass da UI.
+
+## When to Use
+
+* Em qualquer auditoria onde existe uma API por trás de um frontend.
+* Quando uma ação sensível (grant, create, transfer, redeem, vote) é exposta por
+  endpoint.
+* Quando o pedido menciona "API abuse", "rate limiting", "bypass UI", "direct API
+  calls", "replay", "mass assignment".
+* **Composição:** pareia com `input-trust-audit` (campos extra = valores confiados),
+  `authorization-audit` (ID manipulation = IDOR), `idempotency-audit` (replay/repeat),
+  `race-condition-hunter` (concorrência via API), `gamification-audit` (abuso de
+  reward via API), `business-logic-audit` (limites via API).
+
+## Mental Model
+
+A UI é uma camada de conveniência, não de segurança. Toda proteção que vive só na UI
+(esconder campos, desabilitar botões, limitar cliques, validar no submit) é inexistente
+para quem chama a API direto. O modelo:
+
+```text
+para cada ação exposta:
+    qual request a UI faz?
+    quais campos/IDs/parâmetros o servidor aceita além do que a UI envia?
+    o servidor impõe limite/frequency/idempotência/ownership?
+```
+
+O eixo central é: **qual é a diferença entre o que a UI permite e o que a API aceita?**
+Toda diferença é uma superfície de abuso potencial.
+
+Classes de abuso (do `plan.md` §7):
+
+```text
+repetition             — chamar a mesma ação N vezes
+replay                 — reenviar um request capturado
+ID manipulation        — trocar IDs para agir sobre recursos alheios
+extra fields           — enviar campos que a UI não mostra (mass assignment)
+alternative endpoints  — contornar o endpoint protegido por um equivalente desprotegido
+missing rate limiting  — nenhuma frequência imposta
+UI bypass              — fazer pela API o que a UI proíbe/esconde
+```
+
+## Investigation Procedure
+
+1. **Inventariar endpoints** da ação em escopo (e endpoints equivalententes/relacionados).
+2. **Para cada endpoint, capturar o request nominal** — método, path, body, headers,
+   auth. Este é o que a UI envia.
+3. **Testar repetição** — envie N vezes. O efeito escala? Há limite?
+4. **Testar replay** — capture um request válido, reenvie após o efeito esperado ter
+   expirado/consumido. Ainda funciona?
+5. **Testar ID manipulation** — troque o ID do recurso por um alheio. (conecta a
+   `authorization-audit`/IDOR).
+6. **Testar extra fields** — adicione campos não-enviados pela UI (`role`, `xp`,
+   `ownerId`, `status`, `price`). Aceitos? (mass assignment).
+7. **Testar endpoints alternativos** — existe um segundo endpoint que faz o mesmo sem
+   a checagem? (admin/internal/legacy path).
+8. **Testar rate limiting** — burst de requests. Algum é rejeitado (429)? Ou tudo
+   passa?
+9. **Testar UI bypass** — qual ação a UI proíbe (disabled/hidden) cujo endpoint ainda
+   aceita?
+10. **Confirmar com evidência** — reproduza o abuso e observe o efeito.
+11. **Reportar** via `templates/audit-report.md`.
+
+## Questions to Ask
+
+* Quais endpoints servem a ação? Só um, ou há versões alternativas (admin/internal)?
+* O que a UI envia vs o que o servidor aceita? Campos extras são ignorados ou gravados?
+* Repetir o request N vezes — o efeito cresce sem limite?
+* Um request capturado pode ser reenviado depois? (replay / sem nonce ou expiry)
+* Trocar o ID do recurso — acesso alheio permitido?
+* Há rate limiting? Por-IP, por-user, por-recurso? É bypassável (trocar IP, multi-conta)?
+* A UI desabilita uma ação em certo estado — o endpoint correspondente rejeita também?
+* Campos como `role`/`xp`/`price` no body — o servidor lê do payload ou da sessão/DB?
+* Há um endpoint "interno" ou "legacy" sem authz que faz o mesmo efeito?
+
+## Attack Patterns
+
+```text
+repetition
+    POST /claim  ×100   → 100 rewards? limite imposto?
+
+replay
+    POST /vote {postId:7}  → 200 (registrado)
+    replay same request    → 200 again? voto duplicado / troca-e-vota de novo?
+
+ID manipulation
+    POST /react {targetUserId: <other>}   → reage em nome/para outro?
+
+extra fields (mass assignment)
+    PUT /profile {bio:"x"}
+    PUT /profile {bio:"x", role:"admin"}  → role gravado?
+
+alternative endpoint
+    POST /reactions        (valida "no self-reward")
+    POST /reactions/internal/bulk          (valida? ou é legacy desprotegido?)
+
+missing rate limiting
+    1000 req/s para /redeem   → nenhum 429? drena estoque/cota
+
+UI bypass
+    UI: botão "delete" disabled quando status=="locked"
+    API: DELETE /item/{id}   → aceita mesmo em locked? (validação server-side?)
+
+parameter tampering
+    POST /transfer {amount: 100, currency}
+    POST /transfer {amount: -100}          → inverte fluxo? (edge-case overlap)
+
+verb tampering
+    GET /admin/users bloqueado por authz no GET
+    POST /admin/users (ou HEAD)            → middleware só protegeu um verbo?
+```
+
+## Evidence Requirements
+
+* **Nomear o endpoint e o tipo de abuso** (repeat/replay/ID/extra/alternative/rate/UI
+  bypass).
+* **Mostrar o request exato** que abusa (método, path, body, headers) e a resposta.
+* **Mostrar o efeito** — o que o abuso consegue (reward N×, acesso alheio, role
+  alterada, cota drenada).
+* **Escalar confiança:**
+  * `CONFIRMED` — reproduziu o abuso e observou o efeito (request + resposta +
+    consequência).
+  * `HIGH CONFIDENCE` — endpoint visivelmente sem a proteção, sem reprodução manual.
+  * `POSSIBLE` — abuso plausível, não confirmado.
+  * `SPECULATIVE` — "poderia ser abusado" sem rastrear.
+* Abuso que concede valor ou acessa dado alheio = mínimo `HIGH CONFIDENCE` se
+  reproduzido.
+
+## False Positives
+
+* **Rate limiting existe e é eficaz** — se 429 é retornado e o efeito não escala,
+  "repetition" é defendido. Confirmar o limite antes de reportar.
+* **Mass assignment defendido por allowlist** — se o servidor usa uma allowlist de
+  campos atualizáveis e ignora o resto, `role` extra não é gravado. Confirmar.
+* **Replay defendido por nonce/expiry** — se há idempotency key ou nonce com TTL,
+  replay não duplica. Relacionado a `idempotency-audit`; não duplique.
+* **ID manipulation defendido por ownership check** — se o handler valida que o
+  recurso pertence ao caller, IDOR não aplica. Relacionado a `authorization-audit`.
+* **Endpoint alternativo é protegido igual** — se `/internal/*` exige admin real,
+  não é bypass. Confirmar a proteção no endpoint alternativo.
+* **UI bypass é puramente cosmético** — se a ação "disabled" na UI é também rejeitada
+  server-side no mesmo estado, não há bypass.
+* **Ação é pública/idempotente por design** — alguns endpoints públicos sem rate limit
+  são aceitáveis (ex: view counter). Julgar pelo impacto.
+
+## Output Format
+
+Para cada abuso confirmado/plausível, um finding via `templates/audit-report.md`. Em
+**Reproduction**, dê o request exato (curl-equivalente) e a resposta observada. Em
+**Affected component**, nomeie o endpoint. Em **Root cause**, diga qual proteção falta
+(rate limit / allowlist de campos / ownership check / nonce / proteção no endpoint
+alternativo). Em **Recommendation**, indique a defesa server-side (rate limit por-user
+não só por-IP; allowlist de campos; ownership check; idempotency key; descontinuar
+endpoint legacy).
+
+Apresente a matriz (endpoint × tipo de abuso × protegido? × evidência). Abuso que
+concede valor ou acessa alheio primeiro; missing rate limiting e UI bypass depois.

package/skills/security/authorization-audit/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: authorization-audit
+description: Analyzes authenticated vs authorized vs owner vs moderator vs admin vs resource-participant and verifies that authorization is enforced on the server for every resource access, not just authentication.
+category: security
+triggers:
+  - "audit authorization"
+  - "check access control"
+  - "authenticated vs authorized"
+  - "owner and moderator permissions"
+  - "idor and privilege escalation"
+priority: high
+---
+
+# Authorization Audit
+
+## Objective
+
+Ensinar o agente a separar **autenticação** (quem é você) de **autorização** (o que você
+pode fazer) e a verificar que o servidor impõe autorização para *cada* acesso a recurso.
+O bug canônico desta skill:
+
+```text
+GET /resource/123
+
+authenticated ≠ authorized
+```
+
+Estar logado não significa ter permissão sobre o recurso 123.
+
+## When to Use
+
+* Sempre que um fluxo envolve recursos pertencentes a um usuário (posts, pedidos,
+  documentos, configurações, dados de perfil).
+* Quando há papéis (authenticated / authorized / owner / moderator / admin /
+  resource participant) e transições entre eles.
+* Antes de lançar features com dados sensíveis ou multi-tenant.
+* Quando o pedido menciona "authorization", "access control", "permissions", "roles",
+  "IDOR", "privilege escalation", "who can access".
+* **Composição:** núcleo de auditoria de acesso. Pareia com `input-trust-audit`
+  (ownership/role confiados ao cliente), `api-abuse-audit` (bypass via endpoints
+  alternativos), `business-logic-audit` (ownership como regra), `user-flow-audit`
+  (fluxos que cruzam fronteiras de papel).
+
+## Mental Model
+
+Autorização é uma matriz: **sujeito × ação × recurso**. Cada célula deve ter uma
+decisão (permitir / negar) imposta no servidor. Bugs vivem em três lugares:
+
+1. **Células não avaliadas** — o handler checa autenticação mas não autorização; a
+   célula "qualquer usuário × ler × recurso alheio" nunca é testada.
+2. **Decisão no cliente** — a UI esconde botões baseada em papel, mas o endpoint
+   aceita o request de qualquer um. O usuário malicioso não usa a UI.
+3. **Papéis implícitos / confusos** — "authenticated" tratado como "authorized"; ou
+   "participant" confundido com "owner"; ou moderator com poder de admin sem checagem
+   explícita.
+
+Os papéis formam uma hierarquia que deve ser *explícita*:
+
+```text
+authenticated        — tem identidade, nada mais
+authorized            — tem permissão para a ação (genérica)
+owner                 — é dono do recurso específico
+resource participant  — é parte do recurso (membro, convidado)
+moderator             — pode agir sobre recursos de outros num escopo
+admin                 — pode agir sobre tudo num escopo
+```
+
+A skill percorre a matriz e procura células não-impostas.
+
+## Investigation Procedure
+
+1. **Listar recursos** e suas ações (CRUD + ações de domínio: approve, invite, transfer).
+2. **Para cada par (recurso, ação), determinar o papel exigido** — owner?
+   participant? moderator? admin? ou basta authenticated?
+3. **Verificar onde a decisão é imposta** — handler server-side? middleware?
+   só no cliente? em nenhum lugar?
+4. **Testar horizontal privilege escalation** — usuário A acessa recurso de usuário B
+   (mesmo papel, dono diferente). O servidor rejeita?
+5. **Testar vertical privilege escalation** — usuário authenticated tenta ação de
+   admin/moderator. O servidor rejeita?
+6. **Testar IDOR** — manipular o ID do recurso (`/resource/124` em vez de `/123`) para
+   acessar recurso alheio.
+7. **Testar participant vs owner** — um membro de um grupo pode deletar o grupo? Um
+   convidado pode transferir ownership?
+8. **Verificar papel vindo do cliente** — role/ownership é confiado no payload?
+   (conecta a `input-trust-audit`).
+9. **Confirmar com evidência** — reproduza o acesso indevido ou aponte o handler que
+   não checa.
+10. **Reportar** via `templates/audit-report.md`.
+
+## Questions to Ask
+
+* Para cada (recurso, ação): qual papel é exigido? Onde é checado?
+* O handler valida que o solicitante é o *owner* do recurso, ou só que está logado?
+* Posso trocar o ID no path/body para acessar recurso de outro usuário? (IDOR)
+* Um usuário comum pode chamar um endpoint admin? (vertical escalation)
+* O papel vem do token/sessão (server-side) ou do body do request? (input trust)
+* "Participant" e "owner" são distinguidos? Um participant pode deletar?
+* Moderator tem os poderes de admin delimitados por escopo, ou globais?
+* Há um middleware de autorização ou cada handler reimplementa (e esquece)?
+* A UI esconde ações — e o endpoint correspondente as rejeita sem a UI?
+
+## Attack Patterns
+
+```text
+IDOR — horizontal
+    user A: GET /order/1000  (próprio) → 200
+    user A: GET /order/1001  (de user B) → 200? deveria ser 403
+
+vertical escalation
+    user (authenticated): POST /admin/users/delete {id} → 200? deveria ser 403
+
+participant → owner action
+    member: DELETE /group/{groupId}            → permitido? só owner deveria
+
+role from client
+    PUT /profile {role: "admin"}               → aceito? (mass assignment / input trust)
+    POST /grant {targetUserId, xp}             → sem checar que caller é admin
+
+moderator scope bleed
+    moderator of forum X acts on forum Y       → escopo validado?
+
+missing middleware, handler forgets
+    /api/orders/* tem authz middleware
+    /api/orders/special-case  esqueceu de herdar  → bypass
+
+authenticated treated as authorized
+    GET /settings/{userId}                     → só checa token válido, não que userId==token.sub
+
+delete via alternative verb/endpoint
+    não pode DELETE /post/123 (checa owner)
+    pode POST /post/123/delete  (esqueceu checar)  → bypass por endpoint alternativo
+```
+
+## Evidence Requirements
+
+* **Nomear o (recurso, ação) e o papel exigido vs o papel imposto.**
+* **Mostrar o acesso indevido** — request reproduzido com dois usuários, ou o handler
+  que checa só autenticação.
+* **Classificar o tipo** — IDOR (horizontal) / vertical escalation / participant→owner /
+  role-from-client / scope-bleed / endpoint-alternativo.
+* **Escalar confiança:**
+  * `CONFIRMED` — reproduziu com duas contas (A lê/edita recurso de B, ou common faz
+    admin).
+  * `HIGH CONFIDENCE` — handler visivelmente não checa ownership, sem reprodução.
+  * `POSSIBLE` — endpoint suspeito, caminho não confirmado.
+  * `SPECULATIVE` — "deveria haver checagem" sem rastrear.
+* Acesso a dados sensíveis de outro usuário = mínimo `HIGH CONFIDENCE` se reproduzido.
+
+## False Positives
+
+* **Autorização via middleware/global** — se um middleware impõe authz para todos os
+  endpoints sob um prefixo, o handler "sem checagem" está coberto. Confirmar o
+  middleware aplica à rota exata.
+* **Recurso é público por design** — alguns recursos são world-readable (perfil
+  público, post público). Acessar sem ser owner é intencional. Verificar a intenção.
+* **Participant tem poderes reais** — se o produto define que membros podem deletar,
+  isso é decisão de produto, não bug. Marcar `POSSIBLE` se duvidar.
+* **Role imposta por token, não pelo body** — se o servidor ignora `role` no body e usa
+  o claim do token, "role from client" é defesa, não defeito. Confirmar.
+* **Endpoint admin separado e protegido** — se a ação admin vive só em `/admin/*`
+  protegido, o endpoint "comum" que parece exposto pode nem existir/implementar.
+* **Self-access legítimo** — acessar o próprio recurso via ID alheio-numerado não é
+  IDOR se o ID é o seu.
+
+## Output Format
+
+Para cada (recurso, ação) sem imposição server-side de autorização, um finding via
+`templates/audit-report.md`. Em **Reproduction**, dê o request com duas identidades
+demonstrando o acesso indevido. Em **Root cause**, diga onde a checagem falta
+(middleware ausente, handler esqueceu, role do cliente confiada). Em **Recommendation**,
+indique imposição server-side (middleware de authz centralizado + checagem de ownership
+no handler; nunca confiar role do body).
+
+Apresente a matriz (recurso × ação × papel exigido × onde imposto × ✓/✗). IDOR e
+escalada vertical primeiro; participant→owner e scope-bleed depois.