Estructura Organizacional

1. Propósito y alcance

Esta sección define la estructura organizacional del área de Tecnología bajo el modelo operativo: la composición del equipo, la doctrina que rige la relación entre humanos y agentes de IA, los descriptivos integrados de los tres roles humanos (misión, responsabilidades, KPIs, autonomía y ritmo operativo) y la política de onboarding.

Este documento absorbe y reemplaza al descriptivo de puestos anterior (Digital Transformation — Organizational Structure), que queda como fuente histórica. Es la versión única y autoritativa de cada rol.

Delimitación: el detalle de cada agente (misión, configuración, permisos) corresponde a la sección 04; la escalera de autonomía de agentes se define en 02 §6; el flujo de trabajo y los dos pipelines, en la sección 05.

Principio del documento — roles, no personas. Esta sección documenta roles. Las asignaciones nominales (quién ocupa cada rol, qué developer es responsable de qué aplicaciones o módulos) residen en SeaTable, no en la Base de Conocimiento, de modo que este documento no caduque con cada rotación (coherente con el antipatrón A6).

2. Composición del equipo

La plantilla humana del área es de cinco personas: un Digital Transformation Director (reporta al CEO/Founder), un Product Engineering Lead (reporta al Director) y tres Full Stack Software Engineers (reportan al Lead). El equipo opera de forma remota.

El resto de la capacidad del área la aportan los 10 agentes de IA del roster (sección 04), la infraestructura de pairing y la fase de Design atendida (un humano diseñando con tooling, no un agente). Los agentes no son plantilla: no ocupan posiciones en el organigrama ni tienen líneas de reporte. Escalan por flujo de trabajo, no por headcount — un mismo agente sirve a todo el equipo.

2.1 Historia de diseño: de vacantes a agentes

El primer boceto de esta estructura (junio 2026) representaba las capacidades faltantes del área como cajas de organigrama junto a cada persona: un Sr. Architect, un Director de Documentación Técnica, un QA Test Writer, un QA, un Publishing. Eran, en la práctica, vacantes que la operación necesitaba y que nunca se habrían contratado.

El modelo resolvió cada una con un agente:

Vacante conceptual (boceto original)	Resuelta por
Sr. Architect	② Product Architect · ③ Spec Writer
Director Technical Doc	⑦ Publisher (release & docs)
QA Test Writer	③ Spec Writer (redacta los criterios de aceptación)
QA	⑤ QA Runner
Publishing	⑦ Publisher · ⑧ User Guide & Comms

Nota de evolución: en el boceto original de julio, la redacción de criterios y la generación de tarjetas eran agentes separados (Test Plan Writer, Card Generator); se plegaron dentro de ③ Spec Writer, porque el diseño técnico, los criterios de aceptación y la creación de la tarjeta son un mismo momento de autoría. Del mismo modo, la publicación y la actualización de documentación de release —que el boceto separaba— se consolidaron en ⑦ Publisher, operado por el Lead como un solo acto (autorizar → promover → conciliar release y docs). La capacidad “QA Test Writer” vive hoy en ③.

La lección de diseño quedó incorporada a la doctrina (§3): los agentes no se organizan como personas que reportan, sino como capacidades con dueño.

3. Doctrina de la relación humano–agente

3.1 Propiedad

Todo agente tiene exactamente un dueño humano, definido por rol (no por persona). Ser dueño de un agente implica cuatro responsabilidades:

1. Configuración. El dueño responde por las instrucciones, permisos y herramientas del agente. Toda modificación se hace por Pull Request con aprobación del Lead (la configuración de agentes es código, sección 08).
2. Calibración. El dueño revisa las salidas del agente durante sus ventanas de calibración, emite los veredictos correspondientes y propone los cambios de nivel de autonomía con la evidencia definida en 02 §6.
3. Incidentes. Ante un incidente atribuible al agente, el dueño ejecuta el descenso de nivel, diagnostica la configuración y decide la corrección.
4. Resultados. El dueño responde por las salidas del agente ante el resto de la organización.

Principio de responsabilidad: un agente no responde por sus salidas; responde su dueño. No existe “el agente se equivocó” como cierre de un incidente — existe una configuración que su dueño debe corregir.

3.2 Uso

