Plan de mejora del demo — Control Tower Hospital Ángeles (v2)

Cómo leer este plan

Cada punto de la retroalimentación trae su estado real, verificado en el código el 2026-09-30:

El estado reduce mucho la lista P0 original: de los 10 puntos «obligatorios», 6 ya existen total o parcialmente. Lo que queda es sobre todo copy, denominadores, agrupación y una respuesta de IA guionada. Eso cabe en una sesión.

Código de referencia: dominio en src/lib/control/, pantallas en src/components/control/, guía en explicacion/public/.

El objetivo, cuando el plan esté terminado

En una frase: una persona de Hospital Ángeles, en un recorrido guiado de dos minutos y sin explicación técnica, entiende y cree el producto; y si le interesa, puede seguir navegando sola y seguir fascinándose.

Son dos capas y las dos cuentan (Jorge, 2026-09-30: «eso no quita un demo completo que, ya que se interesó, lo pueda seguir navegando y fascinándose»).

Capa 1 — la puerta (dos minutos).

• El recorrido del director corre solo: pregunta, tres temas con MAG-003 primero, Asset 360, ficha de decisión, autorización con identidad, el workflow avanza. Sin narración nuestra.
• El recorrido operativo corre en un teléfono: QR, falla con sus tres preguntas, folio, criticidad sugerida con su porqué, y la alerta aparece sola en la pantalla del director.
• Nada en pantalla miente: sin «En vivo», cada número con fuente, corte y denominador, CAPEX como jerarquía, SAP sólo con lo cierto, y «simulado / por validar / configurable» donde toca.
• Las cuentas no pueden descuadrarse: los invariantes viven en la suite de pruebas.
• Ángeles AI se percibe como la interfaz: en todas las pantallas, con contexto, resume y etiqueta; nunca decide.
• Producto y propuesta separados; el hospital se va con su tarea (las preguntas abiertas), no con la nuestra.

Capa 2 — el mundo (veinte minutos sin callejones). Después del recorrido, una persona curiosa explora por su cuenta sin toparse con una pantalla vacía, un enlace roto, un dato que no cuadra ni un «próximamente»:

• Cualquier equipo del parque abre un Asset 360 con historia coherente (fallas, costos, preventivos, contrato, garantía), no sólo MAG-003.
• Cualquier folio se sigue de punta a punta: EQ-2026-0182 hasta el alta del activo; el expediente de compra M0–M6 completo (comparativo, firmas, solicitud de pedido y orden SAP simuladas, proveedor, recepción, pago).
• Ángeles AI contesta preguntas fuera del guion con fuente y hora de corte, o dice con honestidad «ese dato no está en el demo».
• La torre de control baja de cada KPI a su lista y de cada renglón a su ficha.
• Visión futura (el expediente autónomo que se reproduce solo, la torre de la visión) y la guía con presentación y diagramas están a un clic: separadas del producto, pero completas.
• Cada perfil (Dirección, Finanzas, Adquisiciones, Biomédica, Almacén, Área solicitante, Proveedor) tiene su pantalla con sentido.
• El horizonte está adentro, desde el principio: quien explora descubre que la torre, la IA, el gemelo del activo y la política como dato son lo mismo que hacen los hospitales que llevan la batuta, dicho con su nombre, y en cada pantalla ve el «siguiente escalón» (§12). No hay un «2030» aparte: el demo ya lo trae.

La regla que une las dos capas: simplificar la entrada no es amputar la profundidad. Nada de lo construido se borra; se reordena (§10) y se saca de la vista principal, no del producto. El Demo Mode termina con un panel «Sigue explorando» (§2.3) que abre la capa 2.

Cómo se mide: después de la junta, la retroalimentación del hospital habla de su proceso y sus datos, no de si el demo es creíble; y en la junta alguien pide «¿puedo verlo yo?» y lo navega sin que lo guiemos.

0. La tesis (no cambia)

El demo no es «un dashboard con IA». Es:

Una capa inteligente de gestión para Hospital Ángeles que conecta información administrativa, activos, mantenimiento, solicitudes, autorizaciones y SAP, permitiendo trazabilidad completa y toma de decisiones en tiempo real.

Dolor principal (del brief): las solicitudes de equipo, autorizaciones y firmas viajan en papel; nadie sabe dónde está cada solicitud, quién debe autorizarla, cuánto lleva detenida ni qué pasó después con la compra y el activo.

Papel → firmas → llamadas → correos → información fragmentada se convierte en Solicitud digital → workflow → responsable → SLA → autorización digital → SAP → compra → activo → mantenimiento → trazabilidad completa.

Prioridad de esta ronda: no agregar funcionalidad. Simplificar, contar mejor la historia, corregir inconsistencias, hacer creíble el entorno hospitalario, hacer visible a Ángeles AI, crear un recorrido claro y convertir MAG-003 en el caso de uso. Y no quitar nada de lo que ya fascina: lo que no cabe en el recorrido se reordena, no se borra. El demo no es el paso previo al horizonte: es el horizonte en su primer escalón, funcionando (§12).

1. Qué hace útil a un sistema así (principios y referencias)

Estos principios ordenan todas las decisiones de abajo. Cada uno trae el porqué y, cuando existe, la referencia externa.

