vibe64-dev/seed-nextjs

Genesis Deslop

Revise e simplifique as alterações selecionadas sem modificar o comportamento do produto. Deslop é explícito: nunca execute apenas porque a implementação terminou.

Resolva a invocação antes de executar a primeira operação do Genesis. Não use uma operação do Genesis ou genesis --version como sonda de disponibilidade.

1. Leia o package.json na raiz do repositório. Trate o Genesis como fixado ao projeto apenas quando o name desse manifesto for genesis-compiler, ou seus dependencies, devDependencies ou optionalDependencies contiverem exatamente a chave genesis-compiler.
2. Para um repositório fixado ao projeto, invoque toda operação CLI do Genesis com npm exec --no -- genesis <argumentos>. Isso executa sem buscar outro pacote. Se o pacote declarado não estiver instalado, informe que as dependências do projeto não estão preparadas; não recorra a outra versão do Genesis.
3. Caso contrário, não tente npm exec. Execute command -v genesis (ou o equivalente de PATH do shell atual). Quando resolver um executável, invoque genesis <argumentos> diretamente.
4. Quando nenhuma das fontes estiver disponível, pare e informe que o Genesis está indisponível. Nunca instale ou atualize o Genesis apenas para satisfazer uma instrução de fluxo de trabalho.

A resolução bem-sucedida da invocação é rotineira. Não narre se o Genesis está fixado ao projeto ou no PATH, e nunca descreva o uso direto do PATH como alternativa. Mencione como a invocação foi selecionada apenas quando a resolução falhar ou o usuário perguntar explicitamente.

Siga a abordagem de Colaboração configurada para atualizações voltadas ao usuário, incluindo sua profundidade técnica e extensão da resposta. Relate progresso concreto, descobertas ou bloqueios; não anuncie que você está seguindo orientações.

Carregar as instruções efetivas do projeto uma vez

Uma solicitação Deslop pode chegar como um prompt completo gerado pelo Genesis ou como uma solicitação direta, como Deslop em uma sessão de agente.

Se a tarefa atual já contiver GENESIS CONTEXT cuja tarefa é deslop, prossiga diretamente com ela. Não gere outro prompt.

Caso contrário, antes de resolver o escopo do Git, execute a operação prompt --task deslop do Genesis uma vez, usando a regra de invocação acima. Para uma solicitação simples de Deslop, não passe nenhum argumento de solicitação. Quando o usuário nomear uma contagem, um commit ou um intervalo, passe exatamente essa solicitação como um argumento citado com segurança. Trate o prompt impresso como as instruções para este mesmo turno; não o envie para outro agente e não o gere novamente. Esta etapa compõe as orientações específicas de Deslop do Stack selecionado e qualquer personalização do projeto com o contrato portátil abaixo.

Resolver o escopo da limpeza

Inspecione git status --short e os diffs staged e unstaged antes de editar. Uma árvore de trabalho suja é permitida; um commit anterior não é obrigatório. Preserve o índice existente e o trabalho não relacionado. Não faça stage, stash, commit ou descarte alterações como pré-requisito ou parte da limpeza.

Resolva o escopo do usuário da seguinte forma:

• Sem escopo declarado, selecione apenas suas próprias alterações para a tarefa atual, incluindo turnos anteriores. Isso pode incluir edições staged e unstaged, novos arquivos não rastreados e alterações de tarefas já commitadas. Identifique o ownership a partir do histórico da tarefa e das edições, então confirme essas alterações em relação ao código-fonte atual e aos diffs do Git. Nem todo o diff sujo, o commit mais recente ou uma identidade de autor do Git prova o ownership.
• Preserve as alterações feitas pelo usuário ou por outros agentes, incluindo edições nos mesmos arquivos. Se o ownership não puder ser estabelecido, pergunte quais alterações devem ser deslopadas. Se não houver alterações suas para esta tarefa, informe que não há nada para deslopar; não selecione silenciosamente o commit mais recente ou o trabalho de outra pessoa.
• Um commit explícito, contagem de primeiro pai ou intervalo tem precedência sobre o padrão, independentemente de quem tenha criado essas alterações.
• "O último commit" significa HEAD em relação ao seu primeiro pai.
• "Os últimos N commits" significa a alteração líquida sobrevivente do primeiro pai antes desses N commits até HEAD.
• Um commit nomeado significa esse commit em relação ao seu primeiro pai.
• Um intervalo de commits explícito significa exatamente esse intervalo.
• Um commit raiz usa a forma de diff raiz do Git porque não tem pai.

