====== 01 - La Forja: la app existe antes de escribir código ======

La Forja todavía no es un programa: es una idea que hay que especificar. Antes de escribir una línea de Java (la app nace en el paso 02), hay que decidir **qué** tiene que hacer y **cómo** se le va a hacer, con las herramientas del tema: el modelo **Entrada - Proceso - Salida**, diagramas de flujo con **PlantUML** y **pseudocódigo**.

===== 1. Qué será la aplicación =====

La Forja es la aplicación interna del **Gremio de Héroes**:

  * **Registrar héroes**: nombre, clase (guerrero, mago, arquero) y nivel inicial.
  * **Consultar** la plantilla y la ficha de un héroe, con su **poder de combate**.
  * **Gestionar la forja**: el almacén de **ítems** (armas, pociones, armaduras) del gremio.
  * **Equipar** a un héroe con un ítem de la forja.
  * Su versión final, mucho más adelante, será una **API REST**; pero eso no cambia el análisis: el algoritmo del menú es el mismo aunque cambie quién lo ejecuta.

Hoy solo se entrega la parte del gremio (registrar, listar, buscar): la forja y el equipado quedan para cuando la app sepa de objetos.

===== 2. Entrada - Proceso - Salida =====

Primer análisis: clasificar cada acción en las tres fases del modelo.

^ Fase ^ En La Forja ^
| **Entrada** | opciones del menú, datos de un héroe (nombre, clase, nivel) |
| **Proceso** | registrar héroe, buscar por nombre, calcular poder |
| **Salida** | listado de la plantilla, ficha del héroe, mensajes de confirmación o aviso |

===== 3. El encargo =====

  * Completar el análisis **IPO**: repasar la tabla y añadir las acciones que faltan — entre otras, todo lo que puede salir mal (un dato inválido, una búsqueda fallida, plazas agotadas).
  * Dibujar los **diagramas de flujo**: el bucle del menú y el recorrido de una acción que tenga decisiones (el registro sirve de caso representativo).
  * Escribir el **pseudocódigo** equivalente, con las tres estructuras de control y sin detalles de Java (aún no se sabe ninguno).
  * Documentar las decisiones: qué se considera un dato válido y qué se muestra en cada caso.

===== 4. Con qué =====

  * La sintaxis de **PlantUML** y las convenciones del pseudocódigo están en el tema 01.
  * El material de hoy es papel (o diagrama y texto): hoy no existe ni compilador.

===== 5. Decisiones tuyas =====

  * ¿Qué acciones del menú son imprescindibles hoy y cuáles se dejan para la siguiente versión?
  * ¿Qué le pedimos al usuario y en qué orden? ¿Confirmamos antes de guardar?
  * ¿Qué es un dato válido y qué no (nombre vacío, clase sin sentido, nivel fuera de rango...)? ¿Y dónde se comprueba: al leerlo, al ejecutar la acción o al guardarlo?
  * ¿Qué se muestra en cada caso: acierto, aviso de datos, error de plazas, despedida?

===== 6. Comprobación =====

  * Los diagramas no dejan callejones: toda decisión conduce a un aviso o a una continuación, y el menú siempre vuelve.
  * El pseudocódigo usa de forma reconocible las tres estructuras: el menú como **iterativa** con ramas condicionales, cada acción como **secuencial** con sus validaciones.
  * Ejecutarlo a mano con un guion (dos registros, un listado, una búsqueda acertada y una fallida) produce los mismos mensajes que se prometen.
  * El de al lado puede seguir el pseudocódigo sin preguntar cómo funciona un gremio: nombres y mensajes se explican solos.

===== 7. Pendientes =====

  * El diseño dice *qué* guardar, pero no *cuánto*: la versión con arrays de 02 pondrá el primer techo artificial.
  * El paso 02 traduce este diseño a Java con lo poco que se sabe por entonces: variables, la clase **IO**, selección, bucles, arrays y funcio