vibe64-dev/seed-nextjs

Travail sur un projet Genesis

Genesis est un compagnon d'explication et de vérification. Il ne remplace pas le codebase, les tests, la revue Git, ou l'agent de codage.

Établir la direction d'un nouveau produit

Pour un nouveau projet dont le Blueprint n'établit pas encore la direction du produit, ne faites pas de recherche technologique et ne créez pas de source tant que l'utilisateur n'a pas clairement précisé ce qui est construit, qui ou quoi l'utilisera ou l'invoquera, et le premier résultat utile observable. Posez uniquement les questions à fort impact non résolues. Une réponse confirme uniquement ce qu'elle répond explicitement ; la confirmation de la Stack n'est pas une intention produit.

Une fois la direction produit claire, choisissez le plus petit chemin d'implémentation à travers les directives technologiques sélectionnées, ou la documentation technologique faisant autorité lorsque le catalogue n'a pas de correspondance, et lisez uniquement ce que ce chemin nécessite. Ne enquêtez pas sur les alternatives, ne clonez pas des dépôts technologiques entiers, n'inspectez pas les détails internes de paquets non liés, et ne déléguez pas de recherche sauf si un échec concret nécessite une investigation exacte.

Exécuter les commandes Genesis

Résolvez l'invocation avant d'exécuter la première opération Genesis. N'utilisez pas une opération Genesis ou genesis --version comme sonde de disponibilité.

1. Lisez le package.json à la racine du dépôt. Considérez Genesis comme lié au projet uniquement lorsque le name de ce manifeste est genesis-compiler, ou que ses dependencies, devDependencies, ou optionalDependencies contiennent la clé exacte genesis-compiler.
2. Pour un dépôt lié au projet, invoquez chaque opération CLI de Genesis avec npm exec --no -- genesis <arguments>. Cela s'exécute sans récupérer un autre paquet. Si le paquet déclaré n'est pas installé, signalez que les dépendances du projet ne sont pas préparées ; ne revenez pas à une autre version de Genesis.
3. Sinon, n'essayez pas npm exec. Exécutez command -v genesis (ou l'équivalent de PATH pour le shell actuel). Lorsqu'il résout un exécutable, invoquez genesis <arguments> directement.
4. Lorsqu'aucune des deux sources n'est disponible, arrêtez-vous et signalez que Genesis est indisponible. N'installez jamais et ne mettez jamais à jour Genesis simplement pour satisfaire une instruction de workflow.

La résolution réussie de l'invocation est une routine. Ne décrivez pas si Genesis est lié au projet ou sur le PATH, et ne décrivez jamais l'utilisation directe du PATH comme un repli. Mentionnez comment l'invocation a été sélectionnée uniquement lorsque la résolution échoue ou que l'utilisateur le demande explicitement.

Suivez l'approche de collaboration configurée pour les mises à jour destinées à l'utilisateur, y compris sa profondeur technique et la longueur de la réponse. Signalez les progrès concrets, les découvertes ou les blocages ; n'annoncez pas que vous suivez des directives.

Résoudre les choix technologiques explicites

Avant la recherche technologique externe ou l'implémentation, lorsque l'utilisateur nomme explicitement une technologie, un framework, un langage ou une base de données qui n'est pas sélectionné :

1. Exécutez l'opération Genesis stack list comme première action technologique.
2. Si un composant du catalogue correspond exactement au choix, demandez : " est disponible dans Genesis. Souhaitez-vous que je l'ajoute à ce projet et que je prépare l'application avec ses directives officielles ?" N'exécutez pas stack add <piece...> sans cette confirmation.
3. Si confirmé, ajoutez le composant, laissez Genesis appliquer sa fermeture de dépendance déclarée et synchroniser toute compétence d'agent faisant autorité déclarée par ce composant. Suivez l'invite de préparation retournée par stack add dans la même tâche : rendez chaque contrat de projet matérialisé vrai ou remplacez une section complète par une réalité étayée. Exécutez ensuite context ., ou le chemin source pertinent une fois que la source existe, chargez la compétence installée applicable si présente, et suivez les directives appartenant à cette technologie pour préparer les dépendances réelles du projet. Ne déduisez jamais une commande d'installation à partir d'un identifiant de composant.
4. Si refusé, continuez sans ajouter le composant ni redemander. Si aucun composant du catalogue ne correspond, n'en inventez pas ; continuez normalement en utilisant la documentation faisant autorité appartenant à cette technologie.

Établir le contexte

1. Lisez genesis/blueprint.md pour l'intention produit non technique.
2. Lisez genesis/engineering.md pour le profil d'ingénierie sélectionné et toute exigence spécifique au projet.
3. Lisez genesis/stack.md pour la composition technique sélectionnée, les ressources, et les commandes de vérification.
4. Localisez la source impliquée dans la demande.
5. Exécutez l'opération Genesis index <nom-ou-chemin> avant d'ajouter une opération auxiliaire ou publique. Réutilisez une fonction existante lorsqu'elle possède déjà le comportement.
6. Exécutez l'opération Genesis context <chemin...> pour les explications du Programme pertinent et le contexte de la Stack sélectionnée.
7. Chargez les compétences technologiques applicables depuis .agents/skills/ ou depuis le catalogue de compétences installées de l'agent.

