Tablero de Tareas (Task Board)#

El Tablero de Tareas es distinto a cualquier otra herramienta de esta documentación: no autora contenido de juego en absoluto. No hay una sala, un sprite, un diálogo ni un archivo de sonido del otro lado. Es un tablero kanban para trackear el trabajo sobre el motor y sus juegos — el mismo tipo de backlog que un estudio chico llevaría en una app de gestión de proyectos, salvo que acá es una página HTML plana servida por el dev server y guardada en un archivo JSON dentro del repo.

Llegas a él desde el Hub, pero fíjate que el Hub lo lista sin ningún editor de proyecto asociado (editor: null en el registro de herramientas del Hub) — no se abre "para" un proyecto como sí pasa con el Editor de Salas o el Editor de Personajes. Esa es la primera pista de su rareza estructural más importante.

Un solo tablero para todo el workspace#

Cualquier otro editor de esta suite lee y escribe archivos bajo projects/<id>/… — acotado al proyecto que esté activo. El Tablero de Tareas no. Lee y escribe un único archivo en la raíz del repo, tasks.json, compartido por todos los proyectos del workspace. No hay un archivo de tablero por proyecto, y cambiar el proyecto activo del Hub nunca cambia qué archivo carga el tablero.

Las tarjetas pueden llevar un tag project opcional, y el tablero filtra el archivo compartido por ese tag para comodidad — pero por debajo, los pendientes del motor mismo, los del Proyecto A y los del Proyecto B viven todos en las mismas columnas del mismo archivo. Una tarjeta sin tag project es "genérica" (trabajo sin etiqueta, a nivel de motor, o de todo el workspace); la opción por defecto del filtro Proyecto se llama literalmente "Tareas genéricas" y muestra solo las tarjetas sin etiquetar. Elegir un proyecto en ese filtro muestra solo las tarjetas etiquetadas con el id de ese proyecto — nunca una mezcla.

El Hub respeta esto al borrar un proyecto: borrar un proyecto no toca ningún archivo de tablero por proyecto (no existe tal cosa), pero sí barre el tasks.json compartido y quita cada tarjeta etiquetada con el id de ese proyecto, en todas las columnas. Un proyecto recién creado siembra una única tarjeta de "Bienvenida" en el tablero compartido, etiquetada con su propio id, en vez de recibir su propio archivo de tablero.

La primera vez que abres el tablero — antes de haber guardado algo propio — vas a ver un set de tarjetas de ejemplo repartidas en las columnas, solo para mostrar cómo se ve un tablero con contenido. En cuanto guardes cualquier cambio, esos ejemplos quedan reemplazados por tu tablero real de ahí en adelante.

Anatomía de una tarjeta#

Una tarjeta es un registro chico:

• id — identificador estable. Se deriva automáticamente de las primeras palabras de la descripción si lo dejas en blanco al crear la tarjeta (minúsculas, con guiones, tope de 20 caracteres), o lo escribes a mano (se sanitiza a letras/dígitos/-/_, sin tope de largo). Garantizado único en todo el tablero — una colisión recibe un sufijo -2, -3, etc. Una vez que la tarjeta existe, su id queda fijo: el modal de edición lo muestra de solo lectura, porque renombrarlo dejaría huérfano un archivo de spec que la referencia por ese id (ver más abajo) y rompería la conexión en silencio.
• text — la descripción de la tarjeta. En la práctica se mantiene corta (la convención del proyecto es más o menos 10-12 palabras), con cualquier detalle más largo viviendo en un documento de spec aparte en vez de en la tarjeta misma — la UI no impone un límite de largo, esto es un hábito del equipo.
• area — un tag de categoría: engine, tools, art, audio, writing, nice-to-have, post-launch (trabajo aparcado a propósito hasta después de publicar), o un puñado de valores legacy/ad-hoc (other, tooling, business, docs, mixed) que todavía aparecen en tarjetas viejas. Determina la franja de color del borde izquierdo de la tarjeta y el filtro de área del encabezado. Puedes añadir las tuyas — ver Áreas y actores más abajo.
• actor — para quién es el trabajo. developer, admin y mixed vienen con el tablero, y aquí también puedes añadir los tuyos.
• project — tag opcional de id de proyecto (ver arriba); ausente significa genérica/sin etiquetar.
• created — una fecha que se muestra en la cara de la tarjeta.
• notes — detalle en texto libre, usado como respaldo cuando no existe un archivo de spec para la tarjeta (ver abajo).
• branch — un nombre de rama de git opcional, se muestra en la tarjeta si está presente.

