Durante diez módulos has tenido un ejemplo guiado: Nómada Tareas se construía delante de ti, lección a lección, y cada concepto nuevo llegaba con su trozo de código ya pensado. Eso se acaba aquí. En este módulo construyes tu propio producto, solo, con el mismo método y sin que nadie te dé el código. Nómada Tareas no desaparece: pasa a ser la referencia —seis tareas, 48 horas, reglas R1–R10, 124 pruebas, 58,3 kB en tres peticiones, LCP de 1,9 s— contra la que compararás lo que hagas. Y esta primera lección no escribe ni una línea de lógica de negocio a propósito, porque el error más caro de un proyecto propio no es un undefined inesperado: es empezar a programar sin saber qué se está construyendo. Aquí aprenderás a convertir una idea en un plan defendible: elegir el producto, recortarlo hasta un MVP honesto y escribir en negro sobre blanco lo que no vas a hacer; redactar historias de usuario con criterios de aceptación y priorizarlas con MoSCoW; diseñar el modelo de datos y las reglas de negocio —las nuevas R11 a R15— antes de tocar el editor; decidir la arquitectura por capas y las fronteras que no se cruzan; montar el repositorio, la cadena de herramientas y el flujo de Git; planificar en hitos con un Gantt y una estimación que no te mientas a ti mismo; y fijar desde el minuto cero la Definición de Hecho y el presupuesto de rendimiento y accesibilidad. Al terminar tendrás tres entregables reales: el documento de alcance, el modelo de datos con sus reglas, y un repositorio inicializado y verde.

1. Qué cambia a partir de ahora
2. El producto por defecto: Órbita
3. Tres alternativas de dominio con el mismo método
4. Delimitar el alcance: el MVP
5. La lista de lo que NO se hará
6. Historias de usuario con criterios de aceptación
7. Priorizar con MoSCoW
8. El modelo de datos, escrito antes de programar
9. Las reglas de negocio nuevas: R11 a R15
10. La arquitectura por capas y las fronteras que no se cruzan
11. El entorno: repositorio y cadena de herramientas
12. La estructura de carpetas de partida
13. Git en serio: ramas, commits y revisiones
14. Hitos y estimación honesta
15. La Definición de Hecho
16. El presupuesto de rendimiento y accesibilidad
17. La plantilla de README.md
18. Errores Comunes y Consejos
19. Ejercicios
20. Conclusión

Hasta la lección 10-06, el curso funcionaba así: se explicaba un concepto, se aplicaba a Nómada Tareas, y el código aparecía. Tú lo leías, lo entendías, lo adaptabas en los ejercicios. Es la forma correcta de aprender los fundamentos, y es exactamente lo que había que hacer.

Pero hay una diferencia enorme entre entender código ajeno y producir código propio desde cero, y no se salva leyendo más. Se salva construyendo. Este módulo es esa construcción.

A partir de aquí cambian tres cosas:

Ese último punto merece énfasis. La habilidad que separa a quien sabe JavaScript de quien es desarrollador no es conocer más métodos de array: es terminar cosas. Terminar significa que funciona, que está probado, que se puede desplegar, que otra persona lo entiende y que tú puedes defender por qué está hecho así. Ese es el listón de este módulo.

Y hay una advertencia honesta que conviene leer despacio. La parte difícil de un proyecto propio no es técnica. Es que nadie te dice cuándo has terminado, nadie corrige tu alcance cuando crece, y nadie te avisa de que llevas tres días puliendo una animación mientras la funcionalidad principal sigue a medias. El método de esta lección existe precisamente para poner esas barandillas antes de que las necesites.

El producto por defecto de este módulo se llama Órbita. Es una aplicación de gestión de trabajo para equipos pequeños: la misma familia que Nómada Tareas, pero claramente más ambiciosa, con seis extensiones que en el curso nunca se implementaron y que tendrás que resolver por tu cuenta.

Nota sobre los datos. Órbita, sus usuarios de ejemplo y cualquier organización que aparezca en tus datos de prueba deben ser ficticios. No uses nombres, correos ni datos reales de compañeros, clientes o familiares, ni siquiera «para probar»: en cuanto eso llega a un repositorio público o a un despliegue, deja de ser una prueba y pasa a ser un tratamiento de datos personales. En la lección 11-03 y en la 11-05 volveremos sobre este punto con detalle.

Las seis extensiones sobre Nómada Tareas son estas:

Ninguna de las seis es decorativa. Cada una obliga a resolver un problema real que Nómada Tareas esquivaba:

• E1 rompe la simplificación de responsable: 'Iván'. En cuanto hay entidades referenciadas, aparecen la integridad referencial (¿qué pasa con las tareas de un usuario que se borra?) y los permisos.
• E2 convierte una lista plana en un árbol. Todo lo que era array.filter(...) pasa a necesitar recorrido recursivo, y las horas totales dejan de ser una suma directa.
• E3 parece trivial y no lo es: combinar N filtros con dos semánticas distintas y mantenerlos en la URL (06-04, enrutador) exige pensar el estado.
• E4 es la primera vista que no es una lista, y por tanto la primera que no puedes resolver copiando TableroVista.
• E5 es la primera funcionalidad que produce un fichero, con todo lo que eso implica: formato, codificación, nombres, y el hecho de que un CSV mal escapado rompe en cuanto un título lleva una coma.
• E6 introduce datos inmutables y crecientes, que es exactamente el tipo de dato que hace estallar localStorage (lección 11-03).

Órbita en una frase, que es como deberías poder describir cualquier producto:

Órbita es una aplicación web que permite a un equipo pequeño planificar su trabajo en tareas y subtareas, ver quién está sobrecargado y cuándo vencen las cosas, y saber en todo momento quién cambió qué.

