openclaw-parallels-smoke

OpenClaw Parallels Smoke

Utiliza este skill para flujos de trabajo de invitados Parallels e interpretación de resultados smoke. No lo cargues para trabajo normal de repositorio.

Reglas globales

• Parallels es cobertura de confianza posterior a la publicación de forma predeterminada, no un requisito previo para la fase acotada de publicación beta. Ejecútalo contra una versión de paquete publicada exacta y registra el SHA de Validación + el SHA de Herramientas que autorizaron ese paquete. El SHA de Validación se asigna a su SHA de Código o SHA de Versión; no es una tercera identidad de versión.
• Una línea (lane) de Parallels posterior a la publicación fallida no despublica retroactivamente una versión beta. Clasifícala como fallo de producto, de arnés/herramientas/procedencia, de infraestructura/credencial o de envoltorio. Solo un defecto de producto confirmado ingresa en la siguiente beta.
• Utiliza un coordinador y una línea por familia de invitados independiente. Diagnostica y reintenta una familia fallida una vez, luego reevalúa; no reinicies la matriz agregada automáticamente.
• Inspecciona las máquinas virtuales e instantáneas existentes antes de aprovisionar cualquier cosa. Cuando una instantánea prístina preconfigurada coincida con la línea base solicitada, cámbiate a ella y reutiliza su usuario, herramientas y configuración base. No crees una nueva máquina virtual, reinstales macOS ni reconstruyas la línea base del invitado para una ejecución "nueva".
• "Nueva" significa restaurar la instantánea prístina existente más cercana, no crear otra instantánea. No crees instantáneas ad-hoc a menos que el usuario lo solicite explícitamente o no exista una línea base adecuada; restaura la instantánea original y deja el invitado detenido después de una ejecución ad-hoc.
• Inspecciona el estado de la instantánea antes de restaurarla. Una instantánea prístina poweron puede contener la sesión preconfigurada iniciada; cámbiate a ella normalmente para que Parallels reanude esa sesión. No pases --skip-resume en el punto de entrada de prueba a menos que la ejecución necesite intencionalmente descartar la sesión guardada e iniciar desde la ventana de inicio de sesión. --skip-resume es aceptable para la limpieza final que debe dejar el invitado fuente restaurado detenido.
• La verificación de gateway en ejecuciones smoke debe usar openclaw gateway status --deep --require-rpc a menos que la versión estable que se está verificando aún no lo admita.
• Los diagnósticos previos a la actualización de la versión estable 2026.3.12 pueden requerir una alternativa simple gateway status --deep.
• Trata precheck=latest-ref-fail en esa línea estable previa a la actualización como línea base, no automáticamente como una regresión.
• Pasa --json para resúmenes legibles por máquina.
• Los registros por fase se almacenan en .artifacts/parallels/openclaw-parallels-* de forma predeterminada. Sobrescribe con OPENCLAW_PARALLELS_ARTIFACT_ROOT cuando una ejecución necesite otro volumen de artefactos.
• No ejecutes turnos de agente local y de gateway en paralelo en el mismo espacio de trabajo o sesión nueva.
• Lleva cada línea superior de Parallels con un límite estricto mediante timeout --foreground (o gtimeout --foreground si ese es el binario disponible) para que una instalación atascada, un cambio de instantánea o un transporte prlctl exec no consuman el resto de la ventana de prueba. Valores predeterminados:
  • macOS: 75m
  • Linux: 75m
  • Windows: 90m
  • envoltorio agregado npm-update: 150m Si una línea alcanza el límite, detente allí, inspecciona el directorio de ejecución /tmp/openclaw-parallels-* más reciente y el registro de la fase, luego corrige o vuelve a ejecutar la línea afectada más pequeña. No sigas esperando una línea que ha alcanzado el límite.
