La última lección del módulo 9 lo anunció con estas palabras exactas: "queda una única lección, la última del curso: 'Proyecto: Construyendo TaskFlow', donde no se presenta ningún concepto nuevo, sino que se recorre la aplicación de principio a fin". Esa "única lección" es, en realidad, este módulo completo, dividido en cuatro partes por comodidad de lectura, pero pensado como una sola unidad narrativa: el proyecto final. Esta primera parte no escribe todavía ningún componente; traza el mapa completo de TaskFlow tal como ha quedado tras nueve módulos —su árbol de componentes, cómo viajan los datos entre ellos, y la estructura de carpetas final del proyecto— para que las tres lecciones siguientes tengan un plano claro sobre el que construir, en lugar de reconstruir esa imagen de conjunto sobre la marcha.

1. Qué es este módulo y qué no es
2. El árbol de componentes de TaskFlow, completo
3. Responsabilidad de una línea, por componente
4. Flujo de datos: propiedades hacia abajo
5. Flujo de datos: eventos hacia arriba
6. La excepción deliberada: el contexto de filtro
7. Estructura de carpetas final del proyecto
8. De la carpeta a la lección: dónde se explicó cada pieza
9. Hacia la construcción de los componentes

Conviene fijar esto antes de escribir una sola línea de código: este módulo no introduce ningún concepto de Lit que no se haya explicado ya entre los módulos 1 y 9. Plantillas, propiedades reactivas, estilos con Shadow DOM, eventos personalizados, ciclo de vida, controladores, mixins, directivas, contexto compartido, integración con el resto del ecosistema y buenas prácticas: todo eso ya está cubierto. Lo que sí falta, y es exactamente el objetivo de las cuatro lecciones de este módulo, es verlo todo unido, como un único proyecto coherente, en lugar de como una sucesión de fragmentos de código repartidos entre treinta y seis lecciones distintas, cada uno centrado en la técnica que le correspondía explicar en su momento.

Esta primera lección se limita a la planificación: el árbol de componentes final, el flujo de datos que los conecta, y la estructura de carpetas. Las lecciones 10-02 y 10-03 escriben el código completo de cada componente y cada pieza de infraestructura compartida, y la 10-04 cierra con pruebas, empaquetado y el propio cierre del curso.

TaskFlow ha crecido, a lo largo del curso, hasta convertirse en cinco componentes personalizados, organizados en un árbol de cuatro niveles de profundidad:

Ningún componente de este árbol es nuevo: <task-board> apareció en el módulo 5 (05-04) como ancestro común de <task-list>; <user-avatar> en el módulo 4 (04-04), como hijo de <task-card>; y <task-filter>, mencionado desde el propio módulo 5 sin implementar, no cobró vida real hasta el módulo 7 (07-04), de la mano de @lit/context. Lo único que aporta esta lección es dibujar, por fin, el árbol completo de una sola vez, algo que ninguna lección anterior necesitaba hacer porque cada una se centraba en la pieza que estaba construyendo en ese momento.

Cada componente de TaskFlow tiene una responsabilidad que se puede resumir en una sola frase, sin necesidad de enumerar todos los detalles de su implementación:

Esta tabla, aunque parezca trivial, es la prueba de que la descomposición de TaskFlow en cinco piezas, hecha a lo largo del curso, sigue el criterio explicado en la lección "Patrones y Anti-patrones Comunes" (09-04, apartado 6): cada componente cambia por un motivo distinto al de los demás, y ninguno necesita la conjunción "y" para describirse.

El primer eje de comunicación de TaskFlow, establecido desde el módulo 3 y perfeccionado en el módulo 5, es el flujo de propiedades reactivas de un componente hacia sus hijos directos en la plantilla:

Ninguna fila de esta tabla es nueva: la primera se estableció en la lección "Patrones de Comunicación entre Componentes Hermanos" (05-04), la segunda en "Comunicación de Padre a Hijo con Propiedades" (05-03) y se refinó con repeat en "Contexto Compartido con @lit/context" (07-04), y la tercera en "Slots y Estilizado de Contenido Distribuido" (04-04). Lo que aporta esta lección es, de nuevo, verlas juntas como un único flujo descendente continuo, desde la raíz del árbol hasta su hoja más profunda.

