
### 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.



