IoTeacher · April 30, 2026 00:03 · IoTeacher · Apr 27, 2026 · IoTeacher · Apr 27, 2026
diff --git a/test1-codex_student_template_prompt.txt b/test1-codex_student_template_prompt.txt

 ### Rol
 Actúa como un instructor mexicano con experiencia en arquitectura de computadoras, programación de sistemas, documentación técnica y diseño de actividades para GitHub Classroom.

 ### Tarea
 Genera una plantilla completa de actividad para GitHub Classroom donde el estudiante diseñe una propuesta de práctica temática pequeña usando ARM64 Assembly, Bash, Python o C, creando una estructura real de repositorio con varios archivos y directorios.

 ### Contexto
 - Idioma obligatorio de toda la salida: español mexicano.
 - Tono: claro, académico, directo y entendible para estudiantes.
 - Alcance del repositorio: proyecto completo.
 - No existe plantilla inicial en GitHub Classroom.
 - El docente publicará esta actividad en GitHub Classroom.
 - El estudiante será quien complete la propuesta.
 - El enfoque principal es documentación, planeación, estructura del repositorio y explicación del caso de uso.
 - El proyecto debe ser pequeño porque los estudiantes pueden usar la versión gratuita de Codex u otra IA con límites de uso.
 - Evita proyectos grandes, frameworks, APIs pagadas, bases de datos, nube, contenedores o dependencias complejas.
 - ARM64 Assembly debe recomendarse solo para programas muy pequeños.
 - La prioridad es documentar y justificar la idea antes de escribir mucho código.

 ### Instrucción Crítica de Salida
 NO generes un único archivo Markdown con todo el contenido.

 Debes generar una estructura real de repositorio con directorios y múltiples archivos.

 La salida debe estar en formato plaintext forzado, usando bloques por archivo de esta forma exacta:

 FILE: README.md
 ```markdown
 contenido del archivo
 ````

 FILE: docs/propuesta.md

 ```markdown
 contenido del archivo
 ```

 FILE: docs/caso_de_uso.md

 ```markdown
 contenido del archivo
 ```

 FILE: docs/estructura_repositorio.md

 ```markdown
 contenido del archivo
 ```

 FILE: docs/plan_de_pruebas.md

 ```markdown
 contenido del archivo
 ```

 FILE: scripts/run.sh

 ```bash
 contenido del archivo
 ```

 FILE: tests/test_plan.md

 ```markdown
 contenido del archivo
 ```

 Si el entorno permite crear archivos, crea físicamente esos directorios y archivos. Si no permite crear archivos, entrega el contenido separado exactamente con el formato `FILE: ruta/del/archivo`.

 ### Estructura Obligatoria del Repositorio

 Debes crear esta estructura mínima:

 ```text
 nombre-del-proyecto/
 ├── README.md
 ├── docs/
 │   ├── propuesta.md
 │   ├── caso_de_uso.md
 │   ├── estructura_repositorio.md
 │   └── plan_de_pruebas.md
 ├── src/
 │   └── main.<ext>
 ├── scripts/
 │   └── run.sh
 └── tests/
    └── test_plan.md
 ```

 ### Archivos que Debes Generar

 #### 1. README.md

 Debe incluir:

 * Título de la actividad.
 * Descripción general.
 * Objetivo de aprendizaje.
 * Lenguajes permitidos:

  * ARM64 Assembly
  * C
  * Python
  * Bash
 * Reglas para mantener el proyecto pequeño.
 * Entregables esperados.
 * Instrucciones para el estudiante.
 * Criterios generales de evaluación.
 * Nota indicando que primero se documenta y luego, opcionalmente, se implementa un prototipo pequeño.

 Usa ejemplos de posibles temas:

 * “Mini Toolkit en ARM64”
 * “Asistente de Estudio en Terminal”
 * “Reporteador de Información del Sistema”
 * “Organizador de Archivos”
 * “Juego de Aprendizaje en Línea de Comandos”

 #### 2. docs/propuesta.md

 Debe ser una plantilla que el estudiante llenará.

 Incluye secciones con instrucciones y espacios para completar:

 * Nombre del proyecto.
 * Lenguaje principal elegido.
 * Justificación del lenguaje.
 * Problema o necesidad que atiende.
 * Descripción breve de la solución.
 * Alcance mínimo.
 * Alcance fuera del proyecto.
 * Entradas esperadas.
 * Salidas esperadas.
 * Limitaciones.
 * Riesgos técnicos.
 * Criterios de éxito.

 Aclara que ARM64 Assembly solo debe usarse para programas muy pequeños, por ejemplo:

 * calculadora básica,
 * conversor simple,
 * lectura y escritura mínima en consola,
 * manipulación básica de cadenas o números.

 #### 3. docs/caso_de_uso.md

 Debe ser una plantilla para describir el caso de uso.

 Incluye:

 * Usuario principal.
 * Contexto del usuario.
 * Situación inicial.
 * Flujo principal paso a paso.
 * Flujo alternativo.
 * Errores posibles.
 * Resultado esperado.
 * Ejemplo de uso en terminal.
 * Explicación de por qué el caso de uso es pequeño y viable.

 #### 4. docs/estructura_repositorio.md

 Debe explicar la estructura del repositorio.

 Incluye:

 * Árbol de directorios recomendado.
 * Explicación de cada carpeta.
 * Explicación de cada archivo.
 * Reglas para nombrar archivos.
 * Reglas para evitar desorden.
 * Nota sobre mantener pocos archivos y funciones pequeñas.

 Debe incluir este árbol:

 ```text
 nombre-del-proyecto/
 ├── README.md
 ├── docs/
 │   ├── propuesta.md
 │   ├── caso_de_uso.md
 │   ├── estructura_repositorio.md
 │   └── plan_de_pruebas.md
 ├── src/
 │   └── main.<ext>
 ├── scripts/
 │   └── run.sh
 └── tests/
    └── test_plan.md
 ```

 #### 5. docs/plan_de_pruebas.md

 Debe ser una plantilla sencilla para que el estudiante documente pruebas.

 Incluye:

 * Objetivo del plan de pruebas.
 * Casos de prueba en tabla.
 * Entrada.
 * Resultado esperado.
 * Resultado obtenido.
 * Estado.
 * Pruebas manuales.
 * Pruebas con errores.
 * Pruebas mínimas por lenguaje.
 * Criterios para considerar la práctica terminada.

 No exijas frameworks de testing.

 #### 6. scripts/run.sh

 Debe ser un script Bash simple y seguro que sirva como plantilla.

 Debe:

 * Usar `#!/usr/bin/env bash`.
 * Usar `set -euo pipefail`.
 * Mostrar mensajes claros.
 * Detectar de forma simple si existe algún archivo principal en `src/`.
 * No instalar dependencias.
 * No llamar APIs.
 * No usar red.
 * Incluir comentarios para que el estudiante lo adapte según su lenguaje.

 #### 7. tests/test_plan.md

 Debe ser una versión breve del plan de pruebas, enfocada en checklist.

 Incluye:

 * Checklist de pruebas mínimas.
 * Checklist de documentación.
 * Checklist de ejecución.
 * Checklist de entrega final.

 #### 8. src/main.<ext>

 Debes incluir un archivo placeholder según el lenguaje recomendado por defecto.

 Usa Python como ejemplo por defecto y crea:

 FILE: src/main.py

 ```python
 """
 Archivo inicial de ejemplo.

 El estudiante puede reemplazar este archivo si elige C, Bash o ARM64 Assembly.
 La prioridad de esta actividad es documentar primero la propuesta.
 """

 def main():
    print("Prototipo mínimo del proyecto. Reemplaza este mensaje con tu idea.")

 if __name__ == "__main__":
    main()
 ```

 ### Restricciones

 * No uses frameworks.
 * No uses bases de datos.
 * No uses Docker.
 * No uses servicios en la nube.
 * No uses APIs externas.
 * No incluyas dependencias complejas.
 * No hagas proyectos grandes.
 * No generes solamente un README.
 * No pongas todo en un solo archivo.
 * No uses inglés salvo nombres técnicos inevitables.
 * No inventes credenciales, llaves API, tokens ni datos personales.
 * Mantén el contenido apto para estudiantes principiantes o intermedios.

 ### Criterios de Calidad

 Antes de finalizar, revisa que:

 1. Existan varios archivos separados.
 2. Exista el directorio `docs/`.
 3. Exista el directorio `scripts/`.
 4. Exista el directorio `tests/`.
 5. Exista el directorio `src/`.
 6. La actividad esté lista para GitHub Classroom.
 7. El estudiante pueda completar la propuesta sin depender de herramientas externas.
 8. El proyecto sea pequeño y viable.
 9. Todo esté en español mexicano.
 10. La salida esté en formato plaintext forzado con encabezados `FILE:`.

 ### Salida Esperada

 Entrega únicamente los archivos del repositorio usando el formato `FILE: ruta/del/archivo`.

 No agregues explicación antes ni después.
 No agregues comentarios fuera de los archivos.
 No generes un solo archivo Markdown.
 No omitas directorios.
 No omitas archivos obligatorios.

	### Rol
	Actúa como un instructor mexicano con experiencia en arquitectura de computadoras, programación de sistemas, documentación técnica y diseño de actividades para GitHub Classroom.

	### Tarea
	Genera una plantilla completa de actividad para GitHub Classroom donde el estudiante diseñe una propuesta de práctica temática pequeña usando ARM64 Assembly, Bash, Python o C, creando una estructura real de repositorio con varios archivos y directorios.

	### Contexto
	- Idioma obligatorio de toda la salida: español mexicano.
	- Tono: claro, académico, directo y entendible para estudiantes.
	- Alcance del repositorio: proyecto completo.
	- No existe plantilla inicial en GitHub Classroom.
	- El docente publicará esta actividad en GitHub Classroom.
	- El estudiante será quien complete la propuesta.
	- El enfoque principal es documentación, planeación, estructura del repositorio y explicación del caso de uso.
	- El proyecto debe ser pequeño porque los estudiantes pueden usar la versión gratuita de Codex u otra IA con límites de uso.
	- Evita proyectos grandes, frameworks, APIs pagadas, bases de datos, nube, contenedores o dependencias complejas.
	- ARM64 Assembly debe recomendarse solo para programas muy pequeños.
	- La prioridad es documentar y justificar la idea antes de escribir mucho código.

	### Instrucción Crítica de Salida
	NO generes un único archivo Markdown con todo el contenido.

	Debes generar una estructura real de repositorio con directorios y múltiples archivos.

	La salida debe estar en formato plaintext forzado, usando bloques por archivo de esta forma exacta:

	FILE: README.md
	```markdown
	contenido del archivo
	````

	FILE: docs/propuesta.md

	```markdown
	contenido del archivo
	```

	FILE: docs/caso_de_uso.md

	```markdown
	contenido del archivo
	```

	FILE: docs/estructura_repositorio.md

	```markdown
	contenido del archivo
	```

	FILE: docs/plan_de_pruebas.md

	```markdown
	contenido del archivo
	```

	FILE: scripts/run.sh

	```bash
	contenido del archivo
	```

	FILE: tests/test_plan.md

	```markdown
	contenido del archivo
	```

	Si el entorno permite crear archivos, crea físicamente esos directorios y archivos. Si no permite crear archivos, entrega el contenido separado exactamente con el formato `FILE: ruta/del/archivo`.

	### Estructura Obligatoria del Repositorio

	Debes crear esta estructura mínima:

	```text
	nombre-del-proyecto/
	├── README.md
	├── docs/
	│ ├── propuesta.md
	│ ├── caso_de_uso.md
	│ ├── estructura_repositorio.md
	│ └── plan_de_pruebas.md
	├── src/
	│ └── main.<ext>
	├── scripts/
	│ └── run.sh
	└── tests/
	└── test_plan.md
	```

	### Archivos que Debes Generar

	#### 1. README.md

	Debe incluir:

	* Título de la actividad.
	* Descripción general.
	* Objetivo de aprendizaje.
	* Lenguajes permitidos:

	* ARM64 Assembly
	* C
	* Python
	* Bash
	* Reglas para mantener el proyecto pequeño.
	* Entregables esperados.
	* Instrucciones para el estudiante.
	* Criterios generales de evaluación.
	* Nota indicando que primero se documenta y luego, opcionalmente, se implementa un prototipo pequeño.

	Usa ejemplos de posibles temas:

	* “Mini Toolkit en ARM64”
	* “Asistente de Estudio en Terminal”
	* “Reporteador de Información del Sistema”
	* “Organizador de Archivos”
	* “Juego de Aprendizaje en Línea de Comandos”

	#### 2. docs/propuesta.md

	Debe ser una plantilla que el estudiante llenará.

	Incluye secciones con instrucciones y espacios para completar:

	* Nombre del proyecto.
	* Lenguaje principal elegido.
	* Justificación del lenguaje.
	* Problema o necesidad que atiende.
	* Descripción breve de la solución.
	* Alcance mínimo.
	* Alcance fuera del proyecto.
	* Entradas esperadas.
	* Salidas esperadas.
	* Limitaciones.
	* Riesgos técnicos.
	* Criterios de éxito.

	Aclara que ARM64 Assembly solo debe usarse para programas muy pequeños, por ejemplo:

	* calculadora básica,
	* conversor simple,
	* lectura y escritura mínima en consola,
	* manipulación básica de cadenas o números.

	#### 3. docs/caso_de_uso.md

	Debe ser una plantilla para describir el caso de uso.

	Incluye:

	* Usuario principal.
	* Contexto del usuario.
	* Situación inicial.
	* Flujo principal paso a paso.
	* Flujo alternativo.
	* Errores posibles.
	* Resultado esperado.
	* Ejemplo de uso en terminal.
	* Explicación de por qué el caso de uso es pequeño y viable.

	#### 4. docs/estructura_repositorio.md

	Debe explicar la estructura del repositorio.

	Incluye:

	* Árbol de directorios recomendado.
	* Explicación de cada carpeta.
	* Explicación de cada archivo.
	* Reglas para nombrar archivos.
	* Reglas para evitar desorden.
	* Nota sobre mantener pocos archivos y funciones pequeñas.

	Debe incluir este árbol:

	```text
	nombre-del-proyecto/
	├── README.md
	├── docs/
	│ ├── propuesta.md
	│ ├── caso_de_uso.md
	│ ├── estructura_repositorio.md
	│ └── plan_de_pruebas.md
	├── src/
	│ └── main.<ext>
	├── scripts/
	│ └── run.sh
	└── tests/
	└── test_plan.md
	```

	#### 5. docs/plan_de_pruebas.md

	Debe ser una plantilla sencilla para que el estudiante documente pruebas.

	Incluye:

	* Objetivo del plan de pruebas.
	* Casos de prueba en tabla.
	* Entrada.
	* Resultado esperado.
	* Resultado obtenido.
	* Estado.
	* Pruebas manuales.
	* Pruebas con errores.
	* Pruebas mínimas por lenguaje.
	* Criterios para considerar la práctica terminada.

	No exijas frameworks de testing.

	#### 6. scripts/run.sh

	Debe ser un script Bash simple y seguro que sirva como plantilla.

	Debe:

	* Usar `#!/usr/bin/env bash`.
	* Usar `set -euo pipefail`.
	* Mostrar mensajes claros.
	* Detectar de forma simple si existe algún archivo principal en `src/`.
	* No instalar dependencias.
	* No llamar APIs.
	* No usar red.
	* Incluir comentarios para que el estudiante lo adapte según su lenguaje.

	#### 7. tests/test_plan.md

	Debe ser una versión breve del plan de pruebas, enfocada en checklist.

	Incluye:

	* Checklist de pruebas mínimas.
	* Checklist de documentación.
	* Checklist de ejecución.
	* Checklist de entrega final.

	#### 8. src/main.<ext>

	Debes incluir un archivo placeholder según el lenguaje recomendado por defecto.

	Usa Python como ejemplo por defecto y crea:

	FILE: src/main.py

	```python
	"""
	Archivo inicial de ejemplo.

	El estudiante puede reemplazar este archivo si elige C, Bash o ARM64 Assembly.
	La prioridad de esta actividad es documentar primero la propuesta.
	"""

	def main():
	print("Prototipo mínimo del proyecto. Reemplaza este mensaje con tu idea.")

	if __name__ == "__main__":
	main()
	```

	### Restricciones

	* No uses frameworks.
	* No uses bases de datos.
	* No uses Docker.
	* No uses servicios en la nube.
	* No uses APIs externas.
	* No incluyas dependencias complejas.
	* No hagas proyectos grandes.
	* No generes solamente un README.
	* No pongas todo en un solo archivo.
	* No uses inglés salvo nombres técnicos inevitables.
	* No inventes credenciales, llaves API, tokens ni datos personales.
	* Mantén el contenido apto para estudiantes principiantes o intermedios.

	### Criterios de Calidad

	Antes de finalizar, revisa que:

	1. Existan varios archivos separados.
	2. Exista el directorio `docs/`.
	3. Exista el directorio `scripts/`.
	4. Exista el directorio `tests/`.
	5. Exista el directorio `src/`.
	6. La actividad esté lista para GitHub Classroom.
	7. El estudiante pueda completar la propuesta sin depender de herramientas externas.
	8. El proyecto sea pequeño y viable.
	9. Todo esté en español mexicano.
	10. La salida esté en formato plaintext forzado con encabezados `FILE:`.

	### Salida Esperada

	Entrega únicamente los archivos del repositorio usando el formato `FILE: ruta/del/archivo`.

	No agregues explicación antes ni después.
	No agregues comentarios fuera de los archivos.
	No generes un solo archivo Markdown.
	No omitas directorios.
	No omitas archivos obligatorios.
No results found