L'última lliçó del mòdul 9 ho va anunciar amb aquestes paraules exactes: "queda una única lliçó, l'última del curs: 'Projecte: Construint TaskFlow', on no es presenta cap concepte nou, sinó que es recorre l'aplicació de principi a fi". Aquesta "única lliçó" és, en realitat, aquest mòdul complet, dividit en quatre parts per comoditat de lectura, però pensat com una sola unitat narrativa: el projecte final. Aquesta primera part encara no escriu cap component; traça el mapa complet de TaskFlow tal com ha quedat després de nou mòduls —el seu arbre de components, com viatgen les dades entre ells, i l'estructura de carpetes final del projecte— perquè les tres lliçons següents tinguin un plànol clar sobre el qual construir, en lloc de reconstruir aquesta imatge de conjunt sobre la marxa.

1. Què és aquest mòdul i què no és
2. L'arbre de components de TaskFlow, complet
3. Responsabilitat d'una línia, per component
4. Flux de dades: propietats cap avall
5. Flux de dades: esdeveniments cap amunt
6. L'excepció deliberada: el context de filtre
7. Estructura de carpetes final del projecte
8. De la carpeta a la lliçó: on es va explicar cada peça
9. Cap a la construcció dels components

Convé fixar això abans d'escriure una sola línia de codi: aquest mòdul no introdueix cap concepte de Lit que no s'hagi explicat ja entre els mòduls 1 i 9. Plantilles, propietats reactives, estils amb Shadow DOM, esdeveniments personalitzats, cicle de vida, controladors, mixins, directives, context compartit, integració amb la resta de l'ecosistema i bones pràctiques: tot això ja està cobert. El que sí que falta, i és exactament l'objectiu de les quatre lliçons d'aquest mòdul, és veure-ho tot unit, com un únic projecte coherent, en lloc d'una successió de fragments de codi repartits entre trenta-sis lliçons diferents, cadascuna centrada en la tècnica que li corresponia explicar en el seu moment.

Aquesta primera lliçó es limita a la planificació: l'arbre de components final, el flux de dades que els connecta, i l'estructura de carpetes. Les lliçons 10-02 i 10-03 escriuen el codi complet de cada component i cada peça d'infraestructura compartida, i la 10-04 tanca amb proves, empaquetatge i el propi tancament del curs.

TaskFlow ha crescut, al llarg del curs, fins a convertir-se en cinc components personalitzats, organitzats en un arbre de quatre nivells de profunditat:

Cap component d'aquest arbre és nou: <task-board> va aparèixer al mòdul 5 (05-04) com a ancestre comú de <task-list>; <user-avatar> al mòdul 4 (04-04), com a fill de <task-card>; i <task-filter>, esmentat des del propi mòdul 5 sense implementar, no va cobrar vida real fins al mòdul 7 (07-04), de la mà de @lit/context. L'únic que aporta aquesta lliçó és dibuixar, per fi, l'arbre complet d'una sola vegada, una cosa que cap lliçó anterior necessitava fer perquè cadascuna se centrava en la peça que estava construint en aquell moment.

Cada component de TaskFlow té una responsabilitat que es pot resumir en una sola frase, sense necessitat d'enumerar tots els detalls de la seva implementació:

Aquesta taula, encara que sembli trivial, és la prova que la descomposició de TaskFlow en cinc peces, feta al llarg del curs, segueix el criteri explicat a la lliçó "Patrons i Antipatrons Comuns" (09-04, apartat 6): cada component canvia per un motiu diferent del dels altres, i cap no necessita la conjunció "i" per descriure's.

El primer eix de comunicació de TaskFlow, establert des del mòdul 3 i perfeccionat al mòdul 5, és el flux de propietats reactives d'un component cap als seus fills directes a la plantilla:

Cap fila d'aquesta taula és nova: la primera es va establir a la lliçó "Patrons de Comunicació entre Components Germans" (05-04), la segona a "Comunicació de Pare a Fill amb Propietats" (05-03) i es va refinar amb repeat a "Context Compartit amb @lit/context" (07-04), i la tercera a "Slots i Estilització de Contingut Distribuït" (04-04). El que aporta aquesta lliçó és, de nou, veure-les juntes com un únic flux descendent continu, des de l'arrel de l'arbre fins a la seva fulla més profunda.