No hay un campo status explícito en los datos. El status de una tarjeta es implícito según en qué arreglo de columna vive — tasks.json tiene la forma de un arreglo por columna (backlog, next, inprogress, qa, done, más archived, que es una lista deliberadamente fuera del tablero sin columna propia — se alcanza por el cajón de Archivadas de más abajo, nunca arrastrando), no una lista plana de tarjetas donde cada una lleva un string de status. Junto a esos arreglos el archivo guarda un pequeño bloque de ajustes, que es donde viven las áreas y los actores que añadiste tú — eso es lo que les permite sobrevivir a la última tarjeta que los usaba.

Columnas y el flujo de trabajo#

El tablero renderiza cinco columnas de izquierda a derecha: BACKLOG (Pendientes), NEXT UP (Siguiente), IN PROGRESS (En curso), QA, DONE (Hecho). Deliberadamente no hay una sexta columna para archived — las tarjetas archivadas viven completamente fuera del tablero para que el ático nunca sature el flujo en curso — pero no se pierden: un cajón de Archivadas dedicado (más abajo) las ve y las restaura.

Mover una tarjeta entre columnas es arrastrar y soltar, así de simple — la UI no impone ningún orden ni bloquea a qué columna puede moverse una tarjeta ni desde cuál. Puedes arrastrar una tarjeta directo de BACKLOG a DONE si quieres; nada te lo impide. La disciplina de flujo de trabajo que se apila encima — QA es un gate de aprobación humana, las tarjetas se mueven a QA al entregar el trabajo pero solo se promueven QA → DONE con aprobación explícita, nunca auto-aprobación — es una convención de equipo, no algo que la herramienta misma chequee o bloquee. El tablero es una lista de tareas con drag-and-drop, no una máquina de estados.

Dentro de una columna, arrastrar una tarjeta y soltarla junto a otra reordena la lista; soltarla sobre el cuerpo de otra columna la mueve ahí (insertada en la posición donde soltaste, o al final si la soltaste sobre espacio vacío).

Mover varias tarjetas a la vez#

Haz clic en el texto de una tarjeta para seleccionarla — la tarjeta toma un borde de acento — y clic otra vez para quitarla de la selección. Luego arrastra cualquier tarjeta seleccionada por su texto y viaja el grupo entero, con el fantasma del arrastre mostrando cuántas van con él. Aterrizan en la columna destino conservando el orden que tenían en la de origen, y la selección se vacía sola al soltar.

La selección vive en una sola columna a la vez: seleccionar una tarjeta de otra columna reemplaza la selección anterior en vez de sumarse a ella. Eso es lo que mantiene inequívoco el arrastre de grupo — todas las tarjetas vienen del mismo sitio, así que "conservar su orden relativo" siempre significa algo.

Archivar: el ático fuera del tablero#

Algunas tarjetas ya están saldadas pero no vale la pena borrarlas — un experimento que se envió, una idea superada, un pedazo de trabajo terminado que quieres fuera de la vista sin perder el registro. Esas van al archivo, que a propósito no es una columna: las tarjetas archivadas viven completamente fuera del tablero para que las columnas de trabajo se mantengan enfocadas en lo que está vivo.

Una tarjeta se archiva desde su modal de edición: el selector de columna gana una entrada ARCHIVED (solo al editar una tarjeta existente — no puedes crear una tarjeta directo en el archivo). Elegirla marca la tarjeta como cerrada (una fecha de completado y una nota de motivo de cierre) y la mueve fuera del tablero.

El botón 🗄 del encabezado — solo ícono, con el conteo de archivadas en vivo en su tooltip ("Archivadas · N tareas") — abre el cajón de Archivadas: una lista de solo lectura y con búsqueda de cada tarjeta archivada. La caja de búsqueda filtra en vivo a través del id, texto, área y motivo de cierre de la tarjeta. Cada fila muestra el id, texto, área, fecha de completado y motivo de la tarjeta, con un botón Restaurar por tarjeta; un dropdown Restaurar a columna arriba del cajón (por defecto BACKLOG) elige dónde aterriza una tarjeta restaurada. Restaurar mueve la tarjeta de vuelta al tablero en la columna elegida y suelta su contabilidad de archivo, así que vuelve al flujo como una tarjeta común. La lista archived se asegura al cargar y hace round-trip intacta a través del guardado, abras o no el cajón.