1. Treinta segundos para el director. Al entrar debe poder contestar «¿cómo va el hospital?», «¿qué necesita atención?», «¿qué tengo pendiente de autorizar?». Todo lo demás es profundidad bajo demanda.
2. Todo número lleva fuente, hora de corte y denominador. «94 %» sin denominador no es un dato. Ángeles AI ya devuelve fuentes y actualizado en cada respuesta (src/lib/control/ia.ts); el resto de la interfaz debe hacer lo mismo. Es también lo que ISO 55001:2024 exige a la gestión de activos: un marco de decisión con criterios explícitos y datos confiables (edición de julio de 2024, cláusulas nuevas de toma de decisiones y plan estratégico de activos).
3. Todo KPI baja a un registro y todo registro sube a su KPI. Un número que no abre una lista, y una lista cuyo renglón no abre una ficha, no es accionable.
4. Pocas alertas, ordenadas, accionables y que se apagan solas. Es la misma lección de la fatiga de alarmas en clínica: más de cinco alertas sin verbo no son alertas, son ruido. Hoy la pantalla del director muestra 2 alertas + 1 insight (src/lib/control/alertas.ts:293-297); mantener ese techo.
5. La IA resume, señala faltantes, riesgos y anomalías; la decisión es humana. Y distingue siempre dato · observación · estimación · posible relación. Es la forma en que la IA agentiva está entrando a la operación hospitalaria en 2026: tareas repetitivas y reglas claras primero, con puntos de entrega al humano, bitácora y escalación visibles (ver fuentes).
6. Lo que cambia es dato, no código. Matriz de autorización, SLA, catálogos, criticidad, hospitales: datos versionados. La matriz ya es un dato con versión y bandas marcadas «conocido / supuesto» (src/lib/control/matriz.ts). Todo lo demás debe seguir ese patrón. Es lo que vuelve al sistema útil en un entorno que cambia cada mes: la regla se edita, no se reprograma.
7. El historial no se borra. Los eventos viven en una tabla sólo-anexar (evento_control) que es el audit trail. En producción, la evidencia de cada autorización (usuario, rol, hora, importe, versión y huella del documento, método) se conserva con una constancia NOM-151-SCFI-2016 (prestador acreditado, sello de tiempo, hash) y bajo el Código de Comercio (art. 49 conservación; arts. 89 y siguientes, mensajes de datos y firma electrónica). Eso convierte una «firma de flujo» en evidencia con valor probatorio. ❓ Si Hospital Ángeles exige firma legalmente vinculante, e.firma del SAT en los umbrales altos.
8. Honestidad radical. DEMO · datos simulados · conceptual · por validar · configurable. Nada que parezca una conexión real con el SAP de Hospital Ángeles. Lo que no confirmó el hospital se marca, no se afirma.
9. Un folio viaja de punta a punta. EQ-2026-0182 nace en la solicitud y llega hasta el alta del activo; el activo nuevo hereda la historia del que reemplaza.
10. Móvil para el piso, escritorio para dirigir. QR, foto y voz en el teléfono; tablero y ficha de decisión en la laptop.
11. Es la herramienta de un programa de gestión de equipo médico, no un dashboard. El marco que usan los hospitales acreditados: AAMI EQ56:2024 (estructura, documentación, personal y recursos mínimos de un programa de gestión de equipo médico), AAMI EQ89 (estrategias de mantenimiento: por riesgo, por uso, por condición), la guía de la OMS Medical equipment maintenance programme overview (2011) y, en México, la NOM-240-SSA1-2012 (tecnovigilancia: el hospital identifica, evalúa y notifica incidentes adversos con dispositivos médicos). El Control Tower debe hablar ese idioma: inventario, criticidad, preventivos, correctivos, incidentes, vida útil, contratos, evidencia.

2. Los dos recorridos del demo y el «Demo Mode»

2.1 Historia 1 — Director (menos de dos minutos)

2.2 Historia 2 — Usuario operativo (Responsable de Imagenología)

2.3 Demo Mode 🆕 (P1)

Botón visible en la barra: ▶ Iniciar demo. Abre un recorrido guiado con dos historias.

• Mecanismo: un overlay con el paso actual (título, una frase, botón Siguiente), que navega con enlaces profundos a cada pantalla. El estado del recorrido va en la URL (?demo=director&paso=3), no en el navegador: reproducible, compartible, sin estado oculto.
• Guion: el que ya existe en la presentación (explicacion/public/presentacion.html, pantallas tipo guion, cuatro escenas con enlaces profundos) más la historia operativa. Un solo guion, dos superficies.
• Antes de empezar: «Reiniciar escenario» (ya existe en la barra lateral) para borrar los ensayos.
• Cambio de perfil entre historias: el selector de rol existente; en Demo Mode se muestra como «Ahora eres: Responsable de Imagenología» (P2: transición animada).
• Cierre: la pantalla «De papel a trazabilidad completa» (§14), seguida del panel «Sigue explorando»: seis a ocho puertas a la capa 2 del objetivo (cualquier equipo del parque, el expediente de compra completo, Ángeles AI libre, la torre de control, los otros perfiles, Visión futura, la guía con presentación y diagramas).
• Kill: ocultar el botón; el recorrido no toca datos.

2.4 El momento «wow» (lo que todo lo demás sirve)