El segon eix, simètric a l'anterior, és el dels esdeveniments personalitzats que pugen des d'on passa una interacció fins a qui té l'autoritat per decidir què fer-ne:

Aquest reenviament en dos salts, amb l'idTarea afegit explícitament en el segon esdeveniment perquè <task-board> no té accés al tancament sobre tarea.id que sí que té <task-list>, es va establir íntegrament a les lliçons "Esdeveniments Personalitzats: Comunicació de Fill a Pare" (05-02) i "Patrons de Comunicació entre Components Germans" (05-04). <task-board> és, en tot moment, l'únic component de TaskFlow que modifica realment l'array tareas; tots els altres es limiten a anunciar fets ocorreguts sobre ells mateixos, mai a modificar directament l'estat d'un ancestre.

Els dos eixos anteriors —propietats cap avall, esdeveniments cap amunt— cobreixen tota la comunicació de TaskFlow excepte una relació: la que connecta <task-filter> amb <task-list>, dos components germans sense relació directa de pare a fill. Com es va explicar a la lliçó "Context Compartit amb @lit/context" (07-04), resoldre aquesta relació mitjançant el patró dels dos apartats anteriors obligaria <task-board> a reenviar manualment, a cada tecla premuda al filtre, una propietat cap a <task-list> que el mateix <task-board> no necessita per a res per si mateix.

<task-board> publica el context una única vegada, al seu constructor; <task-filter> el consumeix per llegir i per escriure (a través de la funció actualizar inclosa en el propi valor del context); <task-list> el consumeix només per llegir, i decideix amb aquest valor quines tasques compleixen el filtre abans de passar-les, ja com a propietat normal, cap a cada <task-card>. Cap dels dos germans coneix l'altre en cap moment: tots dos parlen únicament amb el context que <task-board> publica, exactament el mecanisme estudiat al mòdul 7.

Amb l'arbre de components i els dos eixos de comunicació ja traçats, l'estructura de carpetes de TaskFlow, tal com queda al final del curs, organitza cada peça segons el tipus de responsabilitat que compleix, no segons el mòdul en què es va introduir:

src/components/ reuneix els cinc elements personalitzats de l'arbre de l'apartat 2; src/controllers/ i src/mixins/ separen, seguint el criteri de la lliçó "Mixins i Composició de Comportament" (06-04), la lògica amb estat propi i cicle de vida (ContadorTiempoRestanteController) de la lògica que s'integra directament a l'API pública d'un component (ConEstadoCarga); src/context/ conté la clau de context compartida entre <task-board>, <task-filter> i <task-list>; src/directives/ guarda la directiva personalitzada resaltarSiUrgente; src/services/ aïlla la simulació de càrrega de dades externa a qualsevol component concret; i src/styles/ manté els estils compartits entre diversos components. test/ reuneix la bateria de proves construïda al mòdul 9.

Aquesta taula final serveix d'índex invers: donat un fitxer de l'estructura anterior, indica en quina lliçó del curs es va explicar per primera vegada la tècnica que aquest fitxer aplica, útil com a referència ràpida durant les tres lliçons següents d'aquest mòdul.

Amb l'arbre, els dos eixos de comunicació, l'excepció del context i l'estructura de carpetes ja fixats, aquesta lliçó ha complert la seva funció de mapa. Les tres lliçons següents es limiten a recórrer-lo: primer els components que mostren dades, després els que orquestren l'estat, i finalment les proves, l'empaquetatge i el tancament del curs.

• Organitzar les carpetes per mòdul del curs en lloc de per tipus de responsabilitat: una estructura com modulo-06/, modulo-07/ reflectiria l'ordre en què es va aprendre cada tècnica, no com s'organitza un projecte real; components/, controllers/, mixins/, context/ agrupen el codi segons el seu paper dins de l'aplicació, que és el criteri que sobreviu un cop acabat el curs.
• Oblidar que el context de filtre és una excepció, no la regla general: com s'ha explicat a l'apartat 6, la immensa majoria de la comunicació de TaskFlow segueix el patró de propietats cap avall i esdeveniments cap amunt; @lit/context es reserva per a l'únic cas —germans sense relació directa— que aquest patró no resol bé per si sol.
• Pensar que <task-board> coneix l'estructura interna de <task-card>: <task-board> només coneix <task-list> (el seu fill directe) i, mitjançant el context, <task-filter>; mai no ha tingut, ni necessita tenir, cap referència directa a una <task-card> concreta, gràcies al reenviament d'esdeveniments explicat a l'apartat 5.
• Esperar que aquesta lliçó contingui codi executable: deliberadament, no en conté; és un mapa per a les tres lliçons següents, no una implementació.