• Las fases reales de instalación/actualización npm de OpenClaw son una señal más estricta que los límites de línea completa: las fases de instalación normalmente deben finalizar en 7 minutos, y las fases de actualización normalmente deben mostrar progreso significativo en 5 minutos. Si una fase llamada install-main, install-latest, install-baseline o install-baseline-package supera los 420 segundos, o una fase llamada update-dev / openclaw update del mismo invitado supera los 300 segundos sin nuevos marcadores, comienza el diagnóstico desde el registro de esa fase y el estado del proceso invitado. Las fases de actualización actuales de Windows aún pueden pasar después de aproximadamente 10-15 minutos porque doctor --fix puede instalar dependencias de tiempo de ejecución de complementos empaquetados; mantén el límite estricto del script cerca de 20 minutos a menos que el registro esté verdaderamente obsoleto.
• Para una matriz completa de sistemas operativos, prefiere ejecutar líneas de familias de invitados independientes en paralelo cuando la capacidad del host lo permita:
  • timeout --foreground 75m pnpm test:parallels:macos -- --json
  • timeout --foreground 90m pnpm test:parallels:windows -- --json
  • timeout --foreground 75m pnpm test:parallels:linux -- --json Mantén cada línea en su propio shell/sesión y rastrea el directorio de ejecución para cada una. Antes de iniciar la matriz, ejecuta cualquier compilación/empaquetado de host requerido hasta su finalización. Cuando sea necesario empaquetar tgz de la rama principal actual, los scripts smoke mantienen un bloqueo de paquete compartido a través de pnpm build, inventario/staging y npm pack; si ese bloqueo falta o está roto, serializa la matriz en lugar de aceptar una mutación dist concurrente.
• No ejecutes múltiples líneas smoke contra la misma familia de invitados a la vez. Las líneas de Tahoe comparten el puerto HTTP del host, y las líneas de Windows/Linux pueden colisionar en el estado de restauración/inicio de instantáneas si dos trabajos tocan la misma máquina virtual simultáneamente.
• No ejecutes el envoltorio agregado pnpm test:parallels:npm-update en paralelo con líneas smoke individuales de macOS/Windows/Linux; toca las mismas familias de invitados e instantáneas.
• No inicies líneas de Parallels mientras cualquier comando de host no relacionado pueda reconstruir, limpiar o reetapificar dist (pnpm build, pnpm ui:build, pnpm release:check, pnpm test:install:smoke, npm pack/install smoke o líneas Docker que ejecuten preparación de paquete/compilación). Ejecuta primero las puertas de compilación/empaquetado no relacionadas, déjalas terminar, luego inicia la matriz de máquinas virtuales. La mutación concurrente de dist puede hacer que npm pack del host falle con archivos faltantes y desperdicie un ciclo completo de máquina virtual.
• Mientras ejecutas u optimizas la matriz, registra la duración del tiempo de pared por línea y la fase más lenta de los registros /tmp/openclaw-parallels-*. Usa esa sincronización antes de cambiar el orden smoke, los tiempos de espera o el comportamiento del ayudante.
• Si una compilación del host cambia archivos generados rastreados, como src/canvas-host/a2ui/.bundle.hash, detente antes de gastar tiempo de máquina virtual. Confirma el artefacto generado por separado o corrige la desviación del generador, luego vuelve a ejecutar la línea afectada más pequeña.
• Si main se está moviendo bajo trabajo multiagente activo, prefiere un árbol de trabajo separado anclado a un solo commit para suites Parallels largas. Los scripts smoke ahora verifican el commit tgz empaquetado en lugar de git rev-parse HEAD en vivo, pero un árbol de trabajo separado aún evita una reconstrucción/desviación de versión ruidosa durante las re-ejecuciones.
• Para líneas openclaw update --channel dev, recuerda que el invitado clona el main de GitHub, no tu árbol de trabajo local. Si existe una corrección local pero la re-ejecución aún falla dentro del checkout dev clonado, no trates eso como una refutación de la corrección hasta que la rama haya sido enviada.
• Para prlctl exec, pasa el nombre de la máquina virtual antes de --current-user (prlctl exec "$VM" --current-user ...), no al revés.
• Si el flujo de trabajo instala OpenClaw desde un checkout del repositorio en lugar del instalador del sitio/versión npm, finaliza instalando un shim CLI de invitado real y verifícalo en un shell de invitado nuevo. pnpm openclaw ... dentro del repositorio no es suficiente para la paridad de transferencia.
• En invitados macOS, prefiere una instalación global de usuario más un shim estable visible en el PATH:
  • instala con NPM_CONFIG_PREFIX="$HOME/.npm-global" npm install -g .
  • asegúrate de que ~/.local/bin/openclaw exista o ~/.npm-global/bin esté en el PATH
  • verifica desde un shell de invitado completamente nuevo con which openclaw y openclaw --version