Un agente puede tener múltiples usuarios: quienes lo operan en el día a día. Los casos centrales son ⑤ QA Runner y ⑥ Session Wrap-up: los configura el Lead (dueño) y los operan los Developers (usuarios) — el QA Runner para verificar su propio trabajo, el Session Wrap-up para abrir y cerrar cada sesión. El usuario es responsable de operar el agente conforme a su diseño; el dueño, de que el diseño sea correcto. Y quien opera un agente le transfiere su propio carril de escritura: un agente no escribe donde su operador no podría (§7.5.1).

3.3 Distribución de la propiedad

Dueño	Agentes	Racional
Director	① Idea Enricher · ② Product Architect · ⑧ User Guide & Comms · ⑩ Knowledge Curator	Agentes de las fronteras del pipeline (entrada estratégica y salida pública) y de la curaduría de la Base a nivel de agenda
Lead	③ Spec Writer · ④ Independent Reviewer · ⑤ QA Runner · ⑥ Session Wrap-up · ⑦ Publisher · ⑨ Ops-Health Monitor	Agentes del núcleo técnico del pipeline, donde el estándar es su responsabilidad
—	Infraestructura de pairing y fase de Design (no son agentes)	Dueño: Lead

Nota sobre operación vs. propiedad: ⑧ User Guide & Comms es del Director (responde por la documentación de cara al usuario) pero lo opera el Lead con un clic al publicar. Los Developers no son dueños de ningún agente; operan ⑤ QA Runner y ⑥ Session Wrap-up.

3.4 Delegación por ausencia

Ante ausencia planificada de un dueño, sus responsabilidades de propiedad se delegan de forma explícita y temporal: por defecto, el Director cubre al Lead y viceversa. Las decisiones de ascenso de autonomía no se toman bajo delegación; se difieren al regreso del dueño.

4. Digital Transformation Director

Reporta a: CEO / Founder · Reportes directos: Product Engineering Lead

4.1 Misión

Definir y liderar la estrategia de transformación digital de la empresa, asegurando que las iniciativas tecnológicas, productos internos y procesos de automatización estén alineados con los objetivos estratégicos y generen impacto medible. Define qué se construye y por qué. Bajo el modelo operativo, es además el dueño de la arquitectura de contexto: responde por qué conocimiento existe en la organización, dónde reside y qué estándar de calidad cumple. No gestiona la ejecución técnica diaria ni participa en desarrollo de código.

4.2 Responsabilidades

Dirección estratégica tecnológica

• Definir y mantener el roadmap de transformación digital.
• Identificar capacidades clave para escalar la operación (automatización, integraciones, data, IA).
• Priorizar productos y soluciones internas según impacto estratégico.
• Traducir necesidades del negocio en el Requirement de cada Plan, publicado directamente a la Base de Conocimiento (asistido por ② Product Architect); las definiciones dejan de circular como documentos aislados.

Arquitectura de contexto (área nueva bajo el modelo)

• Definir qué conocimiento existe en la Base, dónde reside (Capas A/B/C) y su estándar de calidad.
• Ser dueño de los agentes ① Idea Enricher, ② Product Architect, ⑧ User Guide & Comms y ⑩ Knowledge Curator, con las cuatro responsabilidades de §3.1.
• Garantizar que el ritual de promoción semanal ocurra y que la sección de evaluación (11) se desarrolle e implemente.
• Responder por la vigencia de la documentación de cara al usuario final (generada por ⑧, revisión humana).

Alineación e impacto de negocio

• Asegurar que toda iniciativa tenga KPIs claros; validar que las soluciones resuelvan el problema operativo definido.
• Monitorear adopción interna y medir ROI de iniciativas digitales.
• Validar el impacto funcional de cada release en Staging Validation (tercera validación humana).

Supervisión arquitectónica (nivel macro)

• Aprobar lineamientos arquitectónicos estratégicos; garantizar coherencia entre plataformas.
• Evaluar riesgos de escalabilidad y sostenibilidad; escalar decisiones de impacto estructural significativo.

Innovación, gobierno e inversión

• Identificar tendencias tecnológicas relevantes; definir pilotos estratégicos; establecer objetivos anuales de modernización.
• Aprobar inversiones en herramientas y plataformas; supervisar presupuesto tecnológico.

4.3 KPIs

Los KPIs estratégicos vigentes se conservan (% de iniciativas con impacto medible, reducción de ineficiencias, tiempo a valor, adopción interna, cumplimiento de roadmap, % de procesos automatizados, ROI). El modelo agrega:

