Gobernanza

El manifiesto pierde valor si se limita a una presentación inicial. Debe aparecer en los momentos donde el equipo toma decisiones: definición, diseño, generación, revisión y aprendizaje posterior al lanzamiento.

Responsabilidades

Responsable	Obligación principal
Producto	Establece la definición autorizada, el alcance, los resultados, las reglas, los no objetivos y la evidencia de éxito; valida Jobs to Be Done y Job Stories cuando se utilizan.
Diseño	Traduce el fundamento de producto a recorridos coherentes con el modelo mental de la persona y protege su atención; utiliza Job Stories cuando permiten concretar la situación.
Ingeniería	Absorbe complejidad, garantiza estados, rendimiento, accesibilidad y recuperación.
Agente de IA	Planifica e implementa dentro del fundamento y del contrato; declara supuestos, mantiene cobertura y no reduce ni amplía alcance por iniciativa propia.
Revisión humana	Evalúa causalidad, sentido, riesgo, experiencia completa y evidencia; no se limita a revisar código.

Puntos de control

Momento	Decisión requerida
Antes de diseñar	Fuentes, autoridad, alcance, resultados, evidencia, supuestos y no objetivos están claros; las Job Stories se comprenden cuando existen.
Antes de generar código	El plan cubre la definición completa y establece dependencias, respuesta elegida, rutas, estados, reglas críticas, riesgos y aceptación.
Durante la construcción	La descomposición organiza el trabajo sin alterar el alcance; bloqueos, pendientes y excepciones permanecen visibles.
Antes de integrar	Cada cambio conserva trazabilidad con su fundamento, respeta alcance, cubre estados y pasa pruebas técnicas.
Antes de liberar	La implementación completa demuestra resultados, cobertura, comprensión, control y calidad de experiencia.
Después de liberar	Se observan resultado, fricción, abandono y errores; se revisan el fundamento, las historias y sus supuestos cuando corresponda.

Los principios deben ser estables; las reglas y pruebas pueden evolucionar con nueva evidencia. Todo cambio debería registrar el problema observado, la decisión modificada y la razón. El marco no debe crecer por acumulación: una nueva regla solo se incorpora si resuelve un vacío que las existentes no cubren.

Control de cambios de las versiones 2.0 y 2.1

La versión 1.0 permanece como formulación fundacional. La versión 2.0 conserva su tesis y sus diez principios, pero reemplaza referencias operativas genéricas a Jobs to Be Done por una cadena más concreta y verificable.

Área	Ajuste de la versión 2.0	Contenido que permanece
Unidad de diseño	La Job Story concreta el progreso dentro de un Jobs to Be Done.	El progreso del usuario sigue siendo la medida principal.
Arquitectura	Se incorpora un nivel entre principio y regla.	Principios, reglas y pruebas conservan su función.
Flujo y artefactos	Se exige circunstancia, motivación, resultado y evidencia antes de diseñar.	Se mantiene la documentación mínima que cambia decisiones.
Desarrollo con IA	El agente debe reformular y respetar la Job Story.	Continúan los límites, el determinismo y la revisión humana.
Aceptación	El resultado se prueba bajo la circunstancia descrita.	Accesibilidad, rendimiento, estados y control siguen siendo obligatorios.
Ejemplo y gobernanza	Se añade trazabilidad causal y validación de historias.	El tutor de cálculo y los puntos de control conservan su propósito.

La versión 2.1 preserva la tesis, los diez principios, la doctrina para IA, las Job Stories y el ejemplo aplicado. Amplía el núcleo para admitir definiciones de producto de distinta forma, extensión y profundidad sin imponer una estructura aguas arriba ni suponer una estrategia incremental.

Área	Ajuste de la versión 2.1	Contenido que permanece
Fundamento	Se define una base autorizada, trazable y verificable que puede adoptar distintas formas.	El progreso humano continúa como medida principal.
Job Stories	Se declaran forma de referencia, no estructura universal obligatoria.	Se conservan su forma canónica, evidencia, pruebas y ejemplos.
Alcance	Se exige cobertura completa y se prohíben omisiones o postergaciones no autorizadas.	Producto sigue definiendo alcance y no objetivos.
Planificación	Se separa descomposición, secuencia y paralelismo de cualquier decisión de alcance.	Continúan la claridad previa, las reglas, los riesgos y la aceptación.
Estrategia de entrega	La incrementalidad deja de ser un supuesto del núcleo.	Cada proyecto puede adoptar fases o releases cuando corresponda.
Implementación SDD	Se reserva para anexos y adaptadores independientes.	El núcleo conserva principios y garantías que toda implementación debe respetar.

Un desarrollo está completo cuando todos los elementos obligatorios de la definición de producto tienen una implementación y una evidencia verificable, o una excepción explícita y aprobada; las personas alcanzan los resultados previstos bajo las condiciones definidas, y la conducta del sistema y la calidad de la experiencia han sido verificadas con rigor proporcional al riesgo.

Cuando el fundamento incluye Job Stories, la verificación debe demostrar el resultado en sus circunstancias. La completitud incluye código correcto, pero no termina allí. Exige cobertura del alcance, integración entre sus partes, estados críticos confiables, una experiencia que no obligue a aprender la arquitectura del producto, IA dentro de límites explícitos y claridad sobre lo que debe observarse después del lanzamiento.