chore(i18n): refresh es translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
d286ca2eee
commit
25738bae7b
422
docs/es/ci.md
422
docs/es/ci.md
@ -1,94 +1,94 @@
|
||||
---
|
||||
read_when:
|
||||
- Necesita comprender por qué un trabajo de CI se ejecutó o no se ejecutó
|
||||
- Necesitas entender por qué un trabajo de CI se ejecutó o no.
|
||||
- Estás depurando una comprobación fallida de GitHub Actions
|
||||
- Estás coordinando una ejecución o repetición de la validación de lanzamiento
|
||||
- Estás cambiando el despacho de ClawSweeper o el reenvío de actividad de GitHub
|
||||
summary: Grafo de trabajos de CI, controles de alcance, paraguas de lanzamiento y equivalentes de comandos locales
|
||||
- Estás coordinando una ejecución o reejecución de validación de lanzamiento
|
||||
- Estás cambiando el dispatch de ClawSweeper o el reenvío de actividad de GitHub
|
||||
summary: Grafo de trabajos de CI, controles de alcance, agrupadores de lanzamiento y equivalentes de comandos locales
|
||||
title: Canalización de CI
|
||||
x-i18n:
|
||||
generated_at: "2026-05-02T22:17:38Z"
|
||||
generated_at: "2026-05-02T23:39:31Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: a8033b928b26adfa340200ea69fd63d339a6e65c21659b8119a68b23b8b16016
|
||||
source_hash: 321fe0a061044f75b8e1d03b4d3e76d4f8dd2dae0ebc58831887fc20af953cf1
|
||||
source_path: ci.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
OpenClaw CI se ejecuta en cada push a `main` y en cada pull request. El trabajo `preflight` clasifica el diff y desactiva las rutas costosas cuando solo cambiaron áreas no relacionadas. Las ejecuciones manuales de `workflow_dispatch` omiten intencionalmente el alcance inteligente y despliegan todo el grafo para candidatos de lanzamiento y validación amplia. Las rutas de Android siguen siendo opt-in mediante `include_android`. La cobertura de plugins solo de lanzamiento vive en el flujo de trabajo separado [`Prelanzamiento de Plugin`](#plugin-prerelease) y solo se ejecuta desde [`Validación completa de lanzamiento`](#full-release-validation) o desde un despacho manual explícito.
|
||||
OpenClaw CI se ejecuta en cada push a `main` y en cada pull request. El trabajo `preflight` clasifica el diff y desactiva las lanes costosas cuando solo cambiaron áreas no relacionadas. Las ejecuciones manuales de `workflow_dispatch` omiten intencionalmente el alcance inteligente y despliegan todo el grafo para candidatos de lanzamiento y validación amplia. Las lanes de Android siguen siendo opt-in mediante `include_android`. La cobertura de Plugin solo de lanzamiento vive en el workflow separado [`Prelanzamiento de Plugin`](#plugin-prerelease) y solo se ejecuta desde [`Validación completa de lanzamiento`](#full-release-validation) o una ejecución manual explícita.
|
||||
|
||||
## Descripción general del pipeline
|
||||
## Resumen del pipeline
|
||||
|
||||
| Trabajo | Propósito | Cuándo se ejecuta |
|
||||
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------- |
|
||||
| `preflight` | Detectar cambios solo de documentación, alcances modificados, extensiones modificadas y compilar el manifiesto de CI | Siempre en pushes y PRs no draft |
|
||||
| `security-scm-fast` | Detección de claves privadas y auditoría de flujos de trabajo mediante `zizmor` | Siempre en pushes y PRs no draft |
|
||||
| `security-dependency-audit` | Auditoría del lockfile de producción sin dependencias contra avisos de npm | Siempre en pushes y PRs no draft |
|
||||
| `security-fast` | Agregado requerido para los trabajos rápidos de seguridad | Siempre en pushes y PRs no draft |
|
||||
| `check-dependencies` | Pasada de Knip solo para dependencias de producción más la protección de la lista de permitidos de archivos sin usar | Cambios relevantes para Node |
|
||||
| `build-artifacts` | Compilar `dist/`, Control UI, comprobaciones de artefactos compilados y artefactos reutilizables posteriores | Cambios relevantes para Node |
|
||||
| `checks-fast-core` | Rutas rápidas de corrección en Linux, como comprobaciones de plugins incluidos, contrato de plugins y protocolo | Cambios relevantes para Node |
|
||||
| `checks-fast-contracts-channels` | Comprobaciones fragmentadas de contratos de canales con un resultado agregado estable | Cambios relevantes para Node |
|
||||
| `checks-node-core-test` | Fragmentos de pruebas de Node del núcleo, excluyendo rutas de canales, incluidos, contratos y extensiones | Cambios relevantes para Node |
|
||||
| `check` | Equivalente fragmentado de la puerta local principal: tipos de producción, lint, protecciones, tipos de prueba y smoke estricto | Cambios relevantes para Node |
|
||||
| `check-additional` | Arquitectura, límites, deriva de snapshots de prompts, protecciones de superficie de extensiones, límites de paquete y fragmentos de gateway-watch | Cambios relevantes para Node |
|
||||
| `build-smoke` | Pruebas smoke de CLI compilada y smoke de memoria de arranque | Cambios relevantes para Node |
|
||||
| `checks` | Verificador para pruebas de canales con artefactos compilados | Cambios relevantes para Node |
|
||||
| `checks-node-compat-node22` | Ruta de compilación y smoke de compatibilidad con Node 22 | Despacho manual de CI para lanzamientos |
|
||||
| `check-docs` | Formato, lint y comprobaciones de enlaces rotos de la documentación | Documentación modificada |
|
||||
| `skills-python` | Ruff + pytest para Skills respaldadas por Python | Cambios relevantes para Skills de Python |
|
||||
| `checks-windows` | Pruebas específicas de Windows de procesos/rutas más regresiones compartidas de especificadores de importación en runtime | Cambios relevantes para Windows |
|
||||
| `macos-node` | Ruta de pruebas TypeScript en macOS usando los artefactos compilados compartidos | Cambios relevantes para macOS |
|
||||
| `macos-swift` | Lint, compilación y pruebas de Swift para la app de macOS | Cambios relevantes para macOS |
|
||||
| `android` | Pruebas unitarias de Android para ambos sabores más una compilación de APK debug | Cambios relevantes para Android |
|
||||
| `test-performance-agent` | Optimización diaria de pruebas lentas de Codex tras actividad confiable | Éxito de CI principal o despacho manual |
|
||||
| `openclaw-performance` | Informes diarios/bajo demanda de rendimiento del runtime de Kova con rutas de proveedor mock, perfil profundo y GPT 5.4 en vivo | Programado y despacho manual |
|
||||
| Trabajo | Propósito | Cuándo se ejecuta |
|
||||
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- |
|
||||
| `preflight` | Detectar cambios solo de documentación, scopes cambiados, extensiones cambiadas y compilar el manifiesto de CI | Siempre en pushes y PRs que no sean borrador |
|
||||
| `security-scm-fast` | Detección de claves privadas y auditoría de workflow mediante `zizmor` | Siempre en pushes y PRs que no sean borrador |
|
||||
| `security-dependency-audit` | Auditoría del lockfile de producción sin dependencias frente a advisories de npm | Siempre en pushes y PRs que no sean borrador |
|
||||
| `security-fast` | Agregado requerido para los trabajos rápidos de seguridad | Siempre en pushes y PRs que no sean borrador |
|
||||
| `check-dependencies` | Pasada de Knip solo de dependencias de producción más el guard de allowlist de archivos no usados | Cambios relevantes para Node |
|
||||
| `build-artifacts` | Compilar `dist/`, Control UI, comprobaciones de artefactos compilados y artefactos downstream reutilizables | Cambios relevantes para Node |
|
||||
| `checks-fast-core` | Lanes rápidas de corrección en Linux, como comprobaciones bundled/plugin-contract/protocol | Cambios relevantes para Node |
|
||||
| `checks-fast-contracts-channels` | Comprobaciones de contratos de canal con shards y un resultado de comprobación agregado estable | Cambios relevantes para Node |
|
||||
| `checks-node-core-test` | Shards de pruebas core de Node, excluidas las lanes de canal, bundled, contract y extensión | Cambios relevantes para Node |
|
||||
| `check` | Equivalente con shards de la gate local principal: tipos prod, lint, guards, tipos de prueba y smoke estricto | Cambios relevantes para Node |
|
||||
| `check-additional` | Arquitectura, límites, drift de snapshots de prompts, guards de superficie de extensión, límite de paquete y shards de gateway-watch | Cambios relevantes para Node |
|
||||
| `build-smoke` | Pruebas smoke de CLI compilada y smoke de memoria de arranque | Cambios relevantes para Node |
|
||||
| `checks` | Verificador para pruebas de canal de artefactos compilados | Cambios relevantes para Node |
|
||||
| `checks-node-compat-node22` | Lane de compilación y smoke de compatibilidad con Node 22 | Dispatch manual de CI para lanzamientos |
|
||||
| `check-docs` | Formato, lint y comprobaciones de enlaces rotos de documentación | Documentación cambiada |
|
||||
| `skills-python` | Ruff + pytest para skills respaldadas por Python | Cambios relevantes para skills de Python |
|
||||
| `checks-windows` | Pruebas específicas de Windows de procesos/rutas más regresiones compartidas de especificadores de importación runtime | Cambios relevantes para Windows |
|
||||
| `macos-node` | Lane de pruebas TypeScript de macOS usando los artefactos compilados compartidos | Cambios relevantes para macOS |
|
||||
| `macos-swift` | Swift lint, compilación y pruebas para la app de macOS | Cambios relevantes para macOS |
|
||||
| `android` | Pruebas unitarias de Android para ambos flavors más una compilación de APK debug | Cambios relevantes para Android |
|
||||
| `test-performance-agent` | Optimización diaria de pruebas lentas de Codex tras actividad confiable | Éxito de CI principal o dispatch manual |
|
||||
| `openclaw-performance` | Informes diarios/bajo demanda de rendimiento runtime de Kova con mock-provider, deep-profile y lanes live de GPT 5.4 | Dispatch programado y manual |
|
||||
|
||||
## Orden fail-fast
|
||||
|
||||
1. `preflight` decide qué rutas existen. La lógica de `docs-scope` y `changed-scope` son pasos dentro de este trabajo, no trabajos independientes.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` y `skills-python` fallan rápidamente sin esperar a los trabajos más pesados de artefactos y matrices de plataforma.
|
||||
3. `build-artifacts` se solapa con las rutas rápidas de Linux para que los consumidores posteriores puedan empezar tan pronto como la compilación compartida esté lista.
|
||||
4. Las rutas más pesadas de plataforma y runtime se despliegan después: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` y `android`.
|
||||
1. `preflight` decide qué lanes existen. La lógica `docs-scope` y `changed-scope` son pasos dentro de este trabajo, no trabajos independientes.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` y `skills-python` fallan rápido sin esperar a los trabajos más pesados de artefactos y matriz de plataformas.
|
||||
3. `build-artifacts` se solapa con las lanes rápidas de Linux para que los consumidores downstream puedan empezar en cuanto la compilación compartida esté lista.
|
||||
4. Las lanes más pesadas de plataforma y runtime se despliegan después: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` y `android`.
|
||||
|
||||
GitHub puede marcar trabajos reemplazados como `cancelled` cuando llega un push más reciente al mismo PR o ref de `main`. Trata eso como ruido de CI salvo que la ejecución más nueva para el mismo ref también esté fallando. Las comprobaciones agregadas de fragmentos usan `!cancelled() && always()` para que sigan informando fallos normales de fragmentos, pero no se encolen después de que todo el flujo de trabajo ya haya sido reemplazado. La clave de concurrencia automática de CI está versionada (`CI-v7-*`) para que un zombi del lado de GitHub en un grupo de cola antiguo no pueda bloquear indefinidamente ejecuciones más nuevas de main. Las ejecuciones manuales de suite completa usan `CI-manual-v1-*` y no cancelan ejecuciones en curso.
|
||||
GitHub puede marcar trabajos reemplazados como `cancelled` cuando llega un push más nuevo al mismo PR o ref de `main`. Trátalo como ruido de CI salvo que la ejecución más reciente para la misma ref también esté fallando. Las comprobaciones agregadas de shards usan `!cancelled() && always()` para que sigan informando fallos normales de shards, pero no se encolen después de que todo el workflow ya haya sido reemplazado. La clave automática de concurrencia de CI está versionada (`CI-v7-*`) para que un zombie del lado de GitHub en un grupo de cola antiguo no pueda bloquear indefinidamente ejecuciones principales más nuevas. Las ejecuciones manuales de suite completa usan `CI-manual-v1-*` y no cancelan ejecuciones en curso.
|
||||
|
||||
## Alcance y enrutamiento
|
||||
## Scope y enrutamiento
|
||||
|
||||
La lógica de alcance vive en `scripts/ci-changed-scope.mjs` y está cubierta por pruebas unitarias en `src/scripts/ci-changed-scope.test.ts`. El despacho manual omite la detección de changed-scope y hace que el manifiesto de preflight actúe como si todas las áreas con alcance hubieran cambiado.
|
||||
La lógica de scope vive en `scripts/ci-changed-scope.mjs` y está cubierta por pruebas unitarias en `src/scripts/ci-changed-scope.test.ts`. El dispatch manual omite la detección de changed-scope y hace que el manifiesto de preflight actúe como si todas las áreas con scope hubieran cambiado.
|
||||
|
||||
- **Las ediciones del flujo de trabajo de CI** validan el grafo de CI de Node más el lint de flujos de trabajo, pero no fuerzan por sí solas compilaciones nativas de Windows, Android o macOS; esas rutas de plataforma siguen limitadas a cambios en código fuente de plataforma.
|
||||
- **Las ediciones solo de enrutamiento de CI, ediciones seleccionadas y baratas de fixtures de pruebas del núcleo, y ediciones estrechas de helpers de contrato de plugins/enrutamiento de pruebas** usan una ruta rápida de manifiesto solo de Node: `preflight`, seguridad y una sola tarea `checks-fast-core`. Esa ruta omite artefactos de compilación, compatibilidad con Node 22, contratos de canales, fragmentos completos del núcleo, fragmentos de plugins incluidos y matrices de protecciones adicionales cuando el cambio se limita a las superficies de enrutamiento o helpers que la tarea rápida ejercita directamente.
|
||||
- **Las comprobaciones de Node en Windows** se limitan a wrappers específicos de Windows de procesos/rutas, helpers de ejecutores npm/pnpm/UI, configuración de gestores de paquetes y las superficies de flujos de trabajo de CI que ejecutan esa ruta; los cambios no relacionados de código fuente, plugins, install-smoke y solo de pruebas permanecen en las rutas de Node en Linux.
|
||||
- **Ediciones del workflow de CI** validan el grafo de CI de Node más el linting de workflows, pero no fuerzan por sí solas compilaciones nativas de Windows, Android o macOS; esas lanes de plataforma siguen estando limitadas a cambios de fuente de plataforma.
|
||||
- **Ediciones solo de enrutamiento de CI, ediciones seleccionadas y baratas de fixtures de core-test, y ediciones estrechas de helpers/enrutamiento de pruebas de contratos de Plugin** usan una ruta rápida de manifiesto solo de Node: `preflight`, seguridad y una sola tarea `checks-fast-core`. Esa ruta omite artefactos de compilación, compatibilidad con Node 22, contratos de canal, shards core completos, shards de bundled-plugin y matrices de guards adicionales cuando el cambio se limita a las superficies de enrutamiento o helpers que la tarea rápida ejercita directamente.
|
||||
- **Comprobaciones de Node en Windows** se limitan a wrappers específicos de Windows de procesos/rutas, helpers de runners npm/pnpm/UI, configuración de gestor de paquetes y superficies del workflow de CI que ejecutan esa lane; los cambios no relacionados de fuente, Plugin, install-smoke y solo pruebas permanecen en las lanes de Node en Linux.
|
||||
|
||||
Las familias de pruebas de Node más lentas se dividen o equilibran para que cada trabajo siga siendo pequeño sin sobrerreservar runners: los contratos de canales se ejecutan como tres fragmentos ponderados, las rutas unitarias pequeñas del núcleo se emparejan, auto-reply se ejecuta como cuatro workers equilibrados (con el subárbol de reply dividido en fragmentos de agent-runner, dispatch y commands/state-routing), y las configuraciones agentic de gateway/plugins se reparten entre los trabajos agentic de Node existentes solo de código fuente en lugar de esperar a artefactos compilados. Las pruebas amplias de navegador, QA, medios y plugins varios usan sus configuraciones dedicadas de Vitest en lugar del catch-all compartido de plugins. Los fragmentos con patrones de inclusión registran entradas de tiempo usando el nombre del fragmento de CI, para que `.artifacts/vitest-shard-timings.json` pueda distinguir una configuración completa de un fragmento filtrado. `check-additional` mantiene junto el trabajo de compilación/canary de límites de paquetes y separa la arquitectura de topología de runtime de la cobertura de gateway watch; el fragmento de protección de límites ejecuta sus pequeñas protecciones independientes de forma concurrente dentro de un trabajo, incluyendo `pnpm prompt:snapshots:check` para que la deriva de prompts del happy path de Codex quede fijada al PR que la causó. Gateway watch, las pruebas de canales y el fragmento de límites de soporte del núcleo se ejecutan de forma concurrente dentro de `build-artifacts` después de que `dist/` y `dist-runtime/` ya estén compilados.
|
||||
Las familias de pruebas de Node más lentas se dividen o equilibran para que cada trabajo permanezca pequeño sin reservar runners de más: los contratos de canal se ejecutan como tres shards ponderados, las lanes pequeñas de unidades core se emparejan, auto-reply se ejecuta como cuatro workers equilibrados (con el subárbol de reply dividido en shards de agent-runner, dispatch y commands/state-routing), y las configuraciones agentic de gateway/plugin se distribuyen entre los trabajos agentic existentes de Node solo de fuente en lugar de esperar artefactos compilados. Las pruebas amplias de navegador, QA, medios y Plugin misceláneo usan sus configuraciones dedicadas de Vitest en lugar del catch-all compartido de Plugin. Los shards de include-pattern registran entradas de tiempos usando el nombre de shard de CI, de modo que `.artifacts/vitest-shard-timings.json` pueda distinguir una configuración completa de un shard filtrado. `check-additional` mantiene juntos el trabajo de compilación/canary de límites de paquete y separa la arquitectura de topología runtime de la cobertura de gateway watch; el shard de guard de límites ejecuta sus pequeños guards independientes de forma concurrente dentro de un trabajo, incluido `pnpm prompt:snapshots:check`, para que el drift de prompts del happy-path runtime de Codex quede fijado al PR que lo causó. Gateway watch, las pruebas de canal y el shard core de límite de soporte se ejecutan de forma concurrente dentro de `build-artifacts` después de que `dist/` y `dist-runtime/` ya estén compilados.
|
||||
|
||||
Android CI ejecuta tanto `testPlayDebugUnitTest` como `testThirdPartyDebugUnitTest` y luego compila el APK debug de Play. El sabor de terceros no tiene un source set ni manifiesto separado; su ruta de pruebas unitarias todavía compila el sabor con las banderas BuildConfig de SMS/call-log, evitando a la vez un trabajo duplicado de empaquetado de APK debug en cada push relevante para Android.
|
||||
Android CI ejecuta tanto `testPlayDebugUnitTest` como `testThirdPartyDebugUnitTest` y luego compila el APK debug de Play. El flavor third-party no tiene source set ni manifiesto separados; su lane de pruebas unitarias sigue compilando el flavor con las flags BuildConfig de SMS/call-log, mientras evita un trabajo duplicado de empaquetado de APK debug en cada push relevante para Android.
|
||||
|
||||
El fragmento `check-dependencies` ejecuta `pnpm deadcode:dependencies` (una pasada de Knip solo para dependencias de producción fijada a la versión más reciente de Knip, con la edad mínima de lanzamiento de pnpm deshabilitada para la instalación `dlx`) y `pnpm deadcode:unused-files`, que compara los hallazgos de archivos de producción sin usar de Knip contra `scripts/deadcode-unused-files.allowlist.mjs`. La protección de archivos sin usar falla cuando un PR agrega un nuevo archivo sin usar no revisado o deja una entrada obsoleta en la lista de permitidos, al tiempo que preserva superficies intencionales de plugins dinámicos, generadas, de compilación, de pruebas en vivo y de puente de paquetes que Knip no puede resolver estáticamente.
|
||||
El shard `check-dependencies` ejecuta `pnpm deadcode:dependencies` (una pasada de Knip solo de dependencias de producción fijada a la última versión de Knip, con la edad mínima de lanzamiento de pnpm desactivada para la instalación de `dlx`) y `pnpm deadcode:unused-files`, que compara los hallazgos de archivos no usados en producción de Knip con `scripts/deadcode-unused-files.allowlist.mjs`. El guard de archivos no usados falla cuando un PR añade un nuevo archivo no usado sin revisar o deja una entrada obsoleta en la allowlist, mientras preserva superficies intencionales de Plugin dinámico, generadas, de compilación, de pruebas live y de bridge de paquete que Knip no puede resolver estáticamente.
|
||||
|
||||
## Reenvío de actividad de ClawSweeper
|
||||
|
||||
`.github/workflows/clawsweeper-dispatch.yml` es el puente del lado destino desde la actividad del repositorio de OpenClaw hacia ClawSweeper. No hace checkout ni ejecuta código no confiable de pull requests. El flujo de trabajo crea un token de GitHub App desde `CLAWSWEEPER_APP_PRIVATE_KEY` y luego despacha payloads compactos de `repository_dispatch` a `openclaw/clawsweeper`.
|
||||
`.github/workflows/clawsweeper-dispatch.yml` es el bridge del lado de destino desde la actividad del repositorio OpenClaw hacia ClawSweeper. No hace checkout ni ejecuta código no confiable de pull requests. El workflow crea un token de GitHub App desde `CLAWSWEEPER_APP_PRIVATE_KEY` y luego despacha payloads compactos de `repository_dispatch` a `openclaw/clawsweeper`.
|
||||
|
||||
El flujo de trabajo tiene cuatro rutas:
|
||||
El workflow tiene cuatro lanes:
|
||||
|
||||
- `clawsweeper_item` para solicitudes exactas de revisión de issues y pull requests;
|
||||
- `clawsweeper_comment` para comandos explícitos de ClawSweeper en comentarios de issues;
|
||||
- `clawsweeper_commit_review` para solicitudes de revisión a nivel de commit en pushes a `main`;
|
||||
- `github_activity` para actividad general de GitHub que el agente de ClawSweeper puede inspeccionar.
|
||||
|
||||
La ruta `github_activity` reenvía solo metadatos normalizados: tipo de evento, acción, actor, repositorio, número de elemento, URL, título, estado y extractos breves de comentarios o revisiones cuando están presentes. Evita intencionalmente reenviar el cuerpo completo del webhook. El flujo de trabajo receptor en `openclaw/clawsweeper` es `.github/workflows/github-activity.yml`, que publica el evento normalizado en el hook de OpenClaw Gateway para el agente de ClawSweeper.
|
||||
La lane `github_activity` reenvía solo metadatos normalizados: tipo de evento, acción, actor, repositorio, número de ítem, URL, título, estado y extractos breves de comentarios o revisiones cuando están presentes. Evita intencionalmente reenviar todo el cuerpo del Webhook. El workflow receptor en `openclaw/clawsweeper` es `.github/workflows/github-activity.yml`, que publica el evento normalizado en el hook de OpenClaw Gateway para el agente de ClawSweeper.
|
||||
|
||||
La actividad general es observación, no entrega de forma predeterminada. El agente de ClawSweeper recibe el destino de Discord en su prompt y debe publicar en `#clawsweeper` solo cuando el evento sea sorprendente, accionable, arriesgado u operacionalmente útil. Aperturas rutinarias, ediciones, actividad repetitiva de bots, ruido duplicado de webhooks y tráfico normal de revisiones deberían dar como resultado `NO_REPLY`.
|
||||
La actividad general es observación, no entrega por defecto. El agente de ClawSweeper recibe el destino de Discord en su prompt y debe publicar en `#clawsweeper` solo cuando el evento sea sorprendente, accionable, riesgoso u operacionalmente útil. Aperturas rutinarias, ediciones, churn de bots, ruido de Webhook duplicado y tráfico normal de revisiones deberían resultar en `NO_REPLY`.
|
||||
|
||||
Trata los títulos, comentarios, cuerpos, texto de revisión, nombres de ramas y mensajes de commits de GitHub como datos no confiables en toda esta ruta. Son entrada para resumen y triage, no instrucciones para el flujo de trabajo ni para el runtime del agente.
|
||||
Trata los títulos, comentarios, cuerpos, texto de revisiones, nombres de ramas y mensajes de commit de GitHub como datos no confiables en todo este camino. Son entrada para resumen y triage, no instrucciones para el workflow ni para el runtime del agente.
|
||||
|
||||
## Despachos manuales
|
||||
## Dispatches manuales
|
||||
|
||||
Las ejecuciones manuales de CI ejecutan el mismo grafo de trabajos que la CI normal, pero fuerzan la activación de todos los carriles con alcance no Android: fragmentos de Linux Node, fragmentos de plugins incluidos, contratos de canal, compatibilidad con Node 22, `check`, `check-additional`, smoke de compilación, comprobaciones de documentación, Skills de Python, Windows, macOS e i18n de Control UI. Las ejecuciones manuales de CI independientes ejecutan solo Android con `include_android=true`; el paraguas de lanzamiento completo habilita Android pasando `include_android=true`. Las comprobaciones estáticas de prelanzamiento de plugins, el fragmento `agentic-plugins` exclusivo de lanzamiento, el barrido completo por lotes de extensiones y los carriles Docker de prelanzamiento de plugins quedan excluidos de la CI. La suite Docker de prelanzamiento solo se ejecuta cuando `Full Release Validation` lanza el flujo de trabajo separado `Plugin Prerelease` con la puerta de validación de lanzamiento habilitada.
|
||||
Las ejecuciones manuales de CI ejecutan el mismo grafo de trabajos que la CI normal, pero fuerzan todas las lanes con alcance que no son de Android: shards de Linux Node, shards de Plugin incluidos, contratos de canales, compatibilidad con Node 22, `check`, `check-additional`, smoke de compilación, comprobaciones de documentación, Skills de Python, Windows, macOS y la i18n de Control UI. Las ejecuciones manuales independientes de CI solo ejecutan Android con `include_android=true`; el paraguas de lanzamiento completo habilita Android pasando `include_android=true`. Las comprobaciones estáticas de prelanzamiento de Plugin, el shard solo de lanzamiento `agentic-plugins`, el barrido por lotes completo de extensiones y las lanes Docker de prelanzamiento de Plugin se excluyen de CI. La suite Docker de prelanzamiento solo se ejecuta cuando `Full Release Validation` despacha el workflow separado `Plugin Prerelease` con la compuerta de validación de lanzamiento habilitada.
|
||||
|
||||
Las ejecuciones manuales usan un grupo de concurrencia único, de modo que una suite completa candidata a lanzamiento no sea cancelada por otra ejecución de push o PR en la misma referencia. La entrada opcional `target_ref` permite que un invocador de confianza ejecute ese grafo contra una rama, etiqueta o SHA de confirmación completo mientras usa el archivo de flujo de trabajo de la referencia de lanzamiento seleccionada.
|
||||
Las ejecuciones manuales usan un grupo de concurrencia único para que una suite completa de candidata de lanzamiento no sea cancelada por otra ejecución de push o PR en la misma ref. La entrada opcional `target_ref` permite que un llamador de confianza ejecute ese grafo contra una rama, etiqueta o SHA completo de commit mientras usa el archivo de workflow de la ref de despacho seleccionada.
|
||||
|
||||
```bash
|
||||
gh workflow run ci.yml --ref release/YYYY.M.D
|
||||
@ -98,15 +98,15 @@ gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
|
||||
|
||||
## Ejecutores
|
||||
|
||||
| Ejecutor | Trabajos |
|
||||
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `ubuntu-24.04` | `preflight`, trabajos y agregados rápidos de seguridad (`security-scm-fast`, `security-dependency-audit`, `security-fast`), comprobaciones rápidas de protocolo/contrato/plugins incluidos, comprobaciones fragmentadas de contratos de canal, fragmentos de `check` excepto lint, fragmentos y agregados de `check-additional`, verificadores agregados de pruebas de Node, comprobaciones de documentación, Skills de Python, cordura de flujos de trabajo, etiquetador, respuesta automática; el preflight de install-smoke también usa Ubuntu hospedado en GitHub para que la matriz de Blacksmith pueda ponerse en cola antes |
|
||||
| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, fragmentos de extensiones de menor peso, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` y `check-test-types` |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, fragmentos de pruebas Linux Node, fragmentos de pruebas de plugins incluidos, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (lo bastante sensible a CPU como para que 8 vCPU costaran más de lo que ahorraban); compilaciones Docker de install-smoke (el tiempo de cola de 32 vCPU costaba más de lo que ahorraba) |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` en `openclaw/openclaw`; las bifurcaciones usan `macos-latest` como alternativa |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` en `openclaw/openclaw`; las bifurcaciones usan `macos-latest` como alternativa |
|
||||
| Ejecutor | Trabajos |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ubuntu-24.04` | `preflight`, trabajos rápidos de seguridad y agregados (`security-scm-fast`, `security-dependency-audit`, `security-fast`), comprobaciones rápidas de protocolo/contrato/incluidos, comprobaciones fragmentadas de contratos de canales, shards de `check` excepto lint, shards y agregados de `check-additional`, verificadores agregados de pruebas de Node, comprobaciones de documentación, Skills de Python, workflow-sanity, labeler, auto-response; el preflight de install-smoke también usa Ubuntu hospedado por GitHub para que la matriz de Blacksmith pueda encolarse antes |
|
||||
| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, shards de extensiones de menor peso, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` y `check-test-types` |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shards de pruebas de Linux Node, shards de pruebas de Plugin incluidos, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (lo bastante sensible a CPU como para que 8 vCPU costaran más de lo que ahorraban); compilaciones Docker de install-smoke (el tiempo de cola de 32 vCPU costaba más de lo que ahorraba) |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` en `openclaw/openclaw`; los forks recurren a `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` en `openclaw/openclaw`; los forks recurren a `macos-latest` |
|
||||
|
||||
## Equivalentes locales
|
||||
|
||||
@ -137,36 +137,36 @@ pnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.jso
|
||||
|
||||
## Rendimiento de OpenClaw
|
||||
|
||||
`OpenClaw Performance` es el flujo de trabajo de rendimiento del producto y del entorno de ejecución. Se ejecuta a diario en `main` y puede lanzarse manualmente:
|
||||
`OpenClaw Performance` es el workflow de rendimiento de producto/runtime. Se ejecuta diariamente en `main` y puede despacharse manualmente:
|
||||
|
||||
```bash
|
||||
gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3
|
||||
gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 -f deep_profile=true -f live_gpt54=true
|
||||
```
|
||||
|
||||
El flujo de trabajo instala OCM desde una versión fijada y Kova desde la entrada fijada `kova_ref`, y luego ejecuta tres carriles:
|
||||
El workflow instala OCM desde un lanzamiento fijado y Kova desde la entrada `kova_ref` fijada; luego ejecuta tres lanes:
|
||||
|
||||
- `mock-provider`: escenarios de diagnóstico de Kova contra un entorno de ejecución de compilación local con autenticación falsa determinista compatible con OpenAI.
|
||||
- `mock-deep-profile`: perfilado de CPU, heap y trazas para puntos críticos de inicio, Gateway y turnos de agente.
|
||||
- `mock-provider`: escenarios de diagnóstico de Kova contra un runtime de compilación local con autenticación falsa determinista compatible con OpenAI.
|
||||
- `mock-deep-profile`: perfiles de CPU/heap/trace para puntos críticos de inicio, Gateway y turnos de agente.
|
||||
- `live-gpt54`: un turno real de agente OpenAI `openai/gpt-5.4`, omitido cuando `OPENAI_API_KEY` no está disponible.
|
||||
|
||||
El carril mock-provider también ejecuta sondeos de código fuente nativos de OpenClaw después de la pasada de Kova: tiempos de arranque y memoria del Gateway en casos de inicio predeterminado, con gancho y con 50 plugins; bucles de saludo repetidos de OpenAI simulado `channel-chat-baseline`; y comandos de inicio de CLI contra el Gateway arrancado. El resumen Markdown de sondeos de código fuente vive en `source/index.md` dentro del paquete de informe, con el JSON sin procesar al lado.
|
||||
La lane mock-provider también ejecuta sondas de código fuente nativas de OpenClaw después del pase de Kova: tiempos de arranque y memoria del Gateway en casos de inicio predeterminado, con hook y con 50 plugins; bucles repetidos de saludo mock-OpenAI `channel-chat-baseline`; y comandos de inicio de CLI contra el Gateway arrancado. El resumen Markdown de la sonda de código fuente vive en `source/index.md` dentro del paquete de informe, con JSON sin procesar junto a él.
|
||||
|
||||
Cada carril sube artefactos de GitHub. Cuando `CLAWGRIT_REPORTS_TOKEN` está configurado, el flujo de trabajo también confirma `report.json`, `report.md`, paquetes, `index.md` y artefactos de sondeos de código fuente en `openclaw/clawgrit-reports` bajo `openclaw-performance/<ref>/<run-id>-<attempt>/<lane>/`. El puntero de la rama actual se escribe como `openclaw-performance/<ref>/latest-<lane>.json`.
|
||||
Cada lane sube artefactos de GitHub. Cuando `CLAWGRIT_REPORTS_TOKEN` está configurado, el workflow también confirma `report.json`, `report.md`, paquetes, `index.md` y artefactos de sonda de código fuente en `openclaw/clawgrit-reports` bajo `openclaw-performance/<ref>/<run-id>-<attempt>/<lane>/`. El puntero de rama actual se escribe como `openclaw-performance/<ref>/latest-<lane>.json`.
|
||||
|
||||
## Validación completa de lanzamiento
|
||||
|
||||
`Full Release Validation` es el flujo de trabajo paraguas manual para "ejecutar todo antes del lanzamiento". Acepta una rama, etiqueta o SHA de confirmación completo, lanza el flujo de trabajo manual `CI` con ese destino, lanza `Plugin Prerelease` para pruebas de plugin/paquete/estáticas/Docker exclusivas de lanzamiento y lanza `OpenClaw Release Checks` para smoke de instalación, aceptación de paquetes, suites de ruta de lanzamiento Docker, en vivo/E2E, OpenWebUI, paridad de QA Lab, Matrix y carriles de Telegram. Con `rerun_group=all` y `release_profile=full`, también ejecuta `NPM Telegram Beta E2E` contra el artefacto `release-package-under-test` de las comprobaciones de lanzamiento. Después de publicar, pasa `npm_telegram_package_spec` para volver a ejecutar el mismo carril de paquete de Telegram contra el paquete npm publicado.
|
||||
`Full Release Validation` es el workflow paraguas manual para “ejecutar todo antes del lanzamiento”. Acepta una rama, etiqueta o SHA completo de commit, despacha el workflow manual `CI` con ese objetivo, despacha `Plugin Prerelease` para pruebas solo de lanzamiento de Plugin/paquete/estáticas/Docker, y despacha `OpenClaw Release Checks` para smoke de instalación, aceptación de paquetes, suites de ruta de lanzamiento Docker, live/E2E, OpenWebUI, paridad de QA Lab, Matrix y lanes de Telegram. Con `rerun_group=all` y `release_profile=full`, también ejecuta `NPM Telegram Beta E2E` contra el artefacto `release-package-under-test` de las comprobaciones de lanzamiento. Después de publicar, pasa `npm_telegram_package_spec` para volver a ejecutar la misma lane de paquete de Telegram contra el paquete npm publicado.
|
||||
|
||||
Consulta [Validación completa de lanzamiento](/es/reference/full-release-validation) para la
|
||||
matriz de etapas, los nombres exactos de trabajos de flujo de trabajo, las diferencias de perfiles, los artefactos y los
|
||||
identificadores de reejecución enfocada.
|
||||
Consulta [validación completa de lanzamiento](/es/reference/full-release-validation) para la
|
||||
matriz de etapas, los nombres exactos de trabajos de workflow, las diferencias de perfil, los artefactos y
|
||||
los identificadores de repetición enfocados.
|
||||
|
||||
`OpenClaw Release Publish` es el flujo de trabajo manual de lanzamiento que modifica estado. Lánzalo
|
||||
desde `release/YYYY.M.D` o `main` después de que exista la etiqueta de lanzamiento y después de que la
|
||||
comprobación previa de npm de OpenClaw haya tenido éxito. Verifica `pnpm plugins:sync:check`,
|
||||
lanza `Plugin NPM Release` para todos los paquetes de plugins publicables, lanza
|
||||
`Plugin ClawHub Release` para el mismo SHA de lanzamiento y solo entonces lanza
|
||||
`OpenClaw Release Publish` es el workflow manual de lanzamiento con mutaciones. Despáchalo
|
||||
desde `release/YYYY.M.D` o `main` después de que exista la etiqueta de lanzamiento y después de que
|
||||
el preflight de npm de OpenClaw haya tenido éxito. Verifica `pnpm plugins:sync:check`,
|
||||
despacha `Plugin NPM Release` para todos los paquetes de plugins publicables, despacha
|
||||
`Plugin ClawHub Release` para el mismo SHA de lanzamiento y solo entonces despacha
|
||||
`OpenClaw NPM Release` con el `preflight_run_id` guardado.
|
||||
|
||||
```bash
|
||||
@ -177,47 +177,47 @@ gh workflow run openclaw-release-publish.yml \
|
||||
-f npm_dist_tag=beta
|
||||
```
|
||||
|
||||
Para pruebas de confirmación fijada en una rama que cambia rápidamente, usa el ayudante en lugar de
|
||||
Para prueba de commit fijado en una rama que se mueve rápido, usa el ayudante en vez de
|
||||
`gh workflow run ... --ref main -f ref=<sha>`:
|
||||
|
||||
```bash
|
||||
pnpm ci:full-release --sha <full-sha>
|
||||
```
|
||||
|
||||
Las referencias para lanzar flujos de trabajo de GitHub deben ser ramas o etiquetas, no SHA de confirmación sin procesar. El
|
||||
ayudante empuja una rama temporal `release-ci/<sha>-...` en el SHA de destino,
|
||||
lanza `Full Release Validation` desde esa referencia fijada, verifica que cada
|
||||
`headSha` de flujo de trabajo hijo coincida con el destino y elimina la rama temporal cuando la
|
||||
ejecución se completa. El verificador paraguas también falla si algún flujo de trabajo hijo se ejecutó en un
|
||||
SHA diferente.
|
||||
Las refs de despacho de workflow de GitHub deben ser ramas o etiquetas, no SHA de commits sin procesar. El
|
||||
ayudante sube una rama temporal `release-ci/<sha>-...` en el SHA objetivo,
|
||||
despacha `Full Release Validation` desde esa ref fijada, verifica que cada `headSha`
|
||||
de workflow hijo coincida con el objetivo y elimina la rama temporal cuando la
|
||||
ejecución termina. El verificador paraguas también falla si cualquier workflow hijo se ejecutó en un
|
||||
SHA distinto.
|
||||
|
||||
`release_profile` controla el alcance en vivo/de proveedores pasado a las comprobaciones de lanzamiento. Los
|
||||
flujos de trabajo manuales de lanzamiento usan `stable` de forma predeterminada; usa `full` solo cuando
|
||||
quieras intencionalmente la matriz amplia de proveedores/medios de carácter consultivo.
|
||||
`release_profile` controla la amplitud live/proveedor pasada a las comprobaciones de lanzamiento. Los
|
||||
workflows manuales de lanzamiento tienen `stable` como valor predeterminado; usa `full` solo cuando
|
||||
quieras intencionalmente la matriz amplia asesora de proveedores/medios.
|
||||
|
||||
- `minimum` conserva los carriles críticos para el lanzamiento de OpenAI/núcleo más rápidos.
|
||||
- `stable` añade el conjunto estable de proveedores/backend.
|
||||
- `full` ejecuta la matriz amplia de proveedores/medios de carácter consultivo.
|
||||
- `minimum` conserva las lanes críticas de lanzamiento más rápidas de OpenAI/core.
|
||||
- `stable` agrega el conjunto estable de proveedor/backend.
|
||||
- `full` ejecuta la matriz amplia asesora de proveedores/medios.
|
||||
|
||||
El paraguas registra los IDs de ejecución hijos lanzados, y el trabajo final `Verify full validation` vuelve a comprobar las conclusiones actuales de las ejecuciones hijas y agrega tablas de trabajos más lentos para cada ejecución hija. Si un flujo de trabajo hijo se vuelve a ejecutar y pasa a verde, vuelve a ejecutar solo el trabajo verificador padre para actualizar el resultado paraguas y el resumen de tiempos.
|
||||
El paraguas registra los ids de ejecuciones hijas despachadas, y el trabajo final `Verify full validation` vuelve a comprobar las conclusiones actuales de las ejecuciones hijas y añade tablas de trabajos más lentos para cada ejecución hija. Si un workflow hijo se vuelve a ejecutar y pasa a verde, vuelve a ejecutar solo el trabajo verificador padre para actualizar el resultado paraguas y el resumen de tiempos.
|
||||
|
||||
Para la recuperación, tanto `Full Release Validation` como `OpenClaw Release Checks` aceptan `rerun_group`. Usa `all` para una versión candidata, `ci` solo para el hijo normal de CI completa, `plugin-prerelease` solo para el hijo de prerelease del plugin, `release-checks` para cada hijo de lanzamiento, o un grupo más acotado: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` o `npm-telegram` en el paraguas. Esto mantiene acotada la nueva ejecución de una caja de lanzamiento fallida después de una corrección enfocada.
|
||||
Para la recuperación, tanto `Full Release Validation` como `OpenClaw Release Checks` aceptan `rerun_group`. Usa `all` para un candidato de lanzamiento, `ci` solo para el hijo normal de CI completo, `plugin-prerelease` solo para el hijo de prelanzamiento de Plugin, `release-checks` para cada hijo de lanzamiento, o un grupo más específico: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` o `npm-telegram` en el paraguas. Esto mantiene acotada la repetición de una caja de lanzamiento fallida después de una corrección enfocada.
|
||||
|
||||
`OpenClaw Release Checks` usa la referencia de flujo de trabajo de confianza para resolver la referencia seleccionada una vez en un tarball `release-package-under-test`, y luego pasa ese artefacto tanto al flujo de trabajo Docker de ruta de lanzamiento live/E2E como al shard de aceptación de paquete. Eso mantiene los bytes del paquete coherentes entre cajas de lanzamiento y evita volver a empaquetar el mismo candidato en varios trabajos hijos.
|
||||
`OpenClaw Release Checks` usa la referencia de workflow de confianza para resolver una vez la referencia seleccionada en un tarball `release-package-under-test`, y luego pasa ese artefacto tanto al workflow de Docker de la ruta de lanzamiento live/E2E como al shard de aceptación de paquete. Eso mantiene consistentes los bytes del paquete entre cajas de lanzamiento y evita volver a empaquetar el mismo candidato en varios jobs hijos.
|
||||
|
||||
Las ejecuciones duplicadas de `Full Release Validation` para `ref=main` y `rerun_group=all`
|
||||
reemplazan al paraguas anterior. El monitor padre cancela cualquier flujo de trabajo hijo que
|
||||
ya haya despachado cuando se cancela el padre, de modo que la validación más reciente de main
|
||||
no queda detrás de una ejecución obsoleta de release-check de dos horas. La validación de ramas/etiquetas
|
||||
de lanzamiento y los grupos de nueva ejecución enfocados mantienen `cancel-in-progress: false`.
|
||||
reemplazan al paraguas anterior. El monitor padre cancela cualquier workflow hijo que
|
||||
ya haya despachado cuando se cancela el padre, de modo que la validación más nueva de main
|
||||
no queda detrás de una ejecución obsoleta de release-check de dos horas. La validación de rama/etiqueta
|
||||
de lanzamiento y los grupos de repetición enfocados mantienen `cancel-in-progress: false`.
|
||||
|
||||
## Shards live y E2E
|
||||
|
||||
El hijo live/E2E de lanzamiento mantiene una cobertura nativa amplia de `pnpm test:live`, pero la ejecuta como shards con nombre mediante `scripts/test-live-shard.mjs` en lugar de un solo trabajo serial:
|
||||
El hijo live/E2E de lanzamiento mantiene una cobertura nativa amplia de `pnpm test:live`, pero la ejecuta como shards con nombre mediante `scripts/test-live-shard.mjs` en lugar de un job serial:
|
||||
|
||||
- `native-live-src-agents`
|
||||
- `native-live-src-gateway-core`
|
||||
- trabajos `native-live-src-gateway-profiles` filtrados por proveedor
|
||||
- jobs `native-live-src-gateway-profiles` filtrados por proveedor
|
||||
- `native-live-src-gateway-backends`
|
||||
- `native-live-test`
|
||||
- `native-live-extensions-a-k`
|
||||
@ -225,61 +225,61 @@ El hijo live/E2E de lanzamiento mantiene una cobertura nativa amplia de `pnpm te
|
||||
- `native-live-extensions-openai`
|
||||
- `native-live-extensions-o-z-other`
|
||||
- `native-live-extensions-xai`
|
||||
- shards separados de audio/video multimedia y shards de música filtrados por proveedor
|
||||
- shards divididos de audio/video de medios y shards de música filtrados por proveedor
|
||||
|
||||
Eso mantiene la misma cobertura de archivos y a la vez facilita volver a ejecutar y diagnosticar fallos lentos de proveedores live. Los nombres de shard agregados `native-live-extensions-o-z`, `native-live-extensions-media` y `native-live-extensions-media-music` siguen siendo válidos para nuevas ejecuciones manuales de una sola vez.
|
||||
Eso mantiene la misma cobertura de archivos y a la vez facilita repetir y diagnosticar fallos lentos de proveedores live. Los nombres agregados de shards `native-live-extensions-o-z`, `native-live-extensions-media` y `native-live-extensions-media-music` siguen siendo válidos para repeticiones manuales de una sola vez.
|
||||
|
||||
Los shards nativos live de multimedia se ejecutan en `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, construido por el flujo de trabajo `Live Media Runner Image`. Esa imagen preinstala `ffmpeg` y `ffprobe`; los trabajos de multimedia solo verifican los binarios antes de la configuración. Mantén las suites live respaldadas por Docker en runners normales de Blacksmith: los trabajos en contenedor son el lugar equivocado para lanzar pruebas Docker anidadas.
|
||||
Los shards nativos live de medios se ejecutan en `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, construido por el workflow `Live Media Runner Image`. Esa imagen preinstala `ffmpeg` y `ffprobe`; los jobs de medios solo verifican los binarios antes de la configuración. Mantén las suites live respaldadas por Docker en runners normales de Blacksmith; los jobs de contenedor no son el lugar adecuado para lanzar pruebas Docker anidadas.
|
||||
|
||||
Los shards live de modelo/backend respaldados por Docker usan una imagen compartida separada `ghcr.io/openclaw/openclaw-live-test:<sha>` por confirmación seleccionada. El flujo de trabajo live de lanzamiento construye y publica esa imagen una vez; luego los shards live Docker de modelo, Gateway segmentado por proveedor, backend de CLI, enlace ACP y arnés de Codex se ejecutan con `OPENCLAW_SKIP_DOCKER_BUILD=1`. Los shards Docker de Gateway llevan límites `timeout` explícitos a nivel de script por debajo del timeout del trabajo del flujo de trabajo, para que un contenedor atascado o una ruta de limpieza falle rápido en lugar de consumir todo el presupuesto de release-check. Si esos shards reconstruyen independientemente el destino Docker completo de la fuente, la ejecución de lanzamiento está mal configurada y desperdiciará tiempo real en compilaciones de imagen duplicadas.
|
||||
Los shards live de modelos/backends respaldados por Docker usan una imagen compartida separada `ghcr.io/openclaw/openclaw-live-test:<sha>` por commit seleccionado. El workflow live de lanzamiento construye y publica esa imagen una vez, y luego los shards live Docker de modelo, Gateway fragmentado por proveedor, backend de CLI, enlace ACP y arnés de Codex se ejecutan con `OPENCLAW_SKIP_DOCKER_BUILD=1`. Los shards Docker de Gateway llevan límites explícitos de `timeout` a nivel de script por debajo del timeout del job del workflow, de modo que un contenedor bloqueado o una ruta de limpieza falla rápido en vez de consumir todo el presupuesto de release-check. Si esos shards reconstruyen de forma independiente el destino Docker completo del código fuente, la ejecución de lanzamiento está mal configurada y desperdiciará tiempo de reloj en compilaciones de imagen duplicadas.
|
||||
|
||||
## Aceptación de paquete
|
||||
|
||||
Usa `Package Acceptance` cuando la pregunta sea "¿funciona este paquete instalable de OpenClaw como producto?". Es distinto de la CI normal: la CI normal valida el árbol fuente, mientras que la aceptación de paquete valida un único tarball mediante el mismo arnés Docker E2E que los usuarios ejercitan después de instalar o actualizar.
|
||||
Usa `Package Acceptance` cuando la pregunta sea "¿funciona este paquete instalable de OpenClaw como producto?". Es diferente de la CI normal: la CI normal valida el árbol de código fuente, mientras que la aceptación de paquete valida un único tarball mediante el mismo arnés Docker E2E que los usuarios ejercitan después de instalar o actualizar.
|
||||
|
||||
### Trabajos
|
||||
### Jobs
|
||||
|
||||
1. `resolve_package` hace checkout de `workflow_ref`, resuelve un candidato de paquete, escribe `.artifacts/docker-e2e-package/openclaw-current.tgz`, escribe `.artifacts/docker-e2e-package/package-candidate.json`, sube ambos como el artefacto `package-under-test` e imprime el origen, la referencia del flujo de trabajo, la referencia del paquete, la versión, SHA-256 y el perfil en el resumen del paso de GitHub.
|
||||
2. `docker_acceptance` llama a `openclaw-live-and-e2e-checks-reusable.yml` con `ref=workflow_ref` y `package_artifact_name=package-under-test`. El flujo de trabajo reutilizable descarga ese artefacto, valida el inventario del tarball, prepara imágenes Docker con digest de paquete cuando sea necesario y ejecuta los carriles Docker seleccionados contra ese paquete en lugar de empaquetar el checkout del flujo de trabajo. Cuando un perfil selecciona varios `docker_lanes` dirigidos, el flujo de trabajo reutilizable prepara el paquete y las imágenes compartidas una vez, y luego despliega esos carriles como trabajos Docker dirigidos paralelos con artefactos únicos.
|
||||
3. `package_telegram` llama opcionalmente a `NPM Telegram Beta E2E`. Se ejecuta cuando `telegram_mode` no es `none` e instala el mismo artefacto `package-under-test` cuando Package Acceptance resolvió uno; un despacho independiente de Telegram todavía puede instalar una especificación publicada de npm.
|
||||
4. `summary` falla el flujo de trabajo si falló la resolución de paquete, la aceptación Docker o el carril opcional de Telegram.
|
||||
1. `resolve_package` hace checkout de `workflow_ref`, resuelve un candidato de paquete, escribe `.artifacts/docker-e2e-package/openclaw-current.tgz`, escribe `.artifacts/docker-e2e-package/package-candidate.json`, sube ambos como el artefacto `package-under-test` e imprime el origen, la referencia de workflow, la referencia de paquete, la versión, SHA-256 y el perfil en el resumen del paso de GitHub.
|
||||
2. `docker_acceptance` llama a `openclaw-live-and-e2e-checks-reusable.yml` con `ref=workflow_ref` y `package_artifact_name=package-under-test`. El workflow reutilizable descarga ese artefacto, valida el inventario del tarball, prepara imágenes Docker de digest de paquete cuando es necesario y ejecuta los carriles Docker seleccionados contra ese paquete en lugar de empaquetar el checkout del workflow. Cuando un perfil selecciona varios `docker_lanes` dirigidos, el workflow reutilizable prepara el paquete y las imágenes compartidas una vez, y luego distribuye esos carriles como jobs Docker dirigidos en paralelo con artefactos únicos.
|
||||
3. `package_telegram` llama opcionalmente a `NPM Telegram Beta E2E`. Se ejecuta cuando `telegram_mode` no es `none` e instala el mismo artefacto `package-under-test` cuando Package Acceptance resolvió uno; un despacho independiente de Telegram todavía puede instalar una especificación npm publicada.
|
||||
4. `summary` hace fallar el workflow si fallaron la resolución del paquete, la aceptación Docker o el carril opcional de Telegram.
|
||||
|
||||
### Orígenes de candidato
|
||||
### Orígenes de candidatos
|
||||
|
||||
- `source=npm` acepta solo `openclaw@alpha`, `openclaw@beta`, `openclaw@latest` o una versión exacta de lanzamiento de OpenClaw como `openclaw@2026.4.27-beta.2`. Usa esto para la aceptación de prereleases/estables publicados.
|
||||
- `source=ref` empaqueta una rama, etiqueta o SHA de confirmación completo de `package_ref` de confianza. El resolvedor obtiene ramas/etiquetas de OpenClaw, verifica que la confirmación seleccionada sea alcanzable desde el historial de ramas del repositorio o una etiqueta de lanzamiento, instala dependencias en un worktree desacoplado y la empaqueta con `scripts/package-openclaw-for-docker.mjs`.
|
||||
- `source=npm` acepta solo `openclaw@beta`, `openclaw@latest` o una versión exacta de lanzamiento de OpenClaw como `openclaw@2026.4.27-beta.2`. Usa esto para aceptación de prelanzamientos/estables publicados.
|
||||
- `source=ref` empaqueta una rama, etiqueta o SHA de commit completo de `package_ref` de confianza. El resolvedor obtiene ramas/etiquetas de OpenClaw, verifica que el commit seleccionado sea alcanzable desde el historial de ramas del repositorio o desde una etiqueta de lanzamiento, instala dependencias en un worktree separado y lo empaqueta con `scripts/package-openclaw-for-docker.mjs`.
|
||||
- `source=url` descarga un `.tgz` HTTPS; `package_sha256` es obligatorio.
|
||||
- `source=artifact` descarga un `.tgz` de `artifact_run_id` y `artifact_name`; `package_sha256` es opcional, pero debería proporcionarse para artefactos compartidos externamente.
|
||||
- `source=artifact` descarga un `.tgz` de `artifact_run_id` y `artifact_name`; `package_sha256` es opcional, pero debe suministrarse para artefactos compartidos externamente.
|
||||
|
||||
Mantén `workflow_ref` y `package_ref` separados. `workflow_ref` es el código de flujo de trabajo/arnés de confianza que ejecuta la prueba. `package_ref` es la confirmación fuente que se empaqueta cuando `source=ref`. Esto permite que el arnés de prueba actual valide confirmaciones fuente de confianza más antiguas sin ejecutar lógica antigua de flujo de trabajo.
|
||||
Mantén `workflow_ref` y `package_ref` separados. `workflow_ref` es el código de workflow/arnés de confianza que ejecuta la prueba. `package_ref` es el commit de origen que se empaqueta cuando `source=ref`. Esto permite que el arnés de prueba actual valide commits de origen confiables más antiguos sin ejecutar lógica de workflow antigua.
|
||||
|
||||
### Perfiles de suite
|
||||
|
||||
- `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload`
|
||||
- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `published-upgrade-survivor`, `plugins-offline`, `plugin-update`
|
||||
- `product` — `package` más `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
|
||||
- `full` — chunks completos de ruta de lanzamiento Docker con OpenWebUI
|
||||
- `full` — fragmentos completos de la ruta de lanzamiento Docker con OpenWebUI
|
||||
- `custom` — `docker_lanes` exactos; obligatorio cuando `suite_profile=custom`
|
||||
|
||||
El perfil `package` usa cobertura de plugins offline, para que la validación de paquetes publicados no dependa de la disponibilidad live de ClawHub. El carril opcional de Telegram reutiliza el artefacto `package-under-test` en `NPM Telegram Beta E2E`, y la ruta de especificación npm publicada se conserva para despachos independientes.
|
||||
El perfil `package` usa cobertura de plugins sin conexión para que la validación de paquetes publicados no dependa de la disponibilidad live de ClawHub. El carril opcional de Telegram reutiliza el artefacto `package-under-test` en `NPM Telegram Beta E2E`, y se conserva la ruta de especificación npm publicada para despachos independientes.
|
||||
|
||||
Para la política dedicada de pruebas de actualización y plugins, incluidos comandos locales,
|
||||
carriles Docker, entradas de Package Acceptance, valores predeterminados de lanzamiento y triage de fallos,
|
||||
carriles Docker, entradas de Package Acceptance, valores predeterminados de lanzamiento y triaje de fallos,
|
||||
consulta [Pruebas de actualizaciones y plugins](/es/help/testing-updates-plugins).
|
||||
|
||||
Las comprobaciones de lanzamiento llaman a Package Acceptance con `source=artifact`, el artefacto de paquete de lanzamiento preparado, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=all-since-2026.4.23`, `published_upgrade_survivor_scenarios=reported-issues` y `telegram_mode=mock-openai`. Esto mantiene la prueba de migración de paquete, actualización, limpieza de dependencias obsoletas de plugins, reparación de instalación de plugins configurados, plugins offline, actualización de plugins y Telegram sobre el mismo tarball de paquete resuelto. Configura `package_acceptance_package_spec` en Full Release Validation u OpenClaw Release Checks para ejecutar esa misma matriz contra un paquete npm publicado en lugar del artefacto construido desde SHA. Las comprobaciones de lanzamiento cross-OS siguen cubriendo el onboarding específico del sistema operativo, el instalador y el comportamiento de plataforma; la validación de producto de paquete/actualización debería empezar con Package Acceptance. El carril Docker `published-upgrade-survivor` valida una línea base de paquete publicado por ejecución. En Package Acceptance, el tarball resuelto `package-under-test` siempre es el candidato y `published_upgrade_survivor_baseline` selecciona la línea base publicada de respaldo, con valor predeterminado `openclaw@latest`; los comandos de nueva ejecución de carriles fallidos preservan esa línea base. Configura `published_upgrade_survivor_baselines=all-since-2026.4.23` para expandir la CI de Full Release a cada lanzamiento estable de npm desde `2026.4.23` hasta `latest`; `release-history` sigue disponible para muestreos manuales más amplios con el ancla anterior a esa fecha. Configura `published_upgrade_survivor_scenarios=reported-issues` para expandir las mismas líneas base a fixtures con forma de incidencias para configuración de Feishu, archivos bootstrap/persona preservados, instalaciones configuradas de plugins de OpenClaw, rutas de logs con tilde y raíces de dependencias de plugins heredadas obsoletas. El flujo de trabajo separado `Update Migration` usa el carril Docker `update-migration` con `all-since-2026.4.23` y `plugin-deps-cleanup` cuando la pregunta es la limpieza exhaustiva de actualizaciones publicadas, no la amplitud normal de la CI de Full Release. Las ejecuciones agregadas locales pueden pasar especificaciones exactas de paquete con `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, mantener un solo carril con `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC` como `openclaw@2026.4.15`, o configurar `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` para la matriz de escenarios. El carril publicado configura la línea base con una receta integrada de comando `openclaw config set`, registra los pasos de la receta en `summary.json` y sondea `/healthz`, `/readyz` y el estado RPC después de iniciar Gateway. Los carriles frescos empaquetados y de instalador de Windows también verifican que un paquete instalado pueda importar una anulación de browser-control desde una ruta absoluta cruda de Windows. El smoke cross-OS de turno de agente de OpenAI usa de forma predeterminada `OPENCLAW_CROSS_OS_OPENAI_MODEL` cuando está configurado; de lo contrario, `openai/gpt-5.4`, para que la prueba de instalación y Gateway permanezca en un modelo de prueba GPT-5 y evite valores predeterminados GPT-4.x.
|
||||
Release checks llama a Package Acceptance con `source=artifact`, el artefacto de paquete de lanzamiento preparado, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=all-since-2026.4.23`, `published_upgrade_survivor_scenarios=reported-issues` y `telegram_mode=mock-openai`. Esto mantiene la migración de paquete, actualización, limpieza de dependencias obsoletas de plugins, reparación de instalación de plugins configurados, prueba de plugins sin conexión, actualización de plugins y prueba de Telegram en el mismo tarball de paquete resuelto. Configura `package_acceptance_package_spec` en Full Release Validation u OpenClaw Release Checks para ejecutar esa misma matriz contra un paquete npm publicado en lugar del artefacto construido desde el SHA. Los release checks Cross-OS aún cubren el onboarding, instalador y comportamiento de plataforma específicos del sistema operativo; la validación de producto de paquete/actualización debe comenzar con Package Acceptance. El carril Docker `published-upgrade-survivor` valida una línea base de paquete publicado por ejecución. En Package Acceptance, el tarball resuelto `package-under-test` siempre es el candidato y `published_upgrade_survivor_baseline` selecciona la línea base publicada de respaldo, que por defecto es `openclaw@latest`; los comandos de repetición de carril fallido conservan esa línea base. Configura `published_upgrade_survivor_baselines=all-since-2026.4.23` para expandir la CI de Full Release por cada lanzamiento npm estable desde `2026.4.23` hasta `latest`; `release-history` sigue disponible para un muestreo manual más amplio con el ancla anterior a esa fecha. Configura `published_upgrade_survivor_scenarios=reported-issues` para expandir las mismas líneas base por fixtures con forma de incidencias para la configuración de Feishu, archivos bootstrap/persona preservados, instalaciones configuradas de plugins de OpenClaw, rutas de logs con tilde y raíces de dependencias de plugins legadas obsoletas. El workflow separado `Update Migration` usa el carril Docker `update-migration` con `all-since-2026.4.23` y `plugin-deps-cleanup` cuando la pregunta es una limpieza exhaustiva de actualizaciones publicadas, no el alcance normal de la CI de Full Release. Las ejecuciones agregadas locales pueden pasar especificaciones exactas de paquetes con `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, mantener un solo carril con `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC` como `openclaw@2026.4.15`, o configurar `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` para la matriz de escenarios. El carril publicado configura la línea base con una receta incorporada de comandos `openclaw config set`, registra los pasos de la receta en `summary.json` y sondea `/healthz`, `/readyz`, además del estado RPC después del inicio de Gateway. Los carriles fresh de paquete e instalador en Windows también verifican que un paquete instalado pueda importar una anulación de browser-control desde una ruta absoluta sin procesar de Windows. El smoke de turno de agente Cross-OS de OpenAI usa por defecto `OPENCLAW_CROSS_OS_OPENAI_MODEL` cuando está configurado; de lo contrario, `openai/gpt-5.4`, de modo que la prueba de instalación y Gateway permanezca en un modelo de prueba GPT-5 y evite valores predeterminados GPT-4.x.
|
||||
|
||||
### Ventanas de compatibilidad heredada
|
||||
|
||||
Package Acceptance tiene ventanas acotadas de compatibilidad heredada para paquetes ya publicados. Los paquetes hasta `2026.4.25`, incluido `2026.4.25-beta.*`, pueden usar la ruta de compatibilidad:
|
||||
|
||||
- las entradas privadas conocidas de QA en `dist/postinstall-inventory.json` pueden apuntar a archivos omitidos del tarball;
|
||||
- `doctor-switch` puede omitir el subcaso de persistencia `gateway install --wrapper` cuando el paquete no expone esa marca;
|
||||
- `update-channel-switch` puede podar `pnpm.patchedDependencies` faltantes del fixture git falso derivado del tarball y puede registrar la falta de `update.channel` persistido;
|
||||
- los smokes de plugins pueden leer ubicaciones heredadas de registros de instalación o aceptar la falta de persistencia del registro de instalación del marketplace;
|
||||
- `plugin-update` puede permitir la migración de metadatos de configuración y aun así exigir que el registro de instalación y el comportamiento de no reinstalación permanezcan sin cambios.
|
||||
- las entradas QA privadas conocidas en `dist/postinstall-inventory.json` pueden apuntar a archivos omitidos del tarball;
|
||||
- `doctor-switch` puede omitir el subcaso de persistencia de `gateway install --wrapper` cuando el paquete no expone esa bandera;
|
||||
- `update-channel-switch` puede podar `pnpm.patchedDependencies` faltantes del fixture git falso derivado del tarball y puede registrar `update.channel` persistido faltante;
|
||||
- los smokes de plugins pueden leer ubicaciones heredadas de registros de instalación o aceptar persistencia faltante de registros de instalación del marketplace;
|
||||
- `plugin-update` puede permitir la migración de metadatos de configuración mientras sigue exigiendo que el registro de instalación y el comportamiento sin reinstalación permanezcan sin cambios.
|
||||
|
||||
El paquete publicado `2026.4.26` también puede advertir por archivos de sello de metadatos de compilación local que ya se habían enviado. Los paquetes posteriores deben satisfacer los contratos modernos; las mismas condiciones fallan en lugar de advertir u omitirse.
|
||||
El paquete publicado `2026.4.26` también puede advertir por archivos de sello de metadatos de compilación local que ya fueron enviados. Los paquetes posteriores deben satisfacer los contratos modernos; las mismas condiciones fallan en lugar de advertir u omitirse.
|
||||
|
||||
### Ejemplos
|
||||
|
||||
@ -322,110 +322,110 @@ gh workflow run package-acceptance.yml \
|
||||
-f docker_lanes='install-e2e plugin-update'
|
||||
```
|
||||
|
||||
Al depurar una ejecución fallida de aceptación de paquetes, empieza por el resumen de `resolve_package` para confirmar el origen, la versión y el SHA-256 del paquete. Luego inspecciona la ejecución secundaria de `docker_acceptance` y sus artefactos de Docker: `.artifacts/docker-tests/**/summary.json`, `failures.json`, registros de lanes, tiempos de fases y comandos de reejecución. Prefiere reejecutar el perfil de paquete fallido o las lanes exactas de Docker en lugar de reejecutar la validación completa de la versión.
|
||||
Al depurar una ejecución fallida de aceptación de paquetes, comienza por el resumen de `resolve_package` para confirmar el origen del paquete, la versión y el SHA-256. Luego inspecciona la ejecución secundaria `docker_acceptance` y sus artefactos de Docker: `.artifacts/docker-tests/**/summary.json`, `failures.json`, registros de carriles, tiempos de fases y comandos de repetición. Prefiere volver a ejecutar el perfil de paquete fallido o los carriles de Docker exactos en lugar de volver a ejecutar la validación de versión completa.
|
||||
|
||||
## Smoke de instalación
|
||||
|
||||
El workflow independiente `Install Smoke` reutiliza el mismo script de alcance mediante su propio job `preflight`. Divide la cobertura smoke en `run_fast_install_smoke` y `run_full_install_smoke`.
|
||||
El flujo de trabajo `Install Smoke` separado reutiliza el mismo script de alcance mediante su propio trabajo `preflight`. Divide la cobertura smoke en `run_fast_install_smoke` y `run_full_install_smoke`.
|
||||
|
||||
- **Ruta rápida** se ejecuta para solicitudes de incorporación de cambios que tocan superficies de Docker/paquete, cambios de paquete/manifiesto de Plugin incluido, o superficies principales de Plugin/canal/Gateway/SDK de Plugin que ejercitan los jobs smoke de Docker. Los cambios solo de código fuente en Plugins incluidos, las ediciones solo de pruebas y las ediciones solo de documentación no reservan workers de Docker. La ruta rápida construye una vez la imagen del Dockerfile raíz, comprueba la CLI, ejecuta el smoke de CLI de eliminación de agents en workspace compartido, ejecuta el e2e de gateway-network en contenedor, verifica un argumento de compilación de extensión incluida y ejecuta el perfil acotado de Docker de Plugin incluido bajo un timeout agregado de comando de 240 segundos (cada ejecución de Docker de cada escenario se limita por separado).
|
||||
- **Ruta completa** conserva la instalación de paquetes QR y la cobertura de Docker/actualización del instalador para ejecuciones nocturnas programadas, despachos manuales, comprobaciones de versión mediante workflow-call y solicitudes de incorporación de cambios que realmente tocan superficies de instalador/paquete/Docker. En modo completo, install-smoke prepara o reutiliza una imagen smoke de GHCR para el Dockerfile raíz de un SHA objetivo, y luego ejecuta la instalación de paquetes QR, smokes del Dockerfile raíz/Gateway, smokes de instalador/actualización y el E2E rápido de Docker de Plugin incluido como jobs separados para que el trabajo del instalador no espere detrás de los smokes de la imagen raíz.
|
||||
- **Ruta rápida** se ejecuta para pull requests que tocan superficies de Docker/paquete, cambios en paquete/manifiesto de plugins incluidos o superficies principales de plugin/canal/gateway/Plugin SDK que ejercitan los trabajos smoke de Docker. Los cambios de solo código fuente en plugins incluidos, las ediciones solo de pruebas y las ediciones solo de documentación no reservan workers de Docker. La ruta rápida construye la imagen del Dockerfile raíz una vez, comprueba la CLI, ejecuta el smoke de CLI de eliminación de agentes en espacio de trabajo compartido, ejecuta el e2e de gateway-network en contenedor, verifica un argumento de compilación de una extensión incluida y ejecuta el perfil de Docker acotado de plugins incluidos bajo un tiempo de espera agregado de comando de 240 segundos (cada ejecución de Docker de escenario limitada por separado).
|
||||
- **Ruta completa** mantiene la instalación del paquete QR y la cobertura de Docker/actualización del instalador para ejecuciones nocturnas programadas, despachos manuales, comprobaciones de versión mediante workflow-call y pull requests que realmente tocan superficies de instalador/paquete/Docker. En modo completo, install-smoke prepara o reutiliza una imagen smoke GHCR del Dockerfile raíz para un SHA objetivo, luego ejecuta instalación del paquete QR, smokes del Dockerfile raíz/gateway, smokes de instalador/actualización y el Docker E2E rápido de plugins incluidos como trabajos separados para que el trabajo del instalador no espere detrás de los smokes de la imagen raíz.
|
||||
|
||||
Los pushes a `main` (incluidos los commits de fusión) no fuerzan la ruta completa; cuando la lógica de alcance de cambios solicitaría cobertura completa en un push, el workflow mantiene el smoke rápido de Docker y deja el smoke completo de instalación para la validación nocturna o de versión.
|
||||
Los pushes a `main` (incluidos commits de merge) no fuerzan la ruta completa; cuando la lógica de alcance de cambios solicitaría cobertura completa en un push, el flujo de trabajo conserva el smoke rápido de Docker y deja el smoke completo de instalación para la validación nocturna o de versión.
|
||||
|
||||
El smoke lento de proveedor de imágenes de instalación global de Bun se controla por separado mediante `run_bun_global_install_smoke`. Se ejecuta en la programación nocturna y desde el workflow de comprobaciones de versión, y los despachos manuales de `Install Smoke` pueden optar por incluirlo, pero las solicitudes de incorporación de cambios y los pushes a `main` no. Las pruebas de Docker de QR e instalador conservan sus propios Dockerfiles centrados en instalación.
|
||||
El smoke lento de proveedor de imagen con instalación global de Bun se controla por separado mediante `run_bun_global_install_smoke`. Se ejecuta en la programación nocturna y desde el flujo de trabajo de comprobaciones de versión, y los despachos manuales de `Install Smoke` pueden optar por incluirlo, pero los pull requests y pushes a `main` no. Las pruebas Docker de QR e instalador conservan sus propios Dockerfiles enfocados en instalación.
|
||||
|
||||
## E2E local de Docker
|
||||
## Docker E2E local
|
||||
|
||||
`pnpm test:docker:all` preconstruye una imagen compartida de pruebas live, empaqueta OpenClaw una vez como tarball npm y construye dos imágenes compartidas de `scripts/e2e/Dockerfile`:
|
||||
`pnpm test:docker:all` precompila una imagen de prueba en vivo compartida, empaqueta OpenClaw una vez como tarball npm y construye dos imágenes compartidas de `scripts/e2e/Dockerfile`:
|
||||
|
||||
- un runner básico de Node/Git para lanes de instalador/actualización/dependencias de Plugin;
|
||||
- una imagen funcional que instala el mismo tarball en `/app` para lanes de funcionalidad normal.
|
||||
- un runner básico de Node/Git para carriles de instalador/actualización/dependencias de plugins;
|
||||
- una imagen funcional que instala el mismo tarball en `/app` para carriles de funcionalidad normal.
|
||||
|
||||
Las definiciones de lanes de Docker viven en `scripts/lib/docker-e2e-scenarios.mjs`, la lógica del planificador vive en `scripts/lib/docker-e2e-plan.mjs` y el runner solo ejecuta el plan seleccionado. El programador selecciona la imagen por lane con `OPENCLAW_DOCKER_E2E_BARE_IMAGE` y `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, y luego ejecuta las lanes con `OPENCLAW_SKIP_DOCKER_BUILD=1`.
|
||||
Las definiciones de carriles de Docker viven en `scripts/lib/docker-e2e-scenarios.mjs`, la lógica del planificador vive en `scripts/lib/docker-e2e-plan.mjs` y el runner solo ejecuta el plan seleccionado. El programador selecciona la imagen por carril con `OPENCLAW_DOCKER_E2E_BARE_IMAGE` y `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, luego ejecuta carriles con `OPENCLAW_SKIP_DOCKER_BUILD=1`.
|
||||
|
||||
### Parámetros ajustables
|
||||
### Ajustes
|
||||
|
||||
| Variable | Valor predeterminado | Propósito |
|
||||
| -------------------------------------- | -------------------- | --------------------------------------------------------------------------------------------- |
|
||||
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Recuento de ranuras del grupo principal para lanes normales. |
|
||||
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Recuento de ranuras del grupo final sensible a proveedores. |
|
||||
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Límite de lanes live concurrentes para que los proveedores no apliquen limitación. |
|
||||
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Límite de lanes concurrentes de instalación npm. |
|
||||
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Límite de lanes concurrentes multiservicio. |
|
||||
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Escalonamiento entre inicios de lanes para evitar ráfagas de creación del daemon de Docker; establece `0` para no escalonar. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Timeout de respaldo por lane (120 minutos); las lanes live/finales seleccionadas usan límites más estrictos. |
|
||||
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | sin definir | `1` imprime el plan del programador sin ejecutar lanes. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANES` | sin definir | Lista exacta de lanes separada por comas; omite el smoke de limpieza para que los agents puedan reproducir una lane fallida. |
|
||||
| Variable | Predeterminado | Propósito |
|
||||
| -------------------------------------- | -------------- | --------------------------------------------------------------------------------------------- |
|
||||
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Recuento de slots del pool principal para carriles normales. |
|
||||
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Recuento de slots del pool final sensible a proveedores. |
|
||||
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Límite de carriles en vivo concurrentes para que los proveedores no apliquen throttling. |
|
||||
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Límite de carriles concurrentes de instalación npm. |
|
||||
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Límite de carriles concurrentes con varios servicios. |
|
||||
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Escalonamiento entre inicios de carril para evitar tormentas de creación del daemon de Docker; define `0` para no escalonar. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Tiempo de espera de respaldo por carril (120 minutos); algunos carriles en vivo/finales usan límites más ajustados. |
|
||||
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | sin definir | `1` imprime el plan del programador sin ejecutar carriles. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANES` | sin definir | Lista separada por comas de carriles exactos; omite el smoke de limpieza para que los agentes puedan reproducir un carril fallido. |
|
||||
|
||||
Una lane más pesada que su límite efectivo aún puede iniciarse desde un grupo vacío, y luego se ejecuta sola hasta liberar capacidad. El agregado local ejecuta preflights de Docker, elimina contenedores E2E de OpenClaw obsoletos, emite estado de lanes activas, persiste tiempos de lanes para ordenar de mayor a menor duración y deja de programar nuevas lanes agrupadas después del primer fallo de forma predeterminada.
|
||||
Un carril más pesado que su límite efectivo todavía puede comenzar desde un pool vacío, y luego se ejecuta solo hasta que libera capacidad. Los preflights agregados locales verifican Docker, eliminan contenedores E2E obsoletos de OpenClaw, emiten el estado de carriles activos, persisten tiempos de carril para ordenamiento del más largo primero y dejan de programar carriles nuevos en pools tras el primer fallo de forma predeterminada.
|
||||
|
||||
### Workflow live/E2E reutilizable
|
||||
### Flujo de trabajo reutilizable en vivo/E2E
|
||||
|
||||
El workflow live/E2E reutilizable pregunta a `scripts/test-docker-all.mjs --plan-json` qué cobertura de paquete, tipo de imagen, imagen live, lane y credenciales se requiere. Luego `scripts/docker-e2e.mjs` convierte ese plan en salidas y resúmenes de GitHub. Empaqueta OpenClaw mediante `scripts/package-openclaw-for-docker.mjs`, descarga un artefacto de paquete de la ejecución actual o descarga un artefacto de paquete desde `package_artifact_run_id`; valida el inventario del tarball; construye y publica imágenes E2E de Docker GHCR básicas/funcionales etiquetadas con digest de paquete mediante la caché de capas de Docker de Blacksmith cuando el plan necesita lanes con paquete instalado; y reutiliza las entradas `docker_e2e_bare_image`/`docker_e2e_functional_image` proporcionadas o imágenes existentes por digest de paquete en lugar de reconstruir. Los pulls de imágenes de Docker se reintentan con un timeout acotado de 180 segundos por intento para que un flujo atascado de registry/caché reintente rápido en lugar de consumir la mayor parte de la ruta crítica de CI.
|
||||
El flujo de trabajo reutilizable en vivo/E2E pregunta a `scripts/test-docker-all.mjs --plan-json` qué cobertura de paquete, tipo de imagen, imagen en vivo, carril y credenciales se requiere. Luego `scripts/docker-e2e.mjs` convierte ese plan en salidas y resúmenes de GitHub. Empaqueta OpenClaw mediante `scripts/package-openclaw-for-docker.mjs`, descarga un artefacto de paquete de la ejecución actual o descarga un artefacto de paquete desde `package_artifact_run_id`; valida el inventario del tarball; construye y publica imágenes Docker E2E básicas/funcionales de GHCR etiquetadas por digest de paquete mediante la caché de capas Docker de Blacksmith cuando el plan necesita carriles con paquete instalado; y reutiliza las entradas `docker_e2e_bare_image`/`docker_e2e_functional_image` proporcionadas o imágenes existentes por digest de paquete en lugar de reconstruir. Los pulls de imágenes Docker se reintentan con un tiempo de espera acotado de 180 segundos por intento para que un flujo atascado de registro/caché reintente rápidamente en lugar de consumir la mayor parte de la ruta crítica de CI.
|
||||
|
||||
### Fragmentos de la ruta de versión
|
||||
### Fragmentos de ruta de versión
|
||||
|
||||
La cobertura de Docker de versión ejecuta jobs fragmentados más pequeños con `OPENCLAW_SKIP_DOCKER_BUILD=1`, para que cada fragmento extraiga solo el tipo de imagen que necesita y ejecute varias lanes mediante el mismo programador ponderado:
|
||||
La cobertura Docker de versión ejecuta trabajos fragmentados más pequeños con `OPENCLAW_SKIP_DOCKER_BUILD=1` para que cada fragmento descargue solo el tipo de imagen que necesita y ejecute varios carriles mediante el mismo programador ponderado:
|
||||
|
||||
- `OPENCLAW_DOCKER_ALL_PROFILE=release-path`
|
||||
- `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h`
|
||||
|
||||
Los fragmentos actuales de Docker de versión son `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` y de `plugins-runtime-install-a` a `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` y `plugins-integrations` siguen siendo alias agregados de Plugin/runtime. El alias de lane `install-e2e` sigue siendo el alias agregado de reejecución manual para ambas lanes de instalador de proveedor.
|
||||
Los fragmentos Docker de versión actuales son `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` y de `plugins-runtime-install-a` a `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` y `plugins-integrations` siguen siendo alias agregados de plugin/runtime. El alias de carril `install-e2e` sigue siendo el alias agregado de repetición manual para ambos carriles de instalador de proveedor.
|
||||
|
||||
OpenWebUI se incorpora a `plugins-runtime-services` cuando la cobertura completa de release-path lo solicita, y conserva un fragmento independiente `openwebui` solo para despachos exclusivos de OpenWebUI. Las lanes de actualización de canales incluidos reintentan una vez ante fallos transitorios de red npm.
|
||||
OpenWebUI se incorpora en `plugins-runtime-services` cuando la cobertura completa de release-path lo solicita, y conserva un fragmento independiente `openwebui` solo para despachos exclusivos de OpenWebUI. Los carriles de actualización de canales incluidos reintentan una vez ante fallos transitorios de red npm.
|
||||
|
||||
Cada fragmento sube `.artifacts/docker-tests/` con registros de lanes, tiempos, `summary.json`, `failures.json`, tiempos de fases, JSON del plan del programador, tablas de lanes lentas y comandos de reejecución por lane. La entrada `docker_lanes` del workflow ejecuta lanes seleccionadas contra las imágenes preparadas en lugar de los jobs de fragmentos, lo que mantiene la depuración de lanes fallidas acotada a un job de Docker dirigido y prepara, descarga o reutiliza el artefacto de paquete para esa ejecución; si una lane seleccionada es una lane live de Docker, el job dirigido construye la imagen de pruebas live localmente para esa reejecución. Los comandos de reejecución de GitHub generados por lane incluyen `package_artifact_run_id`, `package_artifact_name` y entradas de imágenes preparadas cuando esos valores existen, para que una lane fallida pueda reutilizar el paquete y las imágenes exactos de la ejecución fallida.
|
||||
Cada fragmento sube `.artifacts/docker-tests/` con registros de carril, tiempos, `summary.json`, `failures.json`, tiempos de fase, JSON del plan del programador, tablas de carriles lentos y comandos de repetición por carril. La entrada `docker_lanes` del flujo de trabajo ejecuta carriles seleccionados contra las imágenes preparadas en lugar de los trabajos de fragmento, lo que mantiene la depuración de carriles fallidos acotada a un trabajo Docker específico y prepara, descarga o reutiliza el artefacto de paquete para esa ejecución; si un carril seleccionado es un carril Docker en vivo, el trabajo específico construye localmente la imagen de prueba en vivo para esa repetición. Los comandos generados de repetición de GitHub por carril incluyen `package_artifact_run_id`, `package_artifact_name` y entradas de imágenes preparadas cuando esos valores existen, para que un carril fallido pueda reutilizar el paquete y las imágenes exactas de la ejecución fallida.
|
||||
|
||||
```bash
|
||||
pnpm test:docker:rerun <run-id> # download Docker artifacts and print combined/per-lane targeted rerun commands
|
||||
pnpm test:docker:timings <summary> # slow-lane and phase critical-path summaries
|
||||
```
|
||||
|
||||
El workflow live/E2E programado ejecuta a diario la suite completa de Docker de release-path.
|
||||
El flujo de trabajo programado en vivo/E2E ejecuta diariamente la suite Docker completa de release-path.
|
||||
|
||||
## Prelanzamiento de Plugin
|
||||
|
||||
`Plugin Prerelease` es una cobertura de producto/paquete más costosa, por lo que es un workflow independiente despachado por `Full Release Validation` o por un operador explícito. Las solicitudes de incorporación de cambios normales, los pushes a `main` y los despachos manuales independientes de CI mantienen esa suite desactivada. Equilibra las pruebas de Plugins incluidos entre ocho workers de extensión; esos jobs de shards de extensión ejecutan hasta dos grupos de configuración de Plugin a la vez con un worker de Vitest por grupo y un heap de Node mayor para que los lotes de Plugins con muchas importaciones no creen jobs adicionales de CI. La ruta de prelanzamiento de Docker solo para versiones agrupa lanes de Docker dirigidas en grupos pequeños para evitar reservar docenas de runners para jobs de uno a tres minutos.
|
||||
`Plugin Prerelease` es una cobertura de producto/paquete más costosa, por lo que es un flujo de trabajo separado despachado por `Full Release Validation` o por un operador explícito. Los pull requests normales, pushes a `main` y despachos manuales independientes de CI mantienen esa suite desactivada. Equilibra las pruebas de plugins incluidos entre ocho workers de extensión; esos trabajos de fragmento de extensión ejecutan hasta dos grupos de configuración de plugins a la vez con un worker de Vitest por grupo y un heap de Node más grande para que los lotes de plugins con muchas importaciones no creen trabajos de CI adicionales. La ruta de prelanzamiento Docker exclusiva de versión agrupa carriles Docker específicos en grupos pequeños para evitar reservar decenas de runners para trabajos de uno a tres minutos.
|
||||
|
||||
## Laboratorio de QA
|
||||
|
||||
El laboratorio de QA tiene lanes de CI dedicadas fuera del workflow principal con alcance inteligente. La paridad agéntica está anidada bajo los arneses amplios de QA y versión, no como un workflow independiente para PR. Usa `Full Release Validation` con `rerun_group=qa-parity` cuando la paridad deba acompañar una ejecución amplia de validación.
|
||||
QA Lab tiene carriles de CI dedicados fuera del flujo de trabajo principal con alcance inteligente. La paridad agéntica está anidada bajo los arneses amplios de QA y versión, no en un flujo de trabajo independiente de PR. Usa `Full Release Validation` con `rerun_group=qa-parity` cuando la paridad deba viajar con una ejecución amplia de validación.
|
||||
|
||||
- El workflow `QA-Lab - All Lanes` se ejecuta cada noche en `main` y con despacho manual; despliega la lane de paridad mock, la lane live de Matrix y las lanes live de Telegram y Discord como jobs paralelos. Los jobs live usan el entorno `qa-live-shared`, y Telegram/Discord usan leases de Convex.
|
||||
- El flujo de trabajo `QA-Lab - All Lanes` se ejecuta cada noche en `main` y por despacho manual; distribuye el carril de paridad mock, el carril Matrix en vivo y los carriles Telegram y Discord en vivo como trabajos paralelos. Los trabajos en vivo usan el entorno `qa-live-shared`, y Telegram/Discord usan leases de Convex.
|
||||
|
||||
Las comprobaciones de versión ejecutan lanes de transporte live de Matrix y Telegram con el proveedor mock determinista y modelos calificados como mock (`mock-openai/gpt-5.5` y `mock-openai/gpt-5.5-alt`) para que el contrato de canal quede aislado de la latencia del modelo live y del inicio normal del Plugin de proveedor. El Gateway de transporte live desactiva la búsqueda de memoria porque la paridad de QA cubre el comportamiento de memoria por separado; la conectividad de proveedor está cubierta por las suites separadas de modelo live, proveedor nativo y proveedor Docker.
|
||||
Las comprobaciones de versión ejecutan carriles de transporte en vivo de Matrix y Telegram con el proveedor mock determinista y modelos calificados para mock (`mock-openai/gpt-5.5` y `mock-openai/gpt-5.5-alt`) para que el contrato de canal quede aislado de la latencia de modelos en vivo y del arranque normal de plugins de proveedor. El gateway de transporte en vivo deshabilita la búsqueda de memoria porque la paridad de QA cubre el comportamiento de memoria por separado; la conectividad de proveedores está cubierta por las suites separadas de modelo en vivo, proveedor nativo y proveedor Docker.
|
||||
|
||||
Matrix usa `--profile fast` para gates programadas y de versión, añadiendo `--fail-fast` solo cuando la CLI obtenida lo admite. El valor predeterminado de la CLI y la entrada manual del workflow siguen siendo `all`; un despacho manual con `matrix_profile=all` siempre divide la cobertura completa de Matrix en los jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` y `e2ee-cli`.
|
||||
Matrix usa `--profile fast` para puertas programadas y de versión, añadiendo `--fail-fast` solo cuando la CLI del checkout lo admite. El valor predeterminado de la CLI y la entrada manual del flujo de trabajo siguen siendo `all`; un despacho manual con `matrix_profile=all` siempre fragmenta la cobertura completa de Matrix en trabajos `transport`, `media`, `e2ee-smoke`, `e2ee-deep` y `e2ee-cli`.
|
||||
|
||||
`OpenClaw Release Checks` también ejecuta las lanes críticas de QA Lab antes de aprobar la versión; su gate de paridad de QA ejecuta los paquetes candidato y de referencia como jobs de lanes paralelos, y luego descarga ambos artefactos en un job de informe pequeño para la comparación final de paridad.
|
||||
`OpenClaw Release Checks` también ejecuta los carriles críticos de versión de QA Lab antes de la aprobación de la versión; su puerta de paridad de QA ejecuta los paquetes candidato y de línea base como trabajos de carril paralelos, luego descarga ambos artefactos en un pequeño trabajo de informe para la comparación final de paridad.
|
||||
|
||||
Para PRs normales, sigue la evidencia de CI/comprobaciones con alcance en lugar de tratar la paridad como un estado requerido.
|
||||
Para PRs normales, sigue la evidencia de CI/comprobación con alcance en lugar de tratar la paridad como un estado obligatorio.
|
||||
|
||||
## CodeQL
|
||||
|
||||
El flujo de trabajo `CodeQL` es intencionadamente un escáner de seguridad estrecho de primera pasada, no el barrido completo del repositorio. Las ejecuciones de protección diarias, manuales y de pull requests no borrador analizan el código de flujos de trabajo de Actions más las superficies JavaScript/TypeScript de mayor riesgo con consultas de seguridad de alta confianza filtradas a `security-severity` alta/crítica.
|
||||
El flujo de trabajo `CodeQL` es intencionalmente un escáner de seguridad inicial de alcance reducido, no el barrido completo del repositorio. Las ejecuciones diarias, manuales y de protección de pull requests que no sean borradores escanean el código de flujos de trabajo de Actions más las superficies JavaScript/TypeScript de mayor riesgo con consultas de seguridad de alta confianza filtradas a `security-severity` alta/crítica.
|
||||
|
||||
La protección de pull requests se mantiene ligera: solo se inicia para cambios en `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` o `src`, y ejecuta la misma matriz de seguridad de alta confianza que el flujo de trabajo programado. Android y macOS CodeQL quedan fuera de los valores predeterminados de PR.
|
||||
La protección de pull requests se mantiene ligera: solo se inicia para cambios bajo `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` o `src`, y ejecuta la misma matriz de seguridad de alta confianza que el flujo de trabajo programado. CodeQL para Android y macOS queda fuera de los valores predeterminados de PR.
|
||||
|
||||
### Categorías de seguridad
|
||||
|
||||
| Categoría | Superficie |
|
||||
| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-security-high/core-auth-secrets` | Línea base de autenticación, secretos, sandbox, cron y gateway |
|
||||
| `/codeql-security-high/channel-runtime-boundary` | Contratos de implementación de canales del núcleo más el runtime de Plugin de canal, gateway, Plugin SDK, secretos y puntos de auditoría |
|
||||
| `/codeql-security-high/network-ssrf-boundary` | Superficies de SSRF del núcleo, análisis de IP, protección de red, web-fetch y política SSRF de Plugin SDK |
|
||||
| `/codeql-security-high/mcp-process-tool-boundary` | Servidores MCP, helpers de ejecución de procesos, entrega saliente y compuertas de ejecución de herramientas de agentes |
|
||||
| `/codeql-security-high/plugin-trust-boundary` | Superficies de confianza de instalación de Plugin, loader, manifest, registry, instalación con package-manager, carga de fuentes y contrato de paquetes de Plugin SDK |
|
||||
| Categoría | Superficie |
|
||||
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-security-high/core-auth-secrets` | Línea base de autenticación, secretos, sandbox, cron y gateway |
|
||||
| `/codeql-security-high/channel-runtime-boundary` | Contratos de implementación de canales principales más el runtime del plugin de canal, gateway, Plugin SDK, secretos y puntos de contacto de auditoría |
|
||||
| `/codeql-security-high/network-ssrf-boundary` | Superficies de SSRF principal, análisis de IP, protección de red, web-fetch y política SSRF del Plugin SDK |
|
||||
| `/codeql-security-high/mcp-process-tool-boundary` | Servidores MCP, helpers de ejecución de procesos, entrega saliente y compuertas de ejecución de herramientas del agente |
|
||||
| `/codeql-security-high/plugin-trust-boundary` | Superficies de confianza de instalación de Plugin, loader, manifest, registry, instalación del package-manager, carga de fuentes y contrato de paquetes del Plugin SDK |
|
||||
|
||||
### Shards de seguridad específicos de plataforma
|
||||
### Fragmentos de seguridad específicos de plataforma
|
||||
|
||||
- `CodeQL Android Critical Security` — shard de seguridad Android programado. Compila la app Android manualmente para CodeQL en el runner Linux de Blacksmith más pequeño aceptado por la comprobación de coherencia del flujo de trabajo. Carga en `/codeql-critical-security/android`.
|
||||
- `CodeQL macOS Critical Security` — shard de seguridad macOS semanal/manual. Compila la app macOS manualmente para CodeQL en Blacksmith macOS, filtra los resultados de compilación de dependencias fuera del SARIF cargado y carga en `/codeql-critical-security/macos`. Se mantiene fuera de los valores predeterminados diarios porque la compilación de macOS domina el tiempo de ejecución incluso cuando está limpia.
|
||||
- `CodeQL Android Critical Security` — fragmento programado de seguridad de Android. Compila manualmente la app de Android para CodeQL en el runner Blacksmith Linux más pequeño aceptado por la validación de cordura del flujo de trabajo. Sube bajo `/codeql-critical-security/android`.
|
||||
- `CodeQL macOS Critical Security` — fragmento semanal/manual de seguridad de macOS. Compila manualmente la app de macOS para CodeQL en Blacksmith macOS, filtra los resultados de compilación de dependencias fuera del SARIF subido y sube bajo `/codeql-critical-security/macos`. Se mantiene fuera de los valores predeterminados diarios porque la compilación de macOS domina el tiempo de ejecución incluso cuando está limpia.
|
||||
|
||||
### Categorías de calidad crítica
|
||||
### Categorías de Critical Quality
|
||||
|
||||
`CodeQL Critical Quality` es el shard correspondiente no relacionado con seguridad. Ejecuta solo consultas de calidad JavaScript/TypeScript de severidad de error y no relacionadas con seguridad sobre superficies estrechas de alto valor en el runner Linux de Blacksmith más pequeño. Su protección de pull requests es intencionadamente más pequeña que el perfil programado: los PR no borrador solo ejecutan los shards correspondientes `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` y `plugin-sdk-reply-runtime` para cambios en código de ejecución de comandos/modelos/herramientas de agente y despacho de respuestas, esquema/migración/IO de configuración, autenticación/secretos/sandbox/seguridad, canal del núcleo y runtime de Plugin de canal incluido, protocolo/método de servidor de gateway, unión de runtime de memoria/SDK, MCP/proceso/entrega saliente, runtime de proveedor/catálogo de modelos, diagnósticos de sesión/colas de entrega, loader de Plugin, Plugin SDK/contrato de paquete o runtime de respuestas de Plugin SDK. Los cambios de configuración de CodeQL y del flujo de trabajo de calidad ejecutan los doce shards de calidad de PR.
|
||||
`CodeQL Critical Quality` es el fragmento equivalente no relacionado con seguridad. Ejecuta solo consultas de calidad JavaScript/TypeScript de severidad de error y no relacionadas con seguridad sobre superficies estrechas de alto valor en el runner Blacksmith Linux más pequeño. Su protección de pull requests es intencionalmente más pequeña que el perfil programado: los PR que no sean borradores solo ejecutan los fragmentos equivalentes `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` y `plugin-sdk-reply-runtime` para cambios en código de ejecución de comandos/modelos/herramientas del agente y despacho de respuestas, código de esquema/migración/IO de configuración, código de autenticación/secretos/sandbox/seguridad, runtime de canales principales y plugins de canal incluidos, protocolo/método de servidor del Gateway, runtime de memoria/glue del SDK, entrega MCP/proceso/saliente, catálogo de modelos/runtime de proveedores, diagnósticos de sesión/colas de entrega, loader de plugins, contrato de Plugin SDK/paquete o runtime de respuestas del Plugin SDK. Los cambios en la configuración de CodeQL y el flujo de trabajo de calidad ejecutan los doce fragmentos de calidad de PR.
|
||||
|
||||
El despacho manual acepta:
|
||||
|
||||
@ -433,40 +433,40 @@ El despacho manual acepta:
|
||||
profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
|
||||
```
|
||||
|
||||
Los perfiles estrechos son hooks de enseñanza/iteración para ejecutar un shard de calidad de forma aislada.
|
||||
Los perfiles estrechos son ganchos de enseñanza/iteración para ejecutar un fragmento de calidad de forma aislada.
|
||||
|
||||
| Categoría | Superficie |
|
||||
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-critical-quality/core-auth-secrets` | Código de límite de seguridad de autenticación, secretos, sandbox, cron y gateway |
|
||||
| `/codeql-critical-quality/config-boundary` | Contratos de esquema de configuración, migración, normalización e IO |
|
||||
| `/codeql-critical-quality/gateway-runtime-boundary` | Esquemas de protocolo de Gateway y contratos de métodos de servidor |
|
||||
| `/codeql-critical-quality/channel-runtime-boundary` | Contratos de implementación de canal del núcleo y Plugin de canal incluido |
|
||||
| `/codeql-critical-quality/agent-runtime-boundary` | Ejecución de comandos, despacho de modelo/proveedor, despacho y colas de respuesta automática, y contratos de runtime del plano de control ACP |
|
||||
| `/codeql-critical-quality/config-boundary` | Esquema de configuración, migración, normalización y contratos de IO |
|
||||
| `/codeql-critical-quality/gateway-runtime-boundary` | Esquemas de protocolo del Gateway y contratos de métodos de servidor |
|
||||
| `/codeql-critical-quality/channel-runtime-boundary` | Contratos de implementación de canales principales y plugins de canal incluidos |
|
||||
| `/codeql-critical-quality/agent-runtime-boundary` | Ejecución de comandos, despacho de modelos/proveedores, despacho y colas de auto-respuesta, y contratos de runtime del plano de control ACP |
|
||||
| `/codeql-critical-quality/mcp-process-runtime-boundary` | Servidores MCP y puentes de herramientas, helpers de supervisión de procesos y contratos de entrega saliente |
|
||||
| `/codeql-critical-quality/memory-runtime-boundary` | SDK del host de memoria, facades del runtime de memoria, alias de Plugin SDK de memoria, unión de activación del runtime de memoria y comandos doctor de memoria |
|
||||
| `/codeql-critical-quality/session-diagnostics-boundary` | Internos de colas de respuesta, colas de entrega de sesión, helpers de vinculación/entrega de sesión saliente, superficies de eventos diagnósticos/paquetes de logs y contratos de CLI doctor de sesión |
|
||||
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Despacho de respuestas entrantes de Plugin SDK, helpers de payload/fragmentación/runtime de respuestas, opciones de respuesta de canal, colas de entrega y helpers de vinculación de sesión/hilo |
|
||||
| `/codeql-critical-quality/provider-runtime-boundary` | Normalización de catálogo de modelos, autenticación y descubrimiento de proveedores, registro de runtime de proveedores, valores predeterminados/catálogos de proveedores y registries de web/búsqueda/fetch/embeddings |
|
||||
| `/codeql-critical-quality/ui-control-plane` | Bootstrap de la UI de control, persistencia local, flujos de control de gateway y contratos de runtime del plano de control de tareas |
|
||||
| `/codeql-critical-quality/web-media-runtime-boundary` | Contratos de runtime de fetch/búsqueda web del núcleo, IO de medios, comprensión de medios, generación de imágenes y generación de medios |
|
||||
| `/codeql-critical-quality/plugin-boundary` | Contratos de loader, registry, superficie pública y punto de entrada de Plugin SDK |
|
||||
| `/codeql-critical-quality/plugin-sdk-package-contract` | Fuente de Plugin SDK del lado del paquete publicado y helpers de contrato de paquete de plugin |
|
||||
| `/codeql-critical-quality/memory-runtime-boundary` | SDK del host de memoria, fachadas del runtime de memoria, alias de memoria del Plugin SDK, glue de activación del runtime de memoria y comandos doctor de memoria |
|
||||
| `/codeql-critical-quality/session-diagnostics-boundary` | Internos de cola de respuestas, colas de entrega de sesiones, helpers de vinculación/entrega de sesiones salientes, superficies de eventos diagnósticos/paquetes de logs y contratos CLI de doctor de sesión |
|
||||
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Despacho de respuestas entrantes del Plugin SDK, helpers de payload/fragmentación/runtime de respuestas, opciones de respuesta de canal, colas de entrega y helpers de vinculación de sesión/hilo |
|
||||
| `/codeql-critical-quality/provider-runtime-boundary` | Normalización del catálogo de modelos, autenticación y descubrimiento de proveedores, registro del runtime de proveedores, valores predeterminados/catálogos de proveedores y registros web/search/fetch/embedding |
|
||||
| `/codeql-critical-quality/ui-control-plane` | Bootstrap de la UI de control, persistencia local, flujos de control del Gateway y contratos de runtime del plano de control de tareas |
|
||||
| `/codeql-critical-quality/web-media-runtime-boundary` | Contratos de runtime de fetch/search web principal, IO de medios, comprensión de medios, generación de imágenes y generación de medios |
|
||||
| `/codeql-critical-quality/plugin-boundary` | Contratos de loader, registry, superficie pública y entrypoint del Plugin SDK |
|
||||
| `/codeql-critical-quality/plugin-sdk-package-contract` | Fuente del Plugin SDK del lado del paquete publicado y helpers de contrato de paquetes de plugins |
|
||||
|
||||
La calidad se mantiene separada de la seguridad para que los hallazgos de calidad puedan programarse, medirse, deshabilitarse o ampliarse sin ocultar la señal de seguridad. La expansión de CodeQL para Swift, Python y plugins incluidos debe volver a añadirse como trabajo posterior acotado o dividido en shards solo después de que los perfiles estrechos tengan runtime y señal estables.
|
||||
La calidad se mantiene separada de la seguridad para que los hallazgos de calidad puedan programarse, medirse, deshabilitarse o expandirse sin oscurecer la señal de seguridad. La expansión de CodeQL para Swift, Python y plugins incluidos debe agregarse de nuevo como trabajo de seguimiento acotado o fragmentado solo después de que los perfiles estrechos tengan tiempo de ejecución y señal estables.
|
||||
|
||||
## Flujos de trabajo de mantenimiento
|
||||
|
||||
### Docs Agent
|
||||
|
||||
El flujo de trabajo `Docs Agent` es un carril de mantenimiento de Codex basado en eventos para mantener la documentación existente alineada con cambios incorporados recientemente. No tiene una programación pura: una ejecución de CI exitosa de push no bot en `main` puede activarlo, y el despacho manual puede ejecutarlo directamente. Las invocaciones de workflow-run se omiten cuando `main` ha avanzado o cuando se creó otra ejecución de Docs Agent no omitida en la última hora. Cuando se ejecuta, revisa el rango de commits desde el SHA de origen anterior de Docs Agent no omitido hasta el `main` actual, de modo que una ejecución por hora puede cubrir todos los cambios de main acumulados desde la última pasada de documentación.
|
||||
El flujo de trabajo `Docs Agent` es una vía de mantenimiento de Codex orientada a eventos para mantener la documentación existente alineada con cambios integrados recientemente. No tiene una programación pura: una ejecución de CI exitosa de push no bot en `main` puede activarlo, y el despacho manual puede ejecutarlo directamente. Las invocaciones por workflow-run se omiten cuando `main` avanzó o cuando otra ejecución no omitida de Docs Agent se creó en la última hora. Cuando se ejecuta, revisa el rango de commits desde el SHA de origen del Docs Agent no omitido anterior hasta el `main` actual, por lo que una ejecución horaria puede cubrir todos los cambios de main acumulados desde la última pasada de docs.
|
||||
|
||||
### Test Performance Agent
|
||||
|
||||
El flujo de trabajo `Test Performance Agent` es un carril de mantenimiento de Codex basado en eventos para pruebas lentas. No tiene una programación pura: una ejecución de CI exitosa de push no bot en `main` puede activarlo, pero se omite si otra invocación workflow-run ya se ejecutó o está en ejecución ese día UTC. El despacho manual evita esa compuerta de actividad diaria. El carril crea un informe de rendimiento Vitest agrupado de la suite completa, permite que Codex haga solo pequeñas correcciones de rendimiento de pruebas que preserven la cobertura en lugar de refactors amplios, luego vuelve a ejecutar el informe de suite completa y rechaza cambios que reduzcan el recuento base de pruebas aprobadas. Si la línea base tiene pruebas fallidas, Codex solo puede corregir fallos obvios y el informe de suite completa posterior al agente debe aprobar antes de que se haga cualquier commit. Cuando `main` avanza antes de que aterrice el push del bot, el carril hace rebase del parche validado, vuelve a ejecutar `pnpm check:changed` y reintenta el push; los parches obsoletos con conflictos se omiten. Usa Ubuntu hospedado por GitHub para que la acción de Codex pueda mantener la misma postura de seguridad drop-sudo que el agente de documentación.
|
||||
El flujo de trabajo `Test Performance Agent` es una vía de mantenimiento de Codex orientada a eventos para pruebas lentas. No tiene una programación pura: una ejecución de CI exitosa de push no bot en `main` puede activarlo, pero se omite si otra invocación por workflow-run ya se ejecutó o está en ejecución ese día UTC. El despacho manual evita esa compuerta de actividad diaria. La vía genera un informe de rendimiento agrupado de Vitest de suite completa, permite que Codex haga solo pequeñas correcciones de rendimiento de pruebas que preserven cobertura en lugar de refactors amplios, luego vuelve a ejecutar el informe de suite completa y rechaza cambios que reduzcan el conteo base de pruebas aprobadas. Si la línea base tiene pruebas fallidas, Codex puede corregir solo fallas obvias y el informe de suite completa posterior al agente debe aprobar antes de que se confirme cualquier cambio. Cuando `main` avanza antes de que llegue el push del bot, la vía rebasea el parche validado, vuelve a ejecutar `pnpm check:changed` y reintenta el push; los parches obsoletos con conflictos se omiten. Usa Ubuntu hospedado en GitHub para que la acción de Codex pueda mantener la misma postura de seguridad drop-sudo que el agente de docs.
|
||||
|
||||
### PR duplicados después del merge
|
||||
|
||||
El flujo de trabajo `Duplicate PRs After Merge` es un flujo de trabajo manual de maintainers para limpieza de duplicados después de aterrizar cambios. De forma predeterminada usa dry-run y solo cierra los PR enumerados explícitamente cuando `apply=true`. Antes de modificar GitHub, verifica que el PR aterrizado esté fusionado y que cada duplicado tenga una issue referenciada compartida o hunks modificados solapados.
|
||||
El flujo de trabajo `Duplicate PRs After Merge` es un flujo de trabajo manual de maintainers para limpieza de duplicados posterior a landing. Por defecto usa dry-run y solo cierra los PR listados explícitamente cuando `apply=true`. Antes de mutar GitHub, verifica que el PR aterrizado esté mergeado y que cada duplicado tenga una issue referenciada compartida o hunks modificados superpuestos.
|
||||
|
||||
```bash
|
||||
gh workflow run duplicate-after-merge.yml \
|
||||
@ -475,29 +475,29 @@ gh workflow run duplicate-after-merge.yml \
|
||||
-f apply=true
|
||||
```
|
||||
|
||||
## Compuertas de comprobación locales y enrutamiento de cambios
|
||||
## Compuertas de verificación local y enrutamiento de cambios
|
||||
|
||||
La lógica local de changed-lane vive en `scripts/changed-lanes.mjs` y la ejecuta `scripts/check-changed.mjs`. Esa compuerta de comprobación local es más estricta con los límites de arquitectura que el alcance amplio de la plataforma de CI:
|
||||
La lógica local de changed-lane vive en `scripts/changed-lanes.mjs` y la ejecuta `scripts/check-changed.mjs`. Esa compuerta de verificación local es más estricta sobre los límites de arquitectura que el alcance amplio de la plataforma CI:
|
||||
|
||||
- los cambios de producción del núcleo ejecutan typecheck de producción del núcleo y pruebas del núcleo más lint/guards del núcleo;
|
||||
- los cambios solo de pruebas del núcleo ejecutan solo typecheck de pruebas del núcleo más lint del núcleo;
|
||||
- los cambios de producción de extensiones ejecutan typecheck de producción de extensiones y pruebas de extensiones más lint de extensiones;
|
||||
- los cambios solo de pruebas de extensiones ejecutan typecheck de pruebas de extensiones más lint de extensiones;
|
||||
- los cambios públicos de Plugin SDK o contrato de plugin se expanden al typecheck de extensiones porque las extensiones dependen de esos contratos del núcleo (los barridos de extensiones de Vitest siguen siendo trabajo de pruebas explícito);
|
||||
- los bumps de versión solo de metadatos de release ejecutan comprobaciones dirigidas de versión/configuración/dependencias raíz;
|
||||
- los cambios desconocidos de raíz/configuración fallan de forma segura hacia todos los carriles de comprobación.
|
||||
- los cambios de producción en core ejecutan typecheck de prod de core y pruebas de core más lint/guards de core;
|
||||
- los cambios solo de pruebas de core ejecutan solo typecheck de pruebas de core más lint de core;
|
||||
- los cambios de producción de extensiones ejecutan typecheck de prod de extensión y pruebas de extensión más lint de extensión;
|
||||
- los cambios solo de pruebas de extensión ejecutan typecheck de pruebas de extensión más lint de extensión;
|
||||
- los cambios públicos del Plugin SDK o del contrato de plugins se expanden al typecheck de extensiones porque las extensiones dependen de esos contratos de core (los barridos de extensiones con Vitest siguen siendo trabajo de pruebas explícito);
|
||||
- los incrementos de versión solo de metadatos de release ejecutan comprobaciones dirigidas de versión/configuración/dependencias raíz;
|
||||
- los cambios desconocidos de raíz/configuración fallan de forma segura hacia todas las vías de comprobación.
|
||||
|
||||
El enrutamiento local de pruebas cambiadas vive en `scripts/test-projects.test-support.mjs` y es intencionadamente más barato que `check:changed`: las ediciones directas de pruebas se ejecutan a sí mismas, las ediciones de código fuente prefieren mapeos explícitos, luego pruebas hermanas y dependientes del grafo de importación. La configuración compartida de entrega de salas de grupo es uno de los mapeos explícitos: los cambios en la configuración de respuesta visible de grupo, el modo de entrega de respuestas de origen o el prompt del sistema de message-tool pasan por las pruebas de respuesta del núcleo más regresiones de entrega de Discord y Slack para que un cambio compartido predeterminado falle antes del primer push de PR. Usa `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` solo cuando el cambio es lo bastante amplio en el harness como para que el conjunto mapeado barato no sea un proxy confiable.
|
||||
El enrutamiento local de pruebas cambiadas vive en `scripts/test-projects.test-support.mjs` y es intencionalmente más barato que `check:changed`: las ediciones directas de pruebas se ejecutan a sí mismas, las ediciones de fuente prefieren mapeos explícitos, luego pruebas hermanas y dependientes del grafo de imports. La configuración compartida de entrega de salas de grupo es uno de los mapeos explícitos: los cambios en la configuración de respuestas visibles para el grupo, el modo de entrega de respuestas de origen o el prompt de sistema de la herramienta de mensajes pasan por las pruebas de respuesta de core más regresiones de entrega de Discord y Slack, para que un cambio predeterminado compartido falle antes del primer push de PR. Usa `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` solo cuando el cambio sea lo bastante amplio en el harness como para que el conjunto barato mapeado no sea un proxy confiable.
|
||||
|
||||
## Validación de Testbox
|
||||
## Validación con Testbox
|
||||
|
||||
Ejecuta Testbox desde la raíz del repositorio y prefiere un entorno recién preparado para una validación amplia. Antes de gastar una comprobación lenta en un entorno reutilizado, caducado o que acaba de informar de una sincronización inesperadamente grande, ejecuta primero `pnpm testbox:sanity` dentro del entorno.
|
||||
Ejecuta Testbox desde la raíz del repositorio y prefiere una caja preparada nueva para una validación amplia. Antes de gastar una verificación lenta en una caja que se reutilizó, expiró o acaba de informar una sincronización inesperadamente grande, ejecuta primero `pnpm testbox:sanity` dentro de la caja.
|
||||
|
||||
La comprobación de cordura falla rápido cuando desaparecen archivos raíz requeridos como `pnpm-lock.yaml` o cuando `git status --short` muestra al menos 200 eliminaciones con seguimiento. Eso normalmente significa que el estado de sincronización remoto no es una copia confiable del PR; detén ese entorno y prepara uno nuevo en lugar de depurar el fallo de prueba del producto. Para PRs con muchas eliminaciones intencionadas, define `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` para esa ejecución de cordura.
|
||||
La comprobación de sanidad falla rápido cuando desaparecieron archivos raíz requeridos como `pnpm-lock.yaml` o cuando `git status --short` muestra al menos 200 eliminaciones rastreadas. Eso suele significar que el estado de sincronización remoto no es una copia confiable del PR; detén esa caja y prepara una nueva en lugar de depurar el fallo de la prueba del producto. Para PRs intencionales con muchas eliminaciones, define `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` para esa ejecución de sanidad.
|
||||
|
||||
`pnpm testbox:run` también termina una invocación local de Blacksmith CLI que permanece en la fase de sincronización durante más de cinco minutos sin salida posterior a la sincronización. Define `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` para desactivar esa protección, o usa un valor mayor en milisegundos para diffs locales inusualmente grandes.
|
||||
`pnpm testbox:run` también termina una invocación local de la CLI de Blacksmith que permanece en la fase de sincronización durante más de cinco minutos sin salida posterior a la sincronización. Define `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` para desactivar esa protección, o usa un valor mayor en milisegundos para diffs locales inusualmente grandes.
|
||||
|
||||
Crabbox es la segunda ruta de entornos remotos propiedad del repositorio para validación en Linux cuando Blacksmith no está disponible o cuando es preferible usar capacidad en la nube propia. Prepara un entorno, hidrátalo mediante el flujo de trabajo del proyecto y luego ejecuta comandos con la CLI de Crabbox:
|
||||
Crabbox es la segunda ruta de cajas remotas propiedad del repositorio para validación en Linux cuando Blacksmith no está disponible o cuando se prefiere capacidad en la nube propia. Prepara una caja, hidrátala mediante el flujo de trabajo del proyecto y luego ejecuta comandos mediante la CLI de Crabbox:
|
||||
|
||||
```bash
|
||||
pnpm crabbox:warmup -- --idle-timeout 90m
|
||||
@ -506,7 +506,7 @@ pnpm crabbox:run -- --id <cbx_id> --shell "OPENCLAW_TESTBOX=1 pnpm check:changed
|
||||
pnpm crabbox:stop -- <cbx_id>
|
||||
```
|
||||
|
||||
`.crabbox.yaml` controla los valores predeterminados de proveedor, sincronización e hidratación de GitHub Actions. Excluye `.git` local para que el checkout hidratado de Actions conserve sus propios metadatos de Git remoto en lugar de sincronizar remotos y almacenes de objetos locales del mantenedor, y excluye artefactos locales de tiempo de ejecución y compilación que nunca deben transferirse. `.github/workflows/crabbox-hydrate.yml` controla el checkout, la configuración de Node/pnpm, la obtención de `origin/main` y el traspaso de entorno no secreto que los comandos posteriores de `crabbox run --id <cbx_id>` cargan como fuente.
|
||||
`.crabbox.yaml` controla los valores predeterminados de proveedor, sincronización e hidratación de GitHub Actions. Excluye `.git` local para que el checkout hidratado de Actions conserve sus propios metadatos Git remotos en lugar de sincronizar remotos y almacenes de objetos locales del mantenedor, y excluye artefactos locales de ejecución/compilación que nunca deberían transferirse. `.github/workflows/crabbox-hydrate.yml` controla el checkout, la configuración de Node/pnpm, la obtención de `origin/main` y el traspaso de entorno no secreto que luego cargan los comandos `crabbox run --id <cbx_id>`.
|
||||
|
||||
## Relacionado
|
||||
|
||||
|
||||
@ -1,36 +1,36 @@
|
||||
---
|
||||
read_when:
|
||||
- Edición del texto del prompt del sistema, la lista de herramientas o las secciones de tiempo/Heartbeat
|
||||
- Cambiar el comportamiento de inicialización del espacio de trabajo o de inyección de Skills
|
||||
- Edición del texto de instrucciones del sistema, la lista de herramientas o las secciones de hora/Heartbeat
|
||||
- Cambiar la inicialización del espacio de trabajo o el comportamiento de inyección de Skills
|
||||
summary: Qué contiene el prompt del sistema de OpenClaw y cómo se ensambla
|
||||
title: Instrucción del sistema
|
||||
title: Prompt del sistema
|
||||
x-i18n:
|
||||
generated_at: "2026-05-02T22:18:06Z"
|
||||
generated_at: "2026-05-02T23:39:13Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 3b8761a8722bb328b937e0832774be7b4e99602ae032c9a255f26843237c110c
|
||||
source_hash: f8e0234453812c16cf5d273096d335049bf435ca76ade36200caf4bb344624e5
|
||||
source_path: concepts/system-prompt.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
OpenClaw construye un prompt de sistema personalizado para cada ejecución de agente. El prompt es **propiedad de OpenClaw** y no usa el prompt predeterminado de pi-coding-agent.
|
||||
OpenClaw construye un prompt del sistema personalizado para cada ejecución de agente. El prompt es **propiedad de OpenClaw** y no usa el prompt predeterminado de pi-coding-agent.
|
||||
|
||||
OpenClaw ensambla el prompt y lo inyecta en cada ejecución de agente.
|
||||
|
||||
Los plugins de proveedor pueden aportar orientación de prompt compatible con caché sin reemplazar
|
||||
todo el prompt propiedad de OpenClaw. El runtime del proveedor puede:
|
||||
|
||||
- reemplazar un conjunto pequeño de secciones core con nombre (`interaction_style`,
|
||||
- reemplazar un conjunto pequeño de secciones centrales con nombre (`interaction_style`,
|
||||
`tool_call_style`, `execution_bias`)
|
||||
- inyectar un **prefijo estable** por encima del límite de caché del prompt
|
||||
- inyectar un **sufijo dinámico** por debajo del límite de caché del prompt
|
||||
|
||||
Usa contribuciones propiedad del proveedor para ajustes específicos de familias de modelos. Mantén la mutación de prompt heredada
|
||||
`before_prompt_build` para compatibilidad o cambios de prompt verdaderamente globales,
|
||||
Usa contribuciones propiedad del proveedor para ajustes específicos por familia de modelos. Mantén la mutación heredada de prompts
|
||||
`before_prompt_build` por compatibilidad o para cambios de prompt verdaderamente globales,
|
||||
no para el comportamiento normal del proveedor.
|
||||
|
||||
La superposición de la familia OpenAI GPT-5 mantiene pequeña la regla de ejecución core y agrega
|
||||
orientación específica del modelo para fijación de personalidad, salida concisa, disciplina de herramientas,
|
||||
La superposición de la familia OpenAI GPT-5 mantiene pequeña la regla central de ejecución y agrega
|
||||
orientación específica del modelo para fijación de persona, salida concisa, disciplina de herramientas,
|
||||
búsqueda paralela, cobertura de entregables, verificación, contexto faltante e
|
||||
higiene de herramientas de terminal.
|
||||
|
||||
@ -39,115 +39,115 @@ higiene de herramientas de terminal.
|
||||
El prompt es intencionalmente compacto y usa secciones fijas:
|
||||
|
||||
- **Herramientas**: recordatorio de fuente de verdad para herramientas estructuradas más orientación de uso de herramientas en runtime.
|
||||
- **Sesgo de ejecución**: orientación compacta de seguimiento: actuar en el turno sobre
|
||||
- **Sesgo de ejecución**: orientación compacta de seguimiento: actuar durante el turno sobre
|
||||
solicitudes accionables, continuar hasta terminar o quedar bloqueado, recuperarse de resultados débiles de herramientas,
|
||||
comprobar en vivo el estado mutable y verificar antes de finalizar.
|
||||
- **Seguridad**: breve recordatorio de límites para evitar comportamiento de búsqueda de poder o eludir supervisión.
|
||||
- **Seguridad**: breve recordatorio de protección para evitar comportamiento de búsqueda de poder o eludir supervisión.
|
||||
- **Skills** (cuando están disponibles): indica al modelo cómo cargar instrucciones de Skills bajo demanda.
|
||||
- **Autoactualización de OpenClaw**: cómo inspeccionar la configuración de forma segura con
|
||||
`config.schema.lookup`, parchear la configuración con `config.patch`, reemplazar la configuración
|
||||
completa con `config.apply` y ejecutar `update.run` solo por solicitud explícita del usuario.
|
||||
La herramienta `gateway`, solo para propietarios, también rechaza reescribir
|
||||
`config.schema.lookup`, parchear la configuración con `config.patch`, reemplazar la configuración completa
|
||||
con `config.apply` y ejecutar `update.run` solo por solicitud explícita del usuario.
|
||||
La herramienta `gateway` solo para propietario también se niega a reescribir
|
||||
`tools.exec.ask` / `tools.exec.security`, incluidos los alias heredados `tools.bash.*`
|
||||
que se normalizan a esas rutas exec protegidas.
|
||||
- **Workspace**: directorio de trabajo (`agents.defaults.workspace`).
|
||||
- **Documentación**: ruta local a la documentación de OpenClaw (repo o paquete npm) y cuándo leerla.
|
||||
- **Archivos de workspace (inyectados)**: indica que los archivos de arranque se incluyen abajo.
|
||||
- **Sandbox** (cuando está habilitado): indica runtime en sandbox, rutas de sandbox y si exec elevado está disponible.
|
||||
que se normalizan a esas rutas protegidas de exec.
|
||||
- **Espacio de trabajo**: directorio de trabajo (`agents.defaults.workspace`).
|
||||
- **Documentación**: ruta local a la documentación de OpenClaw (repositorio o paquete npm) y cuándo leerla.
|
||||
- **Archivos del espacio de trabajo (inyectados)**: indica que los archivos de arranque se incluyen abajo.
|
||||
- **Sandbox** (cuando está habilitado): indica runtime en sandbox, rutas de sandbox y si está disponible exec elevado.
|
||||
- **Fecha y hora actuales**: hora local del usuario, zona horaria y formato de hora.
|
||||
- **Etiquetas de respuesta**: sintaxis opcional de etiquetas de respuesta para proveedores compatibles.
|
||||
- **Heartbeats**: prompt de Heartbeat y comportamiento de confirmación, cuando los Heartbeats están habilitados para el agente predeterminado.
|
||||
- **Runtime**: host, SO, Node, modelo, raíz del repo (cuando se detecta), nivel de pensamiento (una línea).
|
||||
- **Razonamiento**: nivel de visibilidad actual + sugerencia del interruptor /reasoning.
|
||||
- **Runtime**: host, SO, Node, modelo, raíz del repositorio (cuando se detecta), nivel de razonamiento (una línea).
|
||||
- **Razonamiento**: nivel de visibilidad actual + sugerencia del conmutador /reasoning.
|
||||
|
||||
OpenClaw mantiene contenido estable grande, incluido **Contexto del proyecto**, por encima del
|
||||
límite interno de caché del prompt. Las secciones volátiles de canal/sesión, como
|
||||
la orientación de inserción de Control UI, **Mensajería**, **Voz**, **Contexto de chat grupal**,
|
||||
**Reacciones**, **Heartbeats** y **Runtime**, se agregan por debajo de ese límite
|
||||
para que los backends locales con cachés de prefijo puedan reutilizar el prefijo estable del workspace
|
||||
entre turnos de canal. Las descripciones de herramientas también deberían evitar incrustar nombres
|
||||
de canal actuales cuando el esquema aceptado ya lleva ese detalle de runtime.
|
||||
guía de inserción de Control UI, **Mensajería**, **Voz**, **Contexto de chat grupal**,
|
||||
**Reacciones**, **Heartbeats** y **Runtime**, se anexan por debajo de ese límite
|
||||
para que los backends locales con cachés de prefijo puedan reutilizar el prefijo estable del espacio de trabajo
|
||||
entre turnos de canal. Las descripciones de herramientas también deben evitar incrustar nombres de canales actuales
|
||||
cuando el esquema aceptado ya incluye ese detalle de runtime.
|
||||
|
||||
La sección Herramientas también incluye orientación de runtime para trabajo de larga duración:
|
||||
La sección Herramientas también incluye orientación de runtime para trabajos de larga duración:
|
||||
|
||||
- usa Cron para seguimiento futuro (`check back later`, recordatorios, trabajo recurrente)
|
||||
en lugar de bucles de suspensión con `exec`, trucos de demora `yieldMs` o sondeos repetidos de `process`
|
||||
- usa `exec` / `process` solo para comandos que empiezan ahora y siguen ejecutándose
|
||||
- usar cron para seguimiento futuro (`check back later`, recordatorios, trabajo recurrente)
|
||||
en lugar de bucles de suspensión con `exec`, trucos de demora con `yieldMs` o sondeos repetidos de `process`
|
||||
- usar `exec` / `process` solo para comandos que comienzan ahora y continúan ejecutándose
|
||||
en segundo plano
|
||||
- cuando el despertar automático al completar está habilitado, inicia el comando una vez y confía en
|
||||
- cuando la activación automática al completar está habilitada, iniciar el comando una vez y confiar en
|
||||
la ruta de activación basada en push cuando emita salida o falle
|
||||
- usa `process` para logs, estado, entrada o intervención cuando necesites
|
||||
- usar `process` para registros, estado, entrada o intervención cuando necesites
|
||||
inspeccionar un comando en ejecución
|
||||
- si la tarea es más grande, prefiere `sessions_spawn`; la finalización de subagentes está
|
||||
basada en push y se anuncia automáticamente de vuelta al solicitante
|
||||
- no sondees `subagents list` / `sessions_list` en un bucle solo para esperar
|
||||
la finalización
|
||||
- si la tarea es más grande, preferir `sessions_spawn`; la finalización del subagente se
|
||||
basa en push y se anuncia automáticamente al solicitante
|
||||
- no sondear `subagents list` / `sessions_list` en un bucle solo para esperar la
|
||||
finalización
|
||||
|
||||
Cuando la herramienta experimental `update_plan` está habilitada, Herramientas también indica al
|
||||
modelo que la use solo para trabajo no trivial de varios pasos, que mantenga exactamente un paso
|
||||
modelo que la use solo para trabajos no triviales de varios pasos, que mantenga exactamente un paso
|
||||
`in_progress` y que evite repetir todo el plan después de cada actualización.
|
||||
|
||||
Los límites de seguridad del prompt de sistema son orientativos. Guían el comportamiento del modelo, pero no aplican políticas. Usa políticas de herramientas, aprobaciones de exec, sandboxing y listas de permisos de canales para una aplicación estricta; los operadores pueden deshabilitarlos por diseño.
|
||||
Las protecciones de seguridad en el prompt del sistema son orientativas. Guían el comportamiento del modelo, pero no aplican políticas. Usa políticas de herramientas, aprobaciones de exec, sandboxing y listas de canales permitidos para una aplicación estricta; los operadores pueden deshabilitarlas por diseño.
|
||||
|
||||
En canales con tarjetas/botones de aprobación nativos, el prompt de runtime ahora indica al
|
||||
agente que confíe primero en esa UI de aprobación nativa. Solo debería incluir un comando manual
|
||||
agente que confíe primero en esa interfaz de aprobación nativa. Solo debe incluir un comando manual
|
||||
`/approve` cuando el resultado de la herramienta diga que las aprobaciones por chat no están disponibles o que
|
||||
la aprobación manual es la única ruta.
|
||||
la aprobación manual es la única vía.
|
||||
|
||||
## Modos de prompt
|
||||
|
||||
OpenClaw puede renderizar prompts de sistema más pequeños para subagentes. El runtime establece un
|
||||
OpenClaw puede renderizar prompts del sistema más pequeños para subagentes. El runtime establece un
|
||||
`promptMode` para cada ejecución (no es una configuración visible para el usuario):
|
||||
|
||||
- `full` (predeterminado): incluye todas las secciones anteriores.
|
||||
- `minimal`: usado para subagentes; omite **Skills**, **Recuperación de memoria**, **Autoactualización de OpenClaw**,
|
||||
**Alias de modelo**, **Identidad de usuario**, **Etiquetas de respuesta**,
|
||||
- `minimal`: se usa para subagentes; omite **Skills**, **Recuperación de memoria**, **Autoactualización de OpenClaw
|
||||
Self-Update**, **Alias de modelos**, **Identidad del usuario**, **Etiquetas de respuesta**,
|
||||
**Mensajería**, **Respuestas silenciosas** y **Heartbeats**. Herramientas, **Seguridad**,
|
||||
Workspace, Sandbox, Fecha y hora actuales (cuando se conocen), Runtime y el contexto
|
||||
inyectado siguen disponibles.
|
||||
- `none`: devuelve solo la línea base de identidad.
|
||||
Espacio de trabajo, Sandbox, Fecha y hora actuales (cuando se conocen), Runtime y el contexto
|
||||
inyectado permanecen disponibles.
|
||||
- `none`: devuelve solo la línea de identidad base.
|
||||
|
||||
Cuando `promptMode=minimal`, los prompts adicionales inyectados se etiquetan como **Contexto de subagente**
|
||||
Cuando `promptMode=minimal`, los prompts inyectados adicionales se etiquetan como **Contexto de subagente**
|
||||
en lugar de **Contexto de chat grupal**.
|
||||
|
||||
Para ejecuciones de respuesta automática de canal, OpenClaw puede omitir la sección genérica **Respuestas silenciosas**
|
||||
cuando el contexto de chat directo/grupal ya incluye el comportamiento `NO_REPLY`
|
||||
específico de la conversación resuelta. Esto evita repetir mecánicas de tokens
|
||||
tanto en el prompt de sistema global como en el contexto del canal.
|
||||
específico de la conversación resuelto. Esto evita repetir la mecánica de tokens
|
||||
tanto en el prompt global del sistema como en el contexto del canal.
|
||||
|
||||
## Snapshots de prompt
|
||||
## Instantáneas de prompt
|
||||
|
||||
OpenClaw mantiene snapshots de prompt confirmados para la ruta correcta del runtime Codex/message-tool
|
||||
en `test/fixtures/agents/prompt-snapshots/happy-path/`. Renderizan
|
||||
parámetros seleccionados de hilo/turno del app-server más una pila reconstruida de capas de prompt vinculadas al modelo
|
||||
para turnos directos de Telegram, grupales de Discord y Heartbeat. Esa pila
|
||||
incluye una fixture fijada de prompt del modelo Codex `gpt-5.5` generada a partir de la forma del catálogo/caché
|
||||
de modelos de Codex, el texto de desarrollador de permisos de ruta correcta de Codex,
|
||||
instrucciones de desarrollador de OpenClaw, entrada del turno del usuario y referencias a las especificaciones dinámicas
|
||||
OpenClaw mantiene instantáneas de prompt confirmadas para la ruta feliz del runtime de Codex bajo
|
||||
`test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/`. Renderizan
|
||||
parámetros seleccionados de hilo/turno del servidor de aplicaciones más una pila reconstruida de capas de prompt vinculadas al modelo
|
||||
para turnos directos de Telegram, grupales de Discord y de Heartbeat. Esa pila
|
||||
incluye un fixture de prompt de modelo Codex `gpt-5.5` fijado generado a partir de la forma del
|
||||
catálogo/caché de modelos de Codex, el texto de desarrollador de permisos de ruta feliz de Codex,
|
||||
instrucciones de desarrollador de OpenClaw, entrada de turno del usuario y referencias a las especificaciones dinámicas
|
||||
de herramientas.
|
||||
|
||||
Actualiza la fixture fijada de prompt del modelo Codex con
|
||||
`pnpm prompt:snapshots:sync-codex-model`. De forma predeterminada, el script busca
|
||||
la caché de runtime de Codex en `$CODEX_HOME/models_cache.json`, luego
|
||||
`~/.codex/models_cache.json`, y solo entonces recurre a la convención del checkout Codex
|
||||
del mantenedor en `~/code/codex/codex-rs/models-manager/models.json`. Si
|
||||
ninguna de esas fuentes existe, el comando sale sin cambiar la fixture confirmada.
|
||||
Pasa `--catalog <path>` para actualizar desde un archivo `models_cache.json`
|
||||
Actualiza el fixture fijado de prompt de modelo Codex con
|
||||
`pnpm prompt:snapshots:sync-codex-model`. De forma predeterminada, el script busca la
|
||||
caché de runtime de Codex en `$CODEX_HOME/models_cache.json`, luego
|
||||
`~/.codex/models_cache.json` y solo después recurre a la convención del checkout de Codex del mantenedor
|
||||
en `~/code/codex/codex-rs/models-manager/models.json`. Si
|
||||
ninguna de esas fuentes existe, el comando sale sin cambiar el fixture
|
||||
confirmado. Pasa `--catalog <path>` para actualizar desde un archivo `models_cache.json`
|
||||
o `models.json` específico.
|
||||
|
||||
Estos snapshots todavía no son una captura byte por byte de una solicitud OpenAI sin procesar. Codex
|
||||
puede agregar contexto de workspace propiedad del runtime, como `AGENTS.md`, contexto de entorno,
|
||||
memorias, instrucciones de app/plugin y futuras instrucciones de modo de colaboración
|
||||
dentro del runtime de Codex después de que OpenClaw envíe los parámetros de hilo y turno.
|
||||
Estas instantáneas aún no son una captura sin procesar byte por byte de una solicitud de OpenAI. Codex
|
||||
puede agregar contexto de espacio de trabajo propiedad del runtime, como `AGENTS.md`, contexto de entorno,
|
||||
memorias, instrucciones de aplicaciones/plugins e instrucciones futuras de modo de colaboración
|
||||
dentro del runtime de Codex después de que OpenClaw envía parámetros de hilo y turno.
|
||||
|
||||
Regénéralos con `pnpm prompt:snapshots:gen` y verifica la deriva con
|
||||
`pnpm prompt:snapshots:check`. CI ejecuta la comprobación de deriva en el shard
|
||||
adicional de límite para que los cambios de prompt y las actualizaciones de snapshots permanezcan adjuntos al mismo
|
||||
Regénéralas con `pnpm prompt:snapshots:gen` y verifica la deriva con
|
||||
`pnpm prompt:snapshots:check`. CI ejecuta la comprobación de deriva en el shard adicional
|
||||
de límites para que los cambios de prompt y las actualizaciones de instantáneas permanezcan adjuntos al mismo
|
||||
PR.
|
||||
|
||||
## Inyección de arranque del workspace
|
||||
## Inyección de arranque del espacio de trabajo
|
||||
|
||||
Los archivos de arranque se recortan y se agregan bajo **Contexto del proyecto** para que el modelo vea contexto de identidad y perfil sin necesitar lecturas explícitas:
|
||||
Los archivos de arranque se recortan y anexan bajo **Contexto del proyecto** para que el modelo vea el contexto de identidad y perfil sin necesitar lecturas explícitas:
|
||||
|
||||
- `AGENTS.md`
|
||||
- `SOUL.md`
|
||||
@ -155,25 +155,32 @@ Los archivos de arranque se recortan y se agregan bajo **Contexto del proyecto**
|
||||
- `IDENTITY.md`
|
||||
- `USER.md`
|
||||
- `HEARTBEAT.md`
|
||||
- `BOOTSTRAP.md` (solo en workspaces completamente nuevos)
|
||||
- `MEMORY.md` cuando esté presente
|
||||
- `BOOTSTRAP.md` (solo en espacios de trabajo completamente nuevos)
|
||||
- `MEMORY.md` cuando está presente
|
||||
|
||||
Todos estos archivos se **inyectan en la ventana de contexto** en cada turno salvo que
|
||||
Todos estos archivos se **inyectan en la ventana de contexto** en cada turno, a menos que
|
||||
se aplique una compuerta específica del archivo. `HEARTBEAT.md` se omite en ejecuciones normales cuando
|
||||
los Heartbeats están deshabilitados para el agente predeterminado o
|
||||
`agents.defaults.heartbeat.includeSystemPromptSection` es false. Mantén concisos los archivos
|
||||
inyectados, especialmente `MEMORY.md`, que puede crecer con el tiempo y provocar
|
||||
`agents.defaults.heartbeat.includeSystemPromptSection` es falso. Mantén los archivos inyectados
|
||||
concisos, especialmente `MEMORY.md`, que puede crecer con el tiempo y provocar
|
||||
un uso de contexto inesperadamente alto y Compaction más frecuente.
|
||||
|
||||
Cuando una sesión se ejecuta en el arnés nativo de Codex, Codex carga `AGENTS.md`
|
||||
mediante su propio descubrimiento de documentos de proyecto. OpenClaw aún resuelve los demás
|
||||
archivos de arranque y los reenvía como instrucciones de configuración de Codex, de modo que `SOUL.md`,
|
||||
`TOOLS.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md`, `BOOTSTRAP.md` y
|
||||
`MEMORY.md` conservan el mismo rol de contexto del espacio de trabajo sin duplicar
|
||||
`AGENTS.md`.
|
||||
|
||||
<Note>
|
||||
Los archivos diarios `memory/*.md` **no** forman parte del Contexto del proyecto de arranque normal. En turnos ordinarios se accede a ellos bajo demanda mediante las herramientas `memory_search` y `memory_get`, por lo que no cuentan contra la ventana de contexto salvo que el modelo los lea explícitamente. Los turnos simples `/new` y `/reset` son la excepción: el runtime puede anteponer memoria diaria reciente como un bloque de contexto inicial de un solo uso para ese primer turno.
|
||||
Los archivos diarios `memory/*.md` **no** forman parte del Contexto del proyecto de arranque normal. En turnos ordinarios se accede a ellos bajo demanda mediante las herramientas `memory_search` y `memory_get`, por lo que no cuentan contra la ventana de contexto a menos que el modelo los lea explícitamente. Los turnos `/new` y `/reset` desnudos son la excepción: el runtime puede anteponer memoria diaria reciente como bloque único de contexto de inicio para ese primer turno.
|
||||
</Note>
|
||||
|
||||
Los archivos grandes se truncan con un marcador. El tamaño máximo por archivo se controla mediante
|
||||
Los archivos grandes se truncan con un marcador. El tamaño máximo por archivo se controla con
|
||||
`agents.defaults.bootstrapMaxChars` (predeterminado: 12000). El contenido total de arranque inyectado
|
||||
entre archivos está limitado por `agents.defaults.bootstrapTotalMaxChars`
|
||||
(predeterminado: 60000). Los archivos faltantes inyectan un breve marcador de archivo faltante. Cuando se produce truncamiento,
|
||||
OpenClaw puede inyectar un bloque de advertencia en Contexto del proyecto; contrólalo con
|
||||
(predeterminado: 60000). Los archivos faltantes inyectan un marcador breve de archivo faltante. Cuando se produce truncamiento,
|
||||
OpenClaw puede inyectar un bloque de advertencia en Contexto del proyecto; controla esto con
|
||||
`agents.defaults.bootstrapPromptTruncationWarning` (`off`, `once`, `always`;
|
||||
predeterminado: `once`).
|
||||
|
||||
@ -181,40 +188,40 @@ Las sesiones de subagente solo inyectan `AGENTS.md` y `TOOLS.md` (los demás arc
|
||||
se filtran para mantener pequeño el contexto del subagente).
|
||||
|
||||
Los hooks internos pueden interceptar este paso mediante `agent:bootstrap` para mutar o reemplazar
|
||||
los archivos de arranque inyectados (por ejemplo, intercambiar `SOUL.md` por una personalidad alternativa).
|
||||
los archivos de arranque inyectados (por ejemplo, cambiar `SOUL.md` por una persona alternativa).
|
||||
|
||||
Si quieres que el agente suene menos genérico, empieza con
|
||||
[Guía de personalidad de SOUL.md](/es/concepts/soul).
|
||||
|
||||
Para inspeccionar cuánto aporta cada archivo inyectado (sin procesar frente a inyectado, truncamiento, más sobrecarga del esquema de herramientas), usa `/context list` o `/context detail`. Consulta [Contexto](/es/concepts/context).
|
||||
Para inspeccionar cuánto aporta cada archivo inyectado (bruto frente a inyectado, truncamiento, más sobrecarga del esquema de herramientas), usa `/context list` o `/context detail`. Consulta [Contexto](/es/concepts/context).
|
||||
|
||||
## Manejo del tiempo
|
||||
|
||||
El prompt de sistema incluye una sección dedicada **Fecha y hora actuales** cuando se conoce
|
||||
la zona horaria del usuario. Para mantener estable la caché del prompt, ahora solo incluye
|
||||
El prompt del sistema incluye una sección dedicada **Fecha y hora actuales** cuando se
|
||||
conoce la zona horaria del usuario. Para mantener estable la caché del prompt, ahora solo incluye
|
||||
la **zona horaria** (sin reloj dinámico ni formato de hora).
|
||||
|
||||
Usa `session_status` cuando el agente necesite la hora actual; la tarjeta de estado
|
||||
incluye una línea de marca de tiempo. La misma herramienta puede establecer opcionalmente una anulación de modelo
|
||||
por sesión (`model=default` la borra).
|
||||
incluye una línea de marca de tiempo. La misma herramienta puede establecer opcionalmente una anulación de modelo por sesión
|
||||
(`model=default` la borra).
|
||||
|
||||
Configura con:
|
||||
|
||||
- `agents.defaults.userTimezone`
|
||||
- `agents.defaults.timeFormat` (`auto` | `12` | `24`)
|
||||
|
||||
Consulta [Fecha y hora](/es/date-time) para ver todos los detalles del comportamiento.
|
||||
Consulta [Fecha y hora](/es/date-time) para ver los detalles completos de comportamiento.
|
||||
|
||||
## Skills
|
||||
|
||||
Cuando existen Skills elegibles, OpenClaw inyecta una **lista compacta de Skills disponibles**
|
||||
Cuando existen Skills elegibles, OpenClaw inyecta una **lista de Skills disponibles** compacta
|
||||
(`formatSkillsForPrompt`) que incluye la **ruta de archivo** de cada Skill. El
|
||||
prompt indica al modelo que use `read` para cargar el SKILL.md en la ubicación
|
||||
indicada (workspace, administrada o incluida). Si no hay Skills elegibles, se omite
|
||||
la sección Skills.
|
||||
indicada (espacio de trabajo, administrada o incluida). Si no hay Skills elegibles, la
|
||||
sección Skills se omite.
|
||||
|
||||
La elegibilidad incluye compuertas de metadatos de Skills, comprobaciones de entorno/configuración de runtime
|
||||
y la lista efectiva de Skills permitidas para el agente cuando `agents.defaults.skills` o
|
||||
y la lista efectiva de Skills permitidas del agente cuando `agents.defaults.skills` o
|
||||
`agents.list[].skills` está configurado.
|
||||
|
||||
Las Skills incluidas por plugins son elegibles solo cuando su plugin propietario está habilitado.
|
||||
@ -231,7 +238,7 @@ esa orientación directamente en cada descripción de herramienta.
|
||||
</available_skills>
|
||||
```
|
||||
|
||||
Esto mantiene pequeño el prompt base y a la vez habilita el uso dirigido de Skills.
|
||||
Esto mantiene pequeño el prompt base y, al mismo tiempo, permite el uso dirigido de Skills.
|
||||
|
||||
El presupuesto de la lista de Skills pertenece al subsistema de Skills:
|
||||
|
||||
@ -243,17 +250,16 @@ Los extractos genéricos acotados de runtime usan una superficie diferente:
|
||||
- `agents.defaults.contextLimits.*`
|
||||
- `agents.list[].contextLimits.*`
|
||||
|
||||
Esa separación mantiene el dimensionamiento de Skills separado del dimensionamiento de lectura/inyección de runtime, como
|
||||
`memory_get`, resultados de herramientas en vivo y actualizaciones de AGENTS.md posteriores a Compaction.
|
||||
Esa división mantiene el dimensionamiento de Skills separado del dimensionamiento de lectura/inyección en tiempo de ejecución, como `memory_get`, los resultados de herramientas en vivo y las actualizaciones de AGENTS.md posteriores a Compaction.
|
||||
|
||||
## Documentación
|
||||
|
||||
El prompt del sistema incluye una sección de **Documentación**. Cuando hay documentación local disponible, apunta al directorio local de documentación de OpenClaw (`docs/` en una copia de trabajo de Git o la documentación incluida en el paquete npm). Si la documentación local no está disponible, recurre a [https://docs.openclaw.ai](https://docs.openclaw.ai).
|
||||
El prompt del sistema incluye una sección de **Documentación**. Cuando la documentación local está disponible, apunta al directorio local de documentación de OpenClaw (`docs/` en un checkout de Git o la documentación incluida en el paquete npm). Si la documentación local no está disponible, recurre a [https://docs.openclaw.ai](https://docs.openclaw.ai).
|
||||
|
||||
La misma sección también incluye la ubicación del código fuente de OpenClaw. Las copias de trabajo de Git exponen la raíz del código fuente local para que el agente pueda inspeccionar el código directamente. Las instalaciones de paquetes incluyen la URL del código fuente en GitHub e indican al agente que revise el código fuente allí cuando la documentación esté incompleta o desactualizada. El prompt también señala el espejo público de la documentación, el Discord de la comunidad y ClawHub ([https://clawhub.ai](https://clawhub.ai)) para descubrir Skills. Indica al modelo que consulte primero la documentación para el comportamiento, los comandos, la configuración o la arquitectura de OpenClaw, y que ejecute `openclaw status` por sí mismo cuando sea posible (preguntando al usuario solo cuando no tenga acceso). En concreto para la configuración, dirige a los agentes a la acción de herramienta `gateway` `config.schema.lookup` para obtener documentación y restricciones exactas a nivel de campo, y luego a `docs/gateway/configuration.md` y `docs/gateway/configuration-reference.md` para obtener orientación más amplia.
|
||||
La misma sección también incluye la ubicación del código fuente de OpenClaw. Los checkouts de Git exponen la raíz del código fuente local para que el agente pueda inspeccionar el código directamente. Las instalaciones de paquetes incluyen la URL del código fuente en GitHub e indican al agente que revise el código fuente allí cuando la documentación esté incompleta o desactualizada. El prompt también menciona el espejo público de la documentación, el Discord de la comunidad y ClawHub ([https://clawhub.ai](https://clawhub.ai)) para el descubrimiento de Skills. Indica al modelo que consulte primero la documentación para el comportamiento, los comandos, la configuración o la arquitectura de OpenClaw, y que ejecute `openclaw status` por sí mismo cuando sea posible (preguntando al usuario solo cuando no tenga acceso). Específicamente para la configuración, dirige a los agentes a la acción de herramienta `gateway` `config.schema.lookup` para obtener documentación y restricciones exactas a nivel de campo, y luego a `docs/gateway/configuration.md` y `docs/gateway/configuration-reference.md` para orientación más amplia.
|
||||
|
||||
## Relacionado
|
||||
|
||||
- [Entorno de ejecución del agente](/es/concepts/agent)
|
||||
- [Área de trabajo del agente](/es/concepts/agent-workspace)
|
||||
- [Tiempo de ejecución del agente](/es/concepts/agent)
|
||||
- [Espacio de trabajo del agente](/es/concepts/agent-workspace)
|
||||
- [Motor de contexto](/es/concepts/context-engine)
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
---
|
||||
read_when:
|
||||
- Cambiar la transcripción de audio o el manejo de medios
|
||||
summary: Cómo se descargan, transcriben e inyectan en las respuestas el audio y las notas de voz entrantes
|
||||
- Cambiar la transcripción de audio o la gestión de medios
|
||||
summary: Cómo se descargan, transcriben e insertan en las respuestas las notas de audio/voz entrantes
|
||||
title: Audio y notas de voz
|
||||
x-i18n:
|
||||
generated_at: "2026-04-30T05:49:12Z"
|
||||
generated_at: "2026-05-02T23:39:02Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 35074d79104f767ee252064462202a8ec21ac26f6db25c39e67f31f6b40edeb7
|
||||
source_hash: 91cd6951f80c6137061a7d4e82415b0872bc92c6d6ad136273a2e9ad7ec00ac1
|
||||
source_path: nodes/audio.md
|
||||
workflow: 16
|
||||
---
|
||||
@ -17,36 +17,37 @@ x-i18n:
|
||||
## Qué funciona
|
||||
|
||||
- **Comprensión de medios (audio)**: Si la comprensión de audio está habilitada (o se detecta automáticamente), OpenClaw:
|
||||
1. Localiza el primer archivo adjunto de audio (ruta local o URL) y lo descarga si es necesario.
|
||||
1. Localiza el primer adjunto de audio (ruta local o URL) y lo descarga si es necesario.
|
||||
2. Aplica `maxBytes` antes de enviarlo a cada entrada de modelo.
|
||||
3. Ejecuta la primera entrada de modelo apta en orden (proveedor o CLI).
|
||||
4. Si falla o se omite (tamaño/tiempo de espera), prueba la siguiente entrada.
|
||||
5. Si tiene éxito, reemplaza `Body` por un bloque `[Audio]` y establece `{{Transcript}}`.
|
||||
- **Análisis de comandos**: Cuando la transcripción se realiza correctamente, `CommandBody`/`RawBody` se establecen en la transcripción para que los comandos de barra diagonal sigan funcionando.
|
||||
- **Análisis de comandos**: Cuando la transcripción se realiza correctamente, `CommandBody`/`RawBody` se establecen en la transcripción para que los comandos de barra sigan funcionando.
|
||||
- **Registro detallado**: En `--verbose`, registramos cuándo se ejecuta la transcripción y cuándo reemplaza el cuerpo.
|
||||
- **Dictado en la interfaz de control**: El compositor de Chat puede enviar un clip de micrófono grabado por el navegador a `chat.transcribeAudio`. Ese RPC de Gateway escribe el clip en un archivo local temporal, ejecuta esta misma canalización de transcripción de audio, devuelve texto de borrador al navegador y elimina el archivo temporal. No crea por sí solo una ejecución de agente.
|
||||
|
||||
## Detección automática (predeterminada)
|
||||
## Detección automática (predeterminado)
|
||||
|
||||
Si **no configuras modelos** y `tools.media.audio.enabled` **no** está establecido en `false`,
|
||||
OpenClaw detecta automáticamente en este orden y se detiene en la primera opción que funcione:
|
||||
|
||||
1. **Modelo de respuesta activo** cuando su proveedor admite comprensión de audio.
|
||||
2. **CLI locales** (si están instaladas)
|
||||
- `sherpa-onnx-offline` (requiere `SHERPA_ONNX_MODEL_DIR` con encoder/decoder/joiner/tokens)
|
||||
- `sherpa-onnx-offline` (requiere `SHERPA_ONNX_MODEL_DIR` con codificador/decodificador/unidor/tokens)
|
||||
- `whisper-cli` (de `whisper-cpp`; usa `WHISPER_CPP_MODEL` o el modelo tiny incluido)
|
||||
- `whisper` (CLI de Python; descarga modelos automáticamente)
|
||||
3. **CLI de Gemini** (`gemini`) usando `read_many_files`
|
||||
4. **Autenticación del proveedor**
|
||||
- Las entradas configuradas en `models.providers.*` que admiten audio se prueban primero
|
||||
4. **Autenticación de proveedor**
|
||||
- Primero se prueban las entradas `models.providers.*` configuradas que admiten audio
|
||||
- Orden de respaldo incluido: OpenAI → Groq → xAI → Deepgram → Google → SenseAudio → ElevenLabs → Mistral
|
||||
|
||||
Para desactivar la detección automática, establece `tools.media.audio.enabled: false`.
|
||||
Para deshabilitar la detección automática, establece `tools.media.audio.enabled: false`.
|
||||
Para personalizarla, establece `tools.media.audio.models`.
|
||||
Nota: La detección de binarios es de mejor esfuerzo en macOS/Linux/Windows; asegúrate de que la CLI esté en `PATH` (expandimos `~`) o establece un modelo de CLI explícito con una ruta de comando completa.
|
||||
Nota: La detección de binarios es de mejor esfuerzo en macOS/Linux/Windows; asegúrate de que la CLI esté en `PATH` (expandimos `~`), o establece un modelo de CLI explícito con una ruta completa de comando.
|
||||
|
||||
## Ejemplos de configuración
|
||||
|
||||
### Respaldo de proveedor + CLI (OpenAI + CLI de Whisper)
|
||||
### Proveedor + respaldo de CLI (OpenAI + Whisper CLI)
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -70,7 +71,7 @@ Nota: La detección de binarios es de mejor esfuerzo en macOS/Linux/Windows; ase
|
||||
}
|
||||
```
|
||||
|
||||
### Solo proveedor con control por alcance
|
||||
### Solo proveedor con limitación por alcance
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -153,28 +154,28 @@ Nota: La detección de binarios es de mejor esfuerzo en macOS/Linux/Windows; ase
|
||||
|
||||
## Notas y límites
|
||||
|
||||
- La autenticación del proveedor sigue el orden estándar de autenticación de modelos (perfiles de autenticación, variables de entorno, `models.providers.*.apiKey`).
|
||||
- La autenticación de proveedor sigue el orden de autenticación de modelo estándar (perfiles de autenticación, variables de entorno, `models.providers.*.apiKey`).
|
||||
- Detalles de configuración de Groq: [Groq](/es/providers/groq).
|
||||
- Deepgram recoge `DEEPGRAM_API_KEY` cuando se usa `provider: "deepgram"`.
|
||||
- Deepgram detecta `DEEPGRAM_API_KEY` cuando se usa `provider: "deepgram"`.
|
||||
- Detalles de configuración de Deepgram: [Deepgram (transcripción de audio)](/es/providers/deepgram).
|
||||
- Detalles de configuración de Mistral: [Mistral](/es/providers/mistral).
|
||||
- SenseAudio recoge `SENSEAUDIO_API_KEY` cuando se usa `provider: "senseaudio"`.
|
||||
- SenseAudio detecta `SENSEAUDIO_API_KEY` cuando se usa `provider: "senseaudio"`.
|
||||
- Detalles de configuración de SenseAudio: [SenseAudio](/es/providers/senseaudio).
|
||||
- Los proveedores de audio pueden sobrescribir `baseUrl`, `headers` y `providerOptions` mediante `tools.media.audio`.
|
||||
- El límite de tamaño predeterminado es 20 MB (`tools.media.audio.maxBytes`). El audio que excede el tamaño se omite para ese modelo y se prueba la siguiente entrada.
|
||||
- Los archivos de audio diminutos/vacíos por debajo de 1024 bytes se omiten antes de la transcripción mediante proveedor/CLI.
|
||||
- El valor predeterminado de `maxChars` para audio **no está establecido** (transcripción completa). Establece `tools.media.audio.maxChars` o `maxChars` por entrada para recortar la salida.
|
||||
- El valor automático predeterminado de OpenAI es `gpt-4o-mini-transcribe`; establece `model: "gpt-4o-transcribe"` para mayor precisión.
|
||||
- El límite de tamaño predeterminado es 20 MB (`tools.media.audio.maxBytes`). El audio demasiado grande se omite para ese modelo y se prueba la siguiente entrada.
|
||||
- Los archivos de audio diminutos/vacíos de menos de 1024 bytes se omiten antes de la transcripción por proveedor/CLI.
|
||||
- El `maxChars` predeterminado para audio **no está definido** (transcripción completa). Establece `tools.media.audio.maxChars` o `maxChars` por entrada para recortar la salida.
|
||||
- El valor predeterminado automático de OpenAI es `gpt-4o-mini-transcribe`; establece `model: "gpt-4o-transcribe"` para mayor precisión.
|
||||
- Usa `tools.media.audio.attachments` para procesar varias notas de voz (`mode: "all"` + `maxAttachments`).
|
||||
- La transcripción está disponible para las plantillas como `{{Transcript}}`.
|
||||
- `tools.media.audio.echoTranscript` está desactivado de forma predeterminada; habilítalo para enviar una confirmación de la transcripción al chat de origen antes del procesamiento del agente.
|
||||
- La transcripción está disponible para plantillas como `{{Transcript}}`.
|
||||
- `tools.media.audio.echoTranscript` está desactivado de forma predeterminada; habilítalo para enviar una confirmación de transcripción de vuelta al chat de origen antes del procesamiento del agente.
|
||||
- `tools.media.audio.echoFormat` personaliza el texto de repetición (marcador de posición: `{transcript}`).
|
||||
- La salida estándar de la CLI tiene un límite (5 MB); mantén la salida de la CLI concisa.
|
||||
- Los `args` de CLI deben usar `{{MediaPath}}` para la ruta del archivo de audio local. Ejecuta `openclaw doctor --fix` para migrar los marcadores de posición obsoletos `{input}` de configuraciones antiguas de `audio.transcription.command`.
|
||||
- La salida stdout de la CLI está limitada (5 MB); mantén la salida de la CLI concisa.
|
||||
- Los `args` de la CLI deben usar `{{MediaPath}}` para la ruta local del archivo de audio. Ejecuta `openclaw doctor --fix` para migrar los marcadores de posición `{input}` obsoletos de configuraciones antiguas de `audio.transcription.command`.
|
||||
|
||||
### Compatibilidad con entorno de proxy
|
||||
### Compatibilidad con entorno proxy
|
||||
|
||||
La transcripción de audio basada en proveedor respeta las variables de entorno estándar de proxy saliente:
|
||||
La transcripción de audio basada en proveedor respeta las variables de entorno de proxy saliente estándar:
|
||||
|
||||
- `HTTPS_PROXY`
|
||||
- `HTTP_PROXY`
|
||||
@ -183,7 +184,7 @@ La transcripción de audio basada en proveedor respeta las variables de entorno
|
||||
- `http_proxy`
|
||||
- `all_proxy`
|
||||
|
||||
Si no se establecen variables de entorno de proxy, se usa salida directa. Si la configuración del proxy está mal formada, OpenClaw registra una advertencia y vuelve a la obtención directa.
|
||||
Si no hay variables de entorno de proxy establecidas, se usa la salida directa. Si la configuración de proxy tiene un formato incorrecto, OpenClaw registra una advertencia y vuelve a la obtención directa.
|
||||
|
||||
## Detección de menciones en grupos
|
||||
|
||||
@ -191,31 +192,31 @@ Cuando se establece `requireMention: true` para un chat de grupo, OpenClaw ahora
|
||||
|
||||
**Cómo funciona:**
|
||||
|
||||
1. Si un mensaje de voz no tiene cuerpo de texto y el grupo requiere menciones, OpenClaw realiza una transcripción "preflight".
|
||||
1. Si un mensaje de voz no tiene cuerpo de texto y el grupo requiere menciones, OpenClaw realiza una transcripción de "preflight".
|
||||
2. La transcripción se comprueba en busca de patrones de mención (por ejemplo, `@BotName`, disparadores de emoji).
|
||||
3. Si se encuentra una mención, el mensaje continúa por el flujo completo de respuesta.
|
||||
3. Si se encuentra una mención, el mensaje continúa por la canalización completa de respuesta.
|
||||
4. La transcripción se usa para la detección de menciones, de modo que las notas de voz puedan pasar la puerta de menciones.
|
||||
|
||||
**Comportamiento de respaldo:**
|
||||
|
||||
- Si la transcripción falla durante el preflight (tiempo de espera, error de API, etc.), el mensaje se procesa según la detección de menciones solo en texto.
|
||||
- Si la transcripción falla durante el preflight (tiempo de espera, error de API, etc.), el mensaje se procesa según la detección de menciones solo por texto.
|
||||
- Esto garantiza que los mensajes mixtos (texto + audio) nunca se descarten incorrectamente.
|
||||
|
||||
**Exclusión por grupo/tema de Telegram:**
|
||||
|
||||
- Establece `channels.telegram.groups.<chatId>.disableAudioPreflight: true` para omitir las comprobaciones de mención en la transcripción preflight de ese grupo.
|
||||
- Establece `channels.telegram.groups.<chatId>.disableAudioPreflight: true` para omitir las comprobaciones de menciones en la transcripción preflight de ese grupo.
|
||||
- Establece `channels.telegram.groups.<chatId>.topics.<threadId>.disableAudioPreflight` para sobrescribir por tema (`true` para omitir, `false` para forzar la habilitación).
|
||||
- El valor predeterminado es `false` (preflight habilitado cuando coinciden las condiciones con puerta por mención).
|
||||
- El valor predeterminado es `false` (preflight habilitado cuando coinciden las condiciones con puerta de mención).
|
||||
|
||||
**Ejemplo:** Un usuario envía una nota de voz que dice "Hey @Claude, what's the weather?" en un grupo de Telegram con `requireMention: true`. La nota de voz se transcribe, se detecta la mención y el agente responde.
|
||||
**Ejemplo:** Un usuario envía una nota de voz diciendo "Hey @Claude, what's the weather?" en un grupo de Telegram con `requireMention: true`. La nota de voz se transcribe, se detecta la mención y el agente responde.
|
||||
|
||||
## Aspectos a tener en cuenta
|
||||
## Detalles a tener en cuenta
|
||||
|
||||
- Las reglas de alcance usan la primera coincidencia. `chatType` se normaliza a `direct`, `group` o `room`.
|
||||
- Asegúrate de que tu CLI salga con 0 e imprima texto sin formato; el JSON debe procesarse mediante `jq -r .text`.
|
||||
- Para `parakeet-mlx`, si pasas `--output-dir`, OpenClaw lee `<output-dir>/<media-basename>.txt` cuando `--output-format` es `txt` (o se omite); los formatos de salida que no son `txt` recurren al análisis de stdout.
|
||||
- Las reglas de alcance usan primera coincidencia gana. `chatType` se normaliza a `direct`, `group` o `room`.
|
||||
- Asegúrate de que tu CLI salga con 0 e imprima texto sin formato; JSON debe ajustarse mediante `jq -r .text`.
|
||||
- Para `parakeet-mlx`, si pasas `--output-dir`, OpenClaw lee `<output-dir>/<media-basename>.txt` cuando `--output-format` es `txt` (o se omite); los formatos de salida que no sean `txt` vuelven al análisis de stdout.
|
||||
- Mantén tiempos de espera razonables (`timeoutSeconds`, predeterminado 60 s) para evitar bloquear la cola de respuestas.
|
||||
- La transcripción preflight solo procesa el **primer** archivo adjunto de audio para la detección de menciones. El audio adicional se procesa durante la fase principal de comprensión de medios.
|
||||
- La transcripción preflight solo procesa el **primer** adjunto de audio para la detección de menciones. El audio adicional se procesa durante la fase principal de comprensión de medios.
|
||||
|
||||
## Relacionado
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,43 +1,43 @@
|
||||
---
|
||||
read_when:
|
||||
- Quieres usar Arcee AI con OpenClaw
|
||||
- Necesitas la variable de entorno de clave API o la opción de autenticación CLI
|
||||
- Necesitas la variable de entorno de la clave de API o la opción de autenticación de la CLI
|
||||
summary: Configuración de Arcee AI (autenticación + selección de modelo)
|
||||
title: Arcee AI
|
||||
x-i18n:
|
||||
generated_at: "2026-04-24T05:43:32Z"
|
||||
model: gpt-5.4
|
||||
generated_at: "2026-05-02T23:39:09Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 54989e1706901fedc8a0c816ca7ee7f877fa4b973697540dd90cb9182420043f
|
||||
source_hash: 622ee5288aec3ae0b45d3f06ba65fd6f972e07d7a7596ae3905d6fbdac0bf737
|
||||
source_path: providers/arcee.md
|
||||
workflow: 15
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
[Arcee AI](https://arcee.ai) proporciona acceso a la familia Trinity de modelos mixture-of-experts a través de una API compatible con OpenAI. Todos los modelos Trinity tienen licencia Apache 2.0.
|
||||
[Arcee AI](https://arcee.ai) proporciona acceso a la familia Trinity de modelos de mezcla de expertos mediante una API compatible con OpenAI. Todos los modelos Trinity tienen licencia Apache 2.0.
|
||||
|
||||
Se puede acceder a los modelos de Arcee AI directamente mediante la plataforma de Arcee o a través de [OpenRouter](/es/providers/openrouter).
|
||||
Se puede acceder a los modelos de Arcee AI directamente a través de la plataforma Arcee o mediante [OpenRouter](/es/providers/openrouter).
|
||||
|
||||
| Propiedad | Valor |
|
||||
| --------- | ------------------------------------------------------------------------------------ |
|
||||
| Proveedor | `arcee` |
|
||||
| Autenticación | `ARCEEAI_API_KEY` (directo) o `OPENROUTER_API_KEY` (mediante OpenRouter) |
|
||||
| API | Compatible con OpenAI |
|
||||
| URL base | `https://api.arcee.ai/api/v1` (directo) o `https://openrouter.ai/api/v1` (OpenRouter) |
|
||||
| Propiedad | Valor |
|
||||
| -------- | ------------------------------------------------------------------------------------- |
|
||||
| Proveedor | `arcee` |
|
||||
| Autenticación | `ARCEEAI_API_KEY` (directa) o `OPENROUTER_API_KEY` (mediante OpenRouter) |
|
||||
| API | Compatible con OpenAI |
|
||||
| URL base | `https://api.arcee.ai/api/v1` (directa) o `https://openrouter.ai/api/v1` (OpenRouter) |
|
||||
|
||||
## Primeros pasos
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Directo (plataforma Arcee)">
|
||||
<Tab title="Direct (Arcee platform)">
|
||||
<Steps>
|
||||
<Step title="Obtener una clave API">
|
||||
Crea una clave API en [Arcee AI](https://chat.arcee.ai/).
|
||||
<Step title="Get an API key">
|
||||
Crea una clave de API en [Arcee AI](https://chat.arcee.ai/).
|
||||
</Step>
|
||||
<Step title="Ejecutar la incorporación">
|
||||
<Step title="Run onboarding">
|
||||
```bash
|
||||
openclaw onboard --auth-choice arceeai-api-key
|
||||
```
|
||||
</Step>
|
||||
<Step title="Establecer un modelo predeterminado">
|
||||
<Step title="Set a default model">
|
||||
```json5
|
||||
{
|
||||
agents: {
|
||||
@ -51,17 +51,17 @@ Se puede acceder a los modelos de Arcee AI directamente mediante la plataforma d
|
||||
</Steps>
|
||||
</Tab>
|
||||
|
||||
<Tab title="Mediante OpenRouter">
|
||||
<Tab title="Via OpenRouter">
|
||||
<Steps>
|
||||
<Step title="Obtener una clave API">
|
||||
Crea una clave API en [OpenRouter](https://openrouter.ai/keys).
|
||||
<Step title="Get an API key">
|
||||
Crea una clave de API en [OpenRouter](https://openrouter.ai/keys).
|
||||
</Step>
|
||||
<Step title="Ejecutar la incorporación">
|
||||
<Step title="Run onboarding">
|
||||
```bash
|
||||
openclaw onboard --auth-choice arceeai-openrouter
|
||||
```
|
||||
</Step>
|
||||
<Step title="Establecer un modelo predeterminado">
|
||||
<Step title="Set a default model">
|
||||
```json5
|
||||
{
|
||||
agents: {
|
||||
@ -72,7 +72,7 @@ Se puede acceder a los modelos de Arcee AI directamente mediante la plataforma d
|
||||
}
|
||||
```
|
||||
|
||||
Las mismas referencias de modelo funcionan tanto para configuraciones directas como de OpenRouter (por ejemplo `arcee/trinity-large-thinking`).
|
||||
Las mismas referencias de modelo funcionan tanto para configuraciones directas como con OpenRouter (por ejemplo, `arcee/trinity-large-thinking`).
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
@ -82,7 +82,7 @@ Se puede acceder a los modelos de Arcee AI directamente mediante la plataforma d
|
||||
## Configuración no interactiva
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Directo (plataforma Arcee)">
|
||||
<Tab title="Direct (Arcee platform)">
|
||||
```bash
|
||||
openclaw onboard --non-interactive \
|
||||
--mode local \
|
||||
@ -91,7 +91,7 @@ Se puede acceder a los modelos de Arcee AI directamente mediante la plataforma d
|
||||
```
|
||||
</Tab>
|
||||
|
||||
<Tab title="Mediante OpenRouter">
|
||||
<Tab title="Via OpenRouter">
|
||||
```bash
|
||||
openclaw onboard --non-interactive \
|
||||
--mode local \
|
||||
@ -103,37 +103,37 @@ Se puede acceder a los modelos de Arcee AI directamente mediante la plataforma d
|
||||
|
||||
## Catálogo integrado
|
||||
|
||||
OpenClaw incluye actualmente este catálogo integrado de Arcee:
|
||||
OpenClaw incluye actualmente este catálogo Arcee empaquetado:
|
||||
|
||||
| Referencia de modelo | Nombre | Entrada | Contexto | Coste (ent/sal por 1M) | Notas |
|
||||
| ------------------------------ | ---------------------- | ------- | -------- | ---------------------- | ------------------------------------------ |
|
||||
| `arcee/trinity-large-thinking` | Trinity Large Thinking | text | 256K | $0.25 / $0.90 | Modelo predeterminado; razonamiento habilitado |
|
||||
| `arcee/trinity-large-preview` | Trinity Large Preview | text | 128K | $0.25 / $1.00 | Uso general; 400B params, 13B activos |
|
||||
| `arcee/trinity-mini` | Trinity Mini 26B | text | 128K | $0.045 / $0.15 | Rápido y eficiente en costes; llamadas a funciones |
|
||||
| Referencia de modelo | Nombre | Entrada | Contexto | Costo (entrada/salida por 1M) | Notas |
|
||||
| ------------------------------ | ---------------------- | ----- | ------- | -------------------- | ------------------------------------------ |
|
||||
| `arcee/trinity-large-thinking` | Trinity Large Thinking | texto | 256K | $0.25 / $0.90 | Modelo predeterminado; razonamiento habilitado; sin herramientas |
|
||||
| `arcee/trinity-large-preview` | Trinity Large Preview | texto | 128K | $0.25 / $1.00 | De propósito general; 400B parámetros, 13B activos |
|
||||
| `arcee/trinity-mini` | Trinity Mini 26B | texto | 128K | $0.045 / $0.15 | Rápido y rentable; llamadas a funciones |
|
||||
|
||||
<Tip>
|
||||
El ajuste predefinido de incorporación establece `arcee/trinity-large-thinking` como modelo predeterminado.
|
||||
El preajuste de onboarding establece `arcee/trinity-large-thinking` como modelo predeterminado. Es solo de razonamiento/texto y no admite uso de herramientas ni llamadas a funciones.
|
||||
</Tip>
|
||||
|
||||
## Funciones compatibles
|
||||
|
||||
| Función | Compatible |
|
||||
| --------------------------------------------- | ---------------------------- |
|
||||
| Streaming | Sí |
|
||||
| Uso de herramientas / llamadas a funciones | Sí |
|
||||
| Salida estructurada (modo JSON y esquema JSON) | Sí |
|
||||
| Razonamiento extendido | Sí (Trinity Large Thinking) |
|
||||
| Función | Compatible |
|
||||
| --------------------------------------------- | ------------------------------------------- |
|
||||
| Streaming | Sí |
|
||||
| Uso de herramientas / llamadas a funciones | Depende del modelo; no Trinity Large Thinking |
|
||||
| Salida estructurada (modo JSON y esquema JSON) | Sí |
|
||||
| Razonamiento extendido | Sí (Trinity Large Thinking) |
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Nota sobre el entorno">
|
||||
Si Gateway se ejecuta como daemon (launchd/systemd), asegúrate de que `ARCEEAI_API_KEY`
|
||||
<Accordion title="Environment note">
|
||||
Si el Gateway se ejecuta como daemon (launchd/systemd), asegúrate de que `ARCEEAI_API_KEY`
|
||||
(o `OPENROUTER_API_KEY`) esté disponible para ese proceso (por ejemplo, en
|
||||
`~/.openclaw/.env` o mediante `env.shellEnv`).
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Enrutamiento de OpenRouter">
|
||||
Cuando uses modelos Arcee mediante OpenRouter, se aplican las mismas referencias de modelo `arcee/*`.
|
||||
OpenClaw gestiona el enrutamiento de forma transparente según tu elección de autenticación. Consulta la
|
||||
<Accordion title="OpenRouter routing">
|
||||
Al usar modelos de Arcee mediante OpenRouter, se aplican las mismas referencias de modelo `arcee/*`.
|
||||
OpenClaw gestiona el enrutamiento de forma transparente según tu opción de autenticación. Consulta la
|
||||
[documentación del proveedor OpenRouter](/es/providers/openrouter) para ver detalles de configuración
|
||||
específicos de OpenRouter.
|
||||
</Accordion>
|
||||
@ -143,9 +143,9 @@ El ajuste predefinido de incorporación establece `arcee/trinity-large-thinking`
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="OpenRouter" href="/es/providers/openrouter" icon="shuffle">
|
||||
Accede a modelos Arcee y muchos otros mediante una sola clave API.
|
||||
Accede a modelos de Arcee y muchos otros mediante una sola clave de API.
|
||||
</Card>
|
||||
<Card title="Selección de modelo" href="/es/concepts/model-providers" icon="layers">
|
||||
Elegir proveedores, referencias de modelo y comportamiento de failover.
|
||||
<Card title="Model selection" href="/es/concepts/model-providers" icon="layers">
|
||||
Elegir proveedores, referencias de modelo y comportamiento de conmutación por error.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
@ -1,24 +1,23 @@
|
||||
---
|
||||
read_when:
|
||||
- Buscando definiciones de canales de lanzamiento públicos
|
||||
- Ejecución de la validación de lanzamiento o de la aceptación de paquetes
|
||||
- Buscando definiciones públicas de canales de lanzamiento
|
||||
- Ejecutar la validación de lanzamiento o la aceptación del paquete
|
||||
- Buscando la nomenclatura y la cadencia de versiones
|
||||
summary: Canales de lanzamiento, lista de verificación del operador, entornos de validación, nomenclatura de versiones y cadencia
|
||||
title: Política de lanzamientos
|
||||
summary: Canales de lanzamiento, lista de comprobación del operador, cajas de validación, nomenclatura de versiones y cadencia
|
||||
title: Política de lanzamiento
|
||||
x-i18n:
|
||||
generated_at: "2026-05-02T21:03:56Z"
|
||||
generated_at: "2026-05-02T23:39:24Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 493cb8b42f0e15f3bf5f8fb9be7d01fd626f4f16db9ac0a85e6efa747ef12d12
|
||||
source_hash: ba316d1736eae8edd2fb0a71b9a3da345f8895c3b536e9a1f619718ea12fc851
|
||||
source_path: reference/RELEASING.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
OpenClaw tiene cuatro canales públicos de lanzamiento:
|
||||
OpenClaw tiene tres canales públicos de lanzamiento:
|
||||
|
||||
- stable: lanzamientos etiquetados que se publican en npm `beta` de forma predeterminada, o en npm `latest` cuando se solicita explícitamente
|
||||
- alpha: etiquetas de prelanzamiento que se publican en npm `alpha`
|
||||
- beta: etiquetas de prelanzamiento que se publican en npm `beta`
|
||||
- beta: etiquetas de versión preliminar que se publican en npm `beta`
|
||||
- dev: la cabecera móvil de `main`
|
||||
|
||||
## Nomenclatura de versiones
|
||||
@ -27,259 +26,258 @@ OpenClaw tiene cuatro canales públicos de lanzamiento:
|
||||
- Etiqueta de Git: `vYYYY.M.D`
|
||||
- Versión de lanzamiento de corrección estable: `YYYY.M.D-N`
|
||||
- Etiqueta de Git: `vYYYY.M.D-N`
|
||||
- Versión de prelanzamiento alpha: `YYYY.M.D-alpha.N`
|
||||
- Etiqueta de Git: `vYYYY.M.D-alpha.N`
|
||||
- Versión de prelanzamiento beta: `YYYY.M.D-beta.N`
|
||||
- Versión preliminar beta: `YYYY.M.D-beta.N`
|
||||
- Etiqueta de Git: `vYYYY.M.D-beta.N`
|
||||
- No rellenes con ceros el mes ni el día
|
||||
- `latest` significa el lanzamiento estable actual promocionado en npm
|
||||
- `alpha` significa el destino actual de instalación alpha
|
||||
- `beta` significa el destino actual de instalación beta
|
||||
- Los lanzamientos estables y de corrección estable se publican en npm `beta` de forma predeterminada; los operadores de lanzamiento pueden apuntar explícitamente a `latest`, o promocionar más tarde una compilación beta examinada
|
||||
- Cada lanzamiento estable de OpenClaw distribuye juntos el paquete npm y la app de macOS;
|
||||
los lanzamientos beta normalmente validan y publican primero la ruta de npm/paquete, con
|
||||
la compilación/firma/notarización de la app de Mac reservada para estable salvo que se solicite explícitamente
|
||||
- No rellene con ceros el mes ni el día
|
||||
- `latest` significa el lanzamiento estable actual de npm promocionado
|
||||
- `beta` significa el destino de instalación beta actual
|
||||
- Los lanzamientos estables y de corrección estable se publican en npm `beta` de forma predeterminada; los operadores de lanzamiento pueden apuntar explícitamente a `latest`, o promocionar más tarde una compilación beta evaluada
|
||||
- Cada lanzamiento estable de OpenClaw distribuye juntos el paquete npm y la aplicación macOS;
|
||||
los lanzamientos beta normalmente validan y publican primero la ruta npm/paquete, con
|
||||
la compilación/firma/notarización de la aplicación Mac reservada para estable salvo que se solicite explícitamente
|
||||
|
||||
## Cadencia de lanzamientos
|
||||
|
||||
- Los lanzamientos avanzan primero por beta
|
||||
- Estable sigue solo después de validar la beta más reciente
|
||||
- Los mantenedores normalmente preparan lanzamientos desde una rama `release/YYYY.M.D` creada
|
||||
desde el `main` actual, para que la validación y las correcciones del lanzamiento no bloqueen el nuevo
|
||||
- Estable viene solo después de que se valide la beta más reciente
|
||||
- Los mantenedores normalmente cortan los lanzamientos desde una rama `release/YYYY.M.D` creada
|
||||
a partir de `main` actual, para que la validación y las correcciones del lanzamiento no bloqueen el nuevo
|
||||
desarrollo en `main`
|
||||
- Si se ha enviado o publicado una etiqueta beta y necesita una corrección, los mantenedores preparan
|
||||
la siguiente etiqueta `-beta.N` en lugar de eliminar o recrear la etiqueta beta anterior
|
||||
- Si se ha enviado o publicado una etiqueta beta y necesita una corrección, los mantenedores cortan
|
||||
la siguiente etiqueta `-beta.N` en lugar de eliminar o recrear la etiqueta beta antigua
|
||||
- El procedimiento detallado de lanzamiento, las aprobaciones, las credenciales y las notas de recuperación son
|
||||
solo para mantenedores
|
||||
|
||||
## Lista de verificación del operador de lanzamiento
|
||||
## Lista de comprobación del operador de lanzamiento
|
||||
|
||||
Esta lista de verificación es la forma pública del flujo de lanzamiento. Las credenciales privadas,
|
||||
la firma, la notarización, la recuperación de dist-tags y los detalles de reversión de emergencia permanecen en
|
||||
Esta lista de comprobación es la forma pública del flujo de lanzamiento. Las credenciales privadas,
|
||||
la firma, la notarización, la recuperación de dist-tag y los detalles de reversión de emergencia permanecen en
|
||||
el manual de lanzamiento solo para mantenedores.
|
||||
|
||||
1. Empieza desde el `main` actual: trae lo último, confirma que el commit de destino se haya enviado,
|
||||
y confirma que el CI actual de `main` esté lo suficientemente en verde para ramificar desde él.
|
||||
2. Reescribe la sección superior de `CHANGELOG.md` a partir del historial real de commits con
|
||||
`/changelog`, mantén las entradas orientadas al usuario, haz commit, envíalo y haz rebase/pull
|
||||
1. Comience desde `main` actual: haga pull de lo más reciente, confirme que el commit objetivo se haya enviado,
|
||||
y confirme que la CI de `main` actual esté suficientemente verde para crear una rama desde ella.
|
||||
2. Reescriba la sección superior de `CHANGELOG.md` desde el historial real de commits con
|
||||
`/changelog`, mantenga las entradas orientadas al usuario, confírmela, envíela, y haga rebase/pull
|
||||
una vez más antes de crear la rama.
|
||||
3. Revisa los registros de compatibilidad de lanzamiento en
|
||||
3. Revise los registros de compatibilidad de lanzamiento en
|
||||
`src/plugins/compat/registry.ts` y
|
||||
`src/commands/doctor/shared/deprecation-compat.ts`. Elimina la compatibilidad caducada
|
||||
solo cuando la ruta de actualización siga cubierta, o registra por qué se conserva
|
||||
`src/commands/doctor/shared/deprecation-compat.ts`. Elimine compatibilidad caducada
|
||||
solo cuando la ruta de actualización siga cubierta, o registre por qué se mantiene
|
||||
intencionalmente.
|
||||
4. Crea `release/YYYY.M.D` desde el `main` actual; no hagas trabajo normal de lanzamiento
|
||||
4. Cree `release/YYYY.M.D` desde `main` actual; no realice el trabajo normal de lanzamiento
|
||||
directamente en `main`.
|
||||
5. Incrementa cada ubicación de versión requerida para la etiqueta prevista, ejecuta
|
||||
`pnpm plugins:sync` para que los paquetes de Plugin publicables compartan la versión
|
||||
de lanzamiento y los metadatos de compatibilidad, luego ejecuta la verificación previa determinista local:
|
||||
5. Actualice cada ubicación de versión requerida para la etiqueta prevista, ejecute
|
||||
`pnpm plugins:sync` para que los paquetes Plugin publicables compartan la versión de lanzamiento
|
||||
y los metadatos de compatibilidad, y luego ejecute la verificación previa determinista local:
|
||||
`pnpm check:test-types`, `pnpm check:architecture`,
|
||||
`pnpm build && pnpm ui:build`, `pnpm plugins:sync:check`, y
|
||||
`pnpm release:check`.
|
||||
6. Ejecuta `OpenClaw NPM Release` con `preflight_only=true`. Antes de que exista una etiqueta,
|
||||
se permite un SHA completo de 40 caracteres de la rama de lanzamiento para una verificación previa solo de validación.
|
||||
Guarda el `preflight_run_id` correcto.
|
||||
7. Inicia todas las pruebas previas al lanzamiento con `Full Release Validation` para la
|
||||
rama de lanzamiento, la etiqueta o el SHA completo del commit. Este es el único punto de entrada manual
|
||||
para las cuatro grandes cajas de pruebas de lanzamiento: Vitest, Docker, QA Lab y Package.
|
||||
8. Si la validación falla, corrige en la rama de lanzamiento y vuelve a ejecutar el archivo,
|
||||
carril, trabajo de workflow, perfil de paquete, proveedor o allowlist de modelo fallido más pequeño que
|
||||
demuestre la corrección. Vuelve a ejecutar el paraguas completo solo cuando la superficie modificada deje obsoleta
|
||||
la evidencia anterior.
|
||||
9. Para alpha o beta, etiqueta `vYYYY.M.D-alpha.N` o `vYYYY.M.D-beta.N`, luego ejecuta `OpenClaw Release Publish` desde
|
||||
6. Ejecute `OpenClaw NPM Release` con `preflight_only=true`. Antes de que exista una etiqueta,
|
||||
se permite un SHA completo de rama de lanzamiento de 40 caracteres solo para la validación
|
||||
de verificación previa. Guarde el `preflight_run_id` exitoso.
|
||||
7. Inicie todas las pruebas previas al lanzamiento con `Full Release Validation` para la
|
||||
rama de lanzamiento, la etiqueta o el SHA de commit completo. Este es el único punto de entrada manual
|
||||
para las cuatro grandes cajas de prueba de lanzamiento: Vitest, Docker, QA Lab y Package.
|
||||
8. Si la validación falla, corríjalo en la rama de lanzamiento y vuelva a ejecutar el archivo,
|
||||
canal, trabajo de workflow, perfil de paquete, proveedor o allowlist de modelos fallido más pequeño que
|
||||
demuestre la corrección. Vuelva a ejecutar el paraguas completo solo cuando la superficie cambiada vuelva
|
||||
obsoleta la evidencia anterior.
|
||||
9. Para beta, etiquete `vYYYY.M.D-beta.N`, luego ejecute `OpenClaw Release Publish` desde
|
||||
la rama `release/YYYY.M.D` correspondiente. Verifica `pnpm plugins:sync:check`,
|
||||
publica primero en npm todos los paquetes de Plugin publicables, publica el mismo
|
||||
conjunto en ClawHub después y luego promociona el artefacto preparado de verificación previa npm de OpenClaw
|
||||
con el dist-tag correspondiente. Después de publicar, ejecuta la aceptación de paquete posterior a la publicación
|
||||
contra el paquete publicado `openclaw@YYYY.M.D-alpha.N`, `openclaw@alpha`,
|
||||
`openclaw@YYYY.M.D-beta.N`, o `openclaw@beta`. Si un prelanzamiento enviado o
|
||||
publicado necesita una corrección, crea el siguiente número de prelanzamiento correspondiente;
|
||||
no elimines ni reescribas el prelanzamiento anterior.
|
||||
10. Para estable, continúa solo después de que la beta examinada o la candidata de lanzamiento tenga la
|
||||
evidencia de validación requerida. La publicación estable de npm también pasa por
|
||||
`OpenClaw Release Publish`, reutilizando el artefacto correcto de verificación previa mediante
|
||||
publica primero en npm todos los paquetes Plugin publicables, publica el mismo
|
||||
conjunto en ClawHub en segundo lugar, y luego promociona el artefacto de verificación previa npm de OpenClaw preparado
|
||||
con el dist-tag correspondiente. Después de publicar, ejecute la aceptación de paquete
|
||||
posterior a la publicación contra el paquete publicado `openclaw@YYYY.M.D-beta.N` o
|
||||
`openclaw@beta`. Si una versión preliminar enviada o publicada necesita una corrección,
|
||||
corte el siguiente número de versión preliminar correspondiente; no elimine ni reescriba la versión preliminar
|
||||
antigua.
|
||||
10. Para estable, continúe solo después de que la beta evaluada o el candidato de lanzamiento tenga la
|
||||
evidencia de validación requerida. La publicación npm estable también pasa por
|
||||
`OpenClaw Release Publish`, reutilizando el artefacto de verificación previa exitoso mediante
|
||||
`preflight_run_id`; la preparación del lanzamiento estable de macOS también requiere el
|
||||
`.zip`, `.dmg`, `.dSYM.zip` empaquetados y el `appcast.xml` actualizado en `main`.
|
||||
11. Después de publicar, ejecuta el verificador posterior a la publicación de npm, el E2E opcional de Telegram
|
||||
publicado en npm independiente cuando necesites prueba de canal posterior a la publicación,
|
||||
la promoción de dist-tag cuando sea necesario, las notas de lanzamiento/prelanzamiento de GitHub a partir de la
|
||||
`.zip`, `.dmg`, `.dSYM.zip` empaquetados y `appcast.xml` actualizado en `main`.
|
||||
11. Después de publicar, ejecute el verificador npm posterior a la publicación, el E2E de Telegram
|
||||
publicado-npm independiente opcional cuando necesite prueba de canal posterior a la publicación,
|
||||
la promoción de dist-tag cuando sea necesaria, las notas de lanzamiento/versión preliminar de GitHub desde la
|
||||
sección completa correspondiente de `CHANGELOG.md`, y los pasos de anuncio del lanzamiento.
|
||||
|
||||
## Verificación previa del lanzamiento
|
||||
|
||||
- Ejecuta `pnpm check:test-types` antes del preflight de lanzamiento para que TypeScript de pruebas siga
|
||||
cubierto fuera de la puerta local más rápida `pnpm check`
|
||||
- Ejecuta `pnpm check:architecture` antes del preflight de lanzamiento para que las comprobaciones más amplias de ciclos
|
||||
de importación y límites de arquitectura estén verdes fuera de la puerta local más rápida
|
||||
- Ejecuta `pnpm check:test-types` antes de la verificación previa de lanzamiento para que el TypeScript de pruebas siga
|
||||
cubierto fuera de la puerta local más rápida de `pnpm check`
|
||||
- Ejecuta `pnpm check:architecture` antes de la verificación previa de lanzamiento para que las comprobaciones más amplias de ciclos de
|
||||
importación y límites de arquitectura estén en verde fuera de la puerta local más rápida
|
||||
- Ejecuta `pnpm build && pnpm ui:build` antes de `pnpm release:check` para que los artefactos de lanzamiento
|
||||
esperados `dist/*` y el paquete de Control UI existan para el paso de validación
|
||||
de empaquetado
|
||||
- Ejecuta `pnpm plugins:sync` después del aumento de versión raíz y antes de etiquetar. Actualiza
|
||||
las versiones de paquetes de plugins publicables, los metadatos de compatibilidad
|
||||
peer/API de OpenClaw, los metadatos de compilación y los stubs de changelog de plugins para que coincidan con la versión de lanzamiento
|
||||
del core. `pnpm plugins:sync:check` es la guarda de lanzamiento no mutante;
|
||||
`dist/*` esperados y el paquete de Control UI existan para el paso de validación
|
||||
del paquete
|
||||
- Ejecuta `pnpm plugins:sync` después del incremento de versión raíz y antes de etiquetar. Actualiza
|
||||
las versiones de paquetes de plugins publicables, los metadatos de compatibilidad de pares/API
|
||||
de OpenClaw, los metadatos de compilación y los stubs de changelog de plugins para que coincidan con la versión
|
||||
de lanzamiento del núcleo. `pnpm plugins:sync:check` es la guarda de lanzamiento no mutante;
|
||||
el flujo de publicación falla antes de cualquier mutación del registro si este paso se
|
||||
olvidó.
|
||||
- Ejecuta el flujo manual `Full Release Validation` antes de la aprobación del lanzamiento para
|
||||
iniciar todos los test boxes de pre-lanzamiento desde un único punto de entrada. Acepta una rama,
|
||||
etiqueta o SHA completo de commit, despacha `CI` manual y despacha
|
||||
`OpenClaw Release Checks` para install smoke, package acceptance, suites de ruta de lanzamiento de Docker,
|
||||
live/E2E, OpenWebUI, paridad de QA Lab, Matrix y carriles de Telegram. Con
|
||||
`release_profile=full` y `rerun_group=all`, también ejecuta package
|
||||
Telegram E2E contra el artefacto `release-package-under-test` de release
|
||||
checks. Proporciona `npm_telegram_package_spec` después de publicar cuando el mismo
|
||||
Telegram E2E también deba probar el paquete npm publicado. Proporciona
|
||||
- Ejecuta el workflow manual `Full Release Validation` antes de la aprobación del lanzamiento para
|
||||
iniciar todas las cajas de prueba previas al lanzamiento desde un único punto de entrada. Acepta una rama,
|
||||
etiqueta o SHA de commit completo, despacha `CI` manual y despacha
|
||||
`OpenClaw Release Checks` para smoke de instalación, aceptación de paquetes, suites de ruta de lanzamiento
|
||||
de Docker, live/E2E, OpenWebUI, paridad de QA Lab, Matrix y carriles de Telegram.
|
||||
Con `release_profile=full` y `rerun_group=all`, también ejecuta el E2E de Telegram de paquete
|
||||
contra el artefacto `release-package-under-test` de las comprobaciones de lanzamiento. Proporciona
|
||||
`npm_telegram_package_spec` después de publicar cuando el mismo E2E de Telegram también deba probar
|
||||
el paquete npm publicado. Proporciona
|
||||
`package_acceptance_package_spec` después de publicar cuando Package Acceptance
|
||||
deba ejecutar su matriz de paquetes/actualización contra el paquete npm enviado en lugar
|
||||
del artefacto compilado desde el SHA. Proporciona
|
||||
deba ejecutar su matriz de paquete/actualización contra el paquete npm enviado en lugar
|
||||
del artefacto construido desde el SHA. Proporciona
|
||||
`evidence_package_spec` cuando el informe privado de evidencia deba demostrar que la
|
||||
validación coincide con un paquete npm publicado sin forzar Telegram E2E.
|
||||
validación coincide con un paquete npm publicado sin forzar el E2E de Telegram.
|
||||
Ejemplo:
|
||||
`gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
|
||||
- Ejecuta el flujo manual `Package Acceptance` cuando quieras prueba por canal alternativo
|
||||
- Ejecuta el workflow manual `Package Acceptance` cuando quieras una prueba por canal lateral
|
||||
para un candidato de paquete mientras continúa el trabajo de lanzamiento. Usa `source=npm` para
|
||||
`openclaw@alpha`, `openclaw@beta`, `openclaw@latest` o una versión exacta de lanzamiento; `source=ref`
|
||||
`openclaw@beta`, `openclaw@latest` o una versión de lanzamiento exacta; `source=ref`
|
||||
para empaquetar una rama/etiqueta/SHA `package_ref` de confianza con el arnés
|
||||
`workflow_ref` actual; `source=url` para un tarball HTTPS con SHA-256
|
||||
obligatorio; o `source=artifact` para un tarball subido por otra ejecución de GitHub
|
||||
Actions. El flujo resuelve el candidato a
|
||||
`package-under-test`, reutiliza el planificador de lanzamiento Docker E2E contra ese
|
||||
`workflow_ref` actual; `source=url` para un tarball HTTPS con un
|
||||
SHA-256 obligatorio; o `source=artifact` para un tarball subido por otra ejecución de
|
||||
GitHub Actions. El workflow resuelve el candidato en
|
||||
`package-under-test`, reutiliza el programador de lanzamiento Docker E2E contra ese
|
||||
tarball y puede ejecutar QA de Telegram contra el mismo tarball con
|
||||
`telegram_mode=mock-openai` o `telegram_mode=live-frontier`. Cuando los carriles Docker
|
||||
seleccionados incluyen `published-upgrade-survivor`, el artefacto del paquete
|
||||
`telegram_mode=mock-openai` o `telegram_mode=live-frontier`. Cuando los
|
||||
carriles de Docker seleccionados incluyen `published-upgrade-survivor`, el artefacto de paquete
|
||||
es el candidato y `published_upgrade_survivor_baseline` selecciona
|
||||
la línea base publicada.
|
||||
Ejemplo: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai`
|
||||
Perfiles comunes:
|
||||
- `smoke`: carriles de instalación/canal/agente, red de Gateway y recarga de configuración
|
||||
- `package`: carriles nativos de artefacto para paquete/actualización/plugin sin OpenWebUI ni ClawHub live
|
||||
- `package`: carriles de paquete/actualización/plugin nativos del artefacto sin OpenWebUI ni ClawHub live
|
||||
- `product`: perfil de paquete más canales MCP, limpieza de cron/subagente,
|
||||
búsqueda web de OpenAI y OpenWebUI
|
||||
- `full`: fragmentos de ruta de lanzamiento de Docker con OpenWebUI
|
||||
- `custom`: selección exacta de `docker_lanes` para una repetición enfocada
|
||||
- Ejecuta el flujo manual `CI` directamente cuando solo necesites cobertura completa de CI normal
|
||||
- Ejecuta directamente el workflow manual `CI` cuando solo necesites cobertura completa de CI normal
|
||||
para el candidato de lanzamiento. Los despachos manuales de CI omiten el alcance por cambios
|
||||
y fuerzan los shards de Linux Node, shards de plugins empaquetados, contratos de canales,
|
||||
compatibilidad de Node 22, `check`, `check-additional`, build smoke,
|
||||
y fuerzan los shards de Linux Node, los shards de plugins agrupados, contratos de canal,
|
||||
compatibilidad con Node 22, `check`, `check-additional`, smoke de compilación,
|
||||
comprobaciones de docs, Skills de Python, Windows, macOS, Android y carriles de i18n de Control UI.
|
||||
Ejemplo: `gh workflow run ci.yml --ref release/YYYY.M.D`
|
||||
- Ejecuta `pnpm qa:otel:smoke` cuando valides telemetría de lanzamiento. Ejercita
|
||||
QA-lab a través de un receptor OTLP/HTTP local y verifica los nombres de spans
|
||||
de trazas exportadas, atributos acotados y redacción de contenido/identificadores sin
|
||||
requerir Opik, Langfuse u otro colector externo.
|
||||
- Ejecuta `pnpm qa:otel:smoke` al validar la telemetría de lanzamiento. Ejercita
|
||||
QA-lab mediante un receptor OTLP/HTTP local y verifica los nombres de spans de trazas
|
||||
exportados, los atributos acotados y la redacción de contenido/identificadores sin
|
||||
requerir Opik, Langfuse u otro recolector externo.
|
||||
- Ejecuta `pnpm release:check` antes de cada lanzamiento etiquetado
|
||||
- Ejecuta `OpenClaw Release Publish` para la secuencia de publicación mutante después de que la
|
||||
etiqueta exista. Despáchalo desde `release/YYYY.M.D` (o `main` al publicar una
|
||||
etiqueta alcanzable desde main), pasa la etiqueta de lanzamiento y el `preflight_run_id` exitoso de OpenClaw npm,
|
||||
y conserva el alcance predeterminado de publicación de plugins
|
||||
- Ejecuta `OpenClaw Release Publish` para la secuencia de publicación mutante después de que
|
||||
exista la etiqueta. Despáchalo desde `release/YYYY.M.D` (o `main` al publicar una
|
||||
etiqueta alcanzable desde main), pasa la etiqueta de lanzamiento y el `preflight_run_id`
|
||||
correcto de npm de OpenClaw, y conserva el alcance de publicación de plugins predeterminado
|
||||
`all-publishable` salvo que estés ejecutando deliberadamente una reparación enfocada. El
|
||||
flujo serializa la publicación npm de plugins, la publicación de plugins en ClawHub y la publicación npm de OpenClaw
|
||||
para que el paquete core no se publique antes que sus plugins externalizados.
|
||||
- Las comprobaciones de lanzamiento ahora se ejecutan en un flujo manual separado:
|
||||
workflow serializa la publicación npm de plugins, la publicación de plugins en ClawHub y la
|
||||
publicación npm de OpenClaw para que el paquete del núcleo no se publique antes que sus
|
||||
plugins externalizados.
|
||||
- Las comprobaciones de lanzamiento ahora se ejecutan en un workflow manual separado:
|
||||
`OpenClaw Release Checks`
|
||||
- `OpenClaw Release Checks` también ejecuta el carril de paridad mock de QA Lab más el perfil rápido
|
||||
de Matrix live y el carril de QA de Telegram antes de la aprobación del lanzamiento. Los carriles live
|
||||
usan el entorno `qa-live-shared`; Telegram también usa arrendamientos de credenciales de Convex CI.
|
||||
Ejecuta el flujo manual `QA-Lab - All Lanes` con
|
||||
`matrix_profile=all` y `matrix_shards=true` cuando quieras el inventario completo de transporte
|
||||
Matrix, medios y E2EE en paralelo.
|
||||
- La validación de instalación y actualización runtime entre sistemas operativos forma parte de
|
||||
`OpenClaw Release Checks` público y de `Full Release Validation`, que llaman directamente
|
||||
al flujo reutilizable
|
||||
usan el entorno `qa-live-shared`; Telegram también usa leases de credenciales de Convex CI.
|
||||
Ejecuta el workflow manual `QA-Lab - All Lanes` con
|
||||
`matrix_profile=all` y `matrix_shards=true` cuando quieras el inventario completo de
|
||||
transporte, medios y E2EE de Matrix en paralelo.
|
||||
- La validación en tiempo de ejecución de instalación y actualización entre sistemas operativos forma parte de
|
||||
`OpenClaw Release Checks` y `Full Release Validation` públicos, que llaman directamente al
|
||||
workflow reutilizable
|
||||
`.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
|
||||
- Esta separación es intencional: mantener la ruta real de lanzamiento npm corta,
|
||||
determinista y centrada en artefactos, mientras las comprobaciones live más lentas permanecen en su
|
||||
propio carril para que no retrasen ni bloqueen la publicación
|
||||
propio carril para que no demoren ni bloqueen la publicación
|
||||
- Las comprobaciones de lanzamiento con secretos deben despacharse mediante `Full Release
|
||||
Validation` o desde la referencia de flujo `main`/release para que la lógica del flujo y
|
||||
Validation` o desde la referencia de workflow `main`/release para que la lógica del workflow y
|
||||
los secretos permanezcan controlados
|
||||
- `OpenClaw Release Checks` acepta una rama, etiqueta o SHA completo de commit siempre
|
||||
- `OpenClaw Release Checks` acepta una rama, etiqueta o SHA de commit completo siempre
|
||||
que el commit resuelto sea alcanzable desde una rama de OpenClaw o una etiqueta de lanzamiento
|
||||
- El preflight solo de validación de `OpenClaw NPM Release` también acepta el SHA completo
|
||||
actual de 40 caracteres del commit de la rama del flujo sin requerir una etiqueta enviada
|
||||
- La verificación previa solo de validación de `OpenClaw NPM Release` también acepta el SHA completo
|
||||
de 40 caracteres del commit actual de la rama del workflow sin requerir una etiqueta enviada
|
||||
- Esa ruta SHA es solo de validación y no puede promoverse a una publicación real
|
||||
- En modo SHA, el flujo sintetiza `v<package.json version>` solo para la
|
||||
comprobación de metadatos de paquete; la publicación real sigue requiriendo una etiqueta real de lanzamiento
|
||||
- Ambos flujos mantienen la ruta real de publicación y promoción en runners alojados por GitHub,
|
||||
mientras la ruta de validación no mutante puede usar los runners Linux más grandes
|
||||
- En modo SHA, el workflow sintetiza `v<package.json version>` solo para la comprobación de
|
||||
metadatos del paquete; la publicación real sigue requiriendo una etiqueta de lanzamiento real
|
||||
- Ambos workflows mantienen la ruta real de publicación y promoción en runners alojados por GitHub,
|
||||
mientras que la ruta de validación no mutante puede usar los runners Linux más grandes
|
||||
de Blacksmith
|
||||
- Ese flujo ejecuta
|
||||
- Ese workflow ejecuta
|
||||
`OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
|
||||
usando los secretos de flujo `OPENAI_API_KEY` y `ANTHROPIC_API_KEY`
|
||||
- El preflight de lanzamiento npm ya no espera al carril separado de comprobaciones de lanzamiento
|
||||
usando los secretos de workflow `OPENAI_API_KEY` y `ANTHROPIC_API_KEY`
|
||||
- La verificación previa de lanzamiento npm ya no espera al carril separado de comprobaciones de lanzamiento
|
||||
- Ejecuta `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
|
||||
(o la etiqueta beta/corrección correspondiente) antes de la aprobación
|
||||
- Después de publicar en npm, ejecuta
|
||||
`node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
|
||||
(o la versión beta/corrección correspondiente) para verificar la ruta de instalación
|
||||
del registro publicado en un prefijo temporal nuevo
|
||||
(o la versión beta/corrección correspondiente) para verificar la ruta de instalación del registro
|
||||
publicado en un prefijo temporal nuevo
|
||||
- Después de una publicación beta, ejecuta `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`
|
||||
para verificar el onboarding del paquete instalado, la configuración de Telegram y el Telegram E2E real
|
||||
contra el paquete npm publicado usando el pool compartido de credenciales de Telegram arrendadas.
|
||||
Las ejecuciones locales puntuales de mantenedores pueden omitir las variables de Convex y pasar directamente las tres
|
||||
para verificar el onboarding de paquete instalado, la configuración de Telegram y el E2E real de Telegram
|
||||
contra el paquete npm publicado usando el pool compartido de credenciales alquiladas de Telegram.
|
||||
Las ejecuciones puntuales locales de mantenedores pueden omitir las variables de Convex y pasar directamente las tres
|
||||
credenciales de entorno `OPENCLAW_QA_TELEGRAM_*`.
|
||||
- Los mantenedores pueden ejecutar la misma comprobación posterior a la publicación desde GitHub Actions mediante el
|
||||
flujo manual `NPM Telegram Beta E2E`. Es intencionalmente solo manual y
|
||||
workflow manual `NPM Telegram Beta E2E`. Es intencionalmente solo manual y
|
||||
no se ejecuta en cada merge.
|
||||
- La automatización de lanzamientos de mantenedores ahora usa preflight-luego-promoción:
|
||||
- la publicación npm real debe pasar un `preflight_run_id` npm exitoso
|
||||
- La automatización de lanzamiento de mantenedores ahora usa verificación previa y luego promoción:
|
||||
- la publicación npm real debe pasar un `preflight_run_id` npm correcto
|
||||
- la publicación npm real debe despacharse desde la misma rama `main` o
|
||||
`release/YYYY.M.D` que la ejecución de preflight exitosa
|
||||
- los lanzamientos npm estables apuntan de forma predeterminada a `beta`
|
||||
- la publicación npm estable puede apuntar explícitamente a `latest` mediante entrada del flujo
|
||||
`release/YYYY.M.D` que la ejecución correcta de verificación previa
|
||||
- los lanzamientos npm estables apuntan a `beta` de forma predeterminada
|
||||
- la publicación npm estable puede apuntar explícitamente a `latest` mediante la entrada del workflow
|
||||
- la mutación de dist-tag de npm basada en token ahora vive en
|
||||
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
|
||||
por seguridad, porque `npm dist-tag add` todavía necesita `NPM_TOKEN` mientras el
|
||||
por seguridad, porque `npm dist-tag add` aún necesita `NPM_TOKEN` mientras el
|
||||
repo público mantiene publicación solo con OIDC
|
||||
- `macOS Release` público es solo de validación; cuando una etiqueta existe solo en una
|
||||
rama de lanzamiento pero el flujo se despacha desde `main`, establece
|
||||
rama de lanzamiento pero el workflow se despacha desde `main`, establece
|
||||
`public_release_branch=release/YYYY.M.D`
|
||||
- la publicación privada real de Mac debe pasar `preflight_run_id` y `validate_run_id`
|
||||
privados de Mac exitosos
|
||||
- las rutas de publicación reales promueven artefactos preparados en lugar de compilarlos
|
||||
- la publicación privada real de mac debe pasar un `preflight_run_id` y
|
||||
`validate_run_id` privados de mac correctos
|
||||
- las rutas de publicación reales promueven artefactos preparados en lugar de reconstruirlos
|
||||
de nuevo
|
||||
- Para lanzamientos de corrección estable como `YYYY.M.D-N`, el verificador posterior a la publicación
|
||||
- Para lanzamientos estables de corrección como `YYYY.M.D-N`, el verificador posterior a la publicación
|
||||
también comprueba la misma ruta de actualización con prefijo temporal de `YYYY.M.D` a `YYYY.M.D-N`
|
||||
para que las correcciones de lanzamiento no puedan dejar silenciosamente instalaciones globales antiguas en el
|
||||
payload estable base
|
||||
- El preflight de lanzamiento npm falla cerrado salvo que el tarball incluya tanto
|
||||
- La verificación previa de lanzamiento npm falla de forma cerrada salvo que el tarball incluya tanto
|
||||
`dist/control-ui/index.html` como un payload no vacío `dist/control-ui/assets/`
|
||||
para que no volvamos a enviar un panel de navegador vacío
|
||||
para no volver a enviar un dashboard de navegador vacío
|
||||
- La verificación posterior a la publicación también comprueba que los entrypoints de plugins publicados y
|
||||
los metadatos de paquete estén presentes en el layout del registro instalado. Un lanzamiento que
|
||||
envía payloads runtime de plugins faltantes falla el verificador postpublish y
|
||||
los metadatos de paquetes estén presentes en el diseño del registro instalado. Un lanzamiento que
|
||||
envía payloads de runtime de plugins faltantes falla el verificador posterior a la publicación y
|
||||
no puede promoverse a `latest`.
|
||||
- `pnpm test:install:smoke` también aplica el presupuesto `unpackedSize` del npm pack en
|
||||
el tarball candidato de actualización, para que el e2e del instalador detecte crecimiento accidental del paquete
|
||||
- `pnpm test:install:smoke` también aplica el presupuesto `unpackedSize` del paquete npm en
|
||||
el tarball de actualización candidato, para que el e2e del instalador detecte bloat accidental del paquete
|
||||
antes de la ruta de publicación del lanzamiento
|
||||
- Si el trabajo de lanzamiento tocó planificación de CI, manifiestos de timing de plugins o
|
||||
matrices de pruebas de plugins, regenera y revisa las salidas de matriz
|
||||
- Si el trabajo de lanzamiento tocó la planificación de CI, manifiestos de tiempos de extensiones o
|
||||
matrices de pruebas de extensiones, regenera y revisa las salidas de matriz
|
||||
`plugin-prerelease-extension-shard` propiedad del planificador desde
|
||||
`.github/workflows/plugin-prerelease.yml` antes de la aprobación para que las notas de lanzamiento no
|
||||
describan un layout de CI obsoleto
|
||||
- La preparación para lanzamiento estable de macOS también incluye las superficies del actualizador:
|
||||
- el lanzamiento de GitHub debe terminar con los paquetes `.zip`, `.dmg` y `.dSYM.zip`
|
||||
describan un diseño de CI obsoleto
|
||||
- La preparación del lanzamiento estable de macOS también incluye las superficies del actualizador:
|
||||
- el lanzamiento de GitHub debe terminar con los `.zip`, `.dmg` y `.dSYM.zip` empaquetados
|
||||
- `appcast.xml` en `main` debe apuntar al nuevo zip estable después de publicar
|
||||
- la app empaquetada debe mantener un bundle id no debug, una URL de feed de Sparkle
|
||||
no vacía y un `CFBundleVersion` igual o superior al piso de compilación canónico de Sparkle
|
||||
- la app empaquetada debe conservar un id de bundle no debug, una URL de feed de Sparkle
|
||||
no vacía y un `CFBundleVersion` igual o superior al piso canónico de compilación de Sparkle
|
||||
para esa versión de lanzamiento
|
||||
|
||||
## Test boxes de lanzamiento
|
||||
## Cajas de prueba de lanzamiento
|
||||
|
||||
`Full Release Validation` es la forma en que los operadores inician todas las pruebas de pre-lanzamiento desde
|
||||
`Full Release Validation` es la forma en que los operadores inician todas las pruebas previas al lanzamiento desde
|
||||
un único punto de entrada. Para una prueba de commit fijado en una rama de movimiento rápido, usa el
|
||||
helper para que cada flujo hijo se ejecute desde una rama temporal fijada al SHA objetivo:
|
||||
helper para que cada workflow hijo se ejecute desde una rama temporal fijada al SHA
|
||||
objetivo:
|
||||
|
||||
```bash
|
||||
pnpm ci:full-release --sha <full-sha>
|
||||
```
|
||||
|
||||
El helper envía `release-ci/<sha>-...`, despacha `Full Release Validation`
|
||||
desde esa rama con `ref=<sha>`, verifica que cada `headSha` de flujo hijo
|
||||
desde esa rama con `ref=<sha>`, verifica que cada `headSha` de workflow hijo
|
||||
coincida con el objetivo y luego elimina la rama temporal. Esto evita probar por accidente una
|
||||
ejecución hija más nueva de `main`.
|
||||
|
||||
Para validar una rama o etiqueta de lanzamiento, ejecútalo desde la referencia de flujo `main`
|
||||
Para la validación de una rama o etiqueta de lanzamiento, ejecútala desde la referencia de workflow `main`
|
||||
de confianza y pasa la rama o etiqueta de lanzamiento como `ref`:
|
||||
|
||||
```bash
|
||||
@ -292,48 +290,52 @@ gh workflow run full-release-validation.yml \
|
||||
-f evidence_package_spec=openclaw@YYYY.M.D-beta.N
|
||||
```
|
||||
|
||||
El flujo de trabajo resuelve la referencia de destino, despacha `CI` manual con
|
||||
`target_ref=<release-ref>`, despacha `OpenClaw Release Checks` y despacha
|
||||
Telegram E2E de paquete independiente cuando `release_profile=full` con
|
||||
`rerun_group=all` o cuando `npm_telegram_package_spec` está definido. Luego
|
||||
`OpenClaw Release Checks` despliega install smoke, comprobaciones de lanzamiento
|
||||
entre sistemas operativos, cobertura live/E2E de ruta de lanzamiento Docker,
|
||||
Package Acceptance con QA de paquete Telegram, paridad de QA Lab, Matrix en vivo
|
||||
y Telegram en vivo. Una ejecución completa solo es aceptable cuando el resumen de
|
||||
`Full Release Validation`
|
||||
muestra `normal_ci` y `release_checks` como correctos. En modo full/all,
|
||||
el hijo `npm_telegram` también debe ser correcto; fuera de full/all se omite
|
||||
a menos que se haya proporcionado un `npm_telegram_package_spec` publicado. El resumen
|
||||
final del verificador incluye tablas de trabajos más lentos para cada ejecución hija,
|
||||
para que el responsable del lanzamiento pueda ver la ruta crítica actual sin descargar registros.
|
||||
Consulta [Validación completa de lanzamiento](/es/reference/full-release-validation) para la
|
||||
matriz completa de etapas, los nombres exactos de trabajos de flujo de trabajo, las
|
||||
diferencias entre perfiles estable y completo, los artefactos y los identificadores de
|
||||
reejecución enfocada.
|
||||
Los flujos de trabajo hijos se despachan desde la referencia de confianza que ejecuta
|
||||
`Full Release Validation`, normalmente `--ref main`, incluso cuando la `ref` de destino
|
||||
apunta a una rama o etiqueta de lanzamiento anterior. No hay una entrada separada de
|
||||
referencia de flujo de trabajo de Full Release Validation; elige el arnés de confianza
|
||||
eligiendo la referencia de ejecución del flujo de trabajo.
|
||||
No uses `--ref main -f ref=<sha>` para prueba exacta de commit en un `main` móvil;
|
||||
los SHA de commits sin procesar no pueden ser referencias de despacho de flujo de trabajo, así que usa
|
||||
El flujo de trabajo resuelve la ref de destino, despacha manualmente `CI` con
|
||||
`target_ref=<release-ref>`, despacha `OpenClaw Release Checks` y despacha el E2E
|
||||
independiente del paquete de Telegram cuando `release_profile=full` con
|
||||
`rerun_group=all` o cuando `npm_telegram_package_spec` está definido. Luego,
|
||||
`OpenClaw Release
|
||||
Checks` despliega smoke de instalación, comprobaciones de lanzamiento entre
|
||||
sistemas operativos, cobertura live/E2E Docker de la ruta de lanzamiento,
|
||||
Package Acceptance con QA del paquete de Telegram, paridad de QA Lab, Matrix
|
||||
live y Telegram live. Una ejecución completa solo es aceptable cuando el resumen
|
||||
de `Full Release Validation` muestra `normal_ci` y `release_checks` como
|
||||
correctos. En modo full/all, el hijo `npm_telegram` también debe ser correcto;
|
||||
fuera de full/all se omite salvo que se haya proporcionado un
|
||||
`npm_telegram_package_spec` publicado. El resumen final del verificador incluye
|
||||
tablas de trabajos más lentos para cada ejecución hija, de modo que el
|
||||
responsable del lanzamiento pueda ver la ruta crítica actual sin descargar
|
||||
registros.
|
||||
Consulta [validación completa del lanzamiento](/es/reference/full-release-validation) para ver la
|
||||
matriz de etapas completa, los nombres exactos de los trabajos del flujo de
|
||||
trabajo, las diferencias entre los perfiles stable y full, los artefactos y los
|
||||
identificadores de reejecución focalizada.
|
||||
Los flujos de trabajo hijos se despachan desde la ref de confianza que ejecuta
|
||||
`Full Release
|
||||
Validation`, normalmente `--ref main`, incluso cuando la `ref` de destino apunta
|
||||
a una rama o etiqueta de lanzamiento anterior. No hay una entrada independiente
|
||||
de ref de flujo de trabajo para Full Release Validation; elige el arnés de
|
||||
confianza eligiendo la ref de ejecución del flujo de trabajo.
|
||||
No uses `--ref main -f ref=<sha>` para prueba de commit exacto en un `main` móvil;
|
||||
los SHA de commit sin procesar no pueden ser refs de despacho de flujo de trabajo, así que usa
|
||||
`pnpm ci:full-release --sha <sha>` para crear la rama temporal fijada.
|
||||
|
||||
Usa `release_profile` para seleccionar la amplitud live/proveedor:
|
||||
Usa `release_profile` para seleccionar la amplitud live/de proveedor:
|
||||
|
||||
- `minimum`: la ruta crítica de lanzamiento más rápida de OpenAI/core live y Docker
|
||||
- `stable`: mínimo más cobertura estable de proveedor/backend para aprobación de lanzamiento
|
||||
- `full`: estable más cobertura amplia de proveedores/medios de asesoría
|
||||
- `minimum`: ruta Docker y OpenAI/core live más rápida y crítica para el lanzamiento
|
||||
- `stable`: minimum más cobertura de proveedor/backend stable para aprobación del lanzamiento
|
||||
- `full`: stable más cobertura amplia de proveedor/medios consultiva
|
||||
|
||||
`OpenClaw Release Checks` usa la referencia de flujo de trabajo de confianza para resolver la referencia de destino
|
||||
una vez como `release-package-under-test` y reutiliza ese artefacto tanto en las comprobaciones
|
||||
Docker de ruta de lanzamiento como en Package Acceptance. Esto mantiene todas las cajas
|
||||
orientadas a paquetes sobre los mismos bytes y evita compilaciones de paquete repetidas.
|
||||
El install smoke de OpenAI entre sistemas operativos usa `OPENCLAW_CROSS_OS_OPENAI_MODEL` cuando la
|
||||
variable de repo/organización está definida; de lo contrario, `openai/gpt-5.4`, porque esta lane
|
||||
demuestra la instalación del paquete, el onboarding, el arranque de Gateway y un turno de agente en vivo
|
||||
en lugar de comparar el modelo predeterminado más lento. La matriz live de proveedores más amplia
|
||||
sigue siendo el lugar para la cobertura específica de modelos.
|
||||
`OpenClaw Release Checks` usa la ref de flujo de trabajo de confianza para resolver
|
||||
la ref de destino una vez como `release-package-under-test` y reutiliza ese
|
||||
artefacto tanto en las comprobaciones Docker de la ruta de lanzamiento como en
|
||||
Package Acceptance. Esto mantiene todas las cajas orientadas a paquetes en los
|
||||
mismos bytes y evita compilaciones repetidas del paquete.
|
||||
El smoke de instalación de OpenAI entre sistemas operativos usa `OPENCLAW_CROSS_OS_OPENAI_MODEL` cuando la
|
||||
variable de repo/org está definida; de lo contrario, `openai/gpt-5.4`, porque esta línea está
|
||||
probando la instalación del paquete, el onboarding, el arranque del Gateway y un
|
||||
turno live de agente, no comparando el modelo predeterminado más lento. La matriz
|
||||
más amplia de proveedores live sigue siendo el lugar para la cobertura específica de modelos.
|
||||
|
||||
Usa estas variantes según la etapa del lanzamiento:
|
||||
|
||||
@ -365,41 +367,47 @@ gh workflow run full-release-validation.yml \
|
||||
-f npm_telegram_provider_mode=mock-openai
|
||||
```
|
||||
|
||||
No uses el paraguas completo como primera reejecución después de una corrección enfocada. Si una caja
|
||||
falla, usa el flujo de trabajo hijo, el trabajo, la lane Docker, el perfil de paquete, el proveedor
|
||||
del modelo o la lane de QA fallidos para la siguiente prueba. Ejecuta de nuevo el paraguas completo solo cuando
|
||||
la corrección haya cambiado la orquestación compartida de lanzamiento o haya vuelto obsoleta la evidencia
|
||||
previa de todas las cajas. El verificador final del paraguas vuelve a comprobar los ids registrados de ejecución
|
||||
de flujos de trabajo hijos, así que después de que un flujo de trabajo hijo se reejecute correctamente, reejecuta solo el trabajo padre
|
||||
No uses el paraguas completo como primera reejecución después de una corrección
|
||||
focalizada. Si falla una caja, usa el flujo de trabajo hijo, trabajo, línea
|
||||
Docker, perfil de paquete, proveedor de modelo o línea QA fallidos para la
|
||||
siguiente prueba. Ejecuta de nuevo el paraguas completo solo cuando la corrección
|
||||
haya cambiado la orquestación compartida del lanzamiento o haya vuelto obsoleta
|
||||
la evidencia previa de todas las cajas. El verificador final del paraguas vuelve
|
||||
a comprobar los ids registrados de las ejecuciones de flujos de trabajo hijos, así que después de que un
|
||||
flujo de trabajo hijo se reejecute correctamente, reejecuta solo el trabajo padre
|
||||
`Verify full validation` fallido.
|
||||
|
||||
Para recuperación acotada, pasa `rerun_group` al paraguas. `all` es la ejecución real
|
||||
de candidato de lanzamiento, `ci` ejecuta solo el hijo de CI normal, `plugin-prerelease`
|
||||
ejecuta solo el hijo de Plugin exclusivo de lanzamiento, `release-checks` ejecuta todas las cajas
|
||||
de lanzamiento, y los grupos de lanzamiento más estrechos son `install-smoke`, `cross-os`,
|
||||
`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` y `npm-telegram`.
|
||||
Las reejecuciones enfocadas de `npm-telegram` requieren `npm_telegram_package_spec`; las ejecuciones full/all
|
||||
con `release_profile=full` usan el artefacto de paquete de release-checks.
|
||||
Para recuperación acotada, pasa `rerun_group` al paraguas. `all` es la ejecución
|
||||
real del candidato de lanzamiento, `ci` ejecuta solo el hijo de CI normal,
|
||||
`plugin-prerelease` ejecuta solo el hijo de plugin exclusivo del lanzamiento,
|
||||
`release-checks` ejecuta todas las cajas de lanzamiento, y los grupos de
|
||||
lanzamiento más estrechos son `install-smoke`, `cross-os`, `live-e2e`,
|
||||
`package`, `qa`, `qa-parity`, `qa-live` y `npm-telegram`.
|
||||
Las reejecuciones focalizadas de `npm-telegram` requieren `npm_telegram_package_spec`; las ejecuciones
|
||||
full/all con `release_profile=full` usan el artefacto de paquete de release-checks.
|
||||
|
||||
### Vitest
|
||||
|
||||
La caja Vitest es el flujo de trabajo hijo `CI` manual. La CI manual omite
|
||||
intencionadamente el alcance por cambios y fuerza el grafo normal de pruebas para el candidato
|
||||
de lanzamiento: fragmentos de Linux Node, fragmentos de plugins incluidos, contratos de canales, compatibilidad con Node 22,
|
||||
`check`, `check-additional`, build smoke, comprobaciones de documentación, Skills de Python, Windows, macOS, Android
|
||||
y i18n de Control UI.
|
||||
La caja de Vitest es el flujo de trabajo hijo manual `CI`. La CI manual omite
|
||||
intencionadamente el alcance por cambios y fuerza el grafo de pruebas normal
|
||||
para el candidato de lanzamiento: fragmentos de Linux Node, fragmentos de Plugins
|
||||
incluidos, contratos de canales, compatibilidad con Node 22, `check`,
|
||||
`check-additional`, smoke de compilación, comprobaciones de documentación, Skills
|
||||
de Python, Windows, macOS, Android y i18n de Control UI.
|
||||
|
||||
Usa esta caja para responder "¿el árbol de código fuente pasó toda la suite normal de pruebas?"
|
||||
No es lo mismo que la validación de producto de ruta de lanzamiento. Evidencia que conservar:
|
||||
Usa esta caja para responder "¿el árbol de código fuente pasó la suite normal
|
||||
completa de pruebas?". No es lo mismo que la validación de producto en ruta de
|
||||
lanzamiento. Evidencia que conservar:
|
||||
|
||||
- resumen de `Full Release Validation` que muestra la URL de ejecución de `CI` despachada
|
||||
- ejecución de `CI` en verde sobre el SHA de destino exacto
|
||||
- resumen de `Full Release Validation` que muestre la URL de la ejecución `CI` despachada
|
||||
- ejecución `CI` verde en el SHA de destino exacto
|
||||
- nombres de fragmentos fallidos o lentos de los trabajos de CI al investigar regresiones
|
||||
- artefactos de tiempos de Vitest como `.artifacts/vitest-shard-timings.json` cuando
|
||||
una ejecución necesita análisis de rendimiento
|
||||
- artefactos de temporización de Vitest, como `.artifacts/vitest-shard-timings.json`, cuando
|
||||
una ejecución necesite análisis de rendimiento
|
||||
|
||||
Ejecuta la CI manual directamente solo cuando el lanzamiento necesite CI normal determinista pero
|
||||
no las cajas de Docker, QA Lab, live, entre sistemas operativos o paquete:
|
||||
Ejecuta la CI manual directamente solo cuando el lanzamiento necesite CI normal
|
||||
determinista, pero no las cajas Docker, QA Lab, live, entre sistemas operativos
|
||||
o de paquetes:
|
||||
|
||||
```bash
|
||||
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
|
||||
@ -408,16 +416,16 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
|
||||
### Docker
|
||||
|
||||
La caja Docker vive en `OpenClaw Release Checks` mediante
|
||||
`openclaw-live-and-e2e-checks-reusable.yml`, además del flujo de trabajo en modo lanzamiento
|
||||
`install-smoke`. Valida el candidato de lanzamiento mediante entornos Docker empaquetados
|
||||
en lugar de solo pruebas a nivel de código fuente.
|
||||
`openclaw-live-and-e2e-checks-reusable.yml`, además del flujo de trabajo
|
||||
`install-smoke` en modo de lanzamiento. Valida el candidato de lanzamiento
|
||||
mediante entornos Docker empaquetados, no solo pruebas a nivel de fuente.
|
||||
|
||||
La cobertura Docker de lanzamiento incluye:
|
||||
|
||||
- install smoke completo con el install smoke global lento de Bun habilitado
|
||||
- preparación/reutilización de imagen smoke del Dockerfile raíz por SHA de destino, con trabajos smoke de QR,
|
||||
- smoke de instalación completo con el smoke de instalación global lenta de Bun habilitado
|
||||
- preparación/reutilización de imagen de smoke del Dockerfile raíz por SHA de destino, con trabajos de QR,
|
||||
raíz/Gateway e instalador/Bun ejecutándose como fragmentos install-smoke separados
|
||||
- lanes E2E del repositorio
|
||||
- líneas E2E del repositorio
|
||||
- fragmentos Docker de ruta de lanzamiento: `core`, `package-update-openai`,
|
||||
`package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`,
|
||||
`plugins-runtime-services`,
|
||||
@ -425,55 +433,58 @@ La cobertura Docker de lanzamiento incluye:
|
||||
`plugins-runtime-install-c`, `plugins-runtime-install-d`,
|
||||
`plugins-runtime-install-e`, `plugins-runtime-install-f`,
|
||||
`plugins-runtime-install-g` y `plugins-runtime-install-h`
|
||||
- cobertura de OpenWebUI dentro del fragmento `plugins-runtime-services` cuando se solicita
|
||||
- lanes divididas de instalación/desinstalación de plugins incluidos
|
||||
- cobertura de OpenWebUI dentro del fragmento `plugins-runtime-services` cuando se solicite
|
||||
- líneas divididas de instalación/desinstalación de Plugins incluidos
|
||||
`bundled-plugin-install-uninstall-0` hasta
|
||||
`bundled-plugin-install-uninstall-23`
|
||||
- suites live/E2E de proveedores y cobertura live de modelos Docker cuando las comprobaciones de lanzamiento
|
||||
incluyen suites live
|
||||
- suites de proveedores live/E2E y cobertura Docker de modelos live cuando las comprobaciones de lanzamiento
|
||||
incluyan suites live
|
||||
|
||||
Usa los artefactos Docker antes de reejecutar. El planificador de ruta de lanzamiento sube
|
||||
`.artifacts/docker-tests/` con registros de lanes, `summary.json`, `failures.json`,
|
||||
tiempos de fases, JSON de plan del planificador y comandos de reejecución. Para recuperación enfocada,
|
||||
usa `docker_lanes=<lane[,lane]>` en el flujo de trabajo reutilizable live/E2E en lugar de
|
||||
reejecutar todos los fragmentos de lanzamiento. Los comandos de reejecución generados incluyen el
|
||||
`package_artifact_run_id` previo y las entradas de imagen Docker preparada cuando están disponibles, para que una
|
||||
lane fallida pueda reutilizar el mismo tarball y las imágenes GHCR.
|
||||
Usa los artefactos Docker antes de reejecutar. El planificador de ruta de
|
||||
lanzamiento sube `.artifacts/docker-tests/` con registros de línea,
|
||||
`summary.json`, `failures.json`, tiempos de fase, JSON del plan del planificador
|
||||
y comandos de reejecución. Para recuperación focalizada, usa
|
||||
`docker_lanes=<lane[,lane]>` en el flujo de trabajo reutilizable live/E2E en vez de
|
||||
reejecutar todos los fragmentos de lanzamiento. Los comandos de reejecución
|
||||
generados incluyen `package_artifact_run_id` previo y entradas de imagen Docker
|
||||
preparada cuando están disponibles, de modo que una línea fallida pueda reutilizar
|
||||
el mismo tarball y las imágenes GHCR.
|
||||
|
||||
### QA Lab
|
||||
|
||||
La caja QA Lab también forma parte de `OpenClaw Release Checks`. Es la puerta de lanzamiento
|
||||
de comportamiento agéntico y a nivel de canales, separada de Vitest y de la mecánica
|
||||
de paquetes Docker.
|
||||
La caja QA Lab también forma parte de `OpenClaw Release Checks`. Es la puerta de
|
||||
lanzamiento de comportamiento agéntico y a nivel de canal, separada de la mecánica
|
||||
de paquetes de Vitest y Docker.
|
||||
|
||||
La cobertura QA Lab de lanzamiento incluye:
|
||||
La cobertura de QA Lab de lanzamiento incluye:
|
||||
|
||||
- lane de paridad mock que compara la lane candidata de OpenAI contra la línea base Opus 4.6
|
||||
usando el paquete de paridad agéntica
|
||||
- perfil rápido de QA Matrix en vivo usando el entorno `qa-live-shared`
|
||||
- lane de QA Telegram en vivo usando leases de credenciales de Convex CI
|
||||
- línea de paridad mock que compara la línea candidata OpenAI con la línea base
|
||||
Opus 4.6 usando el paquete de paridad agéntica
|
||||
- perfil rápido de QA Matrix live usando el entorno `qa-live-shared`
|
||||
- línea QA de Telegram live usando leases de credenciales CI de Convex
|
||||
- `pnpm qa:otel:smoke` cuando la telemetría de lanzamiento necesita prueba local explícita
|
||||
|
||||
Usa esta caja para responder "¿el lanzamiento se comporta correctamente en escenarios de QA y
|
||||
flujos de canales en vivo?" Conserva las URL de artefactos para las lanes de paridad, Matrix y Telegram
|
||||
al aprobar el lanzamiento. La cobertura completa de Matrix sigue disponible como una ejecución manual
|
||||
fragmentada de QA-Lab en lugar de la lane predeterminada crítica de lanzamiento.
|
||||
Usa esta caja para responder "¿el lanzamiento se comporta correctamente en escenarios
|
||||
QA y flujos de canales live?". Conserva las URLs de artefactos para las líneas de
|
||||
paridad, Matrix y Telegram al aprobar el lanzamiento. La cobertura completa de Matrix
|
||||
sigue disponible como una ejecución manual fragmentada de QA-Lab, no como la línea
|
||||
crítica de lanzamiento predeterminada.
|
||||
|
||||
### Paquete
|
||||
|
||||
La caja Package es la puerta del producto instalable. Está respaldada por
|
||||
`Package Acceptance` y el resolver
|
||||
`scripts/resolve-openclaw-package-candidate.mjs`. El resolver normaliza un
|
||||
candidato en el tarball `package-under-test` consumido por Docker E2E, valida
|
||||
el inventario del paquete, registra la versión del paquete y el SHA-256, y mantiene la
|
||||
referencia del arnés de flujo de trabajo separada de la referencia de origen del paquete.
|
||||
La caja Package es la puerta de producto instalable. Está respaldada por
|
||||
`Package Acceptance` y el resolutor
|
||||
`scripts/resolve-openclaw-package-candidate.mjs`. El resolutor normaliza un
|
||||
candidato en el tarball `package-under-test` consumido por Docker E2E, valida el
|
||||
inventario del paquete, registra la versión del paquete y el SHA-256, y mantiene
|
||||
la ref del arnés del flujo de trabajo separada de la ref fuente del paquete.
|
||||
|
||||
Fuentes de candidatos admitidas:
|
||||
|
||||
- `source=npm`: `openclaw@beta`, `openclaw@latest` o una versión exacta de lanzamiento de OpenClaw
|
||||
- `source=ref`: empaqueta una rama, etiqueta o SHA completo de commit de `package_ref` de confianza
|
||||
- `source=ref`: empaqueta una rama, etiqueta o SHA de commit completo de `package_ref` de confianza
|
||||
con el arnés `workflow_ref` seleccionado
|
||||
- `source=url`: descarga un `.tgz` HTTPS con `package_sha256` obligatorio
|
||||
- `source=url`: descarga un `.tgz` HTTPS con `package_sha256` requerido
|
||||
- `source=artifact`: reutiliza un `.tgz` subido por otra ejecución de GitHub Actions
|
||||
|
||||
`OpenClaw Release Checks` ejecuta Package Acceptance con `source=artifact`, el
|
||||
@ -481,37 +492,40 @@ artefacto de paquete de lanzamiento preparado, `suite_profile=custom`,
|
||||
`docker_lanes=doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update`,
|
||||
`published_upgrade_survivor_baselines=all-since-2026.4.23`,
|
||||
`published_upgrade_survivor_scenarios=reported-issues` y
|
||||
`telegram_mode=mock-openai`. Package Acceptance mantiene la migración, la actualización, la limpieza de dependencias
|
||||
obsoletas de plugins, fixtures de plugins offline, actualización de plugins y QA de paquete Telegram
|
||||
contra el mismo tarball resuelto. La matriz de actualización cubre todas las líneas base estables publicadas en npm desde `2026.4.23` hasta `latest`; usa
|
||||
Package Acceptance con `source=npm` para un candidato ya publicado, o
|
||||
`source=ref`/`source=artifact` para un tarball npm local respaldado por SHA antes de
|
||||
publicar. Es el reemplazo nativo de GitHub
|
||||
para la mayor parte de la cobertura de paquete/actualización que antes requería
|
||||
Parallels. Las comprobaciones de lanzamiento entre sistemas operativos siguen siendo importantes para onboarding,
|
||||
instalador y comportamiento específico de plataforma, pero la validación de producto de paquete/actualización debe
|
||||
preferir Package Acceptance.
|
||||
`telegram_mode=mock-openai`. Package Acceptance mantiene migración, actualización,
|
||||
limpieza de dependencias de Plugins obsoletas, fixtures de Plugins offline,
|
||||
actualización de Plugins y QA del paquete de Telegram contra el mismo tarball
|
||||
resuelto. La matriz de actualización cubre cada línea base stable publicada en npm desde `2026.4.23` hasta `latest`; usa
|
||||
Package Acceptance con `source=npm` para un candidato ya enviado, o
|
||||
`source=ref`/`source=artifact` para un tarball npm local respaldado por SHA antes
|
||||
de publicar. Es el reemplazo nativo de GitHub para la mayor parte de la cobertura
|
||||
de paquetes/actualizaciones que antes requería Parallels. Las comprobaciones de
|
||||
lanzamiento entre sistemas operativos siguen siendo importantes para onboarding,
|
||||
instalador y comportamiento de plataforma específicos del sistema operativo, pero
|
||||
la validación de producto de paquetes/actualizaciones debe preferir Package Acceptance.
|
||||
|
||||
La lista de verificación canónica para validación de actualizaciones y plugins es
|
||||
[Pruebas de actualizaciones y plugins](/es/help/testing-updates-plugins). Úsala al
|
||||
decidir qué lane local, Docker, Package Acceptance o de comprobación de lanzamiento prueba un
|
||||
cambio de instalación/actualización de Plugin, limpieza de doctor o migración de paquete publicado.
|
||||
La migración exhaustiva de actualización publicada desde todos los paquetes estables `2026.4.23+` es
|
||||
un flujo de trabajo manual separado `Update Migration`, no parte de Full Release CI.
|
||||
La lista canónica para validación de actualizaciones y Plugins es
|
||||
[probar actualizaciones y Plugins](/es/help/testing-updates-plugins). Úsala al
|
||||
decidir qué línea local, Docker, Package Acceptance o release-check prueba un
|
||||
cambio de instalación/actualización de Plugin, limpieza de doctor o migración de
|
||||
paquete publicado. La migración exhaustiva de actualización publicada desde cada
|
||||
paquete stable `2026.4.23+` es un flujo de trabajo manual separado `Update Migration`,
|
||||
no parte de Full Release CI.
|
||||
|
||||
La tolerancia heredada de package-acceptance está intencionadamente limitada en el tiempo. Los paquetes hasta
|
||||
`2026.4.25` pueden usar la ruta de compatibilidad para huecos de metadatos ya publicados
|
||||
en npm: entradas privadas de inventario de QA ausentes del tarball, falta de
|
||||
`gateway install --wrapper`, archivos de parches ausentes en el fixture git derivado del tarball,
|
||||
falta de `update.channel` persistido, ubicaciones heredadas de registros de instalación de plugins,
|
||||
falta de persistencia de registros de instalación de marketplace y migración de metadatos de configuración
|
||||
durante `plugins update`. El paquete publicado `2026.4.26` puede advertir
|
||||
por archivos de sello de metadatos de compilación local que ya se enviaron. Los paquetes posteriores
|
||||
deben satisfacer los contratos modernos de paquete; esos mismos huecos fallan la validación
|
||||
de lanzamiento.
|
||||
`2026.4.25` pueden usar la ruta de compatibilidad para vacíos de metadatos ya publicados
|
||||
en npm: entradas privadas de inventario QA ausentes del tarball, falta de
|
||||
`gateway install --wrapper`, archivos de parche ausentes en el fixture git
|
||||
derivado del tarball, falta de persistencia de `update.channel`, ubicaciones
|
||||
heredadas de registro de instalación de Plugins, falta de persistencia de
|
||||
registro de instalación de marketplace y migración de metadatos de configuración
|
||||
durante `plugins update`. El paquete publicado `2026.4.26` puede advertir sobre
|
||||
archivos de marca de metadatos de compilación local que ya se enviaron. Los paquetes
|
||||
posteriores deben satisfacer los contratos de paquete modernos; esos mismos vacíos
|
||||
fallan la validación de lanzamiento.
|
||||
|
||||
Usa perfiles más amplios de Package Acceptance cuando la pregunta de lanzamiento sea sobre un
|
||||
paquete instalable real:
|
||||
Usa perfiles más amplios de Package Acceptance cuando la pregunta del lanzamiento
|
||||
sea sobre un paquete realmente instalable:
|
||||
|
||||
```bash
|
||||
gh workflow run package-acceptance.yml \
|
||||
@ -523,33 +537,34 @@ gh workflow run package-acceptance.yml \
|
||||
-f published_upgrade_survivor_baseline=openclaw@2026.4.26
|
||||
```
|
||||
|
||||
Perfiles comunes de paquete:
|
||||
Perfiles de paquete comunes:
|
||||
|
||||
- `smoke`: lanes rápidas de instalación de paquete/canal/agente, red de Gateway y
|
||||
- `smoke`: líneas rápidas de instalación de paquete/canal/agente, red de Gateway y
|
||||
recarga de configuración
|
||||
- `package`: contratos de paquete de instalación/actualización/Plugin sin ClawHub live; este es el valor predeterminado
|
||||
de release-check
|
||||
- `package`: contratos de paquete de instalación/actualización/Plugin sin ClawHub live; este es el valor
|
||||
predeterminado de release-check
|
||||
- `product`: `package` más canales MCP, limpieza de cron/subagente, búsqueda web de OpenAI
|
||||
y OpenWebUI
|
||||
- `full`: fragmentos Docker de ruta de lanzamiento con OpenWebUI
|
||||
- `custom`: lista exacta de `docker_lanes` para reejecuciones enfocadas
|
||||
- `custom`: lista exacta de `docker_lanes` para reejecuciones focalizadas
|
||||
|
||||
Para la prueba de Telegram del paquete candidato, habilita `telegram_mode=mock-openai` o
|
||||
Para la prueba de Telegram de candidato de paquete, habilita `telegram_mode=mock-openai` o
|
||||
`telegram_mode=live-frontier` en Package Acceptance. El flujo de trabajo pasa el
|
||||
tarball `package-under-test` resuelto al carril de Telegram; el flujo de trabajo
|
||||
independiente de Telegram todavía acepta una especificación npm publicada para comprobaciones posteriores a la publicación.
|
||||
independiente de Telegram aún acepta una especificación npm publicada para comprobaciones posteriores a la publicación.
|
||||
|
||||
## Automatización de publicación de versiones
|
||||
## Automatización de publicación de lanzamientos
|
||||
|
||||
`OpenClaw Release Publish` es el punto de entrada normal para publicaciones mutables. Orquesta los flujos de trabajo de publicador de confianza en el orden que la versión requiere:
|
||||
`OpenClaw Release Publish` es el punto de entrada mutante normal de publicación. Orquesta
|
||||
los flujos de trabajo de publicador de confianza en el orden que necesita el lanzamiento:
|
||||
|
||||
1. Extrae la etiqueta de versión y resuelve su SHA de commit.
|
||||
1. Extrae la etiqueta de lanzamiento y resuelve su SHA de commit.
|
||||
2. Verifica que la etiqueta sea alcanzable desde `main` o `release/*`.
|
||||
3. Ejecuta `pnpm plugins:sync:check`.
|
||||
4. Lanza `Plugin NPM Release` con `publish_scope=all-publishable` y
|
||||
4. Activa `Plugin NPM Release` con `publish_scope=all-publishable` y
|
||||
`ref=<release-sha>`.
|
||||
5. Lanza `Plugin ClawHub Release` con el mismo alcance y SHA.
|
||||
6. Lanza `OpenClaw NPM Release` con la etiqueta de versión, la dist-tag de npm y
|
||||
5. Activa `Plugin ClawHub Release` con el mismo alcance y SHA.
|
||||
6. Activa `OpenClaw NPM Release` con la etiqueta de lanzamiento, el dist-tag de npm y
|
||||
el `preflight_run_id` guardado.
|
||||
|
||||
Ejemplo de publicación beta:
|
||||
@ -562,17 +577,7 @@ gh workflow run openclaw-release-publish.yml \
|
||||
-f npm_dist_tag=beta
|
||||
```
|
||||
|
||||
Ejemplo de publicación alfa:
|
||||
|
||||
```bash
|
||||
gh workflow run openclaw-release-publish.yml \
|
||||
--ref release/YYYY.M.D \
|
||||
-f tag=vYYYY.M.D-alpha.N \
|
||||
-f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
|
||||
-f npm_dist_tag=alpha
|
||||
```
|
||||
|
||||
Publicación estable a la dist-tag beta predeterminada:
|
||||
Publicación estable al dist-tag beta predeterminado:
|
||||
|
||||
```bash
|
||||
gh workflow run openclaw-release-publish.yml \
|
||||
@ -593,88 +598,90 @@ gh workflow run openclaw-release-publish.yml \
|
||||
```
|
||||
|
||||
Usa los flujos de trabajo de nivel inferior `Plugin NPM Release` y `Plugin ClawHub Release`
|
||||
solo para trabajos específicos de reparación o republicación. Para una reparación de plugin seleccionado, pasa
|
||||
solo para trabajos enfocados de reparación o republicación. Para una reparación de plugin seleccionado, pasa
|
||||
`plugin_publish_scope=selected` y `plugins=@openclaw/name` a
|
||||
`OpenClaw Release Publish`, o lanza directamente el flujo de trabajo secundario cuando el
|
||||
paquete OpenClaw no deba publicarse.
|
||||
`OpenClaw Release Publish`, o activa el flujo de trabajo hijo directamente cuando el
|
||||
paquete de OpenClaw no deba publicarse.
|
||||
|
||||
## Entradas del flujo de trabajo de NPM
|
||||
## Entradas del flujo de trabajo NPM
|
||||
|
||||
`OpenClaw NPM Release` acepta estas entradas controladas por el operador:
|
||||
|
||||
- `tag`: etiqueta de versión obligatoria como `v2026.4.2`, `v2026.4.2-1`, o
|
||||
`v2026.4.2-alpha.1` o `v2026.4.2-beta.1`; cuando `preflight_only=true`, también puede ser el SHA de commit completo de 40 caracteres actual de la rama del flujo de trabajo para una comprobación previa solo de validación
|
||||
- `preflight_only`: `true` solo para validación/compilación/paquetización, `false` para la
|
||||
- `tag`: etiqueta de lanzamiento requerida, como `v2026.4.2`, `v2026.4.2-1` o
|
||||
`v2026.4.2-beta.1`; cuando `preflight_only=true`, también puede ser el SHA de commit
|
||||
completo de 40 caracteres de la rama del flujo de trabajo actual para una comprobación previa solo de validación
|
||||
- `preflight_only`: `true` solo para validación/compilación/paquete, `false` para la
|
||||
ruta de publicación real
|
||||
- `preflight_run_id`: obligatorio en la ruta de publicación real para que el flujo de trabajo reutilice
|
||||
el tarball preparado de la ejecución previa correcta
|
||||
- `npm_dist_tag`: etiqueta npm de destino para la ruta de publicación; por defecto es `beta`
|
||||
- `preflight_run_id`: requerido en la ruta de publicación real para que el flujo de trabajo reutilice
|
||||
el tarball preparado de la ejecución de comprobación previa correcta
|
||||
- `npm_dist_tag`: etiqueta de destino de npm para la ruta de publicación; el valor predeterminado es `beta`
|
||||
|
||||
`OpenClaw Release Publish` acepta estas entradas controladas por el operador:
|
||||
|
||||
- `tag`: etiqueta de versión obligatoria; ya debe existir
|
||||
- `preflight_run_id`: id de ejecución previa correcta de `OpenClaw NPM Release`;
|
||||
obligatorio cuando `publish_openclaw_npm=true`
|
||||
- `npm_dist_tag`: etiqueta npm de destino para el paquete OpenClaw
|
||||
- `plugin_publish_scope`: por defecto es `all-publishable`; usa `selected` solo
|
||||
para trabajos específicos de reparación
|
||||
- `tag`: etiqueta de lanzamiento requerida; ya debe existir
|
||||
- `preflight_run_id`: id de ejecución de comprobación previa correcta de `OpenClaw NPM Release`;
|
||||
requerido cuando `publish_openclaw_npm=true`
|
||||
- `npm_dist_tag`: etiqueta de destino de npm para el paquete OpenClaw
|
||||
- `plugin_publish_scope`: el valor predeterminado es `all-publishable`; usa `selected` solo
|
||||
para trabajos enfocados de reparación
|
||||
- `plugins`: nombres de paquetes `@openclaw/*` separados por comas cuando
|
||||
`plugin_publish_scope=selected`
|
||||
- `publish_openclaw_npm`: por defecto es `true`; configúralo en `false` solo cuando uses el
|
||||
- `publish_openclaw_npm`: el valor predeterminado es `true`; establece `false` solo cuando uses el
|
||||
flujo de trabajo como orquestador de reparación solo para plugins
|
||||
|
||||
`OpenClaw Release Checks` acepta estas entradas controladas por el operador:
|
||||
|
||||
- `ref`: rama, etiqueta o SHA de commit completo que se debe validar. Las comprobaciones con secretos
|
||||
- `ref`: rama, etiqueta o SHA de commit completo para validar. Las comprobaciones que contienen secretos
|
||||
requieren que el commit resuelto sea alcanzable desde una rama de OpenClaw o
|
||||
una etiqueta de versión.
|
||||
una etiqueta de lanzamiento.
|
||||
|
||||
Reglas:
|
||||
|
||||
- Las etiquetas estables y de corrección pueden publicarse en `beta` o `latest`
|
||||
- Las etiquetas de versión preliminar alfa solo pueden publicarse en `alpha`
|
||||
- Las etiquetas de versión preliminar beta solo pueden publicarse en `beta`
|
||||
- Las etiquetas de prelanzamiento beta solo pueden publicarse en `beta`
|
||||
- Para `OpenClaw NPM Release`, la entrada de SHA de commit completo solo se permite cuando
|
||||
`preflight_only=true`
|
||||
- `OpenClaw Release Checks` y `Full Release Validation` son siempre
|
||||
solo de validación
|
||||
- La ruta de publicación real debe usar el mismo `npm_dist_tag` usado durante la comprobación previa;
|
||||
el flujo de trabajo verifica esos metadatos antes de continuar con la publicación
|
||||
el flujo de trabajo verifica esos metadatos antes de que la publicación continúe
|
||||
|
||||
## Secuencia de versión npm estable
|
||||
## Secuencia de lanzamiento estable de npm
|
||||
|
||||
Al preparar una versión npm estable:
|
||||
Al preparar un lanzamiento estable de npm:
|
||||
|
||||
1. Ejecuta `OpenClaw NPM Release` con `preflight_only=true`
|
||||
- Antes de que exista una etiqueta, puedes usar el SHA de commit completo actual de la rama del flujo de trabajo para una ejecución de prueba solo de validación del flujo de trabajo de comprobación previa
|
||||
2. Elige `npm_dist_tag=beta` para el flujo normal de beta primero, o `latest` solo
|
||||
- Antes de que exista una etiqueta, puedes usar el SHA de commit completo de la rama del flujo de trabajo actual
|
||||
para una ejecución de prueba solo de validación del flujo de trabajo de comprobación previa
|
||||
2. Elige `npm_dist_tag=beta` para el flujo normal beta primero, o `latest` solo
|
||||
cuando quieras intencionalmente una publicación estable directa
|
||||
3. Ejecuta `Full Release Validation` en la rama de versión, la etiqueta de versión o el SHA de commit completo cuando quieras CI normal más cobertura de caché de prompts en vivo, Docker, QA Lab,
|
||||
3. Ejecuta `Full Release Validation` en la rama de lanzamiento, la etiqueta de lanzamiento o el SHA de commit completo
|
||||
cuando quieras CI normal más cobertura de caché de prompts en vivo, Docker, QA Lab,
|
||||
Matrix y Telegram desde un único flujo de trabajo manual
|
||||
4. Si intencionalmente solo necesitas el grafo de pruebas normal determinista, ejecuta el
|
||||
flujo de trabajo manual `CI` en la referencia de versión en su lugar
|
||||
flujo de trabajo manual `CI` en la ref de lanzamiento en su lugar
|
||||
5. Guarda el `preflight_run_id` correcto
|
||||
6. Ejecuta `OpenClaw Release Publish` con el mismo `tag`, el mismo `npm_dist_tag`,
|
||||
y el `preflight_run_id` guardado; publica plugins externalizados en npm
|
||||
6. Ejecuta `OpenClaw Release Publish` con la misma `tag`, el mismo `npm_dist_tag`
|
||||
y el `preflight_run_id` guardado; publica los plugins externalizados en npm
|
||||
y ClawHub antes de promover el paquete npm de OpenClaw
|
||||
7. Si la versión quedó en `beta`, usa el flujo de trabajo privado
|
||||
7. Si el lanzamiento quedó en `beta`, usa el flujo de trabajo privado
|
||||
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
|
||||
para promover esa versión estable de `beta` a `latest`
|
||||
8. Si la versión se publicó intencionalmente directamente en `latest` y `beta`
|
||||
debe seguir inmediatamente la misma compilación estable, usa ese mismo flujo de trabajo privado
|
||||
para apuntar ambas dist-tags a la versión estable, o deja que su sincronización programada
|
||||
de autocorrección mueva `beta` más tarde
|
||||
8. Si el lanzamiento se publicó intencionalmente directamente en `latest` y `beta`
|
||||
debe seguir de inmediato la misma compilación estable, usa ese mismo flujo de trabajo privado
|
||||
para apuntar ambos dist-tags a la versión estable, o deja que su sincronización programada
|
||||
de autorreparación mueva `beta` más tarde
|
||||
|
||||
La mutación de dist-tag vive en el repo privado por seguridad, porque todavía
|
||||
requiere `NPM_TOKEN`, mientras que el repo público mantiene la publicación solo con OIDC.
|
||||
La mutación de dist-tag vive en el repositorio privado por seguridad porque aún
|
||||
requiere `NPM_TOKEN`, mientras que el repositorio público mantiene publicación solo con OIDC.
|
||||
|
||||
Eso mantiene tanto la ruta de publicación directa como la ruta de promoción con beta primero
|
||||
Eso mantiene tanto la ruta de publicación directa como la ruta de promoción beta primero
|
||||
documentadas y visibles para el operador.
|
||||
|
||||
Si un mantenedor debe recurrir a la autenticación npm local, ejecuta cualquier comando de la
|
||||
CLI de 1Password (`op`) solo dentro de una sesión tmux dedicada. No llames a `op`
|
||||
directamente desde el shell principal del agente; mantenerlo dentro de tmux hace que los prompts,
|
||||
alertas y gestión de OTP sean observables y evita alertas repetidas del host.
|
||||
Si un maintainer debe recurrir a autenticación npm local, ejecuta cualquier comando de la CLI
|
||||
de 1Password (`op`) solo dentro de una sesión tmux dedicada. No llames a `op`
|
||||
directamente desde la shell principal del agente; mantenerlo dentro de tmux hace que los prompts,
|
||||
las alertas y el manejo de OTP sean observables y evita alertas repetidas del host.
|
||||
|
||||
## Referencias públicas
|
||||
|
||||
@ -688,7 +695,7 @@ alertas y gestión de OTP sean observables y evita alertas repetidas del host.
|
||||
- [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh)
|
||||
- [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh)
|
||||
|
||||
Los mantenedores usan la documentación privada de versiones en
|
||||
Los maintainers usan la documentación privada de lanzamientos en
|
||||
[`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
|
||||
para el runbook real.
|
||||
|
||||
|
||||
@ -1,152 +1,153 @@
|
||||
---
|
||||
read_when:
|
||||
- Quieres operar el Gateway desde un navegador
|
||||
- Desea operar el Gateway desde un navegador
|
||||
- Quieres acceso a Tailnet sin túneles SSH
|
||||
sidebarTitle: Control UI
|
||||
summary: Interfaz de control basada en navegador para el Gateway (chat, nodos, configuración)
|
||||
title: Interfaz de control
|
||||
x-i18n:
|
||||
generated_at: "2026-05-02T21:07:40Z"
|
||||
generated_at: "2026-05-02T23:39:11Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 88959ccf435b31015039bf28c3043023d99f0b953a1489986ab2d0cbd261771c
|
||||
source_hash: 50bef807915f27406e19f1c6ca7d839a610d79ba79da85d7a78523400cbf9208
|
||||
source_path: web/control-ui.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
La Control UI es una pequeña aplicación de página única **Vite + Lit** servida por el Gateway:
|
||||
La Control UI es una pequeña aplicación de una sola página **Vite + Lit** servida por el Gateway:
|
||||
|
||||
- predeterminado: `http://<host>:18789/`
|
||||
- prefijo opcional: configura `gateway.controlUi.basePath` (p. ej., `/openclaw`)
|
||||
- prefijo opcional: configura `gateway.controlUi.basePath` (por ejemplo, `/openclaw`)
|
||||
|
||||
Se comunica **directamente con el WebSocket del Gateway** en el mismo puerto.
|
||||
|
||||
## Apertura rápida (local)
|
||||
|
||||
Si el Gateway se está ejecutando en la misma computadora, abre:
|
||||
Si el Gateway se está ejecutando en el mismo equipo, abre:
|
||||
|
||||
- [http://127.0.0.1:18789/](http://127.0.0.1:18789/) (o [http://localhost:18789/](http://localhost:18789/))
|
||||
|
||||
Si la página no se carga, inicia primero el Gateway: `openclaw gateway`.
|
||||
Si la página no carga, inicia primero el Gateway: `openclaw gateway`.
|
||||
|
||||
La autenticación se suministra durante el protocolo de enlace de WebSocket mediante:
|
||||
La autenticación se proporciona durante el handshake de WebSocket mediante:
|
||||
|
||||
- `connect.params.auth.token`
|
||||
- `connect.params.auth.password`
|
||||
- encabezados de identidad de Tailscale Serve cuando `gateway.auth.allowTailscale: true`
|
||||
- encabezados de identidad de proxy de confianza cuando `gateway.auth.mode: "trusted-proxy"`
|
||||
|
||||
El panel de ajustes del panel de control conserva un token para la sesión actual de la pestaña del navegador y la URL del gateway seleccionada; las contraseñas no se persisten. El proceso de incorporación suele generar un token de gateway para la autenticación con secreto compartido en la primera conexión, pero la autenticación con contraseña también funciona cuando `gateway.auth.mode` es `"password"`.
|
||||
El panel de configuración del dashboard conserva un token para la sesión de la pestaña actual del navegador y la URL del Gateway seleccionada; las contraseñas no se conservan. El onboarding normalmente genera un token del Gateway para la autenticación con secreto compartido en la primera conexión, pero la autenticación con contraseña también funciona cuando `gateway.auth.mode` es `"password"`.
|
||||
|
||||
## Emparejamiento de dispositivos (primera conexión)
|
||||
## Emparejamiento de dispositivo (primera conexión)
|
||||
|
||||
Cuando te conectas a la Control UI desde un navegador o dispositivo nuevo, el Gateway normalmente requiere una **aprobación de emparejamiento de un solo uso**. Es una medida de seguridad para evitar accesos no autorizados.
|
||||
Cuando te conectas a la Control UI desde un navegador o dispositivo nuevo, el Gateway normalmente requiere una **aprobación de emparejamiento de una sola vez**. Esta es una medida de seguridad para impedir el acceso no autorizado.
|
||||
|
||||
**Lo que verás:** "desconectado (1008): se requiere emparejamiento"
|
||||
**Lo que verás:** "disconnected (1008): pairing required"
|
||||
|
||||
<Steps>
|
||||
<Step title="Enumerar solicitudes pendientes">
|
||||
<Step title="List pending requests">
|
||||
```bash
|
||||
openclaw devices list
|
||||
```
|
||||
</Step>
|
||||
<Step title="Aprobar por ID de solicitud">
|
||||
<Step title="Approve by request ID">
|
||||
```bash
|
||||
openclaw devices approve <requestId>
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
Si el navegador reintenta el emparejamiento con detalles de autenticación modificados (rol/ámbitos/clave pública), la solicitud pendiente anterior queda reemplazada y se crea un nuevo `requestId`. Vuelve a ejecutar `openclaw devices list` antes de aprobar.
|
||||
Si el navegador vuelve a intentar el emparejamiento con detalles de autenticación cambiados (rol/alcances/clave pública), la solicitud pendiente anterior queda reemplazada y se crea un nuevo `requestId`. Vuelve a ejecutar `openclaw devices list` antes de aprobar.
|
||||
|
||||
Si el navegador ya está emparejado y lo cambias de acceso de lectura a acceso de escritura/administración, esto se trata como una actualización de aprobación, no como una reconexión silenciosa. OpenClaw mantiene activa la aprobación anterior, bloquea la reconexión con mayor alcance y te pide que apruebes explícitamente el nuevo conjunto de ámbitos.
|
||||
Si el navegador ya está emparejado y lo cambias de acceso de lectura a acceso de escritura/admin, esto se trata como una actualización de aprobación, no como una reconexión silenciosa. OpenClaw mantiene activa la aprobación anterior, bloquea la reconexión más amplia y te pide que apruebes explícitamente el nuevo conjunto de alcances.
|
||||
|
||||
Una vez aprobado, el dispositivo se recuerda y no requerirá una nueva aprobación salvo que lo revoques con `openclaw devices revoke --device <id> --role <role>`. Consulta [CLI de dispositivos](/es/cli/devices) para la rotación y revocación de tokens.
|
||||
Una vez aprobado, el dispositivo se recuerda y no requerirá una nueva aprobación a menos que lo revoques con `openclaw devices revoke --device <id> --role <role>`. Consulta [CLI de dispositivos](/es/cli/devices) para la rotación y revocación de tokens.
|
||||
|
||||
<Note>
|
||||
- Las conexiones directas desde navegador por local loopback (`127.0.0.1` / `localhost`) se aprueban automáticamente.
|
||||
- Tailscale Serve puede omitir el viaje de ida y vuelta de emparejamiento para sesiones de operador de la Control UI cuando `gateway.auth.allowTailscale: true`, la identidad de Tailscale se verifica y el navegador presenta su identidad de dispositivo.
|
||||
- Los enlaces directos a Tailnet, las conexiones de navegador por LAN y los perfiles de navegador sin identidad de dispositivo todavía requieren aprobación explícita.
|
||||
- Las conexiones directas del navegador por local loopback (`127.0.0.1` / `localhost`) se aprueban automáticamente.
|
||||
- Tailscale Serve puede omitir la ida y vuelta de emparejamiento para las sesiones de operador de la Control UI cuando `gateway.auth.allowTailscale: true`, se verifica la identidad de Tailscale y el navegador presenta su identidad de dispositivo.
|
||||
- Los enlaces directos a Tailnet, las conexiones de navegador por LAN y los perfiles de navegador sin identidad de dispositivo siguen requiriendo aprobación explícita.
|
||||
- Cada perfil de navegador genera un ID de dispositivo único, por lo que cambiar de navegador o borrar los datos del navegador requerirá volver a emparejar.
|
||||
|
||||
</Note>
|
||||
|
||||
## Identidad personal (local del navegador)
|
||||
|
||||
La Control UI admite una identidad personal por navegador (nombre para mostrar y avatar) adjunta a los mensajes salientes para atribución en sesiones compartidas. Vive en el almacenamiento del navegador, está limitada al perfil de navegador actual y no se sincroniza con otros dispositivos ni se persiste del lado del servidor más allá de los metadatos normales de autoría de transcripciones en los mensajes que realmente envías. Borrar los datos del sitio o cambiar de navegador la restablece a vacío.
|
||||
La Control UI admite una identidad personal por navegador (nombre visible y avatar) adjunta a los mensajes salientes para la atribución en sesiones compartidas. Vive en el almacenamiento del navegador, está limitada al perfil actual del navegador y no se sincroniza con otros dispositivos ni se conserva del lado del servidor más allá de los metadatos normales de autoría de transcripción en los mensajes que realmente envías. Borrar los datos del sitio o cambiar de navegador la restablece a vacío.
|
||||
|
||||
El mismo patrón local del navegador se aplica a la anulación del avatar del asistente. Los avatares de asistente cargados se superponen a la identidad resuelta por el gateway solo en el navegador local y nunca hacen un viaje de ida y vuelta a través de `config.patch`. El campo de configuración compartido `ui.assistant.avatar` sigue disponible para clientes que no son UI y escriben el campo directamente (como gateways con scripts o paneles de control personalizados).
|
||||
El mismo patrón local del navegador se aplica a la anulación del avatar del asistente. Los avatares de asistente subidos se superponen a la identidad resuelta por el Gateway solo en el navegador local y nunca hacen una ida y vuelta mediante `config.patch`. El campo de configuración compartida `ui.assistant.avatar` sigue disponible para clientes que no son de la UI y escriben el campo directamente (como gateways con scripts o dashboards personalizados).
|
||||
|
||||
## Endpoint de configuración en tiempo de ejecución
|
||||
|
||||
La Control UI obtiene sus ajustes en tiempo de ejecución desde `/__openclaw/control-ui-config.json`. Ese endpoint está protegido por la misma autenticación del gateway que el resto de la superficie HTTP: los navegadores no autenticados no pueden obtenerlo, y una obtención correcta requiere un token/contraseña de gateway ya válido, una identidad de Tailscale Serve o una identidad de proxy de confianza.
|
||||
La Control UI obtiene su configuración en tiempo de ejecución desde `/__openclaw/control-ui-config.json`. Ese endpoint está protegido por la misma autenticación del Gateway que el resto de la superficie HTTP: los navegadores no autenticados no pueden obtenerlo, y una obtención correcta requiere un token/contraseña de Gateway ya válido, identidad de Tailscale Serve o una identidad de proxy de confianza.
|
||||
|
||||
## Compatibilidad de idioma
|
||||
## Compatibilidad de idiomas
|
||||
|
||||
La Control UI puede localizarse automáticamente en la primera carga según la configuración regional de tu navegador. Para anularla más tarde, abre **Overview -> Gateway Access -> Language**. El selector de configuración regional se encuentra en la tarjeta Gateway Access, no en Appearance.
|
||||
La Control UI puede localizarse en la primera carga según el idioma de tu navegador. Para anularlo más tarde, abre **Resumen -> Acceso al Gateway -> Idioma**. El selector de idioma está en la tarjeta Acceso al Gateway, no en Apariencia.
|
||||
|
||||
- Configuraciones regionales admitidas: `en`, `zh-CN`, `zh-TW`, `pt-BR`, `de`, `es`, `ja-JP`, `ko`, `fr`, `ar`, `it`, `tr`, `uk`, `id`, `pl`, `th`, `vi`, `nl`, `fa`
|
||||
- Idiomas compatibles: `en`, `zh-CN`, `zh-TW`, `pt-BR`, `de`, `es`, `ja-JP`, `ko`, `fr`, `ar`, `it`, `tr`, `uk`, `id`, `pl`, `th`, `vi`, `nl`, `fa`
|
||||
- Las traducciones que no son al inglés se cargan de forma diferida en el navegador.
|
||||
- La configuración regional seleccionada se guarda en el almacenamiento del navegador y se reutiliza en visitas futuras.
|
||||
- El idioma seleccionado se guarda en el almacenamiento del navegador y se reutiliza en visitas futuras.
|
||||
- Las claves de traducción faltantes recurren al inglés.
|
||||
|
||||
Las traducciones de la documentación se generan para el mismo conjunto de configuraciones regionales no inglesas, pero el selector de idiomas integrado del sitio de documentación de Mintlify está limitado a los códigos de configuración regional que Mintlify acepta. La documentación en tailandés (`th`) y persa (`fa`) todavía se genera en el repositorio de publicación; es posible que no aparezca en ese selector hasta que Mintlify admita esos códigos.
|
||||
Las traducciones de la documentación se generan para el mismo conjunto de idiomas que no son inglés, pero el selector de idiomas integrado del sitio de documentación de Mintlify está limitado a los códigos de idioma que Mintlify acepta. La documentación en tailandés (`th`) y persa (`fa`) aún se genera en el repositorio de publicación; puede que no aparezca en ese selector hasta que Mintlify admita esos códigos.
|
||||
|
||||
## Temas de apariencia
|
||||
|
||||
El panel Appearance mantiene los temas integrados Claw, Knot y Dash, además de un espacio de importación tweakcn local del navegador. Para importar un tema, abre [temas de tweakcn](https://tweakcn.com/themes), elige o crea un tema, haz clic en **Share** y pega el enlace del tema copiado en Appearance. El importador también acepta URL de registro `https://tweakcn.com/r/themes/<id>`, URL de editor como `https://tweakcn.com/editor/theme?theme=amethyst-haze`, rutas relativas `/themes/<id>`, ID de tema sin procesar y nombres de tema predeterminados como `amethyst-haze`.
|
||||
El panel Apariencia conserva los temas integrados Claw, Knot y Dash, además de una ranura de importación tweakcn local del navegador. Para importar un tema, abre [temas de tweakcn](https://tweakcn.com/themes), elige o crea un tema, haz clic en **Compartir** y pega el enlace de tema copiado en Apariencia. El importador también acepta URL de registro `https://tweakcn.com/r/themes/<id>`, URL de editor como `https://tweakcn.com/editor/theme?theme=amethyst-haze`, rutas relativas `/themes/<id>`, ID de tema sin procesar y nombres de tema predeterminados como `amethyst-haze`.
|
||||
|
||||
Los temas importados se almacenan solo en el perfil de navegador actual. No se escriben en la configuración del gateway y no se sincronizan entre dispositivos. Reemplazar el tema importado actualiza el único espacio local; borrarlo cambia el tema activo de vuelta a Claw si el tema importado estaba seleccionado.
|
||||
Los temas importados se almacenan solo en el perfil actual del navegador. No se escriben en la configuración del Gateway y no se sincronizan entre dispositivos. Reemplazar el tema importado actualiza la única ranura local; borrarlo cambia el tema activo de vuelta a Claw si el tema importado estaba seleccionado.
|
||||
|
||||
## Qué puede hacer (hoy)
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Chat y Talk">
|
||||
- Chatea con el modelo mediante Gateway WS (`chat.history`, `chat.send`, `chat.abort`, `chat.inject`).
|
||||
- Habla mediante sesiones en tiempo real del navegador. OpenAI usa WebRTC directo, Google Live usa un token de navegador restringido de un solo uso sobre WebSocket, y los plugins de voz en tiempo real solo de backend usan el transporte de retransmisión del Gateway. La retransmisión mantiene las credenciales del proveedor en el Gateway mientras el navegador transmite PCM del micrófono a través de RPC `talk.realtime.relay*` y envía llamadas de herramienta `openclaw_agent_consult` de vuelta a través de `chat.send` para el modelo OpenClaw configurado más grande.
|
||||
- Transmite llamadas de herramienta + tarjetas de salida de herramienta en vivo en Chat (eventos del agente).
|
||||
<Accordion title="Chat and Talk">
|
||||
- Chatear con el modelo mediante Gateway WS (`chat.history`, `chat.send`, `chat.abort`, `chat.inject`).
|
||||
- Dictar en el compositor de Chat con STT del lado del servidor (`chat.transcribeAudio`). El navegador graba un clip corto del micrófono y lo envía al Gateway, que ejecuta el pipeline de transcripción `tools.media.audio` configurado y devuelve texto borrador sin exponer las credenciales del proveedor al navegador.
|
||||
- Hablar mediante sesiones en tiempo real del navegador. OpenAI usa WebRTC directo, Google Live usa un token de navegador restringido de un solo uso sobre WebSocket, y los plugins de voz en tiempo real solo de backend usan el transporte de retransmisión del Gateway. La retransmisión conserva las credenciales del proveedor en el Gateway mientras el navegador transmite PCM de micrófono mediante RPC `talk.realtime.relay*` y envía llamadas de herramienta `openclaw_agent_consult` de vuelta mediante `chat.send` para el modelo OpenClaw configurado más grande.
|
||||
- Transmitir llamadas de herramienta + tarjetas de salida de herramienta en vivo en Chat (eventos del agente).
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Canales, instancias, sesiones, sueños">
|
||||
- Canales: estado de canales integrados y de plugins incluidos/externos, inicio de sesión QR y configuración por canal (`channels.status`, `web.login.*`, `config.patch`).
|
||||
<Accordion title="Channels, instances, sessions, dreams">
|
||||
- Canales: estado de canales integrados más canales de plugin agrupados/externos, inicio de sesión con QR y configuración por canal (`channels.status`, `web.login.*`, `config.patch`).
|
||||
- Instancias: lista de presencia + actualización (`system-presence`).
|
||||
- Sesiones: lista + anulaciones por sesión de modelo/pensamiento/rápido/detallado/traza/razonamiento (`sessions.list`, `sessions.patch`).
|
||||
- Sueños: estado de Dreaming, interruptor de habilitar/deshabilitar y lector de Diario de Sueños (`doctor.memory.status`, `doctor.memory.dreamDiary`, `config.patch`).
|
||||
- Sesiones: lista + anulaciones por sesión de modelo/thinking/rápido/detallado/traza/razonamiento (`sessions.list`, `sessions.patch`).
|
||||
- Sueños: estado de Dreaming, alternancia de activar/desactivar y lector del diario de sueños (`doctor.memory.status`, `doctor.memory.dreamDiary`, `config.patch`).
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Cron, Skills, nodos, aprobaciones de exec">
|
||||
- Trabajos Cron: listar/agregar/editar/ejecutar/habilitar/deshabilitar + historial de ejecuciones (`cron.*`).
|
||||
- Skills: estado, habilitar/deshabilitar, instalar, actualizaciones de claves de API (`skills.*`).
|
||||
- Nodos: lista + capacidades (`node.list`).
|
||||
- Aprobaciones de exec: editar listas de permitidos del gateway o nodo + política de solicitud para `exec host=gateway/node` (`exec.approvals.*`).
|
||||
<Accordion title="Cron, skills, nodes, exec approvals">
|
||||
- Trabajos de Cron: listar/agregar/editar/ejecutar/activar/desactivar + historial de ejecución (`cron.*`).
|
||||
- Skills: estado, activar/desactivar, instalar, actualizaciones de clave de API (`skills.*`).
|
||||
- Nodes: lista + capacidades (`node.list`).
|
||||
- Aprobaciones de exec: editar listas de permitidos del Gateway o Node + política de solicitud para `exec host=gateway/node` (`exec.approvals.*`).
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Configuración">
|
||||
<Accordion title="Config">
|
||||
- Ver/editar `~/.openclaw/openclaw.json` (`config.get`, `config.set`).
|
||||
- Aplicar + reiniciar con validación (`config.apply`) y despertar la última sesión activa.
|
||||
- Las escrituras incluyen una protección de hash base para evitar sobrescribir ediciones concurrentes.
|
||||
- Las escrituras (`config.set`/`config.apply`/`config.patch`) comprueban previamente la resolución de SecretRef activa para las referencias en la carga útil de configuración enviada; las referencias enviadas activas sin resolver se rechazan antes de escribir.
|
||||
- Esquema + renderizado de formulario (`config.schema` / `config.schema.lookup`, incluidos `title` / `description` de campo, sugerencias de UI coincidentes, resúmenes de hijos inmediatos, metadatos de documentación en nodos anidados de objeto/comodín/array/composición, además de esquemas de plugin + canal cuando estén disponibles); el editor JSON sin procesar solo está disponible cuando la instantánea tiene un viaje de ida y vuelta sin procesar seguro.
|
||||
- Si una instantánea no puede hacer de forma segura el viaje de ida y vuelta de texto sin procesar, la Control UI fuerza el modo Form y deshabilita el modo Raw para esa instantánea.
|
||||
- "Reset to saved" del editor JSON sin procesar conserva la forma creada en bruto (formato, comentarios, diseño de `$include`) en lugar de volver a renderizar una instantánea aplanada, por lo que las ediciones externas sobreviven a un restablecimiento cuando la instantánea puede hacer el viaje de ida y vuelta de forma segura.
|
||||
- Los valores de objeto SecretRef estructurados se renderizan como solo lectura en las entradas de texto del formulario para evitar la corrupción accidental de objeto a cadena.
|
||||
- Las escrituras incluyen una protección de hash base para impedir sobrescribir ediciones concurrentes.
|
||||
- Las escrituras (`config.set`/`config.apply`/`config.patch`) hacen una comprobación previa de resolución de SecretRef activo para las referencias en la carga de configuración enviada; las referencias activas enviadas sin resolver se rechazan antes de escribir.
|
||||
- Renderizado de esquema + formulario (`config.schema` / `config.schema.lookup`, incluido `title` / `description` de campo, sugerencias de UI coincidentes, resúmenes de hijos inmediatos, metadatos de documentación en nodos anidados de objeto/comodín/arreglo/composición, además de esquemas de plugin + canal cuando están disponibles); el editor JSON sin procesar está disponible solo cuando la instantánea tiene una ida y vuelta sin procesar segura.
|
||||
- Si una instantánea no puede hacer una ida y vuelta segura del texto sin procesar, la Control UI fuerza el modo Formulario y deshabilita el modo Sin procesar para esa instantánea.
|
||||
- El editor JSON sin procesar "Restablecer a guardado" conserva la forma creada en bruto (formato, comentarios, disposición de `$include`) en lugar de volver a renderizar una instantánea aplanada, de modo que las ediciones externas sobreviven a un restablecimiento cuando la instantánea puede hacer una ida y vuelta segura.
|
||||
- Los valores de objeto SecretRef estructurados se renderizan como de solo lectura en entradas de texto de formulario para impedir la corrupción accidental de objeto a cadena.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Depuración, registros, actualización">
|
||||
<Accordion title="Debug, logs, update">
|
||||
- Depuración: instantáneas de estado/salud/modelos + registro de eventos + llamadas RPC manuales (`status`, `health`, `models.list`).
|
||||
- Registros: seguimiento en vivo de registros de archivo del gateway con filtro/exportación (`logs.tail`).
|
||||
- Actualización: ejecutar una actualización de paquete/git + reinicio (`update.run`) con un informe de reinicio, luego sondear `update.status` después de reconectar para verificar la versión del gateway en ejecución.
|
||||
- Registros: seguimiento en vivo de los registros de archivo del Gateway con filtro/exportación (`logs.tail`).
|
||||
- Actualización: ejecutar una actualización de paquete/git + reiniciar (`update.run`) con un informe de reinicio, luego sondear `update.status` después de reconectar para verificar la versión del Gateway en ejecución.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Notas del panel de trabajos Cron">
|
||||
- Para trabajos aislados, la entrega usa por defecto un resumen de anuncio. Puedes cambiarla a ninguno si quieres ejecuciones solo internas.
|
||||
- Los campos de canal/destino aparecen cuando se selecciona anuncio.
|
||||
<Accordion title="Cron jobs panel notes">
|
||||
- Para trabajos aislados, la entrega predeterminada es anunciar resumen. Puedes cambiarla a ninguna si quieres ejecuciones solo internas.
|
||||
- Los campos de canal/destino aparecen cuando se selecciona anunciar.
|
||||
- El modo Webhook usa `delivery.mode = "webhook"` con `delivery.to` establecido en una URL Webhook HTTP(S) válida.
|
||||
- Para trabajos de sesión principal, los modos de entrega Webhook y ninguno están disponibles.
|
||||
- Los controles de edición avanzada incluyen eliminar después de ejecutar, borrar anulación de agente, opciones exactas/escalonadas de cron, anulaciones de modelo/pensamiento de agente y conmutadores de entrega de máximo esfuerzo.
|
||||
- La validación del formulario es en línea con errores a nivel de campo; los valores no válidos deshabilitan el botón de guardar hasta que se corrijan.
|
||||
- Para trabajos de sesión principal, están disponibles los modos de entrega Webhook y ninguna.
|
||||
- Los controles de edición avanzados incluyen eliminar tras ejecutar, borrar anulación de agente, opciones exactas/escalonadas de Cron, anulaciones de modelo/thinking del agente y alternancias de entrega de mejor esfuerzo.
|
||||
- La validación del formulario es en línea con errores de nivel de campo; los valores inválidos deshabilitan el botón de guardar hasta que se corrijan.
|
||||
- Configura `cron.webhookToken` para enviar un token bearer dedicado; si se omite, el Webhook se envía sin encabezado de autenticación.
|
||||
- Respaldo obsoleto: los trabajos heredados almacenados con `notify: true` todavía pueden usar `cron.webhook` hasta que migren.
|
||||
- Alternativa obsoleta: los trabajos heredados almacenados con `notify: true` aún pueden usar `cron.webhook` hasta que se migren.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@ -154,62 +155,63 @@ Los temas importados se almacenan solo en el perfil de navegador actual. No se e
|
||||
## Comportamiento de Chat
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Send and history semantics">
|
||||
<Accordion title="Semántica de envío e historial">
|
||||
- `chat.send` es **no bloqueante**: confirma de inmediato con `{ runId, status: "started" }` y la respuesta se transmite mediante eventos `chat`.
|
||||
- Las cargas de chat aceptan imágenes además de archivos que no sean de video. Las imágenes conservan la ruta de imagen nativa; los demás archivos se almacenan como medios administrados y se muestran en el historial como enlaces de adjuntos.
|
||||
- Reenviar con el mismo `idempotencyKey` devuelve `{ status: "in_flight" }` mientras está en ejecución, y `{ status: "ok" }` después de completarse.
|
||||
- Las respuestas de `chat.history` tienen límite de tamaño para la seguridad de la UI. Cuando las entradas de la transcripción son demasiado grandes, Gateway puede truncar campos de texto largos, omitir bloques de metadatos pesados y reemplazar mensajes sobredimensionados con un marcador de posición (`[chat.history omitted: message too large]`).
|
||||
- Las imágenes del asistente/generadas se conservan como referencias de medios administrados y se sirven de vuelta mediante URL de medios autenticadas de Gateway, por lo que las recargas no dependen de que las cargas útiles de imagen base64 sin procesar permanezcan en la respuesta del historial de chat.
|
||||
- `chat.history` también elimina del texto visible del asistente las etiquetas de directivas en línea solo de visualización (por ejemplo, `[[reply_to_*]]` y `[[audio_as_voice]]`), las cargas útiles XML de llamadas a herramientas en texto sin formato (incluidos `<tool_call>...</tool_call>`, `<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`, `<function_calls>...</function_calls>` y bloques truncados de llamadas a herramientas), y los tokens filtrados de control de modelo ASCII/de ancho completo, y omite las entradas del asistente cuyo texto visible completo sea solo el token silencioso exacto `NO_REPLY` / `no_reply`.
|
||||
- Durante un envío activo y la actualización final del historial, la vista de chat mantiene visibles los mensajes locales optimistas del usuario/asistente si `chat.history` devuelve brevemente una instantánea anterior; la transcripción canónica reemplaza esos mensajes locales una vez que el historial de Gateway se pone al día.
|
||||
- `chat.inject` agrega una nota del asistente a la transcripción de la sesión y difunde un evento `chat` para actualizaciones solo de UI (sin ejecución de agente, sin entrega por canal).
|
||||
- Los selectores de modelo y razonamiento del encabezado del chat parchean la sesión activa de inmediato mediante `sessions.patch`; son anulaciones persistentes de sesión, no opciones de envío solo para un turno.
|
||||
- Escribir `/new` en la Control UI crea y cambia a la misma sesión nueva del panel que New Chat. Escribir `/reset` conserva el reinicio explícito in situ de Gateway para la sesión actual.
|
||||
- El selector de modelo del chat solicita la vista de modelos configurada de Gateway. Si `agents.defaults.models` está presente, esa lista permitida controla el selector. De lo contrario, el selector muestra entradas explícitas de `models.providers.*.models` además de proveedores con autenticación utilizable. El catálogo completo sigue disponible mediante el RPC de depuración `models.list` con `view: "all"`.
|
||||
- Cuando los informes de uso de sesiones nuevas de Gateway muestran una presión de contexto alta, el área del compositor de chat muestra un aviso de contexto y, en los niveles recomendados de compaction, un botón compacto que ejecuta la ruta normal de compaction de sesión. Las instantáneas de tokens obsoletas se ocultan hasta que Gateway vuelve a informar uso reciente.
|
||||
- `chat.transcribeAudio` es un asistente de dictado de una sola ejecución para borradores de Chat. Acepta audio base64 grabado por el navegador, mantiene las cargas por debajo del límite de trama WebSocket del Gateway, escribe un archivo local temporal, ejecuta transcripción de audio con comprensión multimedia usando la configuración activa del Gateway, devuelve `{ text, provider, model }` y elimina el archivo temporal. No crea una ejecución de agente y es independiente de Talk en tiempo real.
|
||||
- Las cargas de Chat aceptan imágenes además de archivos que no sean de video. Las imágenes conservan la ruta de imagen nativa; los demás archivos se almacenan como medios gestionados y se muestran en el historial como enlaces de adjunto.
|
||||
- Reenviar con el mismo `idempotencyKey` devuelve `{ status: "in_flight" }` mientras se está ejecutando, y `{ status: "ok" }` después de completarse.
|
||||
- Las respuestas de `chat.history` tienen límite de tamaño por seguridad de la UI. Cuando las entradas de transcripción son demasiado grandes, Gateway puede truncar campos de texto largos, omitir bloques pesados de metadatos y reemplazar mensajes sobredimensionados por un marcador de posición (`[chat.history omitted: message too large]`).
|
||||
- Las imágenes del asistente/generadas se conservan como referencias de medios gestionados y se sirven de vuelta mediante URL de medios autenticadas del Gateway, por lo que las recargas no dependen de que las cargas útiles de imágenes base64 sin procesar permanezcan en la respuesta del historial de chat.
|
||||
- `chat.history` también elimina etiquetas de directivas en línea solo de visualización del texto visible del asistente (por ejemplo `[[reply_to_*]]` y `[[audio_as_voice]]`), cargas útiles XML de llamadas a herramientas en texto plano (incluidos `<tool_call>...</tool_call>`, `<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`, `<function_calls>...</function_calls>` y bloques de llamadas a herramientas truncados), y tokens de control de modelo ASCII/de ancho completo filtrados, y omite entradas del asistente cuyo texto visible completo sea solo el token silencioso exacto `NO_REPLY` / `no_reply`.
|
||||
- Durante un envío activo y la actualización final del historial, la vista de chat mantiene visibles los mensajes locales optimistas de usuario/asistente si `chat.history` devuelve brevemente una instantánea anterior; la transcripción canónica reemplaza esos mensajes locales una vez que el historial del Gateway se pone al día.
|
||||
- `chat.inject` agrega una nota del asistente a la transcripción de la sesión y emite un evento `chat` para actualizaciones solo de UI (sin ejecución de agente ni entrega por canal).
|
||||
- Los selectores de modelo y razonamiento del encabezado del chat parchean la sesión activa de inmediato mediante `sessions.patch`; son anulaciones persistentes de sesión, no opciones de envío de un solo turno.
|
||||
- Escribir `/new` en la Control UI crea y cambia a la misma sesión nueva del panel que New Chat. Escribir `/reset` mantiene el restablecimiento explícito in situ del Gateway para la sesión actual.
|
||||
- El selector de modelo de chat solicita la vista de modelos configurada del Gateway. Si `agents.defaults.models` está presente, esa lista de permitidos impulsa el selector. De lo contrario, el selector muestra las entradas explícitas de `models.providers.*.models` además de proveedores con autenticación utilizable. El catálogo completo sigue disponible mediante el RPC de depuración `models.list` con `view: "all"`.
|
||||
- Cuando los informes recientes de uso de sesión del Gateway muestran alta presión de contexto, el área del compositor de chat muestra un aviso de contexto y, en niveles recomendados de Compaction, un botón de compactación que ejecuta la ruta normal de Compaction de sesión. Las instantáneas de tokens obsoletas se ocultan hasta que el Gateway vuelve a informar uso reciente.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Talk mode (browser realtime)">
|
||||
El modo de conversación usa un proveedor de voz en tiempo real registrado. Configure OpenAI con `talk.provider: "openai"` más `talk.providers.openai.apiKey`, o configure Google con `talk.provider: "google"` más `talk.providers.google.apiKey`; la configuración del proveedor en tiempo real de Voice Call aún puede reutilizarse como alternativa. El navegador nunca recibe una clave de API estándar del proveedor. OpenAI recibe un secreto efímero de cliente Realtime para WebRTC. Google Live recibe un token de autenticación de Live API restringido y de un solo uso para una sesión WebSocket del navegador, con instrucciones y declaraciones de herramientas bloqueadas en el token por Gateway. Los proveedores que solo exponen un puente en tiempo real de backend se ejecutan mediante el transporte de retransmisión de Gateway, de modo que las credenciales y los sockets del proveedor permanecen del lado del servidor mientras el audio del navegador se mueve mediante RPC autenticados de Gateway. El prompt de la sesión Realtime lo ensambla Gateway; `talk.realtime.session` no acepta anulaciones de instrucciones proporcionadas por el llamador.
|
||||
<Accordion title="Modo Talk (tiempo real en navegador)">
|
||||
El modo Talk usa un proveedor de voz en tiempo real registrado. Configura OpenAI con `talk.provider: "openai"` más `talk.providers.openai.apiKey`, o configura Google con `talk.provider: "google"` más `talk.providers.google.apiKey`; la configuración del proveedor en tiempo real de Voice Call todavía puede reutilizarse como respaldo. El navegador nunca recibe una clave de API de proveedor estándar. OpenAI recibe un secreto de cliente Realtime efímero para WebRTC. Google Live recibe un token de autenticación de Live API restringido y de un solo uso para una sesión WebSocket del navegador, con instrucciones y declaraciones de herramientas fijadas en el token por el Gateway. Los proveedores que solo exponen un puente en tiempo real de backend se ejecutan mediante el transporte de retransmisión del Gateway, por lo que las credenciales y los sockets del proveedor permanecen del lado del servidor mientras el audio del navegador se mueve mediante RPC autenticados del Gateway. El prompt de la sesión Realtime lo ensambla el Gateway; `talk.realtime.session` no acepta anulaciones de instrucciones proporcionadas por el llamador.
|
||||
|
||||
En el compositor de chat, el control de conversación es el botón de ondas junto al botón de dictado por micrófono. Cuando inicia la conversación, la fila de estado del compositor muestra `Connecting Talk...`, luego `Talk live` mientras el audio está conectado, o `Asking OpenClaw...` mientras una llamada a herramienta en tiempo real consulta el modelo más grande configurado mediante `chat.send`.
|
||||
En el compositor de Chat, el control Talk es el botón de ondas junto al botón de dictado del micrófono. Cuando Talk inicia, la fila de estado del compositor muestra `Connecting Talk...`, luego `Talk live` mientras el audio está conectado, o `Asking OpenClaw...` mientras una llamada a herramienta en tiempo real consulta el modelo más grande configurado mediante `chat.send`.
|
||||
|
||||
Smoke en vivo para mantenedores: `OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts` verifica el intercambio SDP WebRTC del navegador de OpenAI, la configuración WebSocket del navegador con token restringido de Google Live y el adaptador de navegador de retransmisión de Gateway con medios de micrófono falsos. El comando imprime solo el estado del proveedor y no registra secretos.
|
||||
Prueba en vivo de mantenimiento: `OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts` verifica el intercambio SDP WebRTC del navegador de OpenAI, la configuración WebSocket del navegador con token restringido de Google Live y el adaptador de navegador de retransmisión del Gateway con medios de micrófono falsos. El comando imprime solo el estado del proveedor y no registra secretos.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Stop and abort">
|
||||
- Haga clic en **Stop** (llama a `chat.abort`).
|
||||
- Mientras una ejecución está activa, los seguimientos normales se ponen en cola. Haga clic en **Steer** en un mensaje en cola para inyectar ese seguimiento en el turno en ejecución.
|
||||
- Escriba `/stop` (o frases de cancelación independientes como `stop`, `stop action`, `stop run`, `stop openclaw`, `please stop`) para abortar fuera de banda.
|
||||
<Accordion title="Detener y abortar">
|
||||
- Haz clic en **Stop** (llama a `chat.abort`).
|
||||
- Mientras una ejecución está activa, los seguimientos normales se ponen en cola. Haz clic en **Steer** en un mensaje en cola para inyectar ese seguimiento en el turno en ejecución.
|
||||
- Escribe `/stop` (o frases de aborto independientes como `stop`, `stop action`, `stop run`, `stop openclaw`, `please stop`) para abortar fuera de banda.
|
||||
- `chat.abort` admite `{ sessionKey }` (sin `runId`) para abortar todas las ejecuciones activas de esa sesión.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Abort partial retention">
|
||||
- Cuando se aborta una ejecución, el texto parcial del asistente aún puede mostrarse en la UI.
|
||||
<Accordion title="Retención parcial al abortar">
|
||||
- Cuando una ejecución se aborta, el texto parcial del asistente todavía puede mostrarse en la UI.
|
||||
- Gateway conserva el texto parcial abortado del asistente en el historial de transcripción cuando existe salida en búfer.
|
||||
- Las entradas conservadas incluyen metadatos de aborto para que los consumidores de transcripciones puedan distinguir los parciales abortados de la salida de finalización normal.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Instalación de PWA y push web
|
||||
## Instalación PWA y Web Push
|
||||
|
||||
La Control UI incluye un `manifest.webmanifest` y un service worker, por lo que los navegadores modernos pueden instalarla como una PWA independiente. Web Push permite que Gateway active la PWA instalada con notificaciones incluso cuando la pestaña o la ventana del navegador no está abierta.
|
||||
La Control UI incluye un `manifest.webmanifest` y un service worker, por lo que los navegadores modernos pueden instalarla como una PWA independiente. Web Push permite que el Gateway active la PWA instalada con notificaciones incluso cuando la pestaña o la ventana del navegador no está abierta.
|
||||
|
||||
| Superficie | Qué hace |
|
||||
| Superficie | Qué hace |
|
||||
| ----------------------------------------------------- | ------------------------------------------------------------------ |
|
||||
| `ui/public/manifest.webmanifest` | Manifiesto de PWA. Los navegadores ofrecen "Instalar app" una vez que es accesible. |
|
||||
| `ui/public/sw.js` | Service worker que maneja eventos `push` y clics de notificaciones. |
|
||||
| `push/vapid-keys.json` (bajo el directorio de estado de OpenClaw) | Par de claves VAPID generado automáticamente que se usa para firmar cargas útiles de Web Push. |
|
||||
| `ui/public/manifest.webmanifest` | Manifiesto PWA. Los navegadores ofrecen "Install app" una vez que es accesible. |
|
||||
| `ui/public/sw.js` | Service worker que maneja eventos `push` y clics de notificación. |
|
||||
| `push/vapid-keys.json` (bajo el directorio de estado de OpenClaw) | Par de claves VAPID generado automáticamente usado para firmar cargas útiles de Web Push. |
|
||||
| `push/web-push-subscriptions.json` | Endpoints de suscripción del navegador conservados. |
|
||||
|
||||
Anule el par de claves VAPID mediante variables de entorno en el proceso de Gateway cuando quiera fijar claves (para despliegues multihost, rotación de secretos o pruebas):
|
||||
Anula el par de claves VAPID mediante variables de entorno en el proceso del Gateway cuando quieras fijar claves (para despliegues multi-host, rotación de secretos o pruebas):
|
||||
|
||||
- `OPENCLAW_VAPID_PUBLIC_KEY`
|
||||
- `OPENCLAW_VAPID_PRIVATE_KEY`
|
||||
- `OPENCLAW_VAPID_SUBJECT` (predeterminado: `mailto:openclaw@localhost`)
|
||||
- `OPENCLAW_VAPID_SUBJECT` (el valor predeterminado es `mailto:openclaw@localhost`)
|
||||
|
||||
La Control UI usa estos métodos de Gateway delimitados por alcance para registrar y probar suscripciones del navegador:
|
||||
La Control UI usa estos métodos del Gateway con ámbito restringido para registrar y probar suscripciones del navegador:
|
||||
|
||||
- `push.web.vapidPublicKey` — obtiene la clave pública VAPID activa.
|
||||
- `push.web.subscribe` — registra un `endpoint` más `keys.p256dh`/`keys.auth`.
|
||||
@ -217,22 +219,22 @@ La Control UI usa estos métodos de Gateway delimitados por alcance para registr
|
||||
- `push.web.test` — envía una notificación de prueba a la suscripción del llamador.
|
||||
|
||||
<Note>
|
||||
Web Push es independiente de la ruta de retransmisión APNS de iOS (consulte [Configuración](/es/gateway/configuration) para push respaldado por retransmisión) y del método existente `push.test`, que se dirigen al emparejamiento móvil nativo.
|
||||
Web Push es independiente de la ruta de retransmisión APNS de iOS (consulta [Configuración](/es/gateway/configuration) para push respaldado por retransmisión) y del método existente `push.test`, que apunta al emparejamiento móvil nativo.
|
||||
</Note>
|
||||
|
||||
## Incrustaciones alojadas
|
||||
## Embeds alojados
|
||||
|
||||
Los mensajes del asistente pueden representar contenido web alojado en línea con el shortcode `[embed ...]`. La política de sandbox del iframe se controla mediante `gateway.controlUi.embedSandbox`:
|
||||
Los mensajes del asistente pueden representar contenido web alojado en línea con el shortcode `[embed ...]`. La política de sandbox del iframe la controla `gateway.controlUi.embedSandbox`:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="strict">
|
||||
Deshabilita la ejecución de scripts dentro de incrustaciones alojadas.
|
||||
Desactiva la ejecución de scripts dentro de embeds alojados.
|
||||
</Tab>
|
||||
<Tab title="scripts (default)">
|
||||
Permite incrustaciones interactivas manteniendo el aislamiento de origen; este es el valor predeterminado y suele ser suficiente para juegos/widgets de navegador autocontenidos.
|
||||
Permite embeds interactivos mientras mantiene el aislamiento de origen; este es el valor predeterminado y suele ser suficiente para juegos/widgets de navegador autocontenidos.
|
||||
</Tab>
|
||||
<Tab title="trusted">
|
||||
Agrega `allow-same-origin` además de `allow-scripts` para documentos del mismo sitio que necesitan intencionalmente privilegios más fuertes.
|
||||
Agrega `allow-same-origin` encima de `allow-scripts` para documentos del mismo sitio que intencionalmente necesitan privilegios más fuertes.
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
@ -249,14 +251,14 @@ Ejemplo:
|
||||
```
|
||||
|
||||
<Warning>
|
||||
Use `trusted` solo cuando el documento incrustado necesite realmente comportamiento de mismo origen. Para la mayoría de los juegos generados por agentes y lienzos interactivos, `scripts` es la opción más segura.
|
||||
Usa `trusted` solo cuando el documento embebido realmente necesite comportamiento de mismo origen. Para la mayoría de los juegos generados por agentes y lienzos interactivos, `scripts` es la opción más segura.
|
||||
</Warning>
|
||||
|
||||
Las URL absolutas externas de incrustación `http(s)` permanecen bloqueadas de forma predeterminada. Si quiere intencionalmente que `[embed url="https://..."]` cargue páginas de terceros, establezca `gateway.controlUi.allowExternalEmbedUrls: true`.
|
||||
Las URL externas absolutas de embed `http(s)` permanecen bloqueadas de forma predeterminada. Si intencionalmente quieres que `[embed url="https://..."]` cargue páginas de terceros, establece `gateway.controlUi.allowExternalEmbedUrls: true`.
|
||||
|
||||
## Ancho del mensaje de chat
|
||||
## Ancho de mensajes de chat
|
||||
|
||||
Los mensajes de chat agrupados usan un ancho máximo predeterminado legible. Los despliegues con monitores anchos pueden anularlo sin parchear el CSS incluido estableciendo `gateway.controlUi.chatMessageMaxWidth`:
|
||||
Los mensajes de chat agrupados usan un ancho máximo legible de forma predeterminada. Los despliegues en monitores anchos pueden anularlo sin parchear el CSS incluido estableciendo `gateway.controlUi.chatMessageMaxWidth`:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -268,28 +270,28 @@ Los mensajes de chat agrupados usan un ancho máximo predeterminado legible. Los
|
||||
}
|
||||
```
|
||||
|
||||
El valor se valida antes de llegar al navegador. Los valores admitidos incluyen longitudes simples y porcentajes como `960px` o `82%`, además de expresiones de ancho restringidas `min(...)`, `max(...)`, `clamp(...)`, `calc(...)` y `fit-content(...)`.
|
||||
El valor se valida antes de llegar al navegador. Los valores admitidos incluyen longitudes y porcentajes simples como `960px` o `82%`, además de expresiones de ancho restringidas `min(...)`, `max(...)`, `clamp(...)`, `calc(...)` y `fit-content(...)`.
|
||||
|
||||
## Acceso a tailnet (recomendado)
|
||||
## Acceso a Tailnet (recomendado)
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Integrated Tailscale Serve (preferred)">
|
||||
Mantenga Gateway en loopback y deje que Tailscale Serve lo use como proxy con HTTPS:
|
||||
Mantén el Gateway en local loopback y deja que Tailscale Serve lo proxifique con HTTPS:
|
||||
|
||||
```bash
|
||||
openclaw gateway --tailscale serve
|
||||
```
|
||||
|
||||
Abra:
|
||||
Abre:
|
||||
|
||||
- `https://<magicdns>/` (o su `gateway.controlUi.basePath` configurado)
|
||||
- `https://<magicdns>/` (o tu `gateway.controlUi.basePath` configurado)
|
||||
|
||||
De forma predeterminada, las solicitudes de Control UI/WebSocket Serve pueden autenticarse mediante encabezados de identidad de Tailscale (`tailscale-user-login`) cuando `gateway.auth.allowTailscale` es `true`. OpenClaw verifica la identidad resolviendo la dirección `x-forwarded-for` con `tailscale whois` y comparándola con el encabezado, y solo las acepta cuando la solicitud llega a loopback con los encabezados `x-forwarded-*` de Tailscale. Para sesiones de operador de Control UI con identidad de dispositivo del navegador, esta ruta Serve verificada también omite el viaje de ida y vuelta de emparejamiento de dispositivo; los navegadores sin dispositivo y las conexiones con rol de nodo siguen las comprobaciones normales de dispositivo. Establezca `gateway.auth.allowTailscale: false` si quiere exigir credenciales explícitas de secreto compartido incluso para tráfico Serve. Luego use `gateway.auth.mode: "token"` o `"password"`.
|
||||
De forma predeterminada, las solicitudes de Control UI/WebSocket Serve pueden autenticarse mediante encabezados de identidad de Tailscale (`tailscale-user-login`) cuando `gateway.auth.allowTailscale` es `true`. OpenClaw verifica la identidad resolviendo la dirección `x-forwarded-for` con `tailscale whois` y comparándola con el encabezado, y solo acepta estas solicitudes cuando llegan por local loopback con los encabezados `x-forwarded-*` de Tailscale. Para sesiones de operador de Control UI con identidad de dispositivo del navegador, esta ruta Serve verificada también omite la ida y vuelta de emparejamiento de dispositivo; los navegadores sin dispositivo y las conexiones con rol de nodo todavía siguen las comprobaciones normales de dispositivo. Establece `gateway.auth.allowTailscale: false` si quieres exigir credenciales explícitas de secreto compartido incluso para tráfico Serve. Luego usa `gateway.auth.mode: "token"` o `"password"`.
|
||||
|
||||
Para esa ruta asíncrona de identidad Serve, los intentos de autenticación fallidos para la misma IP de cliente y el mismo alcance de autenticación se serializan antes de las escrituras de límite de tasa. Por lo tanto, los reintentos incorrectos concurrentes desde el mismo navegador pueden mostrar `retry later` en la segunda solicitud en lugar de dos discrepancias simples compitiendo en paralelo.
|
||||
Para esa ruta asíncrona de identidad Serve, los intentos de autenticación fallidos para la misma IP de cliente y ámbito de autenticación se serializan antes de las escrituras de límite de tasa. Por lo tanto, reintentos incorrectos concurrentes desde el mismo navegador pueden mostrar `retry later` en la segunda solicitud en lugar de dos discrepancias simples compitiendo en paralelo.
|
||||
|
||||
<Warning>
|
||||
La autenticación Serve sin token asume que el host de Gateway es de confianza. Si podría ejecutarse código local no confiable en ese host, exija autenticación con token/contraseña.
|
||||
La autenticación Serve sin token asume que el host del gateway es de confianza. Si código local no confiable puede ejecutarse en ese host, exige autenticación con token/contraseña.
|
||||
</Warning>
|
||||
|
||||
</Tab>
|
||||
@ -298,32 +300,32 @@ El valor se valida antes de llegar al navegador. Los valores admitidos incluyen
|
||||
openclaw gateway --bind tailnet --token "$(openssl rand -hex 32)"
|
||||
```
|
||||
|
||||
Luego abra:
|
||||
Luego abre:
|
||||
|
||||
- `http://<tailscale-ip>:18789/` (o su `gateway.controlUi.basePath` configurado)
|
||||
- `http://<tailscale-ip>:18789/` (o tu `gateway.controlUi.basePath` configurado)
|
||||
|
||||
Pegue el secreto compartido correspondiente en la configuración de la UI (se envía como `connect.params.auth.token` o `connect.params.auth.password`).
|
||||
Pega el secreto compartido correspondiente en la configuración de la UI (enviado como `connect.params.auth.token` o `connect.params.auth.password`).
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## HTTP no seguro
|
||||
## HTTP inseguro
|
||||
|
||||
Si abre el panel mediante HTTP sin cifrar (`http://<lan-ip>` o `http://<tailscale-ip>`), el navegador se ejecuta en un **contexto no seguro** y bloquea WebCrypto. De forma predeterminada, OpenClaw **bloquea** las conexiones de Control UI sin identidad de dispositivo.
|
||||
Si abres el panel mediante HTTP sin cifrar (`http://<lan-ip>` o `http://<tailscale-ip>`), el navegador se ejecuta en un **contexto no seguro** y bloquea WebCrypto. De forma predeterminada, OpenClaw **bloquea** las conexiones de Control UI sin identidad de dispositivo.
|
||||
|
||||
Excepciones documentadas:
|
||||
|
||||
- compatibilidad HTTP no segura solo para localhost con `gateway.controlUi.allowInsecureAuth=true`
|
||||
- autenticación correcta de Control UI de operador mediante `gateway.auth.mode: "trusted-proxy"`
|
||||
- compatibilidad con HTTP inseguro solo en localhost con `gateway.controlUi.allowInsecureAuth=true`
|
||||
- autenticación correcta de operador en la Control UI mediante `gateway.auth.mode: "trusted-proxy"`
|
||||
- emergencia `gateway.controlUi.dangerouslyDisableDeviceAuth=true`
|
||||
|
||||
**Corrección recomendada:** use HTTPS (Tailscale Serve) o abra la UI localmente:
|
||||
**Solución recomendada:** usa HTTPS (Tailscale Serve) o abre la UI localmente:
|
||||
|
||||
- `https://<magicdns>/` (Serve)
|
||||
- `http://127.0.0.1:18789/` (en el host de Gateway)
|
||||
- `http://127.0.0.1:18789/` (en el host del gateway)
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Comportamiento del conmutador de autenticación insegura">
|
||||
<Accordion title="Comportamiento del interruptor de autenticación insegura">
|
||||
```json5
|
||||
{
|
||||
gateway: {
|
||||
@ -334,14 +336,14 @@ Excepciones documentadas:
|
||||
}
|
||||
```
|
||||
|
||||
`allowInsecureAuth` es solo un conmutador de compatibilidad local:
|
||||
`allowInsecureAuth` es solo un interruptor de compatibilidad local:
|
||||
|
||||
- Permite que las sesiones locales de Control UI continúen sin identidad del dispositivo en contextos HTTP no seguros.
|
||||
- Permite que las sesiones de localhost de la Control UI continúen sin identidad de dispositivo en contextos HTTP no seguros.
|
||||
- No omite las comprobaciones de emparejamiento.
|
||||
- No relaja los requisitos de identidad del dispositivo remoto (no localhost).
|
||||
- No relaja los requisitos de identidad de dispositivo remotos (no localhost).
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Solo para casos de emergencia">
|
||||
<Accordion title="Solo para emergencias">
|
||||
```json5
|
||||
{
|
||||
gateway: {
|
||||
@ -353,14 +355,14 @@ Excepciones documentadas:
|
||||
```
|
||||
|
||||
<Warning>
|
||||
`dangerouslyDisableDeviceAuth` desactiva las comprobaciones de identidad del dispositivo de Control UI y supone una degradación de seguridad grave. Revierte el cambio rápidamente después del uso de emergencia.
|
||||
`dangerouslyDisableDeviceAuth` desactiva las comprobaciones de identidad de dispositivo de la Control UI y supone una degradación grave de la seguridad. Reviértelo rápidamente después del uso de emergencia.
|
||||
</Warning>
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Nota sobre proxy de confianza">
|
||||
- La autenticación de proxy de confianza correcta puede admitir sesiones de Control UI de **operador** sin identidad del dispositivo.
|
||||
- Esto **no** se extiende a las sesiones de Control UI con rol de nodo.
|
||||
- Los proxies inversos de loopback en el mismo host siguen sin satisfacer la autenticación de proxy de confianza; consulta [Autenticación de proxy de confianza](/es/gateway/trusted-proxy-auth).
|
||||
<Accordion title="Nota sobre trusted-proxy">
|
||||
- La autenticación correcta de trusted-proxy puede admitir sesiones de **operador** en la Control UI sin identidad de dispositivo.
|
||||
- Esto **no** se extiende a las sesiones de la Control UI con rol de nodo.
|
||||
- Los proxies inversos de loopback en el mismo host siguen sin satisfacer la autenticación trusted-proxy; consulta [Autenticación de proxy de confianza](/es/gateway/trusted-proxy-auth).
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@ -369,26 +371,26 @@ Consulta [Tailscale](/es/gateway/tailscale) para obtener orientación sobre la c
|
||||
|
||||
## Política de seguridad de contenido
|
||||
|
||||
Control UI se distribuye con una política `img-src` estricta: solo se permiten recursos de **mismo origen**, URL `data:` y URL `blob:` generadas localmente. El navegador rechaza las URL de imágenes remotas `http(s)` y relativas al protocolo, y no emite solicitudes de red.
|
||||
La Control UI se entrega con una política `img-src` estricta: solo se permiten recursos de **mismo origen**, URL `data:` y URL `blob:` generadas localmente. El navegador rechaza las URL de imágenes remotas `http(s)` y relativas al protocolo, y no realiza solicitudes de red.
|
||||
|
||||
Lo que esto significa en la práctica:
|
||||
|
||||
- Los avatares e imágenes servidos bajo rutas relativas (por ejemplo, `/avatars/<id>`) siguen renderizándose, incluidas las rutas de avatar autenticadas que la UI obtiene y convierte en URL `blob:` locales.
|
||||
- Los avatares e imágenes servidos bajo rutas relativas (por ejemplo, `/avatars/<id>`) siguen renderizándose, incluidas las rutas de avatares autenticadas que la UI obtiene y convierte en URL `blob:` locales.
|
||||
- Las URL `data:image/...` en línea siguen renderizándose (útil para cargas útiles dentro del protocolo).
|
||||
- Las URL `blob:` locales creadas por Control UI siguen renderizándose.
|
||||
- Las URL de avatar remotas emitidas por los metadatos del canal se eliminan en los ayudantes de avatar de Control UI y se sustituyen por el logotipo/insignia integrado, de modo que un canal comprometido o malicioso no pueda forzar solicitudes arbitrarias de imágenes remotas desde el navegador de un operador.
|
||||
- Las URL `blob:` locales creadas por la Control UI siguen renderizándose.
|
||||
- Las URL de avatares remotos emitidas por metadatos de canales se eliminan en los ayudantes de avatar de la Control UI y se reemplazan por el logotipo/insignia integrado, por lo que un canal comprometido o malicioso no puede forzar solicitudes arbitrarias de imágenes remotas desde el navegador de un operador.
|
||||
|
||||
No necesitas cambiar nada para obtener este comportamiento: siempre está activado y no es configurable.
|
||||
|
||||
## Autenticación de la ruta de avatar
|
||||
## Autenticación de rutas de avatar
|
||||
|
||||
Cuando la autenticación del gateway está configurada, el endpoint de avatar de Control UI requiere el mismo token del gateway que el resto de la API:
|
||||
Cuando la autenticación del gateway está configurada, el endpoint de avatar de la Control UI requiere el mismo token del gateway que el resto de la API:
|
||||
|
||||
- `GET /avatar/<agentId>` devuelve la imagen del avatar solo a llamantes autenticados. `GET /avatar/<agentId>?meta=1` devuelve los metadatos del avatar bajo la misma regla.
|
||||
- Las solicitudes no autenticadas a cualquiera de las rutas se rechazan (igual que la ruta hermana de medios del asistente). Esto evita que la ruta de avatar filtre la identidad del agente en hosts que, por lo demás, están protegidos.
|
||||
- Control UI reenvía el token del gateway como encabezado bearer al obtener avatares y usa URL blob autenticadas para que la imagen siga renderizándose en los paneles.
|
||||
- `GET /avatar/<agentId>` devuelve la imagen del avatar solo a los llamadores autenticados. `GET /avatar/<agentId>?meta=1` devuelve los metadatos del avatar bajo la misma regla.
|
||||
- Las solicitudes no autenticadas a cualquiera de las dos rutas se rechazan (igual que la ruta hermana de medios del asistente). Esto evita que la ruta de avatar filtre la identidad del agente en hosts que, por lo demás, están protegidos.
|
||||
- La propia Control UI reenvía el token del gateway como encabezado bearer al obtener avatares, y usa URL blob autenticadas para que la imagen siga renderizándose en los paneles.
|
||||
|
||||
Si desactivas la autenticación del gateway (no recomendado en hosts compartidos), la ruta de avatar también queda sin autenticación, en línea con el resto del gateway.
|
||||
Si desactivas la autenticación del gateway (no recomendado en hosts compartidos), la ruta de avatar también queda sin autenticación, de acuerdo con el resto del gateway.
|
||||
|
||||
## Compilar la UI
|
||||
|
||||
@ -398,7 +400,7 @@ El Gateway sirve archivos estáticos desde `dist/control-ui`. Compílalos con:
|
||||
pnpm ui:build
|
||||
```
|
||||
|
||||
Base absoluta opcional (cuando quieres URL de recursos fijas):
|
||||
Base absoluta opcional (cuando quieras URL de recursos fijas):
|
||||
|
||||
```bash
|
||||
OPENCLAW_CONTROL_UI_BASE_PATH=/openclaw/ pnpm ui:build
|
||||
@ -410,19 +412,19 @@ Para desarrollo local (servidor de desarrollo separado):
|
||||
pnpm ui:dev
|
||||
```
|
||||
|
||||
Luego apunta la UI a la URL WS de tu Gateway (por ejemplo, `ws://127.0.0.1:18789`).
|
||||
Después apunta la UI a la URL WS de tu Gateway (por ejemplo, `ws://127.0.0.1:18789`).
|
||||
|
||||
## Depuración/pruebas: servidor de desarrollo + Gateway remoto
|
||||
|
||||
Control UI son archivos estáticos; el destino WebSocket es configurable y puede ser diferente del origen HTTP. Esto resulta útil cuando quieres usar el servidor de desarrollo de Vite localmente pero el Gateway se ejecuta en otro lugar.
|
||||
La Control UI son archivos estáticos; el destino WebSocket es configurable y puede ser distinto del origen HTTP. Esto resulta útil cuando quieres el servidor de desarrollo de Vite localmente, pero el Gateway se ejecuta en otro lugar.
|
||||
|
||||
<Steps>
|
||||
<Step title="Inicia el servidor de desarrollo de la UI">
|
||||
<Step title="Iniciar el servidor de desarrollo de la UI">
|
||||
```bash
|
||||
pnpm ui:dev
|
||||
```
|
||||
</Step>
|
||||
<Step title="Abre con gatewayUrl">
|
||||
<Step title="Abrir con gatewayUrl">
|
||||
```text
|
||||
http://localhost:5173/?gatewayUrl=ws%3A%2F%2F<gateway-host>%3A18789
|
||||
```
|
||||
@ -438,17 +440,17 @@ Control UI son archivos estáticos; el destino WebSocket es configurable y puede
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Notas">
|
||||
- `gatewayUrl` se almacena en localStorage después de la carga y se elimina de la URL.
|
||||
- Si pasas un endpoint `ws://` o `wss://` completo mediante `gatewayUrl`, codifica en URL el valor de `gatewayUrl` para que el navegador analice correctamente la cadena de consulta.
|
||||
- `token` debe pasarse mediante el fragmento de URL (`#token=...`) siempre que sea posible. Los fragmentos no se envían al servidor, lo que evita filtraciones en registros de solicitudes y Referer. Los parámetros de consulta heredados `?token=` aún se importan una vez por compatibilidad, pero solo como respaldo, y se eliminan inmediatamente después del arranque.
|
||||
- `gatewayUrl` se guarda en localStorage después de cargar y se elimina de la URL.
|
||||
- Si pasas un endpoint `ws://` o `wss://` completo mediante `gatewayUrl`, codifica para URL el valor de `gatewayUrl` para que el navegador analice correctamente la cadena de consulta.
|
||||
- `token` debe pasarse mediante el fragmento de URL (`#token=...`) siempre que sea posible. Los fragmentos no se envían al servidor, lo que evita filtraciones en registros de solicitudes y Referer. Los parámetros de consulta heredados `?token=` todavía se importan una vez por compatibilidad, pero solo como alternativa, y se eliminan inmediatamente después del arranque.
|
||||
- `password` se mantiene solo en memoria.
|
||||
- Cuando `gatewayUrl` está definido, la UI no recurre a credenciales de configuración ni de entorno. Proporciona `token` (o `password`) explícitamente. La falta de credenciales explícitas es un error.
|
||||
- Cuando `gatewayUrl` está definido, la UI no recurre a credenciales de configuración ni de entorno. Proporciona `token` (o `password`) explícitamente. Que falten credenciales explícitas es un error.
|
||||
- Usa `wss://` cuando el Gateway esté detrás de TLS (Tailscale Serve, proxy HTTPS, etc.).
|
||||
- `gatewayUrl` solo se acepta en una ventana de nivel superior (no incrustada) para prevenir clickjacking.
|
||||
- Los despliegues no loopback de Control UI deben definir `gateway.controlUi.allowedOrigins` explícitamente (orígenes completos). Esto incluye configuraciones de desarrollo remotas.
|
||||
- El inicio del Gateway puede sembrar orígenes locales como `http://localhost:<port>` y `http://127.0.0.1:<port>` a partir del enlace y puerto efectivos en tiempo de ejecución, pero los orígenes de navegadores remotos siguen necesitando entradas explícitas.
|
||||
- No uses `gateway.controlUi.allowedOrigins: ["*"]` salvo para pruebas locales estrictamente controladas. Significa permitir cualquier origen de navegador, no "coincidir con cualquier host que esté usando".
|
||||
- `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` habilita el modo de respaldo de origen por encabezado Host, pero es un modo de seguridad peligroso.
|
||||
- `gatewayUrl` solo se acepta en una ventana de nivel superior (no incrustada) para evitar clickjacking.
|
||||
- Los despliegues de la Control UI que no sean de loopback deben definir `gateway.controlUi.allowedOrigins` explícitamente (orígenes completos). Esto incluye configuraciones de desarrollo remotas.
|
||||
- El inicio del Gateway puede inicializar orígenes locales como `http://localhost:<port>` y `http://127.0.0.1:<port>` desde el bind y el puerto efectivos en tiempo de ejecución, pero los orígenes de navegador remotos siguen necesitando entradas explícitas.
|
||||
- No uses `gateway.controlUi.allowedOrigins: ["*"]` excepto para pruebas locales estrictamente controladas. Significa permitir cualquier origen de navegador, no "coincidir con cualquier host que esté usando."
|
||||
- `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` habilita el modo de alternativa de origen mediante encabezado Host, pero es un modo de seguridad peligroso.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@ -470,6 +472,6 @@ Detalles de configuración de acceso remoto: [Acceso remoto](/es/gateway/remote)
|
||||
## Relacionado
|
||||
|
||||
- [Panel](/es/web/dashboard) — panel del gateway
|
||||
- [Comprobaciones de salud](/es/gateway/health) — supervisión de salud del gateway
|
||||
- [Comprobaciones de estado](/es/gateway/health) — supervisión de estado del gateway
|
||||
- [TUI](/es/web/tui) — interfaz de usuario de terminal
|
||||
- [WebChat](/es/web/webchat) — interfaz de chat basada en navegador
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
---
|
||||
read_when:
|
||||
- Depuración o configuración del acceso a WebChat
|
||||
summary: Host estático de Loopback WebChat y uso de WS del Gateway para la interfaz de chat
|
||||
title: WebChat
|
||||
summary: Alojamiento estático de WebChat en loopback y uso de WS del Gateway para la interfaz de chat
|
||||
title: Chat web
|
||||
x-i18n:
|
||||
generated_at: "2026-05-02T05:38:31Z"
|
||||
generated_at: "2026-05-02T23:39:08Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: fe6d3cb30ed18d651b0d0ca8fd188b47c5f1d186410ee340deb79315f194ed8d
|
||||
source_hash: ad3a09c8962e3a6dda83716d319df7ba27e18105cee50721278b5cba0a85c52f
|
||||
source_path: web/webchat.md
|
||||
workflow: 16
|
||||
---
|
||||
@ -16,55 +16,56 @@ Estado: la interfaz de chat SwiftUI de macOS/iOS se comunica directamente con el
|
||||
|
||||
## Qué es
|
||||
|
||||
- Una interfaz de chat nativa para el Gateway (sin navegador integrado ni servidor estático local).
|
||||
- Una interfaz de chat nativa para el gateway (sin navegador integrado ni servidor estático local).
|
||||
- Usa las mismas sesiones y reglas de enrutamiento que otros canales.
|
||||
- Enrutamiento determinista: las respuestas siempre vuelven a WebChat.
|
||||
|
||||
## Inicio rápido
|
||||
|
||||
1. Inicia el Gateway.
|
||||
2. Abre la interfaz de WebChat (aplicación macOS/iOS) o la pestaña de chat de la interfaz de control.
|
||||
3. Asegúrate de que haya configurada una ruta de autenticación válida del Gateway (shared-secret de forma predeterminada,
|
||||
1. Inicia el gateway.
|
||||
2. Abre la interfaz de WebChat (app de macOS/iOS) o la pestaña de chat de la interfaz de Control.
|
||||
3. Asegúrate de que haya configurada una ruta de autenticación válida para el gateway (secreto compartido de forma predeterminada,
|
||||
incluso en loopback).
|
||||
|
||||
## Cómo funciona (comportamiento)
|
||||
|
||||
- La interfaz se conecta al WebSocket del Gateway y usa `chat.history`, `chat.send` y `chat.inject`.
|
||||
- `chat.history` está limitado para aportar estabilidad: el Gateway puede truncar campos de texto largos, omitir metadatos pesados y sustituir entradas demasiado grandes por `[chat.history omitted: message too large]`.
|
||||
- `chat.history` sigue la rama de transcripción activa para archivos de sesión modernos de solo adición, por lo que las ramas de reescritura abandonadas y las copias de prompts reemplazadas no se muestran en WebChat.
|
||||
- La interfaz de control recuerda el `sessionId` del Gateway subyacente devuelto por `chat.history` y lo incluye en las llamadas posteriores a `chat.send`, por lo que las reconexiones y actualizaciones de página continúan la misma conversación almacenada salvo que el usuario inicie o restablezca una sesión.
|
||||
- La interfaz de control combina envíos duplicados en curso para la misma sesión, mensaje y adjuntos antes de generar un nuevo id. de ejecución de `chat.send`; aun así, el Gateway elimina duplicados de solicitudes repetidas que reutilizan la misma clave de idempotencia.
|
||||
- `chat.history` también se normaliza para visualización: el contexto de OpenClaw solo de tiempo de ejecución,
|
||||
los contenedores de envoltorio entrantes, las etiquetas de directivas de entrega en línea
|
||||
como `[[reply_to_*]]` y `[[audio_as_voice]]`, las cargas XML de llamadas a herramientas en texto sin formato
|
||||
- La interfaz se conecta al WebSocket del Gateway y usa `chat.history`, `chat.send`, `chat.inject` y `chat.transcribeAudio`.
|
||||
- `chat.history` está acotado para mayor estabilidad: el Gateway puede truncar campos de texto largos, omitir metadatos pesados y reemplazar entradas demasiado grandes con `[chat.history omitted: message too large]`.
|
||||
- `chat.history` sigue la rama activa de la transcripción para los archivos de sesión modernos de solo adición, de modo que las ramas de reescritura abandonadas y las copias de prompts reemplazadas no se muestran en WebChat.
|
||||
- La interfaz de Control recuerda el `sessionId` del Gateway subyacente devuelto por `chat.history` y lo incluye en las llamadas posteriores a `chat.send`, por lo que las reconexiones y las recargas de página continúan la misma conversación almacenada a menos que el usuario inicie o restablezca una sesión.
|
||||
- La interfaz de Control agrupa los envíos duplicados en curso para la misma sesión, mensaje y adjuntos antes de generar un nuevo id de ejecución de `chat.send`; el Gateway aún desduplica las solicitudes repetidas que reutilizan la misma clave de idempotencia.
|
||||
- `chat.history` también se normaliza para visualización: el contexto de OpenClaw solo de runtime,
|
||||
los envoltorios de sobres entrantes, las etiquetas de directivas de entrega en línea
|
||||
como `[[reply_to_*]]` y `[[audio_as_voice]]`, las cargas XML de llamadas a herramientas en texto plano
|
||||
(incluidos `<tool_call>...</tool_call>`,
|
||||
`<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`,
|
||||
`<function_calls>...</function_calls>` y bloques de llamadas a herramientas truncados), y
|
||||
`<function_calls>...</function_calls>` y bloques truncados de llamadas a herramientas), y
|
||||
los tokens de control del modelo ASCII/de ancho completo filtrados se eliminan del texto visible,
|
||||
y se omiten las entradas del asistente cuyo texto visible completo es solo el token silencioso exacto
|
||||
y se omiten las entradas del asistente cuyo texto visible completo sea solo el token silencioso exacto
|
||||
`NO_REPLY` / `no_reply`.
|
||||
- Las cargas de respuesta marcadas como razonamiento (`isReasoning: true`) se excluyen del contenido del asistente de WebChat, del texto de reproducción de transcripciones y de los bloques de contenido de audio, por lo que las cargas solo de pensamiento no aparecen como mensajes visibles del asistente ni como audio reproducible.
|
||||
- `chat.inject` añade una nota del asistente directamente a la transcripción y la difunde a la interfaz (sin ejecución de agente).
|
||||
- Las ejecuciones abortadas pueden mantener visible una salida parcial del asistente en la interfaz.
|
||||
- El Gateway conserva el texto parcial abortado del asistente en el historial de transcripción cuando existe salida almacenada en búfer, y marca esas entradas con metadatos de aborto.
|
||||
- El historial siempre se obtiene del Gateway (sin vigilancia de archivos locales).
|
||||
- Si no se puede acceder al Gateway, WebChat es de solo lectura.
|
||||
- Las cargas de respuesta marcadas como razonamiento (`isReasoning: true`) se excluyen del contenido del asistente de WebChat, del texto de reproducción de la transcripción y de los bloques de contenido de audio, por lo que las cargas solo de pensamiento no aparecen como mensajes visibles del asistente ni como audio reproducible.
|
||||
- `chat.transcribeAudio` impulsa el dictado del lado del servidor en el compositor de chat de la interfaz de Control. El navegador graba audio del micrófono, lo envía como base64 al Gateway y el Gateway ejecuta la canalización `tools.media.audio` configurada. La transcripción devuelta se inserta en el borrador; no se inicia ninguna ejecución de agente hasta que el usuario la envía.
|
||||
- `chat.inject` agrega una nota del asistente directamente a la transcripción y la difunde a la interfaz (sin ejecución de agente).
|
||||
- Las ejecuciones canceladas pueden mantener visible en la interfaz la salida parcial del asistente.
|
||||
- El Gateway conserva el texto parcial cancelado del asistente en el historial de transcripción cuando existe salida almacenada en búfer y marca esas entradas con metadatos de cancelación.
|
||||
- El historial siempre se obtiene desde el gateway (sin vigilancia de archivos locales).
|
||||
- Si el gateway no está disponible, WebChat es de solo lectura.
|
||||
|
||||
## Panel de herramientas de agentes de la interfaz de control
|
||||
## Panel de herramientas de agentes de la interfaz de Control
|
||||
|
||||
- El panel de herramientas `/agents` de la interfaz de control tiene dos vistas separadas:
|
||||
- El panel Herramientas de `/agents` de la interfaz de Control tiene dos vistas separadas:
|
||||
- **Disponible ahora mismo** usa `tools.effective(sessionKey=...)` y muestra lo que la sesión actual
|
||||
puede usar realmente en tiempo de ejecución, incluidas herramientas del núcleo, de plugins y propiedad de canales.
|
||||
realmente puede usar en runtime, incluidas herramientas principales, de plugins y propiedad del canal.
|
||||
- **Configuración de herramientas** usa `tools.catalog` y se mantiene centrada en perfiles, sobrescrituras y
|
||||
semántica del catálogo.
|
||||
- La disponibilidad en tiempo de ejecución está limitada a la sesión. Cambiar de sesión en el mismo agente puede cambiar la lista
|
||||
**Disponible ahora mismo**.
|
||||
- El editor de configuración no implica disponibilidad en tiempo de ejecución; el acceso efectivo sigue respetando la precedencia de políticas
|
||||
- La disponibilidad en runtime está limitada al alcance de la sesión. Cambiar de sesión en el mismo agente puede cambiar la
|
||||
lista **Disponible ahora mismo**.
|
||||
- El editor de configuración no implica disponibilidad en runtime; el acceso efectivo sigue respetando la precedencia de políticas
|
||||
(`allow`/`deny`, sobrescrituras por agente y por proveedor/canal).
|
||||
|
||||
## Uso remoto
|
||||
|
||||
- El modo remoto tuneliza el WebSocket del Gateway mediante SSH/Tailscale.
|
||||
- El modo remoto tuneliza el WebSocket del gateway mediante SSH/Tailscale.
|
||||
- No necesitas ejecutar un servidor WebChat separado.
|
||||
|
||||
## Referencia de configuración (WebChat)
|
||||
@ -73,20 +74,20 @@ Configuración completa: [Configuración](/es/gateway/configuration)
|
||||
|
||||
Opciones de WebChat:
|
||||
|
||||
- `gateway.webchat.chatHistoryMaxChars`: recuento máximo de caracteres para campos de texto en respuestas de `chat.history`. Cuando una entrada de transcripción supera este límite, el Gateway trunca los campos de texto largos y puede sustituir mensajes demasiado grandes por un marcador de posición. El cliente también puede enviar `maxChars` por solicitud para sobrescribir este valor predeterminado en una sola llamada a `chat.history`.
|
||||
- `gateway.webchat.chatHistoryMaxChars`: recuento máximo de caracteres para campos de texto en respuestas de `chat.history`. Cuando una entrada de transcripción supera este límite, el Gateway trunca los campos de texto largos y puede reemplazar mensajes demasiado grandes con un marcador de posición. El cliente también puede enviar `maxChars` por solicitud para sobrescribir este valor predeterminado en una sola llamada a `chat.history`.
|
||||
|
||||
Opciones globales relacionadas:
|
||||
|
||||
- `gateway.port`, `gateway.bind`: host/puerto de WebSocket.
|
||||
- `gateway.auth.mode`, `gateway.auth.token`, `gateway.auth.password`:
|
||||
autenticación WebSocket shared-secret.
|
||||
- `gateway.auth.allowTailscale`: la pestaña de chat de la interfaz de control en navegador puede usar encabezados de identidad de Tailscale
|
||||
Serve cuando está habilitada.
|
||||
- `gateway.auth.mode: "trusted-proxy"`: autenticación de proxy inverso para clientes de navegador detrás de una fuente de proxy **no-loopback** con identidad (consulta [Autenticación de proxy de confianza](/es/gateway/trusted-proxy-auth)).
|
||||
- `gateway.remote.url`, `gateway.remote.token`, `gateway.remote.password`: destino remoto del Gateway.
|
||||
- `session.*`: almacenamiento de sesión y valores predeterminados de la clave principal.
|
||||
autenticación de WebSocket con secreto compartido.
|
||||
- `gateway.auth.allowTailscale`: la pestaña de chat de la interfaz de Control del navegador puede usar encabezados de identidad de Tailscale
|
||||
Serve cuando está habilitado.
|
||||
- `gateway.auth.mode: "trusted-proxy"`: autenticación de proxy inverso para clientes de navegador detrás de una fuente de proxy **no loopback** con reconocimiento de identidad (consulta [Autenticación con proxy de confianza](/es/gateway/trusted-proxy-auth)).
|
||||
- `gateway.remote.url`, `gateway.remote.token`, `gateway.remote.password`: destino del gateway remoto.
|
||||
- `session.*`: almacenamiento de sesiones y valores predeterminados de clave principal.
|
||||
|
||||
## Relacionado
|
||||
|
||||
- [Interfaz de control](/es/web/control-ui)
|
||||
- [Interfaz de Control](/es/web/control-ui)
|
||||
- [Panel](/es/web/dashboard)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user