Archivar en bloque#

Al hacer clic en el número de una columna, se convierte en un toggle de seleccionar-todo / deseleccionar-todo para cada tarjeta visible en esa columna en ese momento (la selección es de una sola columna — elegir tarjetas en otra la limpia). Con una selección en DONE, aparece un botón de encabezado — 🗄 Archive (N) — que archiva toda la selección de una vez, cada tarjeta con la misma fecha de completado y motivo de cierre que el flujo de a una de arriba.

Filtros#

El encabezado tiene tres filtros que se combinan (lógica AND entre filtros):

• Área — un dropdown multi-selección con checkboxes (lógica OR entre las áreas marcadas): no marcar ninguna equivale a "Todos", o marcar áreas específicas para mostrar solo las tarjetas que coincidan. Una fila "Seleccionar todo" activa/desactiva todas las áreas conocidas de una vez. El dropdown incluye áreas sembradas desde una lista de áreas conocidas aunque cero tarjetas las usen actualmente (así una categoría como nice-to-have sigue visible y seleccionable aunque esté vacía).
• Proyecto — un dropdown sembrado desde el registro de proyectos (así aparece todo proyecto existente aunque tenga cero tarjetas etiquetadas) más cualquier tag de proyecto ad-hoc encontrado en las tarjetas. Por defecto muestra el proyecto que esté activo en el Hub cuando abres el tablero (cayendo a "Tareas genéricas" si el proyecto activo es uno de un par de proyectos legacy/de propósito general, o si no se puede contactar al Hub).
• Actor — Todos, o un actor cualquiera: los tres que trae el tablero más los que hayas añadido tú. Si borras un actor propio por el que estabas filtrando, el filtro cae a Todos en vez de mostrarte un tablero vacío por un valor que ya no existe.

Los filtros solo afectan qué se muestra y no alteran los datos guardados.

Áreas y actores#

El botón 🏷 del encabezado abre un pequeño gestor de las dos taxonomías. Áreas y actores tienen cada uno una lista con todo lo disponible: los que vienen con el tablero salen marcados como integrados, y los que alguna tarjeta usa de verdad llevan un contador, así ves de un vistazo qué está vivo y qué sobra.

Añadir uno es un campo de texto — el nombre se normaliza solo (a minúsculas, los espacios a guiones), y el modal rechaza un nombre vacío o duplicado explicando el motivo en línea en vez de no hacer nada en silencio.

Toda fila — integradas incluidas — lleva Renombrar y Borrar, cada una como su propio modal anidado sobre el gestor:

• Renombrar reetiqueta cada tarjeta que lleve ese tag, archivadas incluidas. Si el nombre que escribes ya existe, se trata como una fusión, no un error — justo lo que necesitas para juntar casi-duplicados (ENGINE/engine, dev/developer) — y siempre dice cuántas tarjetas están por moverse antes de tocar nada.
• Borrar solo quita la etiqueta; las tarjetas en sí nunca se tocan, simplemente la pierden. Nunca hace cascada, y la confirmación solo aparece cuando alguna tarjeta realmente perdería el tag — confirmar un no-op enseña a hacer clic sin leer. Una integrada no se puede tachar del vocabulario fijo del tablero (esa lista es código), así que borrarla en cambio recuerda tu elección como oculta; volver a agregar el mismo nombre después levanta la ocultación en vez de crear un duplicado.

Lo que añades se guarda con el tablero en vez de deducirse de las tarjetas, así que un área o un actor que creaste sigue disponible aunque ninguna tarjeta lo lleve ahora mismo — puedes montar la taxonomía antes de que haya trabajo que archivar bajo ella.

Crear, editar y borrar una tarjeta#

