OpoTests/tests-estructura-extended.md

115 lines
5.5 KiB
Markdown

# Especificación extendida para generación de Tests JSON
Este fichero complementa y extiende las normas básicas de `/tests-estructura.md` para escenarios en los que
se desea obtener una gran variedad de opciones por pregunta (múltiples preguntas equivalentes, varias respuestas
correctas, y un amplio conjunto de respuestas incorrectas plausibles). La sintaxis descrita aquí es estricta: cualquier
desviación en campos, tipos o nombres provocará errores de interpretación por las herramientas de ingestión.
## 1) Objetivo
- Permitir la generación de Tests con mayor densidad de opciones por pregunta sin cambiar la estructura raíz definida
en `/tests-estructura.md`.
- Evitar cambios en la estructura: el parser que consume estos ficheros espera exactamente los campos documentados
(ver sección 2). No se permiten campos adicionales, ni cambios en los nombres de campo.
## 2) Estructura raíz (obligatoria y única)
- El fichero JSON debe ser un array que contenga exactamente un objeto con las claves siguientes:
- `origin`: String — autor o fuente de las preguntas.
- `title`: String — título del conjunto de preguntas.
- `group`: String — clave id del grupo. Debe cumplir la regex: `/^[a-z0-9_]+$/i`.
- `source`: String | Array[String] — fuentes o enlaces.
- `queries`: Array[Question] — lista de preguntas.
Nota: ningún otro campo raíz está permitido. Si se añade cualquier otra clave, el fichero será rechazado por el validador.
## 3) Estructura de `Question` (estricta)
- Cada elemento de `queries` es un objeto con únicamente estas claves:
- `question`: String | Array[String]
- Si es `Array[String]`, cada elemento es una variante textual válida de la misma pregunta.
- `rights`: Array[String] (una o más respuestas correctas). Mínimo 1.
- `wrongs`: Array[String] (respuestas incorrectas plausibles). Mínimo 3.
Reglas estrictas de tipos y contenidos:
- `question` debe ser String o Array de Strings — no se permiten objetos en su lugar.
- `rights` y `wrongs` deben ser arrays de Strings. Ningún elemento puede ser `null` o cadena vacía.
- No se permiten campos adicionales dentro de cada pregunta (por ejemplo `difficulty`, `options`, `explanation`, etc.).
## 4) Reglas de contenido (recomendadas y exigentes)
- Prioriza la calidad y la fidelidad: las entradas en `rights` deben ser correctas según la fuente; `wrongs` deben ser plausibles,
mezclando errores comunes, confusiones terminológicas y alternativas semánticas.
- Para este esquema extendido recomendamos (objetivos, no obligatorios):
- Intentar generar al menos 6 opciones por pregunta (combinando `rights` y `wrongs`).
- Cuando el tema lo permita, incluir >=2 `rights` (respuestas correctas alternativas o complementarias) y >=4 `wrongs`.
- Usar variantes en `question` (Array de Strings) cuando quieras mantener la misma idea expresada con distinto enfoque.
- Es importante entender que las preguntas pertenecen a una batería de preguntas que las une y por tanto, es importante determinar de qué se habla en las mismas para evitar ambigüedades.
## 5) Validaciones que ejecutará el parser (fallo en caso contrario)
- `group` debe cumplir `/^[a-z0-9_]+$/i`.
- `queries` debe ser un array no vacío.
- Cada `query` debe tener `>=1` elemento en `rights` y `>=3` en `wrongs`.
- No se admiten campos extras en la raíz ni en `queries`.
- Todos los valores deben ser de tipo `string` donde se requiera.
Si cualquiera de estas validaciones falla, el fichero se considerará inválido y la herramienta devolverá un error que especifica
el primer incumplimiento detectado.
## 6) Ejemplo mínimo válido (JSON simplificado)
```json
[
{
"origin": "Fuente Ejemplo",
"title": "Ejemplo mínimo",
"group": "ejemplo_min",
"source": "docs/ejemplo.md",
"queries": [
{
"question": "¿Cuál es la finalidad del ejemplo?",
"rights": ["Verificar el formato del test"],
"wrongs": ["Crear campos nuevos","Usar tokens como campos","Dejar el JSON inválido"]
}
]
}
]
```
## 7) Ejemplo extendido (más opciones y múltiples `rights`)
```json
[
{
"origin": "TREBEP - Preámbulo",
"title": "Preguntas TREBEP - Extendido",
"group": "trebep_preambulo_ext",
"source": ["/Public/md/trebep/trebep.000.preambulo.md"],
"queries": [
{
"question": [
"Según el preámbulo, ¿qué autoriza el art. uno.g) de la Ley 20/2014?",
"¿Qué facultad concede el art. uno.g) de la Ley 20/2014 en el preámbulo?"
],
"rights": [
"Autoriza al Gobierno a aprobar textos refundidos en el plazo previsto",
"Permite integrar y armonizar disposiciones dispersas en un único texto"
],
"wrongs": [
"Derogar automáticamente la Ley 7/2007",
"Transferir competencias legislativas a las Comunidades Autónomas sin ley",
"Aprobar normas de carácter constitucional sin reforma",
"Suprimir los derechos laborales sin tramitación"
]
}
]
}
]
```
## 8) Buenas prácticas y recomendaciones editoriales
- Realiza revisiones jurídicas para confirmar que cada `rights` es correcta.
- Diversifica `wrongs` para cubrir errores de concepto, confusiones terminológicas y alternativas plausibles.
- Prefiere variantes textuales en `question` para facilitar tests por formato (formulación directa, de verdadero/falso, de selección múltiple).
## 9) Nomenclatura y guardado
- Nombre sugerido del fichero JSON final: `autor.tema.json` y se guardará en `/Public/json/copilot/gpt5mini/`.
---
Fecha de la especificación: 2025-10-29