Director entra → «¿Qué requiere mi atención hoy?» → «Tienes tres temas prioritarios» → abre MAG-003 → ve en segundos qué equipo es, qué le ha pasado, cuánto cuesta mantenerlo, cuánto downtime acumula, por qué piden reemplazarlo, cuánto cuesta el nuevo, documentación, presupuesto y dictamen de Biomédica → Autorizar → confirmación digital → el workflow avanza. Menos de dos minutos. Todo lo que no sirva a este recorrido se quita de la vista principal, no del producto: sigue a un clic para quien quiera explorar (capa 2 del objetivo).

3. Ángeles AI como interfaz central

3.1 Dónde vive

• ✅ Existe como panel global que se abre desde cualquier botón con una pregunta lista (angeles-ai.tsx, evento angeles-ai:preguntar), con sugerencias por perfil y motor determinista sobre los mismos datos (ia.ts): no inventa cifras, responde igual cada vez, cada respuesta trae hora de corte, fuente y enlaces.
• 🔧 Campo en el header de todas las pantallas: «✨ Pregúntale a Ángeles AI», placeholder «¿Qué necesitas saber del hospital?», atajo ⌘K / Ctrl+K (patrón command bar). Hoy es un botón; debe ser un campo persistente.
• 🔧 Contexto de pantalla. El motor ya tiene Foco (solicitud · activo · incidencia). Falta que la interfaz lo use: dentro de MAG-003 el campo dice «Pregúntale a Ángeles AI sobre MAG-003» y sugiere: ¿Qué le ha pasado a este equipo? · ¿Cuánto hemos gastado en mantenimiento? · ¿Por qué se está solicitando su reemplazo? · ¿Cuánto downtime ha acumulado? · ¿Tiene alguna solicitud abierta? · ¿Cuándo fue su último mantenimiento? · ¿Qué documentos tiene asociados? Las siete ya tienen dato detrás (metricasActivo, snapshotActivo, ITEMS_DOCUMENTALES).

3.2 Cómo responde (reglas)

• Cada bloque de respuesta y cada insight lleva una etiqueta: DATO (viene de un registro), OBSERVACIÓN (comparación entre datos), ESTIMACIÓN (proyección, con el supuesto), POSIBLE RELACIÓN (correlación; nunca causa). 🔧
• Fuente + hora de corte en cada respuesta (✅ ya) y enlace al registro (✅ ya).
• Nunca decide, nunca inventa, nunca afirma causalidad. El insight de ingresos hoy dice «la mayor desviación está en X» (ia.ts:497-500) sin atribuirla a un equipo: mantenerlo así. Si se muestra junto a MAG-003, el texto es: «Posible relación a investigar. Imagenología presenta una desviación de $X vs presupuesto y MAG-003 acumuló 96 horas de indisponibilidad en el mismo periodo. La correlación no implica causalidad.» 🔧

3.3 La respuesta principal del demo 🔧 (P0)

Al elegir «¿Qué requiere mi atención hoy?» en el dashboard:

Hay 3 temas prioritarios: 1. MAG-003 se encuentra fuera de servicio. Tiene una solicitud de reemplazo pendiente de autorización. 2. Tienes N autorizaciones pendientes. M se encuentran fuera de SLA. 3. Existen K mantenimientos preventivos vencidos. ¿Qué quieres revisar? — botón Ver MAG-003

Regla: N, M y K salen de los datos, nunca del texto. El escenario sembrado hoy da 6 pendientes (2 fuera de SLA), 3 críticos y 7 vencidos; si se quiere «5 y una», se cambia el escenario, no la frase.

3.4 IA proactiva («Ángeles AI detectó») 🔧

Tarjetas contextuales, no sólo chat. Una ya existe (MAG-003 registra 5 fallas en 90 días frente a 1.2 de promedio histórico, alertas.ts). Agregar las dos que ya tienen dato: «La etapa con mayor tiempo promedio este mes es Autorización» (tiemposPorEtapa, kpis.ts:244) y «El gasto de mantenimiento de Imagenología está 12 % arriba del presupuesto YTD» (DESVIACION_MTO, escenario.ts:1272). Cada una con su etiqueta de §3.2.

4. Dashboard ejecutivo

• ✅ Seis indicadores en la primera fila con drill-down a su detalle: Ingresos (vs presupuesto, vs año anterior), Forecast, CAPEX disponible, Autorizaciones (cantidad + monto), Equipos críticos fuera de servicio, Mantenimiento preventivo.

• ✅ Terminología: el código dice Ingresos (ingresos.ts), no «Ventas»; la guía y la presentación tampoco usan «ventas». Cerrado.

• 🔧 Quitar «En vivo». tablero-director.tsx:171-177 muestra un punto verde pulsante y «En vivo · última actualización HH:MM h». Cambiar a «DEMO · Datos simulados · última actualización simulada HH:MM h» y punto gris. Revisar el mismo término en la guía (index.html, 2 menciones) y la presentación (presentacion.html, 3 menciones): donde describa que «la pantalla se actualiza sola» está bien; donde sugiera conexión real, cambiarlo.

• 🔧 Preventivo con denominador. El cálculo ya es «realizados en fecha / programados a la fecha, incluye vencidos» (kpis.ts:147-164). La tarjeta debe decirlo: «94 % de los preventivos programados a la fecha completados en tiempo (n de m) · 7 vencidos».

• 🔧 Disponibilidad con criterio. metricas.ts:84,113 la calcula sobre 24 h × 365 días. Preferir «disponibilidad durante horas programadas de operación» con horas por tipo de equipo (p. ej. imagen 14 h × 6 días; UCI 24 × 7) o, mientras, la leyenda «calculada sobre 24 h». ❓ Criterio del hospital (pregunta KPI-01 en preguntas-abiertas.md).

