Descargar Markdown Documento original en GitHub

Aceptación de la integración de aplicaciones

Las comprobaciones en modo cuenta obtienen ahora afirmaciones de identidad de corta duración. Un estado de compra negativo de Launch solo demuestra el estado de compra, no el rechazo de ejecución por Licentivo. Demostrar el comportamiento de ejecución requiere la comprobación con el SDK oficial; no implica despliegue en producción ni publicación del SDK. Consulte los límites de cuentas.

Hay dos niveles de pruebas independientes: comprobaciones automatizadas locales controladas y comprobaciones externas de la sandbox del comerciante. Un doble de prueba, una lectura correcta del catálogo, una configuración generada o una comprobación de salud superada nunca demuestran un pago real, una emisión de licencia ni una activación. La configuración de servicios externos se aplazó explícitamente para esta iteración de desarrollo.

Comprobaciones automatizadas locales

Ejecute desde la raíz del repositorio:

go test ./...
go vet ./...
node --check internal/httpapi/web/app.js
node --check internal/httpapi/web/integration.js
node --check internal/httpapi/web/integration-prompts.js
node --test scripts/integration-prompts.test.mjs scripts/integration-state.test.mjs
python scripts/test_acceptance.py
./scripts/test-mysql.ps1

La herramienta auxiliar MySQL crea un servidor aislado nuevo y bases de datos bajo .cache; no debe apuntarse a una base de datos de clientes. Un go test ./... normal omite los escenarios de base de datos salvo que se proporcionen los DSN aislados. Las pruebas y compilaciones del SDK/paquetes se describen en integration-packages.md. Conserve la salida de pruebas y las versiones de herramientas con el registro de publicación.

La matriz local incluye autenticación, verificación condicional del correo, titularidad de producto/entorno, estados pendientes/vencidos/suspendidos, repetición de eventos de pago, conciliación de licencias, renovaciones/reembolsos, cambio de cuenta, persistencia protegida de sesiones y decisiones sobre el uso alternativo sin conexión. Las pruebas del ciclo de vida usan entornos de ejecución controlados; la verificación criptográfica real de ejecución sigue siendo responsabilidad del SDK oficial y se prueba por separado antes de publicar.

Para Herramientas operativas → Integración rápida con IA, compruebe las nueve opciones de lenguaje, la selección de plataforma/proyecto/función, un borrador sin configurar y una instrucción generada a partir de una configuración pública validada. Compare la copia y la descarga con la instrucción visible y asegúrese de que cambiar el producto o entorno no conserva una configuración validada anteriormente. Las instrucciones deben excluir sesiones, contraseñas, credenciales de ejecución de licencias/dispositivos y claves administrativas; generar o copiar una instrucción no debe llamar a servicios de IA. El comando de prueba de Node del paquete de código fuente anterior comprueba el generador puro. Una instrucción generada o el código producido después por una herramienta de IA siguen requiriendo las pruebas del lenguaje y los pasos de aceptación externa siguientes.

Preparar la aceptación en sandbox externa

Despliegue una instancia de prueba dedicada de Launch con un origen HTTPS accesible y webhooks del proveedor. Mantenga deshabilitadas las ventas live.
Configure las credenciales sandbox de un solo proveedor de pago y una conexión de lectura/escritura de Licentivo. Los registros de la sandbox de pago están aislados, pero siguen usando el servicio Licentivo configurado y pueden crear licencias de prueba/registros de dispositivo reales. Use un producto/una política de prueba dedicados y clientes de prueba.
Publique un plan sandbox y use Integración del programa para exportar launch-config.json y product.json validado a .local/acceptance/.
Instale localmente solo el paquete Python revisado de Launch: python -m pip install ./sdk/python, o instale su wheel. Incluye la implementación privada del SDK.
Use una función de prueba no medida por consumo, como export. --activate inicia el SDK oficial, llama síncronamente a refresh_online(), requiere un estado activo en línea e invoca su API de operaciones protegidas. Una autorización sin conexión en caché por sí sola no supera esta comprobación; esta comprobación no prueba la medición.

Las credenciales se solicitan sin mostrarlas. La automatización puede proporcionar LAUNCH_ACCEPTANCE_EMAIL y LAUNCH_ACCEPTANCE_PASSWORD en el entorno privado del proceso. No incluya contraseñas en argumentos de comandos, informes, capturas ni archivos incluidos en commits. La herramienta revoca su sesión temporal de escritorio después de cada comprobación autenticada, pero no desactiva dispositivos al salir normalmente.

python scripts/acceptance.py preflight --config .local/acceptance/launch-config.json --report .local/acceptance/01-preflight.json
python scripts/acceptance.py verify --config .local/acceptance/launch-config.json --expect not_purchased --report .local/acceptance/02-no-purchase.json

La herramienta rechaza configuraciones live, HTTP fuera del bucle local, redirecciones con credenciales, productos no coincidentes y configuración pública que contenga secretos de ejecución. Antes de realizar solicitudes, rechaza las aserciones de activación/pedido fuera de verify y las opciones de creación de pago fuera de checkout. Nunca sobrescribe informes existentes. Los informes contienen pruebas permitidas por una lista explícita, no respuestas brutas, tokens de acceso ni claves de licencia. La falta de servidor o SDK genera una comprobación fallida, no un éxito simulado.

Las comprobaciones locales del comerciante usan scope: local_sandbox_probe y licensing_scope: not_called. verify --activate contacta con el servicio oficial externo de licencias aunque el comerciante se ejecute en localhost; esa combinación se registra como local_merchant_external_licensing_probe con licensing_scope: official_external_service.

