vibe64-dev/seed-nextjs

Trabalho em projeto Genesis

Genesis é um companheiro explicativo e de verificação. Ele não substitui a base de código, os testes, a revisão Git ou o agente de codificação.

Estabelecer direção de novo produto

Para um novo projeto cujo Blueprint ainda não estabelece a direção do produto, não pesquise tecnologia nem crie código-fonte até que o usuário tenha deixado claro o que está sendo construído, quem ou o que irá usá-lo ou invocá-lo, e o primeiro resultado útil observável. Pergunte apenas questões não resolvidas de alto impacto. Uma resposta confirma apenas o que ela responde explicitamente; a confirmação da Stack não é intenção do produto.

Assim que a direção do produto estiver clara, escolha o menor caminho de implementação através da orientação tecnológica selecionada, ou documentação técnica autoritativa quando o catálogo não tiver correspondência, e leia apenas o que esse caminho requer. Não pesquise alternativas, clone repositórios tecnológicos inteiros, inspecione partes internas de pacotes não relacionados, nem delegue pesquisa a menos que uma falha concreta exija uma investigação exata.

Executar comandos do Genesis

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 arquivo package.json raiz do repositório. Trate o Genesis como fixado ao projeto apenas quando o name desse manifesto for genesis-compiler, ou suas dependencies, devDependencies ou optionalDependencies contiverem a chave exata genesis-compiler.
2. Para um repositório com Genesis fixado, 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, reporte 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 PATH do shell atual). Quando resolver um executável, invoque genesis <argumentos> diretamente.
4. Quando nenhuma das fontes estiver disponível, pare e reporte 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 de 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 um fallback. 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 tamanho da resposta. Reporte progresso concreto, descobertas ou bloqueios; não anuncie que você está seguindo as orientações.

Resolver escolhas tecnológicas explícitas

Antes de pesquisa ou implementação de tecnologia externa, quando o usuário nomear explicitamente uma tecnologia, framework, linguagem ou banco de dados que não está selecionado:

1. Execute a operação do Genesis stack list como a primeira ação tecnológica.
2. Se um componente do catálogo corresponder exatamente à escolha, pergunte: " está disponível no Genesis. Gostaria que eu a adicione a este projeto e prepare o aplicativo com sua orientação oficial?" Não execute stack add <peça...> sem essa confirmação.
3. Se confirmado, adicione o componente, deixe o Genesis aplicar seu fecho de dependência declarado e sincronizar qualquer Skill de Agente autoritativa declarada por esse componente. Siga o prompt de preparação retornado por stack add na mesma tarefa: torne verdadeiro cada contrato de projeto materializado ou substitua uma seção completa pela realidade evidenciada. Em seguida, execute context ., ou o caminho de origem relevante assim que a origem existir, carregue a skill instalada aplicável, se presente, e siga essa orientação de propriedade da tecnologia para preparar as dependências reais do projeto. Nunca infira um comando de instalação a partir de um id de componente.
4. Se recusado, continue sem adicionar o componente ou perguntar novamente. Se nenhum componente do catálogo corresponder, não invente um; continue normalmente usando documentação autoritativa de propriedade daquela tecnologia.

Estabelecer contexto

1. Leia genesis/blueprint.md para intenção não técnica do produto.
2. Leia genesis/engineering.md para o perfil de engenharia selecionado e quaisquer requisitos específicos do projeto.
3. Leia genesis/stack.md para a composição técnica selecionada, recursos e comandos de verificação.
4. Localize a fonte envolvida na solicitação.
5. Execute a operação do Genesis index <nome-ou-caminho> antes de adicionar um helper ou operação pública. Reutilize uma função existente quando ela já for dona do comportamento.
6. Execute a operação do Genesis context <caminho...> para as explicações do Programa relevante e o contexto da Stack selecionado.
7. Carregue skills tecnológicas aplicáveis de .agents/skills/ ou do catálogo de skills instalado pelo próprio agente.

