Nesko

Para que serve#

O Nesko é o modelo do Ploy para projetos: constrói um projeto a partir de uma ideia, ou audita uma pasta que já existe. Um modelo pequeno não segue um método longo a partir de um só pedido, por isso o método vive no motor, em código, e o modelo só preenche ficheiros e código.

Como se usa#

• Projeto novo. Escolhe o Nesko (ou deixa o Automático) e descreve o que queres construir. O projeto fica numa pasta ao lado do projeto predefinido, ~/Projetos Ploy/<nome>, e é um repositório git.
• Auditoria. Escreve auditar e uma pasta, ou só o caminho da pasta. É uma auditoria só de leitura.
• Continuar e parar. continuar retoma uma execução onde ficou, e parar termina-a.
• Conversa. Uma pergunta ou um cumprimento é só conversa: o Nesko responde e não começa nada.

uma calculadora de gorjetas para a linha de comandos
auditar ~/Projetos/o-meu-projeto
continuar
parar

A forma de comando também funciona: /nesko <ideia>, /nesko auditar <pasta>, /nesko continuar e /nesko parar. Os trabalhadores correm em dois modelos próprios que o seletor não lista: o ploy-worker pensa antes de responder e escreve os documentos e o plano, e o ploy-builder não pensa e constrói os passos e faz as correções, porque o raciocínio fazia cada tentativa levar minutos.

Projeto novo: seis fases#

1. Documentos. Uma conversa de trabalho escreve docs/brief.md e docs/constitution.md. O motor confere que cada secção obrigatória existe e não está vazia, e pede outra vez com o nome do que falta.
2. Plano. docs/plan.md, num formato fixo, com critérios e um comando de prova por passo (pedem-se 3 a 6 passos; o motor aceita de 3 a 8). O motor devolve o plano quando um passo não tem prova, quando a prova chega à rede, altera a máquina ou não verifica nada, quando já passa antes de o passo estar feito, ou quando repete a de outro passo.
3. Aprovação. A pergunta aparece na caixa de perguntas da janela, com «Aprovar e construir» e «Cancelar», e podes escrever a alteração que queres (vai para a conversa do planeador). Depois de três rondas sem aprovação, a execução pára. Nada é construído sem o teu sim.
4. Construção. Cada passo numa conversa própria, de contexto limpo. Depois de o trabalhador responder, o motor confere que os ficheiros de código (Python, JavaScript, shell) e JSON não têm erros de sintaxe, corre ele próprio a prova do passo e volta a correr as provas dos passos anteriores: uma alteração que estraga trabalho já provado conta como falha. Se falha, o resultado volta à mesma conversa; à segunda falha, começa uma conversa limpa. Três falhas bloqueiam o passo e a execução segue; se as tentativas estragaram um passo anterior, o projeto volta ao último commit. Cada passo que passa é um commit.
5. Revisão. Uma chamada ao modelo, sem ferramentas e sem histórico, lê o código contra o brief e o plano e lista defeitos num formato fixo. Cada achado é confirmado nos ficheiros: o ficheiro existe dentro do projeto, a linha existe, o código citado está perto dela. Só os achados confirmados de gravidade alta ou média são corrigidos, por uma conversa limpa, e a correção só fica se os ficheiros ainda não tiverem erros de sintaxe e todas as provas anteriores ainda passarem. Senão, é desfeita.
6. Relatório. Um SESSION_STATE.md no projeto, um commit, e um resumo na conversa: o que existe, como foi provado, o que ficou bloqueado e o que só tu podes fazer.

Uma prova que falha por erro da shell, e não do programa, é reescrita uma vez, e só vale se passar as mesmas verificações e passar agora.

Auditoria#

O motor mede a pasta com um script (tamanho, linguagens, estado do git, testes, README e licença, marcas TODO, ficheiros com mais de 400 linhas, sítios que parecem segredos, nunca os valores). Depois pede ao modelo uma leitura curta e os defeitos, bloco a bloco, confirma cada defeito no código e escreve ~/Projetos Ploy/Auditorias/<nome>-<data>.md. A pasta auditada nunca é escrita: um teste compara o seu estado antes e depois.

O relatório separa o medido por script, a leitura do modelo (marcada como não verificada) e os achados confirmados no código. Se o modelo não responder, diz que não há achados e que isso nada diz sobre o código.

O cartão do projeto#

Uma execução aparece num cartão por cima da caixa de escrita. Mostra o nome do projeto, a fase em curso, quantos passos estão prontos e uma barra com um segmento por passo. Cada passo traz o título, o commit, o comando de prova e, se bloqueou, porquê. Mostra ainda a revisão, o que só tu podes fazer e a pasta do projeto. Passados 12 minutos sem novidades, o cartão marca-a como interrompida e diz como a retomar.

O que o motor não faz#

• Não corre uma prova que não seja uma só linha, que chegue à rede, use caminhos absolutos, substituição de comandos ou tarefas em segundo plano, ou altere a máquina (rm, sudo, git push, instalações). Cada prova passa também pelo sistema de permissões, como uma ação de shell, e corre numa proteção do macOS sem rede e sem escrever fora do projeto.
• Não entrega à prova os segredos da execução: as variáveis com ar de chave, token ou palavra-passe são retiradas do ambiente.
• Não trata o que o modelo diz sobre o seu trabalho como prova.

Quanto demora#

Não há um tempo medido. Cada passo é uma conversa de trabalho com limite de cinco minutos por turno e até três tentativas, e um projeto tem entre 3 e 8 passos.

O que sai da máquina#

Nada. Os agentes, as provas e o git correm no teu Mac, e as provas sem rede.

Limites#

Um modelo de 8 mil milhões de parâmetros escreve código partido com frequência. O método não o torna bom: torna a falha visível e limitada. Um passo que não passa fica bloqueado, com a última saída, em vez de ser dado como feito.

Num teste de ponta a ponta com o modelo real, o Nesko construiu um projeto com plano, aprovação, passos e relatório. A taxa de passos concluídos num modelo destes varia de projeto para projeto. O ploy run cancela as perguntas, e com elas o plano: constrói projetos na janela.