Evalúa con tu IA

Completa los campos obligatorios para activar la copia: ¿Qué productos Skip vas a integrar?, Stack del backend, Stack del frontend, Ingenieros/as disponibles, Flujo actual de checkout del paciente (alto nivel).

# Resumen de integración Skip

Skip es una plataforma chilena de salud con dos productos que los partners integran:

## Spot
Onboarding de pacientes y automatización de boletas médicas. Tres formas de integración:
- Widget: el backend mintea un token de un solo uso (POST /api/spot/widget), se embebe un iframe en el sitio del partner, el paciente llena un formulario, el partner escucha eventos postMessage.
- POS: flujo de mostrador. El personal hace lookup por RUT, crea usuario. Sin iframe.
- Boletas: el backend empuja boletas a /api/spot/gastos (archivo) o /api/spot/gastos-url (URL). La IA extrae los datos, el reembolso ISAPRE se presenta automático.

Auth: public_key (browser-safe, query param). Algunos endpoints admin usan un header secret_key aparte.

## AAPD / CNPL
"Atiéndete Ahora y Paga Después". 30% pagado al momento con tarjeta, 70% financiado por Ventipay (proveedor de préstamo, totalmente gestionado por Skip), reembolso ISAPRE presentado automático. Skip cobra el 70% restante cuando la ISAPRE paga — o antes si hay 3 días de acceso ISAPRE bloqueado, o al día 45 sin aprobación.