El segundo eje, simétrico al anterior, es el de los eventos personalizados que suben desde donde ocurre una interacción hasta quien tiene autoridad para decidir qué hacer con ella:

Este reenvío en dos saltos, con el idTarea añadido explícitamente en el segundo evento porque <task-board> no tiene acceso al cierre sobre tarea.id que sí tiene <task-list>, se estableció íntegramente en las lecciones "Eventos Personalizados: Comunicación de Hijo a Padre" (05-02) y "Patrones de Comunicación entre Componentes Hermanos" (05-04). <task-board> es, en todo momento, el único componente de TaskFlow que modifica realmente el array tareas; todos los demás se limitan a anunciar hechos ocurridos sobre sí mismos, nunca a modificar directamente el estado de un ancestro.

Los dos ejes anteriores —propiedades hacia abajo, eventos hacia arriba— cubren toda la comunicación de TaskFlow salvo una relación: la que conecta <task-filter> con <task-list>, dos componentes hermanos sin relación directa de padre a hijo. Como se explicó en la lección "Contexto Compartido con @lit/context" (07-04), resolver esa relación mediante el patrón de los dos apartados anteriores obligaría a <task-board> a reenviar manualmente, en cada tecla pulsada en el filtro, una propiedad hacia <task-list> que el propio <task-board> no necesita para nada por sí mismo.

<task-board> publica el contexto una única vez, en su constructor; <task-filter> lo consume para leer y para escribir (a través de la función actualizar incluida en el propio valor del contexto); <task-list> lo consume solo para leer, y decide con ese valor qué tareas cumplen el filtro antes de pasarlas, ya como propiedad normal, hacia cada <task-card>. Ninguno de los dos hermanos conoce al otro en ningún momento: ambos hablan únicamente con el contexto que <task-board> publica, exactamente el mecanismo estudiado en el módulo 7.

Con el árbol de componentes y los dos ejes de comunicación ya trazados, la estructura de carpetas de TaskFlow, tal como queda al final del curso, organiza cada pieza según el tipo de responsabilidad que cumple, no según el módulo en que se introdujo:

src/components/ reúne los cinco elementos personalizados del árbol del apartado 2; src/controllers/ y src/mixins/ separan, siguiendo el criterio de la lección "Mixins y Composición de Comportamiento" (06-04), la lógica con estado propio y ciclo de vida (ContadorTiempoRestanteController) de la lógica que se integra directamente en la API pública de un componente (ConEstadoCarga); src/context/ contiene la clave de contexto compartida entre <task-board>, <task-filter> y <task-list>; src/directives/ guarda la directiva personalizada resaltarSiUrgente; src/services/ aísla la simulación de carga de datos externa a cualquier componente concreto; y src/styles/ mantiene los estilos compartidos entre varios componentes. test/ reúne la batería de pruebas construida en el módulo 9.

Esta tabla final sirve de índice inverso: dado un fichero de la estructura anterior, indica en qué lección del curso se explicó por primera vez la técnica que ese fichero aplica, útil como referencia rápida durante las tres lecciones siguientes de este módulo.

Con el árbol, los dos ejes de comunicación, la excepción del contexto y la estructura de carpetas ya fijados, esta lección ha cumplido su función de mapa. Las tres lecciones siguientes se limitan a recorrerlo: primero los componentes que muestran datos, después los que orquestan el estado, y por último las pruebas, el empaquetado y el cierre del curso.

• Organizar las carpetas por módulo del curso en lugar de por tipo de responsabilidad: una estructura como modulo-06/, modulo-07/ reflejaría el orden en que se aprendió cada técnica, no cómo se organiza un proyecto real; components/, controllers/, mixins/, context/ agrupan el código según su papel dentro de la aplicación, que es el criterio que sobrevive una vez terminado el curso.
• Olvidar que el contexto de filtro es una excepción, no la regla general: como se ha explicado en el apartado 6, la inmensa mayoría de la comunicación de TaskFlow sigue el patrón de propiedades hacia abajo y eventos hacia arriba; @lit/context se reserva para el único caso —hermanos sin relación directa— que ese patrón no resuelve bien por sí solo.
• Pensar que <task-board> conoce la estructura interna de <task-card>: <task-board> solo conoce a <task-list> (su hijo directo) y, mediante el contexto, a <task-filter>; nunca ha tenido, ni necesita tener, ninguna referencia directa a una <task-card> concreta, gracias al reenvío de eventos explicado en el apartado 5.
• Esperar que esta lección contenga código ejecutable: deliberadamente, no lo contiene; es un mapa para las tres lecciones siguientes, no una implementación.