Primer pago y activación

Cree un proceso de pago de prueba en el sitio del comerciante o créelo con un UUID de operación estable:

$operation = [guid]::NewGuid().ToString()
python scripts/acceptance.py checkout --config .local/acceptance/launch-config.json --provider stripe --plan-version-id PLAN_VERSION_UUID --operation-id $operation --report .local/acceptance/03-checkout.json

Sustituya el proveedor y la versión del plan por su plan sandbox publicado. Conserve y reutilice el mismo UUID de operación al reintentar una creación de pago incierta. La herramienta muestra el ID del pedido. Complete ese pedido propio desde el centro de cuentas del comerciante usando el proceso de pago sandbox oficial del proveedor. La comprobación no simula deliberadamente las interacciones con la interfaz del proveedor.

Después de que el proveedor confirme el pago y se reciba el webhook:

python scripts/acceptance.py verify --config .local/acceptance/launch-config.json --order-id ORDER_UUID --expect-order paid --expect active --activate --product-config .local/acceptance/product.json --feature export --report .local/acceptance/04-activation.json

Comprueba la cuenta autenticada, el pedido sandbox propio, el derecho, la correspondencia de credenciales/producto y una operación protegida real del SDK oficial. Una autorización pendiente se reintenta como máximo cinco veces dentro de una ventana limitada (30 segundos por defecto, máximo 120), respetando Retry-After. Los fallos inesperados de autorización se registran sin exponer el texto bruto de error del SDK.

Matriz de aceptación del ciclo de vida

Para cada combinación publicada de lenguaje/sistema operativo, guarde un registro fechado con la revisión del código fuente, las versiones de Launch/cliente/SDK, el entorno del proveedor, una etiqueta de cliente anonimizada, los ID de pedidos, el resultado esperado, el observado y el nombre del informe pertinente. Marque las filas no ejecutadas como no ejecutadas. No marque toda la matriz como superada a partir de la comprobación del primer pago.

Escenario	Procedimiento	Pruebas requeridas
Registro / verificación	Registrarse sin comprar; repetir con la verificación habilitada y deshabilitada	La verificación deshabilitada no bloquea; la habilitada produce `EMAIL_VERIFICATION_REQUIRED` hasta completarse
Sin compra	Ejecutar `verify --expect not_purchased`	Credencial rechazada; no se ejecuta ninguna operación protegida
Primera compra	Completar el pago sandbox y ejecutar después la comprobación de activación	El proveedor confirma el pago; un derecho pagado, una licencia sincronizada y operación SDK correcta
Reinicio	Cerrar el ejemplo del lenguaje elegido con inicio de sesión recordado, iniciar un proceso nuevo y recuperar	Sin solicitud de contraseña; misma caché de cuenta/producto y autorización firmada válida
Arranque sin conexión	Tras una activación correcta con inicio recordado, deshabilitar la red para ese proceso/equipo de prueba y reiniciar	La autorización firmada en caché solo permite operaciones admitidas por la política; una política sin uso offline/flotante rechaza el arranque
Vencimiento sin conexión / retroceso del reloj	Usar una política de prueba de corta duración y un equipo de prueba desechable	El SDK rechaza estados vencidos/con reloj atrasado; no se ejecuta el callback de función
Renovación / cambio a plan superior	Comprar una renovación o un cambio cotizado a plan superior en la tienda sandbox	Pedido/cobertura correctos; nueva validez y funciones visibles después de sincronizar y actualizar el SDK
Reembolso	Solicitar/aprobar un reembolso sandbox completo; esperar la confirmación del proveedor	El reembolso del proveedor y la cobertura local coinciden; `verify --expect suspended` o `--expect expired` según corresponda; la otra cobertura pagada sigue siendo utilizable
Cierre de sesión / cambio de cuenta	Cerrar sesión de A, iniciar como B sin compra; reiniciar e inspeccionar el comportamiento	Sesión/caché guardadas de A eliminadas; B no puede usar la licencia, los dispositivos ni las funciones de A
Aislamiento de producto / entorno	Usar otro producto y cambiar las configuraciones sandbox/live por separado	Las credenciales y cachés no pueden cruzar alcances de identidad; la propia comprobación externa rechaza live
Límite de dispositivos / liberación	Activar en el máximo de dispositivos de prueba distintos permitido por la política; intentar uno adicional y liberar después uno explícitamente	El SDK rechaza el dispositivo excedente y permite sustituirlo tras la liberación confirmada; el cierre normal no consume cuota de liberación
Recuperación	Reiniciar Launch mientras está pendiente la emisión y repetir un webhook sandbox firmado	Una única cobertura/licencia por pedido, conciliación final; sin proceso de pago ni cargo duplicados

Los efectos de reembolsos/suspensiones sobre una autorización sin conexión ya emitida siguen limitados por la política sin conexión firmada del SDK oficial. No se afirma que haya revocación inmediata sin red. Una interrupción prolongada de Launch al vencer el contrato puede retrasar la suspensión en el servicio original; consulte las limitaciones del contrato.

Finalización y pruebas conservadas

Todos los informes de comprobación establecen deliberadamente acceptance_complete: false: solo registran las comprobaciones realmente ejecutadas en esa llamada. Revise la matriz y los registros del proveedor antes de aceptar una versión. Configure los servicios externos más tarde y reanude los comandos anteriores; no sustituya resultados faltantes por un indicador de éxito ni habilite ventas live solo porque pasen las pruebas locales.