feature-tracker-mcp

Un rastreador de funcionalidades y decisiones independiente del proyecto, construido para el caso en el que una persona dirige varias sesiones de codificación con IA a la vez y se ha convertido en el cuello de botella.

El problema que resuelve no es «rastrear funcionalidades». Es: tienes varios frentes en marcha, cada sesión es ciega a las demás, las decisiones surgen constantemente, y leerlo todo es tu trabajo. La mayoría de esas decisiones son mundanas y delegables. Unas pocas son genuinamente tuyas. Hoy no existe ningún mecanismo que las separe, así que lo lees todo.

Este es el mecanismo.

Tabla de contenidos

• Roles

• Qué existe hoy

• La forma

• Verbos

• Modos

• La columna vertebral: una base de datos por proyecto

• Categorías

• Compuertas: la cola de aprobación

• Recuentos y convergencia

• Condiciones de parada

• Puntos de control, pausa y resúmenes

• Por qué esto no está en git

• Orden de construcción

Roles

El objetivo de la división es que la segunda fila es actualmente el trabajo del humano, y casi nada de ello necesita serlo.

La forma

flowchart TD
    Ideate["/ideate — dialog"] -->|features as they are invented| DB[("project database")]
    Session["coding session (Claude)"] -->|every substantive turn| Capture{"implies a feature,<br/>guardrail, schema change<br/>or risk?"}
    Capture -->|yes, and not a duplicate| DB
    Capture -->|no| Session
    DB --> PM["ChatGPT as manager"]
    PM -->|next task, in priority order| Session
    PM -->|mundane decisions| PM
    PM -->|architectural · install · spend| Gate[["gate queue"]]
    Gate -->|approve / alter / reject| You([You])
    You -->|proceed| Session
    DB --> Table["/tracker-table · /standup"]
    Table --> You

Dos propiedades hacen el trabajo: la base de datos es el estado, así que nada depende de que un modelo recuerde; y las compuertas bloquean, de modo que «sí, continúa» es un mecanismo en lugar de un mensaje que tenías que estar presente para captar.

Qué existe hoy

División honesta, porque el resto de este documento especifica un sistema que solo está parcialmente construido.

Funcionando ahora — 8 herramientas MCP, verificadas de extremo a extremo contra una base de datos real:

Especificado pero no construido: todos los comandos de barra de la siguiente sección, la captura continua, el bucle de ejecución y el generador que renderiza el rastreador markdown de vuelta desde la base de datos.

Verificado contra un proyecto real. 75 funcionalidades importadas de un rastreador markdown existente de 387 líneas con cada id preservado — DIP-16, GLG-1, UA-11 y el resto siguen resolviéndose, porque se citan en mensajes de commit y nombres de worktree, y reasignarlos dejaría huérfano ese historial. Los contadores de categoría se avanzaron más allá del id importado más alto, de modo que nada ya en uso puede volver a entregarse.

Verbos

Cada uno es una habilidad, así que cada uno es también un comando de barra. Ninguno de estos está construido todavía — son la superficie prevista sobre las herramientas anteriores.

/standup, /tracker-table y /gates son de solo lectura y nunca consumen un turno de trabajo.

Modos

Ideación. Un diálogo cuyo subproducto es un backlog poblado. A medida que se inventan funcionalidades, se proponen en la base de datos inmediatamente, cada una presentada para que aceptes o modifiques — nada aterriza en silencio. Así se llena la cola.

Ejecución. Las funcionalidades de una categoría se llevan a su finalización una tras otra en orden de prioridad. ChatGPT selecciona el siguiente elemento, informa a la sesión de codificación, revisa lo que vuelve y lo acepta o lo envía de nuevo.

Captura continua. La parte mundana, y la razón por la que la lista se mantiene fiel. Cada turno sustancial — en cualquier sesión — se examina por lo que implicaba: una tabla nueva, una salvaguarda, una restricción CHECK, un riesgo que necesita mitigación, una subfuncionalidad que nadie nombró. Cada uno se convierte en una fila propuesta. La alternativa es lo que ocurre hoy: se menciona una vez, se desplaza, y se redescubre a un alto coste más tarde.

La captura se ejecuta en turnos que cambiaron archivos o llegaron a una conclusión. La mayoría de los turnos no implican nada, y ejecutarla en todos ellos es cómo se consigue un backlog que nadie lee.

La columna vertebral: una base de datos por proyecto

Cada proyecto recibe su propia base de datos Postgres, creada en el primer uso y nombrada a partir del remoto git del proyecto (de modo que cada worktree y cada clon del mismo proyecto coinciden en el mismo rastreador).

kind es uno de feature, guardrail, schema, risk, mitigation. status va de proposed → agreed → in_progress → done, o dropped.

Los ids se asignan atómicamente por la base de datos. Esto no es un detalle — es la solución para una clase real y recurrente de bug. Dos sesiones que leen independientemente un archivo, ven el siguiente número libre y ambas lo toman producen migraciones 016 duplicadas y números de issue en conflicto. Un contador incrementado dentro de una transacción lo hace estructuralmente imposible.

Cada evento registra el commit git, la rama y el árbol. Una funcionalidad propuesta contra un commit que desde entonces se ha reescrito es una afirmación diferente de una propuesta contra HEAD, y sin el sello nadie puede distinguir la diferencia más tarde.

