El Manager y Build

El Manager es el chat junto al tablero. Ve la descripción del proyecto, los loops, el Task Book y las últimas pasadas, así que se le puede preguntar por el tablero además de planificar con él.

Los cuatro modos

Un modo decide qué puede cambiar el Manager. La conversación se queda en un modo hasta que la persona lo cambia; el Manager nunca cambia de modo por su cuenta.

Modo	Lee los archivos del proyecto	Puede cambiar
Ask	Sí, cuando hay una carpeta vinculada	Solo PROJECT.md
Plan	Sí, cuando hay una carpeta vinculada	Tarjetas del Task Book, tras un acuerdo, y PROJECT.md
Code	Sí	Archivos dentro de la carpeta de un loop, y PROJECT.md
Build	No	Propone un tablero, que se coloca solo al pulsar Construirlo, y PROJECT.md

• Ask responde preguntas sobre el proyecto y el tablero.
• Plan convierte una conversación en tarjetas. Pregunta antes de escribirlas.
• Code edita archivos directamente, limitado a la carpeta de un loop. Si ese loop está haciendo una pasada en la misma carpeta, el turno de Code la espera.
• Build diseña loops. Ver más abajo.

Preguntas

Cuando algo importa, el Manager pregunta. Una pregunta trae de dos a seis opciones, como mucho una de ellas marcada como recomendada, y un cuadro de texto libre. No hay nada preseleccionado. Una pregunta sin responder cuenta como “sin preferencia”.

Guiar y editar

Se puede escribir mientras el Manager trabaja. El mensaje se lee en su siguiente paso, como una indicación, en lugar de esperar a que termine el turno. Editar un mensaje anterior bifurca la conversación; la otra versión se conserva.

PROJECT.md, la descripción del proyecto

La descripción de un tablero es PROJECT.md en la raíz del proyecto. Hasta que se escribe, la pestaña Tareas dice que aún no hay PROJECT.md. Pertenece al proyecto: vive en el proyecto, no en la carpeta propia de la aplicación, y está pensado para incluirse en los commits. Cada pasada de cada bubble lo lee primero.

Tiene dos secciones que la aplicación conoce:

• Rules: cómo debe construirse el proyecto. El Manager solo la cambia cuando se le pide.
• Current state: en qué punto está el proyecto.

Si se pide que el proyecto sea desplegable, el Manager añade una línea Deployable bajo Rules. Desde entonces las bubbles mantienen funcionando la compilación de producción y una configuración de despliegue junto a ella. Esto se puede desactivar desde el panel de la descripción.

Build

Build arma un tablero en dos etapas:

1. Lee lo que sabe (la descripción, el Task Book, la conversación), propone una estructura en palabras sencillas y pregunta si es correcta.
2. Tras el acuerdo, propone los loops: las bubbles de cada uno, un prompt para cada bubble, la carpeta en la que puede escribir cada loop y los Sub-loops que cuelgan de las bubbles Subloop de cada loop.

La propuesta se titula ¿Construir este tablero?, y lo que muestra junto al botón Construirlo es exactamente lo que hará Build. Build en sí no escribe código ni tarjetas, solo PROJECT.md. Al pulsar Construirlo:

• pide primero la carpeta del tablero, si un loop propuesto escribe código y no hay ninguna vinculada;
• cuando una carpeta propuesta ya pertenece a un loop, dice No se construyó nada. Una carpeta ya está ocupada. y ofrece Editar el loop existente o Reemplazar y construir;
• pregunta antes de reemplazar un prompt de equipo escrito a mano.

Un loop que construye algo que una persona mira recibe un diseñador antes de su programador y un revisor después, que hace la revisión visual. Un loop sin interfaz no recibe ninguno de los dos.

Un tablero vacío o un Task Book vacío no es un problema: cuando se sabe demasiado poco, Build pregunta.

El Task Book

El Task Book contiene las tarjetas del tablero en seis columnas: Draft, Approved, Implementing, Review, Done y Blocked.

• Los loops solo toman trabajo Approved. Draft es el filtro de la persona.
• Las tarjetas escritas a mano, y las que escribe una bubble planificadora durante un run, empiezan en Draft.
• Las tarjetas que escribe el Manager en Plan empiezan en Approved, porque ya se acordaron en el chat.
• Un loop que termina una tarjeta la mueve a Review: construida y a la espera de que el verificador del loop (el arquitecto, o quien revise el trabajo en ese loop) la acepte o la devuelva.
• Una tarjeta que espera una subtarea la nombra, con Dejar de esperar para que avance sin ella.