Command Palette

Search for a command to run...

UnylyUnyly
Browse all

Dare Cli

FreeNot checked

DARE Framework - CLI, GraphRAG engine, MCP server and shared types in a single package

GitHubEmbed

About

DARE Framework - CLI, GraphRAG engine, MCP server and shared types in a single package

README

Dewtech

DARE Method

Design. Architect. Review. Execute.

A structured methodology for AI-assisted software development with mandatory human-in-the-loop reviews.

License: MIT Built by Dewtech npm Cursor IDE Antigravity

Docs PT Docs EN Docs ES

🚀 v3.18.1Rails delegado ao rails new — o scaffolder ruby-rails-8 roda o rails new de verdade (native/Docker, imagem ruby:3.3) e sobrepõe só o valor-add do DARE; runtime completo e atual (locales, credentials, storage.yml, solid_* wired). auto usa Docker quando não há Ruby nativo. Novo dare init --fullstack (não-interativo). Ver CHANGELOG. Licença MIT.

Quickstart · Método · Ralph Loop · CLI · Implementações · Comparações


⚡ Quickstart em 5 minutos

Opção 1 — Via CLI (recomendado)

# 1. Instale o CLI globalmente
npm install -g @dewtech/dare-cli

# 2. Inicialize seu projeto de forma interativa
dare init meu-projeto
# → Escolha: Estrutura (Monorepo / Backend / Frontend / MVC / MCP Server)
# → [MVC] Escolha o framework full-stack: Rails 8 (full app) ou Laravel
# → Escolha: IDE (Claude Code / Cursor / Antigravity / Hybrid)
# → Escolha: Backend (Rust/Axum, Node/NestJS, Python/FastAPI, PHP/Laravel)
# → Escolha: Frontend (React, Vue, Leptos fullstack, Leptos CSR)
# → [Rust monorepo] Layout: single-crate (crates/server + crates/web) ou multi-crate
# → Escolha: GraphRAG (SQLite, JSON, Neo4j)

# 3. Abra seu projeto e dispare o primeiro comando
cd meu-projeto
dare design "Quero uma API de autenticação JWT"

Projeto já existe? Use dare discover para instalar o DARE sem tocar no código existente:

cd meu-projeto-existente
dare discover

Atualizou o CLI globalmente? Use dare update em cada projeto para sincronizar os templates / skills / commands com a versão nova do DARE (sem mexer no seu DESIGN/BLUEPRINT/TASKS):

npm install -g @dewtech/dare-cli@latest
cd meu-projeto-dare
dare update                # interativo, com changelog + confirmação
dare update --dry-run      # só preview, não escreve

Task ficou com mock/stub/TODO escondido? v2.17+ traz dois gates anti-stub:

dare review task-034       # detecta TODO/FIXME, stubs, mocks fora de testes, funções vazias
dare refine task-034 --split  # mede complexidade e propõe quebra em sub-tasks

Ative o gate automático no Ralph Loop com review.onComplete: true em dare.config.jsondare execute --complete bloqueia DONE se a review reprovar.

Opção 2 — Manual (Cursor)

# 1. Clone o repo
git clone https://github.com/dewtech-technologies/dare-method.git
cd dare-method

# 2. Copie a implementação para o seu projeto
cp -r implementations/cursor/.cursor seu-projeto/
cp implementations/cursor/.cursorrules seu-projeto/

# 3. Abra seu projeto no Cursor e dispare o primeiro comando
/generate-design "Quero uma API de autenticação JWT em Node.js"

Pronto. Você está usando DARE.


🎯 O Problema

O desenvolvimento de software com IA hoje opera em dois extremos:

Vibe Coding Tradicional
"Me dá um código que faça X" + esperança Especificação detalhada feita só por humanos
Rápido pra protótipo, caos pra evoluir Lento, aproveita pouco a IA
Sem auditabilidade do raciocínio Sem ganho de produtividade real

DARE preenche o gap entre os dois. Mantém a velocidade da IA, mas com estrutura, contexto e checkpoints humanos.


🚀 O Método

