Roster de Agentes

1. Propósito y alcance

Esta sección define el roster completo de agentes de IA del área: la ficha operativa de cada uno de los 10 agentes, los estándares de calidad con los que se construye toda configuración, los umbrales de calibración por defecto y la infraestructura de pairing.

Contrato vs. implementación. Este documento define el contrato de cada agente: qué hace, qué lee, qué produce, qué tiene prohibido. La implementación (prompts, skills, comandos, jobs) es código: vive en una carpeta de tooling (skills/; su ubicación exacta es detalle de Tech Spec), lleva front-matter y cambia por Pull Request con aprobación del Lead (sección 08). Los prompts no se reproducen aquí — hacerlo desactualizaría este documento con cada ajuste (antipatrón A6) — pero toda implementación debe cumplir los estándares de construcción de §3, que sí son parte de este contrato.

Plantillas de artefactos. Las plantillas oficiales de cada tipo de salida (Plan, Tech Spec, verification criteria, guía de usuario, notas de versión) viven en una carpeta de tooling (templates/) — material accionable que cualquier repo jala, fuera del flujo de docs. Este documento las referencia (estándar E2); no las contiene.

Delimitación: la escalera de autonomía se define en 02 §6; la doctrina de propiedad y uso, en 03 §3; el punto de inserción de cada agente en el flujo y los dos pipelines, en la sección 05.

2. El roster de un vistazo

Diez agentes, en orden de flujo. La numeración sigue el viaje de una tarjeta: primero quien la define (Pipeline A · Definición), luego quien la construye, revisa y publica (Pipeline B · Ejecución), y al final la curaduría transversal.

#	Agente	Dueño	Opera	Pipeline · Momento
①	Idea Enricher	Director	Director / Lead	A · Backlog — enriquece la solicitud a tarjeta
②	Product Architect	Director	Director	A · Product Architect — escribe el Requirement
③	Spec Writer	Lead	Lead	A · Tech Specs — Tech Spec + Capa 1 + crea la tarjeta de ejecución
④	Independent Reviewer	Lead	Lead	A y B · revisa plan (Product Architect), diseño (Design), código (In Review)
⑤	QA Runner	Lead	Developer	B · In Review — verifica contra staging
⑥	Session Wrap-up	Lead	Developer	B · Build — /start al abrir · /wrap-up al cerrar → Staging Validation
⑦	Publisher	Lead	Lead	B · Staging Validation → merge a main → release + docs → Published
⑧	User Guide & Comms	Director	Lead	B · Published — disparo aparte (clic en campo)
⑨	Ops-Health Monitor	Lead	Lead	B · Ops Health (carril) · Published → Done
⑩	Knowledge Curator	Director	— (ritual)	Transversal · semanal

Design es una fase atendida del Pipeline A (un humano diseña con tooling), no un agente — ver §6. El developer opera dos agentes (⑤ QA Runner y ⑥ Session Wrap-up); el Lead opera dos (⑦ Publisher y ⑧ User Guide & Comms).

3. La ficha estándar del agente

Todo agente se documenta con la misma ficha de nueve campos. El registro de agentes en SeaTable usa este mismo esquema: el registro contiene el estado vivo (nivel de autonomía vigente, estado de activación, fecha de última calibración); este documento contiene el contrato. Ante diferencia de estado, el registro manda; ante diferencia de contrato, este documento manda.

Campo	Contenido
Identidad	Número, nombre, pipeline/columna, dueño (rol), usuarios (roles)
Disparador	Evento que lo activa
Entradas	Qué lee, y de dónde
Salidas	Qué produce, y dónde lo escribe
Permisos	Qué puede hacer — y qué tiene explícitamente prohibido
Plataforma	Dónde corre (skill, comando, Action, job)
Autonomía inicial	Nivel de arranque (el vigente se consulta en el registro)
Calibración	Umbrales aplicables (default de §5 o acuerdo específico dueño–Lead)
Configuración	Ruta de su implementación

4. Estándares de construcción de configuraciones

Norma obligatoria para toda configuración de agente (prompt, skill, comando o job). Ningún PR de configuración se aprueba si incumple alguno. ④ Independent Reviewer verifica E5, E8 y E10 de forma automática cuando la configuración pasa por un repositorio que él cubre.