Categorías

Las categorías reemplazan la noción informal de «frente» y se generan a medida que se registran funcionalidades en lugar de configurarse de antemano. Proponer una funcionalidad bajo una categoría nueva la crea, con su propio prefijo de id y contador — de modo que DIP-17 y GLG-1 coexisten sin colisionar ni ser administradas centralmente.

Compuertas: la cola de aprobación

Una compuerta es una decisión que las sesiones de trabajo no deben tomar solas.

Levantar una compuerta bloquea la sesión que la levantó. Las compuertas se ponen en cola en un solo lugar, tú apruebas, modificas o rechazas, y la sesión se reanuda. Eso es lo que convierte «esto costará 40 $, ¿te parece bien?» de un mensaje que tenías que estar vigilando en un elemento de cola que espera.

Recuentos y convergencia

El progreso se informa como dos movimientos, nunca una proporción:

3/14  ->  5/16     +2 agreed, +2 surfaced

El numerador es consenso y mide la convergencia. Que el denominador crezca es saludable — los elementos nuevos significan que se encontró un desacuerdo real que había estado ahí todo el tiempo, sin expresar.

Un porcentaje lo invierte. 12/16 -> 12/20 se lee como 75% -> 60%, una caída, cuando nada retrocedió y se nombraron dos problemas genuinos. Una proporción única castiga exactamente el comportamiento que el sistema existe para producir, así que nunca se muestra.

Condiciones de parada

El estancamiento se juzga solo por el numerador. Que surjan elementos mientras nada se acuerda es dar vueltas, e informar de eso como progreso es la forma más fácil de perder una tarde.

Puntos de control, pausa y resúmenes

Cada dos turnos el bucle se detiene e informa:

NEEDS YOU (1)
  · Is the target "one dollar per Track" or "one opportunity live"?
    Not a fact — it is what you are optimising.

HANDLED (6 of 7 tracks)      +2 agreed, +2 surfaced
  filter-decide   uncommitted migration 020 — no collision with other tracks
  layer-lift      6 behind main, clean rebase available
  ...

Puedes decir pause en cualquier momento y obtener el resumen inmediatamente, sin esperar al punto de control. Nada se ejecuta sin supervisión durante más tiempo del que permites — la autonomía comienza en dos turnos y se alarga solo una vez que se la ha ganado.

Por qué esto no está en git

El rastreador era anteriormente un archivo markdown. En una semana reciente necesitó 115 commits de worktrees concurrentes, y el historial contiene colisiones de numeración resueltas a mano. Un solo archivo bajo control de versiones ya es un punto de contención a ritmos de escritura humanos; añadir escrituras automatizadas por turno desde varias sesiones lo haría inutilizable.

Así que la base de datos es canónica y el markdown se convierte en salida generada, regenerada bajo demanda y excluida del control de versiones.

La consecuencia a aceptar deliberadamente: el historial de git era el registro de auditoría. feature_event lo reemplaza — de solo añadidura, sellado con actor y commit — y ese reemplazo es un requisito, no un lujo. De lo contrario, cambias conflictos de fusión por amnesia.

Cualquier instrucción a nivel de proyecto que nombre el archivo markdown como canónico debe reescribirse en el mismo cambio. Las sesiones obedecen esas instrucciones; si dejas una apuntando al archivo antiguo, seguirán escribiendo en algo que nadie lee.

Lo que lo romperá

Spam de propuestas. La captura por turno en varios tracks puede generar cientos de filas de bajo valor, y entonces estás leyendo un backlog en lugar de transcripciones: el mismo problema con ropa diferente. El estándar es explícito: registrar solo lo que de otro modo se perdería, es accionable y no está ya cubierto. La deduplicación es obligatoria, porque dos sesiones que notan de forma independiente la misma restricción faltante es el caso normal, no el caso límite.

Leer el árbol equivocado. Un worktree es un checkout separado. Si apuntas una sesión al equivocado, reportará tus archivos como faltantes y tus cambios como no hechos, con confianza, y de una manera que se lee como un hallazgo sobre el código en lugar de una mala configuración. Cada operación registra el árbol que leyó, por lo que el desajuste es visible antes de que alguien actúe sobre él.

Un gestor que narra en lugar de calcular. Los recuentos se calculan a partir de la base de datos y no pueden ser elocuentes sobre algo falso. Los resúmenes escritos por un modelo sí pueden. Cuando los dos discrepan, gana la tabla.

La autonomía supera a la atención. Los errores compuestos se vuelven caros más rápido cuando nadie está leyendo. Las gates y los checkpoints existen para esto, y el intervalo predeterminado es deliberadamente corto.

Orden de construcción

1. category, feature, feature_event, gate; creación de base de datos por proyecto; asignación atómica de id

2. Herramientas MCP: propose, list, update, table, history, gate raise/list/decide

3. Captura continua, con el estándar y la deduplicación, más la cola de revisión de aceptar o modificar

4. /standup en todos los tracks, incluido el trabajo sin commitear — los commits por sí solos no capturan dónde está realmente el trabajo

5. Gates que bloquean sesiones

6. /ideate

7. Bucle de ejecución que lleva una categoría a completarse en orden de prioridad