vibe64-dev/seed-nextjs

Genesis Deslop

Passez en revue et simplifiez les modifications sélectionnées sans modifier le comportement du produit. Deslop est explicite : ne l'exécutez jamais simplement parce que l'implémentation est terminée.

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 fichier package.json à la racine du dépôt. Considérez Genesis comme « épinglé au projet » uniquement lorsque le champ 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 épinglé au projet, invoquez chaque opération CLI Genesis avec npm exec --no -- genesis <arguments>. Ceci s'exécute sans récupérer un autre package. Si le package 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 recherche dans le PATH pour le shell actuel). Lorsqu'il résout un exécutable, invoquez genesis <arguments> directement.
4. Lorsqu'aucune source n'est disponible, arrêtez-vous et signalez que Genesis est indisponible. N'installez ni ne mettez jamais à jour Genesis simplement pour satisfaire une instruction de workflow.

La résolution réussie de l'invocation est routinière. Ne racontez pas si Genesis est épinglé 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. Faites état de l'avancement concret, des résultats ou des blocages ; n'annoncez pas que vous suivez des instructions.

Charger les instructions de projet effectives une fois

Une requête Deslop peut arriver soit comme une invite complète générée par Genesis, soit comme une requête directe telle que « Deslop » dans une session d'agent.

Si la tâche en cours contient déjà un GENESIS CONTEXT dont la tâche est deslop, continuez directement avec celle-ci. Ne générez pas une autre invite.

Sinon, avant de résoudre la portée Git, exécutez l'opération Genesis prompt --task deslop une fois en utilisant la règle d'invocation ci-dessus. Pour une requête « Deslop » simple, ne passez pas d'argument. Lorsque l'utilisateur nomme un nombre, un commit ou une plage, passez cette requête exacte comme un argument correctement échappé. Traitez l'invite imprimée comme les instructions pour ce même tour ; ne la transmettez pas à un autre agent et ne la générez pas à nouveau. Cette étape compose les instructions Deslop spécifiques à la technologie de la Stack sélectionnée et toute personnalisation du projet avec le contrat portable ci-dessous.

Résoudre la portée du nettoyage

Inspectez git status --short et les diffs stagés et non stagés avant de modifier. Un répertoire de travail modifié est autorisé ; un commit préalable n'est pas requis. Préservez l'index existant et le travail non lié. Ne stagnez pas, ne stash pas, ne committez pas et ne jetez pas les modifications comme condition préalable ou dans le cadre du nettoyage.

Résolvez la portée de l'utilisateur comme suit :

• Sans portée indiquée, sélectionnez uniquement vos propres modifications pour la tâche en cours, y compris les tours précédents. Cela peut inclure des modifications stagées et non stagées, de nouveaux fichiers non suivis, et des modifications de tâches déjà commitées. Identifiez la propriété à partir de l'historique des tâches et des modifications, puis confirmez ces modifications par rapport à la source actuelle et aux diffs Git. Ni l'ensemble du diff modifié, ni le dernier commit, ni une identité d'auteur Git ne prouvent la propriété.
• Préservez les modifications apportées par l'utilisateur ou d'autres agents, y compris les modifications dans les mêmes fichiers. Si la propriété ne peut pas être établie, demandez quelles modifications desloper. S'il n'y a pas de modifications vous appartenant pour cette tâche, signalez qu'il n'y a rien à desloper ; ne sélectionnez pas silencieusement le dernier commit ou le travail de quelqu'un d'autre.
• Un commit explicite, un nombre de premiers parents ou une plage a priorité sur la valeur par défaut, indépendamment de qui a fait ces modifications.
• « Le dernier commit » signifie HEAD par rapport à son premier parent.
• « Les N derniers commits » signifie le changement net survivant du premier parent avant ces N commits jusqu'à HEAD.
• Un commit nommé signifie ce commit par rapport à son premier parent.
• Une plage de commits explicite signifie exactement cette plage.
• Un commit racine utilise la forme de diff racine de Git car il n'a pas de parent.

