Angelicismo01/isaackdb

Workflow de modding Isaac

N'inventez jamais une API de The Binding of Isaac parce que son nom semble plausible. Un nom plausible n'est pas une preuve. Cherchez ; si elle reste absente, dites NON VÉRIFIÉ.

Acheminement de la tâche

1. Inspectez le mod de l'utilisateur avant de l'éditer : metadata.xml, main.lua, contenu XML, includes, copies de dépendances, et notes de cible/version.
2. Identifiez la build cible et si REPENTOGON/bibliothèques sont disponibles. Si non spécifié, utilisez le pin du dépôt comme base de recherche uniquement. Ne prétendez pas que le runtime installé par l'utilisateur correspond à ce pin ou est compatible avec le futur.
3. Traduisez la demande en exigences de portée, propriété, durée de vie, coopération, ressources, dépendances, compatibilité, performance et test. Pour un boss/personnage/étage ou un système de grande envergure, rédigez d'abord un court cahier des charges. Si les visuels changent, inventoriez les ressources nécessaires et lisez les règles de production graphique. Créez des artworks uniquement si nécessaire ; définissez le contrat de feuille/anim avant de travailler sur les PNG/ANM2 finaux.
4. Cherchez dans indexes/tasks.json, les alias, puis les symboles exacts. Lisez knowledge/INDEX.md et l'enregistrement sourcé généré uniquement pour le domaine concerné.
5. Cherchez à la fois dans les enregistrements vanilla et REPENTOGON lorsque REPENTOGON est activé ; son enregistrement de modification explicite l'emporte pour cette cible.
6. Vérifiez la sémantique des callbacks, la précision de version, les conflits/problèmes, la faisabilité, la coopération locale, la durée de vie des états, le XML/ressources, la performance et la compatibilité.
7. Choisissez un motif étiqueté par dépendance. Distinguez un échafaudage d'une référence statique en or ; runtime_tested: false ne signifie jamais vérifié en jeu.
8. Implémentez le plus petit changement compatible avec l'architecture. Réutilisez les modules, IDs, callbacks, helpers et styles existants. Ne créez pas un main.lua de remplacement avant d'avoir compris le projet.
9. Exécutez python scripts/validate_kb.py --project <mod-folder> --ecosystem <vanilla|repentogon> et les audits pertinents sous prompts/.
10. Rapportez les dépendances, les preuves exactes utilisées, les limites de validation et les tests ciblés en jeu.

Quand la récupération a besoin de précision :

• Cherchez dans indexes/symbols.json pour les APIs/enums/XML exacts.
• Cherchez dans indexes/callbacks.json pour les arguments, filtres, retours et modifications REPENTOGON.
• Cherchez dans indexes/aliases.json pour les termes en langage naturel.
• Cherchez dans indexes/errors.json pour l'acheminement basé sur les symptômes.
• Utilisez knowledge/feasibility.md avant un travail inhabituel.
• Pour une sémantique exacte, lisez le source_path de l'enregistrement sous le checkout ignoré .cache/upstreams/<source>/ après avoir vérifié son HEAD par rapport au pin du registre. En cas de dérive, lisez le fichier épinglé avec git show <pin>:<path> ; ne traitez pas le checkout plus récent comme une preuve épinglée. S'il est absent, exécutez le workflow de mise à jour sécurisé et examinez la dérive de la source avant d'accepter un nouveau pin.

Ne réimplémentez pas un système d'étage, de santé personnalisée, de minimap, de configuration, de succès ou de complétion tant que les options natives actuelles de REPENTOGON et des bibliothèques maintenues n'ont pas été comparées. Ne mélangez pas IsaacScript/TypeScript ou une bibliothèque dans du Lua ordinaire à moins que le projet ne l'utilise déjà ou que l'utilisateur ne l'accepte.

Contrôles non-négociables

• Confirmez les arguments du callback, le filtre, le type de retour, le comportement d'annulation/remplacement, et si REPENTOGON modifie le callback vanilla.
• Confirmez l'orthographe des membres de classe et le badge de version dans un enregistrement normalisé.
• Confirmez le type/variante/sous-type d'entité et les attributs XML à partir des enregistrements actuels ou des ressources locales extraites. Ne devinez jamais les IDs numériques ou les chemins de ressources.
• Utilisez les callbacks de cache pour les statistiques de joueur et les comptes de familiers. Utilisez des filtres de callback explicites là où c'est documenté. Évitez les scans complets de salle dans les callbacks par image/rendu sauf si mesurés et filtrés étroitement.
• Gardez la propriété du joueur et la coopération locale explicites. Ne présumez pas que l'index du joueur est 0.
• Gardez les données de sauvegarde compatibles JSON ; chargez seulement après le début d'une partie et sauvegardez aux points de cycle de vie documentés. Préservez les valeurs par défaut lors du décodage de sauvegardes anciennes ou partielles.
• Ne copiez pas et ne modifiez pas les ressources installées du jeu. Les notes de chemins dérivés sont autorisées.
• Considérez les graphismes comme des ressources du jeu : faites correspondre les crops PNG réels, ANM2, Lua/XML et les événements d'animation. Les placeholders sont développementaux, jamais finaux. Sans un test visuel observé en jeu, enregistrez visual_runtime_tested: false.

Lisez seulement ce dont la tâche a besoin

• Question API/callback : catalogues générés plus knowledge/callbacks/critical-callbacks.md.
• Travail XML/ressource/animation/salle : le guide correspondant sous knowledge/ et les schémas vendus sous schemas/.
• Nouveaux sprites, costumes, reskins ou travail d'animation : production graphique, modèle de contrat, et QA visuel. Exécutez scripts/gfx_audit.py <mod-folder> ; utilisez --release pour la porte finale/readiness.
• Implémentation : patterns/INDEX.md et la famille de motifs correspondante.
• Débogage : knowledge/debugging/decision-tree.md.
• Bibliothèques : knowledge/libraries/index.md ; lisez la documentation/le code public actuel de la bibliothèque avant de l'appeler.

Quand les références de confiance ne contiennent pas une API demandée, dites qu'elle est non vérifiée ou inexistante dans les révisions indexées. Ne fabriquez pas de solution de repli.