KPI	Medición	Fuente automática	Activación
Tarjetas en Pending Documentation	Conteo de la columna → 0 y eliminación	SeaTable	Hoy
Utilidad del contexto de arranque	% de tarjetas cuyo Plan recibió veredicto “útil” del Developer (un clic al iniciar, solo durante ventanas de calibración)	Campo select en tarjeta	Piloto

Nota de diseño: el KPI originalmente formulado como “tiempo de arranque de tarea” se sustituyó por el veredicto de utilidad del contexto de arranque — misma señal (¿el contexto llega utilizable?), pero extraíble automáticamente conforme a la regla de KPIs (§7.1).

4.4 Autonomía y escalamiento

Decide sin escalar: prioridades del roadmap · asignación de recursos tecnológicos · aprobación de nuevas iniciativas · inversiones dentro del presupuesto aprobado · lanzamiento de pilotos · cambios a la arquitectura de contexto (qué capas existen, estándares de calidad) · políticas del área y sus fronteras de escritura (§7.5) · ampliaciones de Capa 1 de sus propios Requirement, que se registran con fecha y se comunican al Lead · activación del modelo en una nueva aplicación (Base primero, P1) · ascensos de autonomía de sus agentes ①②⑧⑩, con evidencia y formalización por PR.

Debe escalar: incrementos presupuestales significativos · cambios estructurales organizacionales · decisiones de riesgo financiero mayor.

5. Product Engineering Lead

Reporta a: Digital Transformation Director · Reportes directos: Full Stack Software Engineers

5.1 Misión

Responsable del diseño técnico, la calidad y la ejecución de los productos internos. Traduce la visión estratégica en soluciones técnicas concretas, escalables y mantenibles: es el dueño del cómo técnico y del flujo de trabajo de ingeniería. Bajo el modelo operativo, su naturaleza evoluciona de inspector a codificador de estándares y curador técnico de la Base de Conocimiento: el criterio que hoy reside en su experiencia se convierte en contexto escrito que los agentes entregan y verifican antes de la revisión humana. Su criterio escala sin que escalen sus horas.

5.2 Responsabilidades

Arquitectura y dirección técnica

• Diseñar la arquitectura técnica de productos y servicios (APIs, modelos de datos, integraciones); ③ Spec Writer produce los borradores del Tech Spec, el Lead decide.
• Definir lineamientos técnicos y estándares de código — codificados en la Base de Conocimiento, no transmitidos por repetición en reviews.
• Evaluar y aprobar decisiones técnicas estructurales; documentar decisiones arquitectónicas clave (decisions/ de la Capa B).
• Garantizar escalabilidad y mantenibilidad; supervisar versionado y estructura de APIs.

Curaduría y agentes (área nueva bajo el modelo)

• Curador técnico de la Base: verifica las extracciones iniciales y realiza spot-checks de los Plan durante ventanas de calibración.
• Dueño de los agentes ③ Spec Writer, ④ Independent Reviewer, ⑤ QA Runner, ⑥ Session Wrap-up, ⑦ Publisher y ⑨ Ops-Health Monitor (§3.1), y de la infraestructura de pairing; aprueba por PR toda configuración de agente, propia o ajena.
• Preside el ritual de promoción semanal (diez minutos, dentro de la reunión existente).
• Aprueba los criterios de aceptación (Capa 1) y el verification criteria que ③ redacta (revisa; no redacta — cambio deliberado, sección 05) y resuelve toda Deviation reportada: enmienda o corrección.
• Certifica el onboarding de nuevos ingresos (§7.4) mientras la sección 11 no esté implementada.

Gestión de backlog y flujo de trabajo

• Punto formal de entrada de requerimientos técnicos; evalúa, estructura y prioriza tickets antes de asignación (③ crea la tarjeta de ejecución; el Lead confirma).
• Asegura que ningún desarrollo inicie sin ticket formal aprobado y sin cruzar el Ready gate (criterios congelados ✚ Plan completo).
• Balancea capacidad del equipo con prioridades; monitorea progreso y remueve bloqueos.

Calidad y gobierno técnico

