🧠 Objetivo 0: Mecánica de la asignatura + idea para trabajar

🎯 DE UN VISTAZO

• Objetivo Principal: Formular un problema del mundo real (con lógica de negocio no trivial y desplegable en la nube) y configurar el entorno de trabajo en GitHub con SSH.
• Entregables: PR en repositorio propio (README.md + foto de tarjeta + .gitignore + LICENSE) y PR en repositorio de la asignatura (proyectos/objetivo-0.md en formato v0.0.z).
• Carácter: ⚠️ BLOQUEANTE (Requisito obligatorio para superar la asignatura en convocatoria ordinaria).
• Plazos: Entrega: 1 semana. Superación: 2 semanas.
• Formato de entrega: URL del Pull Request (PR), nunca de la rama ni de un commit.

📋 Lista de Tareas Paso a Paso

Fase 1: Configuración del Entorno y Herramientas (Prerrequisitos)

• Paso 1.1: Completar la equivalencia de nombre real, nick de GitHub y nick de Telegram en la hoja de cálculo compartida.
• Paso 1.2: Configurar par de claves SSH en GitHub (no usar HTTPS).
• Paso 1.3: Configurar nombre y correo en Git local (git config user.name y git config user.email). (Opcional: usar email/nombre anónimo).
• Paso 1.4: Personalizar el avatar de GitHub (evitar el avatar por defecto).
• Paso 1.5: Instalar el plugin de Git de la asignatura (git-iv): seguir instrucciones en git-iv.

Fase 2: Definición del Problema y Juego de Rol

• Paso 2.1: Asistir a la primera clase y participar en el juego de rol / design thinking (o imprimir y rellenar la tarjeta a mano con alguien de tu entorno si no pudiste asistir).
• Paso 2.2: Tomar una fotografía a la tarjeta física del juego de rol.
• Paso 2.3: Formular un problema que:
  • Tenga entidad suficiente para requerir despliegue en la nube.
  • Tenga lógica de negocio sustancial (acciones como: calcular, generar, extraer, resumir, filtrar complejo, validar, analizar).
  • ❌ NO sea un CRUD simple (solo almacenar, buscar, dar de alta, borrar).
  • ❌ NO tenga dependencia externa fuerte de APIs de terceros para cada petición del usuario.

Fase 3: Creación del Repositorio Propio y PR Local

• Paso 3.1: Crear el repositorio del proyecto en GitHub.
• Paso 3.2: Crear una rama de trabajo con git iv objetivo 0.
• Paso 3.3: Crear y redactar el fichero README.md describiendo exclusivamente el problema a resolver.
• Paso 3.4: Añadir la fotografía de la tarjeta al repositorio (git add imagen.jpg, commit y push) y enlazarla en README.md con ruta relativa: ![Fotografía de la tarjeta de rol](nombre_de_la_imagen.jpg).
• Paso 3.5: Incluir fichero de Licencia libre (LICENSE) y .gitignore. (La documentación de configuración adicional debe ir en ficheros aparte enlazados desde el README).
• Paso 3.6: Crear un Pull Request en tu propio repositorio desde tu rama hacia main. NO FUSIONAR hasta que el profesor lo apruebe explícitamente.

Fase 4: Entrega en el Repositorio de la Asignatura

• Paso 4.1: Hacer fork/clone del repositorio de la asignatura e iniciar una rama específica para el objetivo 0.
• Paso 4.2: Editar proyectos/objetivo-0.md añadiendo en tu fila:
  • Nombre del proyecto
  • Enlace al PR de tu propio repositorio
  • Versión con semver: v0.0.z (donde z es el patchlevel, p. ej. v0.0.1).
• Paso 4.3: Crear un Pull Request al repositorio de la asignatura.
  • ⚠️ Título del PR: Debe incluir obligatoriamente la cadena [IV-26-27].
• Paso 4.4: Comprobar los tests automáticos (tardan menos de 1 minuto). Si fallan, corregir en la misma rama.
• Paso 4.5: Cuando el profesor revise o apruebe, atender comentarios mediante commits en la rama. Al finalizar cambios, solicitar revisión de nuevo etiquetando al profesor.

⚠️ Requisitos Clave y Reglas de Evaluación

❗ CRITERIOS Y CARÁCTER BLOQUEANTE DEL OBJETIVO 0

• La entrega y superación de este objetivo dentro de los plazos (entrega: 1 semana, superación: 2 semanas) es imprescindible para aprobar la asignatura en convocatoria ordinaria.
• En caso de no superarlo a tiempo, no se podrá aprobar en la ordinaria, aunque se podrá seguir trabajando para la convocatoria extraordinaria.

⚠️ INTEGRIDAD ACADÉMICA Y PROHIBICIÓN DE IA GENERATIVA / PLAGIO

• El planteamiento del problema debe ser personal e individual.
• Está prohibido usar IA generativa para redactar el problema o la documentación.
• Está prohibido el plagio o copiar las soluciones de otros compañeros. El plagio invalidará automáticamente la entrega sin retroalimentación.

ℹ️ REGLAS DE GESTIÓN DE PRS

• Nunca cierres un PR: Toda corrección se hace añadiendo commits a la rama del PR.
• Fusionar solo tras aprobación explícita: No fusiones el PR en tu repo hasta que el profesor lo apruebe.
• Formato de versión: Mantener v0.0.z para este objetivo (ej. v0.0.1, v0.0.2 al corregir).

🔍 Lista de Auto-comprobación (Antes de Entregar)

Antes de enviar la URL de tu PR, verifica cada uno de estos puntos:

• ¿Es un problema real del que tengo conocimiento personal o interés?
• ¿Requiere para su solución el despliegue de una aplicación en la nube?
• ¿La solución requiere lógica de negocio (procesamiento/cálculo) y NO es solo almacenamiento/búsqueda (CRUD)?
• ¿He incluido la licencia libre y el fichero .gitignore?
• ¿He subido al repo y enlazado correctamente la foto de la tarjeta del juego de rol en el README.md?
• ¿He enviado el URL del Pull Request (PR) y no el de la rama ni el de un commit?
• ¿El título de mi PR en el repo de la asignatura incluye [IV-26-27]?
• ¿He usado el formato de versión semántica v0.0.z en proyectos/objetivo-0.md?

? Encuesta

Por favor, contesta esta encuesta si has usado esta versión.

📖 Contexto y Teoría Completa

Para consultar las explicaciones teóricas detalladas, la motivación completa y la metodología original, consulta la Documentación Original de 0.Repositorio.md.