Bloque 0: Entorno de Desarrollo y Control de Versiones

En un equipo de ingeniería, un resultado solo tiene valor si otro miembro del equipo puede reproducirlo en su máquina y auditar cómo se ha obtenido. Este bloque establece las dos condiciones que lo hacen posible y sobre las que se apoya el resto del programa: un entorno de dependencias determinista y un flujo de trabajo basado en control de versiones y revisión de código.

Itinerario del Programa

El itinerario completo del programa, su secuencia y la regla de integración entre bloques se definen en el README.md de la raíz del repositorio.

Material de Referencia

1. Modelo de datos de Git: Complete los módulos base de Learn Git Branching. La herramienta representa el historial como un grafo dirigido de commits, lo que permite razonar sobre ramas, fusiones y rebases antes de ejecutarlos sobre un repositorio real.
2. Ciclo de vida de un Pull Request: Ejecute el procedimiento de First Contributions: bifurcación, rama, commit, publicación y solicitud de integración.
3. Gestión de dependencias: Estudie la guía de inicio de uv y la guía de gestión de proyectos. uv resuelve las dependencias declaradas en pyproject.toml y las fija con versiones exactas en uv.lock, de modo que todos los miembros del equipo ejecutan el código sobre el mismo entorno.

Convenciones de Trabajo

Estas convenciones son de aplicación obligatoria en todos los bloques y tareas del programa.

• Ramas: una rama por bloque, creada desde main actualizada, con la nomenclatura feat/bXX-descripcion (p. ej., feat/b01-eda). No se realizan commits directos sobre main.
• Integración: todo cambio llega a main mediante un Pull Request que complete la plantilla .github/pull_request_template.md y cuente con la aprobación del responsable de tutoría. Tras la integración, actualice su copia local con git switch main && git pull.
• Dependencias: se gestionan exclusivamente con uv (uv add, uv sync). Queda prohibido el uso de pip install.
• Ejecución: todo el código se ejecuta desde la raíz del repositorio mediante uv run.
• Semillas aleatorias: toda operación estocástica fija random_state=42.
• Confidencialidad: los datos (data/), los modelos serializados (models/), los entornos virtuales y las credenciales no se versionan en ningún caso.
• Commits: mensajes en modo imperativo que describan el cambio (p. ej., Añade script de limpieza de datos).

Directivas Técnicas Obligatorias

• Intérprete de comandos: todos los comandos de este programa se documentan y validan en bash. Los usuarios de macOS deben configurar bash como intérprete por defecto de su terminal integrada (el sistema utiliza zsh por defecto). Los usuarios de Windows deben operar desde WSL2.

Actividad Práctica

1. Genere su repositorio de trabajo a partir de esta plantilla (opción Use this template de GitHub) y clónelo localmente.
2. Configure su identidad de Git (user.name y user.email) con los datos de su cuenta de GitHub. Todos los commits deben ser atribuibles a su cuenta.
3. Instale uv siguiendo la documentación oficial.
4. Cree la rama feat/b00-entorno.
5. Fije la versión de Python del proyecto con uv python pin 3.12. El comando genera el archivo .python-version.
6. Ejecute uv sync. El comando crea el entorno virtual .venv/ a partir de las dependencias declaradas en pyproject.toml y genera el archivo de bloqueo uv.lock.
7. Verifique el entorno con uv run python -c "import pandas, sklearn; print(pandas.__version__, sklearn.__version__)".
8. Confirme los archivos .python-version y uv.lock. Compruebe con git status que .venv/ no aparece como archivo pendiente (está excluido por .gitignore).
9. Publique la rama y abra un Pull Request hacia main, incluyendo la salida del comando de verificación del paso 7. Solicite la revisión del responsable de tutoría.

Criterios de Aceptación

• uv.lock y .python-version están versionados; .venv/ no lo está.
• Un clon limpio del repositorio reproduce el entorno completo con un único uv sync.
• Los commits están atribuidos a su cuenta de GitHub.
• La plantilla del Pull Request está completa; los puntos que no aplican a este bloque se marcan como N/A.

Transición al Bloque 1

Con un entorno reproducible y un flujo de revisión operativo, el Bloque 1 incorpora los primeros datos y las primeras dependencias adicionales (uv add), ejercitando por primera vez el ciclo completo establecido en este bloque.