DARE é o acrônimo de 4 fases sequenciais com responsabilidades claras:

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   1. DESIGN     →  2. ARCHITECT  →  3. REVIEW   →  4. EXECUTE          │
│   ─────────       ─────────────     ─────────      ─────────            │
│   Humano          IA propõe         Humano         IA implementa       │
│   define          arquitetura       valida         + Ralph Loop        │
│   requisitos                        e aprova                            │
│                                                                         │
│   ↓ DESIGN.md     ↓ BLUEPRINT.md    ↓ ✓ approval   ↓ Code + Tests ✓    │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘
Fase O que faz Quem faz Saída Tempo típico
1. Design Define o que vamos construir e por quê Humano (IA auxilia) DARE/DESIGN.md 15-30 min
2. Architect Decide como vamos construir, em arquitetura e tasks IA propõe, humano valida DARE/BLUEPRINT.md 5-15 min
3. Review Aprova ou ajusta o plano antes de gastar tokens Humano ✓ approval explícito 5-10 min
4. Execute Implementa task por task, com Ralph Loop rodando até gates passarem IA Código + testes verdes varia

💡 Princípio central: humanos pensam estratégia (1 e 3), IA executa tática (2 e 4). Cada transição entre fases passa por checkpoint explícito.


🤡 Ralph Loop

Ralph Wiggum — I'm in danger

"I'm in danger 😄"

Inspirado no Ralph Wiggum dos Simpsons, o Ralph Loop é o ciclo de auto-correção pós-execução que acontece dentro da fase 4 (Execute).

A piada esconde uma verdade técnica: agentes de IA são excelentes em iteração até o objetivo, mas ruins em planejamento estratégico. O Ralph Loop usa essa força. As fases anteriores (Design → Architect → Review) suprem a fraqueza.

Como funciona

┌──────────────────────────────────────────────┐
│  IA implementa task (escreve código)         │
│              ↓                               │
│  Roda os Validation Gates                    │
│    • testes unitários                        │
│    • testes de integração                    │
│    • linter / formatter                      │
│    • type checker                            │
│              ↓                               │
│  ┌─────────────┐   FAIL    ┌──────────────┐  │
│  │  Passou?    │ ────────► │ Lê o erro    │  │
│  └─────────────┘           │ Corrige      │  │
│       PASS                 │ Tenta de novo│  │
│        ↓                   └──────┬───────┘  │
│   ✓ Task done                     │          │
│                                   └─────────┘ ⟲
│                                  Ralph Loop   │
└──────────────────────────────────────────────┘

Por que "Ralph"?

Porque a IA, igual ao Ralph Wiggum, persiste confiante mesmo errando. Não desiste até a casa parar de pegar fogo (testes verdes). Não entende inteiramente o porquê — só sabe que precisa fazer passar. E, surpreendentemente, funciona.

Referências externas


🔒 Formal Verification Gate (v3.8)

Gate opt-in estrito que prova módulos críticos marcados — o solver externo decide; o CLI só orquestra e valida anti-bypass (sem LLM).

Controle O que faz
Marcação @dare-formal no código ou verification.formal.modules em dare.config.json
Dafny default Backend recomendado (Verus/Lean opcionais via --formal-backend)
Anti-bypass Rejeita assume(false)/ensures true/vazamento mesmo com exit 0 do solver
Exit 5 Toolchain ausente em módulo marcado — nunca pula em silêncio
Telemetria Aresta task --proven_by--> formal-gate no GraphRAG
{
  "verification": {
    "formal": {
      "enabled": true,
      "backend": "dafny",
      "modules": ["src/math.ts::add"],
      "maxRepairIterations": 3,
      "proofTimeoutSeconds": 120,
      "antiBypass": true
    }
  }
}
dare execute --complete task-042 --verify --formal --output "..."
dare execute --complete task-042 --verify --no-formal
dare execute --complete task-042 --verify --formal --formal-backend verus

Toolchain externa: Dafny/Z3/Verus/Lean instalados no projeto-alvo — não são deps npm do CLI.


🛡️ Reliable Verification Core (v3.3)

Núcleo determinístico que roda após o Ralph Loop quando verification.enabled: true em dare.config.json (opt-in — novos projetos nascem com enabled: false).

Gate O que valida
fail-to-pass Spec executável falhava antes da implementação (RF-02)
anti-tamper Suíte não foi enfraquecida (skip/only, menos asserções)
mutation Stryker / mutmut / cargo-mutants / Infection — score ≥ minScore
type-check Aspecto opcional por stack
decay Política de retentativa (decideNextAction — ver ralph-loop.md)
best-of-N N worktrees + seletor Pareto; --best-of N no dare execute --complete
# Liga verificação nesta conclusão de task
dare execute --complete task-042 --verify --output "..."

# Bench determinístico (qualidade dos gates, não solve-rate do agente)
dare bench --suite fixtures/bench --json --baseline bench-baseline.json --fail-on-regression 3

🕸️ Dual Graph (v3.5)

Grafo de conhecimento requisito ↔ código — ingestão e travessia 100% determinísticas (sem LLM).