• Valida y autoriza en Staging Validation — no re-revisa línea por línea. La revisión detallada de código la absorbe ④ Independent Reviewer en In Review (en loop con Build, hasta dejar la tarjeta limpia). Cuando la tarjeta llega a Staging, el Lead aporta el juicio que un agente no puede: coherencia arquitectónica, seguridad, ¿esto era lo que se pidió?, ¿tiene sentido para el negocio y el sistema? La meta del diseño es que para Staging el Lead no encuentre defectos mecánicos — si los encuentra, es señal de que la revisión previa falló, y eso es un incidente del sistema, no la operación normal.
• Autoriza la publicación a producción (decisión humana que dispara ⑦ Publisher); supervisa despliegues en dev, staging y producción; define el protocolo de releases.
• Identifica y gestiona deuda técnica; asegura cumplimiento de estándares de seguridad.

Innovación y mejora continua

• Propone mejoras técnicas transversales; identifica oportunidades de automatización e IA; evalúa herramientas; ejecuta POCs controladas.
• Garantiza que la documentación técnica y el verification criteria se mantengan al día — instrumentado: la vista técnica la genera ⑦ desde la Base, el verification criteria lo genera ⑤; la responsabilidad del Lead es la curaduría y la frescura, no la redacción.

5.3 KPIs

Los vigentes se conservan (% comprometido vs. entregado, % de trabajo vía sistema formal, tasa de bugs post-release, tiempo de resolución de incidentes, uptime, reducción de deuda técnica, % de mejoras implementadas, tiempo solicitud→inicio). El modelo agrega:

KPI	Qué mide	Fuente automática	Activación
Frescura de la Base	% de archivos dentro del umbral last_verified	Job semanal lee front-matter en Git → fila resumen en SeaTable	Base publicada
Días en Code Review	Su etapa como cuello de botella (④ debe reducirla)	Timestamps de transición (automatización SeaTable)	Piloto
Reincidencia de hallazgos de review	Migración de su criterio al sistema: mismo hallazgo dos veces = estándar sin codificar	Salida estructurada de ④ (hallazgos etiquetados por ID de regla)	④ activo
Tiempo de resolución de Deviations	Que el mecanismo de Capa 1 no se estanque	Tabla Deviations (creada por ⑤, cerrada por el Lead con tipo y fecha)	Piloto
Tasa de corrección en calibración	Calidad de las configuraciones de sus agentes; habilita ascensos	Veredicto de un clic (sin cambios / menores / mayores) al revisar salidas, solo en ventanas de calibración	Piloto

Nota de equidad: varios KPIs vigentes del Lead mejoran mecánicamente con el modelo — bugs post-release ↓ (las Deviations afloran antes de QA), tiempo solicitud→inicio ↓ (el contexto llega en el Plan, se elimina la reconstrucción).

5.4 Autonomía y escalamiento

Decide sin escalar: stack específico dentro del marco aprobado · estructura técnica de endpoints y servicios · librerías y herramientas secundarias · refactorizaciones · distribución de tareas · rechazar tickets mal definidos · posponer iniciativas que afecten estabilidad · bloquear despliegues que no cumplan estándares · aprobar configuraciones de agentes (PR) · resolver Deviations (enmienda o corrección) · otorgar las enmiendas de Capa 1 que relajan, quitan o ajustan un criterio · ascensos de autonomía de sus agentes ③④⑤⑥⑨, con evidencia · certificar o diferir un onboarding.

Debe escalar: decisiones de impacto estructural significativo · cambios a la arquitectura de contexto o a la doctrina de este documento.

6. Full Stack Software Engineer

Reporta a: Product Engineering Lead

6.1 Misión

Responsable del desarrollo técnico end-to-end de funcionalidades y aplicaciones internas: lógica de negocio, APIs, integración frontend y soporte a despliegues. Opera dentro del marco conceptual y arquitectónico definido, con ownership completo desde requerimiento aprobado hasta producción. Bajo el modelo operativo, es además dueño de la calidad del contexto de los módulos que desarrolla: cada tarea que ejecuta inicia recibiendo contexto y termina devolviéndolo.

6.2 Responsabilidades

Ciclo del contexto (área nueva bajo el modelo)

