Glosario

Términos del modelo operativo, en orden alfabético. La nomenclatura del sistema (nombres de artefactos, columnas, agentes, estados) va en inglés; la prosa, en español. Cada término remite a la sección donde se desarrolla.

Audiencia — el eje que decide a qué sitio va un documento de cara al humano. No es “interno vs. externo”: es la calidad en la que la persona actúa, y una misma persona puede estar en dos (un empleado es proveedor cuando carga sus datos de pago y colaborador cuando aprueba una orden). Lista cerrada, alineada a los tipos de rol de Core Identity: equipo (docs/internal/), collaborators, vendors y customers (docs/public/<iface>/). Es propiedad del documento, no de la app: se declara por interfaz en el docs/_meta.yml del repo. (06 §6.1, 06a.)
Carril de escritura — las rutas de un repositorio en las que un rol puede escribir. Tres techos distintos: el Director no escribe código; el Lead escribe en todo, incluido docs/; los Developers en todo menos docs/. Un agente o asistente hereda el carril de quien lo opera. No es permiso de merge: skills/ está en el carril del Director y aun así cambia por PR del Lead. (03 §7.5.)
Base de Conocimiento — conjunto de documentos estructurados, verificados por humanos, con fecha y fuente, que alimentan cada tarea de trabajo (Capas A y B). Reside en Git, cambia por PR y es la fuente única de las vistas humanas. (Definición completa: 02 §3.)
Capa 1 / Capa 2 — las dos capas de la verificación: contrato (criterios de aceptación, congelados al cruzar el Ready gate) / mapa de ejecución (verification criteria, se actualiza contra lo construido). (02 P5.)
Carril de prioridad (Ops Health) — vía por la que un hallazgo o incidente entra al Pipeline B y salta la cola directo a Build, sin pasar por el Pipeline A. Reconcilia la columna Troubleshooting vigente. (05.)
Casos de regresión (E8) — entradas con salida esperada que prueban que un agente (su prompt) no se degradó al editarlo; corren en el PR de configuración. Distintos del verification criteria (que prueba la app) y de la revisión de artefacto de ④ (que juzga una fase). (04 §4.)
Curva J — período inicial de menor velocidad durante la construcción de la Base y la calibración de rituales.
Design — fase atendida del Pipeline A (un humano diseña con tooling, conector claude.ai/design), no un agente. No todas las tarjetas la cruzan; sus artefactos viven en docs/internal/design/<módulo>/. (04 §7, 05.)
Deviation — diferencia entre lo construido y la Capa 1 sin enmienda autorizada. Se reporta; no se absorbe. Vive como fila en la tabla Deviations de SeaTable (creada por ⑤, cerrada por el Lead). (02 P5.)
docs/internal — el tier de docs/ cuya audiencia es el equipo: las secciones 00–11 del modelo (Capa A) y la documentación técnica de cada app (Capa B). Lo que se sincroniza al sitio es siempre docs/, con sus tres tiers (internal/, public/, agent/). El tooling accionable (skills, hooks, plantillas) no es documentación: vive como código/config, fuera del flujo de docs. (06 §6.)
Done — estado terminal de una tarjeta en el Pipeline B. Requiere doble condición: first-fire presenciado limpio ✚ documentación completa. No se llega a Done sin docs completos. (05, 07.)
Dueño (de agente) — rol humano responsable de la configuración, calibración, incidentes y resultados de un agente. Un agente no responde por sus salidas; responde su dueño. (03 §3.)
Enmienda — modificación autorizada de la Capa 1: nota de cambio de alcance en la tarjeta y fecha. Quién la concede depende de su dirección: ampliar (agregar un criterio) lo decide el dueño del Requirement y se comunica al Lead; relajar, quitar o ajustar exige su visto bueno, porque es la dirección que acomoda el contrato a lo construido. (02 P5.)
Escalera de autonomía — L0 sugiere · L1 borrador · L2 actúa con confirmación · L3 autónomo. (Definición completa, ascenso y descenso: 02 §6.)
Estándares de construcción (E1–E10) — norma obligatoria que toda configuración de agente debe cumplir para aprobarse por PR (identidad y límites, salida estructurada, declaración de vacíos, seguridad, casos de regresión, trazabilidad). (04 §4.)
Ficha de agente — contrato de nueve campos que define a cada agente (identidad, disparador, entradas, salidas, permisos, plataforma, autonomía, calibración, configuración); mismo esquema que el registro de agentes en SeaTable. (04 §3.)
first-fire — la primera ejecución real de un cambio ya en producción (p. ej. el primer disparo de un job agendado). Que corra limpio es una de las dos condiciones de Done; lo verifica ⑨ Ops-Health Monitor. (05.)
Incidente (de agente) — salida o acción de un agente fuera de su contrato (contexto erróneo sin marcar, Deviation absorbida, acción fuera de alcance); provoca descenso inmediato de nivel. (02 §6.)
Independencia de herramienta — principio: el conocimiento durable vive en Git y SeaTable, nunca cautivo en superficies del proveedor de IA ni en la herramienta de publicación o de board (capas intercambiables). Contrato portable, implementación intercambiable. (02 §7 A8, 08.)
Interfaz (de una app) — cada superficie de uso distinta de una app, con el nombre que tiene en su código (en Vendor Portal, portal y admin). Es la unidad a la que se le asigna audiencia: docs/public/<iface>/. Una interfaz puede servir a varias audiencias (una pantalla común) y entonces su documento se publica en varios portales. (06 §6.1.)
Nota efímera — registro de sesión que reside en la tarjeta y expira con ella; nunca entra a la Base de forma directa.
Pipeline A / Pipeline B — las dos tablas del board. A · Definición (Backlog → Product Architect → Design → Tech Specs; territorio Director+Lead). B · Ejecución (Queue → Build → In Review → Staging Validation → Published → Done; territorio Lead+Developers). La frontera A→B es el Ready gate. (05.)
Plan — documento de desarrollo completo de una tarjeta, versionado en docs/internal/. Se compone del Requirement (la parte del arquitecto: qué y por qué) y el Tech Spec (la parte del Lead+③: cómo). Es el paquete de contexto de la tarjeta. Reemplaza el término anterior “Brief de Desarrollo”. (02 §4.1, 04.)
Portal — el sitio de documentación de una audiencia. Son cuatro: equipo, colaboradores, proveedores y clientes. No crecen con el parque de apps: cada app aporta su sección dentro del portal que le corresponde. Al portal de usuario se entra desde dentro de la app, por su botón de help desk, heredando la sesión de Core Identity; la documentación de acceso es su única sección abierta. (06 §6.2.)
Promoción — acto humano y deliberado de trasladar un aprendizaje de las notas efímeras a la Base de Conocimiento, en el ritual semanal. (02 P4.)
Published — estado del Pipeline B tras el merge a main (⑦ Publisher concilia release y docs). Distinto de Done: publicado no es terminado. (05, 07.)
Ready gate — condición doble para que una tarjeta cruce del Pipeline A al B: criterios de aceptación (Capa 1) congelados ✚ Plan como contexto. (05.)
Requirement — la parte del Plan que redacta ② Product Architect: el problema, el objetivo y los criterios de experiencia verificables (el qué y el por qué). (04.)
Ritual de corrección — obligación inmediata (aprox. 5 minutos) de registrar una corrección cuando se detecta contexto erróneo, y de aplicarla a la Base por quien tiene el carril de escritura sobre ella: el Lead directo, o ⑦ Publisher desde el status.md al conciliar el release. Un dato erróneo material no espera: se escala al Lead. (02 P3, 03 §7.5.3.)
status.md — puente de estado entre sesiones, por app, en la raíz del repo: estado de despliegue (delta staging↔main, ramas protegidas, migración, entorno) que el board no modela, más las correcciones de documentación que el Developer detecta. Transversal, efímero, se verifica contra el sistema vivo. Lo escribe /wrap-up, lo lee /start. Va en la raíz y no en docs/ porque su autor es el Developer, cuyo carril excluye esa carpeta. (04 §8, 06 §4, 03 §7.5.)
Tech Spec — la parte del Plan que completa ③ Spec Writer: arquitectura, integraciones, decisiones, y —obligatorios— los vacíos de cobertura y preguntas abiertas (el cómo). (04.)
Usuario (de agente) — quien opera un agente en el día a día sin ser su dueño (p. ej., los Developers operan ⑤ QA Runner y ⑥ Session Wrap-up, configurados por el Lead). (03 §3.)
Ventana de calibración — período en que las salidas de un agente se revisan con veredicto humano para acumular la evidencia que habilita cambios de nivel de autonomía.
Veredicto de calibración — registro de un clic (sin cambios / cambios menores / mayores) al revisar la salida de un agente durante su ventana de calibración.
verification criteria — la Capa 2 del plan de verificación: el checklist de pasos que se genera contra lo realmente construido, en el handoff a In Review. Versionable, no una hoja de cálculo pasiva. Reemplaza el término anterior “plan de pruebas”. (04, 05.)
/start · /wrap-up — los dos comandos del agente ⑥ Session Wrap-up, las dos caras del ciclo del contexto: /start abre la sesión leyendo el status.md y el Plan; /wrap-up la cierra escribiendo el status.md, emitiendo el prompt de arranque de la siguiente tarjeta y registrando la nota de sesión. (04.)