Si no puedes escribir esa frase para tu producto, todavía no sabes qué estás construyendo.

Si el dominio de las tareas te aburre —es una razón perfectamente legítima; vas a pasar semanas con esto—, elige otro. El método es idéntico y el módulo entero funciona igual. Estas son las tres alternativas propuestas, cada una con el mapeo de las seis extensiones:

Fíjate en la última fila: cada dominio tiene una regla dura característica que es la que da personalidad al modelo y la que más pruebas va a necesitar. En Aforo es el solapamiento de intervalos, que es un problema clásico y bastante más sutil de lo que parece. En Racha es la unicidad por día, que obliga a pensar zonas horarias. En Estantería es una invariante numérica que hay que defender en todas las operaciones.

Criterio para elegir, en orden de importancia:

1. Que te importe. Vas a dedicarle muchas horas y nadie te va a obligar. La motivación es un recurso de proyecto tan real como el tiempo.
2. Que puedas enseñárselo a alguien. Si en una entrevista puedes explicar el dominio en treinta segundos, sirve.
3. Que tenga al menos una regla dura no trivial. Un CRUD sin reglas no demuestra nada; es el proyecto que hace todo el mundo.
4. Que quepa. Si tu idea es «como Jira pero mejor», no cabe. Recórtala hasta que quepa, que es justo el apartado siguiente.

En el resto del módulo usaré Órbita en todos los ejemplos, pero cada plantilla es directamente reutilizable con cualquiera de los otros tres dominios. Cuando veas una tabla o una plantilla, sustituye los nombres y sigue.

MVP son las siglas de Minimum Viable Product: producto mínimo viable. Las dos palabras importan y casi siempre se entiende mal una de las dos.

• Mínimo no significa «cutre». Significa que no hay nada que puedas quitar sin que deje de resolver el problema.
• Viable no significa «una demo». Significa que alguien podría usarlo de verdad para lo que promete.

Un MVP de Órbita que no permitiera marcar una tarea como hecha sería mínimo pero no viable. Uno que tuviera temas de color, atajos de teclado personalizables y notificaciones por correo sería viable pero no mínimo.

La prueba que uso para decidir si algo entra en el MVP es una sola pregunta:

Si esto no estuviera, ¿el producto seguiría sirviendo para lo que dice su frase?

Si la respuesta es «sí, incómodo pero sirve», no es MVP. Va a la versión 1.1.

Aplicado a Órbita, este es el corte:

De 15 candidatos, 8 entran. Ese ratio (aproximadamente la mitad) es normal y saludable. Si tu MVP contiene el 90 % de lo que se te ha ocurrido, no has recortado: has hecho una lista de deseos.

Una regla práctica de tamaño, contrastada: un MVP de proyecto personal debería ser algo que puedas construir en 6 a 10 semanas dedicándole entre 6 y 10 horas semanales. Si tu estimación honesta (apartado 14) da más, recorta ahora, porque tu estimación es optimista, no pesimista.

Esta es la sección del documento de alcance que más gente se salta y la que más proyectos salva. Un MVP definido solo por lo que incluye es ambiguo: todo lo que no está mencionado queda en una zona gris donde, un martes por la tarde, te parecerá razonable añadir «solo una cosita».

Escribir explícitamente lo que no se hará convierte cada añadido posterior en una decisión consciente en lugar de una deriva.

La plantilla tiene tres columnas y se escribe en docs/alcance.md:

Tres detalles de la plantilla que no son adorno:

• La columna «Por qué» te protege de ti mismo. Dentro de tres semanas no recordarás el razonamiento, solo la tentación.
• «Cuándo se reconsidera» evita el «nunca» rencoroso. Aplazar no es rechazar, y decirlo así hace mucho más fácil aceptar el recorte.
• «No previsto» es una respuesta legítima y conviene usarla sin culpa. No todo aplazado tiene que volver.

Una nota específica sobre la línea de autenticación, porque es un error clásico en proyectos de portafolio: una pantalla de login sin servidor no protege nada. Si los datos están en localStorage, cualquiera con las herramientas de desarrollo los ve. Poner un formulario de contraseña delante es peor que no ponerlo, porque comunica una seguridad que no existe. Si tu proyecto necesita autenticación de verdad, necesita servidor, y eso es la versión 2.0 (lección 11-07).

Una historia de usuario describe una necesidad desde el punto de vista de quien la tiene, no desde el de quien la implementa. Su valor no es el formato bonito: es que te obliga a decir para quién y para qué, y esas dos palabras deciden a menudo el diseño técnico.

La plantilla clásica:

Y lo que de verdad hace útil una historia son sus criterios de aceptación: condiciones verificables que permiten decir «hecho» sin discusión. Se escriben en formato Dado / Cuando / Entonces (Given / When / Then), que tiene una ventaja enorme y nada casual: se traduce casi literalmente a una prueba de las que aprendiste en 08-03 y 08-06.

Aquí tienes tres historias reales de Órbita, completas.

Fíjate en el criterio 2. No dice «no se puede»: dice qué pasa exactamente, con qué mensaje y citando la regla. Esa precisión es la que convierte el criterio en una prueba de Jest de cinco líneas.

Y fíjate en el criterio 3: la accesibilidad está dentro del criterio de aceptación, no en una lista aparte que se revisa al final. Es la única forma de que no se olvide. Volveré sobre esto en el apartado 16 y en la lección 11-02.

El criterio 3 es el que tiene consecuencias arquitectónicas: obliga a que el filtro forme parte del estado de la aplicación y del enrutador (06-04 y el enrutador.js de Nómada Tareas), no a que sea una variable local de la vista. Un criterio de aceptación bien escrito decide diseño.

El criterio 4 es el que más se olvida en proyectos de portafolio: los estados vacíos. Una aplicación que muestra una zona en blanco cuando no hay resultados parece rota aunque funcione perfectamente.

