Issues

La unidad de trabajo de Hilbana: identificador, estados, contexto para agentes y relaciones.

Las issues son la unidad de trabajo. Toda tarea, bug o mejora vive como una issue con un identificador único, un estado y un responsable, que puede ser una persona o un agente.

Qué es

Una issue reúne todo lo necesario para llevar un trabajo de principio a fin:

  • Identificador tipo DRAPPS-123: no es un texto libre, se compone de la clave del equipo (DRAPPS) más un número que se incrementa por equipo. Es estable y sirve para referenciar la issue desde ramas, PRs o comentarios.
  • Título y descripción (markdown).
  • Prioridad y estimación (story points, que alimentan la velocity).
  • Estado del flujo (ver Estados de flujo).
  • Responsable (assignee), creador y proyecto (toda issue vive en un proyecto; ver Proyectos).
  • Ciclo e hito opcionales, para planificar.
  • Fechas: de inicio, objetivo y de vencimiento (deadline).

Sub-issues y relaciones

  • Sub-issues: una issue puede colgar de otra (relación padre/hijo) para descomponer trabajo grande en piezas.
  • Relaciones de bloqueo: una issue puede bloquear o estar bloqueada por otra, de modo que el orden de ejecución quede explícito.

Estados y flujo

El estado no es un texto fijo: es un estado de flujo definido por cada equipo, clasificado por categoría (backlog, en curso, hecho, cancelado…). La app registra las transiciones con marcas de tiempo (cuándo empezó, cuándo se completó, cuándo se canceló) y usa la de completado para cerrar el cálculo de métricas como la velocity y el cycle time (ver Insights).

Contexto para agentes

Lo que hace a las issues de Hilbana distintas es que están pensadas para que un agente pueda tomarlas y ejecutarlas sin redescubrir el contexto cada vez:

  • Contexto del agente (agentContext): notas en markdown con los archivos relevantes, el comando de verificación, la definición de hecho y cualquier apunte útil. Lo leen y escriben tanto la interfaz como el MCP.
  • Definición de Ready (DoR): dos campos estructurados y máquina-verificables, definición de hecho (criterios de aceptación) y comando de verificación (por ejemplo pnpm build o los tests), que permiten decidir si una issue está lista para un agente.
  • Claim / release: cuando un agente empieza a trabajar una issue, la reclama (queda marcada como “en curso por un agente”, con quién y desde cuándo). Es un bloqueo blando para que dos agentes no se pisen; al terminar, la libera. No se confunde con el responsable: el claim es “lo estoy tocando ahora”.

Cómo se usa

  1. Crea la issue con un título claro y su descripción.
  2. Rellena su Definición de Ready (definición de hecho + comando de verificación) si quieres que un agente pueda tomarla.
  3. Asígnala a una persona o a un agente, y sitúala en su proyecto (y ciclo, si aplica).
  4. Muévela por los estados a medida que avanza; la app anota las transiciones.

Consulta también Estados de flujo, Ciclos y Agentes.