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.

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.

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

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

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

• ¿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?

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

• 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