muracoco/gyosei-jp

¿Qué hace gyosei-jp?

Transforma el texto de entrada en un lenguaje administrativo japonés sin alterar los hechos, utilizando únicamente reglas condicionales verificadas.

Lo primero que se debe comprobar

1. Leer references/rule_registry.json y considerar solo las reglas cuyo status sea igual o superior a adopted-experimental.
2. Leer references/genre_profiles.json y verificar si el tipo de documento de entrada está dentro del ámbito de aplicación.
3. Leer references/invariants.md y fijar primero las restricciones de calidad del texto, preservación del significado y Pink Elephant.

No se deben añadir por cuenta propia candidatos no adoptados, palabras de alta frecuencia o términos que parezcan administrativos.

Organizar la entrada

En la medida de lo posible, identificar el propósito, el lector, el tipo de documento, el emisor, los hechos, los valores numéricos, las fechas, las condiciones, las excepciones, el tiempo verbal, el grado de certeza y las acciones necesarias.

Solo confirmar las omisiones importantes que cambien el significado. Si no hay información, no inventar.

Si existe un historial de correcciones o eliminaciones, separar el contenido actualmente válido como TARGET_STATE, las propuestas anteriores como REJECTED_HISTORY, y las comparaciones o divulgaciones necesarias para el producto final como VISIBLE_EXCEPTIONS. En el Clean Brief utilizado para la generación, incluir solo TARGET_STATE y VISIBLE_EXCEPTIONS.

Transformar

La transformación se divide en dos capas.

1. Eliminar los vicios de redacción propios de la IA

Revisar las reglas del registry cuyo family sea ai_removal. Aplicarlas solo si se cumple su trigger y no se incurre en contraindications.

No dejar rastros de eliminación, explicaciones de cambios o formas negativas. Reconstruir las oraciones a partir de los hechos necesarios para explicar el contenido.

2. Estructurar según la sintaxis del japonés administrativo

Revisar las reglas de estructura administrativa del registry y el perfil del tipo de documento. Ajustar el orden de la información, el sujeto, los nombres oficiales, las condiciones, las excepciones, los plazos, los procedimientos, los documentos necesarios, las instrucciones de acción y la disposición de las consultas.

No aumentar el vocabulario administrativo mediante sustituciones de palabras. Vincular internamente la razón de aplicación de cada regla con su rule_id.

Inspeccionar

Inspeccionar el borrador final según references/invariants.md.

• Cotejar con la entrada el significado, los hechos, los valores numéricos, las fechas, los nombres propios, las condiciones, las excepciones, el tiempo verbal y el grado de certeza.
• Confirmar que no se hayan reforzado ni debilitado obligaciones, prohibiciones, permisos, recomendaciones ni efectos legales o institucionales.
• Verificar que no haya omisiones de Pink Elephant en los aspectos Literal, Semántico, Racional y de Atención.
• Si hay omisiones o fallos graves de preservación, no corregir con eliminaciones localizadas, sino reconstruir a partir del Clean Brief.
• En tipos de documento no soportados, no forzar la generalización de las reglas adoptadas; priorizar la preservación del significado y un japonés claro y normal.

Si el usuario solo solicita el borrador final, no mezclar en el cuerpo los IDs de reglas, explicaciones de investigación, historial de cambios ni informes de inspección; devolver únicamente el borrador final.