• 🔧 CAPEX como jerarquía, no como cuatro cifras sueltas. Presupuesto ⊇ Autorizado ⊇ Comprometido ⊇ Ejercido; Disponible = Presupuesto − Autorizado (kpis.ts:192-233). El escenario ya anida (equipo médico 68 M: 21.9 > 17.4 > 14.1; total 96 M). Mostrarlo anidado:

  Presupuesto anual $96 M → Autorizado $56.4 M, de los cuales $35.4 M comprometido (con orden de compra) y, de éstos, $26.6 M ejercido (pagado) → Disponible $39.6 M.

  Nota: el ejemplo de la retroalimentación es anidado, no aditivo (35.4 + 26.6 ≠ 56.4); hay que presentarlo así. Las cifras del demo salen del cálculo, no de la pantalla.

• 🔧 Consistencia matemática como prueba automática (P0). Añadir a pnpm test:control invariantes: autorizado ≥ comprometido ≥ ejercido por categoría y total; disponible = presupuesto − autorizado; pendientes = tamaño de la lista y monto = suma; vencidos ⊆ programados; críticos fuera de servicio = activos críticos con incidencia abierta «fuera de servicio»; forecast ≥ real a la fecha; suma de áreas = total de ingresos; cada alerta apunta a un registro existente. Si una cifra no cuadra, falla la prueba, no la junta.

• 🔧 Leyenda global. app-shell.tsx:167 ya imprime «Datos simulados»; añadir la frase «Datos ilustrativos para fines de demostración.» en un solo lugar (pie del shell) para que aparezca en Dashboard, Asset 360, Solicitudes, Mantenimiento y Finanzas.

5. Asset 360 de MAG-003: el héroe

5.1 Lo que ya tiene el activo (✅, tipos.ts:131-144 y metricas.ts)

Identificación: código, nombre, marca, modelo, serie, hospital, área, ubicación, fecha y valor de adquisición, valor de reposición. Ciclo de vida: edad, vida útil estimada, garantía (garantiaHasta), contrato de mantenimiento (proveedor, tipo, vigencia, costo anual), criticidad, estado. Mantenimiento: último preventivo, próximo, incidencias 12 m, correctivos, horas fuera 12 m, costo 12 m, costo del periodo anterior y variación, disponibilidad 12 m, historial.

5.2 Reagrupar en tres bloques 🔧 (P0)

IDENTIFICACIÓN · CICLO DE VIDA · MANTENIMIENTO, en ese orden, cada uno con sus campos de §5.1. Añadir costo histórico de mantenimiento (suma del historial) y mantenimiento / valor de reposición (%).

5.3 Utilización 🆕 (P1)

Nuevo bloque por activo: estudios últimos 12 meses y % de capacidad estimada (por tipo: imagen = estudios; UCI = horas-cama; quirófano = procedimientos). Escenario guionado para MAG-003, TAC-02, VNT-204; generado para el resto del parque. Etiqueta «simulado». En producción saldría de RIS/PACS/HIS (❓ DAT-13). Objetivo: no sólo saber si un equipo falla, sino cuánto importa.

5.4 Impacto de indisponibilidad 🆕 (P1)

• Horas de downtime (✅ dato).
• Estudios reprogramados = días de paro × promedio diario del equipo (la justificación ya dice «cada día de paro reprograma en promedio 14 estudios»): se deriva, nunca se teclea un «31» suelto.
• Estudios canalizados a otro equipo y capacidad alternativa disponible = equipos del mismo tipo en el hospital con su utilización (sale del parque).
• Todo marcado «simulado».

5.5 Mantener vs reemplazar 🔧 (P0)

Encabezado «Información para decisión» (nunca «debe reemplazarse»): costo de mantenimiento YTD · valor de reposición · mantenimiento / valor de reposición · costo histórico · fin de soporte del fabricante (la justificación ya lo menciona: 18 meses → 🆕 campo finSoporte). La decisión sigue siendo humana.

Solicitud asociada como tarjeta visible: «EQ-2026-0182 · Reemplazo de MAG-003 · Pendiente de autorización · Ver solicitud» (el vínculo existe en los datos; falta la tarjeta).

5.6 Sucesión del activo 🆕 (P2)

Cuando EQ-2026-0182 llegue a «Alta del activo», nace MAG-00X con reemplazaA: "MAG-003"; MAG-003 muestra «Reemplazado por MAG-00X» y la línea de tiempo se lee de corrido: MAG-003 → solicitud de reemplazo → EQ-2026-0182 → orden de compra SAP → equipo nuevo → MAG-00X. Así se preserva el ciclo histórico.

6. Ficha de decisión y autorización digital