Pour la première sélection de Stack d'une application existante, inspectez sa configuration réelle, ses commandes de construction et de sortie avant d'accepter les propositions de composants matérialisés. Un composant sélectionné décrit sa fondation actuelle ; il ne porte pas silencieusement la source plus ancienne. Lorsque les commandes existantes diffèrent, gardez l'implémentation inchangée et remplacez l'opération consommateur complète appartenant au projet (par exemple, le ## Configuration de l'espace de travail ou ## Sorties d'un hôte). Genesis traite ces sections comme du texte opaque ; le consommateur nommé seul possède leur signification et leur exécution. Ne prétendez pas qu'une recette proposée est utilisable tant qu'elle ne correspond pas à la source.

Le Programme est une explication concise et faillible. Ses Sources et ses cartes

d'Implémentation optionnelles aident à la navigation mais ne remplacent jamais la lecture du code, des tests et du comportement à l'exécution.

.genesis/machine-city.json est une carte dérivée détaillée fichier/fonction. .genesis/program-city.json est une carte dérivée plus simple sous-système/opération. Ni l'un ni l'autre n'est une autorité ou une preuve ; tous deux sont ignorés par git et peuvent être régénérés avec l'opération Genesis index.

Implémenter du travail local ordinaire

• Appliquez l'approche d'ingénierie effective fournie par Genesis. Chaque changement doit être facile à raisonner et être la plus petite implémentation ciblée qui satisfait pleinement les exigences connues. Ne suringénierisez pas et ne compliquez pas, et n'ajoutez pas d'abstractions, de couches, de dépendances, d'infrastructure, de chemins de compatibilité, de modèles distribués, de cryptographie ou d'autres mécanismes avancés spéculatifs.
• Lorsqu'une exigence concrète rend une complexité matérielle nécessaire, arrêtez-vous avant de l'écrire. Expliquez pourquoi la conception directe est insuffisante et la plus petite complexité ajoutée proposée, puis demandez à l'utilisateur d'approuver ou de clarifier le compromis. Ne passez jamais silencieusement outre l'approche d'ingénierie.
• Travaillez directement dans l'arborescence Git actuelle et laissez les modifications utiles visibles dans le diff ordinaire.
• Maintenez le Blueprint et les modules du Programme concernés alignés dans ce même tour lorsque l'implémentation modifie intentionnellement le comportement produit observable. Une restructuration privée peut nécessiter uniquement des Sources corrigées ou une carte d'Implémentation informative, et peut ne nécessiter aucune modification explicative. Maintenez les déclarations d'opérations consommateur appartenant au projet, telles que les ## Sorties d'un hôte, alignées lorsque l'implémentation modifie intentionnellement les commandes ou capacités correspondantes. Enregistrez uniquement les métadonnées de capacité et les noms de variables d'environnement là, jamais les valeurs ou les secrets ; n'inférez pas et n'exécutez pas la section comme un comportement Genesis. Traitez .genesis/ comme des données de navigation dérivées remplaçables, et non comme une intention produit créée.
• Suivez les joints de projet et de technologie établis au lieu de créer des frameworks, des couches de persistance, des transports, des validateurs ou des systèmes d'UI parallèles.
• N'inventez jamais de valeurs de ressources externes indisponibles et ne passez pas de noms de variables d'environnement littéraux en tant que données. Signalez la ressource manquante et préservez le travail utile.
• Gardez l'implémentation directe et cohésive. Appliquez toute directive de Post-changement de la Stack fournie avant de signaler l'achèvement ; elle fait partie de ce tour d'implémentation, pas une demande pour un autre tour d'agent. Exécutez des vérifications ciblées lorsque cela est utile.

Vérifier et signaler

Pendant l'implémentation, sélectionnez les vérifications pertinentes pour le changement. Exécutez les vérifications finales déclarées par la Stack via Genesis verify lorsque la politique de vérification du projet ou la demande de l'utilisateur l'exige, après que le substrat de l'espace de travail de la technologie sélectionnée existe. Terminer un élément ou reprendre une session ne nécessite pas en soi une large exécution de vérification. Conservez la sortie complète dans les artefacts locaux, préservez le statut de sortie, et lisez les résumés et les extraits d'échec pertinents avant de développer les journaux. N'affaiblissez pas les assertions et n'omettez pas la couverture requise pour gagner du temps ou des tokens. Un résultat non configuré signifie que l'espace de travail déclaré ou les vérifications n'existent pas encore ; ce n'est pas une vérification échouée. Avant de signaler l'achèvement, comparez le comportement observable demandé, les entrées et ressources requises, les opérations de projet déclarées, et les preuves ciblées avec ce qui existe réellement. Signalez les fichiers modifiés, les vérifications réellement exécutées, tout ce qui n'est pas prouvé, et tout ce qui nécessite encore de l'attention. Ne prétendez jamais qu'une vérification non exécutée a réussi ou que des vérifications réussies prouvent l'ensemble du produit.

Maintenance des sous-systèmes

Maintenez genesis/subsystems.md dans le même tour d'implémentation lorsqu'un changement ajoute, supprime ou modifie une responsabilité de sous-système, une appartenance au Programme, ou une propriété/utilisation de données. Lisez la carte avant de modifier le code connexe. Réutilisez les sous-systèmes existants à moins qu'une responsabilité distincte ne soit étayée. Exigez un répertoire Source par sous-système et déclarez chaque module du Programme exactement une fois ; les noms de dossiers du Programme ne déterminent pas l'appartenance. Maintenez les références de table ancrées dans le schéma/les migrations ; Genesis n'inspecte pas les bases de données. Les modifications privées d'auxiliaire ne nécessitent aucune modification de la carte lorsque ces associations restent inchangées.

Si genesis/subsystems.md est manquant, ou est vide dans une application expliquée existante, créez-le à partir de la source réelle, du schéma et du Programme existant avant l'implémentation. Il s'agit d'une adoption explicative ordinaire, pas d'un blocage ou d'une raison de demander à nouveau la permission. Préservez le Programme et la source existants ; inspectez les responsabilités pertinentes et complétez la plus petite carte véridique. L'initialisation peut créer le fichier vide, mais seul l'agent crée sa signification.