E1 · Identidad y límite explícito. Toda configuración abre declarando qué es el agente y qué no hace — en particular, las decisiones que nunca toma (“produces un borrador; nunca apruebas”, “reportas la Deviation; nunca la absorbes”). El límite es parte del prompt, no un supuesto.

E2 · Salida estructurada conforme a plantilla. Toda salida sigue la plantilla oficial de templates/ para su tipo de artefacto (Plan, Tech Spec, verification criteria, hallazgo de review, nota de versión). Si la salida alimenta un KPI, su formato es parseable por diseño (p. ej., hallazgos de ④ etiquetados con ID de regla).

E3 · Declaración de límites de conocimiento. El agente declara fuentes consultadas y vacíos de cobertura. Prohibido rellenar un vacío con contenido no documentado: lo que la Base no dice, se declara como vacío — nunca se improvisa. Cuando el agente deba inferir (p. ej. ① al deducir un pain point no declarado), marca la inferencia como tal para revisión humana; nunca la presenta como hecho. Es la codificación del principio P2.

E4 · Fecha y fuente en todo dato. Toda afirmación tomada de la Base cita su documento de origen; el contenido que excede el umbral de last_verified se entrega marcado como no verificado (P3).

E5 · Seguridad y mínimo privilegio. La configuración enumera de forma explícita su alcance de escritura; todo lo no enumerado está prohibido. Nunca obtiene, almacena ni reproduce secretos — transmite el enlace de 1Password. Nunca ejecuta acciones del nivel de autonomía superior al vigente en el registro.

E6 · Idioma y audiencia. La nomenclatura y los identificadores del sistema van en inglés; la prosa de las salidas de cara al equipo sigue el idioma de la Base (español); las de cara al usuario final (⑧), en español, conforme a las plantillas de guía.

E7 · Comportamiento ante falta de información. Si el agente no puede completar su tarea con las entradas disponibles, declara el bloqueo y se detiene — no improvisa un resultado parcial presentado como completo. Toda configuración define su ruta de escalamiento al dueño.

E8 · Casos de regresión adjuntos. Toda configuración incluye casos de regresión del prompt (entrada → salida esperada) en su carpeta de skills/<agente>/. El PR que modifica un prompt corre estos casos antes del merge; un cambio que rompe casos existentes requiere actualizarlos justificadamente. Es la suite de regresión de los prompts — la garantía de que editar un agente no lo degrada. No debe confundirse con el verification criteria (que prueba la app construida, no el agente) ni con la revisión de artefacto de ④ (que juzga el trabajo de una fase). El caso de regresión prueba al agente; el dueño humano responde por él (P6).

E9 · Trazabilidad de artefactos. Toda salida escrita en SeaTable o en la Base identifica al agente que la produjo y la versión de configuración usada, para que los veredictos de calibración e incidentes sean atribuibles.

E10 · Front-matter de la configuración. Toda configuración lleva owner, version, last_verified y referencia a su ficha — la misma disciplina que el resto de la Base.

5. Calibración: umbrales por defecto

Marco general en 02 §6 (ascenso con evidencia, descenso por incidente). Defaults aplicables a todo agente salvo acuerdo específico dueño–Lead registrado en su ficha:

Transición	Volumen mínimo	Veredictos “sin cambios”	Incidentes en la ventana	Condición adicional
L1 → L2	20 salidas revisadas	≥ 80%	0	—
L2 → L3	60 ejecuciones	≥ 95%	0	Nunca antes de 2 trimestres de operación

El veredicto se emite con el registro de un clic (sin cambios / cambios menores / mayores) durante la ventana de calibración; la ventana se cierra al formalizarse el ascenso y se reabre ante cualquier descenso. Un incidente (02 §6) provoca descenso inmediato de un nivel y revisión de configuración antes de un nuevo ascenso.

6. Fichas de los agentes

① Idea Enricher