Comando O que faz
dare graph owners <path> Tasks/requisitos que “possuem” símbolos sob o path
dare graph impact <path> Tasks/requisitos impactados por mudanças no path
dare graph trace <req> Rastreia RF-NN / O-NN / task-NN até code_symbol
dare graph locate <seed> Localiza símbolos/arquivos a partir de um seed (path, QN ou texto)
dare graph ingest                          # DAG + requisitos (DESIGN/BLUEPRINT/TASKS)
dare graph ingest --requirements-only      # só re-parse de requisitos
dare graph owners src/math.ts --json
dare graph impact src/math.ts --hops 3
dare graph trace RF-03 --json
dare graph locate math --limit 5

Neo4j: requer neo4j.experimental: true em dare-graph.yml até validação C1 em CI. Use sqlite ou json (recomendado).

Localização opcional antes do patch do agente: dare.config.json"graph": { "locateBeforePatch": true }.


🪝 Agent Hooks (v3.6)

Hooks são opt-in (hooks.trusted: false por default). Repo clonado não auto-executa até revisar a config ou passar --trust.

{
  "hooks": {
    "trusted": false,
    "on": {
      "on-save": [{ "action": "lint" }],
      "pre-commit": [{ "action": "dare-validate" }]
    }
  }
}
dare hooks list
dare hooks validate
dare hooks run on-save --file src/foo.ts --trust

Ações permitidas: dare-validate, dare-review, graph-register, lint, test — sempre via spawn(shell:false).

🧭 Steering files (v3.6)

Precedência determinística: PROJECT-DNA (base) → scope:projectscope:glob (por priority, empate por path).

dare steering list
dare steering show src/auth/login.ts --json

IDEs consomem steering via MCP: GET /steering?file=<rel>.

Hooks nativos Cursor/Antigravity adiados; use pre-commit + dare hooks run manual. Ver templates/HOOKS-ADAPTER.md.


🔁 Fluxo completo

1. /generate-design "Sua ideia em uma frase"
   └─► DARE/DESIGN.md
       ✋ Você revisa e aprova

2. /generate-blueprint DARE/DESIGN.md
   └─► DARE/BLUEPRINT.md
       ✋ Você revisa e aprova

3. /generate-tasks DARE/BLUEPRINT.md
   └─► DARE/TASKS.md + DARE/EXECUTION/task-001.md, task-002.md…
       ✋ Você revisa e aprova

4. /execute-task task-001
   └─► IA implementa com Ralph Loop até gates passarem
       ✓ Código + testes verdes

5. /execute-task task-002
   └─► repete para cada task

📊 /telemetry-report (opcional)
   └─► Análise de tokens, modelos, custo

🛠️ Implementações

IDE / Agente Status Pasta
Claude Code ✅ Production-ready via dare init / dare discover
Cursor IDE ✅ Production-ready implementations/cursor/
Antigravity ✅ Production-ready implementations/antigravity/
VS Code + Continue 🔜 Roadmap
JetBrains AI Assistant 🔜 Roadmap

Cada implementação tem README próprio com setup detalhado.


🔌 Skills & comandos (v3.8.0)

Paridade total CLI ↔ IDE: os 18 comandos do dare CLI (init, bootstrap, discover, reverse, dna, migrate, design, blueprint, execute, graph, dag, validate, info, update, review, refine, skill, welcome) são invocáveis como /dare-<comando> nas 3 IDEs, mais as skills transversais e de stack. Cada uma existe em formato nativo de cada IDE:

IDE Diretório Formato
Antigravity implementations/antigravity/.agents/skills/<name>/SKILL.md YAML+markdown
Claude implementations/claude/.claude/commands/<name>.md slash-command markdown
Cursor implementations/cursor/.cursor/commands/dare-<name>.md slash-command markdown (+ .cursor/rules/skill-*.mdc complementares)

Um teste de consistência (ide-command-parity.test.ts) garante o 1:1: adicionar um comando ao CLI sem o /dare-* correspondente nas 3 IDEs quebra o build.

Veja o índice completo de skills com tabela cruzada IDE × skill.

v3.8.0 — verificação formal: dare execute --complete aceita --formal, --no-formal e --formal-backend <dafny|verus|lean> junto com --verify.

Por categoria

Método DARE (6) — fases canônicas: dare-design · dare-blueprint · dare-tasks · dare-execute · dare-review · dare-refine

DAG runner (4) — orquestração de tasks paralelas: dare-dag-build (só regenera yaml) · dare-dag-run (só executa) · dare-dag-runner (build+run+viz) · dare-dag-viz (Excalidraw)

