Angelicismo01/isaackdb

Flujo de trabajo de modding de Isaac

Nunca inventes una API de Binding of Isaac porque su nombre suene plausible. Un nombre plausible no es evidencia. Busca; si sigue ausente, di NO VERIFICADO.

Enrutar la tarea

1. Inspecciona el mod del usuario antes de editar: metadata.xml, main.lua, XML de contenido, includes, copias de dependencias y notas de destino/versión.
2. Identifica la compilación objetivo y si REPENTOGON/librerías están disponibles. Si no se especifica, usa el pin del repositorio como línea base de investigación únicamente. No afirmes que el tiempo de ejecución instalado del usuario coincide con ese pin o es compatible con el futuro.
3. Traduce la solicitud a alcance, propiedad, ciclo de vida, cooperativo, recursos, dependencias, compatibilidad, rendimiento y requisitos de prueba. Para un jefe/personaje/escenario o sistema grande, escribe primero una especificación breve. Si los elementos visuales cambian, inventaria los assets requeridos y lee reglas de producción gráfica. Crea arte solo cuando sea necesario; define el contrato de hoja/animación antes del trabajo final en PNG/ANM2.
4. Busca en indexes/tasks.json, alias, luego símbolos exactos. Lee knowledge/INDEX.md y el registro generado vinculado a la fuente solo para el dominio relevante.
5. Busca tanto registros vanilla como de REPENTOGON cuando REPENTOGON esté habilitado; su registro de modificación explícito gana para ese objetivo.
6. Comprueba semánticas de callback, precisión de versión, conflictos/problemas, viabilidad, cooperativo local, ciclo de vida de estado, XML/recursos, rendimiento y compatibilidad.
7. Elige un patrón etiquetado por dependencia. Distingue un andamio de una referencia estática dorada; runtime_tested: false nunca significa verificado en juego.
8. Implementa el cambio más pequeño compatible con la arquitectura. Reutiliza módulos, IDs, callbacks, ayudantes y estilos existentes. No crees un main.lua de reemplazo antes de entender el proyecto.
9. Ejecuta python scripts/validate_kb.py --project <carpeta-mod> --ecosystem <vanilla|repentogon> y las auditorías relevantes en prompts/.
10. Reporta dependencias, la evidencia exacta utilizada, los límites de validación y las pruebas específicas en el juego.

Cuando la recuperación necesite precisión:

• Busca indexes/symbols.json para APIs/enums/XML exactos.
• Busca indexes/callbacks.json para argumentos, filtros, retornos y modificaciones de REPENTOGON.
• Busca indexes/aliases.json para términos en lenguaje natural.
• Busca indexes/errors.json para enrutamiento basado en síntomas.
• Usa knowledge/feasibility.md antes de trabajos inusuales.
• Para semánticas exactas, lee el source_path del registro en la copia de trabajo de .cache/upstreams/<source>/ después de verificar su HEAD contra el pin del registro. En caso de desviación, lee el archivo fijado con git show <pin>:<path>; no trates la copia más reciente como evidencia fijada. Si está ausente, ejecuta el flujo de actualización segura curada y revisa la desviación de la fuente antes de aceptar un nuevo pin.

No reimplementes un sistema de escenario, salud personalizada, minimapa, configuración, logro o finalización hasta que se hayan comparado las opciones nativas actuales de REPENTOGON y de librerías mantenidas. No mezcles IsaacScript/TypeScript o una librería en Lua común a menos que el proyecto ya lo use o el usuario lo acepte.

Comprobaciones innegociables

• Confirma argumentos de callback, filtro, tipo de retorno, comportamiento de cancelación/reemplazo y si REPENTOGON modifica el callback vanilla.
• Confirma la ortografía de miembros de clase y la insignia de versión en un registro normalizado.
• Confirma tipo de entidad/variante/subtipo y atributos XML a partir de registros actuales o recursos locales extraídos. Nunca adivines IDs numéricos o rutas de recursos.
• Usa callbacks de caché para estadísticas de jugador y conteos de familiares. Usa filtros de callback explícitos donde estén documentados. Evita escaneos completos de sala en callbacks por cuadro/renderizado a menos que se midan y se filtren de forma estricta.
• Mantén la propiedad del jugador y el cooperativo local explícitos. No asumas el índice de jugador 0.
• Mantén los datos de guardado seguros para JSON; carga solo después de que una partida comience y guarda en puntos de ciclo de vida documentados. Preserva valores predeterminados al decodificar guardados antiguos o parciales.
• No copies ni modifiques assets del juego instalado. Se permiten notas de rutas derivadas.
• Trata los gráficos como assets del juego: coincide con recortes PNG reales, ANM2, Lua/XML y eventos de animación. Los marcadores de posición son de desarrollo, nunca definitivos. Sin una prueba visual observada en el juego, registra visual_runtime_tested: false.

Lee solo lo que la tarea necesita

• Pregunta sobre API/callback: catálogos generados más knowledge/callbacks/critical-callbacks.md.
• Trabajo XML/recurso/animación/sala: la guía correspondiente en knowledge/ y esquemas proporcionados en schemas/.
• Nuevos sprites, disfraces, rediseños o trabajo de animación: producción gráfica, plantilla de contrato, y QA visual. Ejecuta scripts/gfx_audit.py <carpeta-mod>; usa --release para la puerta de asset-final/preparación.
• Implementación: patterns/INDEX.md y la familia de patrones correspondiente.
• Depuración: knowledge/debugging/decision-tree.md.
• Librerías: knowledge/libraries/index.md; lee la documentación/código público actual de la librería antes de llamarla.

Cuando las referencias de confianza no contengan una API solicitada, di que no está verificada o no existe en las revisiones indexadas. No fabriques una alternativa.