capivaOS — Spec-Driven Development Harness para Claude Code

Harness de desenvolvimento spec-driven para Claude Code, open-source sob MIT, instalado como plugin de marketplace. Impõe um pipeline de 5 fases (GRILL_SPEC → PLAN → IMPLEMENT → TEST_VERIFY → FINISH) por máquina de estados: hooks bloqueiam mecanicamente escrita fora de fase, merge sem spec aprovada e transição sem quality gate. O estado do sprint persiste em .board/sprint-state.md entre sessões. Versão atual v1.3.0.

Prompts são sugestão; o capivaOS é enforcement. Instruções degradam conforme a janela de contexto enche e desaparecem entre sessões — o agente "esquece" a regra no momento em que ela mais importa. No capivaOS, a disciplina é infraestrutura: um hook que bloqueia a escrita de código antes da spec aprovada funciona no primeiro minuto e na décima sessão, independente do que há no contexto. É a diferença entre pedir e impedir.

Três diferenças estruturais: (1) enforcement mecânico — guards executáveis que bloqueiam ações fora de fase, não convenção documental que depende de disciplina humana; (2) estado persistente — o board e a fase atual sobrevivem ao fim da sessão e a compactações de contexto; (3) quality gates numéricos — pisos de 75-80% de cobertura e zero warnings novos de linter como condição de transição, não como recomendação.

Sim. É um plugin do Claude Code: /plugin marketplace add iB2/capivaOS e /capiva:init no repo existente. O init detecta o contexto do projeto e configura o board e os guards sem reestruturar o repositório. Convive com CI/CD existente — os gates do capivaOS rodam ANTES do commit/PR, complementando (não substituindo) o pipeline de CI.

.NET, Python/FastAPI e Next.js, definindo padrões de código e de teste por stack. O pipeline em si é stack-agnostic: as fases e guards não dependem de linguagem, e blueprints novos são extensíveis a partir dos existentes.

Para mudanças de baixo risco existe a fast lane, que encurta o pipeline. Para o resto, a matemática é: o custo de escrever spec e plano é fixo e pequeno; o custo de retrabalho de código plausível-mas-errado é variável e composto — débito técnico, regressões e depuração semanas depois em produção. O harness troca minutos previsíveis por horas imprevisíveis.

A transição de fase é bloqueada e o agente recebe o motivo objetivo (cobertura abaixo do piso, warnings novos, critérios de aceite não atendidos). Ele corrige e tenta de novo — o humano só é chamado nos checkpoints de aprovação definidos, não a cada falha. Falha de gate é loop de correção, não interrupção.

Sim: os pisos de qualidade, os checkpoints humanos e os padrões por stack são configuráveis por projeto. O que não é configurável é pular fase silenciosamente — esse é o ponto do harness.

O capivaOS é construído sobre o sistema de plugins, hooks e skills do Claude Code, e é onde ele opera hoje. Os ARTEFATOS que produz (specs, planos, critérios de aceite, relatórios) são markdown aberto, legíveis por qualquer ferramenta — o lock-in dos seus dados é zero.

Gratuito e open-source, licença MIT, sem telemetria comercial. O código está em github.com/iB2/capivaOS. Não há tier pago do plugin; a Capiva monetiza serviços de implementação de harness em empresas, não o capivaOS.

A Capiva, boutique de IA que roda os próprios projetos de cliente no capivaOS todos os dias (Brasil, EUA e UK) — o plugin é a versão publicada da camada de desenvolvimento do harness interno da empresa. Releases versionados (v1.3.0 em julho/2026).

Dois comandos no Claude Code: /plugin marketplace add iB2/capivaOS e depois /capiva:init no seu repositório. A partir daí, a primeira tarefa já entra no pipeline: o agente te leva pela spec antes de deixar qualquer código ser escrito.

Protótipo descartável ou script one-off: o custo de spec não se paga em código que você vai jogar fora — use a fast lane ou nem instale. Repositório sem nenhum teste: os gates de cobertura pressupõem uma suíte existente; nesse caso comece criando a base de testes (o pipeline ajuda a partir daí). E se seu fluxo já tem enforcement equivalente (spec review humano obrigatório + gates de CI bloqueantes), o capivaOS replica o que você já tem — a diferença é ele impor isso DENTRO da sessão do agente, antes do commit.