• Abrir cada sesión con /start (⑥): lee el status.md de la app y el Plan de la tarjeta, y verifica contra el sistema vivo. Así recibe dos capas de contexto: el qué construir (del Plan) y el dónde está el sistema ahora para no romperlo (del status.md).
• Consumir el Plan: validar sus vacíos declarados y resolver sus preguntas abiertas antes de construir (el Plan enmarca la investigación, no la sustituye — antipatrón A5).
• Ejecutar el /wrap-up (⑥) al cierre de cada sesión — requisito para mover una tarjeta de columna. El wrap-up actualiza el status.md (ramas, commits, migración, PR) y emite el prompt de arranque de la siguiente tarjeta: el cierre de una sesión produce la apertura de la siguiente.
• Responder por la calidad del contexto de sus módulos (write-back): notas de sesión útiles, aprendizajes propuestos a promoción.
• Emitir el veredicto de utilidad del contexto de arranque durante ventanas de calibración (un clic).
• En Ops Health: ejecutar la captura retroactiva antes de cerrar (antipatrón A7).

Desarrollo backend

• Implementar APIs REST (Python/Flask o equivalente); lógica de negocio y validaciones; consultas optimizadas; integración de servicios externos; consistencia en contratos de datos.

Desarrollo frontend

• Integrar interfaces (React o equivalente); conectar frontend con APIs internas; ajustar y optimizar componentes generados con IA; decisiones básicas de UX; integración correcta backend–UI.

Ejecución end-to-end

• Validar funcionalidad contra los criterios de aceptación congelados (Capa 1) antes de Ready for Review; toda diferencia con la Capa 1 se reporta como Deviation — nunca se absorbe (antipatrón A4).
• Ejecutar pruebas manuales y automatizadas de los flujos impactados; convertir tickets en soluciones completas; estimar esfuerzo; colaborar en despliegues; dar soporte a incidencias de su trabajo.

Calidad y mejora continua

• Cumplir los estándares codificados en la Base (los mismos que ④ pre-verifica); participar en code reviews; proponer mejoras técnicas; contribuir a iniciativas de automatización e IA; identificar optimizaciones de performance.
• La responsabilidad vigente de “realizar y mantener documentación técnica y casos de prueba” queda transformada: se cumple mediante el write-back del ciclo del contexto (el verification criteria lo genera ⑤; la vista técnica, ⑦).

6.3 KPIs

KPI	Medición	Fuente automática	Activación
Volumen ponderado	Tareas completadas × nivel de esfuerzo (XS–XL)	Dashboard (campos existentes)	Hoy
Rapidez de entrega	Días Doing → Published	Dashboard (existente)	Hoy
Calidad	QA cycles/tarjeta ↓ · % Fix atribuible ↓	Dashboard (QA Cycles pasa a auto-incremento)	Hoy
Deviations	Deviations/tarjeta ↓	Tabla Deviations vinculada	Piloto
Ciudadanía de contexto	Aprendizajes promovidos originados en sus tarjetas	Campos Learnings + Promoted?	Piloto

El cumplimiento de wrap-up no es un KPI: es compuerta estructural para mover tarjetas. Lo estructural se hace cumplir; no se mide.

6.4 Autonomía y escalamiento

Decide sin escalar: implementación técnica específica · estructura interna del código · optimización de consultas y performance · refactorizaciones menores · decisiones básicas de UX · propuestas técnicas de mejora · contenido de sus notas de sesión y aprendizajes propuestos.

Debe escalar: cambios arquitectónicos · modificaciones del stack principal · cambios en modelos de datos centrales · impactos transversales · toda Deviation detectada respecto a la Capa 1 (se reporta; la resuelve el Lead) · toda necesidad de enmienda de criterios (se solicita; la otorga el Lead).

7. Reglas transversales de la estructura

7.1 Regla de KPIs — extracción automática o no existe

Ningún KPI del modelo se adopta si su dato no se extrae automáticamente del flujo: tarjetas del Changelog, sus transiciones de columna (timestamps por automatización), la tabla Deviations, las salidas estructuradas de agentes, o jobs automatizados sobre la Base. Un KPI de recolección manual se abandona; por diseño, aquí no puede existir. Las columnas “Fuente automática” y “Activación” de las tablas anteriores son obligatorias para todo KPI futuro.

7.2 Ritmo operativo

Cadencia	Qué ocurre	Quién
Por sesión de desarrollo	/start al abrir (lee estado) · /wrap-up al cerrar (escribe estado)	Developer (opera ⑤ QA Runner y ⑥ Session Wrap-up)
Por tarjeta	Ready gate · validación contra Capa 1 · QA · pre-review · review	Developer · Lead
Semanal	Ritual de promoción (10 min, dentro de la reunión existente): ⑩ propone, los humanos deciden	Preside: Lead · Asisten: todos · Convoca la agenda: Director
Por release	Autorización · regeneración de vistas · novedades al canal	Lead autoriza · Director revisa salidas de ⑦⑧
Continuo	Ritual de corrección: contexto erróneo detectado → registrarlo (≈5 min) es de quien lo detecta; lo aplica a la Base quien tiene el carril — el Lead directo, o ⑦ desde el status.md al conciliar el release (§7.5.3)	Registra: todos · Aplica: Lead / ⑦
Trimestral	Revisión de niveles de autonomía del roster y de KPIs del modelo	Director + Lead