Endpoints (gokeipay-api en https://pay.getskip.ai):
- POST /orders (auth: client_secret) — crea la orden, devuelve hash
- POST /orders/{hash}/validate_customer_identity (auth: client_id) — el widget llama esto
- POST /orders/{hash}/add_payment_method (auth: client_id) — el widget llama esto
- POST /orders/{hash}/payment (auth: client_id) — el widget llama esto
- PUT /orders/{hash}/refund (auth: client_secret) — reembolso total o parcial

Credenciales de auth:
- public_key: browser-safe, para Spot.
- client_id: browser-safe, para operaciones de paciente AAPD.
- client_secret: solo backend, para creación de órdenes/reembolsos AAPD.
- webhook_secret: solo backend, para verificar firmas HMAC-SHA256 de webhooks.

## Webhooks (AAPD)
SkipPay envía webhooks firmados a una URL hosteada por el partner.
- Firma: X-Gokeipay-Signature: sha256={hex}, HMAC-SHA256 sobre el body JSON crudo usando webhook_secret.
- Retries: 6 intentos con backoff exponencial (1m, 5m, 15m, 30m, 60m). Timeout: 10s por intento.
- Eventos que reciben los partners: order.paid, order.partially_paid, order.refunded, order.failed, order.cancelled.
- Siempre incluye event_id para idempotencia.

## Ambientes
- Producción: backend.getskip.ai (Spot), pay.getskip.ai (AAPD), spot.getskip.ai (host del widget).
- Staging: mismos hosts con prefijo staging., ej. staging.backend.getskip.ai. Credenciales de prueba son pk_test_*, ci_test_*, st_test_*.
- Presentación ISAPRE en staging está mockeada (no se presentan reembolsos reales).
- Ventipay en staging es sandbox (no se mueve plata real).

## Fases típicas de integración
1. Emisión de cuenta y credenciales (equipo Skip).
2. Creación server-side de órdenes (solo AAPD): POST /orders.
3. Minteo server-side de widget tokens: POST /api/spot/widget.
4. Embed del iframe + manejo de eventos postMessage en frontend.
5. Receptor de webhooks: endpoint HTTPS + verificación HMAC + procesamiento idempotente.
6. Test end-to-end en staging con pacientes de prueba.
7. Rollout a producción.

Skip se encarga de: presentación de reembolsos ISAPRE, retries de pago, notificaciones WhatsApp/email al paciente, payouts a sub-centros (para meta-prestadores). Los partners no implementan nada de esto.

## Conceptos
- Provider: la ficha del partner en la base de datos de Skip.
- Beneficiary: la ficha del paciente. Identificada por RUT.
- ISAPRE: aseguradora privada chilena de salud. Las credenciales del paciente se guardan en Skip; Skip presenta los reembolsos en su nombre.
- RUT: ID nacional chileno. Formato XXXXXXXX-Y donde Y es un dígito verificador (0-9 o K). Skip normaliza (saca los puntos).
- order_token: igual al campo hash que devuelve POST /orders. Pásalo al widget para activar el flujo AAPD.
- widget_token: UUID que identifica un TempWidgetToken. TTL de 1 hora, o 30 días para long-term tokens.
- meta-prestador: partner que opera con muchas sub-clínicas detrás de una sola integración. Onboardea sub-clínicas vía POST /api/spot/sacmed/centers, después pasa provider_rut en POST /orders.

## Qué los partners NO construyen
- Integración con la ISAPRE (Skip se encarga).
- Underwriting de crédito/préstamo (Ventipay se encarga).
- Despacho de notificaciones al paciente (Skip se encarga).
- Liquidación / payouts (Skip se encarga).
- Almacenamiento de tarjetas / scope PCI (Ventipay se encarga).


# Contexto de nuestro equipo
- Productos a integrar: 
- Stack del backend: 
- Stack del frontend: 
- Ingenieros disponibles: 
- Flujo actual de checkout del paciente:

- Otros constraints: ninguno declarado

# Tu tarea
Produce una línea de tiempo de integración Skip por fases en días-persona para nuestro equipo. Para cada fase, lista el entregable concreto, la estimación en eng-días (sé específico — asume ingenieros mid-level), y cualquier dependencia de trabajo lado Skip (emisión de credenciales, setup de ambiente). Cubre: setup de cuenta/credenciales, creación server-side de órdenes (si AAPD), minteo de widget token, embed del iframe en frontend, receptor de webhooks, test end-to-end en staging, rollout a producción. Marca riesgos específicos a nuestro stack y cuáles fases se pueden paralelizar. Termina con una línea con la "fecha realista de lanzamiento más temprana" desde hoy.

Completa los campos obligatorios para activar la copia: Tu flujo actual end-to-end del paciente (numerado, por favor), ¿Cómo emiten las boletas hoy?, ¿Pueden enviarnos las boletas digitales (PDF o XML)?, ¿Pueden enviarnos órdenes médicas y comprobantes de atención?, Productos Skip que planeas usar.

# Resumen de integración Skip

Skip es una plataforma chilena de salud con dos productos que los partners integran:

## Spot
Onboarding de pacientes y automatización de boletas médicas. Tres formas de integración:
- Widget: el backend mintea un token de un solo uso (POST /api/spot/widget), se embebe un iframe en el sitio del partner, el paciente llena un formulario, el partner escucha eventos postMessage.
- POS: flujo de mostrador. El personal hace lookup por RUT, crea usuario. Sin iframe.
- Boletas: el backend empuja boletas a /api/spot/gastos (archivo) o /api/spot/gastos-url (URL). La IA extrae los datos, el reembolso ISAPRE se presenta automático.

Auth: public_key (browser-safe, query param). Algunos endpoints admin usan un header secret_key aparte.

## AAPD / CNPL
"Atiéndete Ahora y Paga Después". 30% pagado al momento con tarjeta, 70% financiado por Ventipay (proveedor de préstamo, totalmente gestionado por Skip), reembolso ISAPRE presentado automático. Skip cobra el 70% restante cuando la ISAPRE paga — o antes si hay 3 días de acceso ISAPRE bloqueado, o al día 45 sin aprobación.

Endpoints (gokeipay-api en https://pay.getskip.ai):
- POST /orders (auth: client_secret) — crea la orden, devuelve hash
- POST /orders/{hash}/validate_customer_identity (auth: client_id) — el widget llama esto
- POST /orders/{hash}/add_payment_method (auth: client_id) — el widget llama esto
- POST /orders/{hash}/payment (auth: client_id) — el widget llama esto
- PUT /orders/{hash}/refund (auth: client_secret) — reembolso total o parcial

Credenciales de auth:
- public_key: browser-safe, para Spot.
- client_id: browser-safe, para operaciones de paciente AAPD.
- client_secret: solo backend, para creación de órdenes/reembolsos AAPD.
- webhook_secret: solo backend, para verificar firmas HMAC-SHA256 de webhooks.

## Webhooks (AAPD)
SkipPay envía webhooks firmados a una URL hosteada por el partner.
- Firma: X-Gokeipay-Signature: sha256={hex}, HMAC-SHA256 sobre el body JSON crudo usando webhook_secret.
- Retries: 6 intentos con backoff exponencial (1m, 5m, 15m, 30m, 60m). Timeout: 10s por intento.
- Eventos que reciben los partners: order.paid, order.partially_paid, order.refunded, order.failed, order.cancelled.
- Siempre incluye event_id para idempotencia.

## Ambientes
- Producción: backend.getskip.ai (Spot), pay.getskip.ai (AAPD), spot.getskip.ai (host del widget).
- Staging: mismos hosts con prefijo staging., ej. staging.backend.getskip.ai. Credenciales de prueba son pk_test_*, ci_test_*, st_test_*.
- Presentación ISAPRE en staging está mockeada (no se presentan reembolsos reales).
- Ventipay en staging es sandbox (no se mueve plata real).

## Fases típicas de integración
1. Emisión de cuenta y credenciales (equipo Skip).
2. Creación server-side de órdenes (solo AAPD): POST /orders.
3. Minteo server-side de widget tokens: POST /api/spot/widget.
4. Embed del iframe + manejo de eventos postMessage en frontend.
5. Receptor de webhooks: endpoint HTTPS + verificación HMAC + procesamiento idempotente.
6. Test end-to-end en staging con pacientes de prueba.
7. Rollout a producción.

Skip se encarga de: presentación de reembolsos ISAPRE, retries de pago, notificaciones WhatsApp/email al paciente, payouts a sub-centros (para meta-prestadores). Los partners no implementan nada de esto.

## Conceptos
- Provider: la ficha del partner en la base de datos de Skip.
- Beneficiary: la ficha del paciente. Identificada por RUT.
- ISAPRE: aseguradora privada chilena de salud. Las credenciales del paciente se guardan en Skip; Skip presenta los reembolsos en su nombre.
- RUT: ID nacional chileno. Formato XXXXXXXX-Y donde Y es un dígito verificador (0-9 o K). Skip normaliza (saca los puntos).
- order_token: igual al campo hash que devuelve POST /orders. Pásalo al widget para activar el flujo AAPD.
- widget_token: UUID que identifica un TempWidgetToken. TTL de 1 hora, o 30 días para long-term tokens.
- meta-prestador: partner que opera con muchas sub-clínicas detrás de una sola integración. Onboardea sub-clínicas vía POST /api/spot/sacmed/centers, después pasa provider_rut en POST /orders.

## Qué los partners NO construyen
- Integración con la ISAPRE (Skip se encarga).
- Underwriting de crédito/préstamo (Ventipay se encarga).
- Despacho de notificaciones al paciente (Skip se encarga).
- Liquidación / payouts (Skip se encarga).
- Almacenamiento de tarjetas / scope PCI (Ventipay se encarga).


# Nuestro flujo actual


# Cómo emitimos boletas hoy
- Modo de emisión: 
- Proveedor (si aplica): N/A
- ¿Podemos enviar las boletas digitales a Skip?: 
- ¿Podemos enviar órdenes médicas y comprobantes de atención?: 

# Productos Skip a usar


# Tu tarea
Produce un mapeo lado-a-lado de nuestro flujo actual a un flujo integrado con Skip. Para cada paso numerado:
- Reformula el paso.
- Identifica qué endpoint(s) o webhook(s) de Skip lo reemplaza o complementa.
- Marca pasos sin equivalente Skip que deben quedarse en nuestro lado.
- Marca pasos que desaparecen completamente porque Skip los hace por nosotros.

Considera específicamente cómo se integra nuestro flujo de boletas digitales con el endpoint /api/spot/gastos[-url] de Skip, dada nuestra capacidad de emisión y envío. Si tenemos órdenes médicas y comprobantes de atención disponibles para enviar, indica cómo aprovecharlos para mejorar la rendición a la ISAPRE.

Termina con tres listas:
1. Pasos que eliminamos (Skip los hace).
2. Pasos que modificamos (un endpoint Skip reemplaza nuestra lógica).
3. Pasos que mantenemos igual.

Sé explícito con qué credencial Skip usa cada llamada nueva (public_key vs client_id vs client_secret).

Completa los campos obligatorios para activar la copia: Productos Skip, Equipo disponible (roles, nombres), Resumen del stack, Deadline.

# Resumen de integración Skip

Skip es una plataforma chilena de salud con dos productos que los partners integran:

## Spot
Onboarding de pacientes y automatización de boletas médicas. Tres formas de integración:
- Widget: el backend mintea un token de un solo uso (POST /api/spot/widget), se embebe un iframe en el sitio del partner, el paciente llena un formulario, el partner escucha eventos postMessage.
- POS: flujo de mostrador. El personal hace lookup por RUT, crea usuario. Sin iframe.
- Boletas: el backend empuja boletas a /api/spot/gastos (archivo) o /api/spot/gastos-url (URL). La IA extrae los datos, el reembolso ISAPRE se presenta automático.

Auth: public_key (browser-safe, query param). Algunos endpoints admin usan un header secret_key aparte.

## AAPD / CNPL
"Atiéndete Ahora y Paga Después". 30% pagado al momento con tarjeta, 70% financiado por Ventipay (proveedor de préstamo, totalmente gestionado por Skip), reembolso ISAPRE presentado automático. Skip cobra el 70% restante cuando la ISAPRE paga — o antes si hay 3 días de acceso ISAPRE bloqueado, o al día 45 sin aprobación.

Endpoints (gokeipay-api en https://pay.getskip.ai):
- POST /orders (auth: client_secret) — crea la orden, devuelve hash
- POST /orders/{hash}/validate_customer_identity (auth: client_id) — el widget llama esto
- POST /orders/{hash}/add_payment_method (auth: client_id) — el widget llama esto
- POST /orders/{hash}/payment (auth: client_id) — el widget llama esto
- PUT /orders/{hash}/refund (auth: client_secret) — reembolso total o parcial

Credenciales de auth:
- public_key: browser-safe, para Spot.
- client_id: browser-safe, para operaciones de paciente AAPD.
- client_secret: solo backend, para creación de órdenes/reembolsos AAPD.
- webhook_secret: solo backend, para verificar firmas HMAC-SHA256 de webhooks.

## Webhooks (AAPD)
SkipPay envía webhooks firmados a una URL hosteada por el partner.
- Firma: X-Gokeipay-Signature: sha256={hex}, HMAC-SHA256 sobre el body JSON crudo usando webhook_secret.
- Retries: 6 intentos con backoff exponencial (1m, 5m, 15m, 30m, 60m). Timeout: 10s por intento.
- Eventos que reciben los partners: order.paid, order.partially_paid, order.refunded, order.failed, order.cancelled.
- Siempre incluye event_id para idempotencia.

## Ambientes
- Producción: backend.getskip.ai (Spot), pay.getskip.ai (AAPD), spot.getskip.ai (host del widget).
- Staging: mismos hosts con prefijo staging., ej. staging.backend.getskip.ai. Credenciales de prueba son pk_test_*, ci_test_*, st_test_*.
- Presentación ISAPRE en staging está mockeada (no se presentan reembolsos reales).
- Ventipay en staging es sandbox (no se mueve plata real).

## Fases típicas de integración
1. Emisión de cuenta y credenciales (equipo Skip).
2. Creación server-side de órdenes (solo AAPD): POST /orders.
3. Minteo server-side de widget tokens: POST /api/spot/widget.
4. Embed del iframe + manejo de eventos postMessage en frontend.
5. Receptor de webhooks: endpoint HTTPS + verificación HMAC + procesamiento idempotente.
6. Test end-to-end en staging con pacientes de prueba.
7. Rollout a producción.

Skip se encarga de: presentación de reembolsos ISAPRE, retries de pago, notificaciones WhatsApp/email al paciente, payouts a sub-centros (para meta-prestadores). Los partners no implementan nada de esto.

## Conceptos
- Provider: la ficha del partner en la base de datos de Skip.
- Beneficiary: la ficha del paciente. Identificada por RUT.
- ISAPRE: aseguradora privada chilena de salud. Las credenciales del paciente se guardan en Skip; Skip presenta los reembolsos en su nombre.
- RUT: ID nacional chileno. Formato XXXXXXXX-Y donde Y es un dígito verificador (0-9 o K). Skip normaliza (saca los puntos).
- order_token: igual al campo hash que devuelve POST /orders. Pásalo al widget para activar el flujo AAPD.
- widget_token: UUID que identifica un TempWidgetToken. TTL de 1 hora, o 30 días para long-term tokens.
- meta-prestador: partner que opera con muchas sub-clínicas detrás de una sola integración. Onboardea sub-clínicas vía POST /api/spot/sacmed/centers, después pasa provider_rut en POST /orders.

## Qué los partners NO construyen
- Integración con la ISAPRE (Skip se encarga).
- Underwriting de crédito/préstamo (Ventipay se encarga).
- Despacho de notificaciones al paciente (Skip se encarga).
- Liquidación / payouts (Skip se encarga).
- Almacenamiento de tarjetas / scope PCI (Ventipay se encarga).


# Contexto del proyecto
- Productos: 
- Equipo: 
- Stack: 
- Deadline: 
- Constraints: ninguno declarado

# Tu tarea
Produce un plan de proyecto en Markdown para la integración Skip que un stakeholder no técnico (director(a) de clínica, COO) pueda leer. Estructura:

## Objetivo
Una sola frase.

## Hitos
Numerados, cada uno con:
- Entregable (qué va a existir cuando esté listo).
- Owner (persona nombrada).
- Duración estimada en calendario.
- Criterios de aceptación.

## Línea de tiempo
Gantt en ASCII desde hoy hasta el deadline.

## Riesgos
Top 5 riesgos con mitigación.

## Dependencias del lado Skip
Qué debe entregar el equipo Skip y cuándo.

Escribe para lectura no técnica. Sin jerga sin explicación.