Inspecione as alterações e caminhos resolvidos, além das identidades dos commits quando aplicável. Revise seu diff, código-fonte atual, locais de chamada diretos, testes relevantes e o contexto do Programa e do Stack afetado. Para um escopo commitado explícito, não substitua o diff comum da árvore de trabalho pelo diff commitado selecionado. Aplique a limpeza ao código-fonte atual preservando edições fora do escopo. Se edições sobrepostas não puderem ser separadas com segurança, pergunte sobre essa sobreposição em vez de bloquear apenas porque o repositório está sujo.

Aplicar o contrato de limpeza

Aplique a abordagem de engenharia fornecida com a tarefa. Se esta skill for invocada diretamente, leia genesis/engineering.md bem como o contexto relevante do projeto. A limpeza deve reduzir ou preservar a complexidade, nunca introduzir mecanismos não aprovados que o perfil selecionado ou um requisito concreto não precise.

Consulte .genesis/machine-city.json ou execute a operação index <nome-ou-caminho> do Genesis para encontrar funções públicas e internas existentes antes de introduzir ou consolidar uma abstração. Confirme toda duplicata aparente no código-fonte e em seus locais de chamada.

Dentro do comportamento pretendido e do escopo das alterações selecionadas, não deixe helpers repetidos, código que não seja claro ou difícil de raciocinar, e código que vá contra padrões estabelecidos na base de código. Remova wrappers desnecessários, andaimes abandonados, encanamentos paralelos de framework e abstrações especulativas. Consolide o ownership onde um módulo claro é suficiente. Não otimize para arquivos minúsculos ou indireção; otimize para um design pequeno e óbvio que um programador júnior possa acompanhar.

Limpeza não é uma segunda passada de implementação. As alterações selecionadas limitam onde a limpeza pode ocorrer; compartilhar um arquivo não traz edições não relacionadas para o escopo ou autoriza comportamento diferente naquele arquivo. Deslop pode reorganizar o comportamento já presente; não pode completar, corrigir ou estender o comportamento. Se a revisão revelar um defeito, comportamento ausente, incompatibilidade de contrato ou lacuna de teste, relate-o como uma descoberta de acompanhamento e deixe-o inalterado, mesmo que esteja dentro de um caminho alterado ou pareça relacionado à implementação anterior. Não implemente a descoberta nem altere os testes para acomodá-la durante o Deslop.

Aplique toda instrução específica de Deslop fornecida pelo Stack selecionado e carregue skills técnicas oficiais aplicáveis para contexto de framework e linguagem. As orientações do Stack enriquecem este contrato; não podem enfraquecer o limite que preserva o comportamento, alterar o escopo selecionado ou autorizar implementação não relacionada.

Você pode editar ou excluir arquivos de implementação e teste quando essa for a limpeza mais clara que preserva o comportamento. Se mover ou renomear o código-fonte selecionado tornar uma citação de Programa afetado desatualizada, atualize apenas essa citação ou mapa de Implementação informacional. Não altere o Blueprint ou um contrato público de Programa para justificar o comportamento de limpeza. Não edite .genesis/, metadados do Git, diretórios de dependência, saída de build gerada, histórico de migração retido ou recursos externos. Não enfraqueça testes, comportamento público ou garantias de dados. Não crie uma segunda arquitetura nem execute reescritas não relacionadas.

Deixe a limpeza como trabalho comum não commitado para revisão e um commit normal posterior. Nunca altere ou reescreva os commits selecionados. Execute verificações focadas quando útil. As verificações finais declaradas permanecem disponíveis através da operação verify do Genesis. Resuma o escopo resolvido e quaisquer identidades de commits selecionados, o que se tornou mais simples, arquivos alterados, verificações realmente executadas e descobertas de acompanhamento que ficaram inalteradas.