El criterio 4 es el que te va a costar una tarde entera si no lo escribes ahora. La doble contabilización de horas en árboles es uno de esos fallos que no rompe nada visiblemente: solo hace que todos los números estén mal.

Cuántas historias escribir. Para un MVP como este, entre 12 y 18 historias es el orden de magnitud correcto. Menos de 10 suele significar que las historias son demasiado gruesas («como usuario quiero gestionar tareas» no es una historia, es un módulo). Más de 25 suele significar que estás describiendo la implementación en lugar de la necesidad.

Tener historias no basta: hay que saber en qué orden. MoSCoW es un método de priorización simple y sorprendentemente eficaz, cuyo nombre viene de las iniciales de sus cuatro categorías:

La regla del 60 % es la parte importante y la que casi todo el mundo incumple. Si tus Must consumen el 100 % del tiempo disponible, no tienes plan: tienes una apuesta. Cualquier imprevisto —y siempre hay imprevistos— te deja sin entregar. El 40 % restante en Should y Could es tu margen: cuando el tiempo aprieta, se sacrifican sin dolor y el producto sigue siendo entregable.

Priorización completa del MVP de Órbita:

Reparto: Must 57 h (57 %), Should 26 h (26 %), Could 22 h (22 %). Total 105 h. La regla del 60 % se cumple con holgura.

Dos advertencias sobre esta tabla:

• La columna «Depende de» es la que define el orden real. MoSCoW dice qué es importante; las dependencias dicen qué es posible. No puedes hacer H-11 antes que H-05 aunque quieras.
• Las estimaciones son de la lección 14, no salidas de la nada, y ya llevan incorporado el factor de corrección que allí se explica.

Aquí está el consejo más rentable de toda la lección: el modelo de datos se escribe antes que el código, en un documento, y se revisa como se revisa un contrato. Cambiar un campo en un documento cuesta treinta segundos. Cambiarlo cuando ya está en el dominio, en el repositorio, en la vista, en las pruebas y en los datos guardados de los usuarios cuesta una tarde y una migración (lección 11-03).

El modelo de Órbita amplía el de Nómada Tareas con tres entidades nuevas.

Usuario — la entidad nueva más importante, porque cambia el tipo de dos campos que llevabas diez módulos tratando como texto.

Tarea — conserva los ocho campos de Nómada Tareas y añade cuatro:

Cambio — la entidad del historial (E6). Es append-only: se añade, jamás se modifica ni se borra.

Esa última decisión —serializar a texto en lugar de guardar el valor original— es deliberada y conviene entender por qué: una entrada de historial tiene que seguir siendo legible dentro de dos años, cuando el modelo haya cambiado y prioridad quizá ya no exista. Un historial que depende del modelo actual para interpretarse no es un historial: es una copia parcial del estado.

1 · ¿Qué pasa cuando se borra un usuario con tareas asignadas?

Tres opciones, y hay que elegir una explícitamente:

La opción elegida es la tercera, y es la que se usa en casi todo software profesional: el borrado real de entidades referenciadas casi nunca es lo correcto. Esta decisión merece un ADR (lección 11-06).

2 · ¿Las etiquetas son una entidad o un array de textos?

En Nómada Tareas eran un array de textos normalizados (R9). Para el MVP de Órbita se mantienen así, con una función que deriva el catálogo de etiquetas del tablero. Convertirlas en entidad con id propio solo compensa si necesitas renombrar una etiqueta en todas las tareas a la vez, y eso está fuera de alcance.

Anótalo en el documento: una decisión que se toma explícitamente y se justifica no es deuda técnica; es una decisión. Lo que crea deuda es no darse cuenta de que había una elección.

3 · ¿El árbol se guarda anidado o plano con referencia?

La forma plana es la que usan las bases de datos y la que te ahorrará problemas en la lección 11-03. Construir el árbol es una función recursiva de quince líneas (03-07); mantener sincronizada una estructura anidada duplicada es un problema permanente.

Aviso de protección de datos. En cuanto tu modelo contiene nombre de personas, estás modelando datos personales. En un proyecto de aprendizaje con datos ficticios no hay problema legal alguno, pero adquiere el hábito ahora: anota en el documento de alcance qué campos son personales, para qué se usan y cuánto tiempo se conservan. Si algún día este producto tratara datos de personas reales, el RGPD exige base legal, información al interesado, minimización y plazos de conservación — y eso requiere asesoramiento legal específico, no una lección de JavaScript. Volveremos sobre ello en 11-03 y 11-05.

Las reglas R1 a R10 de Nómada Tareas siguen vigentes. Las repaso brevemente porque son la base sobre la que se apoyan las nuevas:

Y estas son las cinco nuevas, que son las que dan carácter a Órbita:

Cinco observaciones sobre estas reglas, porque cada una esconde una decisión:

R11 y la integridad referencial. «Existente y activo» es más fuerte que «existente». Significa que al desactivar un usuario hay que decidir qué pasa con sus asignaciones futuras: la respuesta elegida es que las existentes se conservan (son historia) pero no se pueden crear nuevas. Esa asimetría es intencionada y merece una prueba explícita.

R12 y la suma de las hojas. Es la regla que evita la doble contabilización del criterio 4 de H-11. Su consecuencia práctica: horasEstimadas deja de ser un campo editable en cuanto una tarea tiene hijas, y la interfaz debe reflejarlo (campo deshabilitado con explicación, no campo que acepta un valor que se ignora en silencio).

R13 y el cierre en cascada. Prohibir cerrar una madre con hijas abiertas es lo estricto; permitirlo cerrando las hijas automáticamente es lo cómodo. La regla elegida hace lo estricto por defecto y ofrece la cascada como acción explícita («Cerrar también las 3 subtareas pendientes»). Nunca hagas la cascada en silencio: borrar o cerrar cosas que el usuario no ha mirado es la receta de la desconfianza.