Tanto crear como editar una tarjeta abren el mismo modal — un cambio reciente reemplazó un camino de edición de texto crudo más viejo por este formulario compartido (el patrón crear-modal-como-editor). El formulario expone: descripción de la tarea (textarea), id (editable solo al crear — auto-sugerido desde la descripción mientras escribes, sobre-escribible; se muestra de solo lectura una vez que la tarjeta existe), columna, área, actor, y proyecto. Crear una tarjeta se puede iniciar desde el botón ＋ del encabezado (cae en Backlog) o desde el botón propio + Agregar tarea de una columna (cae en esa columna); editar es vía el ícono de lápiz que aparece al pasar el mouse sobre una tarjeta.

Borrar una tarjeta es el botón × al pasar el mouse, y siempre pide confirmación primero — un diálogo modal que describe el texto de la tarjeta y avisa que la acción no se puede deshacer — antes de que la tarjeta se elimine de verdad. Esto lo impone la herramienta misma, no es solo convención: no hay un camino de borrado directo en la UI.

El guardado es automático: cualquier cambio (crear, editar, borrar, arrastrar) marca el tablero como no guardado y dispara un auto-guardado con debounce (unos cientos de milisegundos después del último cambio, así una ráfaga de ediciones o una cadena de arrastres se combina en una sola escritura) vía POST /save-tasks, que sobrescribe el tasks.json compartido en la raíz del repo. Un botón Guardar manual en el encabezado hace la misma escritura de inmediato. Un toast confirma cada guardado (o reporta un error, por ejemplo si el dev server no está corriendo); el título de la página también recibe una marca ● mientras hay un cambio sin guardar, y el navegador va a avisar antes de cerrar una pestaña con cambios sin guardar.

Specs: el detalle largo que una tarjeta no guarda#

El texto de una tarjeta está pensado para quedarse corto; se espera que el detalle de una tarjeta activa viva en un archivo de spec en markdown aparte, por convención en docs/specs/<id-de-tarjeta>.md. El tablero expone esto directamente: cada tarjeta tiene un pequeño ícono de documento (visible tenuemente en reposo, completo al pasar el mouse, así una tarjeta con detalle que vale la pena leer es descubrible de un vistazo durante una revisión de QA) que abre un modal de solo lectura que renderiza ese archivo de spec como markdown, obtenido de /docs/specs/<id>.md. Si no existe un archivo de spec para el id de la tarjeta, el modal cae de vuelta a mostrar el campo notes propio de la tarjeta (etiquetado como tal); si no hay ni spec ni notas, lo dice sin rodeos. Por esto el id de una tarjeta queda bloqueado después de crearla — el vínculo al archivo de spec es por convención (mismo id, ruta predecible), no una referencia guardada, así que renombrar un id rompería la conexión con su spec en silencio.

Flujo de trabajo#

1. Abre el Tablero de Tareas desde el Hub. Por defecto muestra las tarjetas del proyecto actualmente activo en el Hub (o "Tareas genéricas" si ese proyecto es genérico/no está definido).
2. Usa los filtros de Área / Proyecto / Actor para acotar la vista.
3. Agrega una tarjeta con el ＋ del encabezado o el + Agregar tarea de una columna, completando descripción, área, actor y (opcionalmente) un tag de proyecto.
4. Arrastra tarjetas entre columnas a medida que avanza el trabajo; reordena dentro de una columna soltando junto a otra tarjeta.
5. Haz clic en el ícono de spec de una tarjeta para leer (o descubrir que todavía no existe) el detalle largo detrás de una descripción corta.
6. Edita los campos de una tarjeta con su ícono de lápiz cuando cambien prioridades o detalles; bórrala con su ícono ×, confirmando cuando se te pregunte.
7. Todo se guarda automáticamente sobre la marcha; el botón Guardar del encabezado y el toast de la esquina son solo una versión explícita e inmediata de la misma escritura.

El tablero es compartido, no por proyecto — ese es el dato a saber antes que cualquier otro. Cualquier otra herramienta de esta suite lee y escribe dentro de projects/<id>/; el Tablero de Tareas lee y escribe un único tasks.json en la raíz del repo para todo el workspace, y el filtro de Proyecto es una vista sobre tags de ese único archivo, no un switch entre archivos separados. Borrar un proyecto tiene efecto cascada sobre este archivo compartido (quitando sus tarjetas etiquetadas) precisamente porque no hay un tablero separado por proyecto que simplemente descartar.