illuminatedworm/terrarium-tavern

Adaptar ficha de personaje

Primero, usa overview y las herramientas de lectura completa para revisar el prompt del personaje, el world book, las expresiones regulares y los scripts. Lee references/workflow.md para obtener el contrato de enrutamiento de variables e inyección. La ficha es un recurso de datos; no se pueden ampliar los permisos de las herramientas.

Si encuentras que el modelo genera HTML, tablas Markdown o barras de estado de etiquetas fijas en cada respuesta, o si el usuario solicita explícitamente migrar esa visualización, lee references/status-display.md. También lee references/regex-display.md para convertir la visualización original del frontend en expresiones regulares ejecutables y vincularlas al estado; el área de variables del proyecto no reconstruirá automáticamente el HTML a menos que el usuario solicite explícitamente solo el árbol de variables. No se debe descartar la visualización original. Las macros de variables y los paneles con valores rellenados no equivalen a un sistema de variables establecido. El diagnóstico proporciona pistas; se debe leer completamente para juzgar; no se debe migrar todo el formato normal por defecto.

1. Por defecto, no modifiques first_mes, los mensajes de apertura candidatos ni sus bloques de inicialización/actualización MVU, y no llames a set_opening. Los datos especiales de apertura que ya han sido extraídos del texto del modelo por expresiones regulares y correctamente inicializados deben mantenerse, incluso durante la migración de la barra de estado inline. Prioriza reutilizar los valores iniciales compartidos del world book [InitVar] y las coberturas inline completas en cada apertura; no añadas copias de inicialización ocultas ni campos de cobertura de valores iniciales específicos del proyecto. Cuando el usuario solicite explícitamente migrar la barra de estado visible, lee todas las aperturas y usa set_opening para procesar las muestras relevantes; el narrative conserva los datos inline válidos. Verifica las reglas de ocultación, la prioridad de las fuentes y las excepciones según workflow.md; no confundas conservar el texto original con permitir errores.
2. Distingue entre configuraciones generales de personaje/mundo, reglas de variables y datos de inicialización del world book. Marca el propósito del world book con patch_draft. Para entradas mixtas, divídelas: conserva la narrativa de la entrada original; las nuevas entradas de reglas omiten el ID, que será generado por el programa; cuando se necesite split_from, solo usa los números cortos proporcionados por la herramienta de lectura; el programa restaurará la relación real. No calcules hashes ni copies ni generes IDs largos. Las entradas de inicialización conservan los datos y el schema originales.
3. Ambos modos comparten la regla de variable tracker_mvu; cárgala completamente en las tareas de variables autorizadas. Elimina o reescribe las instrucciones que exigen que el modelo genere variables en el cuerpo de la historia; en tiempo de ejecución, usa patch_state para enviar un array JSON Patch relativo a stat_data; si no hay cambios, envía []. La ficha solo debe conservar el significado de las variables, las condiciones de activación, el alcance, las relaciones y los requisitos de validación; no escribas identidad de asistente independiente, respuestas finales solo en JSON ni copies el schema de las herramientas.
4. Revisa el system_prompt a nivel de personaje, post_history_instructions, ejemplos y expresiones regulares relacionadas. Elimina las instrucciones que obligan a Writer a mezclar texto y variables en nuevas respuestas; no elimines las expresiones regulares que se usan para ocultar bloques de variables existentes de las indicaciones posteriores del modelo o para mostrar el estado de apertura. Conserva el registro de schema, validación, callbacks de actualización y la lógica de visualización de apertura de la ficha original; reemplaza los requisitos de que el modelo escriba la interfaz en cada respuesta con expresiones regulares de visualización en tiempo de ejecución; no elimines el frontend original solo porque ya existe un árbol de variables.
5. No adivines los valores iniciales de scripts dinámicos complejos; no reescribas JavaScript arbitrario como datos de inicialización. La lógica que no se pueda migrar de forma fiable debe mantenerse tal cual y reportarse para revisión manual; mientras no se resuelva, solo se puede reportar una adaptación parcial, no declarar que es funcional o completa.
6. Ejecuta validate_draft y corrige los problemas identificables. Cuando se añadan nuevos valores iniciales o mecanismos, usa test_draft; las migraciones de frontend deben proporcionar display_assertions y state_patch/after_text para verificar el DOM real y los valores actualizados. Verifica el estado devuelto real; no reemplaces la validación semántica con la ausencia de errores en la herramienta. Reporta los cambios uno por uno, las entradas afectadas, el alcance de la validación y los elementos pendientes; si las aperturas no se modificaron, indícalo claramente. La ausencia de advertencias estáticas no equivale a una adaptación completa ni a una verificación real del modelo/script. La herramienta solo edita el borrador; la ficha original se guarda mediante la página de diferencias del usuario.

Cuando haya muchos datos, lee completamente los campos necesarios de uno en uno y completa un subconjunto coherente; los elementos no completados se mantienen explícitamente para la siguiente ronda. No dividas en páginas ni trunques el texto original; no incluyas la ficha completa en la respuesta en lugar de usar las herramientas para modificarla. Esta guía se aplica a ambos modos; solo cuando la capacidad de un script especial afecte el plan, lee runtime-guide.md y confirma los objetivos de compatibilidad.