openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(i18n): refresh nl translations

Browse Source
This commit is contained in:
openclaw-docs-i18n[bot] 2026-05-02 23:42:16 +00:00
parent ddb464d36c
commit bd1445e513
8 changed files with 1273 additions and 1254 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

386
docs/nl/ci.md
View File

@ -2,93 +2,93 @@
read_when:
- Je moet begrijpen waarom een CI-taak wel of niet is uitgevoerd
- Je debugt een mislukte GitHub Actions-controle
- Je coördineert een uitvoering of heruitvoering van releasevalidatie.
- Je wijzigt de ClawSweeper-routering of het doorsturen van GitHub-activiteit
summary: CI-taakgrafiek, scopecontroles, release-overkoepelingen en lokale commando-equivalenten
title: CI-pijplijn
- Je coördineert een releasevalidatierun of herhaling
- Je wijzigt ClawSweeper-dispatch of het doorsturen van GitHub-activiteit
summary: CI-taakengrafiek, scope-gates, release-overkoepelingen en lokale commando-equivalenten
title: CI-pipeline
x-i18n:
generated_at: "2026-05-02T22:17:29Z"
generated_at: "2026-05-02T23:39:23Z"
model: gpt-5.5
provider: openai
source_hash: a8033b928b26adfa340200ea69fd63d339a6e65c21659b8119a68b23b8b16016
source_hash: 321fe0a061044f75b8e1d03b4d3e76d4f8dd2dae0ebc58831887fc20af953cf1
source_path: ci.md
workflow: 16
---
OpenClaw CI draait bij elke push naar `main` en elke pull-aanvraag. De `preflight`-taak classificeert de diff en schakelt dure banen uit wanneer alleen niet-gerelateerde gebieden zijn gewijzigd. Handmatige `workflow_dispatch`-runs omzeilen smart scoping bewust en waaieren de volledige graaf uit voor releasekandidaten en brede validatie. Android-banen blijven opt-in via `include_android`. Release-only Plugin-dekking staat in de afzonderlijke [`Plugin Prerelease`](#plugin-prerelease)-workflow en draait alleen vanuit [`Full Release Validation`](#full-release-validation) of een expliciete handmatige dispatch.
OpenClaw CI draait bij elke push naar `main` en elke pull request. De `preflight`-taak classificeert de diff en schakelt dure lanes uit wanneer alleen niet-gerelateerde gebieden zijn gewijzigd. Handmatige `workflow_dispatch`-runs omzeilen bewust slimme scoping en waaieren de volledige grafiek uit voor releasekandidaten en brede validatie. Android-lanes blijven opt-in via `include_android`. Release-only Plugin-dekking staat in de afzonderlijke [`Plugin Prerelease`](#plugin-prerelease)-workflow en draait alleen vanuit [`Full Release Validation`](#full-release-validation) of een expliciete handmatige dispatch.
## Pipeline-overzicht
| Taak | Doel | Wanneer deze draait |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ----------------------------------- |
| `preflight` | Detecteert docs-only wijzigingen, gewijzigde scopes, gewijzigde extensions en bouwt het CI-manifest | Altijd bij niet-conceptpushes en PR's |
| `security-scm-fast` | Detectie van privésleutels en workflow-audit via `zizmor` | Altijd bij niet-conceptpushes en PR's |
| `security-dependency-audit` | Productie-lockfile-audit zonder afhankelijkheden tegen npm-adviezen | Altijd bij niet-conceptpushes en PR's |
| `security-fast` | Vereiste aggregatie voor de snelle beveiligingstaken | Altijd bij niet-conceptpushes en PR's |
| `check-dependencies` | Productie-Knip-doorgang alleen voor afhankelijkheden plus de allowlist-bewaking voor ongebruikte bestanden | Node-relevante wijzigingen |
| `build-artifacts` | Bouwt `dist/`, Control UI, controles voor gebouwde artefacten en herbruikbare downstream-artefacten | Node-relevante wijzigingen |
| `checks-fast-core` | Snelle Linux-correctheidsbanen zoals gebundelde/plugin-contract/protocol-controles | Node-relevante wijzigingen |
| `checks-fast-contracts-channels` | Geshaarde kanaalcontractcontroles met een stabiel geaggregeerd controleresultaat | Node-relevante wijzigingen |
| `checks-node-core-test` | Core Node-testshards, met uitzondering van kanaal-, gebundelde, contract- en extension-banen | Node-relevante wijzigingen |
| `check` | Geshaarde equivalent van de belangrijkste lokale gate: productietypes, lint, bewakingen, testtypes en strikte smoke | Node-relevante wijzigingen |
| `check-additional` | Architectuur-, boundary-, prompt-snapshotdrift-, extension-surface-, package-boundary- en gateway-watch-shards | Node-relevante wijzigingen |
| `build-smoke` | Smoke-tests voor de gebouwde CLI en startup-memory-smoke | Node-relevante wijzigingen |
| `checks` | Verificateur voor kanaaltests van gebouwde artefacten | Node-relevante wijzigingen |
| `checks-node-compat-node22` | Node 22-compatibiliteitsbouw en smoke-baan | Handmatige CI-dispatch voor releases |
| `check-docs` | Docs-formattering, lint en controles op kapotte links | Docs gewijzigd |
| `skills-python` | Ruff + pytest voor Python-ondersteunde Skills | Python-skill-relevante wijzigingen |
| `checks-windows` | Windows-specifieke proces-/padtests plus regressies voor gedeelde runtime-importspecificaties | Windows-relevante wijzigingen |
| `macos-node` | macOS TypeScript-testbaan met de gedeelde gebouwde artefacten | macOS-relevante wijzigingen |
| `macos-swift` | Swift-lint, build en tests voor de macOS-app | macOS-relevante wijzigingen |
| `android` | Android-unittests voor beide flavors plus één debug-APK-build | Android-relevante wijzigingen |
| `test-performance-agent` | Dagelijkse Codex-optimalisatie van trage tests na vertrouwde activiteit | Succesvolle hoofd-CI of handmatige dispatch |
| `openclaw-performance` | Dagelijkse/op-aanvraag Kova-runtimeprestatierapporten met mock-provider-, deep-profile- en GPT 5.4-livebanen | Geplande en handmatige dispatch |
| Taak | Doel | Wanneer deze draait |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------- |
| `preflight` | Detecteert docs-only wijzigingen, gewijzigde scopes, gewijzigde extensies en bouwt het CI-manifest | Altijd bij niet-concept-pushes en PR's |
| `security-scm-fast` | Detectie van privésleutels en workflow-audit via `zizmor` | Altijd bij niet-concept-pushes en PR's |
| `security-dependency-audit` | Productie-lockfile-audit zonder afhankelijkheden tegen npm-advisories | Altijd bij niet-concept-pushes en PR's |
| `security-fast` | Vereiste aggregatie voor de snelle beveiligingstaken | Altijd bij niet-concept-pushes en PR's |
| `check-dependencies` | Productie-Knip-pass alleen voor afhankelijkheden plus de allowlist-bewaker voor ongebruikte bestanden | Node-relevante wijzigingen |
| `build-artifacts` | Bouwt `dist/`, Control UI, controles voor gebouwde artefacten en herbruikbare downstream-artefacten | Node-relevante wijzigingen |
| `checks-fast-core` | Snelle Linux-correctheidslanes zoals controles voor gebundelde Plugins/Plugin-contracten/protocollen | Node-relevante wijzigingen |
| `checks-fast-contracts-channels` | Gesherde kanaalcontractcontroles met een stabiel geaggregeerd controleresultaat | Node-relevante wijzigingen |
| `checks-node-core-test` | Core Node-testshards, exclusief kanaal-, gebundelde, contract- en extensielanes | Node-relevante wijzigingen |
| `check` | Gesherde equivalent van de belangrijkste lokale gate: productietypen, lint, bewakers, testtypen en strikte smoke | Node-relevante wijzigingen |
| `check-additional` | Architectuur, grenzen, prompt-snapshotdrift, extensie-oppervlakbewakers, pakketgrenzen en gateway-watch-shards | Node-relevante wijzigingen |
| `build-smoke` | Smoke-tests voor de gebouwde CLI en smoke voor opstartgeheugen | Node-relevante wijzigingen |
| `checks` | Verificatie voor kanaaltests van gebouwde artefacten | Node-relevante wijzigingen |
| `checks-node-compat-node22` | Node 22-compatibiliteitsbuild en smoke-lane | Handmatige CI-dispatch voor releases |
| `check-docs` | Docs-formattering, lint en controles op kapotte links | Docs gewijzigd |
| `skills-python` | Ruff + pytest voor Python-ondersteunde Skills | Python-Skill-relevante wijzigingen |
| `checks-windows` | Windows-specifieke proces-/padtests plus regressies in gedeelde runtime-importspecifiers | Windows-relevante wijzigingen |
| `macos-node` | macOS TypeScript-testlane met de gedeelde gebouwde artefacten | macOS-relevante wijzigingen |
| `macos-swift` | Swift-lint, build en tests voor de macOS-app | macOS-relevante wijzigingen |
| `android` | Android-unittests voor beide flavors plus één debug-APK-build | Android-relevante wijzigingen |
| `test-performance-agent` | Dagelijkse Codex-optimalisatie voor trage tests na vertrouwde activiteit | Succesvolle main-CI of handmatige dispatch |
| `openclaw-performance` | Dagelijkse/op aanvraag Kova-runtimeprestatierapporten met mockprovider-, deep-profile- en GPT 5.4-live-lanes | Geplande en handmatige dispatch |
## Fail-fast-volgorde
1. `preflight` bepaalt welke banen überhaupt bestaan. De `docs-scope`- en `changed-scope`-logica zijn stappen binnen deze taak, geen zelfstandige taken.
1. `preflight` beslist welke lanes überhaupt bestaan. De `docs-scope`- en `changed-scope`-logica zijn stappen binnen deze taak, geen zelfstandige taken.
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` en `skills-python` falen snel zonder te wachten op de zwaardere artefact- en platformmatrixtaken.
3. `build-artifacts` overlapt met de snelle Linux-banen zodat downstream-consumenten kunnen starten zodra de gedeelde build gereed is.
4. Zwaardere platform- en runtimebanen waaieren daarna uit: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` en `android`.
3. `build-artifacts` overlapt met de snelle Linux-lanes zodat downstream-consumenten kunnen starten zodra de gedeelde build klaar is.
4. Zwaardere platform- en runtimelanes waaieren daarna uit: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` en `android`.
GitHub kan vervangen taken als `cancelled` markeren wanneer een nieuwere push op dezelfde PR of `main`-ref landt. Behandel dat als CI-ruis, tenzij de nieuwste run voor dezelfde ref ook faalt. Geaggregeerde shard-controles gebruiken `!cancelled() && always()` zodat ze nog steeds normale shard-fouten rapporteren, maar niet in de wachtrij komen nadat de hele workflow al is vervangen. De automatische CI-concurrency-sleutel is geversioneerd (`CI-v7-*`), zodat een GitHub-side zombie in een oude wachtrijgroep nieuwere main-runs niet onbeperkt kan blokkeren. Handmatige volledige-suite-runs gebruiken `CI-manual-v1-*` en annuleren lopende runs niet.
GitHub kan vervangen taken als `cancelled` markeren wanneer een nieuwere push op dezelfde PR- of `main`-ref landt. Behandel dat als CI-ruis tenzij de nieuwste run voor dezelfde ref ook faalt. Geaggregeerde shardcontroles gebruiken `!cancelled() && always()` zodat ze normale shardfouten nog steeds rapporteren, maar niet meer in de wachtrij komen nadat de hele workflow al is vervangen. De automatische CI-concurrency key is geversioneerd (`CI-v7-*`), zodat een zombie aan GitHub-zijde in een oude wachtrijgroep nieuwere main-runs niet onbeperkt kan blokkeren. Handmatige full-suite-runs gebruiken `CI-manual-v1-*` en annuleren lopende runs niet.
## Scope en routering
Scope-logica staat in `scripts/ci-changed-scope.mjs` en wordt gedekt door unittests in `src/scripts/ci-changed-scope.test.ts`. Handmatige dispatch slaat changed-scope-detectie over en laat het preflight-manifest zich gedragen alsof elk scoped gebied is gewijzigd.
Scopelogica staat in `scripts/ci-changed-scope.mjs` en wordt gedekt door unittests in `src/scripts/ci-changed-scope.test.ts`. Handmatige dispatch slaat changed-scope-detectie over en laat het preflight-manifest doen alsof elk gescoped gebied is gewijzigd.
- **CI-workflowbewerkingen** valideren de Node CI-graaf plus workflow-linting, maar forceren op zichzelf geen native Windows-, Android- of macOS-builds; die platformbanen blijven scoped op platformbronwijzigingen.
- **Alleen-CI-routeringsbewerkingen, geselecteerde goedkope core-testfixturebewerkingen en smalle plugin-contract-helper-/test-routeringsbewerkingen** gebruiken een snel Node-only manifestpad: `preflight`, beveiliging en één `checks-fast-core`-taak. Dat pad slaat buildartefacten, Node 22-compatibiliteit, kanaalcontracten, volledige core-shards, gebundelde-plugin-shards en aanvullende bewakingsmatrices over wanneer de wijziging beperkt is tot de routerings- of helperoppervlakken die de snelle taak direct oefent.
- **Windows Node-controles** zijn scoped op Windows-specifieke proces-/padwrappers, npm/pnpm/UI-runnerhelpers, package-managerconfiguratie en de CI-workflowoppervlakken die die baan uitvoeren; niet-gerelateerde bron-, plugin-, install-smoke- en test-only wijzigingen blijven op de Linux Node-banen.
- **CI-workflowbewerkingen** valideren de Node-CI-grafiek plus workflow-linting, maar forceren op zichzelf geen native Windows-, Android- of macOS-builds; die platformlanes blijven gescoped op wijzigingen in platformbroncode.
- **CI-bewerkingen die alleen routering raken, geselecteerde goedkope fixturebewerkingen voor core-tests en smalle Plugin-contracthelper-/testrouteringsbewerkingen** gebruiken een snel Node-only manifestpad: `preflight`, beveiliging en één `checks-fast-core`-taak. Dat pad slaat buildartefacten, Node 22-compatibiliteit, kanaalcontracten, volledige core-shards, gebundelde-Plugin-shards en aanvullende bewakermatrices over wanneer de wijziging beperkt is tot de routerings- of helperoppervlakken die de snelle taak direct oefent.
- **Windows Node-controles** zijn gescoped op Windows-specifieke proces-/padwrappers, npm/pnpm/UI-runnerhelpers, pakketmanagerconfiguratie en de CI-workflowoppervlakken die die lane uitvoeren; niet-gerelateerde broncode-, Plugin-, install-smoke- en test-only wijzigingen blijven op de Linux Node-lanes.
De traagste Node-testfamilies worden gesplitst of gebalanceerd zodat elke taak klein blijft zonder runners te veel te reserveren: kanaalcontracten draaien als drie gewogen shards, kleine core-unitbanen worden gekoppeld, auto-reply draait als vier gebalanceerde workers (waarbij de reply-subtree is gesplitst in agent-runner-, dispatch- en commands/state-routing-shards) en agentic gateway-/pluginconfiguraties worden verspreid over de bestaande source-only agentic Node-taken in plaats van te wachten op gebouwde artefacten. Brede browser-, QA-, media- en diverse plugintests gebruiken hun eigen Vitest-configs in plaats van de gedeelde plugin-catch-all. Include-pattern-shards registreren timingvermeldingen met de CI-shardnaam, zodat `.artifacts/vitest-shard-timings.json` een volledige config van een gefilterde shard kan onderscheiden. `check-additional` houdt package-boundary-compile-/canary-werk bij elkaar en scheidt runtime-topologiearchitectuur van Gateway-watch-dekking; de boundary-guard-shard draait zijn kleine onafhankelijke bewakingen gelijktijdig binnen één taak, inclusief `pnpm prompt:snapshots:check` zodat Codex-happy-path-promptdrift wordt vastgepind aan de PR die deze veroorzaakte. Gateway-watch, kanaaltests en de core support-boundary-shard draaien gelijktijdig binnen `build-artifacts` nadat `dist/` en `dist-runtime/` al zijn gebouwd.
De traagste Node-testfamilies zijn gesplitst of gebalanceerd zodat elke taak klein blijft zonder runners te ruim te reserveren: kanaalcontracten draaien als drie gewogen shards, kleine core-unitlanes worden gekoppeld, auto-reply draait als vier gebalanceerde workers (waarbij de reply-subtree is gesplitst in agent-runner-, dispatch- en commands/state-routing-shards), en agentic Gateway-/Plugin-configuraties zijn verdeeld over de bestaande source-only agentic Node-taken in plaats van te wachten op gebouwde artefacten. Brede browser-, QA-, media- en overige Plugin-tests gebruiken hun eigen Vitest-configuraties in plaats van de gedeelde Plugin-catch-all. Include-pattern-shards registreren timingitems met de CI-shardnaam, zodat `.artifacts/vitest-shard-timings.json` een hele configuratie kan onderscheiden van een gefilterde shard. `check-additional` houdt compile-/canary-werk voor pakketgrenzen bij elkaar en scheidt runtime-topologiearchitectuur van gateway-watch-dekking; de boundary guard-shard draait zijn kleine onafhankelijke bewakers gelijktijdig binnen één taak, inclusief `pnpm prompt:snapshots:check`, zodat promptdrift in het happy-path van de Codex-runtime wordt vastgepind aan de PR die deze veroorzaakte. Gateway watch, kanaaltests en de core support-boundary-shard draaien gelijktijdig binnen `build-artifacts` nadat `dist/` en `dist-runtime/` al zijn gebouwd.
Android CI draait zowel `testPlayDebugUnitTest` als `testThirdPartyDebugUnitTest` en bouwt daarna de Play-debug-APK. De third-party-flavor heeft geen aparte sourceset of manifest; de unittestsbaan compileert de flavor nog steeds met de SMS/call-log BuildConfig-flags, terwijl een dubbele debug-APK-package-taak bij elke Android-relevante push wordt vermeden.
Android-CI draait zowel `testPlayDebugUnitTest` als `testThirdPartyDebugUnitTest` en bouwt daarna de Play debug-APK. De third-party flavor heeft geen aparte sourceset of manifest; de unit-testlane compileert de flavor nog steeds met de BuildConfig-vlaggen voor SMS/belgeschiedenis, terwijl een dubbele debug-APK-packagingtaak bij elke Android-relevante push wordt vermeden.
De `check-dependencies`-shard draait `pnpm deadcode:dependencies` (een productie-Knip-doorgang alleen voor afhankelijkheden, vastgepind op de nieuwste Knip-versie, met pnpm's minimale releaseleeftijd uitgeschakeld voor de `dlx`-installatie) en `pnpm deadcode:unused-files`, die Knips productiebevindingen voor ongebruikte bestanden vergelijkt met `scripts/deadcode-unused-files.allowlist.mjs`. De ongebruikte-bestandenbewaking faalt wanneer een PR een nieuw niet-beoordeeld ongebruikt bestand toevoegt of een verouderde allowlist-vermelding achterlaat, terwijl opzettelijke dynamische plugin-, gegenereerde, build-, live-test- en package-bridge-oppervlakken behouden blijven die Knip niet statisch kan oplossen.
De `check-dependencies`-shard draait `pnpm deadcode:dependencies` (een productie-Knip-pass alleen voor afhankelijkheden, vastgezet op de nieuwste Knip-versie, met pnpm's minimale releaseleeftijd uitgeschakeld voor de `dlx`-installatie) en `pnpm deadcode:unused-files`, dat Knip's productiebevindingen voor ongebruikte bestanden vergelijkt met `scripts/deadcode-unused-files.allowlist.mjs`. De unused-file-bewaker faalt wanneer een PR een nieuw niet-beoordeeld ongebruikt bestand toevoegt of een verouderde allowlist-entry laat staan, terwijl opzettelijke dynamische Plugin-, gegenereerde, build-, live-test- en pakketbrugoppervlakken behouden blijven die Knip niet statisch kan oplossen.
## ClawSweeper-activiteitsdoorsturing
## Doorsturen van ClawSweeper-activiteit
`.github/workflows/clawsweeper-dispatch.yml` is de doelzijdebrug van OpenClaw-repositoryactiviteit naar ClawSweeper. Deze checkt geen niet-vertrouwde pull-aanvraagcode uit en voert die ook niet uit. De workflow maakt een GitHub App-token vanuit `CLAWSWEEPER_APP_PRIVATE_KEY` en verzendt vervolgens compacte `repository_dispatch`-payloads naar `openclaw/clawsweeper`.
`.github/workflows/clawsweeper-dispatch.yml` is de bridge aan doelzijde van OpenClaw-repositoryactiviteit naar ClawSweeper. Deze checkt geen onvertrouwde pullrequestcode uit en voert die ook niet uit. De workflow maakt een GitHub App-token aan vanuit `CLAWSWEEPER_APP_PRIVATE_KEY` en dispatcht daarna compacte `repository_dispatch`-payloads naar `openclaw/clawsweeper`.
De workflow heeft vier banen:
De workflow heeft vier lanes:
- `clawsweeper_item` voor exacte beoordelingsverzoeken voor issues en pull-aanvragen;
- `clawsweeper_comment` voor expliciete ClawSweeper-commando's in issue-opmerkingen;
- `clawsweeper_commit_review` voor commit-level beoordelingsverzoeken op `main`-pushes;
- `clawsweeper_item` voor exacte reviewverzoeken voor issues en pull requests;
- `clawsweeper_comment` voor expliciete ClawSweeper-commando's in issuecomments;
- `clawsweeper_commit_review` voor reviewverzoeken op commitniveau bij `main`-pushes;
- `github_activity` voor algemene GitHub-activiteit die de ClawSweeper-agent kan inspecteren.
De `github_activity`-baan stuurt alleen genormaliseerde metadata door: eventtype, actie, actor, repository, itemnummer, URL, titel, status en korte fragmenten voor opmerkingen of beoordelingen wanneer aanwezig. Deze vermijdt bewust het doorsturen van de volledige Webhook-body. De ontvangende workflow in `openclaw/clawsweeper` is `.github/workflows/github-activity.yml`, die het genormaliseerde event naar de OpenClaw Gateway-hook voor de ClawSweeper-agent post.
De `github_activity`-lane stuurt alleen genormaliseerde metadata door: eventtype, actie, actor, repository, itemnummer, URL, titel, status en korte fragmenten voor comments of reviews wanneer aanwezig. Deze vermijdt bewust het doorsturen van de volledige Webhook-body. De ontvangende workflow in `openclaw/clawsweeper` is `.github/workflows/github-activity.yml`, die de genormaliseerde gebeurtenis naar de OpenClaw Gateway-hook voor de ClawSweeper-agent post.
Algemene activiteit is observatie, geen standaardbezorging. De ClawSweeper-agent ontvangt het Discord-doel in zijn prompt en mag alleen naar `#clawsweeper` posten wanneer het event verrassend, actiegericht, riskant of operationeel nuttig is. Routinematige opens, bewerkingen, botverloop, dubbele Webhook-ruis en normaal reviewverkeer moeten resulteren in `NO_REPLY`.
Algemene activiteit is observatie, geen standaardbezorging. De ClawSweeper-agent ontvangt het Discord-doel in zijn prompt en hoort alleen naar `#clawsweeper` te posten wanneer de gebeurtenis verrassend, actiegericht, riskant of operationeel nuttig is. Routinematig openen, bewerken, botverloop, dubbele Webhook-ruis en normaal reviewverkeer moeten resulteren in `NO_REPLY`.
Behandel GitHub-titels, opmerkingen, bodies, reviewtekst, branchnamen en commitberichten in dit hele pad als niet-vertrouwde data. Ze zijn input voor samenvatting en triage, geen instructies voor de workflow of agent-runtime.
Behandel GitHub-titels, comments, bodies, reviewtekst, branchnamen en commitberichten overal in dit pad als onvertrouwde data. Ze zijn input voor samenvatting en triage, geen instructies voor de workflow- of agentruntime.
## Handmatige dispatches
Handmatige CI-dispatches voeren dezelfde jobgrafiek uit als normale CI, maar zetten elke niet-Android scope-lane geforceerd aan: Linux Node-shards, gebundelde-Plugin-shards, kanaalcontracten, Node 22-compatibiliteit, `check`, `check-additional`, build-smoke, docs-controles, Python Skills, Windows, macOS en Control UI-i18n. Losstaande handmatige CI-dispatches voeren alleen Android uit met `include_android=true`; de volledige releaseparaplu schakelt Android in door `include_android=true` door te geven. Statische controles voor Plugin-prerelease, de alleen-voor-release `agentic-plugins`-shard, de volledige batch-sweep voor extensies en Docker-lanes voor Plugin-prerelease zijn uitgesloten van CI. De Docker-prerelease-suite wordt alleen uitgevoerd wanneer `Full Release Validation` de afzonderlijke `Plugin Prerelease`-workflow dispatcht met de release-validatiegate ingeschakeld.
Handmatige CI-dispatches voeren dezelfde jobgrafiek uit als normale CI, maar schakelen elke niet-Android scope-lane geforceerd in: Linux Node-shards, gebundelde-plugin-shards, kanaalcontracten, Node 22-compatibiliteit, `check`, `check-additional`, build-smoke, docs-controles, Python Skills, Windows, macOS en Control UI i18n. Losstaande handmatige CI-dispatches voeren alleen Android uit met `include_android=true`; de volledige release-umbrella schakelt Android in door `include_android=true` door te geven. Statische controles voor plugin-prereleases, de alleen-voor-release `agentic-plugins`-shard, de volledige batch-sweep van extensions en Docker-lanes voor plugin-prereleases zijn uitgesloten van CI. De Docker-prerelease-suite draait alleen wanneer `Full Release Validation` de aparte `Plugin Prerelease`-workflow dispatcht met de releasevalidatie-gate ingeschakeld.
Handmatige runs gebruiken een unieke concurrencygroep, zodat een volledige suite voor een release candidate niet wordt geannuleerd door een andere push- of PR-run op dezelfde ref. Met de optionele `target_ref`-invoer kan een vertrouwde aanroeper die grafiek uitvoeren tegen een branch, tag of volledige commit-SHA, terwijl het workflowbestand van de geselecteerde dispatch-ref wordt gebruikt.
Handmatige runs gebruiken een unieke concurrency-groep zodat een volledige suite voor een releasekandidaat niet wordt geannuleerd door een andere push- of PR-run op dezelfde ref. Met de optionele `target_ref`-invoer kan een vertrouwde aanroeper die grafiek uitvoeren tegen een branch, tag of volledige commit-SHA, terwijl het workflowbestand van de geselecteerde dispatch-ref wordt gebruikt.
```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>
## Runners
| Runner | Jobs |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ubuntu-24.04` | `preflight`, snelle beveiligingsjobs en aggregaten (`security-scm-fast`, `security-dependency-audit`, `security-fast`), snelle protocol-/contract-/gebundelde controles, gesharde kanaalcontractcontroles, `check`-shards behalve lint, `check-additional`-shards en aggregaten, aggregaatverificateurs voor Node-tests, docs-controles, Python Skills, workflow-sanity, labeler, auto-response; install-smoke-preflight gebruikt ook door GitHub gehoste Ubuntu, zodat de Blacksmith-matrix eerder in de wachtrij kan komen |
| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, lichtere extensieshards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` en `check-test-types` |
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, Linux Node-testshards, gebundelde Plugin-testshards, `android` |
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (CPU-gevoelig genoeg dat 8 vCPU meer kostte dan het opleverde); install-smoke Docker-builds (32-vCPU-wachtrijtijd kostte meer dan het opleverde) |
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
| `blacksmith-6vcpu-macos-latest` | `macos-node` op `openclaw/openclaw`; forks vallen terug op `macos-latest` |
| `blacksmith-12vcpu-macos-latest` | `macos-swift` op `openclaw/openclaw`; forks vallen terug op `macos-latest` |
| Runner | Jobs |
| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ubuntu-24.04` | `preflight`, snelle beveiligingsjobs en aggregaties (`security-scm-fast`, `security-dependency-audit`, `security-fast`), snelle protocol-/contract-/gebundelde controles, gesharde kanaalcontractcontroles, `check`-shards behalve lint, `check-additional`-shards en aggregaties, Node-testaggregatieverificateurs, docs-controles, Python Skills, workflow-sanity, labeler, auto-response; install-smoke-preflight gebruikt ook door GitHub gehoste Ubuntu zodat de Blacksmith-matrix eerder kan wachtrijen |
| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, lichtere extension-shards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` en `check-test-types` |
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, Linux Node-testshards, gebundelde-plugin-testshards, `android` |
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (CPU-gevoelig genoeg dat 8 vCPU meer kostte dan het opleverde); install-smoke Docker-builds (32-vCPU-wachtrijtijd kostte meer dan het opleverde) |
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
| `blacksmith-6vcpu-macos-latest` | `macos-node` op `openclaw/openclaw`; forks vallen terug op `macos-latest` |
| `blacksmith-12vcpu-macos-latest` | `macos-swift` op `openclaw/openclaw`; forks vallen terug op `macos-latest` |
## Lokale equivalenten
@ -135,9 +135,9 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
pnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.json --output .artifacts/kova/summary.md
```
## OpenClaw Performance
## OpenClaw-prestaties
`OpenClaw Performance` is de workflow voor product-/runtimeprestaties. Deze wordt dagelijks op `main` uitgevoerd en kan handmatig worden gedispatcht:
`OpenClaw Performance` is de product-/runtime-prestatieworkflow. Deze draait dagelijks op `main` en kan handmatig worden gedispatcht:
```bash
gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3
@ -146,26 +146,26 @@ gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1
De workflow installeert OCM vanuit een gepinde release en Kova vanuit de gepinde `kova_ref`-invoer, en voert daarna drie lanes uit:
- `mock-provider`: diagnostische Kova-scenario's tegen een lokaal gebouwde runtime met deterministische nep-auth die compatibel is met OpenAI.
- `mock-provider`: Kova-diagnostische scenario's tegen een lokaal gebouwde runtime met deterministische neppe OpenAI-compatibele auth.
- `mock-deep-profile`: CPU-/heap-/traceprofilering voor hotspots bij opstarten, Gateway en agent-turns.
- `live-gpt54`: een echte OpenAI `openai/gpt-5.4` agent-turn, overgeslagen wanneer `OPENAI_API_KEY` niet beschikbaar is.
- `live-gpt54`: een echte OpenAI `openai/gpt-5.4`-agent-turn, overgeslagen wanneer `OPENAI_API_KEY` niet beschikbaar is.
De mock-provider-lane voert na de Kova-pass ook OpenClaw-native bronprobes uit: Gateway-opstarttiming en geheugen over standaard-, hook- en 50-Plugin-opstartcases; herhaalde mock-OpenAI `channel-chat-baseline` hello-loops; en CLI-opstartcommando's tegen de opgestarte Gateway. De Markdown-samenvatting van de bronprobe staat op `source/index.md` in de rapportbundel, met ruwe JSON ernaast.
De mock-provider-lane voert na de Kova-pass ook OpenClaw-native bronprobes uit: Gateway-opstarttijd en geheugen in standaard-, hook- en 50-plugin-opstartgevallen; herhaalde mock-OpenAI `channel-chat-baseline`-hello-lussen; en CLI-opstartcommando's tegen de opgestarte Gateway. De Markdown-samenvatting van de bronprobe staat op `source/index.md` in de rapportbundel, met ruwe JSON ernaast.
Elke lane uploadt GitHub-artefacten. Wanneer `CLAWGRIT_REPORTS_TOKEN` is geconfigureerd, commit de workflow ook `report.json`, `report.md`, bundels, `index.md` en bronprobe-artefacten naar `openclaw/clawgrit-reports` onder `openclaw-performance/<ref>/<run-id>-<attempt>/<lane>/`. De huidige branch-pointer wordt geschreven als `openclaw-performance/<ref>/latest-<lane>.json`.
Elke lane uploadt GitHub-artefacten. Wanneer `CLAWGRIT_REPORTS_TOKEN` is geconfigureerd, commit de workflow ook `report.json`, `report.md`, bundels, `index.md` en bronprobe-artefacten naar `openclaw/clawgrit-reports` onder `openclaw-performance/<ref>/<run-id>-<attempt>/<lane>/`. De huidige branchpointer wordt geschreven als `openclaw-performance/<ref>/latest-<lane>.json`.
## Volledige Release-validatie
## Volledige releasevalidatie
`Full Release Validation` is de handmatige parapluworkflow voor "alles uitvoeren vóór de release". Deze accepteert een branch, tag of volledige commit-SHA, dispatcht de handmatige `CI`-workflow met dat doel, dispatcht `Plugin Prerelease` voor alleen-voor-release Plugin-/pakket-/statische-/Docker-bewijzen, en dispatcht `OpenClaw Release Checks` voor install-smoke, pakketacceptatie, Docker-releasepad-suites, live/E2E, OpenWebUI, QA Lab-pariteit, Matrix en Telegram-lanes. Met `rerun_group=all` en `release_profile=full` voert deze ook `NPM Telegram Beta E2E` uit tegen het `release-package-under-test`-artefact uit release checks. Geef na publicatie `npm_telegram_package_spec` door om dezelfde Telegram-pakketlane opnieuw uit te voeren tegen het gepubliceerde npm-pakket.
`Full Release Validation` is de handmatige umbrella-workflow voor "alles uitvoeren vóór release." Deze accepteert een branch, tag of volledige commit-SHA, dispatcht de handmatige `CI`-workflow met dat doel, dispatcht `Plugin Prerelease` voor alleen-voor-release plugin-/pakket-/statische-/Docker-bewijsvoering, en dispatcht `OpenClaw Release Checks` voor install-smoke, pakketacceptatie, Docker-releasepad-suites, live/E2E, OpenWebUI, QA Lab-pariteit, Matrix en Telegram-lanes. Met `rerun_group=all` en `release_profile=full` draait deze ook `NPM Telegram Beta E2E` tegen het `release-package-under-test`-artefact uit releasecontroles. Geef na publicatie `npm_telegram_package_spec` door om dezelfde Telegram-pakketlane opnieuw te draaien tegen het gepubliceerde npm-pakket.
Zie [Volledige releasevalidatie](/nl/reference/full-release-validation) voor de
fasematrix, exacte workflow-jobnamen, profielverschillen, artefacten en
fasematrix, exacte workflowjobnamen, profielverschillen, artefacten en
gerichte rerun-handles.
`OpenClaw Release Publish` is de handmatige muterende releaseworkflow. Dispatch deze
vanuit `release/YYYY.M.D` of `main` nadat de releasetag bestaat en nadat de
OpenClaw npm-preflight is geslaagd. Deze verifieert `pnpm plugins:sync:check`,
dispatcht `Plugin NPM Release` voor alle publiceerbare Plugin-pakketten, dispatcht
dispatcht `Plugin NPM Release` voor alle publiceerbare plugin-pakketten, dispatcht
`Plugin ClawHub Release` voor dezelfde release-SHA, en dispatcht pas daarna
`OpenClaw NPM Release` met de opgeslagen `preflight_run_id`.
@ -177,43 +177,43 @@ gh workflow run openclaw-release-publish.yml \
-f npm_dist_tag=beta
```
Gebruik voor bewijs van een gepinde commit op een snel bewegende branch de helper in plaats van
Gebruik voor gepind commitbewijs op een snel bewegende branch de helper in plaats van
`gh workflow run ... --ref main -f ref=<sha>`:
```bash
pnpm ci:full-release --sha <full-sha>
```
GitHub-workflow-dispatch-refs moeten branches of tags zijn, geen ruwe commit-SHA's. De
GitHub-workflowdispatch-refs moeten branches of tags zijn, geen ruwe commit-SHA's. De
helper pusht een tijdelijke `release-ci/<sha>-...`-branch op de doel-SHA,
dispatcht `Full Release Validation` vanuit die gepinde ref, verifieert dat elke child-
workflow `headSha` overeenkomt met het doel, en verwijdert de tijdelijke branch wanneer de
run is voltooid. De parapluverificateur faalt ook als een child-workflow op een
andere SHA is uitgevoerd.
dispatcht `Full Release Validation` vanaf die gepinde ref, verifieert dat elke child-workflow
`headSha` overeenkomt met het doel, en verwijdert de tijdelijke branch wanneer de
run is voltooid. De umbrella-verificateur faalt ook als een child-workflow op een
andere SHA draaide.
`release_profile` bepaalt de live/provider-breedte die aan release checks wordt doorgegeven. De
handmatige releaseworkflows gebruiken standaard `stable`; gebruik `full` alleen wanneer je
`release_profile` bepaalt de live-/providerbreedte die wordt doorgegeven aan releasecontroles. De
handmatige releaseworkflows staan standaard op `stable`; gebruik `full` alleen wanneer je
bewust de brede adviserende provider-/mediamatrix wilt.
- `minimum` behoudt de snelste OpenAI-/core-releasekritieke lanes.
- `stable` voegt de stabiele provider-/backendset toe.
- `full` voert de brede adviserende provider-/mediamatrix uit.
- `full` draait de brede adviserende provider-/mediamatrix.
De paraplu registreert de gedispatchte child-run-id's, en de laatste `Verify full validation`-job controleert de huidige conclusies van child-runs opnieuw en voegt tabellen met de traagste jobs toe voor elke child-run. Als een child-workflow opnieuw wordt uitgevoerd en groen wordt, voer dan alleen de parent-verificateurjob opnieuw uit om het parapluresultaat en de timingsamenvatting te vernieuwen.
De umbrella registreert de gedispatchte child-run-id's, en de laatste `Verify full validation`-job controleert opnieuw de huidige conclusies van child-runs en voegt tabellen met langzaamste jobs toe voor elke child-run. Als een child-workflow opnieuw wordt gedraaid en groen wordt, draai dan alleen de parent-verificateurjob opnieuw om het umbrella-resultaat en de timingsamenvatting te vernieuwen.
Voor herstel accepteren zowel `Full Release Validation` als `OpenClaw Release Checks` `rerun_group`. Gebruik `all` voor een releasekandidaat, `ci` voor alleen het normale volledige CI-child, `plugin-prerelease` voor alleen het plugin-prerelease-child, `release-checks` voor elk release-child, of een smallere groep: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live`, of `npm-telegram` op de overkoepelende workflow. Zo blijft het opnieuw uitvoeren van een mislukte releasebox begrensd na een gerichte fix.
Voor herstel accepteren zowel `Full Release Validation` als `OpenClaw Release Checks` `rerun_group`. Gebruik `all` voor een releasekandidaat, `ci` voor alleen het normale volledige CI-child, `plugin-prerelease` voor alleen het Plugin-prerelease-child, `release-checks` voor elk release-child, of een smallere groep: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live`, of `npm-telegram` op de umbrella. Zo blijft het opnieuw uitvoeren van een mislukte release-box na een gerichte fix afgebakend.
`OpenClaw Release Checks` gebruikt de vertrouwde workflow-ref om de geselecteerde ref één keer om te zetten naar een `release-package-under-test`-tarball, en geeft dat artifact daarna door aan zowel de live/E2E Docker-workflow voor het releasepad als de shard voor package-acceptatie. Zo blijven de packagebytes consistent tussen releaseboxen en wordt voorkomen dat dezelfde kandidaat opnieuw wordt verpakt in meerdere child-jobs.
`OpenClaw Release Checks` gebruikt de vertrouwde workflow-ref om de geselecteerde ref eenmaal op te lossen naar een `release-package-under-test`-tarball, en geeft dat artefact vervolgens door aan zowel de live/E2E Docker-workflow voor het release-pad als de package-acceptance-shard. Zo blijven de package-bytes consistent tussen release-boxes en wordt voorkomen dat dezelfde kandidaat opnieuw wordt verpakt in meerdere child-jobs.
Dubbele `Full Release Validation`-runs voor `ref=main` en `rerun_group=all`
vervangen de oudere overkoepelende workflow. De parent-monitor annuleert elke child-workflow die
vervangen de oudere umbrella. De parent-monitor annuleert elke child-workflow die
al is gestart wanneer de parent wordt geannuleerd, zodat nieuwere main-validatie
niet achter een verouderde twee uur durende release-check-run blijft hangen. Validatie van releasebranches/tags
en gerichte rerun-groepen houden `cancel-in-progress: false`.
niet achter een verouderde twee uur durende release-check-run blijft staan. Release-branch/tag-
validatie en gerichte rerun-groepen behouden `cancel-in-progress: false`.
## Live- en E2E-shards
De release-live/E2E-child behoudt brede native `pnpm test:live`-dekking, maar voert die uit als benoemde shards via `scripts/test-live-shard.mjs` in plaats van als één seriële job:
Het release live/E2E-child behoudt brede native `pnpm test:live`-dekking, maar voert die uit als benoemde shards via `scripts/test-live-shard.mjs` in plaats van als één seriële job:
- `native-live-src-agents`
- `native-live-src-gateway-core`
@ -225,59 +225,59 @@ De release-live/E2E-child behoudt brede native `pnpm test:live`-dekking, maar vo
- `native-live-extensions-openai`
- `native-live-extensions-o-z-other`
- `native-live-extensions-xai`
- gesplitste media-audio/video-shards en provider-gefilterde muziekshards
- gesplitste media-audio/video-shards en provider-gefilterde muziek-shards
Zo blijft dezelfde bestandsdekking behouden terwijl trage live-providerfouten eenvoudiger opnieuw kunnen worden uitgevoerd en gediagnosticeerd. De geaggregeerde shardnamen `native-live-extensions-o-z`, `native-live-extensions-media` en `native-live-extensions-media-music` blijven geldig voor handmatige eenmalige reruns.
Zo blijft dezelfde bestandsdekking behouden, terwijl trage live-providerfouten makkelijker opnieuw kunnen worden uitgevoerd en gediagnosticeerd. De geaggregeerde shardnamen `native-live-extensions-o-z`, `native-live-extensions-media` en `native-live-extensions-media-music` blijven geldig voor handmatige eenmalige reruns.
De native live-mediashards draaien in `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, gebouwd door de workflow `Live Media Runner Image`. Die image installeert `ffmpeg` en `ffprobe` vooraf; mediajobs verifiëren alleen de binaries vóór de setup. Houd Docker-ondersteunde live-suites op normale Blacksmith-runners — containerjobs zijn niet de juiste plaats om geneste Docker-tests te starten.
De native live-media-shards draaien in `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, gebouwd door de workflow `Live Media Runner Image`. Die image installeert `ffmpeg` en `ffprobe` vooraf; media-jobs verifiëren alleen de binaries vóór de setup. Houd door Docker ondersteunde live-suites op normale Blacksmith-runners — containerjobs zijn niet de juiste plek om geneste Docker-tests te starten.
Docker-ondersteunde live model/backend-shards gebruiken een afzonderlijke gedeelde `ghcr.io/openclaw/openclaw-live-test:<sha>`-image per geselecteerde commit. De live-releaseworkflow bouwt en pusht die image één keer, waarna de Docker-live-model-, provider-gesharde Gateway-, CLI-backend-, ACP-bind- en Codex-harnessshards draaien met `OPENCLAW_SKIP_DOCKER_BUILD=1`. Gateway Docker-shards hebben expliciete timeout-limieten op scriptniveau onder de workflow-jobtimeout, zodat een vastgelopen container of cleanup-pad snel faalt in plaats van het volledige release-checkbudget te verbruiken. Als die shards het volledige source-Dockerdoel onafhankelijk opnieuw bouwen, is de releaserun verkeerd geconfigureerd en verspilt die wandkloktijd aan dubbele imagebuilds.
Door Docker ondersteunde live model/backend-shards gebruiken een aparte gedeelde `ghcr.io/openclaw/openclaw-live-test:<sha>`-image per geselecteerde commit. De live-releaseworkflow bouwt en pusht die image eenmaal; daarna draaien de Docker live model-, provider-sharded Gateway-, CLI-backend-, ACP-bind- en Codex-harness-shards met `OPENCLAW_SKIP_DOCKER_BUILD=1`. Gateway Docker-shards hebben expliciete timeout-limieten op scriptniveau onder de workflowjob-timeout, zodat een vastgelopen container of cleanup-pad snel faalt in plaats van het volledige release-checkbudget te verbruiken. Als die shards de volledige source-Docker-target onafhankelijk opnieuw bouwen, is de release-run verkeerd geconfigureerd en verspilt die wandkloktijd aan dubbele image-builds.
## Package-acceptatie
## Package Acceptance
Gebruik `Package Acceptance` wanneer de vraag is: "werkt dit installeerbare OpenClaw-package als product?" Dit verschilt van normale CI: normale CI valideert de source-tree, terwijl package-acceptatie één tarball valideert via dezelfde Docker E2E-harness die gebruikers na installatie of update uitvoeren.
Gebruik `Package Acceptance` wanneer de vraag is: “werkt dit installeerbare OpenClaw-package als product?” Het verschilt van normale CI: normale CI valideert de source tree, terwijl package acceptance één tarball valideert via dezelfde Docker E2E-harness die gebruikers na installatie of update gebruiken.
### Jobs
1. `resolve_package` checkt `workflow_ref` uit, bepaalt één packagekandidaat, schrijft `.artifacts/docker-e2e-package/openclaw-current.tgz`, schrijft `.artifacts/docker-e2e-package/package-candidate.json`, uploadt beide als het artifact `package-under-test`, en drukt de bron, workflow-ref, package-ref, versie, SHA-256 en het profiel af in de GitHub-stapsamenvatting.
2. `docker_acceptance` roept `openclaw-live-and-e2e-checks-reusable.yml` aan met `ref=workflow_ref` en `package_artifact_name=package-under-test`. De herbruikbare workflow downloadt dat artifact, valideert de tarball-inventaris, bereidt package-digest Docker-images voor wanneer nodig, en voert de geselecteerde Docker-lanes uit tegen dat package in plaats van de workflow-checkout te verpakken. Wanneer een profiel meerdere gerichte `docker_lanes` selecteert, bereidt de herbruikbare workflow het package en de gedeelde images één keer voor en waaiert die lanes daarna uit als parallelle gerichte Docker-jobs met unieke artifacts.
3. `package_telegram` roept optioneel `NPM Telegram Beta E2E` aan. Dit draait wanneer `telegram_mode` niet `none` is en installeert hetzelfde `package-under-test`-artifact wanneer Package Acceptance er één heeft bepaald; zelfstandige Telegram-dispatch kan nog steeds een gepubliceerde npm-spec installeren.
4. `summary` laat de workflow falen als packagebepaling, Docker-acceptatie of de optionele Telegram-lane is mislukt.
1. `resolve_package` checkt `workflow_ref` uit, lost één package-kandidaat op, schrijft `.artifacts/docker-e2e-package/openclaw-current.tgz`, schrijft `.artifacts/docker-e2e-package/package-candidate.json`, uploadt beide als het artefact `package-under-test`, en print de bron, workflow-ref, package-ref, versie, SHA-256 en profiel in de GitHub-stapsamenvatting.
2. `docker_acceptance` roept `openclaw-live-and-e2e-checks-reusable.yml` aan met `ref=workflow_ref` en `package_artifact_name=package-under-test`. De herbruikbare workflow downloadt dat artefact, valideert de tarball-inventaris, bereidt package-digest Docker-images voor wanneer nodig, en voert de geselecteerde Docker-lanes uit tegen dat package in plaats van de workflow-checkout te verpakken. Wanneer een profiel meerdere gerichte `docker_lanes` selecteert, bereidt de herbruikbare workflow het package en de gedeelde images eenmaal voor, en verspreidt die lanes vervolgens als parallelle gerichte Docker-jobs met unieke artefacten.
3. `package_telegram` roept optioneel `NPM Telegram Beta E2E` aan. Dit draait wanneer `telegram_mode` niet `none` is en installeert hetzelfde `package-under-test`-artefact wanneer Package Acceptance er een heeft opgelost; zelfstandige Telegram-dispatch kan nog steeds een gepubliceerde npm-specificatie installeren.
4. `summary` laat de workflow falen als package-resolutie, Docker-acceptance of de optionele Telegram-lane is mislukt.
### Kandidaatbronnen
- `source=npm` accepteert alleen `openclaw@alpha`, `openclaw@beta`, `openclaw@latest`, of een exacte OpenClaw-releaseversie zoals `openclaw@2026.4.27-beta.2`. Gebruik dit voor acceptatie van gepubliceerde prerelease/stabiele versies.
- `source=ref` verpakt een vertrouwde `package_ref`-branch, tag of volledige commit-SHA. De resolver haalt OpenClaw-branches/tags op, verifieert dat de geselecteerde commit bereikbaar is vanuit de repository-branchgeschiedenis of een releasetag, installeert dependencies in een detached worktree en verpakt die met `scripts/package-openclaw-for-docker.mjs`.
- `source=npm` accepteert alleen `openclaw@beta`, `openclaw@latest`, of een exacte OpenClaw-releaseversie zoals `openclaw@2026.4.27-beta.2`. Gebruik dit voor gepubliceerde prerelease/stable-acceptance.
- `source=ref` verpakt een vertrouwde `package_ref`-branch, tag of volledige commit-SHA. De resolver fetcht OpenClaw-branches/tags, verifieert dat de geselecteerde commit bereikbaar is vanuit de branch-geschiedenis van de repository of een releasetag, installeert dependencies in een losgekoppelde worktree, en verpakt die met `scripts/package-openclaw-for-docker.mjs`.
- `source=url` downloadt een HTTPS `.tgz`; `package_sha256` is verplicht.
- `source=artifact` downloadt één `.tgz` uit `artifact_run_id` en `artifact_name`; `package_sha256` is optioneel maar moet worden opgegeven voor extern gedeelde artifacts.
- `source=artifact` downloadt één `.tgz` uit `artifact_run_id` en `artifact_name`; `package_sha256` is optioneel maar hoort te worden meegeleverd voor extern gedeelde artefacten.
Houd `workflow_ref` en `package_ref` gescheiden. `workflow_ref` is de vertrouwde workflow-/harnesscode die de test uitvoert. `package_ref` is de source-commit die wordt verpakt wanneer `source=ref`. Hierdoor kan de huidige testharness oudere vertrouwde source-commits valideren zonder oude workflowlogica uit te voeren.
Houd `workflow_ref` en `package_ref` gescheiden. `workflow_ref` is de vertrouwde workflow/harness-code die de test uitvoert. `package_ref` is de source-commit die wordt verpakt wanneer `source=ref`. Hierdoor kan de huidige test-harness oudere vertrouwde source-commits valideren zonder oude workflowlogica uit te voeren.
### Suiteprofielen
- `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` plus `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
- `full` — volledige Docker-releasepadchunks met OpenWebUI
- `full` — volledige Docker-releasepad-chunks met OpenWebUI
- `custom` — exacte `docker_lanes`; verplicht wanneer `suite_profile=custom`
Het `package`-profiel gebruikt offline Plugin-dekking zodat validatie van gepubliceerde packages niet afhankelijk is van live beschikbaarheid van ClawHub. De optionele Telegram-lane hergebruikt het `package-under-test`-artifact in `NPM Telegram Beta E2E`, waarbij het pad met de gepubliceerde npm-spec behouden blijft voor zelfstandige dispatches.
Het `package`-profiel gebruikt offline Plugin-dekking, zodat validatie van gepubliceerde packages niet afhankelijk is van live ClawHub-beschikbaarheid. De optionele Telegram-lane hergebruikt het `package-under-test`-artefact in `NPM Telegram Beta E2E`, terwijl het gepubliceerde npm-specificatiepad behouden blijft voor zelfstandige dispatches.
Voor het specifieke beleid voor update- en plugintests, inclusief lokale opdrachten,
Docker-lanes, Package Acceptance-inputs, releasestandaarden en fouttriage,
Voor het specifieke beleid voor update- en Plugin-tests, inclusief lokale opdrachten,
Docker-lanes, Package Acceptance-inputs, release-standaarden en fouttriage,
zie [Updates en plugins testen](/nl/help/testing-updates-plugins).
Releasechecks roepen Package Acceptance aan met `source=artifact`, het voorbereide releasepackage-artifact, `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` en `telegram_mode=mock-openai`. Zo blijven packagemigratie, update, cleanup van verouderde plugindependencies, herstel van geconfigureerde plugininstallatie, offline Plugin, plugin-update en Telegram-bewijs op dezelfde bepaalde packagetarball. Stel `package_acceptance_package_spec` in op Full Release Validation of OpenClaw Release Checks om diezelfde matrix uit te voeren tegen een verzonden npm-package in plaats van het uit de SHA gebouwde artifact. Cross-OS-releasechecks dekken nog steeds OS-specifieke onboarding, installer- en platformgedrag; productvalidatie voor packages/updates moet beginnen met Package Acceptance. De Docker-lane `published-upgrade-survivor` valideert één gepubliceerde packagebaseline per run. In Package Acceptance is de bepaalde `package-under-test`-tarball altijd de kandidaat en selecteert `published_upgrade_survivor_baseline` de terugvalbaseline uit gepubliceerde packages, standaard `openclaw@latest`; rerun-opdrachten voor mislukte lanes behouden die baseline. Stel `published_upgrade_survivor_baselines=all-since-2026.4.23` in om Full Release CI uit te breiden over elke stabiele npm-release van `2026.4.23` tot en met `latest`; `release-history` blijft beschikbaar voor handmatige bredere sampling met het oudere pre-date-anker. Stel `published_upgrade_survivor_scenarios=reported-issues` in om dezelfde baselines uit te breiden over issue-vormige fixtures voor Feishu-configuratie, behouden bootstrap-/personabestanden, geconfigureerde OpenClaw-plugininstallaties, tilde-logpaden en verouderde roots voor legacy-plugindependencies. De afzonderlijke workflow `Update Migration` gebruikt de Docker-lane `update-migration` met `all-since-2026.4.23` en `plugin-deps-cleanup` wanneer de vraag exhaustieve cleanup van gepubliceerde updates is, niet de normale breedte van Full Release CI. Lokale geaggregeerde runs kunnen exacte package-specs doorgeven met `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, één lane behouden met `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC` zoals `openclaw@2026.4.15`, of `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` instellen voor de scenariomatrix. De gepubliceerde lane configureert de baseline met een ingebakken recept voor de opdracht `openclaw config set`, registreert receptstappen in `summary.json` en test `/healthz`, `/readyz` plus RPC-status na het starten van Gateway. De verse Windows packaged- en installer-lanes verifiëren ook dat een geïnstalleerd package een browser-control-override kan importeren vanuit een raw absoluut Windows-pad. De OpenAI cross-OS agent-turn-smoke gebruikt standaard `OPENCLAW_CROSS_OS_OPENAI_MODEL` wanneer dat is ingesteld, anders `openai/gpt-5.4`, zodat het installatie- en Gateway-bewijs op een GPT-5-testmodel blijft terwijl GPT-4.x-standaarden worden vermeden.
Release-checks roepen Package Acceptance aan met `source=artifact`, het voorbereide releasepackage-artefact, `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` en `telegram_mode=mock-openai`. Zo blijven package-migratie, update, cleanup van verouderde Plugin-dependencies, reparatie van geconfigureerde Plugin-installatie, offline Plugin, Plugin-update en Telegram-bewijs op dezelfde opgeloste package-tarball. Stel `package_acceptance_package_spec` in op Full Release Validation of OpenClaw Release Checks om dezelfde matrix uit te voeren tegen een verzonden npm-package in plaats van het uit de SHA gebouwde artefact. Cross-OS-releasechecks dekken nog steeds OS-specifieke onboarding, installer- en platformgedrag; productvalidatie voor package/update hoort te beginnen met Package Acceptance. De Docker-lane `published-upgrade-survivor` valideert één gepubliceerde package-baseline per run. In Package Acceptance is de opgeloste `package-under-test`-tarball altijd de kandidaat en selecteert `published_upgrade_survivor_baseline` de fallback gepubliceerde baseline, standaard `openclaw@latest`; rerun-opdrachten voor mislukte lanes behouden die baseline. Stel `published_upgrade_survivor_baselines=all-since-2026.4.23` in om Full Release CI uit te breiden over elke stabiele npm-release van `2026.4.23` tot en met `latest`; `release-history` blijft beschikbaar voor handmatige bredere sampling met het oudere anker van vóór die datum. Stel `published_upgrade_survivor_scenarios=reported-issues` in om dezelfde baselines uit te breiden over issue-vormige fixtures voor Feishu-config, behouden bootstrap/persona-bestanden, geconfigureerde OpenClaw Plugin-installaties, tilde-logpaden en verouderde legacy Plugin-dependencyroots. De aparte workflow `Update Migration` gebruikt de Docker-lane `update-migration` met `all-since-2026.4.23` en `plugin-deps-cleanup` wanneer de vraag uitputtende cleanup van gepubliceerde updates is, niet de normale breedte van Full Release CI. Lokale geaggregeerde runs kunnen exacte package-specificaties doorgeven met `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, één lane behouden met `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC` zoals `openclaw@2026.4.15`, of `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` instellen voor de scenariomatrix. De gepubliceerde lane configureert de baseline met een ingebakken `openclaw config set`-opdrachtrecept, legt receptstappen vast in `summary.json`, en controleert `/healthz`, `/readyz`, plus RPC-status na Gateway-start. De fresh lanes voor Windows packaged en installer verifiëren ook dat een geïnstalleerd package een browser-control-override kan importeren vanaf een raw absoluut Windows-pad. De OpenAI cross-OS agent-turn-smoke gebruikt standaard `OPENCLAW_CROSS_OS_OPENAI_MODEL` wanneer ingesteld, anders `openai/gpt-5.4`, zodat het installatie- en Gateway-bewijs op een GPT-5-testmodel blijft en GPT-4.x-standaarden worden vermeden.
### Legacy-compatibiliteitsvensters
Package Acceptance heeft begrensde legacy-compatibiliteitsvensters voor al gepubliceerde packages. Packages tot en met `2026.4.25`, inclusief `2026.4.25-beta.*`, mogen het compatibiliteitspad gebruiken:
Package Acceptance heeft begrensde legacy-compatibiliteitsvensters voor reeds gepubliceerde packages. Packages tot en met `2026.4.25`, inclusief `2026.4.25-beta.*`, mogen het compatibiliteitspad gebruiken:
- bekende private QA-vermeldingen in `dist/postinstall-inventory.json` mogen verwijzen naar bestanden die uit de tarball zijn weggelaten;
- `doctor-switch` mag de subcase voor persistentie van `gateway install --wrapper` overslaan wanneer het package die flag niet exposeert;
- `update-channel-switch` mag ontbrekende `pnpm.patchedDependencies` uit de van tarball afgeleide fake git-fixture snoeien en ontbrekende gepersisteerde `update.channel` loggen;
- plugin-smokes mogen legacy install-record-locaties lezen of ontbrekende persistentie van marketplace-install-records accepteren;
- `plugin-update` mag migratie van configuratiemetadata toestaan terwijl nog steeds wordt vereist dat het install-record en het gedrag zonder herinstallatie ongewijzigd blijven.
- bekende private QA-vermeldingen in `dist/postinstall-inventory.json` mogen wijzen naar bestanden die uit de tarball zijn weggelaten;
- `doctor-switch` mag de subcase voor persistentie van `gateway install --wrapper` overslaan wanneer het package die flag niet aanbiedt;
- `update-channel-switch` mag ontbrekende `pnpm.patchedDependencies` snoeien uit de van de tarball afgeleide fake git-fixture en mag ontbrekende gepersistente `update.channel` loggen;
- Plugin-smokes mogen legacy install-record-locaties lezen of ontbrekende marketplace install-record-persistentie accepteren;
- `plugin-update` mag migratie van configmetadata toestaan, terwijl nog steeds wordt vereist dat het install-record en no-reinstall-gedrag ongewijzigd blijven.
Het gepubliceerde package `2026.4.26` mag ook waarschuwen voor lokale buildmetadata-stempelbestanden die al waren verzonden. Latere packages moeten voldoen aan de moderne contracten; dezelfde voorwaarden falen dan in plaats van te waarschuwen of over te slaan.
@ -322,110 +322,110 @@ gh workflow run package-acceptance.yml \
-f docker_lanes='install-e2e plugin-update'
```
Begin bij het debuggen van een mislukte pakketacceptatierun met de `resolve_package`-samenvatting om de pakketbron, versie en SHA-256 te bevestigen. Inspecteer daarna de `docker_acceptance`-childrun en de Docker-artifacts daarvan: `.artifacts/docker-tests/**/summary.json`, `failures.json`, lane-logs, fasetimings en rerun-opdrachten. Voer bij voorkeur het mislukte pakketprofiel of de exacte Docker-lanes opnieuw uit in plaats van de volledige releasevalidatie opnieuw uit te voeren.
Begin bij het debuggen van een mislukte package-acceptance-run met de `resolve_package`-samenvatting om de pakketbron, versie en SHA-256 te bevestigen. Inspecteer daarna de onderliggende `docker_acceptance`-run en de Docker-artefacten ervan: `.artifacts/docker-tests/**/summary.json`, `failures.json`, lane-logs, fasetimings en rerun-commando's. Geef de voorkeur aan het opnieuw uitvoeren van het mislukte pakketprofiel of de exacte Docker-lanes in plaats van de volledige releasevalidatie opnieuw uit te voeren.
## Installatiesmoke
De afzonderlijke workflow `Install Smoke` hergebruikt hetzelfde scopescript via zijn eigen `preflight`-job. De workflow splitst smoke-dekking op in `run_fast_install_smoke` en `run_full_install_smoke`.
De afzonderlijke workflow `Install Smoke` hergebruikt hetzelfde scope-script via zijn eigen `preflight`-job. Deze splitst smoke-dekking in `run_fast_install_smoke` en `run_full_install_smoke`.
- **Snel pad** draait voor pull requests die Docker-/pakketoppervlakken raken, wijzigingen in gebundelde Plugin-pakketten/-manifesten, of core Plugin-/kanaal-/Gateway-/Plugin SDK-oppervlakken die de Docker-smokejobs uitoefenen. Alleen bronwijzigingen in gebundelde Plugins, test-only-bewerkingen en docs-only-bewerkingen reserveren geen Docker-workers. Het snelle pad bouwt de root-Dockerfile-image eenmalig, controleert de CLI, voert de agents-delete-shared-workspace CLI-smoke uit, voert de container-gateway-network-e2e uit, verifieert een build-argument voor een gebundelde extensie en draait het begrensde gebundelde-Plugin-Docker-profiel onder een totale opdrachttime-out van 240 seconden (waarbij elke Docker-run van een scenario afzonderlijk wordt begrensd).
- **Volledig pad** behoudt QR-pakketinstallatie en installer-Docker-/updatedekking voor nachtelijke geplande runs, handmatige dispatches, workflow-call-releasechecks en pull requests die echt installer-/pakket-/Docker-oppervlakken raken. In volledige modus bereidt install-smoke één target-SHA GHCR-root-Dockerfile-smoke-image voor of hergebruikt die, en voert daarna QR-pakketinstallatie, root-Dockerfile-/Gateway-smokes, installer-/update-smokes en de snelle gebundelde-Plugin-Docker-E2E uit als afzonderlijke jobs, zodat installerwerk niet hoeft te wachten achter de root-image-smokes.
- **Snelle pad** draait voor pull requests die Docker-/pakketoppervlakken raken, wijzigingen in meegeleverde pluginpakketten/manifests, of core-plugin-/kanaal-/gateway-/Plugin SDK-oppervlakken die de Docker-smoke-jobs testen. Broncodewijzigingen die alleen meegeleverde plugins raken, test-only bewerkingen en docs-only bewerkingen reserveren geen Docker-workers. Het snelle pad bouwt de root-Dockerfile-image eenmaal, controleert de CLI, draait de agents-delete shared-workspace CLI-smoke, draait de container-gateway-network-e2e, verifieert een meegeleverde extensie-build-arg en draait het begrensde Docker-profiel voor meegeleverde plugins onder een totale commandotime-out van 240 seconden (waarbij elke Docker-run van een scenario afzonderlijk is begrensd).
- **Volledige pad** bewaart QR-pakketinstallatie en installer-Docker-/updatedekking voor nachtelijke geplande runs, handmatige dispatches, workflow-call-releasechecks en pull requests die daadwerkelijk installer-/pakket-/Docker-oppervlakken raken. In volledige modus bereidt install-smoke één target-SHA GHCR-root-Dockerfile-smoke-image voor of hergebruikt die, en draait daarna QR-pakketinstallatie, root-Dockerfile-/Gateway-smokes, installer-/update-smokes en de snelle Docker-E2E voor meegeleverde plugins als afzonderlijke jobs, zodat installerwerk niet hoeft te wachten op de root-image-smokes.
`main`-pushes (inclusief mergecommits) forceren het volledige pad niet; wanneer changed-scope-logica volledige dekking op een push zou vragen, behoudt de workflow de snelle Docker-smoke en laat de volledige install-smoke over aan nachtelijke of releasevalidatie.
`main`-pushes (inclusief mergecommits) forceren het volledige pad niet; wanneer de changed-scope-logica bij een push volledige dekking zou vragen, behoudt de workflow de snelle Docker-smoke en laat de volledige install-smoke over aan nachtelijke of releasevalidatie.
De trage Bun global-install-image-provider-smoke wordt afzonderlijk afgeschermd door `run_bun_global_install_smoke`. Deze draait volgens het nachtelijke schema en vanuit de releasechecks-workflow, en handmatige `Install Smoke`-dispatches kunnen ervoor kiezen deze mee te nemen, maar pull requests en `main`-pushes doen dat niet. QR- en installer-Docker-tests behouden hun eigen installatiegerichte Dockerfiles.
De trage image-provider-smoke voor globale Bun-installatie wordt afzonderlijk gated door `run_bun_global_install_smoke`. Deze draait volgens het nachtelijke schema en vanuit de releasechecks-workflow, en handmatige `Install Smoke`-dispatches kunnen ervoor kiezen deze mee te nemen, maar pull requests en `main`-pushes doen dat niet. QR- en installer-Docker-tests behouden hun eigen installatiegerichte Dockerfiles.
## Lokale Docker E2E
## Lokale Docker-E2E
`pnpm test:docker:all` bouwt vooraf één gedeelde live-test-image, pakt OpenClaw eenmaal als npm-tarball en bouwt twee gedeelde `scripts/e2e/Dockerfile`-images:
- een kale Node/Git-runner voor installer-/update-/plugin-dependency-lanes;
- een functionele image die dezelfde tarball in `/app` installeert voor normale functionaliteitslanes.
Docker-lanedefinities staan in `scripts/lib/docker-e2e-scenarios.mjs`, plannerlogica staat in `scripts/lib/docker-e2e-plan.mjs`, en de runner voert alleen het geselecteerde plan uit. De scheduler selecteert de image per lane met `OPENCLAW_DOCKER_E2E_BARE_IMAGE` en `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, en voert vervolgens lanes uit met `OPENCLAW_SKIP_DOCKER_BUILD=1`.
Docker-lanedefinities staan in `scripts/lib/docker-e2e-scenarios.mjs`, plannerlogica staat in `scripts/lib/docker-e2e-plan.mjs`, en de runner voert alleen het geselecteerde plan uit. De scheduler selecteert de image per lane met `OPENCLAW_DOCKER_E2E_BARE_IMAGE` en `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, en draait vervolgens lanes met `OPENCLAW_SKIP_DOCKER_BUILD=1`.
### Afstembare instellingen
### Instelbare opties
| Variabele | Standaard | Doel |
| -------------------------------------- | --------- | --------------------------------------------------------------------------------------------- |
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Aantal slots in de hoofdpool voor normale lanes. |
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Aantal slots in de providergevoelige tail-pool. |
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Aantal slots in de main-pool voor normale lanes. |
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Aantal slots in de provider-gevoelige tail-pool. |
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Limiet voor gelijktijdige live-lanes zodat providers niet throttlen. |
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Limiet voor gelijktijdige npm-installatielanes. |
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Limiet voor gelijktijdige multi-service-lanes. |
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Spreiding tussen lane-starts om Docker daemon-create-stormen te vermijden; stel in op `0` voor geen spreiding. |
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Limiet voor gelijktijdige npm-install-lanes. |
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Limiet voor gelijktijdige multi-service-lanes. |
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Spreiding tussen lane-starts om Docker-daemon-create-stormen te voorkomen; zet op `0` voor geen spreiding. |
| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Fallbacktime-out per lane (120 minuten); geselecteerde live-/tail-lanes gebruiken strakkere limieten. |
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | niet ingesteld | `1` print het schedulerplan zonder lanes uit te voeren. |
| `OPENCLAW_DOCKER_ALL_LANES` | niet ingesteld | Door komma's gescheiden exacte lanelijst; slaat cleanup-smoke over zodat agents één mislukte lane kunnen reproduceren. |
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` drukt het schedulerplan af zonder lanes uit te voeren. |
| `OPENCLAW_DOCKER_ALL_LANES` | unset | Exacte lanelijst, gescheiden door komma's; slaat cleanup-smoke over zodat agents één mislukte lane kunnen reproduceren. |
Een lane die zwaarder is dan zijn effectieve limiet kan nog steeds vanuit een lege pool starten en draait daarna alleen totdat hij capaciteit vrijgeeft. De lokale aggregate voert Docker-preflights uit, verwijdert oude OpenClaw E2E-containers, geeft actieve-lanestatus weer, bewaart lanetimings voor longest-first-volgorde en stopt standaard met het inplannen van nieuwe pooled lanes na de eerste fout.
Een lane die zwaarder is dan zijn effectieve limiet kan nog steeds starten vanuit een lege pool, en draait daarna alleen totdat hij capaciteit vrijgeeft. De lokale aggregatie voert Docker-preflights uit, verwijdert verouderde OpenClaw-E2E-containers, geeft actieve-lane-status door, bewaart lanetimings voor longest-first-volgorde en stopt standaard met het plannen van nieuwe gepoolde lanes na de eerste mislukking.
### Herbruikbare live/E2E-workflow
De herbruikbare live/E2E-workflow vraagt `scripts/test-docker-all.mjs --plan-json` welke pakket-, imagetype-, live-image-, lane- en credentialdekking vereist is. `scripts/docker-e2e.mjs` zet dat plan daarna om in GitHub-outputs en samenvattingen. De workflow pakt OpenClaw via `scripts/package-openclaw-for-docker.mjs`, downloadt een pakketartifact uit de huidige run, of downloadt een pakketartifact uit `package_artifact_run_id`; valideert de tarball-inventaris; bouwt en pusht pakket-digest-getagde bare/functionele GHCR Docker E2E-images via Blacksmiths Docker layer cache wanneer het plan lanes met geïnstalleerd pakket nodig heeft; en hergebruikt opgegeven `docker_e2e_bare_image`-/`docker_e2e_functional_image`-inputs of bestaande pakket-digest-images in plaats van opnieuw te bouwen. Docker-image-pulls worden opnieuw geprobeerd met een begrensde time-out van 180 seconden per poging, zodat een vastgelopen registry-/cachestream snel opnieuw probeert in plaats van het grootste deel van het kritieke CI-pad te verbruiken.
De herbruikbare live/E2E-workflow vraagt `scripts/test-docker-all.mjs --plan-json` welke pakket-, imagekind-, live-image-, lane- en credentialdekking vereist is. `scripts/docker-e2e.mjs` zet dat plan vervolgens om in GitHub-outputs en samenvattingen. Deze pakt OpenClaw via `scripts/package-openclaw-for-docker.mjs`, downloadt een pakketartefact uit de huidige run, of downloadt een pakketartefact uit `package_artifact_run_id`; valideert de tarball-inventory; bouwt en pusht package-digest-getagde kale/functionele GHCR Docker-E2E-images via Blacksmiths Docker-layer-cache wanneer het plan lanes nodig heeft met geïnstalleerde pakketten; en hergebruikt meegegeven `docker_e2e_bare_image`-/`docker_e2e_functional_image`-inputs of bestaande package-digest-images in plaats van opnieuw te bouwen. Docker-image-pulls worden opnieuw geprobeerd met een begrensde time-out van 180 seconden per poging, zodat een vastgelopen registry-/cachestream snel opnieuw probeert in plaats van het grootste deel van het kritieke CI-pad te gebruiken.
### Releasepad-delen
### Releasepad-chunks
Release-Docker-dekking draait kleinere chunked jobs met `OPENCLAW_SKIP_DOCKER_BUILD=1`, zodat elk deel alleen het imagetype ophaalt dat het nodig heeft en meerdere lanes uitvoert via dezelfde gewogen scheduler:
Release-Docker-dekking draait kleinere jobs in chunks met `OPENCLAW_SKIP_DOCKER_BUILD=1`, zodat elke chunk alleen het imagekind pullt dat hij nodig heeft en meerdere lanes uitvoert via dezelfde gewogen scheduler:
- `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`
Huidige Release-Docker-delen zijn `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` en `plugins-runtime-install-a` tot en met `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` en `plugins-integrations` blijven aggregate Plugin-/runtime-aliassen. De `install-e2e`-lanealias blijft de aggregate handmatige rerun-alias voor beide provider-installerlanes.
De huidige Release-Docker-chunks zijn `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` en `plugins-runtime-install-a` tot en met `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` en `plugins-integrations` blijven geaggregeerde plugin-/runtime-aliassen. De lane-alias `install-e2e` blijft de geaggregeerde handmatige rerun-alias voor beide provider-installer-lanes.
OpenWebUI wordt opgenomen in `plugins-runtime-services` wanneer volledige releasepaddekking daarom vraagt, en behoudt alleen een zelfstandig `openwebui`-deel voor OpenWebUI-only-dispatches. Gebundelde-kanaal-updatelanes proberen één keer opnieuw bij tijdelijke npm-netwerkfouten.
OpenWebUI wordt opgenomen in `plugins-runtime-services` wanneer volledige releasepaddekking daarom vraagt, en behoudt alleen een zelfstandige `openwebui`-chunk voor OpenWebUI-only dispatches. Bundled-channel-update-lanes proberen één keer opnieuw bij tijdelijke npm-netwerkfouten.
Elk deel uploadt `.artifacts/docker-tests/` met lane-logs, timings, `summary.json`, `failures.json`, fasetimings, schedulerplan-JSON, slow-lane-tabellen en rerun-opdrachten per lane. De workflowinput `docker_lanes` draait geselecteerde lanes tegen de voorbereide images in plaats van de deeljobs, waardoor debugging van mislukte lanes begrensd blijft tot één gerichte Docker-job en het pakketartifact voor die run wordt voorbereid, gedownload of hergebruikt; als een geselecteerde lane een live Docker-lane is, bouwt de gerichte job de live-test-image lokaal voor die rerun. Gegenereerde GitHub-rerun-opdrachten per lane bevatten `package_artifact_run_id`, `package_artifact_name` en voorbereide image-inputs wanneer die waarden bestaan, zodat een mislukte lane het exacte pakket en de exacte images uit de mislukte run kan hergebruiken.
Elke chunk uploadt `.artifacts/docker-tests/` met lane-logs, timings, `summary.json`, `failures.json`, fasetimings, schedulerplan-JSON, slow-lane-tabellen en rerun-commando's per lane. De workflow-input `docker_lanes` draait geselecteerde lanes tegen de voorbereide images in plaats van de chunkjobs, waardoor debugging van mislukte lanes begrensd blijft tot één gerichte Docker-job en het pakketartefact voor die run wordt voorbereid, gedownload of hergebruikt; als een geselecteerde lane een live-Docker-lane is, bouwt de gerichte job de live-test-image lokaal voor die rerun. Gegenereerde GitHub-rerun-commando's per lane bevatten `package_artifact_run_id`, `package_artifact_name` en voorbereide image-inputs wanneer die waarden bestaan, zodat een mislukte lane exact het pakket en de images uit de mislukte run kan hergebruiken.
```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
```
De geplande live/E2E-workflow draait dagelijks de volledige releasepad-Docker-suite.
De geplande live/E2E-workflow draait dagelijks de volledige Releasepad-Docker-suite.
## Plugin-prerelease
## Plugin Prerelease
`Plugin Prerelease` is duurdere product-/pakketdekking, dus het is een afzonderlijke workflow die wordt gedispatcht door `Full Release Validation` of door een expliciete operator. Normale pull requests, `main`-pushes en zelfstandige handmatige CI-dispatches houden die suite uitgeschakeld. De workflow verdeelt gebundelde-Plugin-tests over acht extensieworkers; die extensieshardjobs draaien maximaal twee Plugin-configgroepen tegelijk met één Vitest-worker per groep en een grotere Node-heap, zodat importzware Plugin-batches geen extra CI-jobs aanmaken. Het release-only Docker-prereleasepad batcht gerichte Docker-lanes in kleine groepen om te voorkomen dat tientallen runners worden gereserveerd voor jobs van één tot drie minuten.
`Plugin Prerelease` is duurdere product-/pakketdekking, dus het is een afzonderlijke workflow die wordt gedispatcht door `Full Release Validation` of door een expliciete operator. Normale pull requests, `main`-pushes en zelfstandige handmatige CI-dispatches laten die suite uitgeschakeld. De workflow balanceert tests voor meegeleverde plugins over acht extensieworkers; die extensie-shardjobs draaien maximaal twee pluginconfiguratiegroepen tegelijk met één Vitest-worker per groep en een grotere Node-heap, zodat import-zware pluginbatches geen extra CI-jobs maken. Het release-only Docker-prereleasepad batcht gerichte Docker-lanes in kleine groepen om te voorkomen dat tientallen runners worden gereserveerd voor jobs van één tot drie minuten.
## QA Lab
QA Lab heeft toegewezen CI-lanes buiten de hoofdworkflow met slimme scope. Agentic parity is genest onder de brede QA- en releaseharnassen, niet als zelfstandige PR-workflow. Gebruik `Full Release Validation` met `rerun_group=qa-parity` wanneer parity moet meelopen met een brede validatierun.
QA Lab heeft eigen CI-lanes buiten de belangrijkste smart-scoped workflow. Agentische parity is genest onder de brede QA- en releaseharnassen, niet als zelfstandige PR-workflow. Gebruik `Full Release Validation` met `rerun_group=qa-parity` wanneer parity mee moet lopen met een brede validatierun.
- De workflow `QA-Lab - All Lanes` draait elke nacht op `main` en bij handmatige dispatch; deze waaiert de mock-parity-lane, live Matrix-lane en live Telegram- en Discord-lanes uit als parallelle jobs. Live jobs gebruiken de omgeving `qa-live-shared`, en Telegram/Discord gebruiken Convex-leases.
- De workflow `QA-Lab - All Lanes` draait elke nacht op `main` en bij handmatige dispatch; deze waaiert uit naar de mock-parity-lane, live Matrix-lane en live Telegram- en Discord-lanes als parallelle jobs. Live-jobs gebruiken de omgeving `qa-live-shared`, en Telegram/Discord gebruiken Convex-leases.
Releasechecks draaien Matrix- en Telegram-live-transportlanes met de deterministische mockprovider en mock-gekwalificeerde modellen (`mock-openai/gpt-5.5` en `mock-openai/gpt-5.5-alt`), zodat het kanaalcontract is geïsoleerd van live-modellatentie en normale provider-Plugin-startup. De live-transport-Gateway schakelt memory search uit omdat QA-parity memory-gedrag afzonderlijk dekt; providerconnectiviteit wordt gedekt door de afzonderlijke suites voor live model, native provider en Docker-provider.
Releasechecks draaien Matrix- en Telegram-live-transportlanes met de deterministische mockprovider en mock-gekwalificeerde modellen (`mock-openai/gpt-5.5` en `mock-openai/gpt-5.5-alt`), zodat het kanaalcontract geïsoleerd is van live-modellatentie en normale provider-plugin-startup. De live-transport-Gateway schakelt memory search uit omdat QA-parity geheugengedrag afzonderlijk dekt; providerconnectiviteit wordt gedekt door de afzonderlijke live-model-, native-provider- en Docker-provider-suites.
Matrix gebruikt `--profile fast` voor geplande en releasegates, en voegt `--fail-fast` alleen toe wanneer de uitgecheckte CLI dit ondersteunt. De CLI-standaard en de handmatige workflowinput blijven `all`; handmatige `matrix_profile=all`-dispatch shardt volledige Matrix-dekking altijd in `transport`-, `media`-, `e2ee-smoke`-, `e2ee-deep`- en `e2ee-cli`-jobs.
Matrix gebruikt `--profile fast` voor geplande en release-gates, en voegt `--fail-fast` alleen toe wanneer de uitgecheckte CLI dit ondersteunt. De CLI-standaard en handmatige workflow-input blijven `all`; handmatige `matrix_profile=all`-dispatch shardt volledige Matrix-dekking altijd in `transport`-, `media`-, `e2ee-smoke`-, `e2ee-deep`- en `e2ee-cli`-jobs.
`OpenClaw Release Checks` draait ook de releasekritieke QA Lab-lanes vóór releasegoedkeuring; de QA-parity-gate daarvan draait de kandidaat- en baseline-pakketten als parallelle lanejobs, en downloadt daarna beide artifacts in een kleine rapportjob voor de definitieve parity-vergelijking.
`OpenClaw Release Checks` draait ook de releasekritieke QA Lab-lanes vóór releasegoedkeuring; de QA-parity-gate draait de kandidaat- en baseline-packs als parallelle lane-jobs, en downloadt daarna beide artefacten in een kleine rapportjob voor de uiteindelijke parityvergelijking.
Volg voor normale PR's scoped CI-/checkbewijs in plaats van parity als vereiste status te behandelen.
Volg voor normale PR's scoped CI-/check-bewijs in plaats van parity als verplichte status te behandelen.
## CodeQL
De `CodeQL`-workflow is bewust een smalle beveiligingsscanner voor een eerste controle, niet de volledige repositorydoorlichting. Dagelijkse, handmatige en niet-concept pull request-guard-runs scannen Actions-workflowcode plus de JavaScript/TypeScript-oppervlakken met het hoogste risico, met beveiligingsquery's met hoge betrouwbaarheid die zijn gefilterd op hoge/kritieke `security-severity`.
De `CodeQL`-workflow is bewust een smalle securityscanner voor de eerste pass, niet de volledige repository-sweep. Dagelijkse, handmatige en niet-concept pull request guard-runs scannen Actions-workflowcode plus de JavaScript/TypeScript-oppervlakken met het hoogste risico met high-confidence security-query's, gefilterd op hoge/kritieke `security-severity`.
De pull request-guard blijft licht: die start alleen voor wijzigingen onder `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` of `src`, en voert dezelfde beveiligingsmatrix met hoge betrouwbaarheid uit als de geplande workflow. Android en macOS CodeQL blijven buiten de standaardinstellingen voor PR's.
De pull request guard blijft licht: hij start alleen voor wijzigingen onder `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` of `src`, en voert dezelfde high-confidence security-matrix uit als de geplande workflow. Android- en macOS-CodeQL blijven buiten de standaardinstellingen voor PR's.
### Beveiligingscategorieën
### Securitycategorieën
| Categorie | Oppervlak |
| Categorie | Oppervlak |
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `/codeql-security-high/core-auth-secrets` | Auth, geheimen, sandbox, cron en gateway-baseline |
| `/codeql-security-high/channel-runtime-boundary` | Kerncontracten voor kanaalimplementatie plus de kanaal-Plugin-runtime, Gateway, Plugin SDK, geheimen en audit-aanraakpunten |
| `/codeql-security-high/network-ssrf-boundary` | Kernoppervlakken voor SSRF, IP-parsing, netwerkguard, web-fetch en Plugin SDK SSRF-beleid |
| `/codeql-security-high/mcp-process-tool-boundary` | MCP-servers, helpers voor procesuitvoering, uitgaande levering en agent-gates voor tooluitvoering |
| `/codeql-security-high/plugin-trust-boundary` | Vertrouwensoppervlakken voor Plugin-installatie, loader, manifest, register, package-manager-installatie, bronladen en Plugin SDK-packagecontract |
| `/codeql-security-high/core-auth-secrets` | Auth, secrets, sandbox, cron en Gateway-baseline |
| `/codeql-security-high/channel-runtime-boundary` | Core channel-implementatiecontracten plus de channel Plugin-runtime, Gateway, Plugin SDK, secrets en audit-touchpoints |
| `/codeql-security-high/network-ssrf-boundary` | Core SSRF, IP-parsing, network guard, web-fetch en Plugin SDK SSRF-beleidsoppervlakken |
| `/codeql-security-high/mcp-process-tool-boundary` | MCP-servers, procesuitvoeringshelpers, outbound delivery en agent tool-execution gates |
| `/codeql-security-high/plugin-trust-boundary` | Plugin-installatie, loader, manifest, registry, package-manager-installatie, source-loading en trust-oppervlakken van het Plugin SDK-packagecontract |
### Platformspecifieke beveiligingsshards
### Platformspecifieke security-shards
- `CodeQL Android Critical Security` — geplande Android-beveiligingsshard. Bouwt de Android-app handmatig voor CodeQL op de kleinste Blacksmith Linux-runner die door workflowsanity wordt geaccepteerd. Uploadt onder `/codeql-critical-security/android`.
- `CodeQL macOS Critical Security` — wekelijkse/handmatige macOS-beveiligingsshard. Bouwt de macOS-app handmatig voor CodeQL op Blacksmith macOS, filtert dependency-buildresultaten uit de geüploade SARIF en uploadt onder `/codeql-critical-security/macos`. Buiten de dagelijkse standaardinstellingen gehouden omdat de macOS-build de runtime domineert, zelfs wanneer die schoon is.
- `CodeQL Android Critical Security` — geplande Android-security-shard. Bouwt de Android-app handmatig voor CodeQL op de kleinste Blacksmith Linux-runner die door workflow sanity wordt geaccepteerd. Uploadt onder `/codeql-critical-security/android`.
- `CodeQL macOS Critical Security` — wekelijkse/handmatige macOS-security-shard. Bouwt de macOS-app handmatig voor CodeQL op Blacksmith macOS, filtert dependency-buildresultaten uit de geüploade SARIF en uploadt onder `/codeql-critical-security/macos`. Blijft buiten de dagelijkse standaardinstellingen omdat de macOS-build de runtime domineert, zelfs wanneer hij schoon is.
### Critical Quality-categorieën
`CodeQL Critical Quality` is de bijbehorende niet-beveiligingsshard. Die voert alleen JavaScript/TypeScript-kwaliteitsquery's met error-severity en zonder beveiligingsscope uit over smalle, hoogwaardige oppervlakken op de kleinere Blacksmith Linux-runner. De pull request-guard is bewust kleiner dan het geplande profiel: niet-concept PR's voeren alleen de bijbehorende `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` en `plugin-sdk-reply-runtime`-shards uit voor agent-command/model/tool-uitvoering en reply-dispatchcode, config-schema/migratie/IO-code, auth/geheimen/sandbox/beveiligingscode, kernkanaal en meegeleverde kanaal-Plugin-runtime, Gateway-protocol/servermethode, memory-runtime/SDK-lijm, MCP/proces/uitgaande levering, provider-runtime/modelcatalogus, sessiediagnostiek/leveringswachtrijen, Plugin-loader, Plugin SDK/packagecontract of wijzigingen aan de Plugin SDK reply-runtime. Wijzigingen aan CodeQL-config en kwaliteitsworkflows voeren alle twaalf PR-kwaliteitsshards uit.
`CodeQL Critical Quality` is de overeenkomende niet-security-shard. Deze voert alleen error-severity, niet-security JavaScript/TypeScript-quality-query's uit over smalle, hoogwaardige oppervlakken op de kleinere Blacksmith Linux-runner. De pull request guard is bewust kleiner dan het geplande profiel: niet-concept PR's voeren alleen de overeenkomende `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` en `plugin-sdk-reply-runtime` shards uit voor agent command/model/tool-uitvoering en reply-dispatchcode, config schema/migration/IO-code, auth/secrets/sandbox/security-code, core channel en gebundelde channel Plugin-runtime, Gateway protocol/server-method, memory runtime/SDK-glue, MCP/process/outbound delivery, provider runtime/model catalog, session diagnostics/delivery queues, Plugin-loader, Plugin SDK/package-contract of Plugin SDK reply runtime-wijzigingen. CodeQL-configuratie- en quality-workflowwijzigingen voeren alle twaalf PR-quality-shards uit.
Handmatige dispatch accepteert:
@ -433,40 +433,40 @@ Handmatige dispatch accepteert:
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
```
De smalle profielen zijn onderwijs-/iteratiehooks om één kwaliteitsshard geïsoleerd uit te voeren.
De smalle profielen zijn onderwijs-/iteratiehooks voor het geïsoleerd uitvoeren van één quality-shard.
| Categorie | Oppervlak |
| Categorie | Oppervlak |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `/codeql-critical-quality/core-auth-secrets` | Grenscode voor auth, geheimen, sandbox, cron en Gateway-beveiliging |
| `/codeql-critical-quality/config-boundary` | Contracten voor config-schema, migratie, normalisatie en IO |
| `/codeql-critical-quality/gateway-runtime-boundary` | Gateway-protocolschema's en servermethodecontracten |
| `/codeql-critical-quality/channel-runtime-boundary` | Implementatiecontracten voor kernkanaal en meegeleverde kanaal-Plugin |
| `/codeql-critical-quality/agent-runtime-boundary` | Runtimecontracten voor command-uitvoering, model/provider-dispatch, auto-reply-dispatch en wachtrijen, en ACP-control plane |
| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-servers en toolbridges, helpers voor procestoezicht en contracten voor uitgaande levering |
| `/codeql-critical-quality/memory-runtime-boundary` | Memory host SDK, memory-runtimefacades, memory Plugin SDK-aliassen, lijm voor memory-runtimeactivatie en memory doctor-commands |
| `/codeql-critical-quality/session-diagnostics-boundary` | Internals van reply-wachtrijen, sessieleveringswachtrijen, helpers voor uitgaande sessiebinding/levering, oppervlakken voor diagnostische events/logbundels en session doctor CLI-contracten |
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Plugin SDK-dispatch van inkomende replies, reply-payload/chunking/runtime-helpers, kanaal-replyopties, leveringswachtrijen en helpers voor sessie-/threadbinding |
| `/codeql-critical-quality/provider-runtime-boundary` | Normalisatie van modelcatalogus, provider-auth en discovery, provider-runtime-registratie, provider-standaardwaarden/catalogi en web/search/fetch/embedding-registers |
| `/codeql-critical-quality/ui-control-plane` | Control UI-bootstrap, lokale persistentie, Gateway-controlflows en runtimecontracten voor task control plane |
| `/codeql-critical-quality/web-media-runtime-boundary` | Runtimecontracten voor core web fetch/search, media-IO, media understanding, image-generation en media-generation |
| `/codeql-critical-quality/plugin-boundary` | Loader-, register-, public-surface- en Plugin SDK-entrypointcontracten |
| `/codeql-critical-quality/plugin-sdk-package-contract` | Gepubliceerde package-side Plugin SDK-bron en helpers voor Plugin-packagecontracten |
| `/codeql-critical-quality/core-auth-secrets` | Auth, secrets, sandbox, cron en Gateway-security-boundarycode |
| `/codeql-critical-quality/config-boundary` | Config-schema, migratie, normalisatie en IO-contracten |
| `/codeql-critical-quality/gateway-runtime-boundary` | Gateway-protocolschema's en server-method-contracten |
| `/codeql-critical-quality/channel-runtime-boundary` | Core channel- en gebundelde channel Plugin-implementatiecontracten |
| `/codeql-critical-quality/agent-runtime-boundary` | Command-uitvoering, model/provider-dispatch, auto-reply-dispatch en queues, en ACP control-plane-runtimecontracten |
| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-servers en tool-bridges, process supervision-helpers en outbound delivery-contracten |
| `/codeql-critical-quality/memory-runtime-boundary` | Memory host SDK, memory runtime-facades, memory Plugin SDK-aliassen, memory runtime activation-glue en memory doctor-commando's |
| `/codeql-critical-quality/session-diagnostics-boundary` | Reply queue-internals, session delivery queues, outbound session binding/delivery-helpers, diagnostic event/log bundle-oppervlakken en session doctor CLI-contracten |
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Plugin SDK inbound reply-dispatch, reply payload/chunking/runtime-helpers, channel reply options, delivery queues en session/thread binding-helpers |
| `/codeql-critical-quality/provider-runtime-boundary` | Model catalog-normalisatie, provider-auth en discovery, provider runtime-registratie, provider defaults/catalogs en web/search/fetch/embedding-registries |
| `/codeql-critical-quality/ui-control-plane` | Control UI-bootstrap, lokale persistentie, Gateway-control flows en task control-plane-runtimecontracten |
| `/codeql-critical-quality/web-media-runtime-boundary` | Core web fetch/search, media-IO, media understanding, image-generation en media-generation-runtimecontracten |
| `/codeql-critical-quality/plugin-boundary` | Loader-, registry-, public-surface- en Plugin SDK-entrypointcontracten |
| `/codeql-critical-quality/plugin-sdk-package-contract` | Gepubliceerde package-side Plugin SDK-bron en helperfuncties voor plugin package-contracten |
Kwaliteit blijft gescheiden van beveiliging, zodat kwaliteitsbevindingen kunnen worden gepland, gemeten, uitgeschakeld of uitgebreid zonder het beveiligingssignaal te vertroebelen. Uitbreiding van Swift-, Python- en meegeleverde-Plugin-CodeQL moet alleen als afgebakend of geshard vervolgwerk worden teruggevoegd nadat de smalle profielen stabiele runtime en stabiel signaal hebben.
Quality blijft gescheiden van security zodat quality-bevindingen kunnen worden gepland, gemeten, uitgeschakeld of uitgebreid zonder het security-signaal te vertroebelen. Uitbreiding van Swift-, Python- en gebundelde-plugin-CodeQL moet alleen als gescopeerd of geshard vervolgwerk worden teruggezet nadat de smalle profielen een stabiele runtime en stabiel signaal hebben.
## Onderhoudsworkflows
### Docs Agent
De `Docs Agent`-workflow is een event-gedreven Codex-onderhoudslane om bestaande docs afgestemd te houden op recent gelande wijzigingen. Die heeft geen zuivere planning: een succesvolle niet-bot push-CI-run op `main` kan hem triggeren, en handmatige dispatch kan hem rechtstreeks uitvoeren. Workflow-run-aanroepen worden overgeslagen wanneer `main` verder is gegaan of wanneer er in het afgelopen uur een andere niet-overgeslagen Docs Agent-run is aangemaakt. Wanneer die wordt uitgevoerd, bekijkt hij het commitbereik van de vorige niet-overgeslagen Docs Agent-bron-SHA tot de huidige `main`, zodat één uurlijkse run alle main-wijzigingen kan dekken die sinds de laatste docs-pass zijn verzameld.
De `Docs Agent`-workflow is een eventgedreven Codex-onderhoudslane om bestaande documentatie afgestemd te houden op recent gelande wijzigingen. Hij heeft geen zuiver schema: een succesvolle niet-bot push CI-run op `main` kan hem triggeren, en handmatige dispatch kan hem rechtstreeks uitvoeren. Workflow-run-aanroepen slaan over wanneer `main` is doorgeschoven of wanneer er in het afgelopen uur een andere niet-overgeslagen Docs Agent-run is aangemaakt. Wanneer hij draait, beoordeelt hij de commitrange vanaf de vorige niet-overgeslagen Docs Agent-bron-SHA tot de huidige `main`, zodat één uurlijkse run alle main-wijzigingen kan dekken die sinds de laatste documentatiepass zijn verzameld.
### Test Performance Agent
De `Test Performance Agent`-workflow is een event-gedreven Codex-onderhoudslane voor trage tests. Die heeft geen zuivere planning: een succesvolle niet-bot push-CI-run op `main` kan hem triggeren, maar hij wordt overgeslagen als er die UTC-dag al een andere workflow-run-aanroep is uitgevoerd of draait. Handmatige dispatch omzeilt die dagelijkse activiteitsgate. De lane bouwt een gegroepeerd Vitest-prestatierapport voor de volledige suite, laat Codex alleen kleine testprestatieverbeteringen maken die coverage behouden in plaats van brede refactors, voert daarna het rapport voor de volledige suite opnieuw uit en weigert wijzigingen die het aantal passerende baselinetests verminderen. Als de baseline falende tests heeft, mag Codex alleen duidelijke failures fixen en moet het full-suite-rapport na de agent slagen voordat er iets wordt gecommit. Wanneer `main` verdergaat voordat de bot-push landt, rebaset de lane de gevalideerde patch, voert `pnpm check:changed` opnieuw uit en probeert de push opnieuw; conflicterende verouderde patches worden overgeslagen. De workflow gebruikt GitHub-hosted Ubuntu zodat de Codex-action dezelfde drop-sudo-veiligheidshouding kan behouden als de docs-agent.
De `Test Performance Agent`-workflow is een eventgedreven Codex-onderhoudslane voor trage tests. Hij heeft geen zuiver schema: een succesvolle niet-bot push CI-run op `main` kan hem triggeren, maar hij slaat over als er die UTC-dag al een andere workflow-run-aanroep is uitgevoerd of draait. Handmatige dispatch omzeilt die dagelijkse activiteitsgate. De lane bouwt een gegroepeerd Vitest-performancerapport voor de volledige suite, laat Codex alleen kleine testprestatieverbeteringen maken die coverage behouden in plaats van brede refactors, voert daarna het full-suite-rapport opnieuw uit en wijst wijzigingen af die het aantal geslaagde baselinetests verminderen. Als de baseline falende tests heeft, mag Codex alleen evidente failures oplossen en moet het full-suite-rapport na de agent slagen voordat er iets wordt gecommit. Wanneer `main` doorgaat voordat de bot-push landt, rebased de lane de gevalideerde patch, voert `pnpm check:changed` opnieuw uit en probeert de push opnieuw; conflicterende stale patches worden overgeslagen. Hij gebruikt GitHub-hosted Ubuntu zodat de Codex-action dezelfde drop-sudo-safety-posture kan houden als de docs agent.
### Duplicate PRs After Merge
De `Duplicate PRs After Merge`-workflow is een handmatige maintainer-workflow voor duplicate-opruiming na landing. Standaard is die dry-run en sluit hij alleen expliciet vermelde PR's wanneer `apply=true`. Voordat GitHub wordt gewijzigd, controleert hij of de gelande PR is gemerged en of elke duplicate een gedeeld gerefereerd issue of overlappende gewijzigde hunks heeft.
De `Duplicate PRs After Merge`-workflow is een handmatige maintainer-workflow voor duplicate cleanup na landing. Standaard is dit dry-run en worden alleen expliciet vermelde PR's gesloten wanneer `apply=true`. Voordat GitHub wordt gewijzigd, verifieert hij dat de gelande PR is gemerged en dat elke duplicate ofwel een gedeeld gerefereerd issue heeft, of overlappende gewijzigde hunks.
```bash
gh workflow run duplicate-after-merge.yml \
@ -475,29 +475,29 @@ gh workflow run duplicate-after-merge.yml \
-f apply=true
```
## Lokale check-gates en changed-routing
## Lokale check gates en changed routing
Lokale changed-lane-logica staat in `scripts/changed-lanes.mjs` en wordt uitgevoerd door `scripts/check-changed.mjs`. Die lokale check-gate is strenger over architectuurgrenzen dan de brede CI-platformscope:
Lokale changed-lane-logica leeft in `scripts/changed-lanes.mjs` en wordt uitgevoerd door `scripts/check-changed.mjs`. Die lokale check gate is strikter over architectuurgrenzen dan de brede CI-platformscope:
- core-productiewijzigingen voeren core prod- en core test-typecheck plus core lint/guards uit;
- wijzigingen die alleen core-tests raken voeren alleen core test-typecheck plus core lint uit;
- extension-productiewijzigingen voeren extension prod- en extension test-typecheck plus extension lint uit;
- wijzigingen die alleen extension-tests raken voeren extension test-typecheck plus extension lint uit;
- wijzigingen aan publieke Plugin SDK- of Plugin-contracten breiden uit naar extension-typecheck omdat extensions afhankelijk zijn van die core-contracten (Vitest extension-sweeps blijven expliciet testwerk);
- version bumps die alleen releasemetadata raken voeren gerichte versie-/config-/root-dependency-checks uit;
- onbekende root-/configwijzigingen vallen veilig terug op alle check-lanes.
- wijzigingen alleen aan core-tests voeren alleen core test-typecheck plus core lint uit;
- extensieproductiewijzigingen voeren extension prod- en extension test-typecheck plus extension lint uit;
- wijzigingen alleen aan extensietests voeren extension test-typecheck plus extension lint uit;
- publieke Plugin SDK- of plugin-contractwijzigingen breiden uit naar extension typecheck omdat extensies afhankelijk zijn van die core-contracten (Vitest extension-sweeps blijven expliciet testwerk);
- release metadata-only version bumps voeren gerichte versie-/config-/root-dependency-checks uit;
- onbekende root/config-wijzigingen failen veilig naar alle check lanes.
Lokale changed-test-routing staat in `scripts/test-projects.test-support.mjs` en is bewust goedkoper dan `check:changed`: directe testbewerkingen voeren zichzelf uit, bronbewerkingen geven de voorkeur aan expliciete mappings, daarna sibling-tests en import-graph-afhankelijken. Gedeelde delivery-config voor groepsruimtes is een van de expliciete mappings: wijzigingen aan de groep zichtbare-reply-config, bron-reply-leveringsmodus of de message-tool system prompt lopen via de core reply-tests plus Discord- en Slack-delivery-regressions, zodat een gedeelde standaardwijziging faalt vóór de eerste PR-push. Gebruik `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` alleen wanneer de wijziging zo harness-breed is dat de goedkope gemapte set geen betrouwbare proxy is.
Lokale changed-test-routing leeft in `scripts/test-projects.test-support.mjs` en is bewust goedkoper dan `check:changed`: directe testwijzigingen voeren zichzelf uit, bronwijzigingen geven de voorkeur aan expliciete mappings, daarna sibling-tests en import-graph dependents. Gedeelde group-room delivery-config is een van de expliciete mappings: wijzigingen aan de group visible-reply config, source reply delivery mode of de message-tool system prompt lopen via de core reply-tests plus Discord- en Slack-delivery-regressies, zodat een gedeelde standaardwijziging faalt vóór de eerste PR-push. Gebruik `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` alleen wanneer de wijziging zo harness-breed is dat de goedkope gemapte set geen betrouwbare proxy is.
## Testbox-validatie
Voer Testbox uit vanaf de repo-root en geef voor brede verificatie de voorkeur aan een nieuwe voorverwarmde box. Voordat je een trage gate besteedt aan een box die is hergebruikt, verlopen is, of net een onverwacht grote synchronisatie meldde, voer je eerst `pnpm testbox:sanity` uit in de box.
Voer Testbox uit vanuit de repo-root en geef voor brede verificatie de voorkeur aan een vers opgewarmde box. Voordat je een trage gate uitvoert op een box die is hergebruikt, verlopen is of zojuist een onverwacht grote synchronisatie meldde, voer je eerst `pnpm testbox:sanity` uit in de box.
De sanitycontrole faalt snel wanneer vereiste rootbestanden zoals `pnpm-lock.yaml` verdwenen zijn of wanneer `git status --short` minstens 200 bijgehouden verwijderingen toont. Dat betekent meestal dat de externe synchronisatiestatus geen betrouwbare kopie van de PR is; stop die box en warm een nieuwe op in plaats van de producttestfout te debuggen. Voor opzettelijke PR's met veel verwijderingen stel je `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` in voor die sanityrun.
De sanity check faalt snel wanneer vereiste rootbestanden zoals `pnpm-lock.yaml` zijn verdwenen of wanneer `git status --short` minstens 200 gevolgde verwijderingen toont. Dat betekent meestal dat de remote synchronisatiestatus geen betrouwbare kopie van de PR is; stop die box en warm in plaats van de producttestfout te debuggen een verse op. Voor PR's met bewust grote verwijderingen stel je `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` in voor die sanity-run.
`pnpm testbox:run` beëindigt ook een lokale Blacksmith CLI-aanroep die langer dan vijf minuten in de synchronisatiefase blijft zonder output na synchronisatie. Stel `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` in om die guard uit te schakelen, of gebruik een grotere millisecondenwaarde voor ongewoon grote lokale diffs.
`pnpm testbox:run` beëindigt ook een lokale Blacksmith CLI-aanroep die langer dan vijf minuten in de synchronisatiefase blijft zonder uitvoer na de synchronisatie. Stel `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` in om die bescherming uit te schakelen, of gebruik een grotere millisecondewaarde voor ongebruikelijk grote lokale diffs.
Crabbox is het tweede door de repo beheerde remote-box-pad voor Linux-verificatie wanneer Blacksmith niet beschikbaar is of wanneer eigen cloudcapaciteit de voorkeur heeft. Warm een box op, hydrateer deze via de projectworkflow en voer vervolgens opdrachten uit via de Crabbox CLI:
Crabbox is het tweede door de repo beheerde remote-boxpad voor Linux-verificatie wanneer Blacksmith niet beschikbaar is of wanneer eigen cloudcapaciteit de voorkeur heeft. Warm een box op, hydrateer die via de projectworkflow en voer daarna commando's uit via de Crabbox CLI:
```bash
pnpm crabbox:warmup -- --idle-timeout 90m
@ -506,9 +506,9 @@ pnpm crabbox:run -- --id <cbx_id> --shell "OPENCLAW_TESTBOX=1 pnpm check:changed
pnpm crabbox:stop -- <cbx_id>
```
`.crabbox.yaml` beheert de standaardwaarden voor provider, synchronisatie en GitHub Actions-hydratatie. Het sluit lokale `.git` uit zodat de gehydrateerde Actions-checkout zijn eigen externe Git-metadata behoudt in plaats van maintainer-lokale remotes en objectstores te synchroniseren, en het sluit lokale runtime-/buildartefacten uit die nooit mogen worden overgedragen. `.github/workflows/crabbox-hydrate.yml` beheert checkout, Node/pnpm-installatie, het ophalen van `origin/main` en de niet-geheime omgevingshandoff die latere `crabbox run --id <cbx_id>`-opdrachten sourcen.
`.crabbox.yaml` beheert de standaardinstellingen voor provider, synchronisatie en GitHub Actions-hydratatie. Het sluit lokale `.git` uit zodat de gehydrateerde Actions-checkout zijn eigen remote Git-metadata behoudt in plaats van maintainer-lokale remotes en object stores te synchroniseren, en het sluit lokale runtime-/buildartefacten uit die nooit mogen worden overgedragen. `.github/workflows/crabbox-hydrate.yml` beheert checkout, Node/pnpm-installatie, `origin/main` ophalen, en de niet-geheime omgevingshandoff die latere `crabbox run --id <cbx_id>`-commando's gebruiken als bron.
## Gerelateerd
- [Installatieoverzicht](/nl/install)
- [Ontwikkelingskanalen](/nl/install/development-channels)
- [Ontwikkelkanalen](/nl/install/development-channels)

236
docs/nl/concepts/system-prompt.md
View File

@ -1,107 +1,152 @@
---
read_when:
- Tekst van de systeemprompt, lijst met tools of tijd-/Heartbeat-secties bewerken
- Opstartinitialisatie van de werkruimte of injectiegedrag voor Skills wijzigen
summary: Wat de systeemprompt van OpenClaw bevat en hoe deze wordt samengesteld
- Systeemprompttekst, toolslijst of tijd-/Heartbeat-secties bewerken
- Gedrag voor werkruimtebootstrap of Skills-injectie wijzigen
summary: Wat de OpenClaw-systeemprompt bevat en hoe deze wordt samengesteld
title: Systeemprompt
x-i18n:
generated_at: "2026-05-02T22:18:06Z"
generated_at: "2026-05-02T23:39:08Z"
model: gpt-5.5
provider: openai
source_hash: 3b8761a8722bb328b937e0832774be7b4e99602ae032c9a255f26843237c110c
source_hash: f8e0234453812c16cf5d273096d335049bf435ca76ade36200caf4bb344624e5
source_path: concepts/system-prompt.md
workflow: 16
---
OpenClaw bouwt een aangepaste systeemprompt voor elke agent-run. De prompt is **eigendom van OpenClaw** en gebruikt niet de standaardprompt van pi-coding-agent.
OpenClaw bouwt een aangepaste systeemprompt voor elke agentuitvoering. De prompt is **eigendom van OpenClaw** en gebruikt niet de standaardprompt van pi-coding-agent.
De prompt wordt samengesteld door OpenClaw en in elke agent-run geinjecteerd.
De prompt wordt door OpenClaw samengesteld en in elke agentuitvoering geïnjecteerd.
Providerplugins kunnen cachebewuste promptbegeleiding bijdragen zonder de volledige prompt die eigendom is van OpenClaw te vervangen. De provider-runtime kan:
Providerplugins kunnen cachebewuste promptrichtlijnen bijdragen zonder de volledige
prompt die eigendom is van OpenClaw te vervangen. De providerruntime kan:
- een kleine set benoemde kernsecties vervangen (`interaction_style`,
`tool_call_style`, `execution_bias`)
- een **stabiele prefix** boven de prompt-cachegrens injecteren
- een **dynamische suffix** onder de prompt-cachegrens injecteren
- een **stabiel voorvoegsel** boven de promptcachegrens injecteren
- een **dynamisch achtervoegsel** onder de promptcachegrens injecteren
Gebruik provider-eigen bijdragen voor model-familiespecifieke afstemming. Bewaar legacy
`before_prompt_build`-promptmutatie voor compatibiliteit of werkelijk globale promptwijzigingen, niet voor normaal providergedrag.
Gebruik bijdragen die eigendom zijn van de provider voor modelspecifieke afstemming per modelfamilie. Bewaar legacy
`before_prompt_build`-promptmutatie voor compatibiliteit of echt globale promptwijzigingen,
niet voor normaal providergedrag.
De OpenAI GPT-5-familie-overlay houdt de kernuitvoeringsregel klein en voegt modelspecifieke begeleiding toe voor persona-latching, beknopte uitvoer, tooldiscipline, parallelle opzoeking, dekking van deliverables, verificatie, ontbrekende context en hygiene voor terminaltools.
De overlay voor de OpenAI GPT-5-familie houdt de kernuitvoeringsregel klein en voegt
modelspecifieke richtlijnen toe voor persona-vastlegging, beknopte uitvoer, tooldiscipline,
parallel opzoeken, dekking van deliverables, verificatie, ontbrekende context en
terminaltoolhygiëne.
## Structuur
De prompt is bewust compact en gebruikt vaste secties:
- **Tooling**: herinnering aan de bron van waarheid voor gestructureerde tools plus runtimebegeleiding voor toolgebruik.
- **Uitvoeringsbias**: compacte follow-throughbegeleiding: handel binnen de beurt op
uitvoerbare verzoeken, ga door tot het klaar is of geblokkeerd raakt, herstel van zwakke toolresultaten, controleer veranderlijke status live en verifieer voordat je afrondt.
- **Veiligheid**: korte guardrailherinnering om machtszoekend gedrag of het omzeilen van toezicht te vermijden.
- **Skills** (wanneer beschikbaar): vertelt het model hoe het skill-instructies op aanvraag laadt.
- **OpenClaw Self-Update**: hoe je configuratie veilig inspecteert met
`config.schema.lookup`, configuratie patcht met `config.patch`, de volledige
configuratie vervangt met `config.apply`, en `update.run` alleen uitvoert op expliciet gebruikersverzoek. De owner-only `gateway`-tool weigert ook
`tools.exec.ask` / `tools.exec.security` te herschrijven, inclusief legacy `tools.bash.*`-aliassen die normaliseren naar die beschermde exec-paden.
- **Workspace**: werkdirectory (`agents.defaults.workspace`).
- **Documentatie**: lokaal pad naar OpenClaw-documentatie (repo of npm-pakket) en wanneer die moet worden gelezen.
- **Workspacebestanden (geinjecteerd)**: geeft aan dat bootstrapbestanden hieronder zijn opgenomen.
- **Sandbox** (wanneer ingeschakeld): geeft sandboxed runtime, sandboxpaden en of verhoogde exec beschikbaar is aan.
- **Huidige datum en tijd**: lokale tijd van de gebruiker, tijdzone en tijdnotatie.
- **Tooling**: herinnering aan gestructureerde tools als bron van waarheid plus runtime-richtlijnen voor toolgebruik.
- **Uitvoeringsbias**: compacte richtlijnen voor opvolging: handel binnen de beurt bij
uitvoerbare verzoeken, ga door tot het klaar is of geblokkeerd raakt, herstel van zwakke
toolresultaten, controleer veranderlijke status live en verifieer voor afronding.
- **Veiligheid**: korte guardrail-herinnering om machtszoekend gedrag of het omzeilen van toezicht te vermijden.
- **Skills** (indien beschikbaar): vertelt het model hoe het skill-instructies op aanvraag kan laden.
- **OpenClaw-zelfupdate**: hoe configuratie veilig te inspecteren met
`config.schema.lookup`, configuratie te patchen met `config.patch`, de volledige
configuratie te vervangen met `config.apply`, en `update.run` alleen uit te voeren op expliciet gebruikersverzoek. De alleen-voor-eigenaren `gateway`-tool weigert ook
`tools.exec.ask` / `tools.exec.security` te herschrijven, inclusief legacy `tools.bash.*`-
aliassen die naar die beschermde exec-paden normaliseren.
- **Werkruimte**: werkdirectory (`agents.defaults.workspace`).
- **Documentatie**: lokaal pad naar OpenClaw-documentatie (repo of npm-pakket) en wanneer deze gelezen moet worden.
- **Werkruimtebestanden (geïnjecteerd)**: geeft aan dat bootstrapbestanden hieronder zijn opgenomen.
- **Sandbox** (indien ingeschakeld): geeft sandboxruntime, sandboxpaden en of verhoogde exec beschikbaar is aan.
- **Huidige datum en tijd**: lokale gebruikerstijd, tijdzone en tijdnotatie.
- **Antwoordtags**: optionele syntaxis voor antwoordtags voor ondersteunde providers.
- **Heartbeats**: Heartbeat-prompt en ack-gedrag, wanneer Heartbeats zijn ingeschakeld voor de standaardagent.
- **Runtime**: host, OS, Node, model, repo-root (wanneer gedetecteerd), denkniveau (een regel).
- **Redenering**: huidig zichtbaarheidsniveau + hint voor de /reasoning-toggle.
- **Heartbeats**: heartbeatprompt en ack-gedrag, wanneer heartbeats zijn ingeschakeld voor de standaardagent.
- **Runtime**: host, OS, node, model, repo-root (indien gedetecteerd), denkniveau (één regel).
- **Redenering**: huidig zichtbaarheidsniveau + hint voor /reasoning-schakelaar.
OpenClaw houdt grote stabiele inhoud, inclusief **Projectcontext**, boven de interne prompt-cachegrens. Vluchtige kanaal-/sessiesecties zoals Control UI-insluitbegeleiding, **Berichten**, **Spraak**, **Groepschatcontext**, **Reacties**, **Heartbeats** en **Runtime** worden onder die grens toegevoegd, zodat lokale backends met prefixcaches de stabiele workspace-prefix opnieuw kunnen gebruiken over kanaalbeurten heen. Toolbeschrijvingen moeten eveneens vermijden om huidige kanaalnamen in te bedden wanneer het geaccepteerde schema dat runtimedetail al bevat.
OpenClaw houdt grote stabiele inhoud, inclusief **Projectcontext**, boven de
interne promptcachegrens. Vluchtige kanaal-/sessiesecties zoals
Control UI-inbeddingsrichtlijnen, **Berichten**, **Spraak**, **Groepschatcontext**,
**Reacties**, **Heartbeats** en **Runtime** worden onder die grens toegevoegd
zodat lokale backends met prefixcaches het stabiele werkruimtevoorvoegsel
tussen kanaalbeurten kunnen hergebruiken. Toolbeschrijvingen moeten ook vermijden om huidige
kanaalnamen in te bedden wanneer het geaccepteerde schema dat runtimedetail al bevat.
De Tooling-sectie bevat ook runtimebegeleiding voor langdurig werk:
De Tooling-sectie bevat ook runtime-richtlijnen voor langdurig werk:
- gebruik Cron voor toekomstige follow-up (`check back later`, herinneringen, terugkerend werk)
in plaats van `exec`-slaaplussen, `yieldMs`-vertragingstrucs of herhaalde `process`-polling
- gebruik `exec` / `process` alleen voor opdrachten die nu starten en op de achtergrond blijven draaien
- wanneer automatisch voltooien-wekken is ingeschakeld, start je de opdracht eenmaal en vertrouw je op het push-gebaseerde wekpad wanneer het uitvoer produceert of faalt
- gebruik `process` voor logs, status, invoer of interventie wanneer je een draaiende opdracht moet inspecteren
- als de taak groter is, geef dan de voorkeur aan `sessions_spawn`; voltooiing van subagenten is push-gebaseerd en wordt automatisch terug aangekondigd aan de verzoeker
- gebruik cron voor toekomstige opvolging (`check back later`, herinneringen, terugkerend werk)
in plaats van `exec`-slaaplussen, `yieldMs`-vertragingstrucs of herhaalde `process`-
polling
- gebruik `exec` / `process` alleen voor opdrachten die nu starten en op de achtergrond
blijven draaien
- wanneer automatisch voltooien-waken is ingeschakeld, start de opdracht eenmaal en vertrouw op
het pushgebaseerde wekpad wanneer het uitvoer produceert of faalt
- gebruik `process` voor logs, status, invoer of interventie wanneer je een draaiende opdracht
moet inspecteren
- als de taak groter is, geef de voorkeur aan `sessions_spawn`; voltooiing van subagenten is
pushgebaseerd en wordt automatisch terug aan de aanvrager aangekondigd
- poll `subagents list` / `sessions_list` niet in een lus alleen om op voltooiing te wachten
Wanneer de experimentele `update_plan`-tool is ingeschakeld, vertelt Tooling het model ook om die alleen te gebruiken voor niet-triviaal meerstapswerk, precies een `in_progress`-stap aan te houden en te voorkomen dat het volledige plan na elke update wordt herhaald.
Wanneer de experimentele `update_plan`-tool is ingeschakeld, vertelt Tooling het
model ook om deze alleen te gebruiken voor niet-triviaal meerstapswerk, precies één
`in_progress`-stap te behouden en te vermijden het volledige plan na elke update te herhalen.
Veiligheids-guardrails in de systeemprompt zijn adviserend. Ze sturen modelgedrag maar dwingen geen beleid af. Gebruik toolbeleid, exec-goedkeuringen, sandboxing en kanaal-allowlists voor harde handhaving; operators kunnen deze bewust uitschakelen.
Veiligheids-guardrails in de systeemprompt zijn adviserend. Ze sturen modelgedrag maar handhaven geen beleid. Gebruik toolbeleid, exec-goedkeuringen, sandboxing en kanaal-toelatingslijsten voor harde handhaving; operators kunnen deze bewust uitschakelen.
Op kanalen met native goedkeuringskaarten/-knoppen vertelt de runtimeprompt de agent nu eerst op die native goedkeurings-UI te vertrouwen. Die moet alleen een handmatige `/approve`-opdracht opnemen wanneer het toolresultaat zegt dat chatgoedkeuringen niet beschikbaar zijn of handmatige goedkeuring de enige route is.
Op kanalen met native goedkeuringskaarten/-knoppen vertelt de runtimeprompt de
agent nu eerst op die native goedkeurings-UI te vertrouwen. Deze moet alleen een handmatige
`/approve`-opdracht opnemen wanneer het toolresultaat zegt dat chatgoedkeuringen niet beschikbaar zijn of
handmatige goedkeuring de enige route is.
## Promptmodi
OpenClaw kan kleinere systeemprompts renderen voor subagenten. De runtime stelt een
`promptMode` in voor elke run (geen gebruikersgerichte configuratie):
`promptMode` in voor elke uitvoering (geen gebruikersgerichte configuratie):
- `full` (standaard): bevat alle bovenstaande secties.
- `minimal`: gebruikt voor subagenten; laat **Skills**, **Memory Recall**, **OpenClaw
Self-Update**, **Model Aliases**, **User Identity**, **Reply Tags**,
**Messaging**, **Silent Replies** en **Heartbeats** weg. Tooling, **Veiligheid**,
Workspace, Sandbox, Huidige datum en tijd (wanneer bekend), Runtime en geinjecteerde context blijven beschikbaar.
- `minimal`: gebruikt voor subagenten; laat **Skills**, **Geheugenherinnering**, **OpenClaw-
zelfupdate**, **Modelaliassen**, **Gebruikersidentiteit**, **Antwoordtags**,
**Berichten**, **Stille antwoorden** en **Heartbeats** weg. Tooling, **Veiligheid**,
Werkruimte, Sandbox, Huidige datum en tijd (indien bekend), Runtime en geïnjecteerde
context blijven beschikbaar.
- `none`: retourneert alleen de basisidentiteitsregel.
Wanneer `promptMode=minimal` is, worden extra geinjecteerde prompts gelabeld als **Subagentcontext** in plaats van **Groepschatcontext**.
Wanneer `promptMode=minimal` is, krijgen extra geïnjecteerde prompts het label **Subagent-
context** in plaats van **Groepschatcontext**.
Voor kanaal-auto-reply-runs kan OpenClaw de generieke sectie **Silent Replies** weglaten wanneer de directe/groepschatcontext het opgeloste gespreksspecifieke `NO_REPLY`-gedrag al bevat. Dit voorkomt dat tokenmechanica zowel in de globale systeemprompt als in de kanaalcontext wordt herhaald.
Voor kanaal-autoantwoorduitvoeringen kan OpenClaw de generieke sectie **Stille antwoorden**
weglaten wanneer de directe/groepschatcontext al het opgeloste
gespreksspecifieke `NO_REPLY`-gedrag bevat. Dit voorkomt herhaling van tokenmechanica
in zowel de globale systeemprompt als de kanaalcontext.
## Prompt-snapshots
## Promptsnapshots
OpenClaw bewaart gecommitte happy-path-prompt-snapshots voor de Codex/message-tool-runtime onder `test/fixtures/agents/prompt-snapshots/happy-path/`. Ze renderen geselecteerde app-server-thread-/turn-parameters plus een gereconstrueerde modelgebonden promptlaagstack voor Telegram direct, Discord-groep en Heartbeat-beurten. Die stack bevat een gepinde Codex `gpt-5.5`-modelpromptfixture die is gegenereerd uit de vorm van Codex' modelcatalogus/cache, de Codex happy-path permission developer-tekst, OpenClaw-developerinstructies, invoer van de gebruikersbeurt en verwijzingen naar de dynamische toolspecificaties.
OpenClaw bewaart gecommitte promptsnapshots voor het blije pad van de Codex-runtime onder
`test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/`. Ze renderen
geselecteerde app-server thread-/turn-parameters plus een gereconstrueerde modelgebonden prompt-
laagstapel voor Telegram-direct, Discord-groep en heartbeatbeurten. Die stapel
bevat een vastgezette Codex `gpt-5.5`-modelpromptfixture die is gegenereerd uit de vorm van Codex'
modelcatalogus/cache, de ontwikkelaarstekst voor Codex-happy-pathmachtigingen,
OpenClaw-ontwikkelaarsinstructies, gebruikersbeurtinvoer en verwijzingen naar de dynamische
toolspecificaties.
Ververs de gepinde Codex-modelpromptfixture met
`pnpm prompt:snapshots:sync-codex-model`. Standaard zoekt het script naar Codex' runtimecache op `$CODEX_HOME/models_cache.json`, daarna
`~/.codex/models_cache.json`, en valt pas daarna terug op de maintainer-Codex-checkoutconventie op `~/code/codex/codex-rs/models-manager/models.json`. Als geen van die bronnen bestaat, sluit de opdracht af zonder de gecommitte fixture te wijzigen. Geef `--catalog <path>` door om te verversen vanuit een specifiek `models_cache.json`- of `models.json`-bestand.
Ververs de vastgezette Codex-modelpromptfixture met
`pnpm prompt:snapshots:sync-codex-model`. Standaard zoekt het script naar
Codex' runtimecache op `$CODEX_HOME/models_cache.json`, daarna
`~/.codex/models_cache.json`, en valt pas daarna terug op de Codex-checkoutconventie voor maintainers
op `~/code/codex/codex-rs/models-manager/models.json`. Als geen van
die bronnen bestaat, sluit de opdracht af zonder de gecommitte fixture te wijzigen.
Geef `--catalog <path>` door om te verversen vanuit een specifiek `models_cache.json`-
of `models.json`-bestand.
Deze snapshots zijn nog steeds geen byte-voor-byte ruwe OpenAI-requestcapture. Codex kan runtime-eigen workspacecontext toevoegen, zoals `AGENTS.md`, omgevingscontext, herinneringen, app-/Plugin-instructies en toekomstige instructies voor samenwerkingsmodus binnen de Codex-runtime nadat OpenClaw thread- en turn-parameters verzendt.
Deze snapshots zijn nog steeds geen byte-voor-byte ruwe OpenAI-aanvraagcapture. Codex
kan runtime-eigen werkruimtecontext toevoegen, zoals `AGENTS.md`, omgevingscontext,
herinneringen, app-/Plugin-instructies en toekomstige instructies voor samenwerkingsmodus
binnen de Codex-runtime nadat OpenClaw thread- en turn-parameters heeft verzonden.
Genereer ze opnieuw met `pnpm prompt:snapshots:gen` en verifieer drift met
`pnpm prompt:snapshots:check`. CI voert de driftcheck uit in de aanvullende boundary-shard, zodat promptwijzigingen en snapshotupdates aan dezelfde PR gekoppeld blijven.
`pnpm prompt:snapshots:check`. CI voert de driftcontrole uit in de aanvullende
boundary-shard zodat promptwijzigingen en snapshotupdates aan dezelfde
PR gekoppeld blijven.
## Workspace-bootstrapinjectie
## Werkruimte-bootstrapinjectie
Bootstrapbestanden worden ingekort en toegevoegd onder **Projectcontext**, zodat het model identiteit en profielcontext ziet zonder expliciete leesacties nodig te hebben:
Bootstrapbestanden worden ingekort en toegevoegd onder **Projectcontext** zodat het model identiteit en profielcontext ziet zonder expliciete leesacties nodig te hebben:
- `AGENTS.md`
- `SOUL.md`
@ -109,36 +154,54 @@ Bootstrapbestanden worden ingekort en toegevoegd onder **Projectcontext**, zodat
- `IDENTITY.md`
- `USER.md`
- `HEARTBEAT.md`
- `BOOTSTRAP.md` (alleen op gloednieuwe workspaces)
- `MEMORY.md` wanneer aanwezig
- `BOOTSTRAP.md` (alleen op gloednieuwe werkruimten)
- `MEMORY.md` indien aanwezig
Al deze bestanden worden **in het contextvenster geinjecteerd** bij elke beurt, tenzij een bestandsspecifieke gate van toepassing is. `HEARTBEAT.md` wordt bij normale runs weggelaten wanneer Heartbeats zijn uitgeschakeld voor de standaardagent of
`agents.defaults.heartbeat.includeSystemPromptSection` false is. Houd geinjecteerde bestanden beknopt, vooral `MEMORY.md`, dat in de loop van de tijd kan groeien en kan leiden tot onverwacht hoog contextgebruik en frequentere Compaction.
Al deze bestanden worden **in het contextvenster geïnjecteerd** bij elke beurt, tenzij
een bestandsspecifieke gate van toepassing is. `HEARTBEAT.md` wordt weggelaten bij normale uitvoeringen wanneer
heartbeats zijn uitgeschakeld voor de standaardagent of
`agents.defaults.heartbeat.includeSystemPromptSection` false is. Houd geïnjecteerde
bestanden beknopt — vooral `MEMORY.md`, dat in de loop van de tijd kan groeien en kan leiden tot
onverwacht hoog contextgebruik en frequentere Compaction.
Wanneer een sessie op de native Codex-harness draait, laadt Codex `AGENTS.md`
via zijn eigen projectdocumentdetectie. OpenClaw lost nog steeds de overige
bootstrapbestanden op en stuurt ze door als Codex-configuratie-instructies, zodat `SOUL.md`,
`TOOLS.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md`, `BOOTSTRAP.md` en
`MEMORY.md` dezelfde werkruimtecontextrol behouden zonder
`AGENTS.md` te dupliceren.
<Note>
Dagelijkse bestanden in `memory/*.md` maken **geen** deel uit van de normale bootstrap Projectcontext. Bij gewone beurten worden ze op aanvraag benaderd via de tools `memory_search` en `memory_get`, zodat ze niet meetellen voor het contextvenster tenzij het model ze expliciet leest. Kale `/new`- en `/reset`-beurten zijn de uitzondering: de runtime kan recente dagelijkse herinnering voor die eerste beurt vooraf toevoegen als een eenmalig startup-contextblok.
Dagelijkse bestanden in `memory/*.md` maken **geen** deel uit van de normale bootstrap-Projectcontext. Bij gewone beurten worden ze op aanvraag benaderd via de tools `memory_search` en `memory_get`, zodat ze niet meetellen voor het contextvenster tenzij het model ze expliciet leest. Kale `/new`- en `/reset`-beurten vormen de uitzondering: de runtime kan recente dagelijkse herinnering vooraf toevoegen als een eenmalig startup-contextblok voor die eerste beurt.
</Note>
Grote bestanden worden afgekapt met een markering. De maximale grootte per bestand wordt beheerd door
`agents.defaults.bootstrapMaxChars` (standaard: 12000). De totale geinjecteerde bootstrapinhoud over bestanden heen is begrensd door `agents.defaults.bootstrapTotalMaxChars`
(standaard: 60000). Ontbrekende bestanden injecteren een korte markering voor ontbrekend bestand. Wanneer afkapping optreedt, kan OpenClaw een waarschuwingsblok in Projectcontext injecteren; beheer dit met
Grote bestanden worden afgekapt met een marker. De maximale grootte per bestand wordt bepaald door
`agents.defaults.bootstrapMaxChars` (standaard: 12000). De totale geïnjecteerde bootstrap-
inhoud over bestanden heen wordt begrensd door `agents.defaults.bootstrapTotalMaxChars`
(standaard: 60000). Ontbrekende bestanden injecteren een korte marker voor ontbrekend bestand. Wanneer afkapping
plaatsvindt, kan OpenClaw een waarschuwingsblok in Projectcontext injecteren; beheer dit met
`agents.defaults.bootstrapPromptTruncationWarning` (`off`, `once`, `always`;
standaard: `once`).
Subagentsessies injecteren alleen `AGENTS.md` en `TOOLS.md` (andere bootstrapbestanden worden uitgefilterd om de subagentcontext klein te houden).
Subagentsessies injecteren alleen `AGENTS.md` en `TOOLS.md` (andere bootstrapbestanden
worden eruit gefilterd om de subagentcontext klein te houden).
Interne hooks kunnen deze stap onderscheppen via `agent:bootstrap` om de geinjecteerde bootstrapbestanden te muteren of te vervangen (bijvoorbeeld `SOUL.md` vervangen door een alternatieve persona).
Interne hooks kunnen deze stap onderscheppen via `agent:bootstrap` om de geïnjecteerde bootstrapbestanden te muteren of te vervangen (bijvoorbeeld door `SOUL.md` te vervangen door een alternatieve persona).
Als je de agent minder generiek wilt laten klinken, begin dan met
Als je de agent minder generiek wilt laten klinken, begin dan met de
[SOUL.md-persoonlijkheidsgids](/nl/concepts/soul).
Gebruik `/context list` of `/context detail` om te inspecteren hoeveel elk geinjecteerd bestand bijdraagt (ruw versus geinjecteerd, afkapping, plus overhead van toolschema's). Zie [Context](/nl/concepts/context).
Gebruik `/context list` of `/context detail` om te inspecteren hoeveel elk geïnjecteerd bestand bijdraagt (ruw versus geïnjecteerd, afkapping, plus overhead van toolschema's). Zie [Context](/nl/concepts/context).
## Tijdsafhandeling
## Tijdafhandeling
De systeemprompt bevat een speciale sectie **Huidige datum en tijd** wanneer de gebruikerstijdzone bekend is. Om de prompt cache-stabiel te houden, bevat die nu alleen de **tijdzone** (geen dynamische klok of tijdnotatie).
De systeemprompt bevat een speciale sectie **Huidige datum en tijd** wanneer de
gebruikerstijdzone bekend is. Om de prompt cachestabiel te houden, bevat deze nu alleen
de **tijdzone** (geen dynamische klok of tijdnotatie).
Gebruik `session_status` wanneer de agent de huidige tijd nodig heeft; de statuskaart bevat een tijdstempelregel. Dezelfde tool kan optioneel een modelspecifieke override per sessie instellen (`model=default` wist die).
Gebruik `session_status` wanneer de agent de huidige tijd nodig heeft; de statuskaart
bevat een tijdstempelregel. Dezelfde tool kan optioneel een modelspecifieke overschrijving per sessie
instellen (`model=default` wist deze).
Configureer met:
@ -149,13 +212,19 @@ Zie [Datum en tijd](/nl/date-time) voor volledige gedragsdetails.
## Skills
Wanneer geschikte Skills bestaan, injecteert OpenClaw een compacte **lijst met beschikbare Skills**
(`formatSkillsForPrompt`) die het **bestandspad** voor elke skill bevat. De prompt instrueert het model om `read` te gebruiken om de SKILL.md op de vermelde locatie te laden (workspace, beheerd of gebundeld). Als er geen Skills geschikt zijn, wordt de sectie Skills weggelaten.
Wanneer in aanmerking komende skills bestaan, injecteert OpenClaw een compacte **lijst met beschikbare skills**
(`formatSkillsForPrompt`) die het **bestandspad** voor elke skill bevat. De
prompt instrueert het model om `read` te gebruiken om de SKILL.md op de vermelde
locatie (werkruimte, beheerd of gebundeld) te laden. Als geen skills in aanmerking komen, wordt de
Skills-sectie weggelaten.
Geschiktheid omvat gates voor skillmetadata, runtime-omgeving/configuratiecontroles en de effectieve allowlist voor agentskills wanneer `agents.defaults.skills` of
Eligibility omvat skill-metadatagates, runtime-omgevings-/configuratiecontroles,
en de effectieve agent-skill-toelatingslijst wanneer `agents.defaults.skills` of
`agents.list[].skills` is geconfigureerd.
Door Plugin gebundelde Skills zijn alleen geschikt wanneer hun eigenaar-Plugin is ingeschakeld. Dit laat toolplugins diepere operationele gidsen aanbieden zonder al die begeleiding rechtstreeks in elke toolbeschrijving in te bedden.
Door plugins gebundelde skills komen alleen in aanmerking wanneer hun eigenaar-Plugin is ingeschakeld.
Hierdoor kunnen toolplugins diepere bedieningsgidsen beschikbaar maken zonder al
die richtlijnen direct in elke toolbeschrijving in te bedden.
```
<available_skills>
@ -167,26 +236,25 @@ Door Plugin gebundelde Skills zijn alleen geschikt wanneer hun eigenaar-Plugin i
</available_skills>
```
Dit houdt de basisprompt klein terwijl gericht gebruik van Skills nog steeds mogelijk blijft.
Dit houdt de basisprompt klein terwijl gericht skillgebruik mogelijk blijft.
Het budget voor de Skills-lijst is eigendom van het Skills-subsysteem:
Het budget voor de skillslijst is eigendom van het skillsubsysteem:
- Globale standaard: `skills.limits.maxSkillsPromptChars`
- Override per agent: `agents.list[].skillsLimits.maxSkillsPromptChars`
- Overschrijving per agent: `agents.list[].skillsLimits.maxSkillsPromptChars`
Generieke begrensde runtimefragmenten gebruiken een ander oppervlak:
Generieke begrensde runtime-uittreksels gebruiken een ander oppervlak:
- `agents.defaults.contextLimits.*`
- `agents.list[].contextLimits.*`
Die splitsing houdt de groottebepaling van Skills gescheiden van runtime-lees-/injectiegroottebepaling zoals
`memory_get`, live toolresultaten en post-Compaction-verversingen van AGENTS.md.
Die splitsing houdt de groottebepaling voor Skills gescheiden van de groottebepaling voor lezen/injectie tijdens runtime, zoals `memory_get`, live toolresultaten en AGENTS.md-verversingen na Compaction.
## Documentatie
De systeemprompt bevat een sectie **Documentatie**. Wanneer lokale documentatie beschikbaar is, verwijst deze naar de lokale OpenClaw-documentatiemap (`docs/` in een Git-checkout of de meegeleverde npm-pakketdocumentatie). Als lokale documentatie niet beschikbaar is, valt deze terug op [https://docs.openclaw.ai](https://docs.openclaw.ai).
De systeemprompt bevat een sectie **Documentatie**. Wanneer lokale documentatie beschikbaar is, verwijst die naar de lokale OpenClaw-documentatiemap (`docs/` in een Git-checkout of de documentatie uit het gebundelde npm-pakket). Als lokale documentatie niet beschikbaar is, valt die terug op [https://docs.openclaw.ai](https://docs.openclaw.ai).
Dezelfde sectie bevat ook de OpenClaw-bronlocatie. Git-checkouts geven de lokale bronhoofdmap weer, zodat de agent de code direct kan inspecteren. Pakketinstallaties bevatten de GitHub-bron-URL en instrueren de agent om de bron daar te bekijken wanneer de documentatie onvolledig of verouderd is. De prompt vermeldt ook de openbare documentatiespiegel, de community-Discord en ClawHub ([https://clawhub.ai](https://clawhub.ai)) voor Skills-ontdekking. Deze vertelt het model om eerst de documentatie te raadplegen voor OpenClaw-gedrag, -commando’s, -configuratie of -architectuur, en om waar mogelijk zelf `openclaw status` uit te voeren (en de gebruiker alleen te vragen wanneer het geen toegang heeft). Specifiek voor configuratie verwijst deze agents naar de `gateway`-toolactie `config.schema.lookup` voor exacte documentatie en beperkingen op veldniveau, en vervolgens naar `docs/gateway/configuration.md` en `docs/gateway/configuration-reference.md` voor bredere richtlijnen.
Dezelfde sectie bevat ook de bronlocatie van OpenClaw. Git-checkouts tonen de lokale bronroot zodat de agent code rechtstreeks kan inspecteren. Pakketinstallaties bevatten de GitHub-bron-URL en vertellen de agent om daar de bron te bekijken wanneer de documentatie onvolledig of verouderd is. De prompt vermeldt ook de openbare documentatiespiegel, de community-Discord en ClawHub ([https://clawhub.ai](https://clawhub.ai)) voor het ontdekken van Skills. Die vertelt het model om eerst de documentatie te raadplegen voor OpenClaw-gedrag, opdrachten, configuratie of architectuur, en om waar mogelijk zelf `openclaw status` uit te voeren (en de gebruiker alleen te vragen wanneer het geen toegang heeft). Specifiek voor configuratie verwijst die agents naar de `gateway`-toolactie `config.schema.lookup` voor exacte documentatie en beperkingen op veldniveau, en daarna naar `docs/gateway/configuration.md` en `docs/gateway/configuration-reference.md` voor bredere richtlijnen.
## Gerelateerd

95
docs/nl/nodes/audio.md
View File

@ -1,34 +1,35 @@
---
read_when:
- Audiotranscriptie of mediaverwerking wijzigen
summary: Hoe binnenkomende audio-/spraaknotities worden gedownload, getranscribeerd en in antwoorden worden geïnjecteerd
- Audio-transcriptie of mediaverwerking wijzigen
summary: Hoe inkomende audio-/spraakberichten worden gedownload, getranscribeerd en in antwoorden worden ingevoegd
title: Audio en spraaknotities
x-i18n:
generated_at: "2026-04-29T22:56:36Z"
generated_at: "2026-05-02T23:38:56Z"
model: gpt-5.5
provider: openai
source_hash: 35074d79104f767ee252064462202a8ec21ac26f6db25c39e67f31f6b40edeb7
source_hash: 91cd6951f80c6137061a7d4e82415b0872bc92c6d6ad136273a2e9ad7ec00ac1
source_path: nodes/audio.md
workflow: 16
---
# Audio / spraaknotities (2026-01-17)
# Audio / spraakberichten (2026-01-17)
## Wat werkt
- **Mediabegrip (audio)**: Als audiobegrip is ingeschakeld (of automatisch gedetecteerd), doet OpenClaw het volgende:
1. Vindt de eerste audio-bijlage (lokaal pad of URL) en downloadt die indien nodig.
2. Dwingt `maxBytes` af voordat naar elke modelvermelding wordt verzonden.
3. Voert de eerste geschikte modelvermelding op volgorde uit (provider of CLI).
4. Als deze mislukt of wordt overgeslagen (grootte/time-out), probeert het de volgende vermelding.
- **Mediabegrip (audio)**: Als audiobegrip is ingeschakeld (of automatisch is gedetecteerd), doet OpenClaw het volgende:
1. Het zoekt de eerste audiobijlage (lokaal pad of URL) en downloadt die indien nodig.
2. Het handhaaft `maxBytes` voordat er naar elke modelvermelding wordt verzonden.
3. Het voert de eerste geschikte modelvermelding in volgorde uit (provider of CLI).
4. Als die faalt of wordt overgeslagen (grootte/time-out), probeert het de volgende vermelding.
5. Bij succes vervangt het `Body` door een `[Audio]`-blok en stelt het `{{Transcript}}` in.
- **Opdrachtparsing**: Wanneer transcriptie slaagt, worden `CommandBody`/`RawBody` ingesteld op het transcript, zodat slash-commando's blijven werken.
- **Commandoparsing**: Wanneer transcriptie slaagt, worden `CommandBody`/`RawBody` ingesteld op het transcript, zodat slash-commando's blijven werken.
- **Uitgebreide logging**: In `--verbose` loggen we wanneer transcriptie wordt uitgevoerd en wanneer die de body vervangt.
- **Dictatie in de bedienings-UI**: De chatcomposer kan een met de browser opgenomen microfoonclip naar `chat.transcribeAudio` sturen. Die Gateway-RPC schrijft de clip naar een tijdelijk lokaal bestand, voert dezelfde audiotranscriptiepijplijn uit, retourneert concepttekst naar de browser en verwijdert het tijdelijke bestand. Dit maakt zelf geen agent-run aan.
## Automatische detectie (standaard)
Als je **geen modellen configureert** en `tools.media.audio.enabled` **niet** is ingesteld op `false`,
detecteert OpenClaw automatisch in deze volgorde en stopt bij de eerste werkende optie:
detecteert OpenClaw automatisch in deze volgorde en stopt het bij de eerste werkende optie:
1. **Actief antwoordmodel** wanneer de provider audiobegrip ondersteunt.
2. **Lokale CLI's** (indien geïnstalleerd)
@ -36,13 +37,13 @@ detecteert OpenClaw automatisch in deze volgorde en stopt bij de eerste werkende
- `whisper-cli` (van `whisper-cpp`; gebruikt `WHISPER_CPP_MODEL` of het meegeleverde tiny-model)
- `whisper` (Python-CLI; downloadt modellen automatisch)
3. **Gemini CLI** (`gemini`) met `read_many_files`
4. **Provider-authenticatie**
4. **Providerauthenticatie**
- Geconfigureerde `models.providers.*`-vermeldingen die audio ondersteunen, worden eerst geprobeerd
- Meegeleverde fallbackvolgorde: OpenAI → Groq → xAI → Deepgram → Google → SenseAudio → ElevenLabs → Mistral
Stel `tools.media.audio.enabled: false` in om automatische detectie uit te schakelen.
Stel `tools.media.audio.models` in om aan te passen.
Opmerking: Binaire detectie is beste inspanning op macOS/Linux/Windows; zorg dat de CLI op `PATH` staat (we breiden `~` uit), of stel een expliciet CLI-model in met een volledig opdrachtpad.
Stel `tools.media.audio.models` in om dit aan te passen.
Opmerking: detectie van binaries is best-effort op macOS/Linux/Windows; zorg dat de CLI op `PATH` staat (we breiden `~` uit), of stel een expliciet CLI-model in met een volledig commandopad.
## Configuratievoorbeelden
@ -70,7 +71,7 @@ Opmerking: Binaire detectie is beste inspanning op macOS/Linux/Windows; zorg dat
}
```
### Alleen provider met scope-gating
### Alleen provider met scope-afbakening
```json5
{
@ -151,9 +152,9 @@ Opmerking: Binaire detectie is beste inspanning op macOS/Linux/Windows; zorg dat
}
```
## Opmerkingen en limieten
## Opmerkingen en beperkingen
- Provider-authenticatie volgt de standaardvolgorde voor modelauthenticatie (auth-profielen, env-vars, `models.providers.*.apiKey`).
- Providerauthenticatie volgt de standaardvolgorde voor modelauthenticatie (auth-profielen, env vars, `models.providers.*.apiKey`).
- Groq-installatiedetails: [Groq](/nl/providers/groq).
- Deepgram pikt `DEEPGRAM_API_KEY` op wanneer `provider: "deepgram"` wordt gebruikt.
- Deepgram-installatiedetails: [Deepgram (audiotranscriptie)](/nl/providers/deepgram).
@ -161,20 +162,20 @@ Opmerking: Binaire detectie is beste inspanning op macOS/Linux/Windows; zorg dat
- SenseAudio pikt `SENSEAUDIO_API_KEY` op wanneer `provider: "senseaudio"` wordt gebruikt.
- SenseAudio-installatiedetails: [SenseAudio](/nl/providers/senseaudio).
- Audioproviders kunnen `baseUrl`, `headers` en `providerOptions` overschrijven via `tools.media.audio`.
- De standaardgroottelimiet is 20 MB (`tools.media.audio.maxBytes`). Te grote audio wordt voor dat model overgeslagen en de volgende vermelding wordt geprobeerd.
- Kleine/lege audiobestanden onder 1024 bytes worden overgeslagen vóór provider-/CLI-transcriptie.
- Standaard `maxChars` voor audio is **niet ingesteld** (volledig transcript). Stel `tools.media.audio.maxChars` of per vermelding `maxChars` in om uitvoer in te korten.
- De automatische OpenAI-standaard is `gpt-4o-mini-transcribe`; stel `model: "gpt-4o-transcribe"` in voor hogere nauwkeurigheid.
- Gebruik `tools.media.audio.attachments` om meerdere spraaknotities te verwerken (`mode: "all"` + `maxAttachments`).
- Transcript is beschikbaar voor sjablonen als `{{Transcript}}`.
- `tools.media.audio.echoTranscript` staat standaard uit; schakel dit in om transcriptbevestiging terug te sturen naar de oorspronkelijke chat vóór agentverwerking.
- `tools.media.audio.echoFormat` past de echo-tekst aan (placeholder: `{transcript}`).
- CLI-stdout is begrensd (5 MB); houd CLI-uitvoer beknopt.
- CLI `args` moeten `{{MediaPath}}` gebruiken voor het lokale audiobestandspad. Voer `openclaw doctor --fix` uit om verouderde `{input}`-placeholders uit oudere `audio.transcription.command`-configuraties te migreren.
- De standaardgroottelimiet is 20MB (`tools.media.audio.maxBytes`). Te grote audio wordt voor dat model overgeslagen en de volgende vermelding wordt geprobeerd.
- Zeer kleine/lege audiobestanden onder 1024 bytes worden overgeslagen vóór provider-/CLI-transcriptie.
- Standaard is `maxChars` voor audio **niet ingesteld** (volledig transcript). Stel `tools.media.audio.maxChars` of per vermelding `maxChars` in om uitvoer in te korten.
- OpenAI automatische standaard is `gpt-4o-mini-transcribe`; stel `model: "gpt-4o-transcribe"` in voor hogere nauwkeurigheid.
- Gebruik `tools.media.audio.attachments` om meerdere spraakberichten te verwerken (`mode: "all"` + `maxAttachments`).
- Het transcript is beschikbaar voor templates als `{{Transcript}}`.
- `tools.media.audio.echoTranscript` staat standaard uit; schakel dit in om vóór agentverwerking een transcriptbevestiging terug te sturen naar de oorspronkelijke chat.
- `tools.media.audio.echoFormat` past de echotekst aan (placeholder: `{transcript}`).
- CLI-stdout is afgekapt (5MB); houd CLI-uitvoer beknopt.
- CLI-`args` moeten `{{MediaPath}}` gebruiken voor het lokale audiobestandspad. Voer `openclaw doctor --fix` uit om verouderde `{input}`-placeholders uit oudere `audio.transcription.command`-configs te migreren.
### Ondersteuning voor proxy-omgevingen
### Ondersteuning voor proxy-omgeving
Providergebaseerde audiotranscriptie respecteert standaard env-vars voor uitgaande proxy's:
Op provider gebaseerde audiotranscriptie respecteert standaard env vars voor uitgaande proxy's:
- `HTTPS_PROXY`
- `HTTP_PROXY`
@ -183,39 +184,39 @@ Providergebaseerde audiotranscriptie respecteert standaard env-vars voor uitgaan
- `http_proxy`
- `all_proxy`
Als er geen proxy-env-vars zijn ingesteld, wordt directe egress gebruikt. Als proxyconfiguratie onjuist is gevormd, logt OpenClaw een waarschuwing en valt het terug op direct ophalen.
Als er geen proxy-env vars zijn ingesteld, wordt directe egress gebruikt. Als de proxyconfiguratie ongeldig is, logt OpenClaw een waarschuwing en valt het terug op direct ophalen.
## Vermeldingsdetectie in groepen
## Detectie van vermeldingen in groepen
Wanneer `requireMention: true` is ingesteld voor een groepschat, transcribeert OpenClaw audio nu **vóór** het controleren op vermeldingen. Hierdoor kunnen spraaknotities worden verwerkt, zelfs wanneer ze vermeldingen bevatten.
Wanneer `requireMention: true` is ingesteld voor een groepschat, transcribeert OpenClaw audio nu **voordat** er op vermeldingen wordt gecontroleerd. Hierdoor kunnen spraakberichten worden verwerkt, zelfs wanneer ze vermeldingen bevatten.
**Hoe het werkt:**
**Zo werkt het:**
1. Als een spraakbericht geen tekstbody heeft en de groep vermeldingen vereist, voert OpenClaw een "preflight"-transcriptie uit.
2. Het transcript wordt gecontroleerd op vermeldingspatronen (bijv. `@BotName`, emoji-triggers).
3. Als er een vermelding wordt gevonden, gaat het bericht door de volledige antwoordpipeline.
4. Het transcript wordt gebruikt voor vermeldingsdetectie, zodat spraaknotities de vermeldingspoort kunnen passeren.
3. Als een vermelding wordt gevonden, gaat het bericht door de volledige antwoordpijplijn.
4. Het transcript wordt gebruikt voor vermeldingsdetectie, zodat spraakberichten de vermeldingspoort kunnen passeren.
**Fallbackgedrag:**
- Als transcriptie tijdens preflight mislukt (time-out, API-fout, enz.), wordt het bericht verwerkt op basis van tekstuele vermeldingsdetectie.
- Dit zorgt ervoor dat gemengde berichten (tekst + audio) nooit onterecht worden gedropt.
- Als transcriptie tijdens preflight mislukt (time-out, API-fout, enz.), wordt het bericht verwerkt op basis van vermeldingsdetectie met alleen tekst.
- Dit zorgt ervoor dat gemengde berichten (tekst + audio) nooit onterecht worden genegeerd.
**Opt-out per Telegram-groep/topic:**
**Opt-out per Telegram-groep/-topic:**
- Stel `channels.telegram.groups.<chatId>.disableAudioPreflight: true` in om preflight-controles op transcriptvermeldingen voor die groep over te slaan.
- Stel `channels.telegram.groups.<chatId>.topics.<threadId>.disableAudioPreflight` in om per topic te overschrijven (`true` om over te slaan, `false` om geforceerd in te schakelen).
- Standaard is `false` (preflight ingeschakeld wanneer aan mention-gated voorwaarden wordt voldaan).
- Stel `channels.telegram.groups.<chatId>.disableAudioPreflight: true` in om preflight-transcriptcontroles op vermeldingen voor die groep over te slaan.
- Stel `channels.telegram.groups.<chatId>.topics.<threadId>.disableAudioPreflight` in om dit per topic te overschrijven (`true` om over te slaan, `false` om geforceerd in te schakelen).
- Standaard is `false` (preflight ingeschakeld wanneer aan de voorwaarden voor vermeldingafbakening wordt voldaan).
**Voorbeeld:** Een gebruiker stuurt een spraaknotitie met "Hey @Claude, what's the weather?" in een Telegram-groep met `requireMention: true`. De spraaknotitie wordt getranscribeerd, de vermelding wordt gedetecteerd en de agent antwoordt.
**Voorbeeld:** Een gebruiker stuurt een spraakbericht met "Hey @Claude, what's the weather?" in een Telegram-groep met `requireMention: true`. Het spraakbericht wordt getranscribeerd, de vermelding wordt gedetecteerd en de agent antwoordt.
## Aandachtspunten
## Valkuilen
- Scope-regels gebruiken eerste match wint. `chatType` wordt genormaliseerd naar `direct`, `group` of `room`.
- Zorg dat je CLI afsluit met 0 en platte tekst afdrukt; JSON moet worden bewerkt via `jq -r .text`.
- Scoperegels gebruiken first-match wins. `chatType` wordt genormaliseerd naar `direct`, `group` of `room`.
- Zorg dat je CLI eindigt met 0 en platte tekst afdrukt; JSON moet worden aangepast via `jq -r .text`.
- Voor `parakeet-mlx`: als je `--output-dir` doorgeeft, leest OpenClaw `<output-dir>/<media-basename>.txt` wanneer `--output-format` `txt` is (of is weggelaten); niet-`txt`-uitvoerformaten vallen terug op stdout-parsing.
- Houd time-outs redelijk (`timeoutSeconds`, standaard 60s) om blokkering van de antwoordwachtrij te voorkomen.
- Preflight-transcriptie verwerkt alleen de **eerste** audio-bijlage voor vermeldingsdetectie. Extra audio wordt verwerkt tijdens de hoofdmediabegripsfase.
- Preflight-transcriptie verwerkt alleen de **eerste** audiobijlage voor vermeldingsdetectie. Extra audio wordt verwerkt tijdens de hoofdfase voor mediabegrip.
## Gerelateerd

725
docs/nl/plugins/codex-harness.md
View File

File diff suppressed because it is too large Load Diff

66
docs/nl/providers/arcee.md
View File

@ -5,39 +5,39 @@ read_when:
summary: Arcee AI instellen (authenticatie + modelselectie)
title: Arcee AI
x-i18n:
generated_at: "2026-04-29T23:08:15Z"
generated_at: "2026-05-02T23:39:07Z"
model: gpt-5.5
provider: openai
source_hash: 54989e1706901fedc8a0c816ca7ee7f877fa4b973697540dd90cb9182420043f
source_hash: 622ee5288aec3ae0b45d3f06ba65fd6f972e07d7a7596ae3905d6fbdac0bf737
source_path: providers/arcee.md
workflow: 16
---
[Arcee AI](https://arcee.ai) biedt toegang tot de Trinity-familie van modellen met mixture-of-experts-architectuur via een OpenAI-compatibele API. Alle Trinity-modellen zijn gelicentieerd onder Apache 2.0.
[Arcee AI](https://arcee.ai) biedt toegang tot de Trinity-familie van mixture-of-experts-modellen via een OpenAI-compatibele API. Alle Trinity-modellen hebben een Apache 2.0-licentie.
Arcee AI-modellen zijn rechtstreeks toegankelijk via het Arcee-platform of via [OpenRouter](/nl/providers/openrouter).
| Eigenschap | Waarde |
| ---------- | ------------------------------------------------------------------------------------- |
| Aanbieder | `arcee` |
| Auth | `ARCEEAI_API_KEY` (direct) or `OPENROUTER_API_KEY` (via OpenRouter) |
| Provider | `arcee` |
| Auth | `ARCEEAI_API_KEY` (direct) of `OPENROUTER_API_KEY` (via OpenRouter) |
| API | OpenAI-compatibel |
| Basis-URL | `https://api.arcee.ai/api/v1` (direct) or `https://openrouter.ai/api/v1` (OpenRouter) |
| Basis-URL | `https://api.arcee.ai/api/v1` (direct) of `https://openrouter.ai/api/v1` (OpenRouter) |
## Aan de slag
<Tabs>
<Tab title="Direct (Arcee platform)">
<Tab title="Direct (Arcee-platform)">
<Steps>
<Step title="Get an API key">
<Step title="Een API-sleutel ophalen">
Maak een API-sleutel aan bij [Arcee AI](https://chat.arcee.ai/).
</Step>
<Step title="Run onboarding">
<Step title="Onboarding uitvoeren">
```bash
openclaw onboard --auth-choice arceeai-api-key
```
</Step>
<Step title="Set a default model">
<Step title="Een standaardmodel instellen">
```json5
{
agents: {
@ -53,15 +53,15 @@ Arcee AI-modellen zijn rechtstreeks toegankelijk via het Arcee-platform of via [
<Tab title="Via OpenRouter">
<Steps>
<Step title="Get an API key">
<Step title="Een API-sleutel ophalen">
Maak een API-sleutel aan bij [OpenRouter](https://openrouter.ai/keys).
</Step>
<Step title="Run onboarding">
<Step title="Onboarding uitvoeren">
```bash
openclaw onboard --auth-choice arceeai-openrouter
```
</Step>
<Step title="Set a default model">
<Step title="Een standaardmodel instellen">
```json5
{
agents: {
@ -82,7 +82,7 @@ Arcee AI-modellen zijn rechtstreeks toegankelijk via het Arcee-platform of via [
## Niet-interactieve configuratie
<Tabs>
<Tab title="Direct (Arcee platform)">
<Tab title="Direct (Arcee-platform)">
```bash
openclaw onboard --non-interactive \
--mode local \
@ -103,37 +103,37 @@ Arcee AI-modellen zijn rechtstreeks toegankelijk via het Arcee-platform of via [
## Ingebouwde catalogus
OpenClaw wordt momenteel geleverd met deze gebundelde Arcee-catalogus:
OpenClaw levert momenteel deze gebundelde Arcee-catalogus:
| Modelref | Naam | Invoer | Context | Kosten (in/uit per 1M) | Opmerkingen |
| ------------------------------ | ---------------------- | ------ | ------- | ---------------------- | ---------------------------------------- |
| `arcee/trinity-large-thinking` | Trinity Large Thinking | text | 256K | $0.25 / $0.90 | Standaardmodel; redeneren ingeschakeld |
| `arcee/trinity-large-preview` | Trinity Large Preview | text | 128K | $0.25 / $1.00 | Algemeen inzetbaar; 400B params, 13B actief |
| `arcee/trinity-mini` | Trinity Mini 26B | text | 128K | $0.045 / $0.15 | Snel en kostenefficiënt; functieaanroepen |
| Modelref | Naam | Invoer | Context | Kosten (in/uit per 1 mln.) | Opmerkingen |
| ------------------------------ | ---------------------- | ------ | ------- | -------------------------- | ------------------------------------------------ |
| `arcee/trinity-large-thinking` | Trinity Large Thinking | tekst | 256K | $0.25 / $0.90 | Standaardmodel; redeneren ingeschakeld; geen tools |
| `arcee/trinity-large-preview` | Trinity Large Preview | tekst | 128K | $0.25 / $1.00 | Algemeen inzetbaar; 400B parameters, 13B actief |
| `arcee/trinity-mini` | Trinity Mini 26B | tekst | 128K | $0.045 / $0.15 | Snel en kostenefficient; functieaanroepen |
<Tip>
De onboarding-preset stelt `arcee/trinity-large-thinking` in als het standaardmodel.
De onboarding-preset stelt `arcee/trinity-large-thinking` in als standaardmodel. Het is alleen voor redeneren/tekst en ondersteunt geen toolgebruik of functieaanroepen.
</Tip>
## Ondersteunde functies
| Functie | Ondersteund |
| -------------------------------------------- | ---------------------------- |
| Streaming | Ja |
| Toolgebruik / functieaanroepen | Ja |
| Gestructureerde uitvoer (JSON-modus en JSON-schema) | Ja |
| Uitgebreid denken | Ja (Trinity Large Thinking) |
| Functie | Ondersteund |
| -------------------------------------------- | -------------------------------------------- |
| Streaming | Ja |
| Toolgebruik / functieaanroepen | Afhankelijk van het model; niet Trinity Large Thinking |
| Gestructureerde uitvoer (JSON-modus en JSON-schema) | Ja |
| Uitgebreid denken | Ja (Trinity Large Thinking) |
<AccordionGroup>
<Accordion title="Environment note">
<Accordion title="Omgevingsopmerking">
Als de Gateway als daemon draait (launchd/systemd), zorg er dan voor dat `ARCEEAI_API_KEY`
(of `OPENROUTER_API_KEY`) beschikbaar is voor dat proces (bijvoorbeeld in
`~/.openclaw/.env` of via `env.shellEnv`).
</Accordion>
<Accordion title="OpenRouter routing">
<Accordion title="OpenRouter-routing">
Wanneer je Arcee-modellen via OpenRouter gebruikt, gelden dezelfde `arcee/*`-modelrefs.
OpenClaw handelt de routering transparant af op basis van je auth-keuze. Zie de
OpenClaw handelt routing transparant af op basis van je auth-keuze. Zie de
[OpenRouter-providerdocumentatie](/nl/providers/openrouter) voor OpenRouter-specifieke
configuratiedetails.
</Accordion>
@ -143,9 +143,9 @@ De onboarding-preset stelt `arcee/trinity-large-thinking` in als het standaardmo
<CardGroup cols={2}>
<Card title="OpenRouter" href="/nl/providers/openrouter" icon="shuffle">
Krijg toegang tot Arcee-modellen en vele andere via één API-sleutel.
Krijg toegang tot Arcee-modellen en vele andere via een enkele API-sleutel.
</Card>
<Card title="Model selection" href="/nl/concepts/model-providers" icon="layers">
Aanbieders, modelrefs en failovergedrag kiezen.
<Card title="Modelselectie" href="/nl/concepts/model-providers" icon="layers">
Providers, modelrefs en failovergedrag kiezen.
</Card>
</CardGroup>

660
docs/nl/reference/RELEASING.md
View File

@ -2,22 +2,21 @@
read_when:
- Zoeken naar definities van openbare releasekanalen
- Releasevalidatie of pakketacceptatie uitvoeren
- Op zoek naar versienaamgeving en cadans
summary: Releaselanes, operatorchecklist, validatieboxen, versienaamgeving en cadans
- Op zoek naar versienaamgeving en ritme
summary: Releasesporen, operatorchecklist, validatieboxen, versienaamgeving en cadans
title: Releasebeleid
x-i18n:
generated_at: "2026-05-02T20:58:00Z"
generated_at: "2026-05-02T23:39:12Z"
model: gpt-5.5
provider: openai
source_hash: 493cb8b42f0e15f3bf5f8fb9be7d01fd626f4f16db9ac0a85e6efa747ef12d12
source_hash: ba316d1736eae8edd2fb0a71b9a3da345f8895c3b536e9a1f619718ea12fc851
source_path: reference/RELEASING.md
workflow: 16
---
OpenClaw heeft vier openbare releasekanalen:
OpenClaw heeft drie openbare releasekanalen:
- stable: getagde releases die standaard naar npm `beta` publiceren, of naar npm `latest` wanneer daar expliciet om wordt gevraagd
- alpha: prerelease-tags die naar npm `alpha` publiceren
- stable: getagde releases die standaard naar npm `beta` publiceren, of naar npm `latest` wanneer dat expliciet wordt aangevraagd
- beta: prerelease-tags die naar npm `beta` publiceren
- dev: de bewegende kop van `main`
@ -27,187 +26,186 @@ OpenClaw heeft vier openbare releasekanalen:
- Git-tag: `vYYYY.M.D`
- Stabiele correctiereleaseversie: `YYYY.M.D-N`
- Git-tag: `vYYYY.M.D-N`
- Alpha-prereleaseversie: `YYYY.M.D-alpha.N`
- Git-tag: `vYYYY.M.D-alpha.N`
- Beta-prereleaseversie: `YYYY.M.D-beta.N`
- Git-tag: `vYYYY.M.D-beta.N`
- Gebruik geen voorloopnul voor maand of dag
- `latest` betekent de huidige gepromote stabiele npm-release
- `alpha` betekent het huidige alpha-installatiedoel
- Vul maand of dag niet met nullen aan
- `latest` betekent de huidige gepromoveerde stabiele npm-release
- `beta` betekent het huidige beta-installatiedoel
- Stabiele en stabiele correctiereleases publiceren standaard naar npm `beta`; releasebeheerders kunnen expliciet `latest` als doel kiezen, of later een gecontroleerde beta-build promoveren
- Stabiele en stabiele correctiereleases publiceren standaard naar npm `beta`; release-operators kunnen expliciet `latest` kiezen, of later een gecontroleerde beta-build promoveren
- Elke stabiele OpenClaw-release levert het npm-pakket en de macOS-app samen;
beta-releases valideren en publiceren normaal eerst het npm-/pakketpad, waarbij
bouwen/ondertekenen/notariseren van de mac-app voor stable is gereserveerd, tenzij daar expliciet om wordt gevraagd
beta-releases valideren en publiceren normaal gesproken eerst het npm-/pakketpad, waarbij
bouwen/ondertekenen/notariseren van de Mac-app voor stabiel is gereserveerd tenzij dit expliciet wordt aangevraagd
## Releasecadans
- Releases gaan eerst via beta
- Stable volgt pas nadat de nieuwste beta is gevalideerd
- Maintainers maken releases normaal vanaf een `release/YYYY.M.D`-branch die is gemaakt
- Stabiel volgt pas nadat de nieuwste beta is gevalideerd
- Maintainers maken releases normaal gesproken vanaf een `release/YYYY.M.D`-branch die is gemaakt
vanaf de huidige `main`, zodat releasevalidatie en fixes nieuwe
ontwikkeling op `main` niet blokkeren
- Als een beta-tag is gepusht of gepubliceerd en een fix nodig heeft, maken maintainers
de volgende `-beta.N`-tag in plaats van de oude beta-tag te verwijderen of opnieuw te maken
- Gedetailleerde releaseprocedure, goedkeuringen, inloggegevens en herstelnotities zijn
- Gedetailleerde releaseprocedure, goedkeuringen, referenties en herstelnotities zijn
alleen voor maintainers
## Checklist voor releasebeheerders
## Checklist voor release-operator
Deze checklist is de openbare vorm van de releaseflow. Privé-inloggegevens,
ondertekening, notarisatie, herstel van dist-tags en details voor noodrollback blijven in
Deze checklist is de openbare vorm van de releaseflow. Privéreferenties,
ondertekening, notarisatie, dist-tag-herstel en noodrollbackdetails blijven in
het release-runbook dat alleen voor maintainers is.
1. Begin vanaf de huidige `main`: haal de nieuwste wijzigingen op, bevestig dat de doelcommit is gepusht,
en bevestig dat de huidige `main`-CI groen genoeg is om er een branch vanaf te maken.
en bevestig dat de huidige `main`-CI groen genoeg is om er een branch van te maken.
2. Herschrijf de bovenste sectie van `CHANGELOG.md` op basis van echte commitgeschiedenis met
`/changelog`, houd vermeldingen gebruikersgericht, commit dit, push het, en rebase/pull
nog een keer voordat je een branch maakt.
3. Beoordeel releasecompatibiliteitsrecords in
`/changelog`, houd items gebruikersgericht, commit dit, push dit, en rebase/pull
nog één keer voordat je een branch maakt.
3. Controleer releasecompatibiliteitsrecords in
`src/plugins/compat/registry.ts` en
`src/commands/doctor/shared/deprecation-compat.ts`. Verwijder verlopen
compatibiliteit alleen wanneer het upgradepad gedekt blijft, of leg vast waarom deze
bewust wordt behouden.
4. Maak `release/YYYY.M.D` vanaf de huidige `main`; voer normaal releasewerk niet
rechtstreeks uit op `main`.
5. Verhoog elke vereiste versielocatie voor de bedoelde tag, voer
compatibiliteit alleen wanneer het upgradepad gedekt blijft, of leg vast waarom die
bewust wordt meegenomen.
4. Maak `release/YYYY.M.D` vanaf de huidige `main`; doe normaal releasewerk niet
rechtstreeks op `main`.
5. Verhoog elke vereiste versielocatie voor de beoogde tag, voer
`pnpm plugins:sync` uit zodat publiceerbare Plugin-pakketten de releaseversie
en compatibiliteitsmetadata delen, en voer daarna de lokale deterministische preflight uit:
en compatibiliteitsmetadata delen, en voer daarna de lokale deterministische voorcontrole uit:
`pnpm check:test-types`, `pnpm check:architecture`,
`pnpm build && pnpm ui:build`, `pnpm plugins:sync:check`, en
`pnpm release:check`.
6. Voer `OpenClaw NPM Release` uit met `preflight_only=true`. Voordat er een tag bestaat,
is een volledige release-branch-SHA van 40 tekens toegestaan voor preflight die alleen
valideert. Bewaar de succesvolle `preflight_run_id`.
7. Start alle prereleasetests met `Full Release Validation` voor de
releasebranch, tag of volledige commit-SHA. Dit is het enige handmatige invoerpunt
is een volledige release-branch-SHA van 40 tekens toegestaan voor alleen-validatie
van de voorcontrole. Sla de geslaagde `preflight_run_id` op.
7. Start alle pre-releasetests met `Full Release Validation` voor de
releasebranch, tag of volledige commit-SHA. Dit is het ene handmatige startpunt
voor de vier grote releasetestboxen: Vitest, Docker, QA Lab en Package.
8. Als validatie mislukt, fix dit op de releasebranch en voer het kleinste mislukte
bestand, de kleinste baan, workflowtaak, pakketprofiel, provider of modelallowlist opnieuw uit die
de fix bewijst. Voer de volledige overkoepelende validatie alleen opnieuw uit wanneer het gewijzigde oppervlak
bestand, kanaal, workflowjob, pakketprofiel, provider of model-allowlist opnieuw uit dat
de fix bewijst. Voer de volledige paraplu alleen opnieuw uit wanneer het gewijzigde oppervlak
eerder bewijs verouderd maakt.
9. Voor alpha of beta: tag `vYYYY.M.D-alpha.N` of `vYYYY.M.D-beta.N`, en voer daarna `OpenClaw Release Publish` uit vanaf
de bijpassende `release/YYYY.M.D`-branch. Dit verifieert `pnpm plugins:sync:check`,
9. Voor beta: tag `vYYYY.M.D-beta.N`, en voer daarna `OpenClaw Release Publish` uit vanaf
de bijbehorende `release/YYYY.M.D`-branch. Dit verifieert `pnpm plugins:sync:check`,
publiceert eerst alle publiceerbare Plugin-pakketten naar npm, publiceert dezelfde
set daarna naar ClawHub, en promoot vervolgens het voorbereide OpenClaw npm-preflight-
artefact met de bijpassende dist-tag. Voer na publicatie post-publish pakketacceptatie
uit tegen het gepubliceerde pakket `openclaw@YYYY.M.D-alpha.N`, `openclaw@alpha`,
`openclaw@YYYY.M.D-beta.N` of `openclaw@beta`. Als een gepushte of
gepubliceerde prerelease een fix nodig heeft, maak dan het volgende bijpassende prereleasenummer;
verwijder of herschrijf de oude prerelease niet.
10. Voor stable ga je alleen verder nadat de gecontroleerde beta of releasecandidate het
vereiste validatiebewijs heeft. Publicatie naar stable npm loopt ook via
`OpenClaw Release Publish`, waarbij het succesvolle preflight-artefact opnieuw wordt gebruikt via
`preflight_run_id`; gereedheid voor de stable macOS-release vereist ook de
set daarna naar ClawHub, en promoot vervolgens het voorbereide OpenClaw npm-voorcontrole-
artefact met de bijbehorende dist-tag. Voer na publicatie post-publicatiepakket-
acceptatie uit tegen het gepubliceerde `openclaw@YYYY.M.D-beta.N`- of
`openclaw@beta`-pakket. Als een gepushte of gepubliceerde prerelease een fix nodig heeft,
maak dan het volgende bijbehorende prerelease-nummer; verwijder of herschrijf de oude
prerelease niet.
10. Voor stabiel: ga alleen verder nadat de gecontroleerde beta of releasekandidaat het
vereiste validatiebewijs heeft. Stabiele npm-publicatie verloopt ook via
`OpenClaw Release Publish`, waarbij het geslaagde voorcontrole-artefact opnieuw wordt gebruikt via
`preflight_run_id`; gereedheid voor stabiele macOS-release vereist ook de
verpakte `.zip`, `.dmg`, `.dSYM.zip` en bijgewerkte `appcast.xml` op `main`.
11. Voer na publicatie de npm-post-publish-verifier uit, optionele zelfstandige
gepubliceerde-npm Telegram-E2E wanneer je kanaalbewijs na publicatie nodig hebt,
dist-tagpromotie wanneer nodig, GitHub-release-/prereleasenotities uit de
volledige bijpassende `CHANGELOG.md`-sectie, en de stappen voor de releaseaankondiging.
11. Voer na publicatie de npm-post-publicatieverificatie uit, optioneel zelfstandige
gepubliceerde-npm Telegram E2E wanneer je post-publicatiekanaalbewijs nodig hebt,
dist-tag-promotie wanneer nodig, GitHub-release-/prerelease-notities uit de
volledige bijbehorende `CHANGELOG.md`-sectie, en de releaseaankondigingsstappen.
## Release-preflight
## Releasevoorcontrole
- Voer `pnpm check:test-types` uit vóór de releasepreflight, zodat test-TypeScript
ook buiten de snellere lokale `pnpm check`-gate gedekt blijft
- Voer `pnpm check:architecture` uit vóór de releasepreflight, zodat de bredere
- Voer `pnpm check:test-types` uit vóór de release-preflight zodat test-TypeScript
gedekt blijft buiten de snellere lokale `pnpm check`-gate
- Voer `pnpm check:architecture` uit vóór de release-preflight zodat de bredere
importcyclus- en architectuurgrenscontroles groen zijn buiten de snellere lokale gate
- Voer `pnpm build && pnpm ui:build` uit vóór `pnpm release:check`, zodat de verwachte
`dist/*`-releaseartefacten en de Control UI-bundel bestaan voor de
pakketvalidatiestap
- Voer `pnpm plugins:sync` uit na de rootversiebump en vóór het taggen. Het
werkt publiceerbare Plugin-pakketversies, OpenClaw-peer/API-compatibiliteitsmetadata,
buildmetadata en Plugin-changelogstubs bij zodat ze overeenkomen met de core
releaseversie. `pnpm plugins:sync:check` is de niet-muteren releaseguard;
- Voer `pnpm build && pnpm ui:build` uit vóór `pnpm release:check` zodat de verwachte
`dist/*`-releaseartefacten en de Control UI-bundel bestaan voor de pack-
validatiestap
- Voer `pnpm plugins:sync` uit na de root-versiebump en vóór het taggen. Het
werkt publiceerbare Plugin-pakketversies, OpenClaw peer-/API-compatibiliteits-
metadata, buildmetadata en Plugin-changelogstubs bij zodat ze overeenkomen met
de core-releaseversie. `pnpm plugins:sync:check` is de niet-muteren­de releaseguard;
de publicatieworkflow faalt vóór enige registry-mutatie als deze stap is
vergeten.
- Voer de handmatige workflow `Full Release Validation` uit vóór releasegoedkeuring om
alle prerelease-testboxen vanuit één toegangspunt te starten. Deze accepteert een branch,
tag of volledige commit-SHA, dispatcht handmatig `CI` en dispatcht
`OpenClaw Release Checks` voor installatiesmoke, pakketacceptatie, Docker
release-pad-suites, live/E2E, OpenWebUI, QA Lab-pariteit, Matrix- en Telegram
lanes. Met `release_profile=full` en `rerun_group=all` voert deze ook pakket
Telegram E2E uit tegen het artefact `release-package-under-test` uit releasechecks.
Geef `npm_telegram_package_spec` op na publicatie wanneer dezelfde
- Voer de handmatige `Full Release Validation`-workflow uit vóór releasegoedkeuring om
alle pre-releasetestboxen vanuit één ingangspunt te starten. Deze accepteert een branch,
tag of volledige commit-SHA, dispatcht handmatige `CI`, en dispatcht
`OpenClaw Release Checks` voor installatiesmoke, package acceptance, Docker
release-path-suites, live/E2E, OpenWebUI, QA Lab-pariteit, Matrix- en Telegram-
lanes. Met `release_profile=full` en `rerun_group=all` voert deze ook package
Telegram E2E uit tegen het `release-package-under-test`-artefact uit release-
checks. Geef `npm_telegram_package_spec` op na publicatie wanneer dezelfde
Telegram E2E ook het gepubliceerde npm-pakket moet bewijzen. Geef
`package_acceptance_package_spec` op na publicatie wanneer Package Acceptance
zijn pakket/update-matrix moet uitvoeren tegen het verzonden npm-pakket in plaats
van het uit de SHA gebouwde artefact. Geef
de package/update-matrix moet uitvoeren tegen het uitgeleverde npm-pakket in plaats
van het vanuit de SHA gebouwde artefact. Geef
`evidence_package_spec` op wanneer het private bewijsrapport moet bewijzen dat de
validatie overeenkomt met een gepubliceerd npm-pakket zonder Telegram E2E af te dwingen.
validatie overeenkomt met een gepubliceerd npm-pakket zonder Telegram E2E af te
dwingen.
Voorbeeld:
`gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
- Voer de handmatige workflow `Package Acceptance` uit wanneer je bewijs via een zijkanaal
wilt voor een pakketkandidaat terwijl het releasewerk doorgaat. Gebruik `source=npm` voor
`openclaw@alpha`, `openclaw@beta`, `openclaw@latest` of een exacte releaseversie; `source=ref`
om een vertrouwde `package_ref`-branch/tag/SHA te verpakken met de huidige
`workflow_ref`-harness; `source=url` voor een HTTPS-tarball met een verplichte
SHA-256; of `source=artifact` voor een tarball die is geüpload door een andere GitHub
Actions-run. De workflow resolveert de kandidaat naar
- Voer de handmatige `Package Acceptance`-workflow uit wanneer je bewijs via een nevenkanaal
wilt voor een pakketkandidaat terwijl releasewerk doorgaat. Gebruik `source=npm` voor
`openclaw@beta`, `openclaw@latest` of een exacte releaseversie; `source=ref`
om een vertrouwde `package_ref`-branch/tag/SHA te packen met de huidige
`workflow_ref`-harnas; `source=url` voor een HTTPS-tarball met een vereiste
SHA-256; of `source=artifact` voor een tarball die door een andere GitHub
Actions-run is geüpload. De workflow herleidt de kandidaat tot
`package-under-test`, hergebruikt de Docker E2E-releasescheduler tegen die
tarball en kan Telegram QA tegen dezelfde tarball uitvoeren met
tarball, en kan Telegram QA tegen dezelfde tarball uitvoeren met
`telegram_mode=mock-openai` of `telegram_mode=live-frontier`. Wanneer de
geselecteerde Docker-lanes `published-upgrade-survivor` bevatten, is het pakketartefact
de kandidaat en selecteert `published_upgrade_survivor_baseline`
de gepubliceerde baseline.
geselecteerde Docker-lanes `published-upgrade-survivor` bevatten, is het package-
artefact de kandidaat en selecteert `published_upgrade_survivor_baseline` de
gepubliceerde baseline.
Voorbeeld: `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`
Veelgebruikte profielen:
- `smoke`: installatie-/kanaal-/agent-, Gateway-netwerk- en config-herlaadlanes
- `package`: artefact-native pakket-/update-/Plugin-lanes zonder OpenWebUI of live ClawHub
- `product`: pakketprofiel plus MCP-kanalen, cron-/subagent-opruiming,
OpenAI-webzoekopdracht en OpenWebUI
- `full`: Docker release-pad-chunks met OpenWebUI
Gangbare profielen:
- `smoke`: install/channel/agent-, Gateway-netwerk- en config-reload-lanes
- `package`: package/update/Plugin-lanes die artefact-native zijn, zonder OpenWebUI of live ClawHub
- `product`: packageprofiel plus MCP-kanalen, Cron-/subagent-opschoning,
OpenAI web search en OpenWebUI
- `full`: Docker release-path-chunks met OpenWebUI
- `custom`: exacte `docker_lanes`-selectie voor een gerichte heruitvoering
- Voer de handmatige workflow `CI` direct uit wanneer je alleen volledige normale CI-dekking
nodig hebt voor de releasekandidaat. Handmatige CI-dispatches omzeilen gewijzigde
scoping en forceren de Linux Node-shards, gebundelde-Plugin-shards, kanaalcontracten,
Node 22-compatibiliteit, `check`, `check-additional`, buildsmoke,
docscontroles, Python Skills, Windows, macOS, Android en Control UI i18n
- Voer de handmatige `CI`-workflow direct uit wanneer je alleen volledige normale CI-
dekking nodig hebt voor de releasekandidaat. Handmatige CI-dispatches omzeilen changed-
scoping en forceren de Linux Node-shards, gebundelde-Plugin-shards, channel-
contracts, Node 22-compatibiliteit, `check`, `check-additional`, buildsmoke,
docs-controles, Python Skills, Windows, macOS, Android en Control UI i18n-
lanes.
Voorbeeld: `gh workflow run ci.yml --ref release/YYYY.M.D`
- Voer `pnpm qa:otel:smoke` uit bij het valideren van releasetelemetrie. Dit test
- Voer `pnpm qa:otel:smoke` uit bij het valideren van releasetelemetrie. Het test
QA-lab via een lokale OTLP/HTTP-ontvanger en verifieert de geëxporteerde trace-
spannamen, begrensde attributen en redactie van inhoud/identifiers zonder
spannamen, begrensde attributen en redactie van content/identifiers zonder
Opik, Langfuse of een andere externe collector te vereisen.
- Voer `pnpm release:check` uit vóór elke getagde release
- Voer `OpenClaw Release Publish` uit voor de muterende publicatiereeks nadat de
tag bestaat. Dispatch deze vanaf `release/YYYY.M.D` (of `main` wanneer je een
vanuit main bereikbare tag publiceert), geef de releasetag en succesvolle OpenClaw npm
`preflight_run_id` door en behoud de standaard Plugin-publicatiescope
tag bestaat. Dispatch deze vanuit `release/YYYY.M.D` (of `main` wanneer een
vanuit main bereikbare tag wordt gepubliceerd), geef de releasetag en succesvolle OpenClaw npm
`preflight_run_id` door, en behoud de standaard Plugin-publicatiescope
`all-publishable`, tenzij je bewust een gerichte reparatie uitvoert. De
workflow serialiseert Plugin npm publish, Plugin ClawHub publish en OpenClaw
npm publish, zodat het corepakket niet wordt gepubliceerd vóór de geëxternaliseerde
Plugins.
- Releasechecks draaien nu in een aparte handmatige workflow:
workflow serialiseert Plugin npm-publicatie, Plugin ClawHub-publicatie en OpenClaw
npm-publicatie zodat het corepakket niet wordt gepubliceerd vóór de geëxternaliseerde
plugins.
- Releasechecks draaien nu in een afzonderlijke handmatige workflow:
`OpenClaw Release Checks`
- `OpenClaw Release Checks` voert ook de QA Lab mock-pariteitslane plus het snelle
live Matrix-profiel en de Telegram QA-lane uit vóór releasegoedkeuring. De live
lanes gebruiken de omgeving `qa-live-shared`; Telegram gebruikt ook Convex CI-
credentialleases. Voer de handmatige workflow `QA-Lab - All Lanes` uit met
`matrix_profile=all` en `matrix_shards=true` wanneer je de volledige Matrix-
lanes gebruiken de `qa-live-shared`-omgeving; Telegram gebruikt ook Convex CI-
credentialleases. Voer de handmatige `QA-Lab - All Lanes`-workflow uit met
`matrix_profile=all` en `matrix_shards=true` wanneer je volledige Matrix-
transport-, media- en E2EE-inventaris parallel wilt.
- Cross-OS-runtimevalidatie voor installatie en upgrade maakt deel uit van publieke
`OpenClaw Release Checks` en `Full Release Validation`, die de herbruikbare workflow
- Cross-OS installatie- en upgrade-runtimevalidatie is onderdeel van publieke
`OpenClaw Release Checks` en `Full Release Validation`, die de
herbruikbare workflow
`.github/workflows/openclaw-cross-os-release-checks-reusable.yml` direct aanroepen
- Deze splitsing is bewust: houd het echte npm-releasepad kort,
deterministisch en artefactgericht, terwijl tragere livecontroles in hun
eigen lane blijven zodat ze publicatie niet vertragen of blokkeren
- Releasechecks met geheimen moeten worden gedispatcht via `Full Release
Validation` of vanaf de `main`/release-workflowref, zodat workflowlogica en
geheimen gecontroleerd blijven
- Deze splitsing is opzettelijk: houd het echte npm-releasepad kort,
deterministisch en artefactgericht, terwijl tragere live checks in hun eigen
lane blijven zodat ze publiceren niet vertragen of blokkeren
- Releasechecks met secrets moeten worden gedispatcht via `Full Release
Validation` of vanuit de `main`/release-workflowref zodat workflowlogica en
secrets gecontroleerd blijven
- `OpenClaw Release Checks` accepteert een branch, tag of volledige commit-SHA zolang
de opgeloste commit bereikbaar is vanaf een OpenClaw-branch of releasetag
- Validatie-only preflight van `OpenClaw NPM Release` accepteert ook de huidige
volledige 40-tekens workflow-branch-commit-SHA zonder een gepushte tag te vereisen
de opgeloste commit bereikbaar is vanuit een OpenClaw-branch of releasetag
- `OpenClaw NPM Release` validatie-only preflight accepteert ook de huidige
volledige 40-teken workflow-branch-commit-SHA zonder een gepushte tag te vereisen
- Dat SHA-pad is alleen voor validatie en kan niet worden gepromoveerd naar een echte publicatie
- In SHA-modus synthetiseert de workflow `v<package.json version>` alleen voor de
pakketmetadatacontrole; echte publicatie vereist nog steeds een echte releasetag
- Beide workflows houden het echte publicatie- en promotiepad op GitHub-gehoste
- Beide workflows houden het echte publicatie- en promotiepad op GitHub-hosted
runners, terwijl het niet-muterende validatiepad de grotere
Blacksmith Linux-runners kan gebruiken
- Die workflow voert
`OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
uit met zowel `OPENAI_API_KEY` als `ANTHROPIC_API_KEY` workflowgeheimen
- npm-releasepreflight wacht niet langer op de aparte releasechecks-lane
uit met zowel `OPENAI_API_KEY` als `ANTHROPIC_API_KEY` workflowsecrets
- npm-releasepreflight wacht niet langer op de afzonderlijke releasechecks-lane
- Voer `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
(of de overeenkomende beta-/correctietag) uit vóór goedkeuring
- Voer na npm-publicatie
@ -215,73 +213,73 @@ Validation` of vanaf de `main`/release-workflowref, zodat workflowlogica en
(of de overeenkomende beta-/correctieversie) uit om het gepubliceerde registry-
installatiepad in een verse tijdelijke prefix te verifiëren
- Voer na een betapublicatie `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`
uit om onboarding van het geïnstalleerde pakket, Telegram-installatie en echte Telegram E2E
tegen het gepubliceerde npm-pakket te verifiëren met de gedeelde geleasete Telegram-credential
pool. Lokale eenmalige maintainer-runs mogen de Convex-variabelen weglaten en de drie
`OPENCLAW_QA_TELEGRAM_*`-env-credentials direct doorgeven.
- Maintainers kunnen dezelfde post-publicatiecontrole uitvoeren vanuit GitHub Actions via de
handmatige workflow `NPM Telegram Beta E2E`. Deze is bewust alleen handmatig en
uit om onboarding van het geïnstalleerde pakket, Telegram-configuratie en echte Telegram E2E
tegen het gepubliceerde npm-pakket te verifiëren met de gedeelde geleasede Telegram-
credentialpool. Lokale maintainer-eenmalige runs mogen de Convex-vars weglaten en de drie
`OPENCLAW_QA_TELEGRAM_*` env-credentials direct doorgeven.
- Maintainers kunnen dezelfde post-publishcontrole uitvoeren vanuit GitHub Actions via de
handmatige `NPM Telegram Beta E2E`-workflow. Deze is bewust alleen handmatig en
draait niet bij elke merge.
- Releaseautomatisering voor maintainers gebruikt nu preflight-dan-promote:
- echte npm-publicatie moet slagen met een succesvolle npm `preflight_run_id`
- de echte npm-publicatie moet worden gedispatcht vanaf dezelfde `main`- of
`release/YYYY.M.D`-branch als de succesvolle preflight-run
- Maintainer-releaseautomatisering gebruikt nu preflight-then-promote:
- echte npm-publicatie moet een succesvolle npm `preflight_run_id` hebben doorstaan
- de echte npm-publicatie moet worden gedispatcht vanuit dezelfde `main`- of
`release/YYYY.M.D`-branch als de succesvolle preflightrun
- stabiele npm-releases gebruiken standaard `beta`
- stabiele npm-publicatie kan expliciet op `latest` richten via workflowinvoer
- tokengebaseerde npm dist-tag-mutatie staat nu in
- stabiele npm-publicatie kan expliciet op `latest` mikken via workflowinput
- tokengebaseerde npm dist-tag-mutatie leeft nu in
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
voor beveiliging, omdat `npm dist-tag add` nog steeds `NPM_TOKEN` nodig heeft terwijl de
om veiligheidsredenen, omdat `npm dist-tag add` nog steeds `NPM_TOKEN` nodig heeft terwijl de
publieke repo OIDC-only publicatie behoudt
- publieke `macOS Release` is alleen validatie; wanneer een tag alleen op een
releasebranch staat maar de workflow vanaf `main` wordt gedispatcht, stel dan
releasebranch bestaat maar de workflow vanuit `main` wordt gedispatcht, stel
`public_release_branch=release/YYYY.M.D` in
- echte private mac-publicatie moet slagen met succesvolle private mac
`preflight_run_id` en `validate_run_id`
- de echte publicatiepaden promoten voorbereide artefacten in plaats van ze opnieuw
te bouwen
- Voor stabiele correctiereleases zoals `YYYY.M.D-N` controleert de post-publicatieverifier
ook hetzelfde upgradepad met tijdelijke prefix van `YYYY.M.D` naar `YYYY.M.D-N`,
- echte private mac-publicatie moet succesvolle private mac
`preflight_run_id` en `validate_run_id` hebben doorstaan
- de echte publicatiepaden promoveren voorbereide artefacten in plaats van ze
opnieuw te bouwen
- Voor stabiele correctiereleases zoals `YYYY.M.D-N` controleert de post-publishverifier
ook hetzelfde temp-prefix-upgradepad van `YYYY.M.D` naar `YYYY.M.D-N`
zodat releasecorrecties oudere globale installaties niet stilzwijgend op de
basis-stabiele payload laten staan
basale stabiele payload laten staan
- npm-releasepreflight faalt gesloten tenzij de tarball zowel
`dist/control-ui/index.html` als een niet-lege `dist/control-ui/assets/`-payload bevat,
zodat we niet opnieuw een leeg browserdashboard verzenden
- Post-publicatieverificatie controleert ook of gepubliceerde Plugin-entrypoints en
`dist/control-ui/index.html` als een niet-lege `dist/control-ui/assets/`-payload bevat
zodat we niet opnieuw een leeg browserdashboard uitleveren
- Post-publishverificatie controleert ook dat gepubliceerde Plugin-entrypoints en
pakketmetadata aanwezig zijn in de geïnstalleerde registry-layout. Een release die
ontbrekende Plugin-runtimepayloads verzendt, faalt de postpublish-verifier en
kan niet worden gepromoveerd naar `latest`.
ontbrekende Plugin-runtimepayloads uitlevert, faalt de postpublishverifier en
kan niet naar `latest` worden gepromoveerd.
- `pnpm test:install:smoke` handhaaft ook het npm pack `unpackedSize`-budget op
de kandidaat-updatetarball, zodat installer-e2e onbedoelde pakketgroei opvangt
de kandidaat-updatetarball, zodat installer-e2e accidentele pack-bloat opvangt
vóór het releasepublicatiepad
- Als het releasewerk CI-planning, extensietimingmanifests of
extensietestmatrices heeft geraakt, regenereer en beoordeel dan vóór goedkeuring de door de planner beheerde
`plugin-prerelease-extension-shard`-matrixuitvoer van
`.github/workflows/plugin-prerelease.yml`, zodat releasenotes geen verouderde CI-layout
beschrijven
- Gereedheid voor stabiele macOS-release omvat ook de updateroppervlakken:
- Als het releasewerk CI-planning, extensietimingmanifesten of
extensietestmatrices heeft geraakt, regenereer en review dan de door de planner beheerde
`plugin-prerelease-extension-shard`-matrixoutputs uit
`.github/workflows/plugin-prerelease.yml` vóór goedkeuring zodat releasenotes geen
verouderde CI-layout beschrijven
- Gereedheid voor stabiele macOS-release omvat ook de updater-oppervlakken:
- de GitHub-release moet uiteindelijk de verpakte `.zip`, `.dmg` en `.dSYM.zip` bevatten
- `appcast.xml` op `main` moet na publicatie naar de nieuwe stabiele zip verwijzen
- de verpakte app moet een niet-debug bundle-id, een niet-lege Sparkle-feed-
- `appcast.xml` op `main` moet na publicatie naar de nieuwe stabiele zip wijzen
- de verpakte app moet een niet-debug bundle-id behouden, een niet-lege Sparkle-feed-
URL en een `CFBundleVersion` op of boven de canonieke Sparkle-buildvloer
voor die releaseversie behouden
voor die releaseversie
## Releasetestboxen
`Full Release Validation` is hoe operators alle prerelease-tests vanuit
één toegangspunt starten. Gebruik voor een bewijs van een vastgepinde commit op een snel bewegende branch de
helper, zodat elke child-workflow draait vanaf een tijdelijke branch die is vastgezet op de doel-
SHA:
`Full Release Validation` is hoe operators alle pre-releasetests vanuit
één ingangspunt starten. Voor bewijs met een gepinde commit op een snel bewegende branch gebruik je de
helper zodat elke child-workflow draait vanuit een tijdelijke branch die op de doel-
SHA is vastgezet:
```bash
pnpm ci:full-release --sha <full-sha>
```
De helper pusht `release-ci/<sha>-...`, dispatcht `Full Release Validation`
vanaf die branch met `ref=<sha>`, verifieert dat elke child-workflow `headSha`
overeenkomt met het doel, en verwijdert daarna de tijdelijke branch. Dit voorkomt dat per ongeluk een
nieuwere `main`-child-run wordt bewezen.
vanuit die branch met `ref=<sha>`, verifieert dat elke child-workflow `headSha`
overeenkomt met het doel, en verwijdert daarna de tijdelijke branch. Dit voorkomt dat je per ongeluk een
nieuwere `main`-childrun bewijst.
Voor validatie van een releasebranch of tag voer je deze uit vanaf de vertrouwde `main`-workflow-
Voor validatie van een releasebranch of tag voer je deze uit vanuit de vertrouwde `main` workflow-
ref en geef je de releasebranch of tag door als `ref`:
```bash
@ -294,45 +292,45 @@ gh workflow run full-release-validation.yml \
-f evidence_package_spec=openclaw@YYYY.M.D-beta.N
```
De workflow lost de doel-ref op, dispatcht handmatige `CI` met
`target_ref=<release-ref>`, dispatcht `OpenClaw Release Checks` en dispatcht
zelfstandige pakket-Telegram-E2E wanneer `release_profile=full` met
De workflow herleidt de doelref, start handmatige `CI` met
`target_ref=<release-ref>`, start `OpenClaw Release Checks` en start
zelfstandige package Telegram E2E wanneer `release_profile=full` met
`rerun_group=all` of wanneer `npm_telegram_package_spec` is ingesteld. `OpenClaw Release
Checks` waaiert vervolgens uit naar installatiesmoke, cross-OS-releasechecks, live/E2E-Docker
release-paddekking, Package Acceptance met Telegram-pakket-QA, QA Lab
Checks` waaiert daarna uit naar install smoke, cross-OS releasecontroles, live/E2E Docker
releasepad-dekking, Package Acceptance met Telegram package-QA, QA Lab
pariteit, live Matrix en live Telegram. Een volledige run is alleen acceptabel wanneer de
samenvatting van `Full Release Validation`
`normal_ci` en `release_checks` als geslaagd toont. In full/all-modus
moet het `npm_telegram`-kind ook geslaagd zijn; buiten full/all wordt het overgeslagen,
tenzij een gepubliceerd `npm_telegram_package_spec` is opgegeven. De uiteindelijke
verificatiesamenvatting bevat tabellen met langzaamste jobs voor elke kind-run, zodat de releasemanager
het huidige kritieke pad kan zien zonder logs te downloaden.
moet de `npm_telegram`-child ook geslaagd zijn; buiten full/all wordt deze overgeslagen
tenzij een gepubliceerde `npm_telegram_package_spec` is opgegeven. De uiteindelijke
verificatiesamenvatting bevat tabellen met traagste jobs voor elke child-run, zodat de
releasemanager het huidige kritieke pad kan zien zonder logs te downloaden.
Zie [Volledige releasevalidatie](/nl/reference/full-release-validation) voor de
volledige fasematrix, exacte workflow-jobnamen, verschillen tussen stabiel en volledig profiel,
artefacten en gerichte rerun-handles.
Kind-workflows worden gedispatcht vanaf de vertrouwde ref die `Full Release
complete fasematrix, exacte workflow-jobnamen, verschillen tussen stabiel en volledig profiel,
artifacts en gerichte rerun-handles.
Child-workflows worden gestart vanaf de vertrouwde ref die `Full Release
Validation` uitvoert, normaal `--ref main`, zelfs wanneer de doel-`ref` naar een
oudere release-branch of tag wijst. Er is geen aparte workflow-ref-invoer voor Full Release Validation;
kies de vertrouwde harness door de workflow-run-ref te kiezen.
Gebruik `--ref main -f ref=<sha>` niet voor exact commit-bewijs op bewegende `main`;
ruwe commit-SHA's kunnen geen workflow-dispatch-refs zijn, dus gebruik
`pnpm ci:full-release --sha <sha>` om de vastgepinde tijdelijke branch te maken.
oudere releasebranch of tag wijst. Er is geen aparte Full Release Validation
workflow-ref-invoer; kies de vertrouwde harness door de workflow-run-ref te kiezen.
Gebruik `--ref main -f ref=<sha>` niet voor exact commitbewijs op bewegende `main`;
ruwe commit-SHA's kunnen geen workflow-dispatchrefs zijn, dus gebruik
`pnpm ci:full-release --sha <sha>` om de gepinde tijdelijke branch te maken.
Gebruik `release_profile` om de live/provider-breedte te selecteren:
- `minimum`: snelste release-kritieke OpenAI/core live- en Docker-pad
- `minimum`: snelste releasekritieke OpenAI/core live- en Docker-pad
- `stable`: minimum plus stabiele provider/backend-dekking voor releasegoedkeuring
- `full`: stable plus brede adviserende provider/media-dekking
- `full`: stable plus brede advisory provider/media-dekking
`OpenClaw Release Checks` gebruikt de vertrouwde workflow-ref om de doel-ref
eenmaal als `release-package-under-test` op te lossen en hergebruikt dat artefact in zowel
release-pad-Dockerchecks als Package Acceptance. Dit houdt alle
pakketgerichte boxes op dezelfde bytes en voorkomt herhaalde pakketbuilds.
De cross-OS-OpenAI-installatiesmoke gebruikt `OPENCLAW_CROSS_OS_OPENAI_MODEL` wanneer de
`OpenClaw Release Checks` gebruikt de vertrouwde workflow-ref om de doelref
eenmalig als `release-package-under-test` te herleiden en hergebruikt dat artifact in zowel
releasepad-Docker-controles als Package Acceptance. Dit houdt alle
packagegerichte boxes op dezelfde bytes en voorkomt herhaalde package-builds.
De cross-OS OpenAI install smoke gebruikt `OPENCLAW_CROSS_OS_OPENAI_MODEL` wanneer de
repo/org-variabele is ingesteld, anders `openai/gpt-5.4`, omdat deze lane
pakketinstallatie, onboarding, Gateway-opstart en één live agent-beurt
bewijst in plaats van het langzaamste standaardmodel te benchmarken. De bredere live provider-
matrix blijft de plaats voor modelspecifieke dekking.
package-installatie, onboarding, Gateway-start en een live agentbeurt bewijst
in plaats van het traagste standaardmodel te benchmarken. De bredere live provider
matrix blijft de plek voor modelspecifieke dekking.
Gebruik deze varianten afhankelijk van de releasefase:
@ -365,40 +363,40 @@ gh workflow run full-release-validation.yml \
```
Gebruik de volledige paraplu niet als eerste rerun na een gerichte fix. Als één box
faalt, gebruik dan de mislukte kind-workflow, job, Docker-lane, pakketprofiel, model-
faalt, gebruik dan de mislukte child-workflow, job, Docker-lane, package-profiel, model
provider of QA-lane voor het volgende bewijs. Run de volledige paraplu pas opnieuw wanneer
de fix gedeelde releaseorkestratie heeft gewijzigd of eerder all-box-bewijs
verouderd heeft gemaakt. De uiteindelijke verifier van de paraplu controleert de vastgelegde kind-workflow-run-
id's opnieuw, dus nadat een kind-workflow succesvol opnieuw is uitgevoerd, rerun je alleen de mislukte
bovenliggende job `Verify full validation`.
verouderd heeft gemaakt. De uiteindelijke verifier van de paraplu controleert de vastgelegde child workflow-run
ids opnieuw, dus nadat een child-workflow succesvol opnieuw is uitgevoerd, rerun alleen de mislukte
`Verify full validation` parent-job.
Geef voor begrensd herstel `rerun_group` door aan de paraplu. `all` is de echte
releasecandidate-run, `ci` runt alleen het normale CI-kind, `plugin-prerelease`
runt alleen het release-only Plugin-kind, `release-checks` runt elke release-
Voor begrensd herstel geef je `rerun_group` door aan de paraplu. `all` is de echte
releasecandidate-run, `ci` runt alleen de normale CI-child, `plugin-prerelease`
runt alleen de release-only Plugin-child, `release-checks` runt elke release
box, en de smallere releasegroepen zijn `install-smoke`, `cross-os`,
`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` en `npm-telegram`.
Gerichte `npm-telegram`-reruns vereisen `npm_telegram_package_spec`; full/all-runs
met `release_profile=full` gebruiken het release-checks-pakketartefact.
met `release_profile=full` gebruiken het package artifact van release-checks.
### Vitest
De Vitest-box is de handmatige `CI`-kind-workflow. Handmatige CI omzeilt bewust
changed scoping en forceert de normale testgrafiek voor de releasecandidate:
Linux Node-shards, gebundelde-Plugin-shards, kanaalcontracten, Node 22-
compatibiliteit, `check`, `check-additional`, build-smoke, docs-checks, Python
De Vitest-box is de handmatige `CI` child-workflow. Handmatige CI omzeilt bewust
changed-scoping en forceert de normale testgrafiek voor de releasecandidate:
Linux Node-shards, bundled-plugin-shards, kanaalcontracten, Node 22
compatibiliteit, `check`, `check-additional`, build smoke, docs-controles, Python
Skills, Windows, macOS, Android en Control UI i18n.
Gebruik deze box om te antwoorden: "is de source tree geslaagd voor de volledige normale testsuite?"
Dit is niet hetzelfde als release-pad-productvalidatie. Te bewaren bewijs:
Gebruik deze box om te beantwoorden: "is de source tree geslaagd voor de volledige normale testsuite?"
Dit is niet hetzelfde als releasepad-productvalidatie. Bewijs om te bewaren:
- samenvatting van `Full Release Validation` die de gedispatchte `CI`-run-URL toont
- samenvatting van `Full Release Validation` met de URL van de gestarte `CI`-run
- `CI`-run groen op de exacte doel-SHA
- mislukte of langzame shardnamen uit de CI-jobs bij onderzoek naar regressies
- Vitest-timingartefacten zoals `.artifacts/vitest-shard-timings.json` wanneer
- mislukte of trage shardnamen uit de CI-jobs bij onderzoek naar regressies
- Vitest-timingartifacts zoals `.artifacts/vitest-shard-timings.json` wanneer
een run prestatieanalyse nodig heeft
Run handmatige CI alleen rechtstreeks wanneer de release deterministische normale CI nodig heeft, maar
niet de Docker-, QA Lab-, live-, cross-OS- of pakket-boxes:
Run handmatige CI alleen rechtstreeks wanneer de release deterministische normale CI nodig heeft maar
niet de Docker-, QA Lab-, live-, cross-OS- of package-boxes:
```bash
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
@ -408,17 +406,17 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
De Docker-box zit in `OpenClaw Release Checks` via
`openclaw-live-and-e2e-checks-reusable.yml`, plus de release-modus
`install-smoke`-workflow. Deze valideert de releasecandidate via verpakte
`install-smoke`-workflow. Deze valideert de releasecandidate via gepackagede
Docker-omgevingen in plaats van alleen source-level tests.
Release-Dockerdekking omvat:
Release-Docker-dekking omvat:
- volledige installatiesmoke met de trage Bun global install smoke ingeschakeld
- voorbereiding/hergebruik van root-Dockerfile-smoke-image per doel-SHA, met QR-,
root/Gateway- en installer/Bun-smokejobs als afzonderlijke install-smoke-
shards
- volledige install smoke met de trage Bun global install smoke ingeschakeld
- voorbereiding/hergebruik van root-Dockerfile smoke-image per doel-SHA, waarbij QR,
root/gateway en installer/Bun smoke-jobs als aparte install-smoke
shards draaien
- repository-E2E-lanes
- release-pad-Dockerchunks: `core`, `package-update-openai`,
- releasepad-Docker-chunks: `core`, `package-update-openai`,
`package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`,
`plugins-runtime-services`,
`plugins-runtime-install-a`, `plugins-runtime-install-b`,
@ -426,93 +424,93 @@ Release-Dockerdekking omvat:
`plugins-runtime-install-e`, `plugins-runtime-install-f`,
`plugins-runtime-install-g` en `plugins-runtime-install-h`
- OpenWebUI-dekking binnen de chunk `plugins-runtime-services` wanneer gevraagd
- gesplitste install/uninstall-lanes voor gebundelde Plugins
- opgesplitste install/uninstall-lanes voor gebundelde Plugins
`bundled-plugin-install-uninstall-0` tot en met
`bundled-plugin-install-uninstall-23`
- live/E2E-provider-suites en Docker-live-modeldekking wanneer releasechecks
live suites bevatten
- live/E2E provider-suites en Docker live model-dekking wanneer releasecontroles
live-suites bevatten
Gebruik Docker-artefacten voordat je opnieuw runt. De release-pad-scheduler uploadt
Gebruik Docker-artifacts voordat je opnieuw runt. De releasepad-scheduler uploadt
`.artifacts/docker-tests/` met lane-logs, `summary.json`, `failures.json`,
fasetimings, scheduler-plan-JSON en rerun-commando's. Gebruik voor gericht herstel
`docker_lanes=<lane[,lane]>` op de herbruikbare live/E2E-workflow in plaats van
fasetimings, scheduler-plan-JSON en rerun-commando's. Voor gericht herstel
gebruik je `docker_lanes=<lane[,lane]>` op de herbruikbare live/E2E-workflow in plaats van
alle releasechunks opnieuw te runnen. Gegenereerde rerun-commando's bevatten eerdere
`package_artifact_run_id` en voorbereide Docker-image-invoer wanneer beschikbaar, zodat een
mislukte lane dezelfde tarball en GHCR-images kan hergebruiken.
### QA Lab
De QA Lab-box is ook onderdeel van `OpenClaw Release Checks`. Het is de agentic
gedrags- en kanaalniveau-releasegate, los van Vitest en Docker-
pakketmechanica.
De QA Lab-box is ook onderdeel van `OpenClaw Release Checks`. Het is de agentische
gedrags- en kanaalniveau-releasegate, los van Vitest en Docker
package-mechanica.
Release-QA Lab-dekking omvat:
Release QA Lab-dekking omvat:
- mock-pariteitslane die de OpenAI-candidate-lane vergelijkt met de Opus 4.6-
baseline met het agentic parity pack
- snel live Matrix-QA-profiel met de omgeving `qa-live-shared`
- mock-pariteitslane die de OpenAI-candidate-lane vergelijkt met de Opus 4.6
baseline met behulp van het agentische parity pack
- snelle live Matrix-QA-profiel met de `qa-live-shared`-omgeving
- live Telegram-QA-lane met Convex CI-credentialleases
- `pnpm qa:otel:smoke` wanneer release-telemetrie expliciet lokaal bewijs nodig heeft
Gebruik deze box om te antwoorden: "gedraagt de release zich correct in QA-scenario's en
live kanaalflows?" Bewaar de artefact-URL's voor pariteit-, Matrix- en Telegram-
Gebruik deze box om te beantwoorden: "gedraagt de release zich correct in QA-scenario's en
live kanaalflows?" Bewaar de artifact-URL's voor pariteit-, Matrix- en Telegram-
lanes bij het goedkeuren van de release. Volledige Matrix-dekking blijft beschikbaar als een
handmatige sharded QA-Lab-run in plaats van de standaard release-kritieke lane.
handmatige sharded QA-Lab-run in plaats van de standaard releasekritieke lane.
### Pakket
### Package
De pakket-box is de gate voor het installeerbare product. Deze wordt ondersteund door
De Package-box is de installable-product-gate. Deze wordt ondersteund door
`Package Acceptance` en de resolver
`scripts/resolve-openclaw-package-candidate.mjs`. De resolver normaliseert een
candidate naar de `package-under-test`-tarball die door Docker-E2E wordt gebruikt, valideert
de pakket-inventaris, legt de pakketversie en SHA-256 vast en houdt de
workflow-harness-ref gescheiden van de pakket-source-ref.
candidate naar de `package-under-test`-tarball die door Docker E2E wordt gebruikt, valideert
de package-inventaris, registreert de packageversie en SHA-256, en houdt de
workflow-harness-ref gescheiden van de package-source-ref.
Ondersteunde candidate-bronnen:
- `source=npm`: `openclaw@beta`, `openclaw@latest` of een exacte OpenClaw-release-
- `source=npm`: `openclaw@beta`, `openclaw@latest` of een exacte OpenClaw-release
versie
- `source=ref`: pak een vertrouwde `package_ref`-branch, tag of volledige commit-SHA
- `source=ref`: pack een vertrouwde `package_ref`-branch, tag of volledige commit-SHA
met de geselecteerde `workflow_ref`-harness
- `source=url`: download een HTTPS-`.tgz` met vereiste `package_sha256`
- `source=artifact`: hergebruik een `.tgz` die door een andere GitHub Actions-run is geüpload
- `source=url`: download een HTTPS `.tgz` met verplichte `package_sha256`
- `source=artifact`: hergebruik een `.tgz` dat door een andere GitHub Actions-run is geüpload
`OpenClaw Release Checks` runt Package Acceptance met `source=artifact`, het
voorbereide releasepakketartefact, `suite_profile=custom`,
voorbereide release-package artifact, `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` en
`telegram_mode=mock-openai`. Package Acceptance houdt migratie, update, opschoning van verouderde
Plugin-afhankelijkheden, offline Plugin-fixtures, Plugin-update en Telegram-
pakket-QA tegen dezelfde opgeloste tarball. De upgradematrix dekt elke stabiele npm-gepubliceerde baseline van `2026.4.23` tot en met `latest`; gebruik
Package Acceptance met `source=npm` voor een al uitgebrachte candidate, of
`telegram_mode=mock-openai`. Package Acceptance houdt migratie, update, stale
Plugin dependency cleanup, offline Plugin-fixtures, Plugin-update en Telegram
package-QA tegen dezelfde herleide tarball. De upgradematrix dekt elke stabiele npm-gepubliceerde baseline van `2026.4.23` tot en met `latest`; gebruik
Package Acceptance met `source=npm` voor een al shipped candidate, of
`source=ref`/`source=artifact` voor een SHA-onderbouwde lokale npm-tarball vóór
publicatie. Het is de GitHub-native
vervanging voor het grootste deel van de pakket/update-dekking waarvoor eerder
Parallels nodig was. Cross-OS-releasechecks blijven belangrijk voor OS-specifieke onboarding,
installer- en platformgedrag, maar pakket/update-productvalidatie moet
Package Acceptance verkiezen.
vervanging voor het grootste deel van de package/update-dekking die voorheen
Parallels vereiste. Cross-OS releasecontroles blijven belangrijk voor OS-specifieke onboarding,
installer en platformgedrag, maar package/update-productvalidatie zou
Package Acceptance moeten verkiezen.
De canonieke checklist voor update- en Plugin-validatie is
[Updates en Plugins testen](/nl/help/testing-updates-plugins). Gebruik deze bij het
bepalen welke lokale, Docker-, Package Acceptance- of release-check-lane een
Plugin-install/update, doctor-opruiming of wijziging in gepubliceerde-pakketmigratie bewijst.
Uitputtende gepubliceerde updatemigratie vanaf elk stabiel `2026.4.23+`-pakket is
Plugin-install/update, doctor cleanup of gepubliceerde-package-migratiewijziging bewijst.
Uitputtende gepubliceerde updatemigratie vanaf elk stabiel `2026.4.23+`-package is
een aparte handmatige `Update Migration`-workflow, geen onderdeel van Full Release CI.
Legacy pakketacceptatie-tolerantie is bewust tijdgebonden. Pakketten tot en met
Legacy package-acceptance-tolerantie is bewust tijdgebonden. Packages tot en met
`2026.4.25` mogen het compatibiliteitspad gebruiken voor metadatagaten die al naar
npm zijn gepubliceerd: private QA-inventarisitems die ontbreken in de tarball, ontbrekende
`gateway install --wrapper`, ontbrekende patchbestanden in de uit tarball afgeleide git-
fixture, ontbrekende persistente `update.channel`, legacy Plugin-install-record-
locaties, ontbrekende marketplace-install-record-persistentie en config-metadata-
migratie tijdens `plugins update`. Het gepubliceerde `2026.4.26`-pakket mag waarschuwen
voor lokale build-metadata-stampbestanden die al zijn geleverd. Latere pakketten
moeten voldoen aan de moderne pakketcontracten; diezelfde gaten laten release-
npm zijn gepubliceerd: private QA-inventarisitems die in de tarball ontbreken, ontbrekende
`gateway install --wrapper`, ontbrekende patchbestanden in de tarball-derived git
fixture, ontbrekende gepersisteerde `update.channel`, legacy Plugin install-record
locaties, ontbrekende marketplace install-record persistence en configuratiemetadata-
migratie tijdens `plugins update`. Het gepubliceerde `2026.4.26`-package mag waarschuwen
voor local build metadata stamp-bestanden die al zijn shipped. Latere packages
moeten aan de moderne packagecontracten voldoen; diezelfde gaten laten release
validatie falen.
Gebruik bredere Package Acceptance-profielen wanneer de releasevraag over een
daadwerkelijk installeerbaar pakket gaat:
daadwerkelijk installeerbaar package gaat:
```bash
gh workflow run package-acceptance.yml \
@ -524,37 +522,37 @@ gh workflow run package-acceptance.yml \
-f published_upgrade_survivor_baseline=openclaw@2026.4.26
```
Veelgebruikte pakketprofielen:
Veelgebruikte packageprofielen:
- `smoke`: snelle pakketinstallatie/kanaal/agent, Gateway-netwerk en config-
- `smoke`: snelle package-install/kanaal/agent, Gateway-netwerk en config
reload-lanes
- `package`: install/update/Plugin-pakketcontracten zonder live ClawHub; dit is de release-check-
- `package`: install/update/Plugin-packagecontracten zonder live ClawHub; dit is de release-check
standaard
- `product`: `package` plus MCP-kanalen, cron/subagent-opruiming, OpenAI-web-
zoekopdracht en OpenWebUI
- `full`: Docker-release-padchunks met OpenWebUI
- `product`: `package` plus MCP-kanalen, cron/subagent-cleanup, OpenAI web
search en OpenWebUI
- `full`: Docker-releasepad-chunks met OpenWebUI
- `custom`: exacte `docker_lanes`-lijst voor gerichte reruns
Voor package-kandidaat-Telegram-bewijs schakel je `telegram_mode=mock-openai` of
`telegram_mode=live-frontier` in op Package Acceptance. De workflow geeft de
Voor package-kandidaatbewijs voor Telegram schakelt u `telegram_mode=mock-openai` of
`telegram_mode=live-frontier` in voor Package Acceptance. De workflow geeft de
opgeloste `package-under-test`-tarball door aan de Telegram-lane; de zelfstandige
Telegram-workflow accepteert nog steeds een gepubliceerde npm-specificatie voor controles na publicatie.
## Release-publicatieautomatisering
## Automatisering voor releasepublicatie
`OpenClaw Release Publish` is het normale muterende ingangspunt voor publicatie. Het
`OpenClaw Release Publish` is het normale muterende publicatie-entrypoint. Het
orkestreert de trusted-publisher-workflows in de volgorde die de release nodig heeft:
1. Check de release-tag uit en bepaal de commit-SHA ervan.
1. Check de releasetag uit en los de commit-SHA ervan op.
2. Controleer of de tag bereikbaar is vanaf `main` of `release/*`.
3. Voer `pnpm plugins:sync:check` uit.
4. Dispatch `Plugin NPM Release` met `publish_scope=all-publishable` en
`ref=<release-sha>`.
5. Dispatch `Plugin ClawHub Release` met dezelfde scope en SHA.
6. Dispatch `OpenClaw NPM Release` met de release-tag, npm dist-tag en
6. Dispatch `OpenClaw NPM Release` met de releasetag, npm dist-tag en
opgeslagen `preflight_run_id`.
Voorbeeld voor beta-publicatie:
Voorbeeld voor betapublicatie:
```bash
gh workflow run openclaw-release-publish.yml \
@ -564,17 +562,7 @@ gh workflow run openclaw-release-publish.yml \
-f npm_dist_tag=beta
```
Voorbeeld voor alpha-publicatie:
```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
```
Stabiele publicatie naar de standaard beta-dist-tag:
Stabiele publicatie naar de standaard bèta-dist-tag:
```bash
gh workflow run openclaw-release-publish.yml \
@ -594,91 +582,91 @@ gh workflow run openclaw-release-publish.yml \
-f npm_dist_tag=latest
```
Gebruik de lagere `Plugin NPM Release`- en `Plugin ClawHub Release`-workflows
alleen voor gerichte reparatie of herpublicatie. Geef voor een geselecteerde Plugin-reparatie
Gebruik de lager-niveau workflows `Plugin NPM Release` en `Plugin ClawHub Release`
alleen voor gericht herstel- of herpublicatiewerk. Geef voor herstel van een geselecteerde Plugin
`plugin_publish_scope=selected` en `plugins=@openclaw/name` door aan
`OpenClaw Release Publish`, of dispatch de onderliggende workflow rechtstreeks wanneer het
`OpenClaw Release Publish`, of dispatch de child-workflow rechtstreeks wanneer het
OpenClaw-pakket niet mag worden gepubliceerd.
## NPM-workflowinvoer
`OpenClaw NPM Release` accepteert deze door operators beheerde invoer:
`OpenClaw NPM Release` accepteert deze door de operator beheerde invoer:
- `tag`: vereiste release-tag zoals `v2026.4.2`, `v2026.4.2-1`, of
`v2026.4.2-alpha.1` of `v2026.4.2-beta.1`; wanneer `preflight_only=true`, mag dit ook de huidige
volledige 40-tekens commit-SHA van de workflow-branch zijn voor preflight die alleen valideert
- `preflight_only`: `true` alleen voor validatie/build/package, `false` voor het
- `tag`: vereiste releasetag zoals `v2026.4.2`, `v2026.4.2-1` of
`v2026.4.2-beta.1`; wanneer `preflight_only=true`, mag dit ook de huidige
volledige 40-tekens lange commit-SHA van de workflowbranch zijn voor een preflight
die alleen valideert
- `preflight_only`: `true` alleen voor validatie/build/pakket, `false` voor het
echte publicatiepad
- `preflight_run_id`: vereist op het echte publicatiepad zodat de workflow de
voorbereide tarball uit de succesvolle preflight-run hergebruikt
voorbereide tarball van de geslaagde preflight-run hergebruikt
- `npm_dist_tag`: npm-doeltag voor het publicatiepad; standaard `beta`
`OpenClaw Release Publish` accepteert deze door operators beheerde invoer:
`OpenClaw Release Publish` accepteert deze door de operator beheerde invoer:
- `tag`: vereiste release-tag; moet al bestaan
- `preflight_run_id`: succesvolle `OpenClaw NPM Release`-preflight-run-id;
- `tag`: vereiste releasetag; moet al bestaan
- `preflight_run_id`: geslaagde `OpenClaw NPM Release` preflight-run-id;
vereist wanneer `publish_openclaw_npm=true`
- `npm_dist_tag`: npm-doeltag voor het OpenClaw-pakket
- `plugin_publish_scope`: standaard `all-publishable`; gebruik `selected` alleen
voor gericht reparatiewerk
- `plugins`: kommagescheiden `@openclaw/*`-pakketnamen wanneer
voor gericht herstelwerk
- `plugins`: door komma's gescheiden `@openclaw/*`-pakketnamen wanneer
`plugin_publish_scope=selected`
- `publish_openclaw_npm`: standaard `true`; stel alleen in op `false` wanneer je de
workflow gebruikt als alleen-Plugin-reparatieorkestrator
- `publish_openclaw_npm`: standaard `true`; stel alleen in op `false` wanneer de
workflow wordt gebruikt als herstelorkestrator alleen voor Plugins
`OpenClaw Release Checks` accepteert deze door operators beheerde invoer:
`OpenClaw Release Checks` accepteert deze door de operator beheerde invoer:
- `ref`: branch, tag of volledige commit-SHA om te valideren. Controles met geheimen
- `ref`: branch, tag of volledige commit-SHA om te valideren. Controles met secrets
vereisen dat de opgeloste commit bereikbaar is vanaf een OpenClaw-branch of
release-tag.
releasetag.
Regels:
- Stabiele en correctie-tags mogen publiceren naar `beta` of `latest`
- Alpha-prerelease-tags mogen alleen naar `alpha` publiceren
- Beta-prerelease-tags mogen alleen naar `beta` publiceren
- Voor `OpenClaw NPM Release` is volledige commit-SHA-invoer alleen toegestaan wanneer
- Stabiele en correctietags mogen publiceren naar `beta` of `latest`
- Bèta-prereleasetags mogen alleen publiceren naar `beta`
- Voor `OpenClaw NPM Release` is invoer met een volledige commit-SHA alleen toegestaan wanneer
`preflight_only=true`
- `OpenClaw Release Checks` en `Full Release Validation` zijn altijd
alleen voor validatie
- Het echte publicatiepad moet dezelfde `npm_dist_tag` gebruiken als tijdens preflight;
de workflow controleert die metadata voordat publicatie doorgaat
alleen validatie
- Het echte publicatiepad moet dezelfde `npm_dist_tag` gebruiken als tijdens de preflight;
de workflow verifieert die metadata voordat de publicatie doorgaat
## Stabiele npm-releasevolgorde
## Stabiele npm-releasereeks
Wanneer je een stabiele npm-release maakt:
Bij het maken van een stabiele npm-release:
1. Voer `OpenClaw NPM Release` uit met `preflight_only=true`
- Voordat er een tag bestaat, mag je de huidige volledige commit-SHA van de workflow-branch
- Voordat er een tag bestaat, mag u de huidige volledige commit-SHA van de workflowbranch
gebruiken voor een validatie-only dry run van de preflight-workflow
2. Kies `npm_dist_tag=beta` voor de normale beta-first flow, of `latest` alleen
wanneer je bewust rechtstreeks stabiel wilt publiceren
3. Voer `Full Release Validation` uit op de release-branch, release-tag of volledige
commit-SHA wanneer je normale CI plus live promptcache, Docker, QA Lab,
2. Kies `npm_dist_tag=beta` voor de normale beta-first-flow, of alleen `latest`
wanneer u bewust rechtstreeks stabiel wilt publiceren
3. Voer `Full Release Validation` uit op de releasebranch, releasetag of volledige
commit-SHA wanneer u normale CI plus live promptcache, Docker, QA Lab,
Matrix en Telegram-dekking vanuit één handmatige workflow wilt
4. Als je bewust alleen de deterministische normale testgraaf nodig hebt, voer dan in plaats daarvan de
handmatige `CI`-workflow uit op de release-ref
5. Sla de succesvolle `preflight_run_id` op
6. Voer `OpenClaw Release Publish` uit met dezelfde `tag`, dezelfde `npm_dist_tag`,
en de opgeslagen `preflight_run_id`; deze publiceert geëxternaliseerde plugins naar npm
4. Als u bewust alleen de deterministische normale testgrafiek nodig hebt, voert u in plaats daarvan de
handmatige `CI`-workflow uit op de releaseref
5. Sla de geslaagde `preflight_run_id` op
6. Voer `OpenClaw Release Publish` uit met dezelfde `tag`, dezelfde `npm_dist_tag`
en de opgeslagen `preflight_run_id`; deze publiceert geëxternaliseerde Plugins naar npm
en ClawHub voordat het OpenClaw-npm-pakket wordt gepromoot
7. Als de release op `beta` is geland, gebruik dan de private
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`-workflow
om die stabiele versie van `beta` naar `latest` te promoveren
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
workflow om die stabiele versie van `beta` naar `latest` te promoveren
8. Als de release bewust rechtstreeks naar `latest` is gepubliceerd en `beta`
onmiddellijk dezelfde stabiele build moet volgen, gebruik dan dezelfde private
workflow om beide dist-tags naar de stabiele versie te laten wijzen, of laat de geplande
zelfherstellende sync `beta` later verplaatsen
zelfherstellende synchronisatie `beta` later verplaatsen
De dist-tag-mutatie staat in de private repo voor beveiliging, omdat deze nog steeds
`NPM_TOKEN` vereist, terwijl de publieke repo alleen OIDC-publicatie gebruikt.
De dist-tag-mutatie staat in de private repo om veiligheidsredenen, omdat die nog steeds
`NPM_TOKEN` vereist, terwijl de publieke repo OIDC-only publicatie behoudt.
Zo blijven het directe publicatiepad en het beta-first promotiepad beide
Zo blijven zowel het rechtstreekse publicatiepad als het beta-first-promotiepad
gedocumenteerd en zichtbaar voor operators.
Als een maintainer moet terugvallen op lokale npm-authenticatie, voer dan alle 1Password
CLI-(`op`)-commando's alleen uit binnen een toegewijde tmux-sessie. Roep `op` niet
rechtstreeks aan vanuit de shell van de hoofdagent; door dit binnen tmux te houden blijven prompts,
CLI (`op`)-commando's alleen uit binnen een dedicated tmux-sessie. Roep `op` niet
rechtstreeks aan vanuit de main agent-shell; door dit binnen tmux te houden blijven prompts,
meldingen en OTP-afhandeling observeerbaar en worden herhaalde hostmeldingen voorkomen.
## Publieke referenties
@ -693,7 +681,7 @@ meldingen en OTP-afhandeling observeerbaar en worden herhaalde hostmeldingen voo
- [`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)
Maintainers gebruiken de private release-documentatie in
Maintainers gebruiken de private releasedocumentatie in
[`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
voor het daadwerkelijke runbook.

284
docs/nl/web/control-ui.md
View File

@ -3,18 +3,18 @@ read_when:
- Je wilt de Gateway vanuit een browser bedienen
- Je wilt Tailnet-toegang zonder SSH-tunnels
sidebarTitle: Control UI
summary: Browsergebaseerde bedienings-UI voor de Gateway (chat, knooppunten, configuratie)
title: Bedieningsinterface
summary: Browsergebaseerde beheer-UI voor de Gateway (chat, knooppunten, configuratie)
title: Bedienings-UI
x-i18n:
generated_at: "2026-05-02T20:59:36Z"
generated_at: "2026-05-02T23:39:09Z"
model: gpt-5.5
provider: openai
source_hash: 88959ccf435b31015039bf28c3043023d99f0b953a1489986ab2d0cbd261771c
source_hash: 50bef807915f27406e19f1c6ca7d839a610d79ba79da85d7a78523400cbf9208
source_path: web/control-ui.md
workflow: 16
---
De Control UI is een kleine **Vite + Lit** single-page app die door de Gateway wordt geserveerd:
De bedieningsinterface is een kleine **Vite + Lit** single-page app die door de Gateway wordt aangeboden:
- standaard: `http://<host>:18789/`
- optioneel voorvoegsel: stel `gateway.controlUi.basePath` in (bijv. `/openclaw`)
@ -29,23 +29,23 @@ Als de Gateway op dezelfde computer draait, open dan:
Als de pagina niet laadt, start dan eerst de Gateway: `openclaw gateway`.
Auth wordt tijdens de WebSocket-handshake geleverd via:
Authenticatie wordt tijdens de WebSocket-handshake geleverd via:
- `connect.params.auth.token`
- `connect.params.auth.password`
- Tailscale Serve-identiteitsheaders wanneer `gateway.auth.allowTailscale: true`
- trusted-proxy-identiteitsheaders wanneer `gateway.auth.mode: "trusted-proxy"`
- vertrouwde-proxy-identiteitsheaders wanneer `gateway.auth.mode: "trusted-proxy"`
Het instellingenpaneel van het dashboard bewaart een token voor de huidige browsertabsessie en de geselecteerde gateway-URL; wachtwoorden worden niet bewaard. Onboarding genereert meestal bij de eerste verbinding een gateway-token voor shared-secret-auth, maar wachtwoord-auth werkt ook wanneer `gateway.auth.mode` `"password"` is.
Het instellingenpaneel van het dashboard bewaart een token voor de huidige browsertabsessie en de geselecteerde gateway-URL; wachtwoorden worden niet bewaard. Onboarding genereert meestal bij de eerste verbinding een gateway-token voor authenticatie met een gedeeld geheim, maar wachtwoordauthenticatie werkt ook wanneer `gateway.auth.mode` `"password"` is.
## Apparaat koppelen (eerste verbinding)
## Apparaatkoppeling (eerste verbinding)
Wanneer je vanaf een nieuwe browser of nieuw apparaat verbinding maakt met de Control UI, vereist de Gateway meestal een **eenmalige koppelingsgoedkeuring**. Dit is een beveiligingsmaatregel om ongeautoriseerde toegang te voorkomen.
Wanneer je vanaf een nieuwe browser of nieuw apparaat verbinding maakt met de bedieningsinterface, vereist de Gateway meestal een **eenmalige koppelingsgoedkeuring**. Dit is een beveiligingsmaatregel om ongeautoriseerde toegang te voorkomen.
**Wat je ziet:** "disconnected (1008): pairing required"
<Steps>
<Step title="Openstaande verzoeken weergeven">
<Step title="Openstaande aanvragen weergeven">
```bash
openclaw devices list
```
@ -57,96 +57,97 @@ Wanneer je vanaf een nieuwe browser of nieuw apparaat verbinding maakt met de Co
</Step>
</Steps>
Als de browser opnieuw probeert te koppelen met gewijzigde auth-gegevens (rol/scopes/openbare sleutel), wordt het vorige openstaande verzoek vervangen en wordt een nieuwe `requestId` aangemaakt. Voer vóór goedkeuring opnieuw `openclaw devices list` uit.
Als de browser opnieuw probeert te koppelen met gewijzigde authenticatiegegevens (rol/scopes/openbare sleutel), wordt de vorige openstaande aanvraag vervangen en wordt er een nieuwe `requestId` aangemaakt. Voer vóór goedkeuring opnieuw `openclaw devices list` uit.
Als de browser al is gekoppeld en je deze wijzigt van leestoegang naar schrijf-/beheertoegang, wordt dit behandeld als een goedkeuringsupgrade, niet als een stille herverbinding. OpenClaw houdt de oude goedkeuring actief, blokkeert de bredere herverbinding en vraagt je om de nieuwe set scopes expliciet goed te keuren.
Na goedkeuring wordt het apparaat onthouden en is er geen nieuwe goedkeuring nodig, tenzij je het intrekt met `openclaw devices revoke --device <id> --role <role>`. Zie [Devices CLI](/nl/cli/devices) voor tokenrotatie en intrekking.
Na goedkeuring wordt het apparaat onthouden en is geen nieuwe goedkeuring nodig, tenzij je het intrekt met `openclaw devices revoke --device <id> --role <role>`. Zie [Apparaten-CLI](/nl/cli/devices) voor tokenrotatie en intrekking.
<Note>
- Directe local loopback-browserverbindingen (`127.0.0.1` / `localhost`) worden automatisch goedgekeurd.
- Tailscale Serve kan de koppelingsronde overslaan voor Control UI-operatorsessies wanneer `gateway.auth.allowTailscale: true`, de Tailscale-identiteit is geverifieerd en de browser zijn apparaatidentiteit presenteert.
- Directe Tailnet-binds, LAN-browserverbindingen en browserprofielen zonder apparaatidentiteit vereisen nog steeds expliciete goedkeuring.
- Elk browserprofiel genereert een unieke apparaat-ID, dus wisselen van browser of het wissen van browsergegevens vereist opnieuw koppelen.
- Directe browserverbindingen via local loopback (`127.0.0.1` / `localhost`) worden automatisch goedgekeurd.
- Tailscale Serve kan de koppelingsronde overslaan voor operatorsessies van de bedieningsinterface wanneer `gateway.auth.allowTailscale: true`, de Tailscale-identiteit wordt geverifieerd en de browser zijn apparaatidentiteit presenteert.
- Directe Tailnet-bindings, browserverbindingen via LAN en browserprofielen zonder apparaatidentiteit vereisen nog steeds expliciete goedkeuring.
- Elk browserprofiel genereert een unieke apparaat-ID, dus overschakelen naar een andere browser of het wissen van browsergegevens vereist opnieuw koppelen.
</Note>
## Persoonlijke identiteit (browser-lokaal)
## Persoonlijke identiteit (browserlokaal)
De Control UI ondersteunt een persoonlijke identiteit per browser (weergavenaam en avatar) die wordt gekoppeld aan uitgaande berichten voor toeschrijving in gedeelde sessies. Deze leeft in browseropslag, is beperkt tot het huidige browserprofiel en wordt niet gesynchroniseerd naar andere apparaten of server-side bewaard buiten de normale metadata voor auteurschap van transcriptberichten die je daadwerkelijk verzendt. Het wissen van sitegegevens of wisselen van browser zet deze terug naar leeg.
De bedieningsinterface ondersteunt een persoonlijke identiteit per browser (weergavenaam en avatar) die aan uitgaande berichten wordt gekoppeld voor toeschrijving in gedeelde sessies. Deze staat in browseropslag, is beperkt tot het huidige browserprofiel en wordt niet gesynchroniseerd naar andere apparaten of server-side bewaard buiten de normale metadata voor auteurschap van transcripten op berichten die je daadwerkelijk verzendt. Het wissen van sitegegevens of wisselen van browser zet deze terug naar leeg.
Hetzelfde browser-lokale patroon geldt voor de override van de assistentavatar. Geüploade assistentavatars leggen de door de gateway opgeloste identiteit alleen over de lokale browser heen en gaan nooit via `config.patch` heen en terug. Het gedeelde configuratieveld `ui.assistant.avatar` blijft beschikbaar voor niet-UI-clients die het veld rechtstreeks schrijven (zoals scripted gateways of aangepaste dashboards).
Hetzelfde browserlokale patroon geldt voor de overschrijving van de assistent-avatar. Geüploade assistent-avatars leggen alleen in de lokale browser een laag over de door de gateway opgeloste identiteit en maken nooit een rondgang via `config.patch`. Het gedeelde configuratieveld `ui.assistant.avatar` blijft beschikbaar voor niet-UI-clients die het veld rechtstreeks schrijven (zoals gescripte gateways of aangepaste dashboards).
## Runtime-configuratie-eindpunt
## Eindpunt voor runtimeconfiguratie
De Control UI haalt zijn runtime-instellingen op uit `/__openclaw/control-ui-config.json`. Dat eindpunt wordt beschermd door dezelfde gateway-auth als de rest van het HTTP-oppervlak: niet-geauthenticeerde browsers kunnen het niet ophalen, en een succesvolle fetch vereist een al geldig gateway-token/wachtwoord, Tailscale Serve-identiteit of een trusted-proxy-identiteit.
De bedieningsinterface haalt zijn runtime-instellingen op uit `/__openclaw/control-ui-config.json`. Dat eindpunt wordt afgeschermd door dezelfde gateway-authenticatie als de rest van het HTTP-oppervlak: niet-geauthenticeerde browsers kunnen het niet ophalen, en een succesvolle ophaalactie vereist een al geldig gateway-token/-wachtwoord, Tailscale Serve-identiteit of vertrouwde-proxy-identiteit.
## Taalondersteuning
De Control UI kan zichzelf bij de eerste laadbeurt lokaliseren op basis van je browserlocale. Om dit later te overschrijven, open je **Overview -> Gateway Access -> Language**. De locale-kiezer staat in de Gateway Access-kaart, niet onder Appearance.
De bedieningsinterface kan zichzelf bij de eerste laadactie lokaliseren op basis van je browserlocale. Om dit later te overschrijven, open je **Overzicht -> Gatewaytoegang -> Taal**. De locale-kiezer staat in de kaart Gatewaytoegang, niet onder Uiterlijk.
- Ondersteunde locales: `en`, `zh-CN`, `zh-TW`, `pt-BR`, `de`, `es`, `ja-JP`, `ko`, `fr`, `ar`, `it`, `tr`, `uk`, `id`, `pl`, `th`, `vi`, `nl`, `fa`
- Niet-Engelse vertalingen worden lazy-loaded in de browser.
- De geselecteerde locale wordt opgeslagen in browseropslag en opnieuw gebruikt bij toekomstige bezoeken.
- Ontbrekende vertaalsleutels vallen terug op Engels.
Documentatievertalingen worden gegenereerd voor dezelfde niet-Engelse localeset, maar de ingebouwde Mintlify-taalkiezer van de documentatiesite is beperkt tot de localecodes die Mintlify accepteert. Thaise (`th`) en Perzische (`fa`) documentatie wordt nog steeds gegenereerd in de publicatierepo; deze verschijnt mogelijk pas in die kiezer wanneer Mintlify die codes ondersteunt.
Docs-vertalingen worden gegenereerd voor dezelfde set niet-Engelse locales, maar de ingebouwde Mintlify-taalkiezer van de docs-site is beperkt tot de locale-codes die Mintlify accepteert. Thaise (`th`) en Perzische (`fa`) docs worden nog steeds gegenereerd in de publish-repo; ze verschijnen mogelijk pas in die kiezer wanneer Mintlify die codes ondersteunt.
## Weergavethema's
## Uiterlijksthema's
Het Appearance-paneel behoudt de ingebouwde thema's Claw, Knot en Dash, plus één browser-lokaal tweakcn-importslot. Om een thema te importeren, open je [tweakcn themes](https://tweakcn.com/themes), kies of maak je een thema, klik je op **Share** en plak je de gekopieerde themalink in Appearance. De importer accepteert ook `https://tweakcn.com/r/themes/<id>`-registry-URL's, editor-URL's zoals `https://tweakcn.com/editor/theme?theme=amethyst-haze`, relatieve `/themes/<id>`-paden, ruwe thema-ID's en standaardthemanamen zoals `amethyst-haze`.
Het paneel Uiterlijk behoudt de ingebouwde thema's Claw, Knot en Dash, plus één browserlokale tweakcn-importslot. Om een thema te importeren, open je [tweakcn-thema's](https://tweakcn.com/themes), kies of maak je een thema, klik je op **Delen** en plak je de gekopieerde themalink in Uiterlijk. De importer accepteert ook `https://tweakcn.com/r/themes/<id>`-register-URL's, editor-URL's zoals `https://tweakcn.com/editor/theme?theme=amethyst-haze`, relatieve `/themes/<id>`-paden, ruwe thema-ID's en standaardthemanamen zoals `amethyst-haze`.
Geïmporteerde thema's worden alleen opgeslagen in het huidige browserprofiel. Ze worden niet naar gateway-configuratie geschreven en synchroniseren niet tussen apparaten. Het vervangen van het geïmporteerde thema werkt het ene lokale slot bij; het wissen ervan schakelt het actieve thema terug naar Claw als het geïmporteerde thema was geselecteerd.
Geïmporteerde thema's worden alleen in het huidige browserprofiel opgeslagen. Ze worden niet naar gateway-configuratie geschreven en synchroniseren niet tussen apparaten. Het vervangen van het geïmporteerde thema werkt de ene lokale slot bij; het wissen ervan schakelt het actieve thema terug naar Claw als het geïmporteerde thema was geselecteerd.
## Wat het kan doen (vandaag)
<AccordionGroup>
<Accordion title="Chatten en praten">
<Accordion title="Chat en spraak">
- Chat met het model via Gateway WS (`chat.history`, `chat.send`, `chat.abort`, `chat.inject`).
- Praat via realtime browsersessies. OpenAI gebruikt directe WebRTC, Google Live gebruikt een beperkt eenmalig browsertoken via WebSocket, en backend-only realtime spraakplugins gebruiken het Gateway-relaytransport. De relay houdt providerreferenties op de Gateway terwijl de browser microfoon-PCM streamt via `talk.realtime.relay*`-RPC's en `openclaw_agent_consult`-toolaanroepen terugstuurt via `chat.send` voor het grotere geconfigureerde OpenClaw-model.
- Stream toolaanroepen + live tooluitvoerkaarten in Chat (agent-events).
- Dicteer in de Chat-composer met server-side STT (`chat.transcribeAudio`). De browser neemt een korte microfoonclip op en stuurt die naar de Gateway, die de geconfigureerde transcriptiepijplijn `tools.media.audio` uitvoert en concepttekst teruggeeft zonder providerreferenties aan de browser bloot te stellen.
- Praat via realtime browsersessies. OpenAI gebruikt directe WebRTC, Google Live gebruikt een beperkte eenmalige browsertoken via WebSocket, en backend-only realtime spraakplugins gebruiken de Gateway-relaytransportlaag. De relay houdt providerreferenties op de Gateway terwijl de browser microfoon-PCM streamt via `talk.realtime.relay*`-RPC's en `openclaw_agent_consult`-toolcalls terugstuurt via `chat.send` voor het grotere geconfigureerde OpenClaw-model.
- Stream toolcalls + live tooluitvoerkaarten in Chat (agentevents).
</Accordion>
<Accordion title="Kanalen, instanties, sessies, dromen">
- Kanalen: status van ingebouwde plus gebundelde/externe pluginkanalen, QR-login en configuratie per kanaal (`channels.status`, `web.login.*`, `config.patch`).
- Instanties: aanwezigheidslijst + vernieuwen (`system-presence`).
- Sessies: lijst + overrides per sessie voor model/thinking/fast/verbose/trace/reasoning (`sessions.list`, `sessions.patch`).
- Dromen: dreaming-status, in-/uitschakelschakelaar en Dream Diary-lezer (`doctor.memory.status`, `doctor.memory.dreamDiary`, `config.patch`).
- Kanalen: ingebouwde plus gebundelde/externe Plugin-kanalenstatus, QR-login en configuratie per kanaal (`channels.status`, `web.login.*`, `config.patch`).
- Instanties: aanwezigheidslijst + verversen (`system-presence`).
- Sessies: lijst + overrides per sessie voor model/denken/snel/uitgebreid/trace/redenering (`sessions.list`, `sessions.patch`).
- Dromen: Dreaming-status, schakelaar voor inschakelen/uitschakelen en Dream Diary-lezer (`doctor.memory.status`, `doctor.memory.dreamDiary`, `config.patch`).
</Accordion>
<Accordion title="Cron, Skills, nodes, exec-goedkeuringen">
- Cron-taken: weergeven/toevoegen/bewerken/uitvoeren/inschakelen/uitschakelen + uitvoergeschiedenis (`cron.*`).
<Accordion title="Cron, Skills, Nodes, exec-goedkeuringen">
- Cron-taken: weergeven/toevoegen/bewerken/uitvoeren/inschakelen/uitschakelen + uitvoeringsgeschiedenis (`cron.*`).
- Skills: status, inschakelen/uitschakelen, installeren, API-sleutelupdates (`skills.*`).
- Nodes: lijst + caps (`node.list`).
- Exec-goedkeuringen: allowlists voor gateway of node bewerken + vraagbeleid voor `exec host=gateway/node` (`exec.approvals.*`).
- Nodes: lijst + mogelijkheden (`node.list`).
- Exec-goedkeuringen: allowlists voor gateway of Node bewerken + vraagbeleid voor `exec host=gateway/node` (`exec.approvals.*`).
</Accordion>
<Accordion title="Configuratie">
- Bekijk/bewerk `~/.openclaw/openclaw.json` (`config.get`, `config.set`).
- Toepassen + herstarten met validatie (`config.apply`) en de laatst actieve sessie wekken.
- Schrijfbewerkingen bevatten een base-hash-bescherming om te voorkomen dat gelijktijdige bewerkingen worden overschreven.
- Schrijfbewerkingen (`config.set`/`config.apply`/`config.patch`) voeren vooraf actieve SecretRef-resolutie uit voor refs in de ingediende configuratiepayload; niet-opgeloste actieve ingediende refs worden vóór het schrijven geweigerd.
- Schema + formulierweergave (`config.schema` / `config.schema.lookup`, inclusief veld `title` / `description`, gematchte UI-hints, samenvattingen van directe children, documentatiemetadata op geneste object-/wildcard-/array-/composition-nodes, plus plugin- en kanaalschema's wanneer beschikbaar); de Raw JSON-editor is alleen beschikbaar wanneer de snapshot een veilige raw round-trip heeft.
- Als een snapshot raw tekst niet veilig heen en terug kan verwerken, dwingt Control UI Form-modus af en schakelt Raw-modus uit voor die snapshot.
- Raw JSON-editor "Reset to saved" behoudt de raw-auteursvorm (opmaak, comments, `$include`-layout) in plaats van een afgevlakte snapshot opnieuw te renderen, zodat externe bewerkingen een reset overleven wanneer de snapshot veilig heen en terug kan.
- Gestructureerde SecretRef-objectwaarden worden read-only weergegeven in tekstinvoer van formulieren om onbedoelde corruptie van object naar string te voorkomen.
- Pas toe + herstart met validatie (`config.apply`) en wek de laatst actieve sessie.
- Schrijfacties bevatten een base-hash-bescherming om te voorkomen dat gelijktijdige bewerkingen worden overschreven.
- Schrijfacties (`config.set`/`config.apply`/`config.patch`) doen een preflight van actieve SecretRef-resolutie voor refs in de ingediende configuratiepayload; onopgeloste actieve ingediende refs worden vóór schrijven geweigerd.
- Schema + formulierweergave (`config.schema` / `config.schema.lookup`, inclusief veld `title` / `description`, overeenkomende UI-hints, directe samenvattingen van onderliggende items, docs-metadata op geneste object-/wildcard-/array-/compositienodes, plus Plugin- en kanaalschema's indien beschikbaar); de Raw JSON-editor is alleen beschikbaar wanneer de snapshot een veilige ruwe rondgang heeft.
- Als een snapshot ruwe tekst niet veilig kan rondreizen, dwingt de bedieningsinterface de formuliermodus af en schakelt Raw-modus uit voor die snapshot.
- Raw JSON-editor "Reset naar opgeslagen" behoudt de ruwe, door de auteur gemaakte vorm (opmaak, opmerkingen, `$include`-layout) in plaats van een afgevlakte snapshot opnieuw te renderen, zodat externe bewerkingen een reset overleven wanneer de snapshot veilig kan rondreizen.
- Gestructureerde SecretRef-objectwaarden worden alleen-lezen weergegeven in tekstinvoervelden van formulieren om onbedoelde corruptie van object naar string te voorkomen.
</Accordion>
<Accordion title="Debug, logs, update">
- Debug: snapshots van status/health/models + eventlog + handmatige RPC-aanroepen (`status`, `health`, `models.list`).
- Logs: live tail van gateway-bestandslogs met filter/export (`logs.tail`).
- Update: voer een package-/git-update + herstart uit (`update.run`) met een herstartrapport en poll daarna `update.status` na herverbinding om de draaiende gateway-versie te verifiëren.
- Debug: snapshots van status/gezondheid/modellen + eventlog + handmatige RPC-aanroepen (`status`, `health`, `models.list`).
- Logs: live tail van gatewaybestandslogs met filter/export (`logs.tail`).
- Update: voer een pakket-/git-update + herstart uit (`update.run`) met een herstartrapport en poll daarna `update.status` na herverbinding om de draaiende gatewayversie te verifiëren.
</Accordion>
<Accordion title="Notities bij het Cron-takenpaneel">
- Voor geïsoleerde taken is bezorging standaard ingesteld op samenvatting aankondigen. Je kunt overschakelen naar geen als je alleen interne runs wilt.
<Accordion title="Notities bij het paneel Cron-taken">
- Voor geïsoleerde taken is de standaardlevering het aankondigen van een samenvatting. Je kunt overschakelen naar geen als je alleen interne runs wilt.
- Kanaal-/doelvelden verschijnen wanneer aankondigen is geselecteerd.
- Webhook-modus gebruikt `delivery.mode = "webhook"` met `delivery.to` ingesteld op een geldige HTTP(S)-webhook-URL.
- Voor hoofdsessietaken zijn webhook- en geen-bezorgmodi beschikbaar.
- Geavanceerde bewerkingsbediening bevat verwijderen-na-run, agent-override wissen, exacte/gespreide cron-opties, overrides voor agentmodel/thinking en best-effort-bezorgschakelaars.
- Formuliervalidatie is inline met fouten op veldniveau; ongeldige waarden schakelen de opslagknop uit totdat ze zijn opgelost.
- Stel `cron.webhookToken` in om een dedicated bearer-token te verzenden; als dit wordt weggelaten, wordt de webhook zonder auth-header verzonden.
- Verouderde fallback: opgeslagen legacy-taken met `notify: true` kunnen nog steeds `cron.webhook` gebruiken totdat ze zijn gemigreerd.
- Webhook-modus gebruikt `delivery.mode = "webhook"` met `delivery.to` ingesteld op een geldige HTTP(S)-Webhook-URL.
- Voor hoofdsessietaken zijn Webhook- en geen-leveringsmodi beschikbaar.
- Geavanceerde bewerkingsbesturingselementen omvatten verwijderen-na-uitvoering, agentoverride wissen, Cron exact-/spreidingsopties, overrides voor agentmodel/denken en best-effort-leveringsschakelaars.
- Formuliervalidatie is inline met fouten op veldniveau; ongeldige waarden schakelen de opslagknop uit tot ze zijn hersteld.
- Stel `cron.webhookToken` in om een speciale bearer-token te verzenden; indien weggelaten wordt de Webhook zonder auth-header verzonden.
- Verouderde fallback: opgeslagen legacytaken met `notify: true` kunnen nog steeds `cron.webhook` gebruiken tot ze zijn gemigreerd.
</Accordion>
</AccordionGroup>
@ -154,56 +155,57 @@ Geïmporteerde thema's worden alleen opgeslagen in het huidige browserprofiel. Z
## Chatgedrag
<AccordionGroup>
<Accordion title="Send and history semantics">
- `chat.send` is **niet-blokkerend**: bevestigt onmiddellijk met `{ runId, status: "started" }` en de respons wordt gestreamd via `chat`-events.
<Accordion title="Verzend- en geschiedenissemantiek">
- `chat.send` is **niet-blokkerend**: het bevestigt meteen met `{ runId, status: "started" }` en de reactie streamt via `chat`-events.
- `chat.transcribeAudio` is een eenmalige dicteerhelper voor Chat-concepten. Het accepteert door de browser opgenomen base64-audio, houdt uploads onder de Gateway WebSocket-framegrens, schrijft een tijdelijk lokaal bestand, voert audio-transcriptie met mediabegrip uit met de actieve Gateway-configuratie, retourneert `{ text, provider, model }` en verwijdert het tijdelijke bestand. Het maakt geen agent-run aan en staat los van realtime Talk.
- Chat-uploads accepteren afbeeldingen plus niet-videobestanden. Afbeeldingen behouden het native afbeeldingspad; andere bestanden worden opgeslagen als beheerde media en in de geschiedenis getoond als bijlagelinks.
- Opnieuw verzenden met dezelfde `idempotencyKey` retourneert `{ status: "in_flight" }` zolang de uitvoering loopt, en `{ status: "ok" }` na voltooiing.
- `chat.history`-responses zijn in grootte begrensd voor UI-veiligheid. Wanneer transcriptvermeldingen te groot zijn, kan de Gateway lange tekstvelden inkorten, zware metadatablokken weglaten en te grote berichten vervangen door een placeholder (`[chat.history omitted: message too large]`).
- Door de assistent gegenereerde afbeeldingen worden bewaard als beheerde mediareferenties en teruggegeven via geauthenticeerde Gateway-media-URL's, zodat herladen niet afhankelijk is van ruwe base64-afbeeldingspayloads die in de chatgeschiedenisresponse blijven staan.
- `chat.history` verwijdert ook inline richtlijntags die alleen voor weergave bedoeld zijn uit zichtbare assistenttekst (bijvoorbeeld `[[reply_to_*]]` en `[[audio_as_voice]]`), XML-payloads van tool-calls in platte tekst (waaronder `<tool_call>...</tool_call>`, `<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`, `<function_calls>...</function_calls>` en ingekorte tool-call-blokken), en gelekte ASCII-/volledige-breedte modelcontroletokens, en laat assistentvermeldingen weg waarvan de volledige zichtbare tekst alleen het exacte stille token `NO_REPLY` / `no_reply` is.
- Tijdens een actieve verzending en de uiteindelijke geschiedenisverversing houdt de chatweergave lokale optimistische gebruikers-/assistentberichten zichtbaar als `chat.history` kort een oudere snapshot retourneert; het canonieke transcript vervangt die lokale berichten zodra de Gateway-geschiedenis is bijgewerkt.
- `chat.inject` voegt een assistentnotitie toe aan het sessietranscript en broadcast een `chat`-event voor updates die alleen voor de UI zijn bedoeld (geen agentuitvoering, geen kanaalbezorging).
- De model- en thinking-kiezers in de chatheader patchen de actieve sessie onmiddellijk via `sessions.patch`; het zijn persistente sessie-overschrijvingen, geen verzendopties voor slechts één beurt.
- Opnieuw verzenden met dezelfde `idempotencyKey` retourneert `{ status: "in_flight" }` tijdens het uitvoeren, en `{ status: "ok" }` na voltooiing.
- `chat.history`-reacties zijn begrensd in grootte voor UI-veiligheid. Wanneer transcriptitems te groot zijn, kan Gateway lange tekstvelden inkorten, zware metadatablokken weglaten en te grote berichten vervangen door een placeholder (`[chat.history omitted: message too large]`).
- Door de assistent gegenereerde afbeeldingen worden bewaard als beheerde mediareferenties en teruggeleverd via geverifieerde Gateway-media-URL's, zodat herladen niet afhankelijk is van ruwe base64-afbeeldingspayloads die in de chatgeschiedenisreactie blijven staan.
- `chat.history` verwijdert ook uitsluitend voor weergave bedoelde inline-directivetags uit zichtbare assistenttekst (bijvoorbeeld `[[reply_to_*]]` en `[[audio_as_voice]]`), plattetekst-XML-payloads voor tool-calls (inclusief `<tool_call>...</tool_call>`, `<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`, `<function_calls>...</function_calls>` en afgekorte tool-call-blokken), en gelekte ASCII-/full-width-modelcontroletokens, en laat assistentitems weg waarvan de volledige zichtbare tekst alleen het exacte stille token `NO_REPLY` / `no_reply` is.
- Tijdens een actieve verzending en de laatste verversing van de geschiedenis houdt de chatweergave lokale optimistische gebruikers-/assistentberichten zichtbaar als `chat.history` kortstondig een oudere snapshot retourneert; het canonieke transcript vervangt die lokale berichten zodra de Gateway-geschiedenis is bijgewerkt.
- `chat.inject` voegt een assistentnotitie toe aan het sessietranscript en broadcast een `chat`-event voor updates die alleen voor de UI zijn bedoeld (geen agent-run, geen kanaallevering).
- De model- en thinking-kiezers in de chatkop patchen de actieve sessie onmiddellijk via `sessions.patch`; het zijn persistente sessie-overschrijvingen, geen verzendopties die alleen voor één beurt gelden.
- `/new` typen in de Control UI maakt dezelfde nieuwe dashboardsessie aan als New Chat en schakelt ernaar over. `/reset` typen behoudt de expliciete in-place reset van de Gateway voor de huidige sessie.
- De chatmodelkiezer vraagt de geconfigureerde modelweergave van de Gateway op. Als `agents.defaults.models` aanwezig is, stuurt die allowlist de kiezer aan. Anders toont de kiezer expliciete `models.providers.*.models`-items plus providers met bruikbare auth. De volledige catalogus blijft beschikbaar via de debug-RPC `models.list` met `view: "all"`.
- Wanneer verse gebruiksrapporten van Gateway-sessies hoge contextdruk tonen, toont het chatcomposergebied een contextmelding en, bij aanbevolen compaction-niveaus, een compacte knop die het normale sessiecompaction-pad uitvoert. Verouderde tokensnapshots worden verborgen totdat de Gateway opnieuw vers gebruik rapporteert.
- De chatmodelkiezer vraagt de geconfigureerde modelweergave van de Gateway op. Als `agents.defaults.models` aanwezig is, stuurt die allowlist de kiezer aan. Anders toont de kiezer expliciete `models.providers.*.models`-items plus providers met bruikbare authenticatie. De volledige catalogus blijft beschikbaar via de debug-`models.list`-RPC met `view: "all"`.
- Wanneer rapporten over vers Gateway-sessieverbruik hoge contextdruk tonen, laat het chatcomposergebied een contextmelding zien en, bij aanbevolen Compaction-niveaus, een compacte knop die het normale sessie-Compaction-pad uitvoert. Verouderde tokensnapshots worden verborgen totdat de Gateway opnieuw vers verbruik rapporteert.
</Accordion>
<Accordion title="Talk mode (browser realtime)">
Talk-modus gebruikt een geregistreerde realtime spraakprovider. Configureer OpenAI met `talk.provider: "openai"` plus `talk.providers.openai.apiKey`, of configureer Google met `talk.provider: "google"` plus `talk.providers.google.apiKey`; realtime-providerconfiguratie voor Voice Call kan nog steeds als fallback worden hergebruikt. De browser ontvangt nooit een standaard provider-API-sleutel. OpenAI ontvangt een tijdelijke Realtime client secret voor WebRTC. Google Live ontvangt een eenmalig beperkt Live API-auth-token voor een browser-WebSocket-sessie, waarbij instructies en tooldeclaraties door de Gateway in het token zijn vergrendeld. Providers die alleen een backend realtime bridge aanbieden, draaien via het Gateway-relaytransport, zodat referenties en vendorsockets server-side blijven terwijl browseraudio via geauthenticeerde Gateway-RPC's loopt. De Realtime-sessieprompt wordt samengesteld door de Gateway; `talk.realtime.session` accepteert geen door de aanroeper aangeleverde instructie-overschrijvingen.
<Accordion title="Talk-modus (browser-realtime)">
Talk-modus gebruikt een geregistreerde realtime spraakprovider. Configureer OpenAI met `talk.provider: "openai"` plus `talk.providers.openai.apiKey`, of configureer Google met `talk.provider: "google"` plus `talk.providers.google.apiKey`; realtime providerconfiguratie voor Voice Call kan nog steeds worden hergebruikt als fallback. De browser ontvangt nooit een standaard provider-API-sleutel. OpenAI ontvangt een tijdelijke Realtime-clientsecret voor WebRTC. Google Live ontvangt een eenmalig beperkt Live API-authenticatietoken voor een browser-WebSocket-sessie, waarbij instructies en tooldeclaraties door de Gateway in het token zijn vastgezet. Providers die alleen een backend-realtimebridge aanbieden, lopen via het Gateway-relaytransport, zodat referenties en leverancierssockets server-side blijven terwijl browseraudio via geverifieerde Gateway-RPC's beweegt. De Realtime-sessieprompt wordt samengesteld door de Gateway; `talk.realtime.session` accepteert geen door de caller aangeleverde instructie-overschrijvingen.
In de chatcomposer is de Talk-bediening de golvenknop naast de microfoonknop voor dicteren. Wanneer Talk start, toont de composerstatusrij `Connecting Talk...`, daarna `Talk live` terwijl audio is verbonden, of `Asking OpenClaw...` terwijl een realtime tool-call het geconfigureerde grotere model raadpleegt via `chat.send`.
In de Chat-composer is de Talk-bediening de golvenknop naast de microfoondicteerknop. Wanneer Talk start, toont de statusrij van de composer `Connecting Talk...`, daarna `Talk live` terwijl audio is verbonden, of `Asking OpenClaw...` terwijl een realtime tool-call het geconfigureerde grotere model raadpleegt via `chat.send`.
Maintainer-live-smoke: `OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts` verifieert de OpenAI browser-WebRTC SDP-uitwisseling, de Google Live constrained-token browser-WebSocket-configuratie en de Gateway-relaybrowseradapter met nep-microfoonmedia. De opdracht print alleen providerstatus en logt geen geheimen.
Live rooktest voor maintainers: `OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts` verifieert de OpenAI browser-WebRTC-SDP-uitwisseling, de Google Live browser-WebSocket-setup met beperkt token, en de Gateway-relaybrowseradapter met nep-microfoonmedia. De opdracht drukt alleen providerstatus af en logt geen geheimen.
</Accordion>
<Accordion title="Stop and abort">
<Accordion title="Stoppen en afbreken">
- Klik op **Stop** (roept `chat.abort` aan).
- Terwijl een uitvoering actief is, worden normale vervolgberichten in de wachtrij geplaatst. Klik op **Steer** bij een bericht in de wachtrij om dat vervolgbericht in de lopende beurt te injecteren.
- Typ `/stop` (of zelfstandige afbreekzinnen zoals `stop`, `stop action`, `stop run`, `stop openclaw`, `please stop`) om out-of-band af te breken.
- `chat.abort` ondersteunt `{ sessionKey }` (geen `runId`) om alle actieve uitvoeringen voor die sessie af te breken.
- Terwijl een run actief is, worden normale vervolgberichten in de wachtrij gezet. Klik op **Steer** bij een bericht in de wachtrij om dat vervolgbericht in de lopende beurt te injecteren.
- Typ `/stop` (of losse afbreekzinnen zoals `stop`, `stop action`, `stop run`, `stop openclaw`, `please stop`) om out-of-band af te breken.
- `chat.abort` ondersteunt `{ sessionKey }` (geen `runId`) om alle actieve runs voor die sessie af te breken.
</Accordion>
<Accordion title="Abort partial retention">
- Wanneer een uitvoering wordt afgebroken, kan gedeeltelijke assistenttekst nog steeds in de UI worden getoond.
<Accordion title="Behoud van gedeeltelijke inhoud na afbreken">
- Wanneer een run wordt afgebroken, kan gedeeltelijke assistenttekst nog steeds in de UI worden getoond.
- Gateway bewaart afgebroken gedeeltelijke assistenttekst in de transcriptgeschiedenis wanneer gebufferde uitvoer bestaat.
- Bewaarde vermeldingen bevatten afbreekmetadata zodat transcriptconsumenten afgebroken gedeeltelijke uitvoer kunnen onderscheiden van normale voltooiingsuitvoer.
- Bewaarde items bevatten afbreekmetadata zodat transcriptconsumenten afgebroken gedeelten kunnen onderscheiden van normale voltooiingsuitvoer.
</Accordion>
</AccordionGroup>
## PWA-installatie en Web Push
## PWA-installatie en webpush
De Control UI levert een `manifest.webmanifest` en een serviceworker, zodat moderne browsers deze als zelfstandige PWA kunnen installeren. Met Web Push kan de Gateway de geïnstalleerde PWA wekken met meldingen, zelfs wanneer het tabblad of browservenster niet open is.
De Control UI levert een `manifest.webmanifest` en een serviceworker mee, zodat moderne browsers deze als zelfstandige PWA kunnen installeren. Web Push laat de Gateway de geïnstalleerde PWA wekken met meldingen, zelfs wanneer het tabblad of browservenster niet open is.
| Oppervlak | Wat het doet |
| Oppervlak | Wat het doet |
| ----------------------------------------------------- | ------------------------------------------------------------------ |
| `ui/public/manifest.webmanifest` | PWA-manifest. Browsers bieden "App installeren" aan zodra het bereikbaar is. |
| `ui/public/sw.js` | Serviceworker die `push`-events en klikken op meldingen afhandelt. |
| `push/vapid-keys.json` (onder de OpenClaw-statusmap) | Automatisch gegenereerd VAPID-sleutelpaar dat wordt gebruikt om Web Push-payloads te ondertekenen. |
| `push/web-push-subscriptions.json` | Bewaarde browserabonnementseindpunten. |
| `push/web-push-subscriptions.json` | Bewaarde browserabonnement-endpoints. |
Overschrijf het VAPID-sleutelpaar via env-vars op het Gateway-proces wanneer je sleutels wilt vastzetten (voor multi-host deployments, geheimrotatie of tests):
Overschrijf het VAPID-sleutelpaar via env-vars op het Gateway-proces wanneer je sleutels wilt vastzetten (voor multi-hostdeployments, geheimenrotatie of tests):
- `OPENCLAW_VAPID_PUBLIC_KEY`
- `OPENCLAW_VAPID_PRIVATE_KEY`
@ -211,25 +213,25 @@ Overschrijf het VAPID-sleutelpaar via env-vars op het Gateway-proces wanneer je
De Control UI gebruikt deze scope-gated Gateway-methoden om browserabonnementen te registreren en te testen:
- `push.web.vapidPublicKey` — haalt de actieve openbare VAPID-sleutel op.
- `push.web.vapidPublicKey` — haalt de actieve VAPID-public key op.
- `push.web.subscribe` — registreert een `endpoint` plus `keys.p256dh`/`keys.auth`.
- `push.web.unsubscribe` — verwijdert een geregistreerd eindpunt.
- `push.web.test` — verzendt een testmelding naar het abonnement van de aanroeper.
- `push.web.unsubscribe` — verwijdert een geregistreerd endpoint.
- `push.web.test` — verzendt een testmelding naar het abonnement van de caller.
<Note>
Web Push is onafhankelijk van het iOS APNS-relaypad (zie [Configuratie](/nl/gateway/configuration) voor relay-ondersteunde push) en de bestaande methode `push.test`, die gericht zijn op native mobiele koppeling.
Web Push staat los van het iOS APNS-relaypad (zie [Configuratie](/nl/gateway/configuration) voor relay-ondersteunde push) en de bestaande methode `push.test`, die native mobiele koppeling targeten.
</Note>
## Gehoste embeds
Assistentberichten kunnen gehoste webcontent inline renderen met de shortcode `[embed ...]`. Het iframe-sandboxbeleid wordt beheerd door `gateway.controlUi.embedSandbox`:
Assistentberichten kunnen gehoste webinhoud inline renderen met de `[embed ...]`-shortcode. Het iframe-sandboxbeleid wordt beheerd door `gateway.controlUi.embedSandbox`:
<Tabs>
<Tab title="strict">
Schakelt scriptuitvoering binnen gehoste embeds uit.
</Tab>
<Tab title="scripts (default)">
Staat interactieve embeds toe terwijl origin-isolatie behouden blijft; dit is de standaard en is meestal voldoende voor zelfstandige browsergames/widgets.
Staat interactieve embeds toe terwijl origin-isolatie behouden blijft; dit is de standaardwaarde en is meestal genoeg voor zelfstandige browsergames/widgets.
</Tab>
<Tab title="trusted">
Voegt `allow-same-origin` toe boven op `allow-scripts` voor documenten op dezelfde site die bewust sterkere privileges nodig hebben.
@ -249,14 +251,14 @@ Voorbeeld:
```
<Warning>
Gebruik `trusted` alleen wanneer het ingesloten document daadwerkelijk same-origin-gedrag nodig heeft. Voor de meeste door agents gegenereerde games en interactieve canvassen is `scripts` de veiligere keuze.
Gebruik `trusted` alleen wanneer het ingesloten document werkelijk same-origin-gedrag nodig heeft. Voor de meeste door agenten gegenereerde games en interactieve canvassen is `scripts` de veiligere keuze.
</Warning>
Absolute externe `http(s)`-embed-URL's blijven standaard geblokkeerd. Als je bewust wilt dat `[embed url="https://..."]` pagina's van derden laadt, stel dan `gateway.controlUi.allowExternalEmbedUrls: true` in.
## Breedte van chatberichten
Gegroepeerde chatberichten gebruiken een leesbare standaard maximale breedte. Deployments met brede monitoren kunnen dit overschrijven zonder gebundelde CSS te patchen door `gateway.controlUi.chatMessageMaxWidth` in te stellen:
Gegroepeerde chatberichten gebruiken een leesbare standaard maximum breedte. Deployments op brede monitors kunnen dit overschrijven zonder gebundelde CSS te patchen door `gateway.controlUi.chatMessageMaxWidth` in te stellen:
```json5
{
@ -273,8 +275,8 @@ De waarde wordt gevalideerd voordat deze de browser bereikt. Ondersteunde waarde
## Tailnet-toegang (aanbevolen)
<Tabs>
<Tab title="Integrated Tailscale Serve (preferred)">
Houd de Gateway op loopback en laat Tailscale Serve deze met HTTPS proxyen:
<Tab title="Geïntegreerde Tailscale Serve (voorkeur)">
Houd de Gateway op loopback en laat Tailscale Serve deze proxyen met HTTPS:
```bash
openclaw gateway --tailscale serve
@ -284,16 +286,16 @@ De waarde wordt gevalideerd voordat deze de browser bereikt. Ondersteunde waarde
- `https://<magicdns>/` (of je geconfigureerde `gateway.controlUi.basePath`)
Standaard kunnen Control UI-/WebSocket Serve-aanvragen authenticeren via Tailscale-identiteitsheaders (`tailscale-user-login`) wanneer `gateway.auth.allowTailscale` `true` is. OpenClaw verifieert de identiteit door het `x-forwarded-for`-adres op te lossen met `tailscale whois` en dit met de header te matchen, en accepteert deze alleen wanneer de aanvraag loopback bereikt met Tailscale's `x-forwarded-*`-headers. Voor Control UI-operatorsessies met browserapparaatidentiteit slaat dit geverifieerde Serve-pad ook de roundtrip voor apparaatkoppeling over; browsers zonder apparaat en verbindingen met node-rol volgen nog steeds de normale apparaatcontroles. Stel `gateway.auth.allowTailscale: false` in als je expliciete shared-secret-referenties wilt vereisen, zelfs voor Serve-verkeer. Gebruik dan `gateway.auth.mode: "token"` of `"password"`.
Standaard kunnen Control UI-/WebSocket Serve-verzoeken authenticeren via Tailscale-identiteitsheaders (`tailscale-user-login`) wanneer `gateway.auth.allowTailscale` `true` is. OpenClaw verifieert de identiteit door het `x-forwarded-for`-adres op te lossen met `tailscale whois` en dit te matchen met de header, en accepteert deze alleen wanneer het verzoek loopback bereikt met Tailscale's `x-forwarded-*`-headers. Voor Control UI-operatorsessies met browserapparaatidentiteit slaat dit geverifieerde Serve-pad ook de device-pairing-rondreis over; browsers zonder apparaat en node-role-verbindingen volgen nog steeds de normale apparaatcontroles. Stel `gateway.auth.allowTailscale: false` in als je expliciete gedeelde-geheime referenties wilt vereisen, zelfs voor Serve-verkeer. Gebruik daarna `gateway.auth.mode: "token"` of `"password"`.
Voor dat asynchrone Serve-identiteitspad worden mislukte auth-pogingen voor hetzelfde client-IP en dezelfde auth-scope geserialiseerd vóór rate-limit-writes. Gelijktijdige slechte nieuwe pogingen vanuit dezelfde browser kunnen daarom `retry later` tonen bij de tweede aanvraag in plaats van twee gewone mismatches die parallel racen.
Voor dat asynchrone Serve-identiteitspad worden mislukte authenticatiepogingen voor hetzelfde client-IP en dezelfde authenticatiescope geserialiseerd voordat rate-limit-writes plaatsvinden. Gelijktijdige foutieve retries vanuit dezelfde browser kunnen daarom `retry later` tonen op het tweede verzoek, in plaats van twee gewone mismatches die parallel racen.
<Warning>
Tokenloze Serve-auth gaat ervan uit dat de gatewayhost vertrouwd is. Als onvertrouwde lokale code op die host kan draaien, vereis dan token-/wachtwoordauthenticatie.
Tokenloze Serve-authenticatie gaat ervan uit dat de gatewayhost vertrouwd is. Vereis token-/wachtwoordauthenticatie als niet-vertrouwde lokale code op die host kan draaien.
</Warning>
</Tab>
<Tab title="Bind to tailnet + token">
<Tab title="Binden aan tailnet + token">
```bash
openclaw gateway --bind tailnet --token "$(openssl rand -hex 32)"
```
@ -302,20 +304,20 @@ De waarde wordt gevalideerd voordat deze de browser bereikt. Ondersteunde waarde
- `http://<tailscale-ip>:18789/` (of je geconfigureerde `gateway.controlUi.basePath`)
Plak het overeenkomende shared secret in de UI-instellingen (verzonden als `connect.params.auth.token` of `connect.params.auth.password`).
Plak het overeenkomende gedeelde geheim in de UI-instellingen (verzonden als `connect.params.auth.token` of `connect.params.auth.password`).
</Tab>
</Tabs>
## Onveilige HTTP
Als je het dashboard opent via gewone HTTP (`http://<lan-ip>` of `http://<tailscale-ip>`), draait de browser in een **niet-beveiligde context** en blokkeert deze WebCrypto. Standaard **blokkeert** OpenClaw Control UI-verbindingen zonder apparaatidentiteit.
Als je het dashboard opent via gewone HTTP (`http://<lan-ip>` of `http://<tailscale-ip>`), draait de browser in een **niet-beveiligde context** en blokkeert WebCrypto. Standaard **blokkeert** OpenClaw Control UI-verbindingen zonder apparaatidentiteit.
Gedocumenteerde uitzonderingen:
- alleen-localhost compatibiliteit met onveilige HTTP met `gateway.controlUi.allowInsecureAuth=true`
- geslaagde operator-Control UI-auth via `gateway.auth.mode: "trusted-proxy"`
- break-glass `gateway.controlUi.dangerouslyDisableDeviceAuth=true`
- localhost-only onveilige HTTP-compatibiliteit met `gateway.controlUi.allowInsecureAuth=true`
- geslaagde operatorauthenticatie voor de Control UI via `gateway.auth.mode: "trusted-proxy"`
- noodoptie `gateway.controlUi.dangerouslyDisableDeviceAuth=true`
**Aanbevolen oplossing:** gebruik HTTPS (Tailscale Serve) of open de UI lokaal:
@ -323,7 +325,7 @@ Gedocumenteerde uitzonderingen:
- `http://127.0.0.1:18789/` (op de gatewayhost)
<AccordionGroup>
<Accordion title="Gedrag van de insecure-auth-schakelaar">
<Accordion title="Gedrag van onveilige-authenticatieschakelaar">
```json5
{
gateway: {
@ -336,12 +338,12 @@ Gedocumenteerde uitzonderingen:
`allowInsecureAuth` is alleen een lokale compatibiliteitsschakelaar:
- Hiermee kunnen localhost Control UI-sessies doorgaan zonder apparaatidentiteit in niet-beveiligde HTTP-contexten.
- Hiermee worden koppelingscontroles niet omzeild.
- Hiermee worden vereisten voor apparaatidentiteit op afstand (niet-localhost) niet versoepeld.
- Hiermee kunnen localhost-Control UI-sessies doorgaan zonder apparaatidentiteit in niet-beveiligde HTTP-contexten.
- Het omzeilt geen koppelingscontroles.
- Het versoepelt de vereisten voor apparaatidentiteit op afstand (niet-localhost) niet.
</Accordion>
<Accordion title="Alleen voor noodgevallen">
<Accordion title="Alleen noodoptie">
```json5
{
gateway: {
@ -353,42 +355,42 @@ Gedocumenteerde uitzonderingen:
```
<Warning>
`dangerouslyDisableDeviceAuth` schakelt apparaatidentiteitscontroles van de Control UI uit en is een ernstige beveiligingsverlaging. Draai dit snel terug na gebruik in noodgevallen.
`dangerouslyDisableDeviceAuth` schakelt de apparaatidentiteitscontroles van de Control UI uit en is een ernstige beveiligingsverlaging. Draai dit snel terug na noodgebruik.
</Warning>
</Accordion>
<Accordion title="Opmerking over trusted-proxy">
- Geslaagde trusted-proxy-authenticatie kan **operator** Control UI-sessies toelaten zonder apparaatidentiteit.
- Dit geldt **niet** voor Control UI-sessies met node-rol.
- Reverse proxy's via loopback op dezelfde host voldoen nog steeds niet aan trusted-proxy-authenticatie; zie [Trusted proxy auth](/nl/gateway/trusted-proxy-auth).
- Geslaagde trusted-proxy-authenticatie kan **operator**-Control UI-sessies toelaten zonder apparaatidentiteit.
- Dit geldt **niet** voor Control UI-sessies met de noderol.
- Same-host local loopback reverse proxies voldoen nog steeds niet aan trusted-proxy-authenticatie; zie [Trusted proxy-authenticatie](/nl/gateway/trusted-proxy-auth).
</Accordion>
</AccordionGroup>
Zie [Tailscale](/nl/gateway/tailscale) voor begeleiding bij het instellen van HTTPS.
Zie [Tailscale](/nl/gateway/tailscale) voor richtlijnen voor HTTPS-configuratie.
## Contentbeveiligingsbeleid
## Content security policy
De Control UI wordt geleverd met een strikt `img-src`-beleid: alleen assets van **dezelfde origin**, `data:`-URL's en lokaal gegenereerde `blob:`-URL's zijn toegestaan. Externe `http(s)`- en protocolrelatieve afbeeldings-URL's worden door de browser geweigerd en veroorzaken geen netwerkverzoeken.
De Control UI wordt geleverd met een strikt `img-src`-beleid: alleen assets van **dezelfde oorsprong**, `data:`-URL's en lokaal gegenereerde `blob:`-URL's zijn toegestaan. Externe `http(s)`- en protocolrelatieve afbeeldings-URL's worden door de browser geweigerd en veroorzaken geen netwerkverzoeken.
Wat dit in de praktijk betekent:
- Avatars en afbeeldingen die onder relatieve paden worden aangeboden (bijvoorbeeld `/avatars/<id>`) worden nog steeds weergegeven, inclusief geauthenticeerde avatarroutes die de UI ophaalt en omzet naar lokale `blob:`-URL's.
- Inline `data:image/...`-URL's worden nog steeds weergegeven (handig voor payloads binnen het protocol).
- Lokale `blob:`-URL's die door de Control UI zijn gemaakt, worden nog steeds weergegeven.
- Externe avatar-URL's die door kanaalmetadata worden uitgegeven, worden verwijderd door de avatarhelpers van de Control UI en vervangen door het ingebouwde logo/de badge, zodat een gecompromitteerd of kwaadwillend kanaal geen willekeurige externe afbeeldingsverzoeken vanuit de browser van een operator kan afdwingen.
- Avatars en afbeeldingen die via relatieve paden worden geserveerd (bijvoorbeeld `/avatars/<id>`) worden nog steeds weergegeven, inclusief geauthenticeerde avatarroutes die de UI ophaalt en omzet in lokale `blob:`-URL's.
- Inline `data:image/...`-URL's worden nog steeds weergegeven (handig voor protocolpayloads).
- Lokale `blob:`-URL's die door de Control UI zijn aangemaakt, worden nog steeds weergegeven.
- Externe avatar-URL's die door kanaalmetadata worden uitgegeven, worden verwijderd door de avatarhelpers van de Control UI en vervangen door het ingebouwde logo/de ingebouwde badge, zodat een gecompromitteerd of kwaadaardig kanaal geen willekeurige externe afbeeldingsverzoeken vanuit een operatorbrowser kan afdwingen.
Je hoeft niets te wijzigen om dit gedrag te krijgen — het staat altijd aan en is niet configureerbaar.
U hoeft niets te wijzigen om dit gedrag te krijgen — het staat altijd aan en is niet configureerbaar.
## Authenticatie voor avatarroutes
## Authenticatie voor avatarroute
Wanneer Gateway-authenticatie is geconfigureerd, vereist het avatarendpoint van de Control UI hetzelfde gateway-token als de rest van de API:
Wanneer gatewayauthenticatie is geconfigureerd, vereist het avatareindpunt van de Control UI hetzelfde gatewaytoken als de rest van de API:
- `GET /avatar/<agentId>` retourneert de avatarafbeelding alleen aan geauthenticeerde callers. `GET /avatar/<agentId>?meta=1` retourneert de avatarmetadata volgens dezelfde regel.
- Niet-geauthenticeerde verzoeken naar een van beide routes worden geweigerd (net als bij de gerelateerde assistant-media-route). Dit voorkomt dat de avatarroute agentidentiteit lekt op hosts die verder beschermd zijn.
- De Control UI stuurt zelf het Gateway-token door als bearer-header bij het ophalen van avatars en gebruikt geauthenticeerde blob-URL's zodat de afbeelding nog steeds in dashboards wordt weergegeven.
- `GET /avatar/<agentId>` retourneert de avatarafbeelding alleen aan geauthenticeerde aanroepers. `GET /avatar/<agentId>?meta=1` retourneert de avatarmetadata volgens dezelfde regel.
- Niet-geauthenticeerde verzoeken naar beide routes worden geweigerd (net als bij de verwante assistant-media-route). Dit voorkomt dat de avatarroute agentidentiteit lekt op hosts die verder beschermd zijn.
- De Control UI zelf stuurt het gatewaytoken door als bearer-header bij het ophalen van avatars en gebruikt geauthenticeerde blob-URL's zodat de afbeelding nog steeds in dashboards wordt weergegeven.
Als je Gateway-authenticatie uitschakelt (niet aanbevolen op gedeelde hosts), wordt de avatarroute ook niet-geauthenticeerd, in lijn met de rest van de Gateway.
Als u gatewayauthenticatie uitschakelt (niet aanbevolen op gedeelde hosts), wordt de avatarroute ook niet-geauthenticeerd, in lijn met de rest van de gateway.
## De UI bouwen
@ -398,26 +400,26 @@ De Gateway serveert statische bestanden vanuit `dist/control-ui`. Bouw ze met:
pnpm ui:build
```
Optionele absolute basis (wanneer je vaste asset-URL's wilt):
Optionele absolute basis (wanneer u vaste asset-URL's wilt):
```bash
OPENCLAW_CONTROL_UI_BASE_PATH=/openclaw/ pnpm ui:build
```
Voor lokale ontwikkeling (aparte ontwikkelserver):
Voor lokale ontwikkeling (aparte devserver):
```bash
pnpm ui:dev
```
Wijs de UI vervolgens naar je Gateway WS-URL (bijv. `ws://127.0.0.1:18789`).
Wijs de UI vervolgens naar uw Gateway-WS-URL (bijv. `ws://127.0.0.1:18789`).
## Debuggen/testen: ontwikkelserver + externe Gateway
## Debuggen/testen: devserver + externe Gateway
De Control UI bestaat uit statische bestanden; het WebSocket-doel is configureerbaar en kan verschillen van de HTTP-origin. Dit is handig wanneer je de Vite-ontwikkelserver lokaal wilt gebruiken, maar de Gateway elders draait.
De Control UI bestaat uit statische bestanden; het WebSocket-doel is configureerbaar en kan verschillen van de HTTP-oorsprong. Dit is handig wanneer u de Vite-devserver lokaal wilt gebruiken, maar de Gateway elders draait.
<Steps>
<Step title="Start de UI-ontwikkelserver">
<Step title="Start de UI-devserver">
```bash
pnpm ui:dev
```
@ -439,16 +441,16 @@ De Control UI bestaat uit statische bestanden; het WebSocket-doel is configureer
<AccordionGroup>
<Accordion title="Opmerkingen">
- `gatewayUrl` wordt na het laden opgeslagen in localStorage en uit de URL verwijderd.
- Als je een volledig `ws://`- of `wss://`-endpoint via `gatewayUrl` doorgeeft, URL-encodeer dan de waarde van `gatewayUrl` zodat de browser de querystring correct parseert.
- `token` moet waar mogelijk via het URL-fragment (`#token=...`) worden doorgegeven. Fragmenten worden niet naar de server gestuurd, waardoor lekkage via requestlogs en Referer wordt voorkomen. Verouderde `?token=`-queryparameters worden voor compatibiliteit nog één keer geïmporteerd, maar alleen als fallback, en worden direct na bootstrap verwijderd.
- Als u een volledig `ws://`- of `wss://`-eindpunt via `gatewayUrl` doorgeeft, URL-encodeer dan de `gatewayUrl`-waarde zodat de browser de querystring correct parseert.
- `token` moet waar mogelijk via het URL-fragment (`#token=...`) worden doorgegeven. Fragmenten worden niet naar de server gestuurd, waardoor lekkage via verzoeklogs en Referer wordt vermeden. Verouderde `?token=`-queryparameters worden nog steeds eenmalig geïmporteerd voor compatibiliteit, maar alleen als fallback, en worden onmiddellijk na bootstrap verwijderd.
- `password` wordt alleen in het geheugen bewaard.
- Wanneer `gatewayUrl` is ingesteld, valt de UI niet terug op configuratie- of omgevingsreferenties. Geef `token` (of `password`) expliciet op. Ontbrekende expliciete referenties zijn een fout.
- Gebruik `wss://` wanneer de Gateway achter TLS staat (Tailscale Serve, HTTPS-proxy, enz.).
- `gatewayUrl` wordt alleen geaccepteerd in een venster op topniveau (niet embedded) om clickjacking te voorkomen.
- Niet-loopback Control UI-deployments moeten `gateway.controlUi.allowedOrigins` expliciet instellen (volledige origins). Dit omvat externe ontwikkelsetups.
- Het opstarten van de Gateway kan lokale origins zoals `http://localhost:<port>` en `http://127.0.0.1:<port>` initialiseren op basis van de effectieve runtime-bind en poort, maar externe browser-origins hebben nog steeds expliciete vermeldingen nodig.
- Gebruik `gateway.controlUi.allowedOrigins: ["*"]` niet, behalve voor strikt gecontroleerde lokale tests. Het betekent dat elke browser-origin wordt toegestaan, niet "match de host die ik gebruik."
- `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` schakelt fallbackmodus voor Host-header-origin in, maar dit is een gevaarlijke beveiligingsmodus.
- `gatewayUrl` wordt alleen geaccepteerd in een venster op topniveau (niet ingebed) om clickjacking te voorkomen.
- Niet-loopback Control UI-implementaties moeten `gateway.controlUi.allowedOrigins` expliciet instellen (volledige origins). Dit omvat externe devopstellingen.
- Bij het starten van de Gateway kunnen lokale origins zoals `http://localhost:<port>` en `http://127.0.0.1:<port>` worden ingevoerd op basis van de effectieve runtime-bind en -poort, maar externe browserorigins hebben nog steeds expliciete vermeldingen nodig.
- Gebruik `gateway.controlUi.allowedOrigins: ["*"]` niet, behalve voor strikt gecontroleerde lokale tests. Het betekent elke browserorigin toestaan, niet "match de host die ik gebruik."
- `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` schakelt de fallbackmodus voor Host-header-origin in, maar dit is een gevaarlijke beveiligingsmodus.
</Accordion>
</AccordionGroup>
@ -465,11 +467,11 @@ Voorbeeld:
}
```
Details voor het instellen van externe toegang: [Externe toegang](/nl/gateway/remote).
Details voor configuratie van externe toegang: [Externe toegang](/nl/gateway/remote).
## Gerelateerd
- [Dashboard](/nl/web/dashboard) — Gateway-dashboard
- [Health Checks](/nl/gateway/health) — Gateway-healthmonitoring
- [Dashboard](/nl/web/dashboard) — gatewaydashboard
- [Health Checks](/nl/gateway/health) — gatewaygezondheidsbewaking
- [TUI](/nl/web/tui) — terminalgebruikersinterface
- [WebChat](/nl/web/webchat) — browsergebaseerde chatinterface

75
docs/nl/web/webchat.md
View File

@ -1,71 +1,72 @@
---
read_when:
- WebChat-toegang debuggen of configureren
summary: Statische host voor Loopback WebChat en Gateway WS-gebruik voor chat-UI
summary: Statische host voor Loopback WebChat en Gateway-WS-gebruik voor de chat-UI
title: Webchat
x-i18n:
generated_at: "2026-05-02T11:31:40Z"
generated_at: "2026-05-02T23:39:02Z"
model: gpt-5.5
provider: openai
source_hash: fe6d3cb30ed18d651b0d0ca8fd188b47c5f1d186410ee340deb79315f194ed8d
source_hash: ad3a09c8962e3a6dda83716d319df7ba27e18105cee50721278b5cba0a85c52f
source_path: web/webchat.md
workflow: 16
---
Status: de macOS/iOS SwiftUI-chat-UI praat rechtstreeks met de Gateway WebSocket.
Status: de macOS/iOS SwiftUI-chat-UI communiceert rechtstreeks met de Gateway WebSocket.
## Wat het is
- Een native chat-UI voor de Gateway (geen ingebedde browser en geen lokale statische server).
- Een native chat-UI voor de gateway (geen ingesloten browser en geen lokale statische server).
- Gebruikt dezelfde sessies en routeringsregels als andere kanalen.
- Deterministische routering: antwoorden gaan altijd terug naar WebChat.
## Snel starten
1. Start de Gateway.
2. Open de WebChat-UI (macOS/iOS-app) of het chat-tabblad van de Control UI.
3. Zorg dat er een geldig authenticatiepad voor de Gateway is geconfigureerd (standaard shared-secret,
1. Start de gateway.
2. Open de WebChat-UI (macOS/iOS-app) of het chattabblad van de Control UI.
3. Zorg dat er een geldig gateway-authenticatiepad is geconfigureerd (standaard shared-secret,
zelfs op loopback).
## Hoe het werkt (gedrag)
- De UI maakt verbinding met de Gateway WebSocket en gebruikt `chat.history`, `chat.send` en `chat.inject`.
- De UI maakt verbinding met de Gateway WebSocket en gebruikt `chat.history`, `chat.send`, `chat.inject` en `chat.transcribeAudio`.
- `chat.history` is begrensd voor stabiliteit: Gateway kan lange tekstvelden inkorten, zware metadata weglaten en te grote items vervangen door `[chat.history omitted: message too large]`.
- `chat.history` volgt de actieve transcriptvertakking voor moderne sessiebestanden die alleen worden aangevuld, zodat verlaten herschrijfvertakkingen en vervangen promptkopieën niet in WebChat worden weergegeven.
- Control UI onthoudt de onderliggende Gateway `sessionId` die door `chat.history` wordt teruggegeven en neemt die op in vervolg-aanroepen naar `chat.send`, zodat opnieuw verbinden en pagina's verversen hetzelfde opgeslagen gesprek voortzetten, tenzij de gebruiker een sessie start of reset.
- Control UI voegt dubbele lopende verzendingen voor dezelfde sessie, hetzelfde bericht en dezelfde bijlagen samen voordat een nieuwe run-id voor `chat.send` wordt gegenereerd; de Gateway dedupliceert nog steeds herhaalde verzoeken die dezelfde idempotentiesleutel hergebruiken.
- `chat.history` wordt ook genormaliseerd voor weergave: runtime-only OpenClaw-context,
wrappers voor inkomende enveloppen, inline tags voor bezorgingsrichtlijnen
zoals `[[reply_to_*]]` en `[[audio_as_voice]]`, plain-text XML-payloads voor tool-aanroepen
(inclusief `<tool_call>...</tool_call>`,
- `chat.history` volgt de actieve transcriptvertakking voor moderne append-only sessiebestanden, zodat verlaten herschrijftakken en vervangen promptkopieën niet in WebChat worden weergegeven.
- Control UI onthoudt de onderliggende Gateway `sessionId` die door `chat.history` wordt geretourneerd en neemt die op in vervolgoproepen naar `chat.send`, zodat herverbindingen en paginavernieuwingen hetzelfde opgeslagen gesprek voortzetten, tenzij de gebruiker een sessie start of reset.
- Control UI voegt dubbele lopende inzendingen voor dezelfde sessie, hetzelfde bericht en dezelfde bijlagen samen voordat een nieuwe `chat.send`-run-id wordt gegenereerd; de Gateway dedupliceert nog steeds herhaalde verzoeken die dezelfde idempotentiesleutel hergebruiken.
- `chat.history` is ook genormaliseerd voor weergave: runtime-only OpenClaw-context,
inkomende envelope-wrappers, inline tags voor bezorginstructies
zoals `[[reply_to_*]]` en `[[audio_as_voice]]`, XML-payloads voor toolaanroepen in platte tekst
(waaronder `<tool_call>...</tool_call>`,
`<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`,
`<function_calls>...</function_calls>` en ingekorte tool-aanroepblokken), en
gelekte ASCII-/volledige-breedte modelbesturingstokens worden uit zichtbare tekst gestript,
en assistent-items waarvan de volledige zichtbare tekst alleen het exacte stille
`<function_calls>...</function_calls>` en afgekorte toolaanroepblokken), en
gelekte ASCII-/full-width modelcontroletokens worden uit zichtbare tekst verwijderd,
en assistentitems waarvan de volledige zichtbare tekst alleen het exacte stille
token `NO_REPLY` / `no_reply` is, worden weggelaten.
- Antwoordpayloads met reasoning-vlag (`isReasoning: true`) worden uitgesloten van WebChat-assistentcontent, transcript-replaytekst en audiocontentblokken, zodat thinking-only payloads niet verschijnen als zichtbare assistentberichten of afspeelbare audio.
- `chat.inject` voegt een assistentnotitie rechtstreeks aan het transcript toe en broadcast die naar de UI (geen agent-run).
- Antwoordpayloads met een redeneringsvlag (`isReasoning: true`) worden uitgesloten van WebChat-assistentcontent, tekst voor transcriptweergave en audiocontentblokken, zodat payloads die alleen denkinhoud bevatten niet verschijnen als zichtbare assistentberichten of afspeelbare audio.
- `chat.transcribeAudio` verzorgt server-side dicteren in de chatcomposer van de Control UI. De browser neemt microfoonaudio op, verstuurt die als base64 naar de Gateway, en de Gateway voert de geconfigureerde `tools.media.audio`-pipeline uit. Het geretourneerde transcript wordt in het concept ingevoegd; er wordt geen agentrun gestart totdat de gebruiker het verstuurt.
- `chat.inject` voegt een assistentnotitie rechtstreeks toe aan het transcript en zendt die uit naar de UI (geen agentrun).
- Afgebroken runs kunnen gedeeltelijke assistentuitvoer zichtbaar houden in de UI.
- Gateway bewaart afgebroken gedeeltelijke assistenttekst in de transcriptgeschiedenis wanneer gebufferde uitvoer bestaat, en markeert die items met afbreekmetadata.
- Geschiedenis wordt altijd opgehaald uit de Gateway (geen lokale bestandsbewaking).
- Als de Gateway onbereikbaar is, is WebChat alleen-lezen.
- Gateway bewaart afgebroken gedeeltelijke assistenttekst in de transcriptgeschiedenis wanneer er gebufferde uitvoer bestaat, en markeert die items met afbreekmetadata.
- Geschiedenis wordt altijd opgehaald uit de gateway (geen lokale bestandsbewaking).
- Als de gateway onbereikbaar is, is WebChat alleen-lezen.
## Tools-paneel voor Control UI-agents
## Toolspaneel voor Control UI-agents
- Het Tools-paneel van Control UI `/agents` heeft twee afzonderlijke weergaven:
- **Nu beschikbaar** gebruikt `tools.effective(sessionKey=...)` en toont wat de huidige
sessie daadwerkelijk tijdens runtime kan gebruiken, inclusief tools die eigendom zijn van core, plugins en kanalen.
- **Toolconfiguratie** gebruikt `tools.catalog` en blijft gericht op profielen, overrides en
sessie daadwerkelijk tijdens runtime kan gebruiken, inclusief tools die eigendom zijn van core, plugin en kanaal.
- **Toolconfiguratie** gebruikt `tools.catalog` en blijft gericht op profielen, overschrijvingen en
catalogussemantiek.
- Runtime-beschikbaarheid is sessiegebonden. Wisselen van sessie op dezelfde agent kan de
- Runtimebeschikbaarheid is sessiegebonden. Wisselen van sessie op dezelfde agent kan de
lijst **Nu beschikbaar** wijzigen.
- De configuratie-editor impliceert geen runtime-beschikbaarheid; effectieve toegang volgt nog steeds beleidsprioriteit
(`allow`/`deny`, overrides per agent en provider/kanaal).
- De configuratie-editor impliceert geen runtimebeschikbaarheid; effectieve toegang volgt nog steeds de beleidsprioriteit
(`allow`/`deny`, per-agent en provider-/kanaaloverschrijvingen).
## Extern gebruik
## Gebruik op afstand
- Externe modus tunnelt de Gateway WebSocket via SSH/Tailscale.
- Je hoeft geen afzonderlijke WebChat-server te draaien.
- Externe modus tunnelt de gateway WebSocket via SSH/Tailscale.
- Je hoeft geen aparte WebChat-server te draaien.
## Configuratiereferentie (WebChat)
@ -73,18 +74,18 @@ Volledige configuratie: [Configuratie](/nl/gateway/configuration)
WebChat-opties:
- `gateway.webchat.chatHistoryMaxChars`: maximaal aantal tekens voor tekstvelden in `chat.history`-antwoorden. Wanneer een transcriptitem deze limiet overschrijdt, kort Gateway lange tekstvelden in en kan te grote berichten vervangen door een placeholder. Per verzoek kan de client ook `maxChars` meesturen om deze standaardwaarde voor één `chat.history`-aanroep te overschrijven.
- `gateway.webchat.chatHistoryMaxChars`: maximum aantal tekens voor tekstvelden in `chat.history`-antwoorden. Wanneer een transcriptitem deze limiet overschrijdt, kort Gateway lange tekstvelden in en kan het te grote berichten vervangen door een placeholder. Per verzoek kan `maxChars` ook door de client worden verzonden om deze standaardwaarde voor één `chat.history`-aanroep te overschrijven.
Gerelateerde globale opties:
- `gateway.port`, `gateway.bind`: WebSocket-host/-poort.
- `gateway.auth.mode`, `gateway.auth.token`, `gateway.auth.password`:
shared-secret WebSocket-authenticatie.
- `gateway.auth.allowTailscale`: het chat-tabblad van de browser-Control UI kan Tailscale
- `gateway.auth.allowTailscale`: het chattabblad van de browser-Control UI kan Tailscale
Serve-identiteitsheaders gebruiken wanneer ingeschakeld.
- `gateway.auth.mode: "trusted-proxy"`: reverse-proxy-authenticatie voor browserclients achter een identiteitsbewuste **niet-loopback** proxybron (zie [Trusted Proxy Auth](/nl/gateway/trusted-proxy-auth)).
- `gateway.remote.url`, `gateway.remote.token`, `gateway.remote.password`: extern Gateway-doel.
- `session.*`: sessieopslag en standaardwaarden voor hoofdsleutel.
- `gateway.remote.url`, `gateway.remote.token`, `gateway.remote.password`: externe gatewaydoel.
- `session.*`: sessieopslag en standaardwaarden voor de hoofdsleutel.
## Gerelateerd