El ticket de principio a fin

El agente puede crear tickets hijos para repartir una misión en tareas independientes. Cada hijo tiene su tarjeta, su descripción, su agente y su resultado. El padre puede continuar su propio trabajo, seguir a los hijos y transmitirles instrucciones; retoma la síntesis cuando llegan sus resultados.

La descripción del hijo debe ser autónoma: objetivo, alcance, restricciones y criterios de éxito. La división está limitada a tres niveles y cinco hijos no terminados por padre. Un hijo terminado no cierra al padre: este verifica los resultados y termina su propia misión.

Un ticket de seguimiento conserva un trabajo distinto descubierto por el camino. Una dependencia expresa un requisito previo: puede apuntar a un ticket ya existente sin convertirlo en hijo. Por ejemplo, la documentación puede esperar a la entrega de una funcionalidad, mientras dos hijos, frontend y API, trabajan en paralelo. Una acción reservada a una persona puede representarse mediante un ticket User Actions cuando ese plugin está activo.

La etiqueta numerada identifica el ticket. El título resume el resultado esperado y la descripción aporta su contexto. La prioridad es low, medium, high o critical. Las etiquetas (tags) facilitan la clasificación y los proyectos afectados indican los repositorios que hay que consultar.

Los ocho tipos son feature, bug, refactor, doc, test, ia, session y user-action. Este último representa una acción humana y aparece cuando el módulo User Actions está activo.

Los seis estados exactos son todo, in_progress, working, pending, done y failed. in_progress cubre la asunción del ticket, working una ejecución activa y pending una espera explícita.

Haz doble clic en una tarjeta de Mission Control. El detalle se abre como una pestaña del deck: mantenlo junto al editor, al terminal o a otro ticket sin perder el contexto.

La descripción es la instrucción principal que lee el agente. Aporta el contexto y el problema observado, formula criterios de aceptación verificables y nombra lo que queda fuera del alcance. Añade las rutas o comandos útiles sin imponer una solución cuando solo importa el resultado.

Una buena descripción permite saber qué debe cambiar, cómo verificar el éxito y qué debe quedar intacto.

Un ticket verificable describe el problema actual, el resultado esperado, el alcance, las exclusiones y unos criterios observables acompañados de comandos. Este es un ejemplo ficticio y anonimizado, sin datos de clientes ni sintaxis de especificación impuesta.

En un repositorio Git de demostración con Node.js 22 o posterior, comprueba que las dos rutas siguientes están libres. Crea un ticket en Mission Control, introduce el título, el tipo y la prioridad en sus campos y copia el resto en la descripción. Para tu proyecto real, adapta las rutas, los requisitos previos y los comandos antes de lanzar el agente.

Título: Normalizar los espacios de una etiqueta
Tipo: feature
Prioridad: low
Proyecto: el repositorio de demostración abierto en Singularity
Dependencias: ninguna

Problema actual
Este repositorio Git de demostración no tiene función de normalización.
Una etiqueta introducida con espacios superfluos se conservaría tal cual.

Resultado esperado
Crear una función normalizeLabel(text) exportada desde
src/normalize-label.mjs: eliminar los blancos al principio y al final
y sustituir cada secuencia de blancos (espacios, tabulaciones, saltos
de línea) por un único espacio. Conservar mayúsculas y acentos.

Alcance
Crear src/normalize-label.mjs y test/normalize-label.test.mjs.
Usar Node.js 22 o posterior, node:test y node:assert/strict.
Las entradas son únicamente cadenas. Ninguna dependencia que instalar.

Exclusiones
Sin interfaz, base de datos, llamada de red, cambios en los
archivos existentes, gestión de otros tipos ni publicación.

Criterios de aceptación
1. "  Bonjour   équipe  " se convierte en "Bonjour équipe".
2. "" y una cadena compuesta de blancos se convierten en "".
3. Las tabulaciones y saltos de línea entre dos palabras se convierten
   en un espacio; "Équipe A" sigue siendo "Équipe A".
4. Los tests automatizados cubren cada uno de estos casos y pasan.
5. El diff final solo contiene los dos archivos del alcance.

Verificación desde la raíz del repositorio
node --version
node --check src/normalize-label.mjs
node --test test/normalize-label.test.mjs
git diff --check

Informe esperado
Indicar los comandos ejecutados, sus resultados y los archivos creados.
Si un comando falla, conservar su error y explicar la limitación.
Revisar los dos archivos en la pestaña Review y verificar el alcance
antes de la integración; un comando correcto no valida todo el diff.

Los criterios 1 a 4 se verifican con los tests; el criterio 5 se verifica en el diff de la pestaña Review. El agente debe ejecutar los comandos anteriores después de crear los archivos; este ejemplo no pretende reflejar una ejecución real.

Suelta un archivo o una imagen en el formulario de creación, o utiliza el botón de añadir. Las imágenes, los PDF y los textos se previsualizan en el detalle. Durante la ejecución, Singularity expone su lista al agente, que puede leerlos a través de la pasarela de sesión o con la ruta local proporcionada.

Utiliza ejemplos mínimos y anonimizados: ninguna captura debe revelar secretos ni el contenido de un ticket real.

El campo Blocked by vincula el ticket con sus requisitos previos. Solo se lanza cuando estos están terminados y, si han producido un worktree, integrados.

Un ticket complejo puede dividirse en hijos. El padre conserva sus vínculos y puede seguir trabajando. Cuando espera a sus hijos, pasa a pending y después se reanuda para sintetizar sus resultados.

Una fecha límite indica la fecha objetivo sin lanzar el trabajo. La planificación programa una ejecución recurrente diaria o semanal a la hora elegida. Puedes iniciar la primera ocurrencia de inmediato y después suspender, reanudar o eliminar la programación.

El hilo conserva los intentos, mensajes y respuestas del agente. Escribe para precisar la solicitud durante una ejecución. Si el agente plantea una pregunta bloqueante, el ticket pasa a pending: tu respuesta vuelve a la misma sesión con su contexto.

En un ticket done o failed, un nuevo mensaje o el relanzamiento inicia un nuevo intento sin borrar el historial.

El informe final explica lo que se ha entregado, las verificaciones realizadas y las posibles limitaciones. Permanece en el detalle y alimenta la revisión cuando está activada.

La resolución breve es una frase sin Markdown de menos de 120 caracteres, mostrada en negrita en la tarjeta terminada para que la columna Done se pueda leer de un vistazo.