• ✅ Resumen de Ángeles AI arriba (resumenDecision: párrafos, cierre, completo, faltantes): resume, señala lo que falta, destaca riesgos. Si está completo: «La documentación requerida se encuentra completa.»
• ✅ Ficha condensada: equipo, monto, motivo, presupuesto disponible/no, equipo actual (edad, incidencias, downtime, mantenimiento YTD e histórico desde snapshotActivo), cotizaciones A/B/C, checklist documental (dictamen de Biomédica, justificación del área, cotizaciones, validación financiera, presupuesto, especificación técnica). 🔧 Orden visual: primero el resumen y la ficha; los PDF al final, nunca una pila de archivos al abrir.
• ✅ Tres botones: AUTORIZAR · REGRESAR PARA INFORMACIÓN · RECHAZAR (acciones-autorizacion.tsx:18-19,84-88).
• ✅ Modal «Confirmar autorización» con solicitud, monto, hospital, área, documento/versión, fecha, usuario, ✅ Identidad verificada, método. 🔧 Verificar que los ocho campos se vean en ese orden y que el método diga **«Autenticación corporativa
  • biometría del dispositivo»**.
• ✅ INE + selfie no ocurre en cada firma. La pantalla ya lo dice: «SSO corporativo + passkey de este dispositivo… ni INE ni selfie en cada firma… huella o rostro en este dispositivo» (acciones-autorizacion.tsx:212-219). 🆕 (P2) una pantalla «Alta de autorizador» que muestre el enrolamiento inicial (INE + selfie + prueba de vida + usuario corporativo + rol + facultades) para que el concepto se vea, y step-up para montos sensibles.
• ✅ Matriz de autorización como dato versionado (matriz.ts, v3): ≤ $150,000 gerente local (conocido) · $150,001–$4,999,999 por definir (el demo supone al director del hospital y lo marca) · ≥ $5,000,000 Director del Grupo (conocido). Condiciones por presupuesto, tipo, área y hospital. 🔧 Texto exacto en pantalla: «Cadena de autorización corporativa — por validar con Hospital Ángeles». 🔧 Decir que es configurable por monto, hospital, área, tipo de compra, CAPEX/OPEX, presupuesto, criticidad y categoría de activo (CAPEX/OPEX, criticidad y categoría son 🆕 campos de condición).
• 🔧 Mensaje al autorizar (§2.1 paso 8) y, para la segunda autorización del guion (EQ-2026-0190, Monitores), mostrar el paso a SAP: se crea la solicitud de pedido simulada y el CAPEX disponible baja.
• 🔮 En producción: evidencia conservada con constancia NOM-151 (§1.7); e.firma en umbrales altos si HA lo exige.

7. Torre de control de equipo y mantenimiento

Es el módulo principal del producto: ACTIVOS (qué tenemos) + MANTENIMIENTO (qué les pasa) + SOLICITUDES (qué necesitamos comprar o reemplazar) + AUTORIZACIONES (dónde está cada decisión).

• ✅ Existe en /control-tower y /operacion (torreControl, kpis.ts:299). 🔧 Un solo nombre, «Torre de control · Equipo y mantenimiento», y una pantalla con los cuatro bloques.
• KPIs de mantenimiento: ✅ abiertas, críticas, fuera de SLA, tiempo promedio de resolución, disponibilidad, cumplimiento de preventivos, reincidencias, presupuesto y proyección. 🔧 Añadir downtime total y costo de mantenimiento YTD como tarjetas.
• KPIs de activos: ✅ total, valor, críticos, fuera de servicio. 🆕 próximos al fin de vida, fuera de garantía (garantiaHasta ya existe), con solicitud de reemplazo (computable desde las solicitudes).
• KPIs de solicitudes: ✅ completos (abiertas, monto solicitado, autorizado, pendiente, pendientes, fuera de SLA, tiempo promedio de autorización, solicitud → compra, compra → instalación).
• Alertas: máximo 3–5, cada una con el verbo Revisar que abre el activo, la incidencia o la solicitud. ✅ Existen con «Ver equipo» (alertas.ts); 🔧 unificar el verbo. Todas las del ejemplo ya son computables: MAG-003 fuera de servicio desde hace N horas · 7 preventivos vencidos · EQ-2026-0182 lleva N días en autorización (solicitudesDetenidas) · VNT-204 presentó su cuarta falla en 60 días (parque.ts) · 🆕 14 equipos perderán garantía en 60 días (desde garantiaHasta).
• Funnel de mantenimiento ✅ idéntico al pedido (§2.2). Funnel de equipo nuevo ✅ idéntico: Solicitud → Evaluación técnica / Biomédica → Validación presupuestal → Cotizaciones → Autorización → Solicitud de pedido SAP → Orden de compra SAP → Entrega → Instalación → Alta del activo → Cerrada (procesos.ts:29-44). 🔧 Renombrar «Requisición SAP» a «Solicitud de pedido SAP» y «Orden de compra» a «Orden de compra SAP».
• 🔧 Cada etapa muestra siempre: responsable · fecha de entrada · días en etapa · SLA (semáforo) · próxima acción. Los cinco datos existen (diasEnEtapa, semaforo, siguienteAccionSolicitud); verificar que las cinco columnas se vean en cada tarjeta.
• Registro de incidencias: ✅ QR o búsqueda → describir (texto, foto) → preguntas → enviar. 🔧 tercera pregunta («¿Existe equipo alternativo?»); 🆕 video/audio/archivo simulados (P2).
• Criticidad sugerida: ✅ el triage la calcula (triage.ts). 🔧 Mostrar el porqué: **«🔴 CRÍTICA — Equipo de alta criticidad
  • fuera de servicio + sin respaldo disponible»** y permitir que el usuario la cambie con motivo (queda en el historial).