1. Sense mirar les lliçons anteriors, dibuixa de memòria l'arbre de components de l'apartat 2 i, al costat de cada fletxa, escriu si aquesta relació es resol amb una propietat, amb un esdeveniment, o amb el context de filtre. Comprova després el resultat contra els apartats 4, 5 i 6.
2. Explica, basant-te en l'apartat 5, per què <task-list> necessita afegir idTarea al detail de l'esdeveniment tarea-cambiada que reenvia, quan <task-card>, l'origen de l'esdeveniment, mai no va incloure aquesta dada en el seu.
3. Un company d'equip proposa moure contador-tiempo-restante-controller.js a src/components/, argumentant que només l'utilitza <task-card>. Explica, basant-te en l'apartat 7 i en el criteri de la lliçó "Mixins i Composició de Comportament" (06-04), per què src/controllers/ continua sent la ubicació més adequada tot i que, de moment, només un component l'utilitzi.

1. L'arbre correcte és el de l'apartat 2: <task-board> amb dos fills, <task-filter> i <task-list>; <task-list> amb una <task-card> per cada tasca; cada <task-card> amb un <user-avatar>. Les relacions són: <task-board> → <task-list> (propietat .tareas), <task-list> → <task-card> (propietats per tasca), <task-card> → <user-avatar> (atribut i contingut distribuït), <task-card> → <task-list> → <task-board> (esdeveniment tarea-cambiada en dos salts), i <task-board> ↔ <task-filter> / <task-board> ↔ <task-list> (context de filtre, en totes dues direccions per a <task-filter>, només lectura per a <task-list>).
2. <task-card> no coneix el concepte d'"identificador de tasca": és un component aïllat que només sap de si mateix, i l'esdeveniment que despatxa (tarea-cambiada, amb només nuevoEstado al seu detail) reflecteix exactament aquesta ignorància deliberada. <task-list>, en canvi, sí que coneix l'estructura de l'array tareas (gràcies al tancament de tarea.id capturat en recórrer l'array amb repeat), i és l'única que pot afegir aquesta informació abans que l'esdeveniment continuï pujant; si no l'afegís, <task-board>, que no té cap tancament sobre quina targeta concreta va disparar l'esdeveniment, no podria saber quin element de l'array ha d'actualitzar.
3. ContadorTiempoRestanteController no és, en si mateix, part de l'API pública ni de la plantilla de cap component: és un objecte amb estat propi i cicle de vida, pensat deliberadament (com es va explicar a 06-03) per ser reutilitzable per qualsevol host futur que exposi una propietat fechaLimite, no només per <task-card>. Col·locar-lo a src/components/ suggeriria que és, ell mateix, un element personalitzat registrat amb customElements.define, cosa que no és el cas; src/controllers/ reflecteix correctament la seva naturalesa —una peça de comportament reutilitzable, desacoblada de qualsevol component concret— independentment de quants hosts l'utilitzin avui.

Aquesta lliçó ha traçat el mapa complet de TaskFlow sense escriure cap component nou: l'arbre de cinc components amb la seva responsabilitat d'una línia cadascun, els dos eixos de comunicació —propietats cap avall, esdeveniments cap amunt— que resolen quasi tota l'aplicació, l'excepció deliberada del context de filtre per a l'única parella de germans sense relació directa, i l'estructura de carpetes final que organitza cada peça segons el seu paper, no segons el mòdul en què es va aprendre.

Amb aquest mapa ja traçat, la lliçó següent, "Construint els Components Principals", comença a omplir-lo de veritat: el codi complet i consolidat de <user-avatar>, <task-card> i <task-filter>, unint en un sol fitxer per component totes les peces que aquest mateix curs va anar afegint per parts, mòdul a mòdul.