R14 y la inmutabilidad. «Una corrección es una entrada nueva» es el principio contable de toda la vida, y es lo que hace que un historial valga para algo. En cuanto se puede editar, deja de ser prueba de nada.

R15 y la semana ISO. Elegir la semana ISO 8601 (lunes a domingo, con la regla del jueves para la semana 1) en lugar de «los últimos siete días» es una decisión con consecuencias: hay que implementarla bien, y es un caso de prueba precioso porque el 1 de enero cae a veces en la semana 52 del año anterior. Anótalo: será una de tus pruebas parametrizadas de la lección 11-04.

Dónde viven las reglas. Todas, sin excepción, en la capa de dominio. La vista puede anticiparlas para dar buena información al usuario (deshabilitar un botón, avisar antes de enviar), pero la vista nunca es la que decide. Si una regla solo está en el formulario, no existe: basta con llamar al método desde otro sitio para saltársela. Esto es exactamente lo que 06-07 explicaba sobre validación de cliente, y lo mismo que la lección 11-05 repetirá sobre validación de servidor.

Nómada Tareas tenía cuatro carpetas —modelo/, datos/, vista/, util/— y esa organización no era estética: era una arquitectura por capas, con reglas sobre quién puede llamar a quién. Órbita la formaliza con cuatro capas y una capa transversal.

Las cuatro capas, con su responsabilidad y sus prohibiciones:

Las tres fronteras que no se cruzan, y qué te pasa si las cruzas:

1. dominio/ no sabe que existe un navegador. Ni document, ni localStorage, ni fetch, ni alert. Consecuencia práctica inmediata: el dominio se prueba en Node sin jsdom, en milisegundos, y eso es lo que hace posible tener cientos de pruebas rápidas (11-04). Si un día necesitas Date.now() dentro del dominio, se pasa como parámetro o como reloj inyectado — nunca se llama directamente, porque entonces las pruebas dependen de qué día las ejecutes.

2. vista/ no sabe de dónde vienen los datos. Recibe un estado y unas funciones (alCrearTarea, alCambiarEstado) y las llama. No sabe si detrás hay memoria, localStorage o una API. Consecuencia práctica: cambiar el almacenamiento en la lección 11-03 no tocará ni un fichero de vista.

3. datos/ no sabe qué se pinta. Devuelve entidades del dominio o lanza errores tipados. No devuelve HTML, ni mensajes de usuario, ni «cadenas listas para mostrar». Consecuencia práctica: la traducción de un error a un texto amable es responsabilidad de la vista, y por eso el mismo ErrorDeRegla puede mostrarse de tres formas distintas en tres pantallas.

Por qué esta arquitectura, y no otra. Dos referencias del propio curso:

• 05-04 (módulos) enseñó que un import es una dependencia declarada: al escribirlo estás diciendo «esto no funciona sin aquello». Una arquitectura por capas es, literalmente, una regla sobre qué import están permitidos. Y como es una regla mecánica, se puede automatizar: ESLint (08-02) tiene reglas de restricción de importaciones que rompen la compilación si alguien escribe import { guardar } from '../datos/...' dentro de dominio/. Configurarlo es el ejercicio 3.

• 10-06 demostró con datos que dominio/reglas.js fue idéntico en las cuatro versiones de la misma pantalla (JavaScript puro, React, Vue y Angular). Ese hecho es el argumento definitivo: si el dominio no depende de la vista, sobrevive al cambio de vista. Y las vistas cambian. Siempre.

Un apunte de honestidad: para un proyecto de 100 horas, cuatro capas pueden parecer ceremonia. No lo son, por una razón muy concreta: el coste de introducirlas al principio es de una hora; el de introducirlas cuando ya hay 4.000 líneas mezcladas es de una semana. Y en este proyecto en particular las necesitas, porque la lección 11-03 va a sustituir la capa de datos entera y la 11-04 va a probar cada capa con una técnica distinta.

Ahora sí, teclado. El objetivo de este apartado es un repositorio que, al ejecutar un solo comando, verifique todo y salga en verde.

Cada línea, explicada:

• git init -b main crea el repositorio con la rama principal llamada main desde el principio, que es lo que espera GitHub y lo que usará el flujo de despliegue de la lección 11-05.
• vite es el servidor de desarrollo y el empaquetador. Te da recarga instantánea al guardar y, en producción, la compilación con minificación y hashing que verás en 11-05. Es la herramienta que Nómada Tareas usaba desde el Módulo 9.
• ESLint y Prettier separan responsabilidades como explicaba 08-02: ESLint busca errores, Prettier impone formato. eslint-config-prettier desactiva las reglas de ESLint que se pelearían con Prettier.
• Jest con jsdom para unitarias e integración; Testing Library para consultar el DOM por rol y por texto, como una persona (08-05).
• Cypress para los tres recorridos de extremo a extremo (08-06).
• Husky y lint-staged ejecutan las comprobaciones antes de cada commit, sobre los ficheros que estás confirmando. Es la diferencia entre «la CI me avisará» y «no puedo confirmar código roto».

El guion clave es verificar. Es el contrato del proyecto en una línea: lint, formato, pruebas con cobertura y compilación. Es exactamente lo que ejecutará la integración continua (11-04) y lo que debes poder lanzar en cualquier momento para saber si el proyecto está sano. La regla asociada es simple y no admite excepciones:

npm run verificar tiene que estar en verde antes de cada push. Siempre.

El orden de los cuatro pasos no es casual: van de más rápido a más lento, para que el primero que falle sea el más barato de detectar.

Este es el fichero eslint.config.js, y contiene la parte que hace que la arquitectura del apartado 10 se cumpla sola:

