VÁRIOS PROVIDERS · UM CICLO FECHADO

Agentes diferentes.
Um só ciclo.
Engenharia de verdade.

Claude, Codex, Cursor, Cline, Antigravity — cada um no seu card, todos falando entre si pelo board. Um orquestra, outros implementam, outro revisa, e o relatório volta para quem pediu. O ciclo só fecha quando um agente que não escreveu o código julgou.

  • 01Contrato antes do códigoterritório, gate e forma do relatório
  • 02Um agente por territóriosem dois escrevendo no mesmo arquivo
  • 03Quem escreve não aprovao veredito vem de outro provider
  • 04Commit só depois do vereditouma fatia por tarefa, em worktree limpo
roda local · sem conta · sem servidor · GPL-3.0
Cada passagem é um evento registrado — contrato, spawn, relatório, veredito. Nada se perde numa janela fechada.
COMO FUNCIONA · UMA TAREFA DO PEDIDO AO COMMIT

Seis momentos. Um board que você vê inteiro.

Role e o board ao lado avança. Ou clique numa nota para pular até ela. O que aparece aqui é o que o app faz — mesmos estados, mesmas cores.

board · fila-de-retries1 tarefa escrita · nenhum agenteorquestrador escrevendo o contrato2 implementadores rodandodiff crescendo · navegador abertorevisor lendo 62 linhas2 tarefas done · 2 commits
01 · O PEDIDO

Tudo começa na Fila.

Você escreve o que precisa, não para quem. Uma tarefa é uma unidade de entrega: o defeito medido, o território que pode mexer, o gate que prova e a forma do relatório.

A tarefa sobrevive ao card e ao restart do app. Ela pode nascer sem agente nenhum.
02 · O CONTRATO

Um card orquestra os outros.

O orquestrador lê a Fila e escreve o contrato. Ele não implementa: brifa, lê o diff, verifica e integra.

Quem decide sobre o commit é ele — e só ele.
03 · O DESPACHO

Um implementador por território.

Dois agentes, dois provedores, dois arquivos. O conector ciano é o spawn: fato registrado, não desenho. Cada um nasce com allowCommit: false.

Dois cards escrevendo no mesmo arquivo é colisão, não paralelismo.
04 · À VISTA

Nada acontece fora da tela.

Os terminais rodam lado a lado, o diff cresce em Mudanças e o navegador do canvas mostra a tela rodando. Abrir uma URL nova passa pelo seu consentimento.

O agente escreve na sua árvore; você vê o que mudou antes de qualquer commit.
05 · QUEM JULGA

Quem escreveu não aprova o próprio trabalho.

Um terceiro card, de outro provedor, lê o diff e escreve o veredito. Com review: wanted, só ele pode fechar a tarefa — nem o orquestrador.

Um ok: true com gates vazios não é entrega. Peça o comando, a saída, a linha.
06 · O RETORNO

O verde só nasce de outro card.

Os relatórios voltam pelo conector apagado — a resposta ao pedido. O orquestrador verifica num worktree limpo e commita uma fatia por tarefa.

Vereditos são append-only: uma linha por rodada, para sempre.
O QUE MORA NO BOARD

Nem todo card é um agente.
Todo card é visível.

Processos vivos, páginas reais, documentos e recados dividem o mesmo plano. Um agente pode ler e escrever em quase todos — e abrir algo novo passa por você.

terminal
Uma CLI de agente rodando de verdade — claude, cursor, codex, cline ou antigravity. O scrollback fica no card.
fila
Tarefas com papel, estado e dependências. É o que o orquestrador lê e o que o despacho automático segue.
mudanças
O diff da sua árvore, arquivo a arquivo, antes de qualquer commit.
navegador
Uma página real dentro do canvas. O snapshot dela vira evidência no relatório.
mídia
Imagem ou PDF copiados para os assets do board, com zoom e rotação próprios.
nota
Recado com categoria por cor: anotação, concluído, em andamento, bug. Pessoa ou agente escrevem.
arquivos
O explorador do diretório que o trabalho toca, sem sair do board.
desenho
Traço à mão livre para marcar o board sem parar o raciocínio.
CASOS DE USO · DE PONTA A PONTA

Seis trabalhos reais, montados no board.

A SITUAÇÃO
Quatro tarefas que não tocam os mesmos arquivos, e você não quer ser o copia-e-cola entre quatro terminais.
NO BOARDfilaorquestrador · claudeimpl · clineimpl · cursorimpl · codexmudanças
  1. 1Escreva as quatro tarefas na FilaCada uma com contrato: o defeito medido, o território, o gate e a forma do relatório.
  2. 2O orquestrador despachaUm implementador por território, cada um com allowCommit: false. O conector do spawn fica registrado no board.
  3. 3Os terminais rodam lado a ladoVocê acompanha sem trocar de janela; o diff de todos aparece em Mudanças.
  4. 4Os relatórios voltamCom gates e evidência — comando, saída, linha. Progresso não conta como entrega.
  5. 5Uma fatia por tarefaO orquestrador verifica num worktree limpo no HEAD e commita cada tarefa separada.
NO FIMQuatro commits separados, cada um com quem fez e quem conferiu — e um board que mostra o caminho inteiro.
SUA MÁQUINA, SUAS REGRAS

O que fica aqui. E o que a gente não promete.

arquivos · ~/.config/stellar
boards/sprints, cards, tarefas
board-assets/imagens e PDFs colados
agent-canvas.dbo registro de tudo
relatorios/o que cada agente reportou
keychain do SOsuas chaves, cifradas
Nada sai daqui sem você mandar. O único pedido externo é a checagem de versão nova no GitHub — um pedido, não telemetria.
O QUE NÃO PROMETEMOS

Terminal de agente roda com as suas permissões — sem sandbox. Quem é confinado é o gate: ele roda em bubblewrap no Linux e é recusado onde não existe, em vez de fingir que confinou.

Sem conta. Sem servidor.Você instala, abre, e o board vive na sua máquina.
Seus providers, suas contas.Claude, Codex, Cursor, Antigravity, OpenCode, Cline, Command Code ou um shell puro — cada card roda a CLI que você já usa.
Nada atualiza sozinho.O app avisa que há versão nova; quem clica é você.

Monte o seu primeiro board.

Ao abrir, você não cai num canvas vazio: cai nas suas sessões, agrupadas por projeto, prontas para retomar.

Ver releases
só aparecem sistemas com build publicado · macOS Intel não tem build