7.3 Cambios respecto al descriptivo anterior — trazabilidad

Responsabilidad del descriptivo 2026	Veredicto	Cómo queda
Director: “Traducir necesidades del negocio en briefs estructurados”	Instrumentada	Asistida por ②; el Requirement se publica a la Base
Lead: “Definir lineamientos técnicos y estándares de código”	Transformada	Los estándares se codifican en la Base y los verifican los agentes antes del review
Lead: “Garantizar que la documentación técnica y casos de prueba se mantengan al día”	Transformada	De redactar a curar: la generan ③⑤⑦; el Lead responde por frescura y calidad
Lead: “Realizar code reviews obligatorios”	Instrumentada	④ pre-revisa lo mecánico; el review humano se concentra en arquitectura y juicio
Lead: “Asegurar que ningún desarrollo inicie sin ticket formal aprobado”	Ampliada	Se agrega el Ready gate (criterios congelados ✚ Plan)
Developer: “Validar funcionalidad contra criterios de aceptación antes de Ready for Review”	Ampliada	Contra la Capa 1 congelada; toda diferencia se reporta como Deviation
Developer: “Realizar y mantener actualizada documentación técnica y casos de prueba”	Transformada	Se cumple vía write-back del ciclo del contexto; el verification criteria lo genera ⑤
Todas las demás responsabilidades de los tres roles	Se mantienen	Sin cambio

7.4 Política de onboarding

Regla: la comprensión de la arquitectura y del proceso documentados en la Base de Conocimiento es requisito previo para escribir código en Prism. Ninguna tarjeta se asigna a quien no haya completado la ruta y obtenido la certificación.

Ruta de lectura (en orden), sobre el sitio interno (docs/internal/):

1. 00 Índice Maestro → 01 Visión y Tesis → 02 Modelo Operativo (concepto, principios, antipatrones)
2. 03 Estructura Organizacional (este documento) → 05 Flujo de Trabajo → 06 Arquitectura de Información
3. 04 Roster de Agentes → 07 Kanban y Changelog → 08 Gobernanza → 09 Políticas Vigentes
4. Capa B de la(s) aplicación(es) asignada(s): architecture.md, notas de los módulos que tocará, decisiones vigentes.

Certificación: mientras la sección 11 (quizzes a la semana, mes y trimestre) no esté implementada, la certificación es una sesión de validación estructurada con el Lead, quien certifica o difiere con lectura adicional. Al implementarse la sección 11, los quizzes se convierten en el instrumento formal y la sesión con el Lead pasa a ser su complemento.

Equipo actual: los cinco miembros vigentes completan la misma ruta durante la transición — son los primeros en recorrerla, y su paso valida que la ruta funciona (parte del plan de adopción, T0 §6).

Dueño de la política: el Director. Certificador: el Lead.

7.5 Fronteras de escritura — quién escribe dónde

La sección define, hasta aquí, qué decide cada rol. Esta subsección define dónde escribe cada uno, que no es lo mismo y hasta ahora no estaba escrito.

Regla. Cada rol tiene un carril de escritura declarado en cada repositorio. Lo que no está en el carril no se escribe: se pide.

	Repo del modelo (000-dev-ops-model)	Repo de una app
Director	docs/ · plans/ · skills/ · templates/	docs/ · plans/
Lead	Todo el repo, incluido docs/	Todo el repo, incluido docs/
Developers	Todo el repo menos docs/	Todo el repo menos docs/

No es una partición, son tres techos. El Lead escribe en docs/ porque la Capa B de cada app es suya —su architecture.md, sus decisions/, sus notas de módulo— y porque ⑦ Publisher, el agente que concilia la Base al publicar, es suyo. Los Developers no escriben en docs/: su responsabilidad de documentación no es redactar la Base sino devolver contexto por el ciclo (§6.2), y su carril de escritura en Git es el código, plans/ y el status.md. El Director no escribe código. Cada techo es distinto porque cada rol responde por cosas distintas.