Campo	Definición
Identidad	Pipeline A · Backlog · Dueño: Director · Usuarios: Director, Lead
Disparador	Solicitud planteada en el chat del sitio de documentación
Entradas	La solicitud cruda · Base de Conocimiento (para aterrizar contra lo ya documentado) · inventario de aplicaciones (SeaTable, en vivo)
Salidas	Tarjeta en Backlog con título, recorrido who/what/outcome y línea de Pain point · primer puntaje impacto/facilidad para triage
Permisos	Hace preguntas base antes de crear; crea la tarjeta en Backlog. Cuando la solicitud no declara su porqué, infiere el más plausible y lo marca Pain point (inferido) para que el humano lo refine — nunca lo presenta como declarado. Prohibido: comprometer alcances, fechas o prioridad; crear tarjetas de ejecución en el Pipeline B
Plataforma	Chat interactivo sobre el sitio de documentación + SeaTable API
Autonomía inicial	L1
Configuración	skills/01-idea-enricher/

② Product Architect

Campo	Definición
Identidad	Pipeline A · Product Architect · Dueño: Director · Usuario: Director
Disparador	Tarjeta priorizada que entra a la columna Product Architect
Entradas	Problema planteado · Base de Conocimiento (decisiones previas, patrones de KPI) · inventario de aplicaciones (SeaTable, en vivo) · plantilla de Plan
Salidas	Requirement (la parte del Plan: qué y por qué, con criterios de experiencia verificables)
Permisos	Lectura de Base y SeaTable; escribe el Requirement del Plan. Prohibido: comprometer alcances o fechas; redactar la parte técnica (corresponde a ③)
Plataforma	Skill de Claude (entorno del Director)
Autonomía inicial	L1
Configuración	skills/02-product-architect/

③ Spec Writer

Campo	Definición
Identidad	Pipeline A · Tech Specs · Dueño: Lead · Usuario: Lead
Disparador	Requirement aprobado por el Director (y diseño aprobado, si la tarjeta pasó por Design)
Entradas	Requirement · Base de Conocimiento (Capa A + Capa B de la app: architecture.md, integrations.md, decisions/, notas de módulo) · inventario (SeaTable, en vivo)
Salidas	(a) Tech Spec que completa el Plan — el cómo, con vacíos y preguntas abiertas obligatorios · (b) criterios de aceptación (Capa 1) · (c) tarjeta de ejecución creada en Queue del Pipeline B
Permisos	Escribe el Tech Spec (L1). Crea la tarjeta de ejecución y congela la Capa 1 con confirmación del Lead (L2). Prohibido: modificar código; alterar decisiones vigentes sin proponerlas como ADR nuevo; tocar la Capa 1 una vez congelada
Plataforma	Skill de Claude (entorno del Lead) + SeaTable API
Autonomía inicial	L1 para el Tech Spec; L2 para la creación de tarjeta (mecánico, verificable de inmediato)
Configuración	skills/03-spec-writer/

③ absorbe los agentes previos Test Plan Writer y Card Generator: el Tech Spec, los criterios de aceptación y la tarjeta son un mismo momento de autoría. El ensamblaje del contexto de la tarjeta (antes función del agente Context Courier) ocurre aquí — el Plan es el paquete de contexto de la tarjeta (02 §4). El contexto de estado del sistema (dónde está staging, migraciones, ramas) no lo da el Plan sino ⑥ Session Wrap-up.

④ Independent Reviewer

Campo	Definición
Identidad	Pipeline A y B · Product Architect, Design, In Review · Dueño: Lead · Usuario: Lead
Disparador	Cierre de una fase generativa: Plan listo (Product Architect), diseño listo (Design), PR abierto hacia staging (In Review)
Entradas	Solo el artefacto de la fase (plan / diseño / diff del PR) — sin el resumen ni la intención del autor, para preservar la independencia · criterios de review codificados por columna, con ID de regla · estándares de Capas A y B
Salidas	Veredicto BLOQUEANTE / NO-BLOQUEANTE / LIMPIO + hallazgos en la tarjeta (hallazgo = ID de regla, archivo, severidad), almacenados para el KPI de reincidencia
Permisos	Comenta y emite veredicto; nunca edita el artefacto — la revisión (el arreglo) se queda con la fase que lo produjo. Prohibido: aprobar, rechazar o mergear; bloquear el pipeline. El humano decide siempre
Plataforma	Agente fresco en modelo distinto al autor; GitHub Action en runners self-hosted para código; skill para plan y diseño
Autonomía inicial	L1
Configuración	skills/04-independent-reviewer/ + workflow en cada app