Transversais (6) — princípios de engenharia que se aplicam a qualquer stack: dare-ax (Agent Experience) · dare-layered-design (4 camadas) · dare-llm-integration (providers+cache) · dare-frontend-design (componentes+estado) · dare-realtime (WS/SSE) · dare-quality-telemetry (M-01..M-04 + CI)

Stack/Tools (8) — escopo específico: dare-bugfix-design · dare-feature-design · dare-docker · dare-security (OWASP A01-A10) · dare-telemetry · dare-rust-workspace · dare-rust-leptos · dare-laravel-api

Brownfield (3) — projetos legados: dare-reverse (Fase 0: reconstrói arquitetura módulo a módulo → IDEIA.md) · dare-dna (extrai convenções → PROJECT-DNA.md) · dare-migrate (plano de migração + Gherkin de paridade → MIGRATION/)

Stacks novas (5) — adicionadas na v3.0.0: dare-nestjs-api (Node + NestJS + Prisma) · dare-fastapi-api (Python + FastAPI + Pydantic) · dare-go-gin-api (Go + Gin/stdlib) · dare-mcp-server (MCP TS/Py) · dare-rails-api (Ruby Rails 8 + Solid Queue + Action Cable)


🔌 dare discover — projetos existentes

Instalou o DARE em um projeto que já existe? Use dare discover:

cd meu-projeto-existente
dare discover

O CLI detecta automaticamente a stack (NestJS, FastAPI, Rails, Laravel, React, Vue, MCP Server…), confirma com você e instala apenas os arquivos DARE — sem tocar no código existente. Projetos Rails (Gemfile) e Laravel são classificados como estrutura MVC.

dare discover --check   # só mostra o que detectou, sem instalar
dare discover --dir ./outro-projeto

🔁 dare reverse — engenharia reversa de legado (Fase 0)

Enquanto dare discover só detecta a stack e instala os arquivos, dare reverse faz engenharia reversa do código para reconstruir a arquitetura módulo a módulo — uma Fase 0 antes do DESIGN, pensada para projetos legados/brownfield.

cd meu-projeto-legado
dare reverse

O CLI varre o código (sem tocá-lo), detecta as fronteiras de módulo, mede tamanho por LOC e infere o grafo de dependências, gerando:

DARE/
├── IDEIA.md                       ← pré-arquitetura: o QUE é o software, com mapa de módulos
└── REVERSE/
    ├── reverse-facts.json         ← fatos determinísticos
    ├── architecture.excalidraw    ← canvas editável da arquitetura
    └── module-*.md                ← um mini-spec por módulo

O IDEIA.md traz um diagrama Mermaid do mapa de módulos (renderiza nativo no GitHub) com cor por tamanho (🔵 LOW · 🟠 MED · 🔴 HIGH). Depois, a skill /dare-reverse na sua IDE preenche as inferências semânticas (propósito, domínio, fluxos via sequenceDiagram). É um rascunho a validar: você revisa o IDEIA.md e o promove a DESIGN.md com dare design.

dare reverse --check          # só mostra os módulos detectados, sem escrever
dare reverse --modules api,auth   # limita a módulos específicos
dare reverse --no-excalidraw  # pula o canvas .excalidraw

Confiança & rastreabilidade. A skill /dare-reverse marca cada afirmação com 🟢 CONFIRMED (evidência arquivo:linha) · 🟡 INFERRED · 🔴 GAP. Os fatos estruturais já nascem 🟢 (extraídos pelo scan). Depois de marcar, rode:

dare reverse --report   # computa o índice de confiança a partir dos marcadores

Isso gera DARE/REVERSE/confidence-report.md (índice por módulo, computado deterministicamente — não auto-avaliado por LLM) e DARE/REVERSE/traceability/code-spec-matrix.md. Os 🔴 viram gaps.md (classificados por severidade) e questions.md.

Modo profundo (--deep). Extrai mais coisa do legado:

dare reverse --deep   # + ERD, API surface, regras de negócio, state machines, permissões, C4

O CLI extrai deterministicamente o modelo de dados (erd.md) e os endpoints (api-surface.md) — com evidência arquivo:linha — e o nível component do C4 (do mapa de módulos). A skill /dare-reverse completa as partes semânticas: domain-rules.md, state-machines.md (Mermaid), permissions.md e o C4 context/container.

