forjavia
v1.3Arquitetura integrada: Spec Kit + TLC + Understand Anything

Seus agentes escrevem o código. Forjavia governa a entrega.

Um único Control Plane para orquestrar agentes de IA com Spec-Driven Development: roteamento por risco, contexto compilado, verificação independente e evidência rastreável — do requisito ao commit.

Explorar a arquiteturaCódigo aberto no GitHub

Orquestra o que você já usa

  • Claude Code
  • Codex
  • Spec Kit
  • TLC
  • Understand Anything

forjavia · governed mission

live

❯ forjavia "Adicionar Market com safe zone"

    01O problema

    Agentes de IA são rápidos. Sem governança, são rápidos em errar.

    Claude Code, Codex e afins geram código impressionante. O que falta é a camada que decide quanto rigor cada mudança merece, o que o agente precisa saber e como provar que funcionou.

    • Contexto que se perde

      Cada sessão do agente começa do zero. Decisões, lições e regras de domínio somem entre prompts.

    • Autor verificando a si mesmo

      O mesmo agente que escreve o código declara que funcionou. Sem verificador independente, "PASS" é opinião.

    • Mudanças críticas tratadas como triviais

      Uma alteração em economia, auth ou dados recebe o mesmo fluxo que ajustar um botão.

    • Sem rastreabilidade

      Do requisito ao commit não há trilha: ninguém sabe por que o código existe nem qual evidência o sustenta.

    02Arquitetura

    Três planos. Responsabilidades que não se misturam.

    O Forjavia não substitui seus agentes — ele separa quem decide, quem executa e onde a verdade é guardada.

    Control Plane

    owner: Forjavia
    • 01Risk Router: LIGHT, STANDARD ou CRITICAL
    • 02Context Compiler: só o contexto necessário
    • 03Engineering Skeptic: lentes de risco e lições
    • 04Stop Reasons e Owner Gate determinísticos
    • 05Provider Profiles e roteamento por eval

    03Fluxo governado

    Do pedido ao commit, cada etapa deixa rastro.

    Uma missão percorre um pipeline determinístico. Quem decide é o Control Plane; o agente executa dentro dos limites que recebeu.

    1. 01

      Pedido do Owner

      intake

      Uma frase em linguagem natural. O Owner define intenção, não implementação.

    2. 02

      Structured State

      state

      Requirements, decisões e lições são carregados do repositório — a única fonte da verdade.

    3. 03

      Risk Router

      route

      Classifica o risco e escolhe o rigor: modelo, esforço, sensores e nível de verificação.

    4. 04

      Context Compiler

      compile

      Monta um pacote mínimo: vizinhança no Engineering Graph, regras e lições relevantes.

    5. 05

      Engineering Skeptic

      skeptic

      Questiona a missão por lentes de risco antes de qualquer linha de código.

    6. 06

      Spec Kit + TLC

      spec

      Especificação, plano e tarefas em waves paralelas com dependências explícitas.

    7. 07

      Execução isolada

      execute

      O provider executa em uma árvore isolada. Sensores rodam a cada entrega.

    8. 08

      Verifier independente

      verify

      Outra instância verifica. O autor nunca aprova o próprio trabalho.

    9. 09

      Evidence + Decisão

      evidence

      Evidência persistida e ligada ao commit. CONTINUE, ou um Stop Reason determinístico.

    04Risk Router

    Rigor proporcional ao risco. Nem mais, nem menos.

    Mudar um texto não deveria custar o mesmo que mexer na economia do produto. O Risk Router escolhe modelo, contexto e verificação para cada missão.

    Exemplo de missão

    "Nova tela de inventário"

    Rigor aplicado

    55%

    A classificação usa sinais objetivos — arquivos tocados, domínios sensíveis e invariantes — e não a opinião do agente sobre o próprio trabalho.

    Modelo
    sonnet · effort=medium
    Contexto
    vizinhança no grafo + lições
    Spec Kit
    specify → plan → tasks
    Sensores
    testes + lint + typecheck
    Verificação
    Verifier independente
    Owner Gate
    apenas em Stop Reason

    05Engineering Graph

    Todo código sabe por que existe.

    Requirements, decisões, specs, tarefas, código, testes e evidências formam um grafo navegável. O Context Compiler usa essa vizinhança para entregar ao agente só o que importa.

    Code → src/market/access.ts · mapeado pelo Understand Anything

    06Engineering Skeptic

    Um cético na equipe que transforma dúvidas em testes.

    Antes de executar, o Cético examina a missão por lentes de risco. Quando um julgamento se prova útil, ele é promovido: vira regra, validator e teste — e deixa de depender de opinião.

    • Lentes de risco
    • DOMAIN_RISKA mudança fere alguma regra de negócio ou invariante?
    • DATA_INTEGRITYExiste caminho para corromper ou duplicar dados?
    • SECURITY_SURFACEAbre superfície nova para abuso ou vazamento?
    • REVERSIBILITYSe der errado, dá para desfazer sem dano?
    • LESSON_MATCHAlguma lição registrada já previu esse erro?

    Promoção determinística

    1. 1
      Julgamento"Market fora da safe zone permite exploit"
    2. 2
      RegraMARKET_ACCESS_REQUIRES_SAFE_ZONE
    3. 3
      Validatorvalidators/market-access.ts
    4. 4
      Testes4 casos determinísticos

    market-access.spec.ts

    • PASSbloqueia acesso fora da safe zone
    • PASSpermite acesso dentro da safe zone
    • PASSrejeita bypass via cliente
    • PASSregistra tentativa negada

    07Contratos

    Missões são contratos, não conversas.

    Cada missão nasce como um contrato versionado e termina com um resultado verificável. Quando algo sai do esperado, o sistema para com um motivo explícito — nunca com um palpite.

    • Entrada

      mission.yaml

    • Saída

      result.json

    • Parada

      Stop Reasons

    mission: M-118intent: "Adicionar Market com safe zone"risk: CRITICALsignals:  - economy_impact  - data_integrityprovider_profile: claude/opuseffort: highcontext_budget_kb: 16requirements:  - REQ-042rules:  - MARKET_ACCESS_REQUIRES_SAFE_ZONEverification: independentowner_gate: irreversible_only

    08Roadmap

    Construído em público, etapa por etapa.

    Cada etapa só começa quando a anterior tem evidência. O mesmo rigor que o Forjavia aplica aos seus agentes.

    1. etapa 00Concluído

      Cutover

      Arquitetura v1.3 integrada como base oficial.

    2. etapa 01Concluído

      Structured State

      Requirements, decisions e lessons versionados no repo.

    3. etapa 02Em andamento

      Legacy Reconciliation

      Adoção em projetos existentes sem reescrever nada.

    4. etapa 03Planejado

      Risk Router

      Classificação LIGHT, STANDARD e CRITICAL por sinais.

    5. etapa 04Planejado

      Context Compiler

      Pacotes mínimos a partir do Engineering Graph.

    6. etapa 05Planejado

      Provider Profiles

      Claude Code e Codex com perfis declarativos.

    7. etapa 06Planejado

      Engineering Skeptic

      Lentes de risco e promoção de lições em testes.

    8. etapa 07Planejado

      Independent Verifier

      Verificação separada do autor por padrão.

    9. etapa 08Planejado

      Evidence Ledger

      Trilha auditável do requisito ao commit.

    10. etapa 09Planejado

      Eval Routing

      Escolha de modelo baseada em evals reais.

    11. etapa 10Planejado

      Métricas

      Hit-rate de contexto, promoções e eficiência paralela.

    09FAQ

    Perguntas frequentes

    O Forjavia substitui o Claude Code ou o Codex?

    Não. Eles continuam sendo os executores. O Forjavia é o Control Plane que decide rigor, contexto e verificação — e pode trocar de provider sem mudar o fluxo.

    Funciona em um projeto que já existe?

    Sim. A etapa de Legacy Reconciliation mapeia o código existente com o Understand Anything e reconstrói o Structured State sem exigir reescrita.

    Onde ficam os dados e as decisões?

    No seu repositório. Requirements, decisões, lições e evidências são arquivos versionados. Não há cloud obrigatória nem lock-in.

    O que é Spec-Driven Development aqui?

    A especificação vem antes do código e é a referência da verificação. O Spec Kit gera spec, plano e tarefas; o TLC organiza a execução em waves paralelas.

    Quando o Owner é acionado?

    Só quando um Stop Reason determinístico exige: ambiguidade de requisito, ação irreversível ou divergência do Verifier. Fora isso, a missão segue sozinha.

    É pago?

    O Forjavia é open source e gratuito. Você pode apoiar o projeto contribuindo com código ou com doações.

    Open source

    Forje software confiável com os agentes que você já usa.

    Acompanhe o desenvolvimento, abra issues, contribua com código ou apoie o projeto.

    Dar uma estrela no GitHubApoiar o projeto