Treinamento Itô

ito-training é a habilidade canônica do ECC para treinamento em computação Itô. O ECC nunca executa um treinador, agendador ou pipeline de dados próprio; ele nunca reserva, aloca ou gasta. Esta habilidade se conecta a uma reserva concluída do ito-compute.

Limite de produção atual

O treinamento gerenciado não está disponível hoje. A ponte ECC expõe apenas login, logout, auth, find, status e evals explicitamente controlados. Ela não possui o verbo train, e o verbo run do CLI canônico e o backend de mesa training-run permanecem como andaimes. A garantia aplicável localmente é que o ECC rejeita train antes de resolver ou iniciar o cliente canônico portador de credenciais.

Portanto, pare antes da autenticação ou de qualquer invocação de comando. Relate a capacidade ausente e retorne ao agente de origem. Nunca substitua um treinador local, auxiliar SSH, fluxo de trabalho do navegador ou ponto de extremidade de compra.

Direito de acesso exigido

Quando o treinamento for implementado, seu primeiro portão será uma reserva concluída verificada pelo servidor. Memória de acesso, um RFQ, uma cotação, IPs de nó ou acesso SSH não são prova de direito de acesso. O backend deve retornar elegibilidade de treinamento atualizada vinculada à conta autenticada, reserva, topologia de GPU, região, fabricação e prazo. Reservas expiradas, revogadas, incompatíveis, incompletas ou já liberadas falham antes da confirmação.

Contrato futuro de CLI e API

O nome de comando pretendido é train. A entrega futura deve ser equivalente a:

ecc ito train \
  --booking <server-verified-booking-id> \
  --manifest <absolute-reviewed-json-file> \
  --confirmation-ref <opaque-non-authorizing-reference> \
  --idempotency-key <stable-retry-key> \
  --json

O manifesto revisado deve identificar o tamanho e a revisão do modelo, referências de dados com proveniência de descontaminação, alvo de treinamento, receita pós-treinamento, teto de orçamento em USD, política de checkpoint e custo incremental máximo. Nenhuma chave de API bruta, chave SSH, senha de nó, token de portador ou credencial de conjunto de dados deve estar em argumentos, manifestos, logs, resultados do MCP ou chat.

O cliente deve canonizar o caminho do manifesto, rejeitar links simbólicos, abrir um arquivo regular sem seguir links, exigir propriedade apropriada e permissões restritivas, impor um tamanho limitado e gerar hash dos bytes do descritor aberto. Esse resumo deve ser exatamente igual ao resumo vinculado na confirmação antes de qualquer mutação de carga de trabalho. Uma troca de caminho, resumo incompatível, arquivo grande demais ou arquivo inseguro mutável falha.

A API canônica — não o ECC — deve ser responsável pela criação da carga de trabalho e retornar JSON estruturado com ok, live_api_contacted, notice e data ou error. Os dados de treinamento devem incluir IDs estáveis de reserva, execução, manifesto e idempotência, além de um enum de estado. Erros devem incluir um código estável e uma mensagem segura sem segredos.

Portões de confirmação e execução

Antes da criação da carga de trabalho, exija todos os seguintes itens:

1. Elegibilidade de treinamento e direito de acesso atualizados do backend canônico.
2. Um manifesto imutável revisável e resumo determinístico.
3. Uma confirmação separada de uso único vinculada à conta, ação, manifesto e custo, com expiração curta e proteção contra repetição. Argumentos de CLI carregam apenas uma referência de confirmação opaca e não autorizadora; o servidor resolve e consome a capacidade do portador fora de banda.
4. Uma chave de idempotência fornecida pelo chamador, reservada atomicamente com a execução.
5. Validação de fabricação, capacidade, política de dados, armazenamento de checkpoint e custo no lado do servidor, incluindo o teto de orçamento do manifesto.

Autenticação é identidade, não autoridade de carga de trabalho. Um login, chave de API, cotação ou reserva concluída nunca substitui a confirmação de treinamento. Inspeção e geração de plano não devem criar uma carga de trabalho. Cancelamento e limpeza são mutações separadas com seus próprios limites de confirmação e idempotência.

Ciclo de vida e recuperação

A superfície de produção está incompleta até que o mesmo cliente canônico exponha status com escopo de inquilino, logs, métricas, listagem de checkpoint, cancelamento e limpeza. Cada operação necessita de tempos limite de conexão e gerais limitados, erros cientes de revogação e saída estruturada. Após uma falha de transporte ambígua, consulte o status pela chave de idempotência antes de tentar novamente; nunca crie uma segunda execução meramente porque a primeira resposta foi perdida. Uma credencial revogada interrompe a consulta e retorna o controle ao agente de origem sem iniciar o login automaticamente.

Relate os portões de estágio honestamente; nunca substitua um portão de avaliação falho. A limpeza deve ser

…