Por eso el status.md vive en la raíz del repo y no en docs/. Lo escribe el Developer en cada /wrap-up, así que no puede estar en una carpeta que su carril excluye. Y encaja: es global a la app, no documentación de la Base (06 §4).

Y el carril no es permiso de merge. Dice dónde puedes escribir, no que puedas mergear sin revisión: la configuración de agentes en skills/ está en el carril del Director y, aun así, cambia por PR con aprobación del Lead (§3.1). Son dos controles distintos.

7.5.1 La herencia del carril

Un agente, un asistente o una sesión de IA hereda el carril de quien lo opera. Sin esta regla la anterior no sirve: la escritura no la hace la persona, la hace la herramienta que opera en su nombre, y el repositorio solo ve el commit.

Es la extensión a los humanos de un estándar que el modelo ya exigía a las máquinas. El estándar E5 de la sección 04 dice que toda configuración de agente “enumera de forma explícita su alcance de escritura; todo lo no enumerado está prohibido”. Mínimo privilegio, declarado y obligatorio — para un agente del roster. Esta subsección cierra la asimetría: los roles humanos también tienen alcance de escritura declarado, y quien opera en su nombre no puede exceder el de su operador.

7.5.2 La válvula: el límite rutea, no bloquea

Cuando el Director necesita un cambio fuera de su carril —que el sync soporte un tier nuevo, que un workflow cambie— no lo escribe: lo pide, y el pedido ya tiene camino en el modelo: se vuelve un Requirement y entra por el Pipeline A como cualquier otro trabajo (sección 05). El límite no le quita capacidad de acción a nadie; la encauza por el pipeline que este modelo existe para operar.

Razonamiento. La regla se escribió después de cruzarla. En el montaje de la app piloto, el Director escribió 912 líneas de código y configuración —el script de sync, los dos gates, los workflows de CI, los configs de los sitios— en un repo cuyo dueño del cómo técnico es el Lead. Nadie desobedeció nada: la asignación estaba escrita en la propia tarjeta (“[Director] crear la estructura técnica: sync/, sites/, .gitea/workflows/”), la frontera no existía en ningún documento, y la rama main no estaba protegida. Tres capas ausentes a la vez. El daño no fue el código —se puede revisar o reescribir— sino que el dev recibió un repo con decisiones técnicas ya tomadas por alguien que no responde por mantenerlas.

7.5.3 Qué pasa con el ritual de corrección

El ritual de corrección (P3) obliga a corregir un dato erróneo en el momento en que se detecta, y quien más lo va a detectar es el Developer: es el que lee el Plan y choca con el sistema real. Pero docs/ está fuera de su carril. La mecánica, entonces, se parte en dos:

1. Registrar es inmediato y es de quien lo detecta (≈5 minutos). El Developer anota la corrección en el status.md de la app o en el plan de la tarjeta — su carril.
2. Aplicar a la Base es de quien tiene el carril. ⑦ Publisher ya recibe el status.md como entrada al conciliar el release: la corrección llega a docs/ en ese momento, sin plumbing nuevo. El Lead también puede aplicarla directo cuando corresponda.

La obligación de inmediatez no se relaja: se traslada al registro. Lo que cambia es quién la aplica, no cuándo se levanta.

Y queda una válvula, porque el traslado tiene un costo. Entre el registro y el release, la Base sigue sirviendo el dato viejo a los Plan que se escriban en esa ventana — que es exactamente el daño que P3 existe para evitar. Por eso: si el error es material —no una errata, sino un dato que puede hacer construir mal— el Developer lo escala al Lead, que corrige de inmediato. Sin esa válvula, un dato peligroso vive hasta el próximo release.

Prohíbe. Que el Director escriba fuera de su carril, en persona o vía asistente; que un Developer edite docs/ en vez de registrar la corrección en su carril; asignar trabajo de infraestructura al Director en un plan o una tarjeta; y dar por buena una frontera que no esté protegida en el repositorio — una regla que solo vive en un documento se cruza sin que nadie se dé cuenta.

Enforcement. La frontera se protege en el repositorio, no solo en este documento: todo repositorio de Prism —los que existen hoy y los que se creen— lleva su rama principal protegida, su CODEOWNERS y un gate de CI que compara las rutas de cada PR contra el carril de su autor. Es política, no una lista de repos por atender: el andamiaje de un repo nuevo siembra los tres en el mismo acto de crearlo, así que no depende de que alguien se acuerde de aplicarla caso por caso.