Mecánica del loop. El bucle termina siempre en una revisión, nunca en una promesa: se revisa → si BLOQUEANTE, la fase autora corrige → se revisa de nuevo → se detiene al tope (max_review_rounds, default 1). En una re-revisión, cada hallazgo previo se rinde individualmente (corregido / parcial / no atendido / rebatido con razón). Un veredicto LIMPIO carga la obligación de nombrar qué se intentó romper; una racha de puros LIMPIO es en sí un hallazgo (el revisor no está mordiendo). ④ redefine al agente previo PR Pre-Reviewer: de pre-revisor de PR a revisor independiente por fase.

⑤ QA Runner

Campo	Definición
Identidad	Pipeline B · In Review · Dueño: Lead · Usuarios: Developers
Disparador	El developer lo corre sobre su trabajo antes de dar la tarjeta por lista
Entradas	Build en staging · Capa 1 congelada + enmiendas autorizadas · verification criteria (Capa 2)
Salidas	verification criteria actualizado contra lo construido (Capa 2) · filas en la tabla Deviations (una por diferencia con Capa 1) · resultados de ejecución en la tarjeta
Permisos	Escribe la Capa 2, crea filas en Deviations, escribe campos de QA. Prohibido: modificar la Capa 1 bajo cualquier circunstancia — es la regla dura del modelo (P5, A4)
Plataforma	Skill qa-runner (navegando staging) + SeaTable API
Autonomía inicial	L1
Configuración	skills/05-qa-runner/

⑤ reformula al agente previo Test Plan Updater + QA Runner: retirado el xlsx, la Capa 2 es el verification criteria generado contra lo construido — un checklist versionable, no una hoja de cálculo pasiva (A3). El verification criteria prueba la app; no debe confundirse con los casos de regresión de prompts (E8, que prueban al agente). Lo opera el developer, que hace QA primario de su propio trabajo; el dueño de su configuración es el Lead.

⑥ Session Wrap-up

Campo	Definición
Identidad	Pipeline B · Build · Dueño: Lead · Usuarios: Developers
Disparador	/start al abrir una sesión · /wrap-up al cerrarla (requisito para mover la tarjeta de columna)
Entradas	/start: status.md de la app + Plan de la tarjeta + estado del sistema vivo · /wrap-up: diff y estado git de la sesión + tarjeta
Salidas	/start: punto de arranque de la sesión (lee el estado, verifica contra el sistema vivo, entrega el contexto de estado). /wrap-up: verificación de convención de commits · push · PR · campos Github PR, Env Variables, Data Model Changes · actualiza status.md (ramas, commits, migración, PR, y las correcciones de documentación detectadas) · emite el prompt de arranque de la siguiente tarjeta del proyecto · nota de sesión (Session Log) · candidatos a Learnings · en Ops Health: captura retroactiva
Permisos	Push a ramas de trabajo y apertura de PR con confirmación (L2); escribe los campos listados y status.md. Prohibido: merge a main; editar Acceptance Criteria; cerrar tarjetas; escribir en docs/ — hereda el carril del Developer que lo opera (03 §7.5.1), así que una corrección de documentación se registra en el status.md, no se aplica
Plataforma	Comandos de Claude Code (/start, /wrap-up) + hook de formato de commit
Autonomía inicial	L2 (mecánico, verificable de inmediato)
Configuración	skills/06-session-wrap-up/ (comandos distribuidos por la infraestructura de pairing)

Un solo agente, dos comandos — las dos caras del ciclo del contexto en cada extremo de la sesión (/start abre leyendo el estado; /wrap-up cierra escribiéndolo). El cierre del developer suelta la tarjeta a Staging Validation y le permite tomar la siguiente sin dejar cabos; no toca main. La publicación a main es de ⑦ Publisher. Se separarán en dos fichas solo si la práctica lo exige.

⑦ Publisher