Framework-agnostic por linguagem. A extração não depende de framework: pega SQL inline (DDL e tabelas referenciadas em queries — ex.: PHP legado com PDO), tipos/classes/structs em pastas de modelo (PHP/Python/TS/Go/Ruby/Rust), além de Prisma e dos ORMs (TypeORM/Eloquent/ActiveRecord/ SQLAlchemy). Rotas cobrem múltiplos dialetos por linguagem: Express/Nest/Fastify, Laravel/Slim/Symfony, FastAPI/Flask/Django, Rails/Sinatra, Gin/stdlib, Axum. Onde um framework existe, ele enriquece; onde não, o baseline da linguagem ainda extrai.

Fluxo brownfield: dare reverse/dare-reversedare dnadare patternsdare design --interactive/dare-designdare blueprintdare execute.


🚚 dare migrate — migração com paridade (Fase 2)

Fecha o loop brownfield: depois de entender o legado (reverse + dna), o dare migrate planeja uma reimplementação segura numa stack-alvo, com cenários Gherkin de paridade que garantem que o comportamento não quebra.

cd meu-projeto-legado        # após dare reverse (+ /dare-reverse --report)
dare migrate --to go-gin     # ou rust-axum, node-nestjs, python-fastapi, php-laravel, ruby-rails-8…

O CLI consome reverse-facts.json + dna-facts.json, herda os blocking gaps (🔴 da Fase 1) como riscos, e gera:

DARE/MIGRATION/
├── MIGRATION.md          ← paradigma, estratégia, risco, arquitetura-alvo, cutover
├── migration-facts.json
└── parity/<módulo>.feature  ← contrato Gherkin de paridade (um por módulo)

A skill /dare-migrate escreve a estratégia (big-bang vs. strangler), trata os blocking gaps, desenha a arquitetura-alvo alinhada ao DNA e preenche os cenários de paridade reais (derivados do comportamento legado). Os .feature viram o contrato de aceite da reimplementação.

dare migrate --check         # mostra origem/alvo/módulos/blocking gaps, sem escrever

Loop completo: reverse (o quê) → dna (como) → migrate (reimplementar com paridade) → design/blueprint/execute na stack-alvo.


🧬 dare dna — convenções de projeto legado

Enquanto dare reverse reconstrói o QUE o software é, dare dna extrai COMO o codebase faz as coisas — suas convenções. Em legado você não pode reescrever, então o método precisa se adaptar ao padrão do projeto. O dare dna persiste essas convenções num ruleset reutilizável.

cd meu-projeto-legado
dare dna

O CLI extrai (sem tocar no código): tooling de lint/format (+ regras-chave do Prettier/EditorConfig), convenção de nomenclatura por extensão, arquitetura/camadas, framework e cobertura de teste, bibliotecas-chave (ORM/HTTP/auth/validação) e a convenção de commits (do git log). Gera:

DARE/
├── PROJECT-DNA.md     ← ruleset de convenções (o agente segue ao trabalhar no projeto)
└── dna-facts.json     ← fatos determinísticos

Depois, a skill /dare-dna transforma os fatos em regras acionáveis ("ao criar um controller, siga X"; "validação sempre via Y") e descreve padrões que o CLI não infere (tratamento de erro, estilo de teste). Se você já rodou dare reverse, o dna reaproveita o reverse-facts.json.

dare dna --check          # só mostra as convenções detectadas, sem escrever
dare dna --dir ./outro-projeto

🔍 dare patterns — padrões recorrentes do legado

Enquanto dare dna captura convenções explícitas, dare patterns descobre padrões implícitos por frequência e co-ocorrência — camadas inferidas, idiomas de nomenclatura, chamadas recorrentes e decisões arquiteturais não documentadas. Tudo determinístico, sem LLM no CLI; a interpretação semântica fica na skill /dare-dna.

cd meu-projeto-legado
dare patterns
dare patterns --check                    # só resumo, não escreve arquivos
dare patterns --dir ./packages/api       # escaneia subdiretório
dare patterns --modules api,auth         # limita a módulos
dare patterns --inject                   # registra PATTERNS.md como fonte de steering (idempotente)

Gera:

DARE/
├── PATTERNS.md            ← skeleton com <!-- AGENT --> + seção ⚠️ Incertezas (gaps 🔴)
└── patterns-facts.json    ← fatos serializados (5 PatternKind)

Os padrões também entram no grafo (pattern / evidenced_by / exhibits) e o PATTERNS.md vira 2ª fonte-base de steering (ao lado de PROJECT-DNA.md). Sem patterns-facts.json / PATTERNS.md, o comportamento permanece idêntico ao v3.6.0.


📐 dare design --interactive — questionário de planejamento

