ALPHA · EM PREPARAÇÃO

Developer Companion e Intent Runtime

Esta é uma referência de arquitetura do Alpha, não um fluxo de instalação. Ela separa a fundação publicada do Companion que ainda será conectado ponta a ponta.

Alpha em preparação

O Developer Companion ainda não é um produto executável de ponta a ponta. Nenhum Mission Graph é despachado automaticamente para um Mac, não há adapter de Codex ou Claude, e o Evidence Gate ainda não produz Evidence selada. Os blocos abaixo distinguem o que pode ser inspecionado hoje do que continua planejado.

Disponível hoje no Alpha

Dois conjuntos de primitivas existem separadamente: as sete tools kelvin_intents_* do Kelvin Cloud emitem o plano e registram o estado da sessão; kelvin_companion_challenge, kelvin_companion_prepare e kelvin_companion_attest, no MCP local, aprovam um diretório concedido e produzem seu registro de integridade. Ainda não existe a ponte que despache automaticamente o primeiro conjunto para o segundo.

O contrato publicado

kelvin_intents_plan emite uma proposta inerte de Mission Graph, vinculada ao projeto, principal, cliente OAuth, policy, digest e expiração. O template do Alpha cobre feature e fix e declara intake, preflight, reprodução (apenas para fix), trabalho do agente, revisão, teste e Evidence Gate. Dependências, orçamentos, timeouts, retries e critérios ficam no contrato; isso não significa que todos esses limites ou nós já tenham executor.

Kelvin Cloud · Mission Graph

recebe: O projeto escolhido, um resumo que o usuário envia explicitamente, limitado a 2.000 caracteres, e digests. Por padrão, o Kelvin Cloud não recebe o código-fonte nem o caminho do workspace.
devolve: Plano emitido, estados e uma tentativa com lease e fencing token. Leases vencidos são recuperados pelo reconciler; o fencing token ordena gerações e recusa mensagens antigas. Isso não reserva um Mac, worktree ou Simulator e não prova o resultado.

Mac · Developer Companion

recebe: Um diretório de trabalho local, uma lista fechada de operações e os identificadores do claim remoto. O challenge exige aprovação humana e prende principal, cliente, action token, attempt e fencing; o despacho automático Cloud → Mac ainda está pendente.
devolve: Digests da árvore antes e depois e um LocalWorkReceipt v2 assinado como registro de integridade local. O Kelvin Cloud consegue verificar o binding quando a identidade é de um Node enrolado; esse receipt só satisfaz um Evidence Gate em deliveryMode=demonstration, não cria veredito e não é Evidence selada.

O que as primitivas do Alpha fazem

Planejar: “corrija este bug” vira uma emissão curta e inerte de nós e critérios. Ela guarda apenas bindings e digests, não cria sessão, job, Room ou grant, e start recusa um plano fabricado ou alterado pelo cliente.
Registrar: start cria a sessão durável; inspect lê o estado; cancel encerra a sessão. Nenhuma dessas operações abre um shell ou escolhe um binário no Mac.
Reivindicar: next entrega no máximo um nó pronto, com lease curto, action token e fencing token monotônico. O fencing token identifica a geração atual da tentativa; ele evita que trabalho antigo vença trabalho novo, mas não concede acesso à máquina.
Reportar: report registra uma MissionActionReceipt idempotente e deve corresponder à tentativa, ao action token, ao fencing token, ao principal e ao cliente atuais. O outcome autodeclarado nunca basta. Um Evidence Gate nunca chega a completed em deliveryMode=verified sem um EvidenceJob selado do projeto; um LocalWorkReceipt válido só satisfaz o gate em demonstration e mantém o veredito sem avaliação.
Registrar integridade local: challenge/prepare/attest exigem aprovação humana, resolvem o diretório canônico, calculam digests antes e depois e assinam o binding remoto. O LocalWorkReceipt resultante ainda não transforma esse registro em Evidence selada.

Em preparação para a execução ponta a ponta

Ainda faltam o despacho automático e autenticado para um Mac real, worktrees e build lanes isoladas, alocação de Simulator, adapters reais de Codex e Claude, o E2E do binding local com um Node enrolado, o child EvidenceJob selado, recovery completo após restart, scheduler de frota, UI no dashboard e Protocol Mirror. Só depois desses gates o Companion poderá dizer que executou e provou uma missão ponta a ponta.

Artifact MCP: em preparação

Artifact MCP ainda não está disponível para conexão. Quando for publicado, será a superfície de leitura de Evidence selada e de criação de flows derivados autorizados — separada do Live MCP e sem conceder input, job, Room ou acesso ao Mac.

Privacidade e superfícies

Por padrão, o Kelvin Cloud não recebe o código-fonte: recebe o projeto, um resumo que o usuário envia explicitamente, limitado a 2.000 caracteres, e digests. Esse resumo é conteúdo classificado como cloud_user_submitted e seu envio exige uma escolha explícita. Isso descreve a fronteira do Kelvin Cloud; não promete que o provedor do agente seja local.

Codex, Claude ou outro cliente MCP pode enviar código-fonte ao provedor de modelo escolhido, conforme o contrato e a configuração desse provedor. O Kelvin não faz proxy desse tráfego nem o copia para o Kelvin Cloud, mas também não o bloqueia. A tela que mostrará provedor e fronteira de dados antes da autorização ainda está em preparação.

O Companion é aditivo. Evidence selada, Live MCP, Rooms e Dojo mantêm contratos e autoridades separados e não dependem de o Companion estar ativo.