1. Sin mirar las lecciones anteriores, dibuja de memoria el árbol de componentes del apartado 2 y, junto a cada flecha, escribe si esa relación se resuelve con una propiedad, con un evento, o con el contexto de filtro. Comprueba después el resultado contra los apartados 4, 5 y 6.
2. Explica, basándote en el apartado 5, por qué <task-list> necesita añadir idTarea al detail del evento tarea-cambiada que reenvía, cuando <task-card>, el origen del evento, nunca incluyó ese dato en el suyo.
3. Un compañero de equipo propone mover contador-tiempo-restante-controller.js a src/components/, argumentando que solo lo usa <task-card>. Explica, basándote en el apartado 7 y en el criterio de la lección "Mixins y Composición de Comportamiento" (06-04), por qué src/controllers/ sigue siendo la ubicación más adecuada aunque, por ahora, solo un componente lo use.

1. El árbol correcto es el del apartado 2: <task-board> con dos hijos, <task-filter> y <task-list>; <task-list> con una <task-card> por cada tarea; cada <task-card> con un <user-avatar>. Las relaciones son: <task-board> → <task-list> (propiedad .tareas), <task-list> → <task-card> (propiedades por tarea), <task-card> → <user-avatar> (atributo y contenido distribuido), <task-card> → <task-list> → <task-board> (evento tarea-cambiada en dos saltos), y <task-board> ↔ <task-filter> / <task-board> ↔ <task-list> (contexto de filtro, en ambas direcciones para <task-filter>, solo lectura para <task-list>).
2. <task-card> no conoce el concepto de "identificador de tarea": es un componente aislado que solo sabe de sí mismo, y el evento que despacha (tarea-cambiada, con solo nuevoEstado en su detail) refleja exactamente esa ignorancia deliberada. <task-list>, en cambio, sí conoce la estructura del array tareas (gracias al cierre de tarea.id capturado al recorrer el array con repeat), y es la única que puede añadir esa información antes de que el evento siga subiendo; si no la añadiera, <task-board>, que no tiene ningún cierre sobre qué tarjeta concreta disparó el evento, no podría saber qué elemento del array debe actualizar.
3. ContadorTiempoRestanteController no es, en sí mismo, parte de la API pública ni de la plantilla de ningún componente: es un objeto con estado propio y ciclo de vida, pensado deliberadamente (como se explicó en 06-03) para ser reutilizable por cualquier host futuro que exponga una propiedad fechaLimite, no solo por <task-card>. Colocarlo en src/components/ sugeriría que es, él mismo, un elemento personalizado registrado con customElements.define, lo cual no es el caso; src/controllers/ refleja correctamente su naturaleza —una pieza de comportamiento reutilizable, desacoplada de cualquier componente concreto— independientemente de cuántos hosts lo usen hoy.

Esta lección ha trazado el mapa completo de TaskFlow sin escribir ningún componente nuevo: el árbol de cinco componentes con su responsabilidad de una línea cada uno, los dos ejes de comunicación —propiedades hacia abajo, eventos hacia arriba— que resuelven casi toda la aplicación, la excepción deliberada del contexto de filtro para el único par de hermanos sin relación directa, y la estructura de carpetas final que organiza cada pieza según su papel, no según el módulo en que se aprendió.

Con este mapa ya trazado, la siguiente lección, "Construyendo los Componentes Principales", empieza a rellenarlo de verdad: el código completo y consolidado de <user-avatar>, <task-card> y <task-filter>, uniendo en un solo fichero por componente todas las piezas que este mismo curso fue añadiendo por partes, módulo a módulo.