A flag --interactive estende dare design para emitir um bloco de perguntas determinísticas (Analyst/PM) derivado de dna-facts.json + patterns-facts.json — gaps, ambiguidades e escopo. O CLI só monta o questionário; a skill /dare-design conduz 1 passagem sequencial (Analyst → PM), sem runtime multi-agente.

dare dna          # opcional, enriquece o questionário
dare patterns     # opcional, ancoragem em padrões reais
dare design "Nova feature de pagamentos" --interactive

Sem --interactive, o dare design mantém o comportamento anterior (esqueleto estático).


📦 DARE CLI — Pacote npm

O DARE Method está disponível como um pacote npm único e instalável: tudo o que o framework oferece (CLI, servidor MCP, engine GraphRAG, DAG runner) vem dentro de @dewtech/dare-cli. Não há subpacotes para gerenciar.

Pré-requisitos

Para o CLI rodar

Para dare init scaffoldar a stack escolhida

O dare init executa o scaffold oficial da stack (composer create-project, npx degit vitejs/vite/..., cargo init, go mod init, rails new, etc.). Você pode escolher de onde a toolchain vem:

Stack Toolchain nativo Imagem Docker (fallback)
ruby-rails-8 Ruby 3.3+ · Bundler 2+ · Rails 8 — https://www.ruby-lang.org/ ruby:3.3-slim
php-laravel PHP 8.2+ · Composer 2+ — https://getcomposer.org/ composer:latest
node-nestjs Node 18+ (já vem com npx) node:20-alpine
python-fastapi Python 3.11+ — https://www.python.org/downloads/ python:3.12-slim
rust-axum Rust 1.83+ via rustup — https://www.rust-lang.org/tools/install rust:1.83
go-gin Go 1.25+ — https://go.dev/dl/ golang:1.25
go-stdlib Go 1.22+ (sem framework — só net/http) — https://go.dev/dl/ golang:1.25
react, vue Node 18+ node:20-alpine
rust-leptos Rust 1.83+ (rustup) + cargo-leptos 0.2.22 ghcr.io/dewtech-technologies/dare-rust-leptos:1
rust-leptos-csr Rust 1.83+ (rustup) + trunk ghcr.io/dewtech-technologies/dare-rust-leptos:1
mcp-node-ts Node 18+ node:20-alpine
mcp-python Python 3.11+ python:3.12-slim
mcp-rust (beta) Rust 1.78+ via rustup rust:1.83
mcp-go (beta) Go 1.22+ golang:1.25

Nota v3.1.0: todas as 11 stacks têm gerador completo internalizado no @dewtech/dare-cli — 7 backends (ruby-rails-8, node-nestjs, python-fastapi, php-laravel, rust-axum, go-gin, go-stdlib) + 4 variantes MCP (mcp-node-ts, mcp-python, mcp-rust, mcp-go). Cada gerador entrega o mesmo DNA DARE: llms.txt, OpenAPI, flag --json, rate limit, .env.example sem segredos, .dare/skills.yml e CI com gates de auditoria/lint/test. Não há mais pacotes de stack isolados — tudo num único tarball publicável (corrige o erro 404 do npm install -g das versões anteriores). O comando dare new foi removido; dare init é o único entrypoint de scaffolding.

TL;DR: se você só tem Docker Desktop, o dare init consegue scaffoldar qualquer stack. Se você tem o toolchain nativo, ele é mais rápido. Se você tem os dois, escolha o modo no momento do init.

Instalação

npm install -g @dewtech/dare-cli

Modos de toolchain (a partir da v2.7.0)

Ao rodar dare init, uma pergunta nova aparece:

? Toolchain for scaffolding (composer / npm / cargo / python / go):
  ❯ 🤖 Auto — usa nativo se disponível, senão Docker (recomendado)
    🔧 Native only — exige a CLI no PATH (mais rápido, sem pull de imagem)
    🐳 Docker only — sempre usa imagem oficial (hermético, sem instalar nada no host)

A resposta é salva em dare.config.json ("toolchain": "auto") e usada em todos os dare bootstrap futuros. Override pontual com dare bootstrap --toolchain <mode>.

Modo Quando escolher
auto Default. Não sabe o que tem instalado, ou trabalha em time misto.
native Já tem toolchain instalada. Quer velocidade máxima.
docker Não quer instalar PHP/Cargo/Python/Go no host. Quer build hermético.

Caveat — Ralph Loop: dare execute --complete roda os gates (composer dump-autoload, php artisan test, cargo build, etc.) direto no host, não dentro do container do scaffold. Se você escolheu docker only sem toolchain nativa, o agente da IDE deve rodar os gates via docker compose exec app <comando> no container que a primeira task (Containerize) cria.

