Por qué existe el archivo
El trabajo saca cosas a la luz. Un permiso que nadie otorga, una pantalla que carga registros que nunca muestra, un defecto junto al que reportaste. Nada de eso le toca a la tarea que lo encontró — una corrida que amplía su propio alcance es una corrida que nadie acordó — así que el comando lo nombra al final de su reporte y sigue.
Un reporte desaparece cuando termina la conversación. Por eso lo que un comando notó también se escribe en todos.md, un documento de tu proyecto en el toolkit, junto a la carpeta de análisis. Lo lees en la sección Proyectos; no es un archivo de tu repositorio. Cuando ya no queda nada urgente, ese único archivo te dice qué vale la pena hacer después.
Hay uno por proyecto, nunca uno por módulo, y se escribe en tu idioma. El primer comando que tiene algo que escribir lo crea.
Es una lista, no un plan
Una fila dice qué está mal y dónde. Decidir qué hacer con eso le toca al paso de planeación, y construirlo al paso de construcción. Cuando le pides a /plan-prompt algo que coincide con una fila, lee el archivo y trata tu petición como esa fila que se retoma, no como trabajo nuevo.
Cómo se ve una fila
El archivo tiene tres secciones, en este orden: Alta, Media y Baja. Cada fila lleva cinco cosas:
- El área del producto, en negritas — la que nombraría una persona, como Facturación o Administración.
- Qué está mal, en una o dos frases sencillas, nombrando la pantalla, el flujo o el registro, para que alguien que no estuvo ahí pueda juzgar si importa.
- Dónde se encontró — el trabajo que lo sacó a la luz.
- La fecha.
- El comando que la escribió.
Nada más: ni estado, ni responsable, ni estimación. Una fila que necesita cualquiera de esas cosas dejó de ser un hallazgo y pide un plan.
En qué sección va
La prioridad depende de lo que cuesta dejarlo así, nunca de lo difícil que parezca arreglarlo.
- Alta — alguien pierde datos, ve algo que no debería o no puede terminar algo que el producto promete. También todo lo que empeora conforme crecen los registros o los usuarios.
- Media — funciona, pero mal o con desperdicio, de una forma que una persona notaría: una pantalla lenta, una regla aplicada en un lugar y no en su gemelo.
- Baja — hoy no hay nada roto: configuración muerta, un permiso sin usar, una duplicación que todavía no causó un defecto.
Cuando dos lecturas son discutibles, gana la más baja. Una lista donde todo es Alta no ordena nada.
Qué se escribe y qué no
Solo lo que está cerca del trabajo que lo encontró: los mismos archivos, pantallas o flujos que la tarea ya tocó. Algo que se notó en un desvío hacia un área sin relación se descarta: un hallazgo sin contexto alrededor es uno con el que nadie puede hacer nada.
Tres cosas nunca se vuelven una fila:
- Un defecto en el trabajo de la propia tarea. Un comportamiento incorrecto en la pantalla o el flujo que la tarea está construyendo, revisando o documentando se corrige en la misma corrida, no se deja para después.
- Una decisión. Una fila dice qué está mal; nunca le pide a nadie que elija. Lo que solo tú puedes resolver se pregunta — al plan, cuando lo hay — o se nombra en el reporte.
- Código que es de otro repositorio. Va a ese repositorio como una solicitud, como explica Mandar un defecto al repositorio que lo posee.
El mismo hallazgo que vuelve a aparecer no es una fila nueva; la que ya está se deja como está. Antes de guardar una fila, el comando que la escribe revisa que lleve las cinco partes de arriba y que esté en la sección correcta.
Escribir una fila no es una invitación a investigarla. Lo que entra es lo que se notó, al costo con que se notó.
Quién agrega una fila y quién la quita
Cualquier comando que encuentra algo cerca de su trabajo agrega la fila. Uno que solo reporta nunca quita ninguna. Uno que no escribe ningún documento — la revisión en el navegador /test, por ejemplo — tampoco escribe filas: le entrega sus filas a quien lo llamó, para que la corrida que actúa sobre un hallazgo sea la que lo anota.
Quien lo arregla quita la fila, en la misma corrida que el arreglo, sea que el arreglo se planeó desde esta lista o que pasó por ahí. Una fila se quita solo cuando la corrida puede decir qué cambió que hace falsa la fila; cuando no puede sin ir a mirar, la fila se queda y el reporte lo dice.
Nada más quita una fila por su cuenta. Ningún comando poda filas que no arregló, las da por vencidas o reescribe lo que escribió otro. Un hallazgo que nadie ha arreglado sigue siendo cierto, por viejo que sea.
Tú sí puedes. Pídele a cualquier comando, /cloud-doc incluido, que agregue, cambie o quite una fila y lo hace — una fila que tú pides lleva las mismas cinco partes. O abre todos.md en Tus proyectos y sus documentos y edítalo a mano.
Sigue por aquí
- Planear antes de construir — qué pasa cuando retomas una fila.
- Correr la cola con /next — trabajar los planes que salen de esta lista.
- Lo que el analizador no puede revisar — el otro tipo de cosa que una persona tiene que mirar.