Condução
- Thread e 6 fases
- Modos #Classic · #Maestro · #Auto · #Fast
- Despacho com prompt + sha256
- Setup por bloco
- Onboarding
- Portfólio prod → proj → init
DOCS / ARQUITETURA
A fábrica que entrega e presta contas.
Em uma página: as camadas, os blocos funcionais, os serviços e os contratos do Orkastery. E a regra que atravessa tudo: nenhuma afirmação de agente vale antes de ser provada, e o seu tempo só é usado para o que só você pode decidir.
- Nada vale por relatoToda afirmação do agente vira claim com comando e é reexecutada no commit real, e de novo num runner limpo.
- Você só é chamado quando importaUm resumo por hora, perguntas em lotes de cinco com uma recomendada, e o óbvio chega decidido.
- A fábrica não paraConta esgotada, login perdido ou rate limit: o mesmo prompt segue em outro perfil, outro runtime ou na fila.
- A documentação não menteProduto e roadmap vivem no repositório e reprovam o PR quando divergem do código ou do git.
01 · MAPA DA PLATAFORMA
Cinco camadas, uma regra: a decisão de negócio mora só no núcleo.
De cima para baixo, o pedido desce como intenção e vira prompt com sha256. De baixo para cima, a evidência sobe como commit e saída de comando e só passa depois de verificada. As faixas da direita valem para todas as camadas.
Pessoas e canaisPLAT-01
- Você, o Product Builderdecide o quê e o porquê; nunca o como de rotina
- Telegramvia Hermes ou OpenClaw, com ingresso autenticado
- Claude Code/orkastery:ork, MCP local
- Codex$ork, MCP local
Hosts e adaptadores · zero regra de negócioSYS-02 ↗
- Plugin Claude Codeskills, subagentes de fase, hooks
- Skills Codexcatálogo de condução no projeto
- Plugin Hermesroteador fino e ingresso HITL
- Extensão OpenClawtools ork_*, uma por comando
- Servidor MCPork mcp serve, stdio
Núcleo ork · determinístico, nenhum LLM dentroSYS-01 ↗
Verdade e entrega
- Claims com comando
- Verify no HEAD real
- CI como CHECK independente
- Ship com push provado
- Worktrees e leases
- Auditoria e dívida
Runtimes e contas
- Registro de runtimes
- Rodízio de contas
- Fallback por bloco
- Retry tipado
- Fila de rate limit
- Sensores de sessão
Atenção humana
- Resumo por hora
- Lote a–d com recomendada
- Decisão tomada e informada
- Horário do dono
- Monitor, board e pulse
- MASTER com índice
Memória e registro
- Handoff triado
- Recall no momento certo
- Memória OrkMind
- Telemetria do ledger
- Documentação como código
- Company Brain no CLI
Execução · quem escreve o códigoMOD-03 ↗
- claude-bgClaude Code em segundo plano; a sessão aparece em claude agents
- codexcodex exec headless na sessão autenticada
- Perfis de contaum diretório por conta; o login é do próprio CLI
Fundações e estado
- gitworktree e branch por thread; merge serializado
- Ledgerappend-only por thread; decisão e correção são eventos novos
- Contratos ork.*/vNJSON versionado; leitor antigo aceita para sempre
- GitHub Actionso CHECK independente no SHA exato
- OrkMindopcional: memória do tenant em Postgres com pgvector
02 · UMA ENTREGA DE PONTA A PONTA
Do pedido ao roadmap atualizado, sem um passo que dependa de acreditar no agente.
- 01 Pedido Você escreve o resultado e a #TAG, no canal que preferir.
ork modos --do-pedido - 02 GOAL · PLAN Objetivo, critério de pronto executável e tarefas com verify. Decisão óbvia é registrada, não perguntada.
ork decisao registrar - 03 GO O runtime certo trabalha na worktree da thread; conta esgotada troca de perfil sem parar.
ork phase run - 04 CHECK As claims são reexecutadas no HEAD real e, de novo, no runner do GitHub, no SHA exato.
ork verify · ork ci run - 05 SHIP Merge serializado por lease; só vale com o SHA que o remoto devolve.
ork ship - 06 MASTER POSTMORTEM tipado e índice derivado do ledger; ninguém digita nota para a fila andar.
ork master - 07 Docs O roadmap recebe o commit do merge e a fase da thread, direto do ledger e do git.
ork docs sincronizar
O CHECK acontece duas vezes, de propósito: na máquina da fábrica e num runner que não herda nada de quem construiu. Onde as duas discordam, vale o runner.
03 · ONDE VOCÊ ENTRA
Atenção em camadas. O óbvio chega decidido; o resto, em lote.
- 0SilêncioO que o agente resolve com segurança, ele resolve. Fica no ledger, com o porquê.
- 1Resumo por horaUma mensagem só: pendentes, urgentes, bloqueando uma thread, críticas. E a pergunta: posso mandar agora?
- 2LoteCom o seu sim, até cinco perguntas objetivas, cada uma com a–d e uma recomendada.
- 3AbertasAté duas, uma de cada vez, sempre depois das objetivas.
Regras que não afrouxam
- Decisão óbvia vem tomada e informada no próximo resumo, com como mudar e o custo de mudar agora ou depois.
- Prazo vencido espera ou escala, nunca aprova. Ato irreversível nunca avança por default.
- O agente nunca responde por você. A resposta só vale com prova HMAC nascida do update autenticado do canal.
- Horário no seu fuso, em formato brasileiro, dito uma vez por mensagem.
04 · POR QUE A FÁBRICA NÃO PARA
Uma escada de saídas antes de chegar em você.
- Mesmo perfilrate limit curto: espera a janela na fila durável, com o horário lido do stderr
- Outro perfilcota ou crédito esgotado: o mesmo prompt, mesmo sha256, na próxima conta com login
- Outro runtimesem perfil livre: o fallback do bloco (por exemplo Claude → Codex)
- Filasem nenhuma saída agora: a fase espera o menor prazo de volta
- Vocêsó quando a política manda: custo, irreversível ou limite de tentativas
O ork nunca lê, copia ou migra credencial: cada perfil aponta o diretório onde o próprio CLI guarda o login. Chave de API paga no ambiente da fábrica é cost.violation, sem retry. FEAT-008 ↗
05 · SERVIÇOS E PROCESSOS
Onde cada peça roda.
Máquina da fábrica
- CLI ork global, compilado da main
- sessões claude --bg e codex exec, uma por fase
- estado das threads em .orkastery/ na árvore principal
- cron do pulse (resumo em camadas)
- gateways Hermes e OpenClaw (serviços do usuário)
GitHub
- repositório e PRs
- workflow CI: ork-verify, núcleo em Node 20 e 22, documentação
- o check no SHA exato é o portão do merge
OrkMind (opcional)
- Postgres com pgvector, uma base por tenant
- decisões, handoffs, lições e roadmap com proveniência
- sem ele, a memória degrada para arquivos, com aviso
Canal do dono
- Telegram via bot do Hermes ou do OpenClaw
- allowlist de remetente e chat
- resposta vale só com prova HMAC do update
06 · CONTRATOS E ESTADO
Os dados que cruzam fronteiras têm contrato versionado.
| Contrato | O que carrega | Bloco |
|---|---|---|
ork.hitl/v2 | pedido humano com itens decididos e perguntas | HITL |
ork.hitl-lote/v1 | o lote de até cinco perguntas servido ao dono | HITL |
ork.pulse-consent/v1 | o "posso mandar agora?" e o código da resposta | HITL |
ork.decisao-autonoma/v1 | o rastro da decisão tomada pelo agente | Condução |
ork.ci-bundle/v1 | as claims exportadas para o runner | Verdade |
ork.runtime-profiles/v1 | perfis de conta, sem segredo | Runtimes |
ork.ledger-stats/v1 | tempo, tokens, custo e espera por período | Registro |
ork.pulse/v1 | a fila unificada de atenção | Atenção |
Escritores param, leitores aceitam para sempre. Quando um mecanismo sai do produto, o que já foi gravado com ele continua legível. Ledger, contratos e hashes ficam em UTC ISO; só a superfície humana muda de fuso.
07 · O QUE SÓ O ORKASTERY FAZ
Cada dor tem um mecanismo, e cada mecanismo tem uma prova.
| A dor | O mecanismo | A prova |
|---|---|---|
| O agente diz que terminou | claim com comando, reexecutada no HEAD real e no CI | o check verde no SHA exato |
| O dono vira o monitor | resumo em camadas e lote com recomendação | ork decisao placar |
| A conta acaba e o roadmap para | rodízio de perfis e fallback de runtime | evento runtime_profile_rotated |
| Duas sessões pisam no mesmo arquivo | worktree por thread e lease com fila | fila FIFO visível em ork board plan |
| A doc diz uma coisa e o código outra | páginas com fontes, símbolos e commits conferíveis | ork docs verificar no CI |
DUAS MÉTRICAS JULGAM QUALQUER MECANISMO
Entregas por semana sobem. Interrupções por semana caem para uma ou duas. O que não move nenhuma das duas na direção certa sai do produto, com um canário provando que a falha que ele evitava continua evitada.