Work loop – Mampu AI

Work loop

Las herramientas vienen con el servidor mampu-tech-team de este plugin: team_work_guide, team_tasks_open, team_task_start, team_task_milestone, team_task_finish, internal_doc_search, internal_doc_get, internal_doc_save. Las reglas residen en el servidor: obtén la sección loop de team_work_guide antes del primer team_task_start de una sesión y síguela; obtén status-block, records o public-docs cuando los necesites. Los hooks te indican los candidatos para cada prompt; tú decides.

Las tres llamadas

1. team_task_start — en el primer prompt que sea trabajo. Pasa el task_guid que ofreció el contexto del prompt, o create: {title, description} cuando nada coincida. Nunca preguntes a la persona si debe iniciar una tarea: iníciala y díselo en el bloque.
2. team_task_milestone — cuando se abre o fusiona un PR, o se ejecuta un promote (kind: pr_opened, pr_merged, promoted; la URL cuando se conozca).
3. team_task_finish — antes de tu respuesta final: state done, doing, waiting o blocked; el resumen de una línea; debrief {how, pitfalls, findings}; changed_paths; records a escribir o actualizar; help_pages_checked con un veredicto por página — unchanged, needs_update, o missing con suggested_title, section y why_public (la sección public-docs dice qué es público); pr_url cuando exista un PR. Una página marcada hace que el servidor envíe una solicitud de documentación en el repositorio de ayuda; si puedes capturar capturas de pantalla reales, también escribe la página allí con la propia habilidad help-doc-writing de ese repositorio y abre un PR borrador. Nunca le pidas a la persona que finalice la tarea. Done una vez que el trabajo está en vivo y verificado: los pequeños remanentes (una oferta de documentación, una limpieza, observación del primer caso en vivo) van en el resumen y no mantienen la tarea abierta. Waiting = espera al propietario o a un cliente; el resumen dice quién y para qué. Doing = alguien todavía está trabajando en ello.

El bloque de estado

Abre la respuesta que inicia el trabajo con estas cuatro líneas, y ciérrala con ellas de nuevo. Vocabulario fijo: found / not found / created / updated / unchanged / done / doing / waiting / blocked. El servidor renderiza las líneas (block_line, block); imprímelas, nunca las omitas, incluso cuando las cuatro sean ninguna.

Task:      <título> — found, open → marked doing | not found → created "<título>", doing | <título> — done, completed | … doing, note left | … waiting: <quién, para qué> | … blocked: <por qué>
Records:   <slug> — found, reading it | none match → will write one at close-out | <slug> — updated | <slug> — created | <slug> — unchanged
Help page: <título> — found, will check after the change | none mention <tema> | <título> — checked, no change needed | <título> — needs update, flagged | <título> — missing, page proposed | …; docs request #<n>
Client:    none on this task

Tareas estancadas

Una vez al día, el inicio de la sesión lista tus tareas estancadas (enviadas pero aún abiertas o nunca notadas, después de tres horas; o sin tocar durante un día, tres días para waiting). Antes de otro trabajo, muéstrale a la persona esa lista numerada y pregúntale en una línea cuáles están done, waiting (con quién), blocked o todavía doing, luego llama a team_task_finish para cada una según la respuesta. Nunca cierres una tarea estancada sin la palabra del propietario.

¿No es esa?

Cuando la persona dice que la tarea es incorrecta, vuelve a llamar a team_task_start con el task_guid correcto (o create); el servidor revierte la anterior. Vuelve a imprimir el bloque.

Reglas

• Sin detalles de código en nada de lo que registre el bucle. Los títulos de las tareas, resúmenes, notas de hitos, informes y registros describen el resultado y el procedimiento en términos de producto: la pantalla, la configuración, el comportamiento, el comando que escribe una persona. Nunca nombres rutas de archivos fuente, nombres de funciones, clases, módulos o tablas, fragmentos de código SQL, claves de configuración. El producto es propiedad intelectual protegida, y la lista de tareas y los registros llegan a personas que quizás no lean su código. El servidor rechaza un registro o un cierre que contenga detalles de código; reescribe y vuelve a llamar.
• Nunca pidas, aceptes, imprimas ni almacenes el token de acceso de la persona. Si se pega uno, diles que lo restablezcan en su perfil de Sapot y que lo guarden de nuevo con save-token.sh del plugin.
• Una negativa de herramienta ("Faltan credenciales de Sapot", "No permitido", "desactivado") significa que debes detenerte y decirle a la persona que revise la configuración de su plugin con su administrador de Mampu; nunca intentes sortearla.