Manifesto

O Manifesto é a metodologia de desenvolvimento de Joseph Trupel, usada em todos os projetos: um caminho só para planejar, decidir, executar e entregar software, com uma IA agente conduzindo o trabalho e o humano revisando. Tudo o que mexe no código é uma ADR com seis arquivos, no repositório; o controle do trabalho (tarefas e prazos) mora no Gestor, recomendado e não obrigatório. Comece por O que é o Manifesto.

A versão em vigor

• Versão2.0.0
• Capítulos10
• Documentos44

A última mudança, 2.0.0 — 2026-10-08 · ADR 143 (o Manifesto escrito para usar com o Gestor):

O que mudou de sentido (por isso a versão maior):

• “Tudo é ADR” virou “Tudo o que mexe no código é ADR” (princípio 2). Do módulo ao bugfix de uma linha, o código continua sempre numa ADR. O que não mexe no código — um deploy, um roadmap, a organização do trabalho — deixa de ser ADR: é uma tarefa no Gestor, se valer registrar. Um estudo só vira ADR quando é complexo e vai ser reaproveitado. A regra e os casos estão no capítulo novo Tarefa ou ADR.
• “Fonte da verdade é o repositório” virou “Um fato, um lugar” (princípio 4): o que é útil no contexto do repositório (a decisão, o plano, a execução viva, os relatórios) mora na ADR; o que é útil para gerir (as tarefas, os prazos, os ciclos, a conversa com o cliente) mora no Gestor. A matriz fato a fato está em Quem faz o quê.
• A IA orquestra sozinha. Ninguém precisa dizer “abre a tarefa tal” ou “abre a ADR tal”: a IA decide se o trabalho é ADR, acha ou cria a ADR, vincula à tarefa e anda a tarefa (Em andamento ao começar, Revisão ao fechar a ADR; o Concluído é do dono). A regra está num bloco único de Tarefa ou ADR, entre as marcas <!-- manifesto:regra:inicio --> e <!-- manifesto:regra:fim -->, que o Gestor lê e leva às instruções do MCP e ao Executar; o manifesto:check confere o bloco.
• “Abrir ADR” deixou de ser papel do Arquiteto e do CEO: a IA abre pela regra, e eles aprovam o 001 e decidem o quiz (Papéis).

O que mudou (sem mudar de sentido):

• A numeração vem da reserva do Gestor (sem colisão entre sessões paralelas, nunca reusada); sem o Gestor, o maior + 1. O índice .specs/readme.md é uma lista enxuta e narrativa (número, título e situação), sem “a próxima ADR é a…”, e o CLAUDE.md também deixa de dizê-lo (Fluxo de ADR).
• ADRs vinculadas às tarefas do Gestor, com os papéis implementa e contexto; o 005 copia as tarefas vinculadas no fechamento (seção “Tarefas no Gestor” no modelo). O termo é vincular.
• O commit cita a tarefa e a ADR no rodapé (Tarefa: KBP-12, ADR: 098), e o Gestor mostra esses commits no item e na ADR, só à equipe (Git e commits).
• O 006 chega ao cliente pelo Gestor; o envio pelo Discord vira opcional (Relatórios e PDF).
• Glossário: “Tarefa” é a do Gestor; o item técnico do 004 é o passo (o arquivo continua 004-tasks.md, e o modelo chama a coluna de “Passo”).
• Continua igual: o 001 com a situação (Em planejamento · Em execução · Concluído) e a tabela de prazos; o 004 com a situação de cada passo (todo / doing / done / blocked) — o passo que também é tarefa leva o identificador ao lado; os seis arquivos; a ADR concluída imutável.

Ajustes do dono antes da publicação (ADR 147 do jhowdev, dobrados nesta mesma versão: a 2.0.0 ainda não tinha saído do jhowdev):

• Docker recomendado para projetos novos, porque já vem instalado nos espaços do Gestor (o Podman precisaria ser instalado); o Podman também funciona. Era “Podman primeiro, Docker como alternativa” (Infraestrutura, stack universal, Ferramentas padrão). O kit dos modelos usa o que houver, o Docker primeiro; o pacote de produção continua Podman.
• Orquestração de agentes reescrito com os dois modos: teammates (um agente por frente conversando com o orquestrador, para o trabalho longo e ajustado no caminho) e workflows (uma execução roteirizada, para um lote de ADRs bem definidas: implementar → revisão adversarial contra as palavras do dono → integrar), e as regras comuns (um worktree, uma porta e um banco de teste por frente; só o orquestrador no banco principal; integração uma por vez com a trava; relatório com verificado e não verificado; a mensagem que chega depois da integração se perde). Glossário: Orquestrador e Teammate revistos, Workflow novo.
• Push só com a autorização do dono e sem pull request (Git e commits): a IA faz o git push quando o dono pede ou autoriza daquela vez (pode oferecer), nunca --force; agente secundário e workflow nunca fazem push. Integrar é o merge local; o pull request saiu do método (antes, “opcional”).

Novo: Tarefa ou ADR, Quem faz o quê, Sem o Gestor e Gestor. O Gestor é recomendado, não obrigatório: o método funciona inteiro nos dois modos.

Para atualizar um projeto 1.x: pnpm manifesto:pull numa ADR; tirar do CLAUDE.md e do .specs/readme.md a “próxima ADR”; com o Gestor, cadastrar o projeto e o repositório e configurar o MCP. Nenhuma ADR que já existe muda: só o trabalho novo segue a 2.0.0.

Para ficar na 1.x: pnpm manifesto:pull --versao 1.2.1 traz a pasta da etiqueta manifesto-v1.2.1 do jhowdev (a opção --versao é nova nesta versão do manifesto:pull; copie o script novo antes). A 1.x fica congelada: não recebe correções.

Cada versão sai de uma ADR do jhowdev. Todo o histórico.

Como usar em outro projeto

Nos outros projetos, a pasta manifesto/ é só de leitura: ela muda só aqui, no jhowdev, dentro de uma ADR, com a versão nova no VERSION e a seção no Histórico. Para trazer a versão em vigor:

pnpm manifesto:pull            # traz a pasta manifesto/ do jhowdev, mostra o diff e não commita
pnpm manifesto:pull --dry-run  # só mostra o que mudaria

Projeto novo já nasce com a versão em vigor: no jhowdev,pnpm boilerplate:build <vazio|manifesto|monorepo> <destino> --nome "…" --slug …. O passo a passo está em Como usar em um projeto.

Por onde começar

1. O que é o Manifesto
2. Princípios
3. Fluxo de ADR — Visão geral
4. Tarefa ou ADR
5. Os seis arquivos

A barra lateral é o índice: os capítulos na ordem do PDF do Manifesto, com o Histórico no fim. Para achar um termo, use a busca (Ctrl K).