Para a primeira seleção de Stack de um aplicativo existente, inspecione seus comandos reais de configuração, construção e saída antes de aceitar propostas de componentes materializados. Um componente selecionado descreve sua fundação atual; ele não porta silenciosamente código-fonte mais antigo. Quando os comandos existentes diferirem, mantenha a implementação inalterada e substitua a operação consumidora completa de propriedade do projeto (por exemplo, ## Configuração do workspace ou ## Saídas de um host). O Genesis trata essas seções como texto opaco; apenas o consumidor nomeado possui seu significado e execução. Não afirme que uma receita proposta é utilizável até que corresponda à fonte.

Programa é uma explicação concisa e falível. Suas Fontes e mapas opcionais de Implementação auxiliam na navegação, mas nunca substituem a leitura do código-fonte, testes e comportamento em tempo de execução.

.genesis/machine-city.json é um mapa detalhado derivado de arquivo/função. .genesis/program-city.json é um mapa derivado mais simples de subsistema/operação. Nenhum é autoridade ou prova; ambos estão em .gitignore e podem ser regenerados com a operação index do Genesis.

Implementar trabalho local ordinário

• Aplique a abordagem de engenharia eficaz fornecida pelo Genesis. Cada mudança deve ser fácil de raciocinar e ser a menor implementação direcionada que atenda completamente aos requisitos conhecidos. Não complique demais nem adicione abstrações especulativas, camadas, dependências, infraestrutura, caminhos de compatibilidade, padrões distribuídos, criptografia ou outro maquinário avançado.
• Quando um requisito concreto tornar a complexidade material necessária, pare antes de escrevê-la. Explique por que o design direto é insuficiente e a menor complexidade adicionada proposta, então pergunte ao usuário para aprovar ou esclarecer a compensação. Nunca substitua silenciosamente a abordagem de engenharia.
• Trabalhe diretamente na árvore Git atual e deixe edições úteis visíveis no diff ordinário.
• Mantenha o Blueprint e os módulos de Programa afetados alinhados nesta mesma rodada quando a implementação alterar intencionalmente o comportamento observável do produto. Reestruturação privada pode exigir apenas Fontes corrigidas ou um mapa de Implementação informativo, e pode não exigir nenhuma edição explicativa. Mantenha as declarações de operação de propriedade do consumidor exatas, como ## Saídas de um host, alinhadas quando a implementação alterar intencionalmente os comandos ou capacidades correspondentes. Registre apenas metadados de capacidade e nomes de variáveis de ambiente ali, nunca valores ou segredos; não infira nem execute a seção como comportamento do Genesis. Trate .genesis/ como dados de navegação derivados substituíveis, não intenção de produto autorada.
• Siga as juntas de projeto e tecnologia estabelecidas em vez de criar frameworks paralelos, camadas de persistência, transportes, validadores ou sistemas de UI.
• Nunca invente valores de recursos externos indisponíveis nem passe nomes literais de variáveis de ambiente como dados. Reporte o recurso ausente e preserve trabalho útil.
• Mantenha a implementação direta e coesa. Aplique qualquer orientação fornecida pela Stack Pós-mudança antes de relatar conclusão; ela faz parte desta rodada de implementação, não uma solicitação de outra rodada do agente. Execute verificações focadas quando útil.

Verificar e relatar

Durante a implementação, selecione as verificações relevantes para a mudança. Execute as verificações finais declaradas pela Stack através do Genesis verify quando exigido pela política de verificação do projeto ou pela solicitação do usuário, após o substrato do workspace da tecnologia selecionada existir. Finalizar um item ou retomar uma sessão não exige por si só uma ampla execução de verificação. Mantenha a saída completa em artefatos locais, preserve o status de saída e leia resumos e trechos de falha relevantes antes de expandir logs. Não enfraqueça asserções nem omita cobertura necessária para economizar tempo ou tokens. Um resultado não configurado significa que o workspace declarado ou as verificações ainda não existem; não é uma verificação com falha. Antes de relatar conclusão, compare o comportamento observável solicitado, as entradas e recursos necessários, as operações de projeto declaradas e a evidência focada com o que realmente existe. Relate arquivos alterados, verificações realmente executadas, qualquer coisa não comprovada e qualquer coisa que ainda exija atenção. Nunca afirme que uma verificação não executada passou ou que verificações bem-sucedidas comprovam todo o produto.

Manutenção de subsistemas

Mantenha genesis/subsystems.md na mesma rodada de implementação quando uma mudança adicionar, remover ou alterar uma responsabilidade de subsistema, participação em Programa ou propriedade/uso de dados. Leia o mapa antes de alterar código relacionado. Reutilize subsistemas existentes a menos que uma responsabilidade distinta seja evidenciada. Exija um Diretório Fonte por subsistema e declare cada módulo de Programa exatamente uma vez; nomes de pastas de Programa não determinam participação. Mantenha referências de tabela fundamentadas em esquemas/migrações; o Genesis não inspeciona bancos de dados. Mudanças em helpers privados não precisam de edição no mapa quando essas associações permanecerem inalteradas.

Se genesis/subsystems.md estiver faltando, ou estiver vazio em um aplicativo explicado existente, crie-o a partir do código-fonte real, esquema e Programa existente antes da implementação. Esta é uma adoção explicativa ordinária, não um bloqueador ou razão para pedir permissão novamente. Preserve o Programa e a fonte existentes; inspecione as responsabilidades relevantes e complete o menor mapa verdadeiro. A inicialização pode criar o arquivo vazio, mas apenas o agente é autor de seu significado.