Campo	Definición
Identidad	Pipeline B · Staging Validation → Published · Dueño: Lead · Usuario: Lead
Disparador	El Lead autoriza la publicación (decisión humana; no se infiere de una columna)
Entradas	Rango de cambios en Staging Validation · status.md (estado de despliegue) · Depends on de las tarjetas · commits con IDs de tarjeta · Base
Salidas	(a) Pre-vuelo: qué en el rango nunca se ejecutó realmente (advierte antes de promover) · (b) merge a main · (c) cierre pesado de release: validación de que cada claim de deploy es cierto ahora, notas de versión (SeaTable + Teams), PRs de actualización a la Base (docs/internal, docs/agent) incluyendo las correcciones que los Developers registraron en el status.md, regeneración de la vista técnica · (d) tarjetas a Published
Permisos	Ejecuta el merge a main con autorización del Lead; escribe a la Base solo vía PR; publica notas por los canales existentes. Prohibido: tocar código de aplicación; publicar vistas sin fuente en la Base; promover sin la autorización humana
Plataforma	Comando /publish + job dentro del pipeline CI/CD existente (semantic-release)
Autonomía inicial	L1
Configuración	skills/07-publisher/

⑦ fusiona el publish (pre-vuelo + merge), el wrap-up pesado de release y el agente previo Release & Docs Updater en un solo momento operado por el Lead: autoriza → promueve → consolida release y docs → Published. La documentación conciliada aquí es condición de Done (ver §8): la tarjeta no cierra hasta que la doc está completa. Si la práctica exige aislar la configuración de release, ⑦ puede escindirse; hoy es un solo agente.

⑧ User Guide & Comms

Campo	Definición
Identidad	Pipeline B · Published · Dueño: Director · Usuario: Lead (dispara)
Disparador	Clic en el campo User Guide de la tarjeta (disparo aparte, posterior a la publicación)
Entradas	verification criteria verificado (el paso a paso real, por construcción) · Base · notas de versión
Salidas	Guía de usuario paso a paso (español) → docs/public/<iface>/ de la app, declarando la audiencia a la que escribe · guion de tutorial/video (producción del video: D8) · mensaje de novedades → webhook de Teams. Todo como borrador a revisión del Director; publicación tras aprobación
Permisos	Escribe borradores vía PR; publica solo tras aprobación (L1). Prohibido: publicar sin revisión; documentar funcionalidad sin verification criteria verificado que la respalde; escribir en una interfaz sin audiencia declarada, o dirigir una guía a una audiencia que esa interfaz no sirve — una guía en el portal equivocado es una fuga, no un error de estilo
Plataforma	Job post-release + webhook de Teams existente
Autonomía inicial	L1
Configuración	skills/08-user-guide-comms/

El dueño es el Director (responde por la documentación de cara al usuario), pero lo dispara y opera el Lead con un clic cuando decide que la guía debe generarse. Es un disparo aparte del Publisher: no toda publicación genera guía de usuario.

La audiencia es parte de su entrada, no un detalle de formato. Antes de redactar, ⑧ lee el docs/_meta.yml de la app para saber qué interfaces existen y a quién sirve cada una: la misma funcionalidad se explica distinto a un proveedor que a un colaborador, y una pantalla común necesita una guía por audiencia o una redactada para las dos. Si la interfaz no declara audiencia, se detiene y lo reporta (E7): no la infiere.

⑨ Ops-Health Monitor

Campo	Definición
Identidad	Pipeline B · Ops Health (carril de prioridad) y Published→Done · Dueño: Lead · Usuarios: Lead
Disparador	Job programado nocturno
Entradas	Pipelines de servicios externos monitoreados · tarjetas en Published (para verificar first-fire) · estado de documentación de la tarjeta
Salidas	(a) Hallazgos e incidentes archivados en Ops Health (un problema → tarjeta nueva) · (b) transición de Published → Done cuando el first-fire corre limpio ✚ la documentación está completa
Permisos	Archiva hallazgos en Ops Health; mueve Published → Done con confirmación (L2). Prohibido: reabrir tarjetas cerradas; mover a Done sin las dos condiciones cumplidas
Plataforma	Job programado (mismo patrón de las automatizaciones agendadas existentes)
Autonomía inicial	L2 (mecánico y verificable de inmediato; Done no es puerta destructiva — un incidente posterior genera tarjeta nueva)
Configuración	skills/09-ops-health-monitor/

⑩ Knowledge Curator