Lo que acabas de hacer es importante y merece que lo veas con claridad: has convertido una decisión de arquitectura en una regla automática. A partir de ahora, la frontera no depende de que te acuerdes un viernes por la tarde. Si alguien —tú dentro de tres semanas— escribe import { RepositorioLocal } from '../datos/repositorio-local.js' dentro de dominio/tarea.js, npm run lint falla, el commit se rechaza y la CI se pone en rojo.

Las arquitecturas que no se pueden verificar automáticamente se erosionan siempre. No es cuestión de disciplina: es cuestión de que nadie recuerda un documento de hace dos meses a las once de la noche.

Dos pasos: formatear y revisar solo los ficheros que estás confirmando (lint-staged), y ejecutar solo las pruebas afectadas (--onlyChanged). Rápido a propósito: un gancho lento es un gancho que acabarás saltándote con --no-verify, y un gancho que se salta no sirve para nada. La suite completa es responsabilidad de la CI.

Tres decisiones de la estructura, con su porqué:

• src/ como raíz del código. Separa el código de la configuración, que en la raíz ya son diez ficheros. Vite lo espera así por defecto.
• docs/ versionado con el código. Si el documento de alcance vive en una nota suelta o en un servicio externo, se desincroniza en dos semanas. Dentro del repositorio, cambia en el mismo commit que el código que refleja.
• test/ fuera de src/, reflejando su estructura. Existe la alternativa de poner las pruebas junto al código (tarea.test.js al lado de tarea.js); las dos funcionan. La ventaja de separarlas es que el build de producción no tiene que excluir nada y la cobertura por capas se lee de un vistazo.

Hasta ahora quizá hayas usado Git como copia de seguridad: git add ., git commit -m "cambios", git push. Funciona hasta que necesitas responder a una de estas preguntas, y entonces no funciona en absoluto:

• ¿Cuándo dejó de funcionar el informe de carga y qué cambio lo rompió?
• ¿Por qué está escrito así este trozo raro que no me atrevo a tocar?
• ¿Puedo deshacer la funcionalidad de subtareas sin deshacer las tres de después?
• ¿Qué entró exactamente en la versión que desplegué el martes?

El historial de Git es documentación que se escribe sola si le dedicas treinta segundos por commit. Estas son las reglas del proyecto.

Una rama por historia de usuario. Nace de main, vive entre unas horas y tres días, y se fusiona.

Convenio de nombres, con el mismo prefijo que los commits:

Por qué cortas. Una rama de tres semanas acumula conflictos, se desincroniza de main y llega un momento en que fusionarla da miedo. Una rama de dos días se fusiona sin pensar. Si una historia no cabe en tres días, la historia es demasiado grande: pártela (H-04 se puede partir en «crear subtarea», «agregar horas» y «regla de cierre R13»).

El formato de Commits Convencionales es un estándar ampliamente adoptado:

Ejemplos reales de este proyecto, del peor al mejor:

Y un commit con cuerpo, que es donde está el valor de verdad:

Nadie escribe esto para lucirse. Se escribe porque dentro de seis meses, cuando el informe vuelva a dar un número raro, este mensaje aparece en git log y te ahorra dos horas. Es el mismo argumento del historial de cambios de la R14, aplicado al código en lugar de a los datos.

La regla de oro del tamaño del commit: si necesitas la palabra «y» para describir lo que hace, son dos commits.

Qué va en la descripción y qué va en el cuerpo:

El qué ya está en el diff. El porqué solo está en tu cabeza, y tu cabeza no se puede consultar dentro de seis meses.

«Reviso mi propio código» suena a teatro. No lo es, si se hace con un procedimiento que fuerce el cambio de perspectiva:

1. Abre una Pull Request contra main, siempre. Aunque la vayas a aprobar tú.
2. Deja pasar tiempo. Idealmente hasta el día siguiente; como mínimo, una hora haciendo otra cosa. La revisión inmediata no ve nada porque tu cabeza todavía rellena los huecos.
3. Lee el diff completo en la interfaz web, no en tu editor. El cambio de contexto visual es sorprendentemente eficaz: verás cosas que en tu editor eran invisibles.
4. Aplica la lista de comprobación del apartado siguiente y escribe los comentarios en la PR, no en un papel.
5. Corrige con commits nuevos en la misma rama, no reescribiendo. Que se vea la corrección.

Lista de comprobación de revisión (la ampliaremos en 11-02 y 11-06):

Y una regla que vale oro cuando alguien más revisa tu código o tú revisas el de otros: critica el código, nunca a la persona. «Esta función hace tres cosas» en lugar de «has hecho un lío». Aplícalo también contigo mismo: el objetivo es un producto mejor, no un juicio.

Todo el mundo estima mal y siempre en la misma dirección: por defecto. La causa está bien estudiada y se llama falacia de la planificación: al estimar imaginamos el camino en el que todo sale bien, porque es el único que podemos imaginar en detalle. Los imprevistos, por definición, no se pueden enumerar.

El método honesto tiene tres pasos:

1. Estima cada historia en horas de trabajo efectivo, suponiendo que no hay interrupciones y que sabes hacerlo.
2. Multiplica por un factor de corrección según lo conocido que te resulte el problema.
3. Añade un 20 % de reserva al total del proyecto para lo que no está en ninguna historia (configurar cosas, arreglar el despliegue, un fallo raro de Jest).

Un ejemplo completo, la historia H-04:

Las 10 horas de la tabla del apartado 7 salen de ahí, no de una intuición.

Total de Órbita: 105 h de historias + 21 h de reserva (20 %) = 126 horas. A 8 horas semanales, unas 16 semanas. Si eso te parece mucho, tienes dos salidas legítimas: dedicarle más horas por semana, o recortar los Could (22 h) y quedarte en 13 semanas. Lo que no es una salida es decidir que en realidad serán 60 horas.