O que vem incluso

Componente Função
CLI dare init, discover, design, blueprint, execute, update, review, refine
CLI dare-mcp-server Servidor MCP local de contexto (~95% economia de tokens)
Engine GraphRAG Grafo de conhecimento com SQLite + FTS5
DAG Task Runner Execução paralela de tasks (Kahn's algorithm)
Anti-stub gates (v2.17+) dare review detecta mocks/stubs/TODOs; dare refine quebra tasks gigantes

Histórico: até a v1.x existiam 4 pacotes separados (dare-cli, dare-core, dare-graphrag, dare-mcp-server). A partir da v2.0 todos foram consolidados em @dewtech/dare-cli. Os 3 pacotes antigos estão deprecated no npm.

Stacks suportados

Backend (API-only): Ruby on Rails 8 · Rust/Axum · Node.js/NestJS · Python/FastAPI · PHP/Laravel · Go/Gin · Go/stdlib

MVC (full-stack): Ruby on Rails 8 (full application — views + asset pipeline + Hotwire) · PHP/Laravel — escolhidos na estrutura MVC

Frontend: React 18+ · Vue 3+ · Leptos fullstack (Rust SSR+WASM) · Leptos CSR (Rust WASM)

MCP Server: TypeScript/Node.js · Python · Rust (beta) · Go (beta) — cada um com transports stdio, SSE, HTTP Stream selecionáveis via --transport

Execução paralela com DAG Task Runner

Inspired by Cursor Cookbook DAG Task Runner, o DARE CLI suporta execução paralela de tasks:

# Gerar grafo de dependências e executar em paralelo
dare blueprint          # gera BLUEPRINT.md + dare-dag.yaml
dare execute --parallel # executa tasks independentes em paralelo
Modo Tempo estimado
Sequencial (anterior) ~280 minutos
Paralelo com DAG ~70 minutos
Ganho 75% mais rápido

Economia de tokens com MCP Server

Em vez de a IA reler o BLUEPRINT.md inteiro a cada task, o MCP Server fornece apenas o contexto necessário:

# Iniciar o servidor MCP local
dare-mcp-server

# A IA consulta contexto via HTTP em vez de reler arquivos
# POST http://localhost:3000/context/query
# { "type": "architecture", "query": "authentication", "limit": 3 }
Método Tokens usados
Reler BLUEPRINT.md completo ~8.000 tokens
Query MCP (5 resultados) ~400 tokens
Economia ~95%

Segurança do MCP Server (v3.4.0+)

O servidor embutido (dare-mcp-server) aplica hardening por padrão:

Variável Default Descrição
DARE_MCP_BIND 127.0.0.1 Host do listen — use 0.0.0.0 somente em redes confiáveis
DARE_MCP_PORT 3000 Porta HTTP
DARE_MCP_TOKEN UUID gerado no boot Bearer token — impresso mascarado uma vez no console
DARE_PROJECT_PATH process.cwd() Raiz de I/O (paths no body são ignorados)
DARE_MCP_BODY_LIMIT 1mb Limite do express.json
  • Requisições fora de loopback exigem Authorization: Bearer <token>.
  • Erros 5xx retornam JSON genérico com correlationId — sem paths absolutos nem stack.
  • Detalhes de disclosure: SECURITY.md.

📋 Comandos disponíveis (Cursor)

Core (DARE)

Comando Entrada Saída
/generate-design Descrição da feature DARE/DESIGN.md
/generate-blueprint DARE/DESIGN.md DARE/BLUEPRINT.md
/generate-tasks DARE/BLUEPRINT.md DARE/TASKS.md + task-*.md
/execute-task task-001 Código + testes ✓

Infraestrutura

Comando Saída
/generate-dockerfile Dockerfile + .dockerignore
/generate-docker-compose docker-compose.yml

Análise

Comando Saída
/telemetry-report Análise de tokens / modelos / custo
/generate-bugfix-design DESIGN específico para correção de bug
/generate-feature-design DESIGN específico para feature nova

📂 Estrutura de arquivos esperada no seu projeto

Após adotar DARE, seu projeto fica assim:

seu-projeto/
├── .cursorrules                  # Regras globais (do DARE)
├── .cursor/
│   ├── commands/                 # Os comandos /generate-*
│   └── rules/                    # Skills (Laravel, Docker, Security, etc.)
│
├── DARE/                         # Pasta de governança do método
│   ├── DESIGN.md                 # ← Fase 1 (humano define)
│   ├── BLUEPRINT.md              # ← Fase 2 (IA propõe, humano valida)
│   ├── TASKS.md                  # ← Visão geral
│   ├── EXECUTION/                # ← Fase 4 (specs por task)
│   │   ├── task-001.md
│   │   ├── task-002.md
│   │   └── …
│   └── TELEMETRY.md              # ← métricas opcionais
│
└── (resto do seu código)

⚖️ Comparações

Aspecto DARE Vibe Coding BDD TDD tradicional
Estrutura Alta (4 fases) Nenhuma Alta Média
Velocidade inicial Média Alta Baixa Baixa
Velocidade longo prazo Alta Cai com complexidade Alta Média
Auditabilidade Total (DESIGN, BLUEPRINT, TASKS) Nenhuma Alta (specs) Média (testes)
Uso de IA Otimizado (fases 2 e 4) Total mas caótico Baixo Baixo
Curva de aprendizado Média Zero Alta Alta
Ideal para Times sérios com IA Protótipos rápidos descartáveis Domínios regulados Bibliotecas / kernels

🏢 Battle-tested

DARE foi desenvolvido durante a construção de produtos reais de IA generativa na Dewtech e está em uso ativo em projetos de produção desde 2025. A metodologia evoluiu a partir de problemas concretos de:

  • Manter qualidade em codebases que crescem rápido com IA
  • Garantir que decisões arquiteturais fiquem registradas e revisitáveis
  • Reduzir débito técnico gerado por "Vibe Coding" sem estrutura
  • Permitir que membros novos do time entrem rapidamente sem perder contexto

O método não é um framework experimental — é o padrão pelo qual a Dewtech entrega software hoje.


📚 Documentação

Doc pública de usuário (canônica): docs-site/ publicada em GitHub Pages (PT · EN · ES) — CLI, stacks, agents, configuration.

Arquivo interno (RFC, metodologia, índice de skills):


🗺️ Roadmap

Veja o ROADMAP.md na raiz do repositório com:

  • Shipped — em produção na v3.8.0: Formal Verification Gate (Dafny default, opt-in estrito, anti-bypass, exit 5), Brownfield Discovery (v3.7), Agent Hooks + Steering (v3.6), Dual Graph + fix Neo4j (v3.5), Security Hardening (v3.4), Reliable Verification Core (v3.3); + paridade CLI↔IDE /dare-* nas 3 IDEs, 11 stacks com gerador completo, suíte brownfield reverse/dna/migrate, CLI/GraphRAG/MCP/DAG
  • Planejado (v3.9.x+) — VS Code + Continue, JetBrains AI Assistant, Zed Editor, site institucional, DARE Cloud
  • Histórico de releases — resumo de cada versão da v1.0.0 até a v3.8.2 atual

Detalhes técnicos de cada release ficam no CHANGELOG.md.


🤝 Contribuindo

PRs são muito bem-vindos. Veja CONTRIBUTING.md pra:

  • Adicionar nova implementação (IDE / agente)
  • Adicionar nova skill (Python, Go, Rust, mobile, etc.)
  • Reportar bugs ou sugerir melhorias na metodologia
  • Compartilhar case studies de uso real

📜 Licença

MIT — veja LICENSE.


🚀 Adotando DARE no seu time?

Workshops, consultoria de adoção e cases study customizados disponíveis via Dewtech.

📧 [email protected] 🌐 https://dewtech.tech

Feito com ❤️ pela Dewtech em Belo Horizonte, Brasil 🇧🇷

from github.com/dewtech-technologies/dare-method

Install Dare Cli in Claude Desktop, Claude Code & Cursor

Recommended · one command, every IDE
unyly install dare-cli

Installs into Claude Desktop, Claude Code, Cursor & VS Code — handles npx, uvx and build-from-source repos for you.

First time? Get the CLI: curl -fsSL https://unyly.org/install | sh

Or configure manually

Run in your terminal:

claude mcp add dare-cli -- npx -y @dewtech/dare-cli

FAQ

Is Dare Cli MCP free?

Yes, Dare Cli MCP is free — one-click install via Unyly at no cost.

Does Dare Cli need an API key?

No, Dare Cli runs without API keys or environment variables.

Is Dare Cli hosted or self-hosted?

Self-hosted: the server runs locally on your machine via the install command above.

How do I install Dare Cli in Claude Desktop, Claude Code or Cursor?

Open Dare Cli on unyly.org, pick your client tab (Claude Desktop, Claude Code, Cursor) and press Install — the config is generated automatically, no JSON editing.

Related MCPs

Compare Dare Cli with

Not sure what to pick?

Find your stack in 60 seconds

Author?

Embed badge for your README

Browse similar

All ai MCPs