Campo	Definición
Identidad	Transversal (semanal) · Dueño: Director · Usuarios: todo el equipo (ritual)
Disparador	Job programado semanal, previo a la reunión de equipo
Entradas	Session Log y Learnings de la semana · hallazgos de ④ (leídos de vuelta) · Base actual (para detectar duplicados y destino)
Salidas	(a) Candidatos de promoción de learnings → Base, con borrador del texto y ubicación propuesta · (b) hallazgos de review repetidos 3+ veces, agrupados por causa (no por redacción) → propuesta de regla que nombra la línea del prompt o del estándar que reemplaza → agenda del ritual
Permisos	Solo lectura + escribe la lista de candidatos. Prohibido: escribir a la Base o a las reglas directamente — la promoción es humana (P4)
Plataforma	Job programado (mismo patrón de las automatizaciones agendadas existentes)
Autonomía inicial	L1
Configuración	skills/10-knowledge-curator/

⑩ absorbe la función review-harvest con su umbral: solo propone una regla cuando un hallazgo se repite 3+ veces, y la regla nueva nombra la que reemplaza (un prompt largo con una regla que no reemplaza nada debilita a las demás). Lee dos señales agregadas primero: todo LIMPIO = el revisor no muerde; todo BLOQUEANTE = las fases fallan o el listón está mal puesto. Sin solapamiento con ⑨: ⑩ propone conocimiento cross-app; ⑨ archiva un problema de un repo como tarjeta.

7. Design — no es un agente

La columna Design del Pipeline A es una fase atendida: un humano diseña con tooling (conector claude.ai/design), no un agente autónomo. No todas las tarjetas la cruzan. Sus artefactos (mockups, biblioteca de diseño) viven en docs/internal/design/<módulo>/; las decisiones de diseño en markdown llevan agent:true, los mockups no entran al corpus. Su desarrollo como fase corresponde a la sección 05. Se documenta aquí solo para dejar constancia de que Design es flujo, no roster.

8. Infraestructura de pairing

No es un agente (03 §3.3): es la configuración estandarizada de Claude Code que hace idéntica la sesión de desarrollo de los tres Developers y es la vía por la que la Base llega a cada sesión. Dueño: Lead; cambia por PR como toda configuración. Componentes:

• CLAUDE.md por repositorio — la constitución: convenciones del repo, arquitectura en síntesis, referencias a la Capa B. Prohibido usarlo como diario (A2) o como fuente de conocimiento durable (A8); es una proyección generada desde la Base, estable y curada.
• Skills compartidas — capacidades reutilizables del equipo, distribuidas desde skills/.
• Comandos — /start y /wrap-up (⑥) como mínimo; nuevos comandos se proponen por PR.
• Hooks — verificación de formato de commit (tipo(card-id):) y las validaciones deterministas que el Lead defina.
• status.md por app, en la raíz del repo — el puente de estado entre sesiones: lo escribe /wrap-up, lo lee /start. Transversal a la app, efímero, se verifica contra el sistema vivo (no es fuente durable). Va en la raíz y no en docs/ porque su autor es el Developer, cuyo carril de escritura excluye docs/ (03 §7.5). El estado por-tarjeta vive en SeaTable; lo durable se promueve. Su forma exacta se define en la sección 06.

9. Activación y estado

El estado de activación y el nivel de autonomía vigente de cada agente se consultan en el registro de agentes de SeaTable — nunca en este documento (el equivalente para agentes de la regla “roles, no personas”). Al publicarse esta versión, los 10 agentes están en estado no activado.

El encendido de agentes no es el arranque del piloto. Por el principio de lanzamiento estrecho (Base primero, agentes después), primero existe la app con su Base poblada; solo entonces se encienden agentes sobre ella. La secuencia del piloto es: construir y adaptar la app → poblar y verificar su Base → encender agentes en el orden de abajo. El pipeline de definición del propio piloto lo ejecutan humanos —la definición y el Plan de la plataforma son este trabajo de rediseño; el documento de arquitectura de la plataforma es el Tech Spec que se entrega al desarrollador— porque ningún agente existe todavía. No hay, en ningún momento, construcción sin Plan.

Una vez la app está en marcha y su Base poblada, el orden de encendido sigue el viaje de una tarjeta:

Orden	Agente	Etapa del viaje	Razón
1	② Product Architect	Define	Sin Requirement no hay Plan; sin Plan no hay nada aguas abajo
2	③ Spec Writer	Define	Completa el Plan (Tech Spec + Capa 1) y crea la tarjeta de ejecución
3	⑥ Session Wrap-up	Construye	Abre y cierra cada sesión de Build; sin él no se mueven tarjetas
4	④ Independent Reviewer	Revisa	Ya hay Plan y código que revisar; la palanca de calidad
5	⑤ QA Runner	Prueba	Genera el verification criteria contra lo construido
6	⑦ Publisher	Publica	Autoriza, promueve y consolida release + docs
7	⑨ Ops-Health Monitor	Cierra	Carril de prioridad y transición a Done
8	⑧ User Guide & Comms	Publica	Salida pública, disparo aparte
9	① Idea Enricher	Alimenta	Enriquecimiento de solicitudes en Backlog
10	⑩ Knowledge Curator	Cura	Curaduría transversal, una vez que hay flujo acumulado que curar

10. Relación con el resto de la documentación

Para conocer	Sección
La escalera de autonomía (definiciones, ascenso, descenso)	02 §6
Propiedad, uso, incidentes y delegación	03 §3
Anatomía conceptual del contexto y del Plan	02 §4.1
El punto exacto de inserción de cada agente en el flujo y los dos pipelines	05
La columna Design como fase atendida	05
El status.md y la separación de capas de conocimiento	06
La tabla Deviations, los timestamps y campos que los agentes escriben	07
La regla “una columna sin lector automático no es un estado”	07
El régimen de cambios de configuración (PR + aprobación del Lead) y la independencia de herramienta	08
Las plantillas oficiales de cada artefacto	templates/

---

Historial de versiones

Versión	Fecha	Cambio
v2.4	2026-09-04	Fronteras de escritura aplicadas al roster: ⑥ Session Wrap-up hereda el carril del Developer y tiene prohibido escribir en docs/ — registra las correcciones de documentación en el status.md; ⑦ Publisher las aplica a la Base al conciliar el release. El status.md se ubica en la raíz del repo (§8).
v2.3	2026-09-03	Ficha de ⑧ User Guide & Comms actualizada por el eje de audiencia (06 v2.0): escribe en docs/public/<iface>/ declarando audiencia, lee el _meta.yml de la app como entrada, y se le prohíbe explícitamente dirigir una guía a una audiencia que la interfaz no sirve.
v2.2	2026-09-03	Rutas de tooling sin dev-standards/: la implementación de cada agente vive en skills/ y las plantillas en templates/, como código/config fuera del flujo de docs (§1, E2, E8, las diez fichas, §8, §10). Sin cambios de contrato.
v2.1	2026-09-01	Roster ajustado tras contrastar contra el pipeline probado en producción. Session Wrap-up vuelve como ficha propia (⑥), operado por el developer, con dos comandos (/start abre leyendo el estado, /wrap-up cierra escribiéndolo en status.md y emite el prompt de arranque de la siguiente tarjeta). Nace ⑦ Publisher (operado por el Lead): fusiona publish + wrap-up pesado + Release & Docs en un solo momento (autoriza → merge → release/docs → Published). ⑧ User Guide como disparo aparte (clic en campo), operado por el Lead. Tabla resumen del roster (§2). ④ Independent Reviewer: recibe solo el artefacto (sin intención del autor), no edita, loop con tope, regla del veredicto LIMPIO. ⑩ conserva el umbral de review-harvest (3+, por causa, nombra lo que reemplaza). ① marca Pain point (inferido). status.md documentado en la infraestructura de pairing. El developer opera ⑤+⑥; el Lead opera ⑦+⑧.
v2.0	2026-09-01	Reforma inicial de la sesión: roster 11 → 10, renumerado en orden de flujo; disueltos Test Plan Writer, Card Generator y Context Courier; PR Pre-Reviewer → Independent Reviewer; QA Runner sin xlsx; Knowledge Curator absorbe review-harvest; nuevos Idea Enricher y Ops-Health Monitor; E6/E8 actualizados; §4 (spec del brief) → referencia a templates/; Design como fase; configuraciones en skills/; front-matter YAML; destino docs/internal/.
v1.0	2026-07-03	Versión inicial: ficha estándar de nueve campos; estándares E1–E10; especificación del brief; umbrales de calibración; las 11 fichas; infraestructura de pairing; orden de activación.