• ✅ Audit trail en cada solicitud («Historial / audit trail», ficha-solicitud.tsx:631) sobre eventos sólo-anexar. 🔧 Mismo bloque en incidencias y activos, con el formato: 03 Sep · Solicitud creada · Juan Pérez.
• ✅ ID único que viaja (EQ-2026-0182, INC-2026-01843) por solicitud, autorización, SAP, compra, entrega e instalación.

8. SAP: decir sólo lo que es cierto

Las transacciones del demo vienen del diagrama del propio hospital (página 1 del proceso recibido; ver conocimiento/01-proceso/proceso-adquisicion-activo-fijo.md, §2). Eso cambia dos puntos de la retroalimentación:

Cadena conceptual en pantalla: Solicitud aprobada → Solicitud de pedido SAP (ME51N) → Orden de compra SAP (ME21N) → Recepción (MB01 / MIGO) → Alta o actualización del activo (AS01) → Programación de pago (ZFI123, por confirmar). Los prefijos SIM- de cada referencia se quedan.

🔧 Aviso técnico en /arquitectura y en cada panel SAP: «Arquitectura conceptual. Integración final sujeta a validación de versión SAP, módulos disponibles, APIs y configuración actual de Hospital Ángeles.»

9. Honestidad de datos (dónde va cada etiqueta)

Nada de lo anterior se afirma como conocido. El demo demuestra cómo funcionaría, no que ya conocemos datos o arquitectura.

10. Navegación: producto a la izquierda, propuesta aparte

Hoy el menú mezcla producto y propuesta (app-shell.tsx:56-96: «Mapa del proceso», «Arquitectura e integración» y «Visión» viven bajo «Estratégico»). 🔧 (P1):

PRODUCTO: Inicio · Mis autorizaciones · Activos · Mantenimiento · Solicitudes · Compras · Ángeles AI. (Los expedientes de compra, licitaciones, proveedor, recepción y pagos del flujo M0–M6 cuelgan de Compras.)

PROPUESTA / DEMO: Cómo funciona · Integración SAP · Arquitectura · Visión futura.

🔧 «Adquisiciones autónomas» deja de ser titular. La sección pasa a llamarse «Adquisiciones inteligentes», subtítulo «Visión futura» (src/app/(app)/vision/page.tsx:36-37, src/lib/domain/vision.ts:2, conocimiento/02-producto/vision.md). Ahí queda sólo lo que es extrapolación: agentes negociando con proveedores, autorización por política con validez legal, gemelo multi-marca que dispara compras. Lo demás del horizonte (torre, IA, gemelo del activo, RTLS, software del equipo, mantenimiento por condición, agentes de compras en SAP) se ve dentro del producto, como lo que ya está o como «siguiente escalón» en su pantalla (§12): nunca presentado como hecho cuando no lo está, pero tampoco escondido.

11. Lo que el software podrá hacer (la parte de soñar, con cerca)

Esta sección es la que la retroalimentación no traía. Está escrita para un grupo con decenas de hospitales (la prensa cuenta 27–28; dato por confirmar con HA), con las cercas que ya fijó la investigación de la visión (vision.md, 26 fuentes): lo que la industria ya hace se marca ✔ verificado; lo que nadie ha demostrado se marca ~ extrapolación y se cuenta como tal.

11.1 Niveles de autonomía de Ángeles AI (la regla para todo lo demás)

Es la autonomía por niveles que ya usan operaciones hospitalarias con agentes (MIT CTL / Novant Health, 2026 ✔) y que hoy recomiendan los marcos de gobierno de agentes en cadenas de suministro: alcance estrecho, humano en el lazo, bitácora y escalación visibles. Cada acción N2/N3 nace con su apagador y su registro; sin eso no se construye.

11.2 Para el director

• Autorizar desde el teléfono con passkey; la ficha de decisión cabe en una pantalla. N1 ✔
• Agenda de decisiones de la semana: las autorizaciones ordenadas por impacto y SLA, cada una con su resumen. N0
• Suplencia automática: si una autorización lleva N días y el titular está fuera, Ángeles AI propone al suplente que la matriz permite y lo activa con un clic. N1. Humano: el titular define a su suplente.
• Costo de no decidir: cada día detenida = estudios no realizados × ingreso promedio, siempre como ESTIMACIÓN. N0
• El cierre del mes antes de que termine: forecast con sus supuestos a la vista y qué lo mueve. N0

11.3 Para el parque de equipos

• Plan de renovación a cinco años generado por reglas (edad, vida útil, fin de soporte del fabricante, fallas, mantenimiento / valor de reposición, utilización) y revisado por un comité de capital. N1 ✔ (comités de análisis de valor, AHRMM). No es predicción: es un ranking explicable. La predicción de reemplazo en producción sigue ~ extrapolación.
• Preventivos por riesgo y por uso (AAMI EQ89 ✔), programados en el hueco de agenda con menor impacto clínico. N1 → N2
• Alertas de seguridad y retiros del fabricante (COFEPRIS / FDA) cruzados con el parque: «3 equipos de este modelo en el grupo». N0 → N1
• Tecnovigilancia NOM-240 ✔: un incidente adverso con un dispositivo genera el reporte prellenado para COFEPRIS y lo deja listo para que el responsable lo revise y envíe. N1
• Garantías y contratos: aviso 60 días antes del vencimiento y propuesta (renovar, cambiar a mantenimiento interno, renegociar) con el historial del equipo como argumento. N1
• Contratos de mantenimiento con SLA medido por el sistema: downtime real vs SLA contratado → penalización o crédito calculado y la nota lista para el proveedor. N1. Humano: Compras aprueba el cobro.
• Utilización real desde RIS/PACS/HIS (bitácoras DICOM) en vez de estimada. N0 ❓ integración. El «gemelo digital del parque que dispara compras» sigue ~ extrapolación; el mantenimiento predictivo existe hoy como servicio del fabricante sobre su propio equipo, no multi-marca.

