Visión y Tesis — Rediseño del Modelo Operativo

La tesis en una frase

Ninguna tarea en Prism inicia sin contexto: el conocimiento llega con la tarea, y cada tarea devuelve conocimiento al sistema.

El problema que se resuelve

El equipo ha señalado que, al recibir una tarea nueva, no llega el contexto suficiente. El contexto existe — pero reside en documentos de SharePoint fuera del flujo de trabajo diario, en el historial de SeaTable y en el conocimiento individual de las personas. El conocimiento almacenado donde el trabajo no ocurre no se consulta ni se actualiza: un documento sin punto de contacto con el flujo diario pierde vigencia de forma sistemática.

No es un problema de almacenamiento. Es un problema de flujo.

El cambio

Modelo actual	Modelo propuesto
La documentación es un subproducto que se actualiza a posteriori	La documentación es el medio por el que fluye el pipeline
El contexto se busca, con resultados inconsistentes	El contexto llega con la tarjeta y regresa al cerrar la sesión
El conocimiento reside en Word/SharePoint, estático	El conocimiento reside en Git: versionado, con fecha y fuente, consultado en cada tarea
Los lectores son humanos, con consulta esporádica	El lector principal son los agentes de IA — consulta sistemática — y de ahí se generan las vistas para lectores humanos

El contexto llega con la tarjeta condensado en el Plan — el documento que el Product Architect inicia (el Requirement: qué y por qué) y que el Spec Writer enriquece con el Tech Spec (el cómo) — y regresa al cerrar cada sesión, mediante el wrap-up y la promoción semanal. Esa función de hacer llegar el contexto y devolverlo es lo que se resume en la idea de que los agentes de IA son mensajeros del contexto: no un agente con ese nombre, sino el sistema entero operando el ciclo. El trabajo manual que hacía inviable este flujo —ensamblar el contexto de cada tarea, capturar lo aprendido, mantener los documentos al día— es precisamente el tipo de tarea que los agentes ejecutan de forma consistente y a bajo costo.

Qué cambia por rol

• Digital Transformation Director — De producir documentación de consulta esporádica, a ser dueño de la arquitectura de contexto: qué conocimiento existe, dónde reside y qué estándar de calidad cumple.
• Product Engineering Lead — De inspector a codificador de estándares: los lineamientos que hoy se transmiten por repetición en cada code review se convierten en contexto escrito que los agentes entregan y verifican antes del review. Su criterio escala sin que escalen sus horas; la revisión humana se concentra en arquitectura y juicio técnico.
• Full Stack Software Engineers — De reconstruir contexto en cada arranque, a recibirlo al abrir la tarjeta. Cada desarrollador es dueño de la calidad del contexto que devuelven sus propios módulos.

Principios de diseño

1. Lanzamiento estrecho, Base de Conocimiento primero. Se inicia con una sola aplicación piloto. Ningún agente entrega contexto que un humano no haya verificado previamente. La Base de Conocimiento siempre precede a la automatización.
2. El contexto declara sus límites. Fuentes consultadas, vacíos de cobertura y preguntas abiertas. El contexto recibido enmarca la investigación del desarrollador; no la reemplaza.
3. Todo dato lleva fecha y fuente. El contexto sin verificar genera más riesgo que la ausencia de contexto. Corregir un documento erróneo es una obligación inmediata (aprox. 5 minutos), no un elemento de backlog.
4. Dos tipos de escritura de vuelta. Las notas de sesión son efímeras: residen en la tarjeta, sirven a la siguiente sesión y expiran. El conocimiento durable se promueve de forma deliberada mediante un ritual semanal de 10 minutos.
5. Criterios de aceptación congelados, con vía de enmienda ágil. La verificación opera en dos capas: el contrato (Capa 1, congelado al cruzar el Ready gate; se enmienda con nota de cambio de alcance + visto bueno del Lead) y el mapa de ejecución (Capa 2, se actualiza contra lo construido). Las Deviations se reportan; no se absorben.
6. Autonomía por niveles, otorgada con calibración. Todo agente inicia en nivel L1 (borrador que un humano revisa). La autonomía se amplía con base en resultados observados, no por diseño.
7. Independencia de herramienta. 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. El contrato es portable y la implementación, intercambiable.

Qué NO cambia

• El flujo de trabajo permanece intacto: ninguna fase se omite. Se reorganiza en dos pipelines —Definición y Ejecución— con las mismas fases y validaciones humanas de siempre.
• El Lead aprueba cada PR. Los agentes pre-revisan; el humano decide.
• Nada llega a producción sin pasar por Staging.
• Las políticas de ramas, commits y versionado permanecen vigentes.

Los agentes se insertan dentro de las reglas existentes. Es una evolución del sistema operativo actual, no su reemplazo.

Expectativa de resultados

Durante las primeras 6–8 semanas la velocidad de entrega se reducirá: la construcción de la Base, la adopción de rituales y la calibración de agentes tienen un costo inicial. Es una inversión declarada, con fecha de evaluación definida. Métricas de éxito (línea base capturada previamente): ciclos de QA por tarjeta, días en Code Review, tarjetas rebotadas, tarjetas en Pending Documentation (objetivo: cero) y utilidad del contexto de arranque.

---

El detalle del modelo — flujo por pipelines, arquitectura de información, ajustes por rol y roster de agentes — se desarrolla en el documento 02 · Modelo Operativo y siguientes.

Historial de versiones

Versión	Fecha	Cambio
v2.0	2026-09-01	Reforma de la sesión 2026-09-01. “Mensajeros del contexto” reencuadrado como función del sistema (el Plan = Requirement + Tech Spec), no un agente. Se agrega el 7.º principio (independencia de herramienta). “Qué NO cambia” reconciliado con los dos pipelines (Definición / Ejecución). Nomenclatura de sistema en inglés (Plan, Ready gate, Deviations), prosa en español. KPI “tiempo de arranque” → “utilidad del contexto de arranque”. Front-matter YAML; destino docs/internal/.
v1.3	2026-07-03	Referencia actualizada al documento 02 (renumeración del índice v2.0).
v1.2	2026-07-02	Término “corpus” → “Base de Conocimiento”.
v1.1	2026-07-02	Tono corporativo; títulos oficiales de puestos; métrica de Pending Documentation; renumeración como 01.
v1.0	2026-07-02	Versión inicial.