Y ninguno de los tres lo implementa el rol que restringen: los escribe el Lead o un Developer — el gate que impide escribir código es, él mismo, código. Su régimen se detalla en la sección 08.

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

Para conocer	Sección
El modelo, sus principios y antipatrones	02
Cada agente en detalle (misión, configuración, permisos, calibración)	04
El flujo de la tarjeta por los dos pipelines y la fase de Design	05
Dónde vive cada tipo de conocimiento	06
Los campos y columnas que alimentan los KPIs	07
Las reglas de decisión (PRs de configuración, rituales, enmiendas)	08
El régimen de enforcement de las fronteras de escritura	08

---

Historial de versiones

Versión	Fecha	Cambio
v2.5	2026-09-04	Matrices de autonomía alineadas con la vía de enmienda por dirección (02 P5 v3.3): el Lead otorga las enmiendas que relajan o ajustan un criterio; el Director decide las ampliaciones de sus propios Requirement y las políticas del área, incluidas sus fronteras de escritura.
v2.4	2026-09-04	El enforcement de §7.5 se enuncia como política universal —todo repositorio, los de hoy y los que se creen, con los tres controles sembrados al crearse— y no como un alcance de repos por atender.
v2.3	2026-09-04	§7.5 corregida: la tabla ponía Lead y Developers en la misma fila y con eso les daba a los Developers el carril de docs/ que la propia §6.2 les había quitado. Ahora son tres filas, una por rol. Nueva §7.5.3 con la mecánica del ritual de corrección bajo el carril: registrar es inmediato y de quien detecta, aplicar es de quien tiene el carril, con válvula de escalamiento al Lead si el error es material. §7.2 alineada. El status.md se ubica en la raíz del repo, fuera de docs/, porque lo escribe el Developer.
v2.2	2026-09-04	Nueva §7.5 Fronteras de escritura: la sección definía qué decide cada rol y no dónde escribe. Declara el carril de cada rol por repositorio (techo para el Director, sin restricción para Lead y Developers), la herencia del carril por agentes y asistentes —que extiende a los humanos el mínimo privilegio que E5 ya exigía a las máquinas—, y la válvula que rutea el pedido por el Pipeline A en vez de bloquearlo. Se escribió después de cruzar la frontera en el montaje del piloto.
v2.1	2026-09-01	Ajuste tras contrastar con el pipeline probado. Roster de 10 con Publisher (⑦) y Session Wrap-up (⑥) como fichas distintas: distribución de propiedad final (Director ①②⑧⑩; Lead ③④⑤⑥⑦⑨). §3.2 Uso: el developer opera dos agentes (⑤ QA Runner y ⑥ Session Wrap-up). §5.2 cambio de fondo: el code review del Lead deja de ser línea por línea y se vuelve validación de juicio + autorización en Staging Validation; la revisión detallada la absorbe ④ Independent Reviewer. Ciclo del contexto del developer: /start lee el status.md al abrir, /wrap-up lo escribe al cerrar (dos capas de contexto: Plan + estado del sistema). §2.1 nota de evolución ampliada (publicación consolidada en ⑦). Referencias por número actualizadas al roster final.
v2.0	2026-09-01	Reforma de la sesión 2026-09-01. Plantilla de agentes 11 → 10; distribución de propiedad rebalanceada. §2.1 vacantes→agentes actualizado con nota de evolución (Test Plan Writer y Card Generator plegados en ③). §3.2 Uso: el caso central pasa a ser solo el Session Wrap-up (Context Courier disuelto). KPIs actualizados a la numeración nueva y a Deviation/verification criteria/Ready gate; “utilidad del brief” → “utilidad del contexto de arranque”. §5.2 el Lead revisa criterios y verification criteria (no plan de pruebas xlsx). Ruta de onboarding anclada a docs/internal/. Design mencionada como fase atendida en la composición. Nomenclatura EN/prosa ES. Front-matter YAML; destino docs/internal/.
v1.0	2026-07-03	Versión inicial. Absorbe y reemplaza Digital Transformation — Organizational Structure: descriptivos integrados de los tres roles; doctrina humano–agente; organigrama corregido; KPIs con fuente automática y fase de activación; ritmo operativo; política de onboarding; historia de diseño (vacantes → agentes).