@dewtech/dare-cli 2.17.0 → 3.1.0

package/templates/ide/cursor/.cursor/commands/review-task.md

@@ -1,91 +1,91 @@
-# Comando: /review-task
-
-## Descrição
-
-Audita uma task **implementada** cruzando a spec (`DARE/EXECUTION/<id>.md`) com os arquivos reais que ela tocou. Detecta stubs, mocks fora de testes, funções vazias, TODOs, retorno-fantasma — **e** valida critério-a-critério se a implementação satisfaz o que a spec prometeu.
-
-Esta é a camada **semântica** do review. A camada estática (regex / patterns) já é feita automaticamente pelo CLI quando você roda `dare review <task-id>`. Este comando combina as duas: rode a estática via CLI, gere um verdito semântico aqui, e produza um relatório fundido.
-
-## Quando rodar
-
-- Antes de marcar uma task como DONE (gate obrigatório no Definition of Done do TASK-SPEC)
-- Quando o `dare review <id>` estático passa mas você quer validação adicional contra a spec
-- Quando o dev pede revisão manual: `/review-task task-034`
-
-## Instruções para o Cursor Composer
-
-### 1. Validar argumento
-
-`$ARGUMENTS` deve conter o `task-id`. Se vazio, peça.
-
-### 2. Rodar a camada estática primeiro
-
-```bash
-dare review $ARGUMENTS --format json > .dare/review-static-$ARGUMENTS.json
-```
-
-Leia esse JSON. Se houver erros estáticos, reporte-os e pergunte se quer prosseguir com a análise semântica (geralmente não vale — corrija primeiro).
-
-### 3. Carregar contexto
-
-- `DARE/EXECUTION/$ARGUMENTS.md` — spec
-- Cada arquivo listado na seção 3 da spec
-- `DARE/BLUEPRINT.md` — contratos referenciados
-
-### 4. Auditoria critério-a-critério
-
-Para **cada** item das seções abaixo da spec, marque ✅ / ❌ com evidência (arquivo + linha):
-
-- **4.1 Objetivo (seção 1):** estado observável foi atingido?
-- **4.2 Arquivos (seção 3):** todos existem com conteúdo descrito? Há arquivos extras suspeitos?
-- **4.3 Implementação (seção 4):** cada passo executado? assinaturas exatas? validações com regras concretas (não "valida email" — a regex específica)?
-- **4.4 Testes:** cada teste listado existe? Tem assertions reais? Edge cases cobertos?
-- **4.5 Segurança (seção 5):** input validation, autorização, secrets, SQL injection — tudo conforme spec?
-- **4.6 Anti-Stub (seção 7):** a camada estática já checou — só anote se você encontrar algo que regex não pegaria (ex.: dados hardcoded disfarçados de "do banco").
-
-### 5. Emitir verdito semântico
-
-Salve em `.dare/review-semantic-$ARGUMENTS.json`:
-
-```json
-{
-  "passed": true,
-  "unmetCriteria": [],
-  "notes": "Resumo de 1-3 frases do que foi verificado"
-}
-```
-
-Se algo falhou:
-
-```json
-{
-  "passed": false,
-  "unmetCriteria": [
-    "Seção 4.3: validação de senha não implementa regex de força",
-    "Seção 4.4: teste de 'email duplicado' não existe"
-  ],
-  "notes": "2 critérios não atendidos em src/auth/register.ts"
-}
-```
-
-### 6. Rodar o review fundido
-
-```bash
-dare review $ARGUMENTS --from-agent .dare/review-semantic-$ARGUMENTS.json
-```
-
-Exit code 0 = task pode ir para DONE; 1 = não pode.
-
-### 7. Mensagem final
-
-Se passou:
-> ✅ Task `$ARGUMENTS` aprovada. Marque como DONE: `dare execute --complete $ARGUMENTS`
-
-Se falhou:
-> ❌ Task `$ARGUMENTS` não passou. Itens a corrigir: [lista]. Após corrigir, rode `/review-task $ARGUMENTS` novamente.
-
-## Regras inegociáveis
-
-- **Não invente** que algo está implementado se você não viu o código.
-- **Não aceite** mocks/stubs em código de produção mesmo que "façam o teste passar".
-- **Mocks são OK** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`.
+# Comando: /review-task
+
+## Descrição
+
+Audita uma task **implementada** cruzando a spec (`DARE/EXECUTION/<id>.md`) com os arquivos reais que ela tocou. Detecta stubs, mocks fora de testes, funções vazias, TODOs, retorno-fantasma — **e** valida critério-a-critério se a implementação satisfaz o que a spec prometeu.
+
+Esta é a camada **semântica** do review. A camada estática (regex / patterns) já é feita automaticamente pelo CLI quando você roda `dare review <task-id>`. Este comando combina as duas: rode a estática via CLI, gere um verdito semântico aqui, e produza um relatório fundido.
+
+## Quando rodar
+
+- Antes de marcar uma task como DONE (gate obrigatório no Definition of Done do TASK-SPEC)
+- Quando o `dare review <id>` estático passa mas você quer validação adicional contra a spec
+- Quando o dev pede revisão manual: `/review-task task-034`
+
+## Instruções para o Cursor Composer
+
+### 1. Validar argumento
+
+`$ARGUMENTS` deve conter o `task-id`. Se vazio, peça.
+
+### 2. Rodar a camada estática primeiro
+
+```bash
+dare review $ARGUMENTS --format json > .dare/review-static-$ARGUMENTS.json
+```
+
+Leia esse JSON. Se houver erros estáticos, reporte-os e pergunte se quer prosseguir com a análise semântica (geralmente não vale — corrija primeiro).
+
+### 3. Carregar contexto
+
+- `DARE/EXECUTION/$ARGUMENTS.md` — spec
+- Cada arquivo listado na seção 3 da spec
+- `DARE/BLUEPRINT.md` — contratos referenciados
+
+### 4. Auditoria critério-a-critério
+
+Para **cada** item das seções abaixo da spec, marque ✅ / ❌ com evidência (arquivo + linha):
+
+- **4.1 Objetivo (seção 1):** estado observável foi atingido?
+- **4.2 Arquivos (seção 3):** todos existem com conteúdo descrito? Há arquivos extras suspeitos?
+- **4.3 Implementação (seção 4):** cada passo executado? assinaturas exatas? validações com regras concretas (não "valida email" — a regex específica)?
+- **4.4 Testes:** cada teste listado existe? Tem assertions reais? Edge cases cobertos?
+- **4.5 Segurança (seção 5):** input validation, autorização, secrets, SQL injection — tudo conforme spec?
+- **4.6 Anti-Stub (seção 7):** a camada estática já checou — só anote se você encontrar algo que regex não pegaria (ex.: dados hardcoded disfarçados de "do banco").
+
+### 5. Emitir verdito semântico
+
+Salve em `.dare/review-semantic-$ARGUMENTS.json`:
+
+```json
+{
+  "passed": true,
+  "unmetCriteria": [],
+  "notes": "Resumo de 1-3 frases do que foi verificado"
+}
+```
+
+Se algo falhou:
+
+```json
+{
+  "passed": false,
+  "unmetCriteria": [
+    "Seção 4.3: validação de senha não implementa regex de força",
+    "Seção 4.4: teste de 'email duplicado' não existe"
+  ],
+  "notes": "2 critérios não atendidos em src/auth/register.ts"
+}
+```
+
+### 6. Rodar o review fundido
+
+```bash
+dare review $ARGUMENTS --from-agent .dare/review-semantic-$ARGUMENTS.json
+```
+
+Exit code 0 = task pode ir para DONE; 1 = não pode.
+
+### 7. Mensagem final
+
+Se passou:
+> ✅ Task `$ARGUMENTS` aprovada. Marque como DONE: `dare execute --complete $ARGUMENTS`
+
+Se falhou:
+> ❌ Task `$ARGUMENTS` não passou. Itens a corrigir: [lista]. Após corrigir, rode `/review-task $ARGUMENTS` novamente.
+
+## Regras inegociáveis
+
+- **Não invente** que algo está implementado se você não viu o código.
+- **Não aceite** mocks/stubs em código de produção mesmo que "façam o teste passar".
+- **Mocks são OK** dentro de `*.test.*`, `*.spec.*`, `__tests__/`, `tests/`, `spec/`.

package/templates/ide/cursor/.cursor/commands/run-dag.md

@@ -1,110 +1,110 @@
-# Comando: /run-dag
-
-## Descrição
-
-Executa o grafo de tasks definido em `DARE/dare-dag.yaml` usando o **Cursor
-como executor** e o CLI `dare` como orquestrador. O canvas ao vivo fica em
-`DARE/.canvas.md`.
-
-> **Sem API keys.** Você (Cursor) usa o plano da IDE em que o usuário já está
-> logado. O CLI apenas coordena estado, monta prompts e atualiza canvas.
-
-## Pré-requisitos
-
-- `DARE/dare-dag.yaml` existe e foi aprovado pelo usuário
-- Specs em `DARE/EXECUTION/task-<id>.md` geradas
-- `dare` disponível no PATH (`npm i -g @dewtech/dare-cli`)
-
-## Instruções para o Cursor Composer
-
-### 1. Validar pré-condições
-
-- Confirme que `DARE/dare-dag.yaml` existe. Se não, oriente o usuário a rodar
-  `/generate-tasks` primeiro
-- Leia o YAML e verifique:
-  - Sem ciclos
-  - Pelo menos 2 tasks no rank 0 (paralelismo lógico)
-  - Cada task tem `id` único, `complexity`, `subtask_prompt`
-
-### 2. Pegar próximas tasks
-
-```bash
-dare execute --next
-```
-
-O CLI imprime as tasks ready do rank atual com o prompt completo (já com
-snippets dos outputs dos pais costurados). Use exatamente esses prompts.
-
-### 3. Sugerir abrir o canvas
-
-Antes de começar, peça ao usuário abrir `DARE/.canvas.md` em uma aba para
-acompanhar o progresso ao vivo.
-
-### 4. Executar cada task
-
-Para cada task ready:
-
-1. Leia `spec_file` se houver
-2. Implemente conforme o prompt
-3. Rode Ralph Loop: build → test → lint
-4. Registre o resultado:
-
-```bash
-# Sucesso
-dare execute --complete task-001 --output "Resumo + arquivos criados/modificados (paths)"
-
-# Falha
-dare execute --fail task-002 --reason "Mensagem clara da falha"
-```
-
-### 5. Avançar de rank
-
-Após registrar todos os `--complete`/`--fail` do rank atual:
-
-```bash
-dare execute --next
-```
-
-Se aparece `✅ All tasks resolved`, todas as tasks terminaram. Caso contrário,
-continue executando o próximo rank.
-
-### 6. Pós-execução
-
-Ao terminar:
-
-- Rode `dare execute --status` para ver o sumário final
-- Se houver FAILED: leia `DARE/EXECUTION/task-<id>.md` da que falhou,
-  corrija a spec ou o prompt, depois:
-
-  ```bash
-  dare execute --reset task-002    # volta para PENDING
-  dare execute --next              # tente novamente
-  ```
-
-## Comandos disponíveis
-
-| Comando | Função |
-|---------|--------|
-| `dare execute --next` | Imprime tasks ready do rank atual com prompts |
-| `dare execute --complete <id> --output "…"` | Marca DONE |
-| `dare execute --fail <id> --reason "…"` | Marca FAILED + cascade-skip |
-| `dare execute --reset <id>` | Volta para PENDING (retry) |
-| `dare execute --status` | Snapshot do canvas + sumário |
-
-## Erros comuns
-
-| Sintoma | Causa | Correção |
-|---------|-------|----------|
-| `dare-dag.yaml not found` | Não foi gerado | Rode `/generate-tasks` |
-| Cascata de SKIPPED | Pai falhou | Corrija pai → `--reset` → `--next` |
-| Output truncado em 4000 chars | Cap normal | Faça a task escrever em arquivo, retorne resumo |
-| Tudo no rank 0 disputa o mesmo arquivo | Ausência de deps reais | Edite `dare-dag.yaml` adicionando `depends_on` |
-
-## Referências
-
-- Skill: `.cursor/rules/skill-dag-runner.mdc`
-- Schema: `DARE/dare-dag.yaml`
-- Canvas: `DARE/.canvas.md`
-- Specs: `DARE/EXECUTION/task-*.md`
-
-$ARGUMENTS
+# Comando: /run-dag
+
+## Descrição
+
+Executa o grafo de tasks definido em `DARE/dare-dag.yaml` usando o **Cursor
+como executor** e o CLI `dare` como orquestrador. O canvas ao vivo fica em
+`DARE/.canvas.md`.
+
+> **Sem API keys.** Você (Cursor) usa o plano da IDE em que o usuário já está
+> logado. O CLI apenas coordena estado, monta prompts e atualiza canvas.
+
+## Pré-requisitos
+
+- `DARE/dare-dag.yaml` existe e foi aprovado pelo usuário
+- Specs em `DARE/EXECUTION/task-<id>.md` geradas
+- `dare` disponível no PATH (`npm i -g @dewtech/dare-cli`)
+
+## Instruções para o Cursor Composer
+
+### 1. Validar pré-condições
+
+- Confirme que `DARE/dare-dag.yaml` existe. Se não, oriente o usuário a rodar
+  `/generate-tasks` primeiro
+- Leia o YAML e verifique:
+  - Sem ciclos
+  - Pelo menos 2 tasks no rank 0 (paralelismo lógico)
+  - Cada task tem `id` único, `complexity`, `subtask_prompt`
+
+### 2. Pegar próximas tasks
+
+```bash
+dare execute --next
+```
+
+O CLI imprime as tasks ready do rank atual com o prompt completo (já com
+snippets dos outputs dos pais costurados). Use exatamente esses prompts.
+
+### 3. Sugerir abrir o canvas
+
+Antes de começar, peça ao usuário abrir `DARE/.canvas.md` em uma aba para
+acompanhar o progresso ao vivo.
+
+### 4. Executar cada task
+
+Para cada task ready:
+
+1. Leia `spec_file` se houver
+2. Implemente conforme o prompt
+3. Rode Ralph Loop: build → test → lint
+4. Registre o resultado:
+
+```bash
+# Sucesso
+dare execute --complete task-001 --output "Resumo + arquivos criados/modificados (paths)"
+
+# Falha
+dare execute --fail task-002 --reason "Mensagem clara da falha"
+```
+
+### 5. Avançar de rank
+
+Após registrar todos os `--complete`/`--fail` do rank atual:
+
+```bash
+dare execute --next
+```
+
+Se aparece `✅ All tasks resolved`, todas as tasks terminaram. Caso contrário,
+continue executando o próximo rank.
+
+### 6. Pós-execução
+
+Ao terminar:
+
+- Rode `dare execute --status` para ver o sumário final
+- Se houver FAILED: leia `DARE/EXECUTION/task-<id>.md` da que falhou,
+  corrija a spec ou o prompt, depois:
+
+  ```bash
+  dare execute --reset task-002    # volta para PENDING
+  dare execute --next              # tente novamente
+  ```
+
+## Comandos disponíveis
+
+| Comando | Função |
+|---------|--------|
+| `dare execute --next` | Imprime tasks ready do rank atual com prompts |
+| `dare execute --complete <id> --output "…"` | Marca DONE |
+| `dare execute --fail <id> --reason "…"` | Marca FAILED + cascade-skip |
+| `dare execute --reset <id>` | Volta para PENDING (retry) |
+| `dare execute --status` | Snapshot do canvas + sumário |
+
+## Erros comuns
+
+| Sintoma | Causa | Correção |
+|---------|-------|----------|
+| `dare-dag.yaml not found` | Não foi gerado | Rode `/generate-tasks` |
+| Cascata de SKIPPED | Pai falhou | Corrija pai → `--reset` → `--next` |
+| Output truncado em 4000 chars | Cap normal | Faça a task escrever em arquivo, retorne resumo |
+| Tudo no rank 0 disputa o mesmo arquivo | Ausência de deps reais | Edite `dare-dag.yaml` adicionando `depends_on` |
+
+## Referências
+
+- Skill: `.cursor/rules/skill-dag-runner.mdc`
+- Schema: `DARE/dare-dag.yaml`
+- Canvas: `DARE/.canvas.md`
+- Specs: `DARE/EXECUTION/task-*.md`
+
+$ARGUMENTS

package/templates/ide/cursor/.cursor/rules/skill-ax.mdc

@@ -0,0 +1,263 @@
+---
+description: Agent Experience (AX) — codifica padrões para desenvolvimento assistido por IA em três planos (Discovery, Usage, Defense). Garante que todo projeto DARE exponha sinais estruturados (llms.txt, OpenAPI, --json, rate limit) que agentes de código precisam.
+globs: llms.txt,openapi.json,public/openapi.json,README.md,.env.example,DARE/DESIGN.md
+alwaysApply: false
+---
+
+# Skill: Agent Experience (AX) DARE
+
+Você é um especialista em integração entre projetos e agentes de código (Claude Code, Cursor, Antigravity, MCP servers). Esta skill define o **padrão AX DARE** que todo projeto novo deve seguir e contra o qual todo projeto existente deve ser auditado.
+
+## Por que AX é design-first
+
+Projetos podem ter código correto e arquitetura limpa mas **carecer de sinais estruturados** para agentes:
+- Sem `llms.txt`, o agente precisa adivinhar a estrutura
+- Sem OpenAPI, o agente faz parsing regex de docs HTML
+- Sem `--json` no CLI, o agente lida com tabelas ASCII coloridas
+- Sem rate limit, um prompt mal feito vira DDoS
+
+A skill `dare-ax` codifica três planos:
+
+| Plano | Pergunta que responde |
+|---|---|
+| **Discovery** | "Como o agente acha o que precisa?" |
+| **Usage** | "Como o agente opera sem refactor desnecessário?" |
+| **Defense** | "Como o projeto resiste a prompts ruins?" |
+
+---
+
+## Plano 1 — Discovery
+
+### `llms.txt` na raiz (obrigatório)
+
+Arquivo público com a "ficha técnica" do projeto. Formato livre mas seções fixas:
+
+```
+# <nome-do-projeto>
+
+> <descrição em 1-2 frases — o que é, qual problema resolve>
+
+## Stack
+- <linguagem + framework>
+- <banco>
+- <cache, fila, etc.>
+
+## Bootstrap
+- `make setup` — instala deps + sobe Postgres/Redis local
+- `make dev`   — sobe aplicação
+- `make test`  — roda suite
+
+## Endpoints
+- `GET  /healthz` — liveness
+- `GET  /openapi.json` — spec completa
+- `POST /api/login` — autenticação
+...
+
+## CLI (se aplicável)
+- `<bin> users create --email <e> --json`
+- `<bin> migrate run --json`
+
+## Docs internas
+- DARE/DESIGN.md — requisitos
+- DARE/BLUEPRINT.md — arquitetura
+- docs/RUNBOOK.md — operações
+```
+
+**Critério objetivo:** o arquivo deve ser navegável em < 2 minutos por um agente.
+
+### Estrutura previsível
+
+| Pasta | Conteúdo |
+|---|---|
+| `src/` ou `crates/<projeto>-*/` | código de produção |
+| `tests/` | testes (mirror de `src/` quando possível) |
+| `docs/` | documentação humana extensa |
+| `DARE/` | DESIGN.md, BLUEPRINT.md, EXECUTION/, dare-dag.yaml |
+| `infra/` ou `deploy/` | Dockerfile, compose, k8s manifests |
+
+Nomes esotéricos (`thing/`, `stuff/`, `misc/`) — proibidos.
+
+---
+
+## Plano 2 — Usage
+
+### `openapi.json` (HTTP)
+
+Toda API HTTP deve expor spec OpenAPI 3.x em `/openapi.json` ou `public/openapi.json`.
+
+| Stack | Como gerar |
+|---|---|
+| FastAPI | Automático (Pydantic models) |
+| NestJS | `@nestjs/swagger` decorators |
+| Laravel | `darkaonline/l5-swagger` |
+| Rails | `grape-swagger` ou `rswag` |
+| Rust/Axum | `utoipa` + `utoipa-swagger-ui` |
+| Go/Gin | `swaggo/swag` |
+
+**Antipattern:** escrever OpenAPI à mão em YAML — desatualiza no primeiro PR.
+
+### CLI com `--json`
+
+Todo comando de CLI exposto a humanos deve ter alternativa machine-readable:
+
+```bash
+# Para humanos
+$ dare metrics
+┌──────┬──────────┐
+│ ID   │ Status   │
+├──────┼──────────┤
+│ M-01 │ PASS     │
+└──────┴──────────┘
+
+# Para agentes
+$ dare metrics --json
+{"metrics":[{"id":"M-01","status":"PASS","value":1.0}]}
+```
+
+Regras:
+- JSON puro em stdout, sem cores ANSI, sem prompt
+- Exit code 0 em sucesso, ≠ 0 em erro
+- Schema documentado em `llms.txt`
+
+### `.env.example` versionado
+
+Sempre commitado, com **chaves e tipos**, sem valores reais:
+
+```
+DATABASE_URL=postgres://user:password@localhost:5432/dbname
+REDIS_URL=redis://localhost:6379/0
+JWT_SECRET=replace-with-256-bit-random-string
+STRIPE_SECRET_KEY=sk_test_xxx
+```
+
+`.env` real fica no `.gitignore`.
+
+---
+
+## Plano 3 — Defense
+
+### Rate limit
+
+Endpoint público sem rate limit = vulnerável. Use o middleware da stack:
+
+| Stack | Middleware típico |
+|---|---|
+| Rails | `rack-attack` |
+| Node/Express | `express-rate-limit` |
+| NestJS | `@nestjs/throttler` |
+| FastAPI | `slowapi` |
+| Rust/Axum | `tower-governor` |
+| Go/Gin | `gin-contrib/limit` ou middleware custom |
+| Laravel | `ThrottleRequests` middleware (nativo) |
+
+**Padrão recomendado:**
+- Login: 5 req / 15 min por IP + por usuário
+- API autenticada geral: 100 req / min por usuário
+- API pública: 30 req / min por IP
+
+### Validação de input
+
+Sempre no servidor, mesmo que o frontend valide:
+
+| Stack | Tooling |
+|---|---|
+| Laravel | FormRequest classes |
+| FastAPI | Pydantic models |
+| Node | Zod, class-validator |
+| Rust/Axum | `serde` + `validator` crate |
+| Rails | strong params + ActiveModel validations |
+| Go | `go-playground/validator` |
+
+### Secrets só via env
+
+Nada de `password = "..."` no código. Configure scanner no CI:
+
+```bash
+pip install detect-secrets
+detect-secrets scan > .secrets.baseline
+```
+
+### `llms.txt` sem secrets
+
+`llms.txt` é público — o scanner do CI deve bloquear commits onde apareçam:
+- `api_key=`, `password=`, `DATABASE_URL=postgres://user:pwd@`
+- `Bearer ...`, `Authorization: ...`
+- Chaves PEM, AWS access keys, GCP service account JSON inline
+
+---
+
+## Métricas obrigatórias (CI)
+
+| ID | Métrica | Comando de validação |
+|---|---|---|
+| M-01 | `llms.txt` existe e é válido (sem secrets, seções obrigatórias) | `dare ax validate --llms` |
+| M-02 | `openapi.json` ou `public/openapi.json` existe | `test -f public/openapi.json \|\| test -f openapi.json` |
+| M-03 | CLI suporta `--json` | `cli --help \| grep -- '--json'` |
+| M-04 | Rate limit configurado | grep pelo middleware da stack |
+
+Falha M-01 ou M-04 em produção = release bloqueado.
+
+---
+
+## Antipatterns
+
+| AP | Antipattern | Por que evitar |
+|---|---|---|
+| AP-01 | Docs fora do código | Divergem rapidamente |
+| AP-02 | OpenAPI escrito à mão | Desatualiza no primeiro PR |
+| AP-03 | CLI sem `--json` | Agentes fazem regex no output, frágil |
+| AP-04 | Rate limit em dev, faltando em prod | Endpoint vira target de abuse |
+| AP-05 | `llms.txt` com secrets | Credenciais em repositório público |
+| AP-06 | CORS `*` em produção | Origem qualquer permitida |
+| AP-07 | Validação só em API, esquecida em CLI | Agentes usam ambos |
+| AP-08 | Configs opcionais sem default | Agentes precisam de defaults previsíveis |
+
+---
+
+## Aplicação por fase DARE
+
+### Design (`/generate-design`)
+
+DESIGN.md deve ter seção **## Agent Experience (AX)** com:
+- Como o projeto será descoberto por agentes
+- Quais CLIs/endpoints expostos terão `--json`/OpenAPI
+- Estratégia de rate limit para endpoints públicos
+
+### Blueprint (`/generate-blueprint`)
+
+BLUEPRINT.md deve listar:
+- Geração automática de OpenAPI (qual tooling)
+- Middleware de rate limit por endpoint
+- Estratégia de logging estruturado (JSON)
+
+### Tasks (`/generate-tasks`)
+
+Crie tasks dedicadas:
+- "Gerar `llms.txt`"
+- "Expor OpenAPI em /openapi.json"
+- "Adicionar `--json` ao CLI"
+- "Configurar rate limit em endpoints públicos"
+
+### Execute (`/execute-task`)
+
+Em qualquer task que mexa em endpoint HTTP ou comando CLI, valide:
+- OpenAPI atualizado?
+- `--json` disponível?
+- Rate limit aplicado?
+
+---
+
+## Checklist final
+
+- [ ] `llms.txt` na raiz com seções obrigatórias
+- [ ] OpenAPI 3.x gerado a partir do código
+- [ ] Todos os CLIs aceitam `--json`
+- [ ] Rate limit em todos os endpoints públicos
+- [ ] `.env.example` versionado sem valores reais
+- [ ] Scanner de secrets no CI
+- [ ] Seção AX em DESIGN.md
+- [ ] Métricas M-01 a M-04 verificáveis em CI
+
+---
+
+Skill licenciada MIT — parte do DARE Method v3.