Un hito no es una fecha: es un estado del producto que se puede enseñar. Cada uno termina con algo demostrable.

Dos observaciones sobre el Gantt:

• La reserva aparece en el diagrama. Si la reserva no está dibujada, no existe: se la comerá el primer imprevisto y darás por perdido el plan. Dibujada, es una parte del plan que se está consumiendo, y lo ves.
• Los hitos no se solapan. Es tentador dibujar tareas en paralelo, pero trabajas solo: el paralelismo es una ilusión que solo sirve para que el plan parezca más corto.

Cómo se usa el plan. No como una promesa, sino como un instrumento de medida. Al final de cada semana anota horas dedicadas y historias cerradas. Si al terminar H2 llevas un 40 % más de tiempo del previsto, tu factor de corrección es bajo: súbelo para el resto del plan en vez de esperar recuperar. Recuperar tiempo perdido casi nunca ocurre; ajustar el modelo, sí.

La Definición de Hecho (Definition of Done) responde a una pregunta que parece tonta y no lo es: ¿cuándo está terminada una historia? Sin una respuesta escrita, «hecho» significa «funciona en mi máquina cuando hago lo que espero», y ese es el origen del 80 % de la deuda de un proyecto personal.

Se escribe una vez, al principio, y se aplica a todas las historias sin excepción:

Sí, es larga. Y sí, se cumple, por dos motivos:

1. La mayoría de las casillas las verifica una máquina: npm run verificar cubre siete de ellas. Solo unas pocas exigen que tú hagas algo a mano.
2. Es más barata que la alternativa. Cada casilla de esta lista representa un problema real que aparece si no se comprueba, y todos son más caros de arreglar después.

Un consejo práctico: guárdala como plantilla de Pull Request en .github/pull_request_template.md. Así aparece sola, marcada como lista de tareas, cada vez que abres una PR. Lo que no aparece solo, no se hace.

La lección 09-01 dejó una idea que hay que aplicar ahora, no al final: medir antes de optimizar. Y su corolario, que es lo que hace este apartado: un objetivo sin número no es un objetivo.

Nómada Tareas midió su línea base al final, con la aplicación ya construida, y encontró diez problemas de golpe. Tú vas a hacerlo al revés: fijas el presupuesto ahora, con la aplicación vacía, y la CI lo vigila desde el primer día. La diferencia es enorme: un presupuesto fijado al principio se incumple el día que se rompe, con un solo cambio sospechoso; fijado al final, se incumple por la acumulación de treinta cambios y nadie sabe cuál fue.

La columna de referencia son los números medidos de Nómada Tareas en la lección 09-01 (línea base con 600 tareas, tras las optimizaciones de todo el Módulo 9):

Los presupuestos son algo más laxos que los números de Nómada Tareas, y eso es deliberado: Órbita tiene más pantallas y más funcionalidad. Un presupuesto imposible se ignora a la primera semana; uno alcanzable pero exigente se respeta.

La regla del presupuesto: si un cambio lo incumple, hay tres salidas legítimas — optimizar el cambio, renunciar a la funcionalidad, o subir el presupuesto conscientemente y anotar por qué. La cuarta salida, «lo miro más adelante», es la que produce aplicaciones de 2 MB.

El criterio 9 tiene una consecuencia inmediata en Órbita y conviene verla ahora: la tarea vencida de la R10 no puede destacarse solo en rojo, y la celda sobrecargada de la R7 no puede destacarse solo en ámbar. Las dos necesitan texto o icono con texto alternativo. Si lo sabes ahora, lo diseñas bien; si lo descubres en la revisión de accesibilidad, lo reharás.

Los umbrales 1, 2, 5 y 6 los verifica la máquina. Los demás son manuales y van en la Definición de Hecho. La lección 11-04 monta la automatización completa.

El README.md es lo primero que ve cualquiera que llegue a tu repositorio: un revisor, un reclutador, o tú mismo dentro de un año. Se crea ahora, con huecos, y se rellena a medida que el proyecto avanza. Un README que se escribe el último día se nota, y no se nota bien.

git clone https://github.com//orbita.git cd orbita npm install npm run dev # http://localhost:5173

npm test # unitarias e integración npm run test:cov # con informe de cobertura npm run e2e # recorridos de extremo a extremo npm run verificar # todo lo anterior + lint + build

src/dominio/ Reglas R1-R15. Sin dependencias. Se prueba en Node. src/datos/ Persistencia y red. Una interfaz, tres implementaciones. src/vista/ DOM, eventos y accesibilidad. No sabe de dónde vienen los datos. src/aplicacion/ Casos de uso y estado. Une las tres anteriores.

Las secciones que casi nadie escribe y que más impresionan a quien revisa son «Decisiones técnicas» y «Limitaciones conocidas». La primera demuestra criterio; la segunda demuestra honestidad y conciencia de los límites del propio trabajo, que es exactamente lo que se busca en alguien con quien vas a trabajar. La lección 11-06 desarrolla el README a fondo.

Empezar a programar antes de tener el modelo de datos escrito. Es el error más caro de todos, porque no duele al principio: duele en la semana cuatro, cuando descubres que responsable debía ser una referencia y ya está en veinte sitios. Media hora de documento ahorra dos días de refactorización. Escribe el modelo, léelo en voz alta, y solo entonces abre el editor.

Confundir MVP con «versión cutre». Un MVP tiene menos funcionalidades, no menos calidad. Las que están, están terminadas: probadas, accesibles y con sus estados vacío y de error. Una aplicación con tres funcionalidades impecables demuestra muchísimo más que una con doce a medias — y en una entrevista, la segunda juega en tu contra.