11.4 Para mantenimiento

• Asignación automática del técnico o proveedor según contrato, especialidad y carga; aviso al área. N2
• Refacción en un clic: al diagnosticar, Ángeles AI arma la solicitud de refacción con la cotización vigente del contrato y la manda a autorizar. N1
• Reincidencia: cuarta falla en 60 días abre de oficio la revisión «reparar vs reemplazar» con la ficha de decisión. N1
• Técnico en campo: voz y foto; checklist por tipo de equipo; el área valida con su firma y el equipo vuelve a servicio. N0 → N1

11.5 Para solicitudes y compras

• El expediente se arma solo: justificación desde el historial del equipo, cotizaciones desde contratos marco, validación presupuestal automática; el humano confirma la necesidad y el criterio técnico. N1 → N2 ✔ (parcial: así se guionó la visión)
• Comparativo por costo total a cinco años (precio + mantenimiento + consumibles + capacitación + downtime esperado), no por precio. N0 ✔ (HMPI, BCG, AHRMM)
• «¿Este precio es razonable?» contra compras históricas del grupo. N0, siempre como OBSERVACIÓN.
• Compras fraccionadas: varias compras al mismo proveedor y centro de costo por debajo del umbral, agrupadas. N0
• Proveedores calificados por desempeño real: entregas a tiempo, fallas tempranas, respuesta a incidencias. N0
• Negociación agente-a-agente con proveedores: ~ extrapolación, se cuenta como idea, no como plan.

11.6 Para finanzas

• CAPEX en vivo desde SAP con la jerarquía de §4 y forecast de ejercicio. N0
• Conciliación de tres vías automática (orden de compra, recepción, CFDI validado por el SAT) ✔ CFDI 4.0 / PAC. N2
• Programación de pago propuesta según condiciones y flujo. N1
• Autorización por política de lo pequeño, rutinario y reversible. N3 ~ (validez legal en México por validar)

11.7 Para el grupo (donde «gigante» cambia las reglas)

• Torre corporativa: los mismos indicadores por hospital, comparables: downtime, costo de mantenimiento por tipo de equipo, tiempo de autorización, cumplimiento de preventivos, edad del parque. N0
• Compra consolidada: «siete hospitales necesitan ventiladores en los próximos 12 meses» → una sola negociación de grupo. N1 (práctica común de compras hospitalarias en grupo)
• Préstamo o redistribución entre hospitales: un equipo subutilizado en un hospital cubre la falla de otro en la misma ciudad; el sistema lo propone con la logística. N1
• Estandarización del catálogo (marcas y modelos): menos refacciones distintas, menos capacitación, mejor precio. N0 insight
• Matriz corporativa por sociedad, hospital y área, versionada y con auditoría de cambios. N0, configuración
• Contratos marco de grupo con SLA medido en todos los hospitales desde la misma torre. N1
• Tecnovigilancia y retiros consolidados a nivel grupo. N0 → N1
• Lo que aprende un hospital lo saben todos: fallas tempranas de un modelo en un hospital alertan a los demás. N0

Lo de §11 que ya existe se nombra en el producto como lo que es; lo que no existe se ve como «siguiente escalón» en la pantalla donde cabría (§12). Nada se construye en el demo sin pasar por P0–P2, y nada se muestra como hecho cuando no lo está.

12. El horizonte está en el demo desde el principio

Jorge, 2026-09-30: «no es 2030: es precisamente el demo que estamos mostrando, ya lo trae». El demo no es el paso previo al horizonte; es el horizonte en su primer escalón, funcionando. Lo que hacen en 2026 los hospitales y plataformas que llevan la batuta (torre de control, hospital con IA, gemelo del activo, agentes de compras, política como dato) ya vive en nuestras pantallas, con nombre y apellido, desde el primer minuto del recorrido. En dos minutos el visitante entiende qué hace; al explorar descubre que lo que vio es lo mismo que hacen los líderes. Lo que todavía no está se muestra dentro de la pantalla donde cabría, como «siguiente escalón», en una línea con su fuente, nunca escondido en una sección que nadie abre.

12.1 Los que llevan la batuta, y dónde está eso en el demo (con fuente, §17)

12.2 Un día en Hospital Ángeles con la torre (lo que el demo ya hace, contado como lo cuentan los líderes)

07:15. La directora abre la torre: tres temas. MAG-003 está fuera de servicio y tiene un reemplazo pendiente de autorizar. Johns Hopkins lo llama command center; aquí, torre de control.

07:20. Abre MAG-003: once años, siete incidencias en doce meses, 96 horas fuera, costo de mantenimiento contra valor de reposición, fin de soporte del fabricante en 18 meses. «Información para decisión», no una orden. El gemelo del activo, como en Singapur; la utilización, como en Mater Private.