Historial de versiones

Versión	Fecha	Cambio
v2.4	2026-09-04	Enmienda precisada: quién la concede depende de su dirección (ampliar frente a relajar).
v2.3	2026-09-04	Término nuevo Carril de escritura. Ritual de corrección y status.md precisados: registrar frente a aplicar, y la ubicación en la raíz del repo.
v2.2	2026-09-03	Términos nuevos: Audiencia, Interfaz (de una app) y Portal, por el paso del eje de tiers al eje de audiencia (06 v2.0). docs/internal reescrito como el tier del equipo.
v2.1	2026-09-03	Entrada docs/internal reescrita tras retirarse `dev-standards/`: todo el contenido navegable vive en `docs/`; el tooling accionable es código/config fuera del flujo de docs.
v2.0	2026-09-01	Reforma 2026-09-01. Términos muertos retirados: Courier/Mensajero de contexto, Brief de contexto, Compuerta de Ready, Wrap-up (reemplazado por /start·/wrap-up). Renombrados a nomenclatura inglesa: Desviación → Deviation, Compuerta de Ready → Ready gate, plan de pruebas → verification criteria. Nuevos: Plan, Requirement, Tech Spec, Pipeline A/B, Published, Done, Ready gate, status.md, first-fire, Design, Carril de prioridad, Casos de regresión, Independencia de herramienta, /start·/wrap-up. Referencias de sección y agentes actualizadas al roster de 10. Front-matter YAML; destino `docs/internal/`.
v1.2	2026-07-03	Términos de la sección 04: Ficha de agente, Estándares de construcción, Incidente.
v1.1	2026-07-03	Términos de la sección 03: Dueño, Usuario, Compuerta de Ready, Ventana y Veredicto de calibración.
v1.0	2026-07-03	Extracción del índice a documento propio; términos ordenados alfabéticamente; se agregan Enmienda, Ritual de corrección y Wrap-up.