No escribir la lista de lo que NO se hará. Sin esa lista, cada idea nueva parece razonable porque nada dice lo contrario. Con la lista, añadir algo exige tacharlo explícitamente, y ese pequeño acto de fricción filtra el 90 % de las ideas de martes por la tarde.

Estimar en el mejor caso. Tu estimación ingenua es el tiempo que tardarías si todo saliera bien y ya supieras hacerlo. Multiplica por el factor de la tabla del apartado 14 sin negociar contigo mismo, y añade la reserva del 20 %. Un plan que se cumple motiva; uno que se incumple desde la segunda semana se abandona.

Dejar la arquitectura como una intención. «Ya tendré cuidado de no importar datos/ desde dominio/» es una frase que caduca en dos semanas. Configura la regla de ESLint del apartado 11.3 el primer día: convierte tu buena intención en un error de compilación, que es lo único que no se olvida.

Aplazar la accesibilidad a «cuando funcione». Añadir accesibilidad al final es rehacer la mitad de la vista: los <div> pulsables hay que convertirlos en <button>, el foco hay que gestionarlo, los anuncios hay que introducirlos. Hecho desde el principio no cuesta prácticamente nada, porque casi todo se reduce a usar el elemento HTML correcto.

Un README vacío durante meses. Escribe hoy la primera versión, aunque la mitad sean huecos. Cada vez que tomes una decisión, añade una fila a la tabla de decisiones técnicas. Reconstruir el porqué de veinte decisiones el último día es imposible: no las recordarás.

Ramas largas. Una rama de tres semanas es un proyecto paralelo que un día tendrás que reconciliar. Si una historia no cabe en tres días, pártela. Si no sabes cómo partirla, es señal de que no la entiendes bien todavía — y eso también es información valiosa.

Consejo · Escribe el documento de alcance para «el tú de dentro de tres meses». Ese lector no recuerda nada, no tiene contexto y solo tiene diez minutos. Si el documento le sirve, te sirve a ti y le servirá a cualquiera.

Consejo · Fija un día y una hora de trabajo, y protégelos. La causa número uno de abandono de proyectos personales no es la dificultad técnica: es la pérdida de ritmo. Dos sesiones semanales fijas de tres horas rinden muchísimo más que «cuando pueda».

Consejo · Haz el primer despliegue con la aplicación vacía. En el hito H1, antes de escribir lógica. Descubrirás los problemas de configuración cuando no cuestan nada, en lugar de la última semana con todo en juego. Es el mismo principio que la fase piloto de las migraciones de 10-06.

Estos tres ejercicios son el hito H1 de tu proyecto. Al terminarlos tendrás el documento de alcance, el modelo de datos y un repositorio verde: todo lo necesario para empezar a construir en la lección siguiente.

Ejercicio 1 — El documento de alcance.

Crea docs/alcance.md en tu repositorio con estas siete secciones:

1. El producto en una frase (formato del apartado 2): quién lo usa, qué hace, qué problema resuelve.
2. El MVP: la tabla de funcionalidades con la columna «¿MVP?» y su razón. Mínimo 12 candidatas, y al menos 5 con «No».
3. Fuera de alcance: la tabla de tres columnas del apartado 5, con al menos 8 filas.
4. Historias de usuario: entre 12 y 18, con la plantilla Como / quiero / para. Al menos cuatro desarrolladas por completo con criterios Dado / Cuando / Entonces (mínimo 3 criterios cada una), incluyendo al menos un criterio de accesibilidad.
5. Priorización MoSCoW: la tabla del apartado 7 con estimación, hito y dependencias. Verifica la regla del 60 %.
6. Plan de hitos: los seis hitos con su entregable demostrable y su diagrama de Gantt en Mermaid, con la reserva dibujada.
7. Definición de Hecho: adaptada a tu proyecto, con al menos 18 casillas repartidas entre las seis categorías.

Ejercicio 2 — El modelo de datos y las reglas.

Crea docs/modelo-datos.md con:

1. Un diagrama de entidades en Mermaid (erDiagram) con todas tus entidades y sus relaciones.
2. Una tabla por entidad con campo, tipo, si admite null, reglas y una nota justificando el tipo elegido.
3. La tabla de reglas R1–R15 (o las que correspondan a tu dominio, si has elegido otro) con: descripción, capa donde se aplica y error que lanza.
4. Las tres decisiones de modelado del apartado 8.3 aplicadas a tu dominio, cada una con sus alternativas descartadas y el porqué.
5. Un ejemplo completo de datos ficticios en JSON con al menos 8 entidades, incluyendo un caso límite de cada regla nueva.
6. Una sección «Datos personales» que enumere qué campos lo son, para qué se usan y cuánto se conservan.

Ejercicio 3 — El repositorio verde.

Deja el repositorio en el estado exacto del que parte la lección 11-02:

1. Repositorio con main, primer commit convencional y .gitignore correcto (node_modules, dist, .env, coverage, cypress/videos).
2. package.json con los diez guiones del apartado 11.2, incluido verificar.
3. eslint.config.js con las dos fronteras de arquitectura configuradas y comprobadas.
4. .prettierrc, jest.config.js (con testEnvironment: 'jsdom' y umbrales de cobertura) y vite.config.js.
5. Gancho de pre-commit con Husky y lint-staged, verificado con un commit real.
6. La estructura de carpetas del apartado 12, con un .gitkeep en las vacías.
7. Una prueba que demuestre que las fronteras funcionan: escribe src/dominio/prueba-frontera.js con import ... from '../datos/repositorio.js', comprueba que npm run lint falla con tu mensaje personalizado, y bórralo. Documenta el resultado en el ADR-0001.
8. README.md con la plantilla del apartado 17 (los huecos se rellenan luego).
9. npm run verificar en verde.

