core/, o núcleo ork

Núcleo CLI determinístico do Orkastery (Camada 2, o Looping Threads Maestro). Sem LLM embutido: o ork monta prompt, despacha pelo runtime adapter, verifica no mundo real e registra no ledger. Quem escreve código e a orquestra (Camada 3); quem decide e o humano.

Instalar

Publicado no npm como @orkastery/cli. O nome curto ork no registry pertence a outro projeto, mas o binario instalado continua sendo ork:

npm install -g @orkastery/cli
ork doctor

O tarball leva junto o catalogo do produto (skills/, references/, eval/ e adapters/), entao ork eval e ork adapter install funcionam a partir da instalacao global.

Compilar deste repositorio

cd core
npm install
npm run build        # gera dist/index.js (bin `ork`)
npm test             # compila e roda a suite (node --test)
npm link             # opcional: poe o `ork` desta arvore no PATH

O prepack roda o build e copia o catalogo da raiz do repositorio para dentro de core/; o postpack remove as copias. E por isso que npm pack e npm publish levam o produto inteiro sem que essas pastas existam na arvore versionada de core/.

Comandos

node dist/index.js doctor                 # o que vale nesta maquina agora
node dist/index.js init                   # gera o orkastery.yaml do repo
node dist/index.js modos                  # tabela dos 5 modos de conducao
node dist/index.js thread new "<nome>" --modo default
node dist/index.js thread list
node dist/index.js thread status <thread-id>
node dist/index.js phase run <thread-id> GOAL --prompt "<pedido>"
node dist/index.js phase list <thread-id>
node dist/index.js sessions [--all]
node dist/index.js sessions logs|stop|attach <sessao>

Bloco B1 (verdade, gate de tokens, handoff e entrega):

node dist/index.js claims add <thread-id> <arquivo> --claim "<alegacao>" --verificar "<comando>"
node dist/index.js claims list|verificar|retirar <thread-id> [...]
node dist/index.js verify <thread-id> [--baseline] [--so-claims]
node dist/index.js gate next <thread-id> [--proximo FASE] [--ocupacao 0..1] [--transcript ARQ]
node dist/index.js gate approve <thread-id> push --por <quem>
node dist/index.js handoff export <thread-id> [--proxima-fase FASE]
node dist/index.js handoff recall <thread-id> "<path#ancora>"
node dist/index.js ship <thread-id> --para main [--autorizar-push <quem>] [--dry-run]
node dist/index.js lease list|release <nome>

Mapa dos módulos

| Arquivo | Papel | |---|---| | src/index.ts | CLI: parse de argumentos e roteamento dos subcomandos | | src/doctor.ts | Checks de ambiente, manifesto, abbrev, custo/provider e sessões | | src/init.ts | Detecção do repo e geração do orkastery.yaml | | src/thread.ts | Estado da thread em disco, slug, base carimbada, listagem | | src/phase.ts | Montagem do prompt da fase, despacho e leitura do ledger | | src/modos.ts | Matriz dos 5 modos de condução e parse da #TAG | | src/slug.ts | Slug de 3 partes, regex canonica e rotação de sessão | | src/ledger.ts | Ledger JSONL append-only por thread | | src/manifest.ts | Leitura e validação do manifesto (com fallback devmaster.yaml) | | src/yaml.ts | Leitor do subconjunto de YAML usado pelo manifesto (sem dependência) | | src/adapters/claude-bg.ts | Runtime adapter: claude --bg, claude agents, logs e stop | | src/sessoes.ts | Observabilidade: cruza o runtime real com o registrado nas threads | | src/claims.ts | Alegações verificaveis por thread (claims.jsonl) e a regra da alegação negativa | | src/verify.ts | Reexecucao no HEAD real, baseline e classificação regressão vs pré-existente | | src/gates.ts | Catálogo de motivos tipados de gate e registro de aprovação humana | | src/policies.ts | Policies do manifesto executaveis, por gate e por severidade | | src/leases.ts | Leases com aquisição atômica e TTL (o main-tree serializa o ship) | | src/ship.ts | Merge --no-ff serializado, verificado, e push provado por ls-remote | | src/tokens.ts | Gate de tokens: medida honesta da janela e veredito de rotação | | src/handoff.ts | Handoff triado em 3 níveis com proveniência, e o recall dos ponteiros |