Instalación npm y luego actualización

• Punto de entrada preferido: pnpm test:parallels:npm-update
• Para una verificación de actualización de versión publicada solo para macOS, usa:
  • timeout --foreground 75m pnpm test:parallels:npm-update -- --platform macos --package-spec openclaw@<old-version> --update-target <target-version-or-tag> --json Esto mantiene la cobertura openclaw update --tag ... del mismo invitado y usa la alternativa compartida de usuario actual/sudo de macOS sin iniciar líneas de Windows/Linux.
• Cobertura requerida: cada ejecución de regresión de versión/actualización debe incluir ambas líneas:
  • instantánea nueva -> instalar paquete/línea base solicitado -> smoke
  • misma línea base del invitado -> ejecutar el comando openclaw update ... instalado del invitado -> smoke nuevamente
• La línea de actualización debe ejercitar el actualizador interno de OpenClaw. No cuentes una instalación directa npm install -g <tgz-or-spec> o un intercambio de paquete del lado del arnés como cobertura de flujo de actualización; esos son solo smokes de instalación.
• Para objetivos publicados, instala primero el paquete de línea base antiguo (por ejemplo [email protected]), luego ejecuta el CLI de invitado instalado con el canal/etiqueta previsto (por ejemplo openclaw update --channel beta --yes --json) y verifica openclaw --version, openclaw update status --json, gateway RPC y un turno de agente después del comando.
• Para objetivos no publicados, empaqueta el candidato en el host, sirve el .tgz a través del servidor HTTP del arnés y apunta el actualizador del invitado a ese paquete servido. Prefiere openclaw update --tag http://<host-ip>:<port>/openclaw-<version>.tgz --yes --json; cuando la persistencia del canal también importe, pasa --channel <stable|beta> y establece OPENCLAW_UPDATE_PACKAGE_SPEC en la misma URL servida en el entorno de actualización del invitado. El comando bajo prueba aún debe ser openclaw update, no npm directo.
• Para la validación de corrección local no publicada, recuerda que el código del actualizador de línea base antiguo aún controla el primer salto. Una corrección que solo vive en el nuevo código del actualizador no puede cambiar ese proceso antiguo ya en ejecución; el candidato servido debe mantener metadatos de paquete/complemento compatibles con el host de línea base o la línea base misma debe incluir la corrección del actualizador.
• Para la verificación beta/estable, resuelve la etiqueta inmediatamente antes de la ejecución (npm view openclaw@beta version dist.tarball o npm view openclaw@latest ...). Las etiquetas pueden moverse mientras una matriz de máquinas virtuales larga ya se está ejecutando; reinicia la matriz cuando la versión preliminar prevista aparezca después de una verificación anterior de 404/retraso de etiqueta del registro.
• Usa el flujo de trabajo de secreto configurado para inyectar solo las claves de proveedor necesarias para las líneas de OpenAI/Anthropic. No imprimas secretos o volcados de entorno; pasa los secretos del proveedor a través del entorno de ejecución del invitado.
• La verificación de actualización del mismo invitado debe establecer el modelo predeterminado explícitamente a openai/gpt-5.4 antes del turno del agente y usar un --session-id explícito nuevo para que el estado del modelo de sesión anterior no se filtre en la verificación.
• El envoltorio agregado npm-update debe resolver la máquina virtual Linux con la misma política de respaldo de Ubuntu que parallels-linux-smoke.sh antes de las líneas nueva y de actualización. Trata cualquier invitado Ubuntu con versión principal >= 24 como aceptable cuando falte la máquina virtual predeterminada exacta, prefiriendo el invitado Ubuntu versionado más reciente con una instantánea de apagado nueva. En el host actual de Peter hoy, usa Ubuntu 26.04.
• En las verificaciones de actualización del mismo invitado macOS, reinicia el gateway después de la actualización npm antes de gateway status / agent; de lo contrario, launchd puede informar un servicio cargado mientras el proceso antiguo ha salido y el proceso nuevo aún no está listo para RPC.
• La etapa de actualización macOS del envoltorio npm-update escribe el script de actualización del invitado como root, luego lo ejecuta como el usuario de escritorio. Si prlctl exec "$MACOS_VM" --current-user ... no puede autenticarse, reintenta a través de prlctl exec root simple más sudo -u <desktop-user> /usr/bin/env HOME=/Users/<desktop-user> USER=<desktop-user> LOGNAME=<desktop-user> PATH=/opt/homebrew/bin:/opt/homebrew/opt/node/bin:/usr/bin:/bin:/usr/sbin:/sbin .... Eso es una alternativa de transporte de Parallels; aún verifica openclaw --version, gateway RPC y un turno de agente después de la actualización.
• En las verificaciones de actualización del mismo invitado Windows, reinicia el gateway después de la actualización npm antes de gateway status / agent; de lo contrario, las actualizaciones npm globales in situ pueden dejar importaciones de módulos dist/* con hash obsoleto vivas en el servicio en ejecución.
• En esas verificaciones de actualización del mismo invitado Windows, no trates un openclaw gateway restart distinto de cero como fallo definitivo. Los reinicios de elementos de inicio de sesión actuales pueden informar un fallo antes de que el servicio en segundo plano se vuelva observable nuevamente; continúa con una espera más larga de preparación para RPC y usa gateway start solo como un paso de recuperación si la preparación nunca regresa.
• Después de ese reinicio de Windows, no confíes en una sola llamada gateway status --deep --require-rpc después de un sueño fijo. Reintenta la sonda de preparación para RPC durante aproximadamente 30 segundos y registra cada intento; los invitados actuales pueden mantener el puerto 18789 vinculado mientras el nuevo endpoint RPC aún está arrancando.
• Para las verificaciones de actualización del mismo invitado Windows, prefiere el patrón de ejecutor PowerShell de archivo hecho/registro drenado sobre un transporte prlctl exec ... powershell -EncodedCommand ... de larga duración. El invitado puede finalizar con éxito mientras el prlctl exec externo aún se cuelga.
• El ayudante de actualización del mismo invitado Windows debe escribir marcadores de etapa en su registro antes de pasos largos como la descarga tgz y npm install -g para que el monitor de progreso externo no se quede en esperando la primera línea de registro durante instalaciones saludables pero silenciosas.
• La verificación de actualización del mismo invitado Linux también debe exportar HOME=/root, pasar OPENAI_API_KEY a través de prlctl exec ... /usr/bin/env y usar openclaw agent --local; la línea base Linux nueva no depende de credenciales de gateway persistentes.
• El envoltorio npm-update ahora imprime el progreso por línea desde los archivos de registro anidados. Si una línea aún parece atascada, inspecciona primero los registros anidados en runDir (macos-fresh.log, windows-fresh.log, linux-fresh.log, macos-update.log, windows-update.log, linux-update.log) en lugar de asumir que el envoltorio externo se colgó.
• Cada ejecución escribe tanto summary.json como summary.md; lee el markdown primero para una clasificación humana rápida, luego el JSON/sincronizaciones para automatización.
• Para la validación beta completa después de que se publique una etiqueta, prefiere un comando:
  • timeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta3 --json Esto resuelve beta3 a la última versión *-beta.3, ejecuta la cobertura de actualización del mismo invitado desde la última versión hasta esa versión, y luego ejecuta smoke de instalación nueva para ese objetivo publicado exacto en la misma matriz de SO seleccionada. Usa --platform macos|windows|linux para reducir las re-ejecuciones.
• Para la validación npm beta 4 con turnos de agente, la forma conocida buena es:
  • gtimeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta4 --model openai/gpt-5.4 --json Prefiere el alias explícito beta4 sobre openclaw@beta al validar un número de versión preliminar específico; las etiquetas npm pueden moverse.
• Si el envoltorio falla en una línea, lee el archivo de registro anidado correspondiente, corrige el problema y vuelve a ejecutar solo esa línea, no la matriz completa.
• Después de un fallo de línea, no reinicies la matriz completa automáticamente; corrige la línea fallida más pequeña y vuelve a ejecutarla primero.
• Cuando se complete la validación, confirma los archivos de registro en el artefacto de compilación para su posterior análisis.