No hay soluciones en forma de código, porque el proyecto es tuyo. Estas son las rúbricas con las que se evalúa cada entregable. Puntúate honestamente: el objetivo no es la nota, es detectar lo que falta antes de que te cueste caro.

Rúbrica del ejercicio 1 — Documento de alcance (30 puntos)

Umbral de aprobación: 20/30, con al menos 2 puntos en «Recorte del MVP» y en «Historias». Si fallas ahí, todo lo demás se construye sobre arena.

Rúbrica del ejercicio 2 — Modelo de datos (24 puntos)

Señal de alarma inequívoca: si tu tabla de reglas tiene menos de cinco reglas nuevas propias del dominio, tu producto es un CRUD. Añade reglas duras — son lo que hace interesante el dominio, lo que da sentido a las pruebas de 11-04 y lo que se cuenta bien en una entrevista.

Rúbrica del ejercicio 3 — Repositorio (verificación binaria)

Aquí no hay grises: cada punto se cumple o no se cumple.

El punto 10 es el que de verdad importa y el que casi nadie comprueba. Una regla de ESLint mal configurada no falla: simplemente no hace nada, y tú crees que estás protegido durante tres meses. Provoca el error a propósito, comprueba el mensaje, y solo entonces bórralo.

Autoevaluación final del hito H1. Responde con sinceridad antes de pasar a la lección siguiente:

Seis «sí» y puedes seguir. Un solo «no» y merece la pena volver antes de escribir código, porque cada uno de esos «no» se multiplica por semanas de trabajo más adelante.

Has hecho lo que casi nadie hace en un proyecto personal: planificar antes de programar. Y no con un plan decorativo, sino con instrumentos que se van a usar cada semana del módulo.

Sabes que a partir de aquí el código lo escribes tú: Nómada Tareas deja de ser el ejemplo que se te da resuelto y pasa a ser la referencia contra la que comparar, con sus seis tareas, sus 48 horas, sus reglas R1–R10 y sus números medidos. Tienes un producto por defecto —Órbita— con seis extensiones que obligan a resolver problemas que el curso esquivaba: usuarios como entidades, un árbol de subtareas, filtro múltiple, una vista que no es una lista, un informe que produce un fichero y un historial inmutable que crece sin parar. Y tienes tres alternativas de dominio —Aforo, Racha, Estantería— con el mapeo completo de las seis extensiones, porque el método es el mismo y lo que importa es que te importe.

Sabes recortar: el MVP es lo que no puede quitarse sin romper la frase del producto, y la prueba es una sola pregunta. De quince candidatas entraron ocho. Y sabes que la mitad que se queda fuera hay que escribirla, con su porqué y su cuándo se reconsidera, porque una funcionalidad que no está en ninguna lista es una funcionalidad que aparecerá un martes por la tarde.

Sabes escribir historias de usuario que dicen para quién y para qué, con criterios Dado / Cuando / Entonces tan precisos que se traducen en pruebas casi palabra por palabra — incluidos los criterios de accesibilidad, que van dentro de la historia y no en una lista aparte que se revisa al final. Y sabes priorizarlas con MoSCoW respetando la regla del 60 %, que es la que convierte un plan en un plan y no en una apuesta.

Tienes el modelo de datos escrito antes que el código, con su diagrama de entidades, sus tipos justificados y las tres decisiones que había que tomar explícitamente: desactivar usuarios en lugar de borrarlos, etiquetas como texto normalizado, y árbol plano con tareaMadreId en vez de anidado. Y tienes las reglas nuevas R11 a R15 —integridad referencial con usuarios activos, árbol sin ciclos con horas por hojas, cierre bloqueado por subtareas abiertas, historial inmutable, y permisos con carga por semana ISO— viviendo todas en el dominio, porque una regla que solo está en el formulario no existe.

Tienes una arquitectura por capas con tres fronteras que no se cruzan —el dominio no sabe que hay navegador, la vista no sabe de dónde vienen los datos, los datos no saben qué se pinta— y, lo que es más importante, las tienes verificadas por ESLint: has convertido una intención en un error de compilación, que es lo único que no se erosiona. El argumento no es teórico: en 10-06, dominio/reglas.js fue idéntico en las cuatro versiones de la misma pantalla.

Tienes el entorno montado: Vite, ESLint y Prettier, Jest con jsdom y Testing Library, Cypress, Husky y lint-staged, con un guion verificar que resume el contrato del proyecto en una línea y una regla sin excepciones. Tienes Git en serio: ramas cortas por historia, commits convencionales cuyo cuerpo explica el porqué —lo único que el diff no puede contarte dentro de seis meses— y revisiones de tu propio código con distancia, en la interfaz web y con lista de comprobación.

Tienes un plan honesto: 105 horas de historias, factor de corrección por familiaridad, 20 % de reserva dibujada en el Gantt, seis hitos que terminan cada uno en algo que se puede enseñar. Tienes una Definición de Hecho de la que la mayoría de casillas las verifica una máquina, guardada como plantilla de Pull Request para que aparezca sola. Y tienes el presupuesto de rendimiento y accesibilidad fijado al principio, con los números de Nómada Tareas como referencia: ≤ 60 kB, LCP ≤ 2,5 s, ≤ 1.500 nodos, 0 incidencias graves de axe, contraste 4,5:1 y nada comunicado solo por color.

El hito H1 está cerrado: documento de alcance, modelo de datos con sus reglas, y un repositorio que responde en verde. La página está vacía, y eso es exactamente lo correcto, porque ahora sabes qué vas a poner en ella y por qué.

Lo siguiente es ponerlo. Y hay una forma de hacerlo que no es la intuitiva —de dentro hacia fuera, empezando por las reglas y terminando por los píxeles, y una funcionalidad completa antes que todas a medias—: es Construcción del Proyecto.