07:25. Ficha de decisión: el resumen de Ángeles AI, la documentación completa, tres cotizaciones. Autoriza con su identidad; EQ-2026-0182 pasa sola al Director del Grupo. Con EQ-2026-0190 se crea la solicitud de pedido SAP y el CAPEX disponible baja. La política como dato y el expediente que se arma solo: lo que SAP está poniendo en manos de agentes este año.

09:40. Una técnica escanea TAC-02 con el teléfono, describe la falla, foto, «no puede seguir operando». Criticidad sugerida: crítica, con su porqué. En la laptop de Dirección la alerta aparece sola; los críticos pasan de tres a cuatro. El hospital con IA que atiende, como lo plantea Sheba.

09:45. Asset 360 de TAC-02: «5 fallas en 90 días frente a 1.2 de promedio». Crear solicitud de reemplazo: prellenada, ligada al equipo, EQ-2026-0198. La versión por reglas de lo que GE, Siemens y Philips hacen con predicción sobre sus equipos.

12:00. «¿Qué solicitudes llevan más de cinco días?» «La etapa más lenta este mes es Autorización.» Con fuente y hora de corte.

16:00. Torre de equipo y mantenimiento: VNT-204 presentó su cuarta falla en 60 días; 14 equipos pierden garantía en 60 días. Cada alerta con su verbo. La calidad del dato, medida, como en Bradford.

Todo lo anterior es el demo, hoy, más P0–P1. Lo que no está (robots, drones, RTLS, gemelo multi-marca, agentes negociando) se ve dentro de la pantalla donde cabría, como «siguiente escalón», con su fuente en una línea.

12.3 Cómo se integra desde el principio (qué se construye)

• Intro del Demo Mode (P1-9): una pantalla, una frase: «Lo que van a ver es lo que ya hacen los hospitales que llevan la batuta: una torre de control (Johns Hopkins), un hospital con IA que atiende (Sheba), cada equipo con su gemelo (Singapur, Mater Private), compras y autorizaciones por política (SAP 2026). Aquí, funcionando sobre el proceso de Hospital Ángeles.»
• Leyenda por paso (P1-9): bajo cada paso del recorrido, una línea «así lo hacen en …» con el nombre y el año.
• Tarjetas «siguiente escalón» (P1-9), cinco, cada una con fuente: Asset 360 (RTLS; software del equipo; mantenimiento por condición), torre (logística autónoma: robots y drones), etapa Requisición (agentes de compras en SAP). Una línea, un enlace a la fuente, etiqueta «siguiente escalón». No simulan funcionalidad.
• Bloques nuevos, pequeños y simulados que hacen visible el horizonte en el producto: software del equipo (P2-9), reporte de tecnovigilancia prellenado (P2-10), simulación «¿qué pasa si?» (P2-11).
• Visión futura queda sólo para lo que es extrapolación: agentes negociando con proveedores, autorización por política con validez legal en México, gemelo multi-marca que dispara compras. Y la presentación lleva la tabla de §12.1 como una pantalla «Los que llevan la batuta, y dónde está eso en el demo».
• La regla de §9 no cambia: todo con etiqueta; nada que parezca conectado o hecho cuando no lo está.

13. Fases del producto (cómo se cuenta)

FASE 1 — TRAZABILIDAD: digitalización, workflow, activos, incidencias, solicitudes, autorizaciones, integración SAP. Es el demo de hoy más P0–P1.

FASE 2 — INTELIGENCIA: Ángeles AI contextual y proactiva, alertas, anomalías, criticidad sugerida, utilización, insights con etiqueta. Parte ya existe; el resto es P1–P2 y §11 N0–N1.

FASE 3 — AUTOMATIZACIÓN: adquisiciones inteligentes, automatización avanzada, IoT / RFID, gemelo digital, agentes. §11 N2–N3 y lo marcado ~ extrapolación; vive en Visión futura.

Los tres niveles de la guía (hoy · demo · visión) cuentan el tiempo; las tres fases cuentan el producto. Se muestran juntas en una franja de la presentación, sin confundirlas.

14. Pantalla final y mensaje principal

De papel a trazabilidad completa. HOY: solicitud física · firma física · seguimiento manual · llamadas · correos · carpetas · información fragmentada. CON CONTROL TOWER: solicitud digital · workflow · responsable · SLA · firma digital · integración SAP · Asset 360 · alertas · Ángeles AI.

Cierre (la presentación ya lo usa; el Demo Mode termina con él):

Una capa inteligente de gestión que conecta información administrativa, activos y procesos del hospital para que cada solicitud sea trazable, cada autorización tenga responsable y tiempo, y cada activo pueda seguirse durante todo su ciclo de vida.

Resultado esperado: alguien de Hospital Ángeles entiende el concepto sin explicación técnica previa: «puedo ver qué está pasando en el hospital, saber qué requiere mi atención, abrir cualquier equipo y conocer toda su historia, reportar una falla, solicitar un reemplazo, seguir exactamente dónde está la solicitud, autorizarla digitalmente y conectar todo el proceso con SAP».

15. Prioridades, recortadas por el estado real

Tamaño: S = horas · M = media sesión · L = una sesión. Kill = cómo se apaga en una línea.

P0 — obligatorio (una sesión, un deploy)

Lo que la retroalimentación ponía en P0 y ya está: matriz configurable y «por definir», Ángeles AI visible con «¿Qué requiere mi atención hoy?», ficha de decisión con resumen, tres botones, modal con identidad, INE sólo en el alta, eyebrow «Datos simulados».

P1 — muy importante

P2 — deseable