Angelicismo01/isaackdb

Isaac-Modding-Workflow

Erfinde niemals eine Binding-of-Isaac-API, weil ihr Name plausibel klingt. Ein plausibler Name ist kein Beweis. Suche; wenn sie nicht vorhanden bleibt, sage UNVERIFIED (UNBESTÄTIGT) an.

Route die Aufgabe

1. Untersuche das Mod des Benutzers vor dem Bearbeiten: metadata.xml, main.lua, Inhalts-XML, Includes, Abhängigkeitskopien und Ziel-/Versionshinweise.
2. Identifiziere den Ziel-Build und ob REPENTOGON/Bibliotheken verfügbar sind. Falls nicht angegeben, verwende den Repository-Pin nur als Forschungsbasis. Gib nicht an, dass die installierte Laufzeit des Benutzers diesem Pin entspricht oder zukunftskompatibel ist.
3. Übersetze die Anfrage in Anforderungen an Umfang, Eigentümerschaft, Lebensdauer, Koop, Ressourcen, Abhängigkeiten, Kompatibilität, Leistung und Tests. Erstelle für einen Boss/Charakter/Bühne oder ein großes System zuerst eine kurze Spezifikation. Wenn sich die Optik ändert, inventarisiere die benötigten Assets und lies die Grafik-Produktionsregeln. Erstelle Kunst nur bei Bedarf; definiere den Sheet/Animationsvertrag vor der finalen PNG/ANM2-Arbeit.
4. Durchsuche indexes/tasks.json, Aliase, dann exakte Symbole. Lies knowledge/INDEX.md und den generierten quellverlinkten Datensatz nur für die relevante Domäne.
5. Durchsuche sowohl Vanilla- als auch REPENTOGON-Datensätze, wenn REPENTOGON aktiviert ist; sein expliziter Änderungsdatensatz gewinnt für dieses Ziel.
6. Prüfe Callback-Semantik, Versionsgenauigkeit, Konflikte/Probleme, Machbarkeit, lokalen Koop, Zustandslebensdauer, XML/Ressourcen, Leistung und Kompatibilität.
7. Wähle ein abhängigkeitsgekennzeichnetes Muster. Unterscheide ein Gerüst von einer goldenen statischen Referenz; runtime_tested: false bedeutet nie spielgeprüft.
8. Implementiere die kleinste architekturkompatible Änderung. Verwende vorhandene Module, IDs, Callbacks, Helfer und Stile wieder. Erstelle keinen Ersatz- main.lua, bevor du das Projekt verstanden hast.
9. Führe python scripts/validate_kb.py --project <mod-folder> --ecosystem <vanilla|repentogon> und die relevanten Audits unter prompts/ aus.
10. Melde Abhängigkeiten, verwendete genaue Beweise, Validierungsgrenzen und gezielte In-Game-Tests.

Wenn die Suche Präzision benötigt:

• Durchsuche indexes/symbols.json nach exakten APIs/Enums/XML.
• Durchsuche indexes/callbacks.json nach Argumenten, Filtern, Rückgaben und REPENTOGON-Änderungen.
• Durchsuche indexes/aliases.json nach Begriffen in natürlicher Sprache.
• Durchsuche indexes/errors.json nach symptomgesteuerter Weiterleitung.
• Verwende knowledge/feasibility.md vor ungewöhnlicher Arbeit.
• Für genaue Semantik lies den source_path des Datensatzes im ignorierten .cache/upstreams/<source>/-Checkout, nachdem du seinen HEAD mit dem Registry-Pin verglichen hast. Bei Abweichung lese die gepinnte Datei mit git show <pin>:<path>; behandle den neueren Checkout nicht als gepinnten Beweis. Wenn nicht vorhanden, führe den kuratierten sicheren Update-Workflow aus und überprüfe die Quellabweichung, bevor du einen neuen Pin akzeptierst.

Implementiere ein Bühnen-, Individual-Leben-, Minikarten-, Konfigurations-, Erfolgs- oder Abschlusssystem erst dann neu, wenn die aktuellen nativen REPENTOGON- und gepflegten Bibliotheksoptionen verglichen wurden. Mische IsaacScript/TypeScript oder eine Bibliothek nicht in normales Lua, es sei denn, das Projekt verwendet es bereits oder der Benutzer akzeptiert es.

Nicht verhandelbare Prüfungen

• Bestätige Callback-Argumente, Filter, Rückgabetyp, Abbrech-/Ersetzungsverhalten und ob REPENTOGON den Vanilla-Callback ändert.
• Bestätige die Schreibweise von Klassenelementen und den Versionsabzeichen in einem normalisierten Datensatz.
• Bestätige Entity-Typ/Variante/Untertyp und XML-Attribute anhand aktueller Datensätze oder extrahierter lokaler Ressourcen. Rate niemals numerische IDs oder Ressourcenpfade.
• Verwende Cache-Callbacks für Spielerstatistiken und Familiar-Zählungen. Verwende explizite Callback-Filter, wo dokumentiert. Vermeide vollständige Raum-Scans in Pro-Bild/ Render-Callbacks, es sei denn, sie sind gemessen und eng gefiltert.
• Halte Spieler-Eigentümerschaft und lokalen Koop explizit. Nimm nicht Spieler-Index 0 an.
• Halte Speicherdaten JSON-sicher; lade erst, nachdem ein Lauf gestartet ist, und speichere an dokumentierten Lebenszykluspunkten. Bewahre Standardwerte beim Dekodieren alter oder teilweiser Speicherdaten.
• Kopiere oder ändere keine installierten Spiel-Assets. Abgeleitete Pfadnotizen sind erlaubt.
• Behandle Grafiken als Spiel-Assets: stimme mit tatsächlichen PNG-Zuschnitten, ANM2, Lua/XML und Animationsereignissen überein. Platzhalter sind entwicklungsbedingt, niemals endgültig. Ohne einen beobachteten In-Game-Visual-Test, zeichne visual_runtime_tested: false auf.

Lies nur, was die Aufgabe benötigt

• API-/Callback-Frage: generierte Kataloge plus knowledge/callbacks/critical-callbacks.md.
• XML-/Ressourcen-/Animations-/Raumarbeit: der passende Leitfaden unter knowledge/ und die bereitgestellten Schemas unter schemas/.
• Neue Sprites, Kostüme, Reskins oder Animationsarbeit: Grafikproduktion, Vertragsvorlage und visuelle Qualitätssicherung. Führe scripts/gfx_audit.py <mod-folder> aus; verwende --release für das finale Asset-/Bereitschaftstor.
• Implementierung: patterns/INDEX.md und die passende Mustergruppe.
• Fehlersuche: knowledge/debugging/decision-tree.md.
• Bibliotheken: knowledge/libraries/index.md; lies die aktuellen öffentlichen Dokumente/Code der Bibliothek, bevor du sie aufrufst.

Wenn vertrauenswürdige Referenzen eine angeforderte API nicht enthalten, sage, dass sie in den indizierten Revisionen unbestätigt oder nicht vorhanden ist. Erfinde keinen Fallback.