Inspectez les modifications et chemins résolus, ainsi que les identités de commit le cas échéant. Passez en revue leur diff, la source actuelle, les sites d'appel directs, les tests pertinents, et le contexte de Program et de Stack concerné. Pour une portée commitée explicite, ne substituez pas le diff ordinaire de l'arbre de travail par le diff commité sélectionné. Appliquez le nettoyage à la source actuelle tout en préservant les modifications en dehors de la portée. Si des modifications qui se chevauchent ne peuvent pas être séparées en toute sécurité, demandez à propos de ce chevauchement plutôt que de bloquer uniquement parce que le dépôt est modifié.

Appliquer le contrat de nettoyage

Appliquez l'approche d'ingénierie fournie avec la tâche. Si cette compétence est invoquée directement, lisez genesis/engineering.md ainsi que le contexte pertinent du projet. Le nettoyage doit réduire ou préserver la complexité, ne jamais introduire de mécanisme non approuvé dont le profil sélectionné ou une exigence concrète n'a pas besoin.

Consultez .genesis/machine-city.json ou exécutez l'opération Genesis index <nom-ou-chemin> pour trouver les fonctions publiques et internes existantes avant d'introduire ou de consolider une abstraction. Confirmez chaque doublon apparent dans la source et ses sites d'appel.

Dans le comportement prévu et la portée des modifications sélectionnées, ne laissez aucun utilitaire répété, aucun code peu clair ou difficile à raisonner, et aucun code qui va à l'encontre des modèles établis dans la base de code. Supprimez les wrappers inutiles, l'échafaudage abandonné, la tuyauterie de framework parallèle et les abstractions spéculatives. Consolidez la propriété là où un seul module clair suffit. N'optimisez pas pour des fichiers minuscules ou de l'indirection ; optimisez pour une conception petite et évidente qu'un programmeur junior peut suivre.

Deslop n'est pas une seconde passe d'implémentation. Les modifications sélectionnées limitent l'endroit où le nettoyage peut se produire ; partager un fichier n'inclut pas des modifications non liées dans la portée ni n'autorise un comportement différent dans ce fichier. Deslop peut réorganiser le comportement déjà présent ; il ne peut pas compléter, corriger ou étendre le comportement. Si la revue révèle un défaut, un comportement manquant, une non-conformité de contrat ou une lacune de test, signalez-le comme une constatation de suivi et laissez-le inchangé, même s'il se trouve à l'intérieur d'un chemin modifié ou semble lié à l'implémentation précédente. N'implémentez pas la constatation et ne modifiez pas les tests pour l'accommoder pendant Deslop.

Appliquez chaque instruction Deslop spécifique à la technologie fournie par la Stack sélectionnée et chargez les compétences technologiques officielles applicables pour le contexte du framework et du langage. Les conseils de la Stack enrichissent ce contrat ; ils ne peuvent pas affaiblir la frontière de préservation du comportement, changer la portée sélectionnée ou autoriser une implémentation non liée.

Vous pouvez modifier ou supprimer des fichiers d'implémentation et de test lorsque c'est le nettoyage le plus clair préservant le comportement. Si le déplacement ou le renommage d'une source sélectionnée rend une citation de Program concernée obsolète, mettez à jour uniquement cette citation ou la carte d'implémentation informative. Ne modifiez pas le Blueprint ou le contrat public d'un Program pour excuser un comportement de nettoyage. Ne modifiez pas .genesis/, les métadonnées Git, les répertoires de dépendances, les artefacts de build générés, l'historique des migrations conservé, ou les ressources externes. N'affaiblissez pas les tests, le comportement public ou les garanties de données. Ne créez pas une seconde architecture et n'effectuez pas de réécritures non liées.

Laissez le nettoyage comme un travail ordinaire non commité pour une revue et un commit normal ultérieur. Ne modifiez ni ne réécrivez jamais les commits sélectionnés. Exécutez des vérifications ciblées lorsque c'est utile. Les vérifications déclarées finales restent disponibles via l'opération Genesis verify. Résumez la portée résolue et toute identité de commit sélectionnée, ce qui est devenu plus simple, les fichiers modifiés, les vérifications réellement exécutées, et les constatations de suivi laissées inchangées.