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-04-30 18:42:25 +00:00
parent 5a05b5e12c
commit 5779502f98
5 changed files with 741 additions and 736 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

318
docs/nl/ci.md
View File

@ -1,75 +1,75 @@
---
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 releasevalidatie-uitvoering of heruitvoering
summary: CI-taakgrafiek, scopecontroles, release-overkoepelingen en lokale opdrachtequivalenten
title: CI-pijplijn
- Je debugt een falende GitHub Actions-controle
- Je coördineert een releasevalidatierun of een herhaling daarvan
summary: CI-taakgrafiek, scopecontroles, release-overkoepelingen en equivalenten voor lokale opdrachten
title: CI-pipeline
x-i18n:
generated_at: "2026-04-30T09:35:01Z"
generated_at: "2026-04-30T18:38:52Z"
model: gpt-5.5
provider: openai
source_hash: a9c18f0801864ca1030aac9ea81117b011bd7936388984a1809ce3ae6e906e62
source_hash: a24afc27606ac7f4e9ead89acdd319bffa23336610f8a6cd8b576ea1a5b233dd
source_path: ci.md
workflow: 16
---
OpenClaw CI draait bij elke push naar `main` en elke pull request. De `preflight`-job classificeert de diff en schakelt dure lanes uit wanneer alleen niet-gerelateerde gebieden zijn gewijzigd. Handmatige `workflow_dispatch`-runs omzeilen smart scoping bewust en waaieren de volledige graph uit voor release candidates 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.
OpenClaw CI draait bij elke push naar `main` en elke pull request. De taak `preflight` 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 graaf uit voor releasekandidaten en brede validatie. Android-lanes blijven opt-in via `include_android`. Release-only Plugin-dekking staat in de afzonderlijke workflow [`Plugin Prerelease`](#plugin-prerelease) en draait alleen vanuit [`Volledige Releasevalidatie`](#full-release-validation) of een expliciete handmatige dispatch.
## Pipeline-overzicht
| Job | Doel | Wanneer die draait |
| Taak | Doel | Wanneer deze draait |
| -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- |
| `preflight` | Detecteert docs-only wijzigingen, gewijzigde scopes, gewijzigde extensies, en bouwt het CI-manifest | Altijd bij non-draft pushes en PR's |
| `security-scm-fast` | Detectie van private keys en workflow-audit via `zizmor` | Altijd bij non-draft pushes en PR's |
| `security-dependency-audit` | Productie-lockfile-audit zonder dependencies tegen npm-advisories | Altijd bij non-draft pushes en PR's |
| `security-fast` | Vereiste aggregate voor de snelle security-jobs | Altijd bij non-draft pushes en PR's |
| `check-dependencies` | Productie-Knip dependency-only pass plus de unused-file allowlist guard | Node-relevante wijzigingen |
| `build-artifacts` | Bouwt `dist/`, Control UI, built-artifact checks, en herbruikbare downstream artifacts | Node-relevante wijzigingen |
| `checks-fast-core` | Snelle Linux-correctnesslanes zoals bundled/plugin-contract/protocol-checks | Node-relevante wijzigingen |
| `checks-fast-contracts-channels` | Sharded kanaalcontract-checks met een stabiel aggregate check-resultaat | Node-relevante wijzigingen |
| `checks-node-core-test` | Core Node-testshards, exclusief kanaal-, bundled-, contract- en extensielanes | Node-relevante wijzigingen |
| `check` | Sharded equivalent van de belangrijkste lokale gate: prod-types, lint, guards, test-types, en strict smoke | Node-relevante wijzigingen |
| `check-additional` | Architectuur-, boundary-, extension-surface guards, package-boundary, en gateway-watch shards | Node-relevante wijzigingen |
| `build-smoke` | Built-CLI smoke tests en startup-memory smoke | Node-relevante wijzigingen |
| `checks` | Verifier voor built-artifact kanaaltests | Node-relevante wijzigingen |
| `preflight` | Detecteert docs-only wijzigingen, gewijzigde scopes, gewijzigde extensies en bouwt het CI-manifest | Altijd bij niet-draft pushes en PR's |
| `security-scm-fast` | Detectie van privésleutels en workflow-audit via `zizmor` | Altijd bij niet-draft pushes en PR's |
| `security-dependency-audit` | Dependency-free audit van productie-lockfiles tegen npm-adviezen | Altijd bij niet-draft pushes en PR's |
| `security-fast` | Vereiste aggregatie voor de snelle beveiligingstaken | Altijd bij niet-draft pushes en PR's |
| `check-dependencies` | Productie-Knip dependency-only pass plus de allowlist-guard voor ongebruikte bestanden | Node-relevante wijzigingen |
| `build-artifacts` | Bouwt `dist/`, Control UI, built-artifact-controles en herbruikbare downstream-artifacts | Node-relevante wijzigingen |
| `checks-fast-core` | Snelle Linux-correctheidslanes zoals bundled/plugin-contract/protocol-controles | Node-relevante wijzigingen |
| `checks-fast-contracts-channels` | Gesegmenteerde channel-contractcontroles met een stabiel geaggregeerd controleresultaat | Node-relevante wijzigingen |
| `checks-node-core-test` | Core Node-testshards, exclusief channel-, bundled-, contract- en extensielanes | Node-relevante wijzigingen |
| `check` | Gesegmenteerd equivalent van de lokale hoofdgate: productietypen, lint, guards, testtypen en strikte smoke | Node-relevante wijzigingen |
| `check-additional` | Architectuur-, grens-, extension-surface-guards, package-boundary- en gateway-watch-shards | Node-relevante wijzigingen |
| `build-smoke` | Built-CLI-smoketests en startup-memory-smoke | Node-relevante wijzigingen |
| `checks` | Verificatie voor built-artifact-channeltests | Node-relevante wijzigingen |
| `checks-node-compat-node22` | Node 22-compatibiliteitsbuild en smoke-lane | Handmatige CI-dispatch voor releases |
| `check-docs` | Docs-opmaak, lint, en broken-link checks | Docs gewijzigd |
| `skills-python` | Ruff + pytest voor Python-backed Skills | Python-skill-relevante wijzigingen |
| `checks-windows` | Windows-specifieke process/path-tests plus gedeelde runtime import specifier-regressies | Windows-relevante wijzigingen |
| `check-docs` | Docs-formattering, lint en controles op kapotte links | Docs gewijzigd |
| `skills-python` | Ruff + pytest voor Python-backed skills | Python-skill-relevante wijzigingen |
| `checks-windows` | Windows-specifieke proces-/padtests plus regressies in gedeelde runtime-importspecificaties | Windows-relevante wijzigingen |
| `macos-node` | macOS TypeScript-testlane met de gedeelde built artifacts | macOS-relevante wijzigingen |
| `macos-swift` | Swift-lint, build, en tests voor de macOS-app | macOS-relevante wijzigingen |
| `android` | Android-unit tests voor beide flavors plus één debug-APK-build | Android-relevante wijzigingen |
| `test-performance-agent` | Dagelijkse Codex-optimalisatie van trage tests na vertrouwde activiteit | Main CI-succes of handmatige dispatch |
| `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 main-CI of handmatige dispatch |
## Fail-fast volgorde
## Fail-fast-volgorde
1. `preflight` bepaalt welke lanes überhaupt bestaan. De `docs-scope`- en `changed-scope`-logica zijn stappen binnen deze job, geen zelfstandige jobs.
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 artifact- en platformmatrix-jobs.
3. `build-artifacts` overlapt met de snelle Linux-lanes zodat downstream consumers kunnen starten zodra de gedeelde build klaar is.
4. Zwaardere platform- en runtime-lanes waaieren daarna uit: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift`, en `android`.
1. `preflight` bepaalt welke lanes überhaupt bestaan. De logica `docs-scope` en `changed-scope` bestaat uit 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 artifact- en platformmatrixtaken.
3. `build-artifacts` overlapt met de snelle Linux-lanes, zodat downstream-consumenten kunnen starten zodra de gedeelde build klaar is.
4. Zwaardere platform- en runtime-lanes 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 jobs 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. Aggregate shard-checks gebruiken `!cancelled() && always()` zodat ze normale shard-fouten 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 queue group nieuwere main-runs niet onbeperkt kan blokkeren. Handmatige full-suite-runs gebruiken `CI-manual-v1-*` en annuleren in-progress runs niet.
GitHub kan vervangen taken als `cancelled` markeren wanneer een nieuwere push op dezelfde PR- of `main`-ref terechtkomt. Behandel dat als CI-ruis, tenzij de nieuwste run voor dezelfde ref ook faalt. Geaggregeerde shardcontroles gebruiken `!cancelled() && always()`, zodat ze nog steeds normale shardfouten rapporteren maar niet in de wachtrij komen nadat de hele workflow al is vervangen. De automatische CI-concurrencykey is geversioneerd (`CI-v7-*`), zodat een GitHub-zombie 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 unit tests in `src/scripts/ci-changed-scope.test.ts`. Handmatige dispatch slaat changed-scope-detectie over en laat het preflight-manifest doen 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 scoped gebied is gewijzigd.
- **CI-workflowbewerkingen** valideren de Node CI-graph plus workflow-linting, maar forceren op zichzelf geen native builds voor Windows, Android, of macOS; die platformlanes blijven beperkt tot platformsourcestijzigingen.
- **CI routing-only bewerkingen, geselecteerde goedkope core-test fixture-bewerkingen, en smalle Plugin contract helper/test-routing-bewerkingen** gebruiken een snel Node-only manifestpad: `preflight`, security, en één `checks-fast-core`-taak. Dat pad slaat build artifacts, Node 22-compatibiliteit, kanaalcontracten, volledige core-shards, bundled-Plugin shards, en aanvullende guard-matrices over wanneer de wijziging beperkt is tot de routing- of helperoppervlakken die de snelle taak direct uitoefent.
- **Windows Node-checks** zijn beperkt tot Windows-specifieke process/path-wrappers, npm/pnpm/UI runner helpers, package-managerconfiguratie, en de CI-workflowoppervlakken die die lane uitvoeren; niet-gerelateerde source-, Plugin-, install-smoke- en test-only wijzigingen blijven op de Linux Node-lanes.
- **CI-workflowwijzigingen** valideren de Node CI-graaf plus workflow-linting, maar forceren op zichzelf geen Windows-, Android- of macOS-native builds; die platformlanes blijven beperkt tot wijzigingen in platformsources.
- **CI-routing-only wijzigingen, geselecteerde goedkope core-test-fixturewijzigingen en smalle plugin-contract-helper/test-routing-wijzigingen** gebruiken een snel Node-only manifestpad: `preflight`, beveiliging en één `checks-fast-core`-taak. Dat pad slaat build artifacts, Node 22-compatibiliteit, channel-contracts, volledige core-shards, bundled-plugin-shards en aanvullende guardmatrices over wanneer de wijziging beperkt is tot de routing- of helperoppervlakken die de snelle taak direct oefent.
- **Windows Node-controles** zijn beperkt tot Windows-specifieke proces-/padwrappers, npm/pnpm/UI-runnerhelpers, package-managerconfiguratie en de CI-workflowoppervlakken die die lane uitvoeren; niet-gerelateerde source-, plugin-, install-smoke- en test-only wijzigingen blijven op de Linux Node-lanes.
De traagste Node-testfamilies zijn opgesplitst of gebalanceerd zodat elke job 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 opgesplitst in agent-runner-, dispatch-, en commands/state-routing-shards), en agentic Gateway/Plugin-configs worden verspreid over de bestaande source-only agentic Node-jobs in plaats van te wachten op built artifacts. Brede browser-, QA-, media- en diverse Plugin-tests gebruiken hun dedicated 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 hele config kan onderscheiden van een gefilterde shard. `check-additional` houdt package-boundary compile/canary-werk bij elkaar en scheidt runtime topology-architectuur van gateway-watch-dekking; de boundary guard shard draait zijn kleine onafhankelijke guards gelijktijdig binnen één job. 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 overreserveren: channel-contracts 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 worden verspreid over de bestaande source-only agentic Node-taken in plaats van te wachten op built artifacts. Brede browser-, QA-, media- en diverse plugintests gebruiken hun eigen Vitest-configuraties in plaats van de gedeelde plugin catch-all. Include-pattern-shards leggen timingvermeldingen vast met de CI-shardnaam, zodat `.artifacts/vitest-shard-timings.json` een volledige config kan onderscheiden van een gefilterde shard. `check-additional` houdt package-boundary compile/canary-werk bij elkaar en scheidt runtime-topologiearchitectuur van gateway-watch-dekking; de boundary-guard-shard voert zijn kleine onafhankelijke guards gelijktijdig binnen één taak uit. Gateway watch, channeltests 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 afzonderlijke source set of manifest; de unit-testlane compileert de flavor nog steeds met de SMS/call-log BuildConfig-flags, terwijl een dubbele debug-APK-packagingjob 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 afzonderlijke source set of manifest; de unittests-lane compileert de flavor nog steeds met de SMS/call-log BuildConfig-vlaggen, terwijl een dubbele debug-APK-packagingtaak bij elke Android-relevante push wordt vermeden.
De `check-dependencies`-shard draait `pnpm deadcode:dependencies` (een productie-Knip dependency-only pass gepind op de nieuwste Knip-versie, met pnpm's minimum release age uitgeschakeld voor de `dlx`-installatie) en `pnpm deadcode:unused-files`, dat Knip's production unused-file findings vergelijkt met `scripts/deadcode-unused-files.allowlist.mjs`. De unused-file guard faalt wanneer een PR een nieuw niet-beoordeeld unused file toevoegt of een verouderde allowlist-entry laat staan, terwijl intentionele dynamische Plugin-, generated-, 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 dependency-only pass vastgezet op de nieuwste Knip-versie, met pnpm's minimale releaseleeftijd uitgeschakeld voor de `dlx`-installatie) en `pnpm deadcode:unused-files`, dat Knips productiebevindingen voor ongebruikte bestanden vergelijkt met `scripts/deadcode-unused-files.allowlist.mjs`. De unused-file-guard faalt wanneer een PR een nieuw niet-beoordeeld ongebruikt bestand toevoegt of een verouderde allowlistvermelding achterlaat, terwijl opzettelijke dynamische plugin-, gegenereerde, build-, live-test- en package-bridge-oppervlakken behouden blijven die Knip niet statisch kan oplossen.
## Handmatige dispatches
Handmatige CI-dispatches draaien dezelfde job graph als normale CI, maar forceren elke non-Android scoped lane aan: Linux Node-shards, bundled-Plugin shards, kanaalcontracten, Node 22-compatibiliteit, `check`, `check-additional`, build smoke, docs-checks, Python Skills, Windows, macOS, en Control UI i18n. Zelfstandige handmatige CI-dispatches draaien Android alleen met `include_android=true`; de volledige release-umbrella schakelt Android in door `include_android=true` mee te geven. Plugin-prerelease static checks, de release-only `agentic-plugins`-shard, de volledige extension batch sweep, en Plugin-prerelease Docker-lanes zijn uitgesloten van CI. De Docker-prerelease suite draait alleen wanneer `Full Release Validation` de afzonderlijke `Plugin Prerelease`-workflow dispatcht met de release-validation gate ingeschakeld.
Handmatige CI-dispatches draaien dezelfde taakegraaf als normale CI, maar forceren elke niet-Android scoped lane aan: Linux Node-shards, bundled-plugin-shards, channel-contracts, Node 22-compatibiliteit, `check`, `check-additional`, build smoke, docs-controles, Python skills, Windows, macOS en Control UI i18n. Zelfstandige handmatige CI-dispatches draaien Android alleen met `include_android=true`; de volledige release-umbrella schakelt Android in door `include_android=true` door te geven. Statische controles voor plugin-prerelease, de release-only `agentic-plugins`-shard, de volledige extensiebatch-sweep en plugin-prerelease-Docker-lanes zijn uitgesloten van CI. De Docker-prerelease-suite draait alleen wanneer `Volledige Releasevalidatie` de afzonderlijke workflow `Plugin Prerelease` dispatcht met de release-validation-gate ingeschakeld.
Handmatige runs gebruiken een unieke concurrency group zodat een release-candidate full suite niet wordt geannuleerd door een andere push- of PR-run op dezelfde ref. Met de optionele `target_ref`-input kan een vertrouwde caller die graph draaien tegen een branch, tag, of volledige commit SHA terwijl het workflowbestand van de geselecteerde dispatch-ref wordt gebruikt.
Handmatige runs gebruiken een unieke concurrencygroep, zodat een releasekandidaat-full-suite niet wordt geannuleerd door een andere push- of PR-run op dezelfde ref. Met de optionele invoer `target_ref` kan een vertrouwde caller die graaf 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
@ -79,15 +79,15 @@ gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
## Runners
| Uitvoerder | Taken |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ubuntu-24.04` | `preflight`, snelle beveiligingstaken 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, Node-testaggregaatverificateurs, 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 plugin-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 bespaarde); install-smoke Docker-builds (32-vCPU-wachtrijtijd kostte meer dan het bespaarde) |
| `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 | Taken |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ubuntu-24.04` | `preflight`, snelle beveiligingstaken en aggregaties (`security-scm-fast`, `security-dependency-audit`, `security-fast`), snelle protocol-/contract-/gebundelde controles, gesharde channel-contractcontroles, `check`-shards behalve lint, `check-additional`-shards en aggregaties, Node-testaggregatieverifiers, docs-controles, Python Skills, workflow-sanity, labeler, auto-response; install-smoke-preflight gebruikt ook door GitHub gehoste Ubuntu zodat de Blacksmith-matrix eerder kan worden ingepland |
| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, lichtere Plugin-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 bespaarde); install-smoke Docker-builds (32-vCPU-wachtrijtijd kostte meer dan het bespaarde) |
| `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
@ -117,23 +117,23 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
## Volledige releasevalidatie
`Full Release Validation` is de handmatige overkoepelende 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 release-only Plugin-/package-/static-/Docker-bewijs, en dispatcht `OpenClaw Release Checks` voor install smoke, package-acceptatie, Docker-releasepad-suites, live/E2E, OpenWebUI, QA Lab-pariteit, Matrix en Telegram-lanes. De workflow kan ook de post-publicatie-workflow `NPM Telegram Beta E2E` uitvoeren wanneer een gepubliceerde packagespecificatie is opgegeven.
`Full Release Validation` is de handmatige overkoepelende workflow voor "alles uitvoeren voor de release". Deze accepteert een branch, tag of volledige commit-SHA, dispatcht de handmatige `CI`-workflow met dat doel, dispatcht `Plugin Prerelease` voor release-only bewijs van Plugin/package/static/Docker, en dispatcht `OpenClaw Release Checks` voor install smoke, packageacceptatie, Docker-release-path-suites, live/E2E, OpenWebUI, QA Lab-pariteit, Matrix- en Telegram-lanes. De workflow kan ook de post-publish-workflow `NPM Telegram Beta E2E` uitvoeren wanneer een gepubliceerde packagespecificatie is opgegeven.
`release_profile` bepaalt de live/provider-breedte die aan releasecontroles wordt doorgegeven:
`release_profile` bepaalt de live/provider-breedte die wordt doorgegeven aan releasecontroles:
- `minimum` behoudt de snelste OpenAI-/core-releasekritieke lanes.
- `stable` voegt de stabiele provider-/backendset toe.
- `minimum` behoudt de snelste OpenAI/core releasekritieke lanes.
- `stable` voegt de stabiele provider/backend-set toe.
- `full` voert de brede adviserende provider-/mediamatrix uit.
De paraplu registreert de gedispatchte child-run-id's, en de laatste taak `Verify full validation` controleert de huidige conclusies van child-runs opnieuw en voegt tabellen met de traagste taken voor elke child-run toe. Als een child-workflow opnieuw wordt uitgevoerd en groen wordt, voer dan alleen de verifier-taak van de parent opnieuw uit om het parapluresultaat en de timingsamenvatting te vernieuwen.
De overkoepelende workflow registreert de gedispatchte child-run-ID's, en de laatste taak `Verify full validation` controleert de huidige conclusies van child-runs opnieuw en voegt tabellen met traagste taken toe voor elke child-run. Als een child-workflow opnieuw wordt uitgevoerd en groen wordt, voer dan alleen de parent-verifiertaak opnieuw uit om het overkoepelende resultaat en de timingsamenvatting te vernieuwen.
Voor herstel accepteren zowel `Full Release Validation` als `OpenClaw Release Checks` `rerun_group`. Gebruik `all` voor een releasecandidate, `ci` voor alleen de normale volledige CI-child, `release-checks` voor elke release-child, of een smallere groep: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` of `npm-telegram` op de paraplu. Dit houdt een mislukte releasebox-heruitvoering begrensd na een gerichte fix.
Voor herstel accepteren zowel `Full Release Validation` als `OpenClaw Release Checks` `rerun_group`. Gebruik `all` voor een releasecandidate, `ci` voor alleen het normale volledige CI-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` in de overkoepelende workflow. Dit houdt een heruitvoering van een mislukte releasebox na een gerichte fix begrensd.
`OpenClaw Release Checks` gebruikt de vertrouwde workflow-ref om de geselecteerde ref één keer op te lossen naar een `release-package-under-test`-tarball, en geeft dat artifact vervolgens door aan zowel de live/E2E-releasepad-Docker-workflow als de package-acceptatieshard. Daardoor blijven de package-bytes consistent over releaseboxen heen en wordt voorkomen dat dezelfde kandidaat opnieuw wordt verpakt in meerdere child-taken.
`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 artifact vervolgens door aan zowel de live/E2E release-path Docker-workflow als de packageacceptatieshard. Dat houdt de packagebytes consistent tussen releaseboxen en voorkomt dat dezelfde kandidaat in meerdere child-taken opnieuw wordt verpakt.
## 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 één seriële taak:
Het live/E2E-child voor de release 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 taak:
- `native-live-src-agents`
- `native-live-src-gateway-core`
@ -145,57 +145,57 @@ 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`
- opgesplitste media-audio-/video-shards en provider-gefilterde muziekshards
- opgesplitste media-audio-/videoshards en provider-gefilterde muziekshards
Dat behoudt dezelfde bestandsdekking en maakt trage live-providerfouten gemakkelijker opnieuw uit te voeren en te diagnosticeren. De aggregaatshardnamen `native-live-extensions-o-z`, `native-live-extensions-media` en `native-live-extensions-media-music` blijven geldig voor handmatige eenmalige heruitvoeringen.
Dat behoudt dezelfde bestandsdekking terwijl trage live-providerfouten makkelijker opnieuw kunnen worden uitgevoerd en gediagnosticeerd. De aggregaatshardnamen `native-live-extensions-o-z`, `native-live-extensions-media` en `native-live-extensions-media-music` blijven geldig voor handmatige eenmalige heruitvoeringen.
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; mediataken verifiëren alleen de binaries vóór setup. Houd door Docker ondersteunde livesuites op normale Blacksmith-runners — containerjobs zijn de verkeerde plek om geneste Docker-tests te starten.
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 vooraf `ffmpeg` en `ffprobe`; mediataken verifiëren alleen de binaries vóór de setup. Houd door Docker ondersteunde live-suites op normale Blacksmith-runners — containertaken zijn de verkeerde plek om geneste Docker-tests te starten.
Door Docker ondersteunde live model-/backendshards gebruiken een aparte gedeelde image `ghcr.io/openclaw/openclaw-live-test:<sha>` per geselecteerde commit. De live-releaseworkflow bouwt en pusht die image één keer, waarna de Docker live model-, Gateway-, CLI-backend-, ACP-bind- en Codex-harness-shards draaien met `OPENCLAW_SKIP_DOCKER_BUILD=1`. Als die shards het volledige source-Dockerdoel zelfstandig opnieuw bouwen, is de release-uitvoering verkeerd geconfigureerd en verspilt die wandkloktijd aan dubbele image-builds.
Door Docker ondersteunde live model-/backendshards 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-, Gateway-, CLI-backend-, ACP bind- en Codex harness-shards draaien met `OPENCLAW_SKIP_DOCKER_BUILD=1`. Als die shards de volledige source-Docker-target onafhankelijk opnieuw bouwen, is de release-run verkeerd geconfigureerd en verspilt die wandkloktijd aan dubbele imagebuilds.
## Package-acceptatie
## Packageacceptatie
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 gebruiken.
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 packageacceptatie één tarball valideert via dezelfde Docker E2E-harness die gebruikers na installatie of update gebruiken.
### Taken
1. `resolve_package` checkt `workflow_ref` uit, lost één packagekandidaat op, 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 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 artifact, valideert de tarball-inventaris, bereidt waar nodig package-digest-Docker-images voor 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 vervolgens uit als parallelle gerichte Docker-taken met unieke artifacts.
3. `package_telegram` roept optioneel `NPM Telegram Beta E2E` aan. Deze draait wanneer `telegram_mode` niet `none` is en installeert hetzelfde `package-under-test`-artifact wanneer Package Acceptance er één heeft opgelost; zelfstandige Telegram-dispatch kan nog steeds een gepubliceerde npm-specificatie installeren.
4. `summary` laat de workflow mislukken als package-resolutie, Docker-acceptatie of de optionele Telegram-lane is mislukt.
1. `resolve_package` checkt `workflow_ref` uit, lost één packagekandidaat op, 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 print de bron, workflow-ref, package-ref, versie, SHA-256 en het profiel in de GitHub-stappensamenvatting.
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-inventory, 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 vervolgens uit als parallelle gerichte Docker-taken met unieke artifacts.
3. `package_telegram` roept optioneel `NPM Telegram Beta E2E` aan. Deze draait wanneer `telegram_mode` niet `none` is en installeert hetzelfde artifact `package-under-test` wanneer Package Acceptance er een heeft opgelost; een zelfstandige Telegram-dispatch kan nog steeds een gepubliceerde npm-specificatie installeren.
4. `summary` laat de workflow falen als packageoplossing, Docker-acceptatie of de optionele Telegram-lane is mislukt.
### Kandidaatbronnen
- `source=npm` accepteert alleen `openclaw@beta`, `openclaw@latest` of een exacte OpenClaw-releaseversie zoals `openclaw@2026.4.27-beta.2`. Gebruik dit voor gepubliceerde beta-/stabiele acceptatie.
- `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 branchgeschiedenis van de repository of een releasetag, installeert afhankelijkheden in een losgekoppelde worktree en verpakt deze 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 acceptatie van gepubliceerde beta/stable-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 branchgeschiedenis van de repository of een releasetag, installeert afhankelijkheden in een losgekoppelde worktree en verpakt die met `scripts/package-openclaw-for-docker.mjs`.
- `source=url` downloadt een HTTPS-`.tgz`; `package_sha256` is vereist.
- `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 moet worden opgegeven voor extern gedeelde artifacts.
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.
### Suite-profielen
- `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload`
- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update`
- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update`
- `product` — `package` plus `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
- `full` — volledige Docker-releasepad-chunks met OpenWebUI
- `custom` — exacte `docker_lanes`; vereist wanneer `suite_profile=custom`
Het profiel `package` gebruikt offline Plugin-dekking, zodat validatie van gepubliceerde pakketten niet afhankelijk is van live beschikbaarheid van ClawHub. De optionele Telegram-lane hergebruikt het artifact `package-under-test` in `NPM Telegram Beta E2E`, waarbij het gepubliceerde npm-spec-pad behouden blijft voor zelfstandige dispatches.
Het `package`-profiel gebruikt offline plugindekking zodat validatie van gepubliceerde pakketten niet afhankelijk is van live ClawHub-beschikbaarheid. De optionele Telegram-lane hergebruikt het `package-under-test`-artifact in `NPM Telegram Beta E2E`, waarbij het gepubliceerde npm-spec-pad behouden blijft voor zelfstandige dispatches.
Releasechecks roepen Package Acceptance aan met `source=ref`, `package_ref=<release-ref>`, `workflow_ref=<release workflow ref>`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` en `telegram_mode=mock-openai`. Docker-chunks voor het releasepad dekken de overlappende package-/update-/Plugin-lanes; Package Acceptance behoudt de artifact-native compatibiliteit voor gebundelde kanalen, offline Plugin- en Telegram-bewijs tegen dezelfde opgeloste pakket-tarball. Cross-OS-releasechecks dekken nog steeds OS-specifieke onboarding, installer- en platformgedrag; package-/update-productvalidatie moet beginnen met Package Acceptance. De Windows packaged- en installer fresh-lanes verifiëren ook dat een geïnstalleerd pakket 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 ingesteld, anders `openai/gpt-5.4-mini`, zodat het installatie- en Gateway-bewijs snel en deterministisch blijft.
Releasecontroles roepen Package Acceptance aan met `source=ref`, `package_ref=<release-ref>`, `workflow_ref=<release workflow ref>`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` en `telegram_mode=mock-openai`. Docker-chunks voor het releasepad dekken de overlappende package-/update-/plugin-lanes; Package Acceptance behoudt de artifact-native compatibiliteit voor gebundelde kanalen, offline plugins en Telegram-bewijs tegen dezelfde opgeloste package-tarball. Cross-OS-releasecontroles dekken nog steeds OS-specifieke onboarding, installer en platformgedrag; package-/update-productvalidatie moet beginnen met Package Acceptance. De Windows packaged- en installer fresh-lanes verifiëren ook dat een geïnstalleerd pakket een browser-control-override kan importeren vanuit een onbewerkt absoluut Windows-pad. De OpenAI cross-OS agent-turn smoke gebruikt standaard `OPENCLAW_CROSS_OS_OPENAI_MODEL` wanneer die is ingesteld, anders `openai/gpt-5.4-mini`, zodat het installatie- en Gateway-bewijs snel en deterministisch blijft.
### Verouderde compatibiliteitsvensters
### Vensters voor legacy-compatibiliteit
Package Acceptance heeft begrensde vensters voor verouderde compatibiliteit voor al gepubliceerde pakketten. Pakketten tot en met `2026.4.25`, inclusief `2026.4.25-beta.*`, mogen het compatibiliteitspad gebruiken:
Package Acceptance heeft begrensde vensters voor legacy-compatibiliteit voor al gepubliceerde pakketten. Pakketten tot en met `2026.4.25`, inclusief `2026.4.25-beta.*`, mogen het compatibiliteitspad gebruiken:
- bekende private QA-items 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 pakket die vlag niet beschikbaar stelt;
- `doctor-switch` mag de subcase voor persistentie van `gateway install --wrapper` overslaan wanneer het pakket die flag niet exposeert;
- `update-channel-switch` mag ontbrekende `pnpm.patchedDependencies` verwijderen uit de van de tarball afgeleide nep-git-fixture en mag ontbrekende gepersisteerde `update.channel` loggen;
- Plugin-smokes mogen verouderde install-record-locaties lezen of ontbrekende persistentie van marketplace-install-records accepteren;
- `plugin-update` mag migratie van configmetadata toestaan, terwijl nog steeds vereist is dat het install-record en het gedrag zonder herinstallatie ongewijzigd blijven.
- plugin-smokes mogen legacy install-record-locaties lezen of ontbrekende marketplace install-record-persistentie accepteren;
- `plugin-update` mag config-metadatamigratie toestaan terwijl nog steeds wordt vereist dat de install record en het no-reinstall-gedrag ongewijzigd blijven.
Het gepubliceerde pakket `2026.4.26` mag ook waarschuwen voor lokale buildmetadatastempelbestanden die al waren verzonden. Latere pakketten moeten aan de moderne contracten voldoen; dezelfde voorwaarden falen dan in plaats van te waarschuwen of over te slaan.
Het gepubliceerde pakket `2026.4.26` mag ook waarschuwen voor lokaal gebouwde metadata-stempelbestanden die al zijn verzonden. Latere pakketten moeten voldoen aan de moderne contracten; dezelfde voorwaarden falen dan in plaats van te waarschuwen of over te slaan.
### Voorbeelden
@ -238,111 +238,111 @@ gh workflow run package-acceptance.yml \
-f docker_lanes='install-e2e plugin-update'
```
Begin bij het debuggen van een mislukte package acceptance-run met de samenvatting `resolve_package` om de pakketbron, versie en SHA-256 te bevestigen. Inspecteer daarna de child-run `docker_acceptance` en de Docker-artifacts daarvan: `.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 volledige releasevalidatie opnieuw uit te voeren.
Begin bij het debuggen van een mislukte package acceptance-run bij de samenvatting van `resolve_package` om de pakketbron, versie en SHA-256 te bevestigen. Inspecteer daarna de child-run `docker_acceptance` en de Docker-artifacts daarvan: `.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.
## Install smoke
De afzonderlijke workflow `Install Smoke` hergebruikt hetzelfde scopescript via de eigen job `preflight`. Deze splitst smoke-dekking in `run_fast_install_smoke` en `run_full_install_smoke`.
De afzonderlijke workflow `Install Smoke` hergebruikt hetzelfde scope-script via zijn eigen `preflight`-job. Die splitst smoke-dekking in `run_fast_install_smoke` en `run_full_install_smoke`.
- **Snel pad** draait voor pull requests die Docker-/package-oppervlakken, wijzigingen in gebundelde Plugin-pakketten/manifests of core Plugin-/kanaal-/Gateway-/Plugin SDK-oppervlakken raken die de Docker-smoke-jobs oefenen. Alleen-source wijzigingen in gebundelde Plugins, alleen-testbewerkingen en alleen-docsbewerkingen reserveren geen Docker-workers. Het snelle pad bouwt de root-Dockerfile-image één keer, controleert de CLI, voert de CLI-smoke voor agents delete shared-workspace uit, voert de container gateway-network e2e uit, verifieert een build-arg voor gebundelde extensies en voert het begrensde gebundelde-Plugin-Docker-profiel uit onder een totale commandotime-out van 240 seconden (waarbij de Docker-run van elk scenario afzonderlijk begrensd is).
- **Volledig pad** behoudt QR-package-installatie en installer-Docker-/update-dekking voor nachtelijke geplande runs, handmatige dispatches, workflow-call-releasechecks en pull requests die werkelijk installer-/package-/Docker-oppervlakken raken. In volledige modus bereidt install-smoke één doel-SHA GHCR root-Dockerfile-smoke-image voor of hergebruikt die, en voert daarna QR-package-installatie, root-Dockerfile-/Gateway-smokes, installer-/update-smokes en de snelle gebundelde-Plugin-Docker-E2E uit als afzonderlijke jobs, zodat installerwerk niet hoeft te wachten op de root-image-smokes.
- **Snel pad** wordt uitgevoerd voor pull requests die Docker-/package-oppervlakken raken, wijzigingen in gebundelde pluginpakketten/manifests, of kernoppervlakken voor plugin/kanaal/Gateway/Plugin SDK die de Docker smoke-jobs uitvoeren. Source-only wijzigingen in gebundelde plugins, test-only edits en docs-only edits reserveren geen Docker-workers. Het snelle pad bouwt de root-Dockerfile-image één keer, controleert de CLI, voert de agents delete shared-workspace CLI smoke uit, voert de container gateway-network e2e uit, verifieert een build-argument voor gebundelde extensies en voert het begrensde gebundelde-plugin Docker-profiel uit onder een geaggregeerde commandotime-out van 240 seconden (waarbij elke Docker-run van een scenario afzonderlijk is begrensd).
- **Volledig pad** behoudt QR package install en installer Docker-/update-dekking voor nachtelijke geplande runs, handmatige dispatches, workflow-call-releasecontroles en pull requests die daadwerkelijk installer-/package-/Docker-oppervlakken raken. In volledige modus bereidt install-smoke één doel-SHA GHCR root-Dockerfile smoke-image voor of hergebruikt die, en voert daarna QR package install, root-Dockerfile-/Gateway-smokes, installer-/update-smokes en de snelle gebundelde-plugin Docker E2E uit als afzonderlijke jobs, zodat installer-werk niet hoeft te wachten achter de root-image-smokes.
`main`-pushes (inclusief mergecommits) forceren het volledige pad niet; wanneer changed-scope-logica volledige dekking zou vragen op een push, behoudt de workflow de snelle Docker-smoke en laat deze de volledige install-smoke over aan nachtelijke of releasevalidatie.
`main`-pushes (inclusief mergecommits) forceren het volledige pad niet; wanneer changed-scope-logica volledige dekking op een push zou aanvragen, 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 gestuurd 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 Bun global install image-provider smoke wordt apart bewaakt door `run_bun_global_install_smoke`. Die draait op de nachtelijke planning en vanuit de releasecontroles-workflow, en handmatige `Install Smoke`-dispatches kunnen ervoor kiezen die 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
`pnpm test:docker:all` bouwt vooraf één gedeelde live-test-image, verpakt OpenClaw één keer als npm-tarball en bouwt twee gedeelde `scripts/e2e/Dockerfile`-images:
`pnpm test:docker:all` prebuildt één gedeelde live-test-image, verpakt OpenClaw één keer als npm-tarball en bouwt twee gedeelde `scripts/e2e/Dockerfile`-images:
- een kale Node/Git-runner voor installer-/update-/Plugin-afhankelijkheidslanes;
- een functionele image die dezelfde tarball installeert in `/app` voor normale functionaliteitslanes.
- 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 voert daarna lanes uit met `OPENCLAW_SKIP_DOCKER_BUILD=1`.
### Instelbare waarden
### Instelbare opties
| Variabele | Standaard | Doel |
| -------------------------------------- | --------- | --------------------------------------------------------------------------------------------- |
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Aantal slots in de main-pool voor normale lanes. |
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Aantal slots in de providergevoelige tail-pool. |
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Limiet voor gelijktijdige live-lanes, zodat providers niet throttlen. |
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Aantal slots in de hoofdpool 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-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 vermijden; stel `0` in voor geen spreiding. |
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Spreiding tussen lane-starts om Docker-daemon create-stormen te vermijden; stel `0` in 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` | unset | `1` drukt het schedulerplan af zonder lanes uit te voeren. |
| `OPENCLAW_DOCKER_ALL_LANES` | unset | Door komma's gescheiden exacte lanelijst; slaat cleanup-smoke over zodat agents één mislukte lane kunnen reproduceren. |
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` print het schedulerplan zonder lanes uit te voeren. |
| `OPENCLAW_DOCKER_ALL_LANES` | unset | Door komma's gescheiden exacte lanelijst; slaat cleanup smoke over zodat agents één mislukte lane kunnen reproduceren. |
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 aggregate voert Docker-preflights uit, verwijdert verouderde OpenClaw E2E-containers, schrijft actieve-lane-status weg, persisteert lanetimings voor longest-first-volgorde en stopt standaard met het plannen 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 geaggregeerde preflights controleren Docker, verwijderen verouderde OpenClaw E2E-containers, geven actieve-lane-status weer, bewaren lanetimings voor langste-eerst-ordening en stoppen standaard met het plannen van nieuwe gepoolde lanes na de eerste fout.
### Herbruikbare live/E2E-workflow
De herbruikbare live/E2E-workflow vraagt met `scripts/test-docker-all.mjs --plan-json` welke package, imagesoort, live-image, lane en credential-dekking vereist is. `scripts/docker-e2e.mjs` zet dat plan vervolgens om in GitHub-outputs en samenvattingen. Deze verpakt OpenClaw via `scripts/package-openclaw-for-docker.mjs`, downloadt een package-artifact uit de huidige run of downloadt een package-artifact 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 met geïnstalleerde packages nodig heeft; en hergebruikt opgegeven inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` 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-/cache-stream 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 package-, image-kind-, live-image-, lane- en credential-dekking vereist is. `scripts/docker-e2e.mjs` zet dat plan vervolgens om in GitHub-outputs en samenvattingen. Het verpakt OpenClaw via `scripts/package-openclaw-for-docker.mjs`, downloadt een current-run package-artifact of downloadt een package-artifact uit `package_artifact_run_id`; valideert de tarball-inventory; bouwt en pusht package-digest-getagde bare/functional GHCR Docker E2E-images via Blacksmiths Docker-laagcache wanneer het plan package-installed lanes nodig heeft; en hergebruikt opgegeven inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` 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 verbruiken.
### Releasepad-chunks
Release-Docker-dekking draait kleinere chunked jobs met `OPENCLAW_SKIP_DOCKER_BUILD=1`, zodat elke chunk alleen de imagesoort ophaalt die nodig is en meerdere lanes uitvoert via dezelfde gewogen scheduler:
Release-Docker-dekking draait kleinere gechunkte jobs met `OPENCLAW_SKIP_DOCKER_BUILD=1`, zodat elke chunk alleen het image-kind ophaalt 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 | bundled-channels`
Huidige Docker-chunks voor releases zijn `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a` tot en met `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` en `bundled-channels-contracts`. De geaggregeerde chunk `bundled-channels` blijft beschikbaar voor handmatige eenmalige heruitvoeringen, en `plugins-runtime-core`, `plugins-runtime` en `plugins-integrations` blijven geaggregeerde plugin-/runtime-aliassen. De lane-alias `install-e2e` blijft de geaggregeerde handmatige heruitvoeringsalias voor beide provider-installatielanes. De chunk `bundled-channels` voert gesplitste lanes `bundled-channel-*` en `bundled-channel-update-*` uit in plaats van de seriële alles-in-één-lane `bundled-channel-deps`.
De huidige Docker-chunks voor releases zijn `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a` tot en met `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` en `bundled-channels-contracts`. De geaggregeerde chunk `bundled-channels` blijft beschikbaar voor handmatige eenmalige herruns, en `plugins-runtime-core`, `plugins-runtime` en `plugins-integrations` blijven geaggregeerde aliassen voor Plugin/runtime. De lane-alias `install-e2e` blijft de geaggregeerde handmatige herrun-alias voor beide providerinstaller-lanes. De chunk `bundled-channels` voert gesplitste lanes `bundled-channel-*` en `bundled-channel-update-*` uit in plaats van de seriële alles-in-één-lane `bundled-channel-deps`.
OpenWebUI wordt opgenomen in `plugins-runtime-services` wanneer volledige release-paddekking daarom vraagt, en behoudt alleen een zelfstandige chunk `openwebui` voor dispatches die uitsluitend OpenWebUI betreffen. Update-lanes voor gebundelde kanalen proberen één keer opnieuw bij tijdelijke npm-netwerkfouten.
OpenWebUI wordt opgenomen in `plugins-runtime-services` wanneer volledige dekking van het releasepad daarom vraagt, en behoudt alleen een zelfstandige chunk `openwebui` voor dispatches die uitsluitend OpenWebUI betreffen. Update-lanes voor gebundelde kanalen proberen het één keer opnieuw bij tijdelijke npm-netwerkfouten.
Elke chunk uploadt `.artifacts/docker-tests/` met lane-logboeken, timings, `summary.json`, `failures.json`, fasetimings, JSON voor het scheduler-plan, tabellen met trage lanes en heruitvoeringscommando's per lane. De workflow-invoer `docker_lanes` voert geselecteerde lanes uit tegen de voorbereide images in plaats van de chunk-jobs; daardoor blijft debuggen van mislukte lanes beperkt tot één gerichte Docker-job en wordt het package-artifact voor die uitvoering voorbereid, gedownload of hergebruikt. Als een geselecteerde lane een live Docker-lane is, bouwt de gerichte job de live-testimage lokaal voor die heruitvoering. Gegenereerde GitHub-heruitvoeringscommando's per lane bevatten `package_artifact_run_id`, `package_artifact_name` en voorbereide image-invoer wanneer die waarden bestaan, zodat een mislukte lane exact hetzelfde package en dezelfde images van de mislukte uitvoering kan hergebruiken.
Elke chunk uploadt `.artifacts/docker-tests/` met lane-logs, timings, `summary.json`, `failures.json`, fasetimings, schedulerplan-JSON, tabellen met trage lanes en herrun-commando's per lane. De workflow-invoer `docker_lanes` voert geselecteerde lanes uit tegen de voorbereide images in plaats van de chunk-jobs, waardoor debugging van mislukte lanes beperkt blijft tot één gerichte Docker-job en het package-artifact voor die run wordt voorbereid, gedownload of hergebruikt; als een geselecteerde lane een live Docker-lane is, bouwt de gerichte job lokaal de live-testimage voor die herrun. Gegenereerde GitHub-herrun-commando's per lane bevatten `package_artifact_run_id`, `package_artifact_name` en voorbereide image-invoer wanneer die waarden bestaan, zodat een mislukte lane exact hetzelfde package en dezelfde 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 voert dagelijks de volledige Docker-suite voor het release-pad uit.
De geplande live/E2E-workflow voert dagelijks de volledige Docker-suite voor het releasepad uit.
## Plugin-prerelease
`Plugin Prerelease` is duurdere product-/packagedekking, dus het is een afzonderlijke workflow die wordt gedispatcht door `Full Release Validation` of door een expliciete operator. Normale pull requests, pushes naar `main` en zelfstandige handmatige CI-dispatches houden die suite uitgeschakeld. De workflow verdeelt gebundelde Plugin-tests over acht extensieworkers; die extensieshard-jobs voeren maximaal twee pluginconfiguratiegroepen tegelijk uit met één Vitest-worker per groep en een grotere Node-heap, zodat importzware pluginbatches geen extra CI-jobs aanmaken.
`Plugin Prerelease` is duurdere product/package-dekking, dus het is een afzonderlijke workflow die wordt gedispatcht door `Full Release Validation` of door een expliciete operator. Normale pull requests, pushes naar `main` en zelfstandige handmatige CI-dispatches laten die suite uitgeschakeld. De workflow verdeelt gebundelde Plugin-tests over acht extensieworkers; die extensieshard-jobs voeren maximaal twee Plugin-configuratiegroepen tegelijk uit, met één Vitest-worker per groep en een grotere Node-heap, zodat import-zware Plugin-batches geen extra CI-jobs aanmaken.
## QA Lab
## QA-lab
QA Lab heeft speciale CI-lanes buiten de hoofdworkflow met slimme scope.
QA-lab heeft eigen CI-lanes buiten de hoofdworkflow met slimme scoping.
- De workflow `Parity gate` draait bij overeenkomende PR-wijzigingen en handmatige dispatch; hij bouwt de private QA-runtime en vergelijkt de agentische packs voor mock GPT-5.5 en Opus 4.6.
- De workflow `QA-Lab - All Lanes` draait elke nacht op `main` en bij handmatige dispatch; hij waaiert de mock-pariteitsgate, 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 `Parity gate` draait bij overeenkomende PR-wijzigingen en handmatige dispatch; hij bouwt de private QA-runtime en vergelijkt de mock GPT-5.5- en Opus 4.6-agentic-packs.
- De workflow `QA-Lab - All Lanes` draait elke nacht op `main` en bij handmatige dispatch; hij waaiert de mock parity gate, 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.
Releasecontroles voeren live transportlanes voor Matrix en Telegram uit met de deterministische mockprovider en mockgekwalificeerde modellen (`mock-openai/gpt-5.5` en `mock-openai/gpt-5.5-alt`), zodat het kanaalcontract is geïsoleerd van live modellatentie en normale startup van provider-plugins. De live transport-Gateway schakelt geheugenzoeken uit omdat QA-pariteit geheugengedrag afzonderlijk dekt; providerconnectiviteit wordt gedekt door de afzonderlijke suites voor live modellen, native providers en Docker-providers.
Releasechecks voeren live transport-lanes voor Matrix en Telegram uit 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 opstart van provider-Plugins. De live transport-Gateway schakelt geheugenzoekopdrachten uit, omdat QA-pariteit geheugengedrag afzonderlijk afdekt; providerconnectiviteit wordt afgedekt door de afzonderlijke suites voor live modellen, native providers en Docker-providers.
Matrix gebruikt `--profile fast` voor geplande gates en releasegates, en voegt `--fail-fast` alleen toe wanneer de uitgecheckte CLI dit ondersteunt. De CLI-standaard en de handmatige workflow-invoer blijven `all`; handmatige dispatch met `matrix_profile=all` shardt volledige Matrix-dekking altijd in jobs voor `transport`, `media`, `e2ee-smoke`, `e2ee-deep` en `e2ee-cli`.
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-invoer blijven `all`; handmatige dispatch met `matrix_profile=all` shardt volledige Matrix-dekking altijd in de jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` en `e2ee-cli`.
`OpenClaw Release Checks` voert vóór releasegoedkeuring ook de releasekritieke QA Lab-lanes uit; de QA-pariteitsgate voert de kandidaat- en baselinepacks uit als parallelle lane-jobs, en downloadt daarna beide artifacts naar een kleine rapportjob voor de uiteindelijke pariteitsvergelijking.
`OpenClaw Release Checks` voert ook de releasekritieke QA-lab-lanes uit vóór releasegoedkeuring; de QA-parity gate voert de candidate- en baseline-packs uit als parallelle lane-jobs, en downloadt daarna beide artifacts naar een kleine rapportjob voor de uiteindelijke pariteitsvergelijking.
Plaats het PR-landingspad niet achter `Parity gate`, tenzij de wijziging daadwerkelijk raakt aan de QA-runtime, modelpackpariteit of een oppervlak dat eigendom is van de pariteitsworkflow. Behandel dit voor normale kanaal-, configuratie-, documentatie- of unit-testfixes als een optioneel signaal en volg in plaats daarvan het gescopete CI-/controlebewijs.
Plaats het PR-landingspad niet achter `Parity gate`, tenzij de wijziging daadwerkelijk de QA-runtime, model-pack-pariteit of een oppervlak raakt dat eigendom is van de parity-workflow. Behandel dit bij normale oplossingen voor kanalen, configuratie, documentatie of unit-tests als een optioneel signaal en volg in plaats daarvan het bewijs uit de gescopete CI/checks.
## CodeQL
De workflow `CodeQL` is bewust een smalle eerste securityscanner, niet de volledige repository-sweep. Dagelijkse, handmatige en niet-concept pull request-guard-uitvoeringen scannen Actions-workflowcode plus de JavaScript-/TypeScript-oppervlakken met het hoogste risico, met high-confidence beveiligingsquery's gefilterd op hoge/kritieke `security-severity`.
De workflow `CodeQL` is bewust een smalle beveiligingsscanner voor de eerste pass, niet de volledige repository-sweep. Dagelijkse, handmatige en niet-draft pull-request-guard-runs scannen Actions-workflowcode plus de JavaScript/TypeScript-oppervlakken met het hoogste risico, met high-confidence beveiligingsqueries gefilterd op hoge/kritieke `security-severity`.
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 beveiligingsmatrix uit als de geplande workflow. Android- en macOS-CodeQL blijven buiten de PR-standaarden.
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 beveiligingsmatrix uit als de geplande workflow. Android- en macOS-CodeQL blijven buiten de PR-standaarden.
### Beveiligingscategorieën
| Categorie | Oppervlak |
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| `/codeql-security-high/core-auth-secrets` | Auth, secrets, sandbox, cron en Gateway-baseline |
| `/codeql-security-high/channel-runtime-boundary` | Implementatiecontracten voor core-kanalen plus de runtime van kanaal-plugins, Gateway, Plugin SDK, secrets, audit-aanraakpunten |
| `/codeql-security-high/network-ssrf-boundary` | Oppervlakken voor core-SSRF, IP-parsing, netwerkguard, web-fetch en SSRF-beleid van de Plugin SDK |
| `/codeql-security-high/mcp-process-tool-boundary` | MCP-servers, helpers voor procesuitvoering, uitgaande aflevering en gates voor tooluitvoering door agents |
| `/codeql-security-high/plugin-trust-boundary` | Vertrouwensoppervlakken voor Plugin-installatie, loader, manifest, registry, runtime-dependency-staging, source-loading en Plugin SDK-packagecontract |
| Categorie | Oppervlak |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| `/codeql-security-high/core-auth-secrets` | Auth, geheimen, sandbox, cron en Gateway-baseline |
| `/codeql-security-high/channel-runtime-boundary` | Implementatiecontracten voor core-kanalen plus de kanaal-Plugin-runtime, Gateway, Plugin SDK, geheimen, audit-aanraakpunten |
| `/codeql-security-high/network-ssrf-boundary` | Core SSRF, IP-parsing, netwerkguard, web-fetch en SSRF-beleidsoppervlakken van Plugin SDK |
| `/codeql-security-high/mcp-process-tool-boundary` | MCP-servers, helpers voor procesuitvoering, outbound delivery en gates voor tooluitvoering door agents |
| `/codeql-security-high/plugin-trust-boundary` | Plugin-installatie, loader, manifest, registry, staging van runtime-afhankelijkheden, source-loading en trust-oppervlakken van het Plugin SDK-packagecontract |
### Platformspecifieke beveiligingsshards
- `CodeQL Android Critical Security` — geplande Android-beveiligingsshard. 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-beveiligingsshard. Bouwt de macOS-app handmatig voor CodeQL op Blacksmith macOS, filtert buildresultaten van dependencies uit de geüploade SARIF en uploadt onder `/codeql-critical-security/macos`. Blijft buiten dagelijkse standaarden omdat de macOS-build de runtime domineert, zelfs wanneer hij schoon is.
- `CodeQL macOS Critical Security` — wekelijkse/handmatige macOS-beveiligingsshard. Bouwt de macOS-app handmatig voor CodeQL op Blacksmith macOS, filtert buildresultaten van dependencies uit de geüploade SARIF en uploadt onder `/codeql-critical-security/macos`. Blijft buiten de dagelijkse standaarden omdat de macOS-build de runtime domineert, zelfs wanneer die schoon is.
### Critical Quality-categorieën
`CodeQL Critical Quality` is de overeenkomende niet-beveiligingsshard. Hij voert alleen foutseverity, niet-beveiligingsgerichte JavaScript-/TypeScript-kwaliteitsquery's uit over smalle waardevolle 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 shards `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` uit voor wijzigingen aan agent-command-/model-/tooluitvoering en reply-dispatchcode, configuratieschema-/migratie-/IO-code, auth-/secrets-/sandbox-/beveiligingscode, core-kanaalruntime en gebundelde kanaal-pluginruntime, Gateway-protocol/servermethode, geheugenruntime/SDK-glue, MCP/proces/uitgaande aflevering, providerruntime/modelcatalogus, sessiediagnostiek/afleveringswachtrijen, pluginloader, Plugin SDK/packagecontract of Plugin SDK reply-runtime. Wijzigingen aan CodeQL-configuratie en kwaliteitsworkflows voeren alle twaalf PR-kwaliteitsshards uit.
`CodeQL Critical Quality` is de overeenkomende niet-beveiligingsshard. Hij voert alleen JavaScript/TypeScript-kwaliteitsqueries met error-severity en zonder beveiligingskarakter uit over smalle, waardevolle oppervlakken op de kleinere Blacksmith Linux-runner. De pull-request-guard is bewust kleiner dan het geplande profiel: niet-draft PR's voeren alleen de overeenkomende shards `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` uit voor wijzigingen in agent-commando/model/tooluitvoering en reply-dispatchcode, configuratieschema/migratie/IO-code, auth/geheimen/sandbox/beveiligingscode, runtime van core-kanalen en gebundelde kanaal-Plugins, Gateway-protocol/server-method, memory-runtime/SDK-glue, MCP/proces/outbound delivery, provider-runtime/modelcatalogus, sessiediagnostiek/delivery queues, Plugin-loader, Plugin SDK/packagecontract of Plugin SDK-reply-runtime. Wijzigingen in CodeQL-configuratie en kwaliteitsworkflows voeren alle twaalf PR-kwaliteitsshards uit.
Handmatige dispatch accepteert:
@ -352,38 +352,38 @@ profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-run
De smalle profielen zijn onderwijs-/iteratiehooks om één kwaliteitsshard geïsoleerd uit te voeren.
| Categorie | Oppervlak |
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `/codeql-critical-quality/core-auth-secrets` | Auth, geheimen, sandbox, Cron en code voor de Gateway-beveiligingsgrens |
| `/codeql-critical-quality/config-boundary` | Configuratieschema, migratie, normalisatie en IO-contracten |
| `/codeql-critical-quality/gateway-runtime-boundary` | Gateway-protocolschema's en servermethodecontracten |
| `/codeql-critical-quality/channel-runtime-boundary` | Implementatiecontracten voor kernkanalen en gebundelde kanaal-Plugins |
| `/codeql-critical-quality/agent-runtime-boundary` | Opdrachtuitvoering, model-/providerdispatch, auto-reply-dispatch en wachtrijen, en ACP-runtimecontracten voor het control plane |
| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-servers en tool bridges, procesbewakingshelpers en contracten voor uitgaande levering |
| `/codeql-critical-quality/memory-runtime-boundary` | Memory host SDK, memory runtime-facades, memory Plugin SDK-aliassen, memory runtime-activeringslijm en memory doctor-opdrachten |
| `/codeql-critical-quality/session-diagnostics-boundary` | Interne reply-wachtrijen, sessieleveringswachtrijen, helpers voor uitgaande sessiebinding/-levering, oppervlakken voor diagnostische events/logbundels en sessie-doctor-CLI-contracten |
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Inkomende reply-dispatch van de Plugin SDK, helpers voor reply-payload/chunking/runtime, kanaalreply-opties, leveringswachtrijen en helpers voor sessie-/threadbinding |
| `/codeql-critical-quality/provider-runtime-boundary` | Normalisatie van modelcatalogi, provider-auth en discovery, provider-runtime-registratie, providerdefaults/-catalogi en web-/search-/fetch-/embedding-registers |
| `/codeql-critical-quality/ui-control-plane` | Bootstrap van de control UI, lokale persistentie, Gateway-controlflows en runtimecontracten voor het task control plane |
| `/codeql-critical-quality/web-media-runtime-boundary` | Runtimecontracten voor core web fetch/search, media-IO, mediabegrip, image-generation en media-generation |
| `/codeql-critical-quality/plugin-boundary` | Loader-, registry-, public-surface- en Plugin SDK-entrypointcontracten |
| `/codeql-critical-quality/plugin-sdk-package-contract` | Gepubliceerde pakketkant-Plugin SDK-broncode en contracthelpers voor Plugin-pakketten |
| Categorie | Oppervlak |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `/codeql-critical-quality/core-auth-secrets` | Auth-, geheimen-, sandbox-, Cron- en Gateway-beveiligingsgrenscode |
| `/codeql-critical-quality/config-boundary` | Configuratieschema, migratie, normalisatie en IO-contracten |
| `/codeql-critical-quality/gateway-runtime-boundary` | Gateway-protocolschema's en servermethodecontracten |
| `/codeql-critical-quality/channel-runtime-boundary` | Corekanaal- en gebundelde kanaal-Plugin-implementatiecontracten |
| `/codeql-critical-quality/agent-runtime-boundary` | Opdrachtuitvoering, model-/provider-dispatch, auto-reply-dispatch en wachtrijen, en ACP-control-plane-runtimecontracten |
| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-servers en toolbruggen, processupervisiehelpers en uitgaande afleveringscontracten |
| `/codeql-critical-quality/memory-runtime-boundary` | Memory-host-SDK, memory-runtimefacades, memory-Plugin SDK-aliassen, memory-runtime-activeringslijm en memory-doctor-opdrachten |
| `/codeql-critical-quality/session-diagnostics-boundary` | Reply-wachtrij-internals, sessieafleveringswachtrijen, uitgaande sessiebinding-/afleveringshelpers, diagnostische event-/logbundeloppervlakken en sessiedoctor-CLI-contracten |
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Plugin SDK-dispatch van inkomende replies, reply-payload-/chunking-/runtimehelpers, kanaalreply-opties, afleveringswachtrijen en sessie-/threadbindinghelpers |
| `/codeql-critical-quality/provider-runtime-boundary` | Modelcatalogusnormalisatie, providerauthenticatie en -discovery, provider-runtimeregistratie, providerstandaarden/-catalogi, en web-/zoek-/fetch-/embeddingregisters |
| `/codeql-critical-quality/ui-control-plane` | Control UI-bootstrap, lokale persistentie, Gateway-controlflows en task-control-plane-runtimecontracten |
| `/codeql-critical-quality/web-media-runtime-boundary` | Core webfetch/-zoekopdrachten, media-IO, mediabegrip, image-generation- en media-generation-runtimecontracten |
| `/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 |
Kwaliteit blijft gescheiden van beveiliging, zodat kwaliteitsbevindingen kunnen worden gepland, gemeten, uitgeschakeld of uitgebreid zonder het beveiligingssignaal te vertroebelen. Swift, Python en gebundelde-Plugin CodeQL-uitbreiding moeten pas weer worden toegevoegd als afgebakend of geshard vervolgwerk nadat de smalle profielen een stabiele runtime en stabiel signaal hebben.
Kwaliteit blijft gescheiden van beveiliging zodat kwaliteitsbevindingen kunnen worden gepland, gemeten, uitgeschakeld of uitgebreid zonder het beveiligingssignaal te vertroebelen. Swift-, Python- en gebundelde-Plugin-CodeQL-uitbreiding moet alleen als scoped of geshard follow-upwerk worden teruggezet nadat de smalle profielen een stabiele runtime en stabiel signaal hebben.
## Onderhoudsworkflows
### Docs Agent
De `Docs Agent`-workflow is een event-gestuurde Codex-onderhoudslane om bestaande docs afgestemd te houden op recent gelande wijzigingen. Deze heeft geen zuiver schema: een succesvolle niet-bot push-CI-run op `main` kan hem triggeren, en manual dispatch kan hem rechtstreeks uitvoeren. Workflow-run-aanroepen worden overgeslagen wanneer `main` inmiddels verder is gegaan of wanneer in het afgelopen uur een andere niet-overgeslagen Docs Agent-run is gemaakt. Wanneer hij draait, beoordeelt hij het commitbereik 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 docspas zijn verzameld.
De `Docs Agent`-workflow is een eventgedreven Codex-onderhoudslane om bestaande docs 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 manual dispatch kan hem direct uitvoeren. Workflow-run-aanroepen slaan over wanneer `main` inmiddels verder is of wanneer er in het afgelopen uur een andere niet-overgeslagen Docs Agent-run is aangemaakt. Wanneer hij draait, beoordeelt 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.
### Test Performance Agent
De `Test Performance Agent`-workflow is een event-gestuurde Codex-onderhoudslane voor trage tests. Deze heeft geen zuiver schema: een succesvolle niet-bot push-CI-run op `main` kan hem triggeren, maar hij wordt overgeslagen als die UTC-dag al een andere workflow-run-aanroep heeft gedraaid of draait. Manual dispatch omzeilt die dagelijkse activiteitsgate. De lane bouwt een full-suite gegroepeerd Vitest-prestatierapport, laat Codex alleen kleine dekkingsbehoudende testprestatieverbeteringen doen in plaats van brede refactors, draait daarna het full-suite rapport opnieuw en weigert wijzigingen die het baseline-aantal geslaagde tests verlagen. Als de baseline falende tests heeft, mag Codex alleen duidelijke failures oplossen en moet het full-suite rapport na de agent slagen voordat iets wordt gecommit. Wanneer `main` verder gaat voordat de bot-push landt, rebased de lane de gevalideerde patch, draait `pnpm check:changed` opnieuw en probeert de push opnieuw; conflicterende verouderde patches worden overgeslagen. De lane 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 op die UTC-dag al een andere workflow-run-aanroep heeft gedraaid of draait. Manual dispatch omzeilt die dagelijkse activiteitsgate. De lane bouwt een full-suite gegroepeerd Vitest-prestatierapport, laat Codex alleen kleine dekkingsbehoudende testprestatieverbeteringen maken in plaats van brede refactors, draait daarna het full-suite rapport opnieuw en wijst wijzigingen af die het baseline-aantal geslaagde tests verminderen. Als de baseline falende tests heeft, mag Codex alleen duidelijke fouten repareren 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, draait `pnpm check:changed` opnieuw en probeert de push opnieuw; conflicterende verouderde patches worden overgeslagen. Hij gebruikt GitHub-hosted Ubuntu zodat de Codex-action dezelfde drop-sudo-veiligheidshouding kan behouden als de docs-agent.
### Dubbele PR's na merge
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 gemuteerd, verifieert de workflow dat de gelande PR is gemerged en dat elke duplicate een gedeeld gerefereerd issue of overlappende gewijzigde hunks heeft.
De `Duplicate PRs After Merge`-workflow is een handmatige maintainer-workflow voor het opruimen van duplicaten na landen. Hij staat standaard op dry-run en sluit alleen expliciet vermelde PR's wanneer `apply=true`. Voordat hij GitHub muteert, controleert hij of de gelande PR is gemerged en of elk duplicaat ofwel een gedeeld gerefereerd issue heeft of overlappende gewijzigde hunks.
```bash
gh workflow run duplicate-after-merge.yml \
@ -392,29 +392,29 @@ gh workflow run duplicate-after-merge.yml \
-f apply=true
```
## Lokale check-gates en gewijzigde routering
## Lokale checkgates en gewijzigde 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 checkgate is strenger over architectuurgrenzen dan de brede CI-platformscope:
- wijzigingen in core productie draaien core prod- en core test-typecheck plus core lint/guards;
- wijzigingen die alleen core tests raken, draaien alleen core test-typecheck plus core lint;
- wijzigingen in extensieproductie draaien extensie prod- en extensie test-typecheck plus extensie lint;
- wijzigingen die alleen extensietests raken, draaien extensie test-typecheck plus extensie lint;
- wijzigingen in publieke Plugin SDK of plugin-contract breiden uit naar extensie-typecheck omdat extensies van die core-contracten afhankelijk zijn (Vitest-extensiesweeps blijven expliciet testwerk);
- release-metadata-only versiebumpen draaien gerichte versie-/config-/root-dependency-checks;
- onbekende root-/configwijzigingen vallen veilig terug naar alle check-lanes.
- coreproductiewijzigingen draaien core prod- en core test-typecheck plus core lint/guards;
- wijzigingen die alleen coretests raken draaien alleen core test-typecheck plus core lint;
- extensieproductiewijzigingen draaien extensie prod- en extensie test-typecheck plus extensie lint;
- wijzigingen die alleen extensietests raken draaien extensie test-typecheck plus extensie lint;
- publieke Plugin SDK- of Plugin-contractwijzigingen breiden uit naar extensietypecheck omdat extensies afhankelijk zijn van die corecontracten (Vitest-extensiesweeps blijven expliciet testwerk);
- release-metadata-only versiebumps draaien gerichte versie-/config-/rootdependency-checks;
- onbekende root-/configwijzigingen falen veilig naar alle checklanes.
Lokale changed-test-routering staat in `scripts/test-projects.test-support.mjs` en is bewust goedkoper dan `check:changed`: directe testbewerkingen draaien zichzelf, bronbewerkingen geven de voorkeur aan expliciete mappings, daarna sibling-tests en import-graph-afhankelijken. Gedeelde group-room delivery-configuratie 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 defaultwijziging faalt vóór de eerste PR-push. Gebruik `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` alleen wanneer de wijziging breed genoeg is voor de harness 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 testbewerkingen draaien zichzelf, bronbewerkingen geven de voorkeur aan expliciete mappings, daarna siblingtests en import-graph-afhankelijken. Gedeelde group-room-afleveringsconfiguratie is een van de expliciete mappings: wijzigingen aan de group-visible-reply-configuratie, source-reply-afleveringsmodus of de message-tool-systeemprompt lopen via de core reply-tests plus Discord- en Slack-afleveringsregressies zodat een gedeelde standaardwijziging faalt vóór de eerste PR-push. Gebruik `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` alleen wanneer de wijziging harness-breed genoeg is dat de goedkope gemapte set geen betrouwbare proxy is.
## Testbox-validatie
Draai Testbox vanuit de repo-root en geef voor breed bewijs de voorkeur aan een nieuwe voorverwarmde box. Voordat je een trage gate besteedt aan een box die opnieuw is gebruikt, verlopen is of net een onverwacht grote sync rapporteerde, draai eerst `pnpm testbox:sanity` in de box.
Draai Testbox vanuit de repo-root en geef voor brede bewijsvoering de voorkeur aan een vers opgewarmde box. Voordat je een trage gate besteedt aan een box die is hergebruikt, verlopen is of net een onverwacht grote sync meldde, draai je eerst `pnpm testbox:sanity` binnen de box.
De sanity-check faalt snel wanneer vereiste rootbestanden zoals `pnpm-lock.yaml` verdwenen zijn of wanneer `git status --short` ten minste 200 getrackte deletions toont. Dat betekent meestal dat de externe syncstatus geen betrouwbare kopie van de PR is; stop die box en warm een nieuwe op in plaats van de producttestfailure te debuggen. Voor opzettelijke PR's met grote deletions stel je `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` in voor die sanity-run.
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 sync-state geen betrouwbare kopie van de PR is; stop die box en warm een verse op in plaats van de producttestfout te debuggen. Stel voor opzettelijke PR's met veel verwijderingen `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 syncfase blijft zonder post-sync-output. Stel `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` in om die guard uit te schakelen, of gebruik een grotere millisecondewaarde voor ongewoon grote lokale diffs.
`pnpm testbox:run` beëindigt ook een lokale Blacksmith CLI-aanroep die langer dan vijf minuten in de sync-fase blijft zonder post-sync-uitvoer. Stel `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` in om die guard uit te schakelen, of gebruik een grotere millisecondenwaarde voor ongewoon grote lokale diffs.
## Gerelateerd
- [Installatieoverzicht](/nl/install)
- [Ontwikkelkanalen](/nl/install/development-channels)
- [Ontwikkelingskanalen](/nl/install/development-channels)

169
docs/nl/concepts/agent-loop.md
View File

@ -1,190 +1,191 @@
---
read_when:
- Je hebt een exacte doorloop van de agentlus of levenscyclusgebeurtenissen nodig
- Je wijzigt sessiewachtrijen, transcript-schrijfbewerkingen of het gedrag van sessieschrijfvergrendelingen
summary: Levenscyclus van de agentloop, streams en wachtsemantiek
- Je hebt een nauwkeurige stapsgewijze uitleg van de agentlus of levenscyclusgebeurtenissen nodig
- U wijzigt sessiewachtrijen, transcript-schrijfbewerkingen of het gedrag van de schrijflock voor sessies.
summary: Levenscyclus van de agentlus, stromen en wachtsemantiek
title: Agentlus
x-i18n:
generated_at: "2026-04-29T22:36:34Z"
generated_at: "2026-04-30T18:38:48Z"
model: gpt-5.5
provider: openai
source_hash: 902d543bd71dd517a810d825cbe92e244fe89230f47eeada72477c657a2bec32
source_hash: 5466893253e1f82482284ff82db56f4c3fca018bf12e4114fad76d37cad954df
source_path: concepts/agent-loop.md
workflow: 16
---
Een agentic loop is de volledige “echte” uitvoering van een agent: intake → contextassemblage → modelinferentie →
tooluitvoering → streaming-antwoorden → persistentie. Dit is het gezaghebbende pad dat een bericht
Een agentische loop is de volledige “echte” uitvoering van een agent: intake → contextassemblage → modelinferentie →
tooluitvoering → streamingantwoorden → persistentie. Het is het gezaghebbende pad dat een bericht
omzet in acties en een definitief antwoord, terwijl de sessiestatus consistent blijft.
In OpenClaw is een loop één enkele, geserialiseerde uitvoering per sessie die lifecycle- en stream-events emit
In OpenClaw is een loop een enkele, geserialiseerde uitvoering per sessie die lifecycle- en stream-events uitzendt
terwijl het model denkt, tools aanroept en uitvoer streamt. Dit document legt uit hoe die authentieke loop
end-to-end is bedraad.
## Entry points
## Ingangspunten
- Gateway-RPC: `agent` en `agent.wait`.
- CLI: opdracht `agent`.
## Hoe het werkt (op hoofdlijnen)
## Hoe het werkt (op hoog niveau)
1. `agent` RPC valideert parameters, lost de sessie op (sessionKey/sessionId), persisteert sessiemetadata en retourneert direct `{ runId, acceptedAt }`.
1. `agent`-RPC valideert parameters, lost de sessie op (sessionKey/sessionId), bewaart sessiemetadata en retourneert meteen `{ runId, acceptedAt }`.
2. `agentCommand` voert de agent uit:
- lost model + standaardwaarden voor thinking/verbose/trace op
- lost model- en thinking/verbose/trace-standaardwaarden op
- laadt Skills-snapshot
- roept `runEmbeddedPiAgent` aan (pi-agent-core-runtime)
- emit **lifecycle end/error** als de embedded loop er geen emit
- roept `runEmbeddedPiAgent` aan (pi-agent-core runtime)
- zendt **lifecycle end/error** uit als de embedded loop er geen uitzendt
3. `runEmbeddedPiAgent`:
- serialiseert uitvoeringen via per-sessie- en globale wachtrijen
- lost model + auth-profiel op en bouwt de Pi-sessie
- abonneert zich op Pi-events en streamt assistant/tool-delta's
- handhaaft timeout -> breekt uitvoering af als die wordt overschreden
- retourneert payloads + gebruiksmetadata
4. `subscribeEmbeddedPiSession` brugt pi-agent-core-events naar de OpenClaw-`agent`-stream:
- serialiseert uitvoeringen via wachtrijen per sessie en globale wachtrijen
- lost model en auth-profiel op en bouwt de Pi-sessie
- abonneert zich op Pi-events en streamt assistant/tool-delta’s
- dwingt timeout af -> breekt uitvoering af als deze wordt overschreden
- breekt voor Codex app-server-beurten een geaccepteerde beurt af die geen app-server-voortgang meer produceert vóór een terminal event
- retourneert payloads en gebruiksmetadata
4. `subscribeEmbeddedPiSession` overbrugt pi-agent-core-events naar de OpenClaw `agent`-stream:
- tool-events => `stream: "tool"`
- assistant-delta's => `stream: "assistant"`
- assistant-delta’s => `stream: "assistant"`
- lifecycle-events => `stream: "lifecycle"` (`phase: "start" | "end" | "error"`)
5. `agent.wait` gebruikt `waitForAgentRun`:
- wacht op **lifecycle end/error** voor `runId`
- retourneert `{ status: ok|error|timeout, startedAt, endedAt, error? }`
## Wachtrijen + concurrency
## Wachtrijen + gelijktijdigheid
- Uitvoeringen worden per sessiesleutel (sessielane) geserialiseerd en optioneel via een globale lane.
- Uitvoeringen worden per sessiesleutel (sessielaan) geserialiseerd en optioneel via een globale laan geleid.
- Dit voorkomt tool-/sessieraces en houdt de sessiegeschiedenis consistent.
- Berichtkanalen kunnen wachtrijmodi kiezen (collect/steer/followup) die dit lanesysteem voeden.
- Berichtkanalen kunnen wachtrijmodi kiezen (collect/steer/followup) die dit laansysteem voeden.
Zie [Opdrachtwachtrij](/nl/concepts/queue).
- Transcriptwrites worden ook beschermd door een sessie-writelock op het sessiebestand. De lock is
procesbewust en bestandsgebaseerd, zodat die writers opvangt die de in-process wachtrij omzeilen of uit
- Transcriptwrites worden ook beschermd door een sessieschrijflock op het sessiebestand. De lock is
procesbewust en bestandsgebaseerd, zodat schrijvers worden opgemerkt die de in-process-wachtrij omzeilen of uit
een ander proces komen.
- Sessie-writelocks zijn standaard niet-reentrant. Als een helper bewust het verkrijgen van
dezelfde lock nest terwijl één logische writer behouden blijft, moet die daar expliciet voor kiezen met
- Sessieschrijflocks zijn standaard niet-reentrant. Als een helper bewust het verkrijgen van
dezelfde lock nest terwijl één logische schrijver behouden blijft, moet die expliciet opt-innen met
`allowReentrant: true`.
## Sessie- + werkruimtevoorbereiding
## Sessie- en werkruimtevoorbereiding
- De werkruimte wordt opgelost en aangemaakt; sandboxed uitvoeringen kunnen worden omgeleid naar een sandbox-werkruimteroot.
- Skills worden geladen (of hergebruikt uit een snapshot) en geïnjecteerd in env en prompt.
- Bootstrap-/contextbestanden worden opgelost en geïnjecteerd in het systeempromptrapport.
- Er wordt een sessie-writelock verkregen; `SessionManager` wordt geopend en voorbereid vóór streaming. Elk
later pad voor transcript rewrite, Compaction of truncatie moet dezelfde lock nemen voordat het transcriptbestand wordt geopend of
- De werkruimte wordt opgelost en aangemaakt; sandboxed uitvoeringen kunnen omleiden naar een sandbox-werkruimteroot.
- Skills worden geladen (of hergebruikt vanuit een snapshot) en geïnjecteerd in env en prompt.
- Bootstrap-/contextbestanden worden opgelost en geïnjecteerd in het systeemprompt-rapport.
- Er wordt een sessieschrijflock verkregen; `SessionManager` wordt geopend en voorbereid vóór streaming. Elk
later pad voor transcriptherschrijven, Compaction of afkapping moet dezelfde lock nemen voordat het transcriptbestand wordt geopend of
gemuteerd.
## Promptassemblage + systeemprompt
- De systeemprompt wordt opgebouwd uit de basisprompt van OpenClaw, Skills-prompt, bootstrapcontext en per-uitvoering-overrides.
- Modelspecifieke limieten en Compaction-reservetokens worden afgedwongen.
- De systeemprompt wordt gebouwd uit de basisprompt van OpenClaw, de Skills-prompt, bootstrapcontext en overrides per uitvoering.
- Modelspecifieke limieten en gereserveerde tokens voor Compaction worden afgedwongen.
- Zie [Systeemprompt](/nl/concepts/system-prompt) voor wat het model ziet.
## Hookpunten (waar je kunt onderscheppen)
OpenClaw heeft twee hooksystemen:
- **Interne hooks** (Gateway-hooks): eventgestuurde scripts voor opdrachten en lifecycle-events.
- **Interne hooks** (Gateway-hooks): eventgedreven scripts voor opdrachten en lifecycle-events.
- **Plugin-hooks**: uitbreidingspunten binnen de agent-/tool-lifecycle en Gateway-pipeline.
### Interne hooks (Gateway-hooks)
- **`agent:bootstrap`**: draait tijdens het bouwen van bootstrapbestanden voordat de systeemprompt definitief wordt gemaakt.
Gebruik dit om bootstrapcontextbestanden toe te voegen of te verwijderen.
- **Opdrachthooks**: `/new`, `/reset`, `/stop` en andere opdrachtevents (zie Hooks-documentatie).
- **Opdrachthooks**: `/new`, `/reset`, `/stop` en andere opdracht-events (zie het Hooks-document).
Zie [Hooks](/nl/automation/hooks) voor setup en voorbeelden.
Zie [Hooks](/nl/automation/hooks) voor configuratie en voorbeelden.
### Plugin-hooks (agent- + Gateway-lifecycle)
Deze draaien binnen de agent-loop of Gateway-pipeline:
Deze draaien binnen de agentloop of Gateway-pipeline:
- **`before_model_resolve`**: draait pre-sessie (geen `messages`) om provider/model deterministisch te overschrijven vóór modelresolutie.
- **`before_prompt_build`**: draait na sessielaadstap (met `messages`) om `prependContext`, `systemPrompt`, `prependSystemContext` of `appendSystemContext` te injecteren vóór promptinzending. Gebruik `prependContext` voor dynamische tekst per beurt en system-context-velden voor stabiele richtlijnen die in de systeempromptruimte moeten staan.
- **`before_prompt_build`**: draait na sessielading (met `messages`) om `prependContext`, `systemPrompt`, `prependSystemContext` of `appendSystemContext` te injecteren vóór promptindiening. Gebruik `prependContext` voor dynamische tekst per beurt en systeemcontextvelden voor stabiele richtlijnen die in systeempromptruimte moeten staan.
- **`before_agent_start`**: legacy-compatibiliteitshook die in beide fasen kan draaien; geef de voorkeur aan de expliciete hooks hierboven.
- **`before_agent_reply`**: draait na inline acties en vóór de LLM-aanroep, zodat een Plugin de beurt kan claimen en een synthetisch antwoord kan retourneren of de beurt volledig kan dempen.
- **`agent_end`**: inspecteer de uiteindelijke berichtenlijst en uitvoeringsmetadata na voltooiing.
- **`before_agent_reply`**: draait na inline acties en vóór de LLM-aanroep, zodat een Plugin de beurt kan claimen en een synthetisch antwoord kan retourneren of de beurt volledig kan stilhouden.
- **`agent_end`**: inspecteer de definitieve berichtenlijst en uitvoeringsmetadata na voltooiing.
- **`before_compaction` / `after_compaction`**: observeer of annoteer Compaction-cycli.
- **`before_tool_call` / `after_tool_call`**: onderschep toolparameters/-resultaten.
- **`before_install`**: inspecteer ingebouwde scanbevindingen en blokkeer optioneel installatie van Skills of Plugins.
- **`tool_result_persist`**: transformeer toolresultaten synchroon voordat ze worden weggeschreven naar een sessietranscript dat eigendom is van OpenClaw.
- **`message_received` / `message_sending` / `message_sent`**: inbound + outbound berichthooks.
- **`session_start` / `session_end`**: grenzen van de sessie-lifecycle.
- **`before_install`**: inspecteer ingebouwde scanbevindingen en blokkeer optioneel Skill- of Plugin-installaties.
- **`tool_result_persist`**: transformeer toolresultaten synchroon voordat ze naar een door OpenClaw beheerd sessietranscript worden geschreven.
- **`message_received` / `message_sending` / `message_sent`**: hooks voor inkomende en uitgaande berichten.
- **`session_start` / `session_end`**: sessie-lifecyclegrenzen.
- **`gateway_start` / `gateway_stop`**: Gateway-lifecycle-events.
Beslisregels voor hooks voor outbound/tool-guards:
Beslisregels voor hooks voor uitgaande/tool-guards:
- `before_tool_call`: `{ block: true }` is terminaal en stopt handlers met lagere prioriteit.
- `before_tool_call`: `{ block: false }` is een no-op en heft een eerdere blokkade niet op.
- `before_tool_call`: `{ block: false }` is een no-op en wist een eerdere blokkade niet.
- `before_install`: `{ block: true }` is terminaal en stopt handlers met lagere prioriteit.
- `before_install`: `{ block: false }` is een no-op en heft een eerdere blokkade niet op.
- `before_install`: `{ block: false }` is een no-op en wist een eerdere blokkade niet.
- `message_sending`: `{ cancel: true }` is terminaal en stopt handlers met lagere prioriteit.
- `message_sending`: `{ cancel: false }` is een no-op en heft een eerdere annulering niet op.
- `message_sending`: `{ cancel: false }` is een no-op en wist een eerdere annulering niet.
Zie [Plugin-hooks](/nl/plugins/hooks) voor de hook-API en registratiedetails.
Harnesses kunnen deze hooks anders adapteren. De Codex app-server-harness behoudt
Harnesses kunnen deze hooks anders aanpassen. De Codex app-server-harness behoudt
OpenClaw Plugin-hooks als het compatibiliteitscontract voor gedocumenteerde gespiegeld
oppervlakken, terwijl native Codex-hooks een afzonderlijk Codex-mechanisme op lager niveau blijven.
oppervlakken, terwijl native Codex-hooks een apart lager niveau Codex-mechanisme blijven.
## Streaming + gedeeltelijke antwoorden
- Assistant-delta's worden gestreamd vanuit pi-agent-core en als `assistant`-events geëmit.
- Blokstreaming kan gedeeltelijke antwoorden emitten op `text_end` of `message_end`.
- Reasoning-streaming kan worden geëmit als een afzonderlijke stream of als blokantwoorden.
- Zie [Streaming](/nl/concepts/streaming) voor chunking- en blokantwoordgedrag.
- Assistant-delta’s worden vanuit pi-agent-core gestreamd en als `assistant`-events uitgezonden.
- Block-streaming kan gedeeltelijke antwoorden uitzenden op `text_end` of `message_end`.
- Reasoning-streaming kan worden uitgezonden als een aparte stream of als blokantwoorden.
- Zie [Streaming](/nl/concepts/streaming) voor chunking en blokantwoordgedrag.
## Tooluitvoering + berichtentools
## Tooluitvoering + berichttools
- Toolstart-/update-/end-events worden geëmit op de `tool`-stream.
- Toolresultaten worden gesanitized voor grootte en afbeeldingspayloads voordat ze worden gelogd/geëmit.
- Verzendingen door berichtentools worden bijgehouden om dubbele assistant-bevestigingen te onderdrukken.
- Events voor tool-start/update/end worden uitgezonden op de `tool`-stream.
- Toolresultaten worden gesanitized voor grootte en image-payloads voordat ze worden gelogd/uitgezonden.
- Verzendingen met berichttools worden bijgehouden om dubbele assistant-bevestigingen te onderdrukken.
## Antwoordvorming + onderdrukking
- Definitieve payloads worden samengesteld uit:
- assistant-tekst (en optioneel reasoning)
- assistant-tekst (en optionele reasoning)
- inline toolsamenvattingen (wanneer verbose + toegestaan)
- assistant-fouttekst wanneer het model een fout geeft
- Het exacte stille token `NO_REPLY` / `no_reply` wordt uit outgoing
- assistant-fouttekst wanneer het model fouten geeft
- Het exacte stille token `NO_REPLY` / `no_reply` wordt uit uitgaande
payloads gefilterd.
- Duplicaten van berichtentools worden verwijderd uit de definitieve payloadlijst.
- Als er geen renderbare payloads overblijven en een tool een fout gaf, wordt een fallback-toolfoutantwoord geëmit
(tenzij een berichtentool al een voor de gebruiker zichtbaar antwoord heeft verzonden).
- Duplicaten van berichttools worden uit de definitieve payloadlijst verwijderd.
- Als er geen renderbare payloads overblijven en een tool een fout gaf, wordt een fallback-toolfoutantwoord uitgezonden
(tenzij een berichttool al een voor de gebruiker zichtbaar antwoord heeft verzonden).
## Compaction + retries
## Compaction + nieuwe pogingen
- Auto-Compaction emit `compaction`-streamevents en kan een retry triggeren.
- Bij een retry worden in-memory buffers en toolsamenvattingen gereset om dubbele uitvoer te voorkomen.
- Auto-Compaction zendt `compaction`-streamevents uit en kan een nieuwe poging triggeren.
- Bij een nieuwe poging worden in-memory buffers en toolsamenvattingen gereset om dubbele uitvoer te voorkomen.
- Zie [Compaction](/nl/concepts/compaction) voor de Compaction-pipeline.
## Eventstreams (vandaag)
- `lifecycle`: geëmit door `subscribeEmbeddedPiSession` (en als fallback door `agentCommand`)
- `assistant`: gestreamde delta's vanuit pi-agent-core
- `lifecycle`: uitgezonden door `subscribeEmbeddedPiSession` (en als fallback door `agentCommand`)
- `assistant`: gestreamde delta’s vanuit pi-agent-core
- `tool`: gestreamde tool-events vanuit pi-agent-core
## Chatkanaalafhandeling
- Assistant-delta's worden gebufferd in chat-`delta`-berichten.
- Een chat-`final` wordt geëmit bij **lifecycle end/error**.
- Assistant-delta’s worden gebufferd in chat-`delta`-berichten.
- Een chat-`final` wordt uitgezonden bij **lifecycle end/error**.
## Timeouts
- Standaard voor `agent.wait`: 30s (alleen het wachten). Parameter `timeoutMs` overschrijft dit.
- Agentruntime: `agents.defaults.timeoutSeconds` standaard 172800s (48 uur); afgedwongen in de aborttimer van `runEmbeddedPiAgent`.
- Cron-runtime: geïsoleerde agent-turn `timeoutSeconds` is eigendom van Cron. De scheduler start die timer wanneer uitvoering begint, breekt de onderliggende uitvoering af op de geconfigureerde deadline en voert daarna begrensde cleanup uit voordat de timeout wordt vastgelegd, zodat een verouderde child-sessie de lane niet vast kan houden.
- Herstel van vastgelopen sessie: met diagnostics ingeschakeld detecteert `diagnostics.stuckSessionWarnMs` lange `processing`-sessies. Actieve embedded uitvoeringen, actieve antwoordoperaties en actieve sessie-lane-taken blijven standaard alleen waarschuwingen; als diagnostics geen actief werk voor de sessie tonen, geeft de watchdog de getroffen sessielane vrij zodat queued opstartwerk kan leeglopen.
- Model-idletimeout: OpenClaw breekt een modelrequest af wanneer er geen response chunks binnenkomen vóór het idle-venster. `models.providers.<id>.timeoutSeconds` verlengt deze idle-watchdog voor trage lokale/self-hosted providers; anders gebruikt OpenClaw `agents.defaults.timeoutSeconds` wanneer geconfigureerd, standaard begrensd op 120s. Door Cron getriggerde uitvoeringen zonder expliciete model- of agenttimeout schakelen de idle-watchdog uit en vertrouwen op de buitenste Cron-timeout.
- Provider-HTTP-requesttimeout: `models.providers.<id>.timeoutSeconds` is van toepassing op de model-HTTP-fetches van die provider, inclusief connect, headers, body, SDK-requesttimeout, totale guarded-fetch-aborthandling en modelstream-idle-watchdog. Gebruik dit voor trage lokale/self-hosted providers zoals Ollama voordat je de volledige agentruntime-timeout verhoogt.
- Agent-runtime: `agents.defaults.timeoutSeconds` standaard 172800s (48 uur); afgedwongen in de afbreektimer van `runEmbeddedPiAgent`.
- Cron-runtime: geïsoleerde agent-turn `timeoutSeconds` is eigendom van Cron. De scheduler start die timer wanneer de uitvoering begint, breekt de onderliggende uitvoering af op de geconfigureerde deadline en voert daarna begrensde opschoning uit voordat de timeout wordt vastgelegd, zodat een verouderde child-sessie de laan niet vast kan houden.
- Herstel van vastgelopen sessies: met diagnostiek ingeschakeld detecteert `diagnostics.stuckSessionWarnMs` langdurige `processing`-sessies. Actieve embedded uitvoeringen, actieve antwoordoperaties en actieve sessielaan-taken blijven standaard alleen waarschuwingen; als diagnostiek geen actief werk voor de sessie toont, geeft de watchdog de betrokken sessielaan vrij zodat werk in de opstartwachtrij kan doorstromen.
- Model-inactiviteitstimeout: OpenClaw breekt een modelrequest af wanneer er geen responsechunks arriveren vóór het inactiviteitsvenster. `models.providers.<id>.timeoutSeconds` verlengt deze inactiviteitswatchdog voor trage local loopback/zelfgehoste providers; anders gebruikt OpenClaw `agents.defaults.timeoutSeconds` wanneer geconfigureerd, standaard afgetopt op 120s. Door Cron getriggerde uitvoeringen zonder expliciete model- of agenttimeout schakelen de inactiviteitswatchdog uit en vertrouwen op de buitenste Cron-timeout.
- Timeout voor provider-HTTP-request: `models.providers.<id>.timeoutSeconds` geldt voor de model-HTTP-fetches van die provider, inclusief connect, headers, body, SDK-requesttimeout, totale guarded-fetch-afbreekafhandeling en modelstream-inactiviteitswatchdog. Gebruik dit voor trage local loopback/zelfgehoste providers zoals Ollama voordat je de runtime-timeout van de hele agent verhoogt.
## Waar dingen vroeg kunnen eindigen
- Agenttimeout (abort)
- AbortSignal (cancel)
- Gateway-disconnect of RPC-timeout
- Agenttimeout (afbreken)
- AbortSignal (annuleren)
- Gateway-verbinding verbroken of RPC-timeout
- `agent.wait`-timeout (alleen wachten, stopt agent niet)
## Gerelateerd
- [Tools](/nl/tools) — beschikbare agenttools
- [Hooks](/nl/automation/hooks) — eventgestuurde scripts die worden getriggerd door agent-lifecycle-events
- [Hooks](/nl/automation/hooks) — eventgedreven scripts getriggerd door agent-lifecycle-events
- [Compaction](/nl/concepts/compaction) — hoe lange gesprekken worden samengevat
- [Exec-goedkeuringen](/nl/tools/exec-approvals) — goedkeuringspoorten voor shellopdrachten
- [Thinking](/nl/tools/thinking) — configuratie van thinking-/reasoningniveau
- [Thinking](/nl/tools/thinking) — configuratie van thinking-/reasoning-niveau

98
docs/nl/concepts/queue.md
View File

@ -1,36 +1,36 @@
---
read_when:
- Uitvoering of gelijktijdigheid van automatische antwoorden wijzigen
- Uitleg over /queue-modi of gedrag voor berichtsturing
summary: Wachtrijmodi voor automatische antwoorden, standaardinstellingen en overschrijvingen per sessie
title: Opdrachtwachtrij
- De uitvoering of gelijktijdigheid van automatische antwoorden wijzigen
- Uitleg over /queue-modi of berichtsturingsgedrag
summary: Wachtrijmodi voor automatische antwoorden, standaardwaarden en overschrijvingen per sessie
title: Opdrachtenwachtrij
x-i18n:
generated_at: "2026-04-30T09:36:26Z"
generated_at: "2026-04-30T18:38:47Z"
model: gpt-5.5
provider: openai
source_hash: 2ac0c0ded9558b080714fa4b8be0d552f985911bf19b427020f9654ae4955b2d
source_hash: fbf1bb1ffd4ce06fa138f63e31651b8821226d9c95dd6b93d68326a5fb91fdd0
source_path: concepts/queue.md
workflow: 16
---
We serialiseren inkomende auto-antwoorduitvoeringen (alle kanalen) via een kleine in-process wachtrij om te voorkomen dat meerdere agentuitvoeringen botsen, terwijl veilige parallelliteit tussen sessies mogelijk blijft.
We serialiseren inkomende auto-reply-uitvoeringen (alle kanalen) via een kleine in-process wachtrij om te voorkomen dat meerdere agentuitvoeringen botsen, terwijl veilige parallelliteit tussen sessies mogelijk blijft.
## Waarom
- Auto-antwoorduitvoeringen kunnen kostbaar zijn (LLM-aanroepen) en kunnen botsen wanneer meerdere inkomende berichten kort na elkaar aankomen.
- Serialiseren voorkomt concurrentie om gedeelde resources (sessiebestanden, logs, CLI stdin) en verkleint de kans op upstream-ratelimits.
- Auto-reply-uitvoeringen kunnen duur zijn (LLM-aanroepen) en kunnen botsen wanneer meerdere inkomende berichten kort na elkaar binnenkomen.
- Serialiseren voorkomt concurrentie om gedeelde resources (sessiebestanden, logs, CLI stdin) en vermindert de kans op upstream-rate limits.
## Hoe het werkt
- Een lane-bewuste FIFO-wachtrij verwerkt elke lane met een configureerbare concurrency-limiet (standaard 1 voor niet-geconfigureerde lanes; main is standaard 4, subagent 8).
- `runEmbeddedPiAgent` plaatst in de wachtrij op **sessiesleutel** (lane `session:<key>`) om te garanderen dat er slechts één actieve uitvoering per sessie is.
- Elke sessie-uitvoering wordt daarna in een **globale lane** (`main` standaard) geplaatst, zodat de totale parallelliteit wordt begrensd door `agents.defaults.maxConcurrent`.
- Wanneer uitgebreide logging is ingeschakeld, sturen wachtrij-uitvoeringen een korte melding als ze meer dan ~2s moesten wachten voordat ze startten.
- Typindicatoren worden nog steeds direct bij het plaatsen in de wachtrij geactiveerd (wanneer het kanaal dit ondersteunt), zodat de gebruikerservaring ongewijzigd blijft terwijl we op onze beurt wachten.
- Een lane-bewuste FIFO-wachtrij verwerkt elke lane met een configureerbare concurrency-limiet (standaard 1 voor niet-geconfigureerde lanes; main standaard 4, subagent 8).
- `runEmbeddedPiAgent` plaatst in de wachtrij op basis van **sessiesleutel** (lane `session:<key>`) om te garanderen dat er slechts één actieve uitvoering per sessie is.
- Elke sessie-uitvoering wordt daarna in een **globale lane** geplaatst (`main` standaard), zodat de totale parallelliteit wordt begrensd door `agents.defaults.maxConcurrent`.
- Wanneer verbose logging is ingeschakeld, geven uitvoeringen in de wachtrij een korte melding als ze meer dan ~2 s hebben gewacht voordat ze startten.
- Typing indicators starten nog steeds direct bij het plaatsen in de wachtrij (wanneer ondersteund door het kanaal), zodat de gebruikerservaring ongewijzigd blijft terwijl we op onze beurt wachten.
## Standaardwaarden
## Standaarden
Wanneer niets is ingesteld, gebruiken alle inkomende kanaaloppervlakken:
Wanneer niet ingesteld, gebruiken alle inkomende kanaaloppervlakken:
- `mode: "steer"`
- `debounceMs: 500`
@ -38,26 +38,26 @@ Wanneer niets is ingesteld, gebruiken alle inkomende kanaaloppervlakken:
- `drop: "summarize"`
`steer` is de standaard omdat het de actieve modelbeurt responsief houdt zonder
een tweede sessie-uitvoering te starten. Het verwerkt alle sturingsberichten die
vóór de volgende modelgrens zijn aangekomen. Als de huidige uitvoering geen
sturing kan accepteren, valt OpenClaw terug op een followup-wachtrijitem.
een tweede sessie-uitvoering te starten. Het verwerkt alle stuurberichten die zijn aangekomen
vóór de volgende modelgrens. Als de huidige uitvoering geen sturing kan accepteren,
valt OpenClaw terug op een followup-wachtrijitem.
## Wachtrijmodi
Inkomende berichten kunnen de huidige uitvoering sturen, wachten op een followup-beurt, of beide doen:
- `steer`: plaats sturingsberichten in de actieve runtime. Pi levert alle wachtende sturingsberichten **nadat de huidige assistentbeurt klaar is met het uitvoeren van zijn toolaanroepen**, vóór de volgende LLM-aanroep; Codex app-server ontvangt één gebatchte `turn/steer`. Als de uitvoering niet actief streamt of sturing niet beschikbaar is, valt OpenClaw terug op een followup-wachtrijitem.
- `queue` (legacy): oude een-voor-een-sturing. Pi levert één wachtrij-sturingsbericht bij elke modelgrens; Codex app-server ontvangt afzonderlijke `turn/steer`-verzoeken. Geef de voorkeur aan `steer`, tenzij je het vorige geserialiseerde gedrag nodig hebt.
- `steer`: plaats stuurberichten in de actieve runtime. Pi levert alle wachtende stuurberichten **nadat de huidige assistentbeurt klaar is met het uitvoeren van de toolaanroepen**, vóór de volgende LLM-aanroep; Codex app-server ontvangt één gebatchte `turn/steer`. Als de uitvoering niet actief streamt of sturing niet beschikbaar is, valt OpenClaw terug op een followup-wachtrijitem.
- `queue` (legacy): oude één-voor-één-sturing. Pi levert één stuurbericht uit de wachtrij bij elke modelgrens; Codex app-server ontvangt afzonderlijke `turn/steer`-requests. Geef de voorkeur aan `steer`, tenzij je het vorige geserialiseerde gedrag nodig hebt.
- `followup`: plaats elk bericht in de wachtrij voor een latere agentbeurt nadat de huidige uitvoering eindigt.
- `collect`: voeg wachtrijberichten samen tot één **enkele** followup-beurt na het stille venster. Als berichten op verschillende kanalen/threads zijn gericht, worden ze afzonderlijk verwerkt om routering te behouden.
- `collect`: voeg berichten in de wachtrij samen tot een **enkele** followup-beurt na het stille venster. Als berichten op verschillende kanalen/threads zijn gericht, worden ze afzonderlijk verwerkt om routing te behouden.
- `steer-backlog` (ook bekend als `steer+backlog`): stuur nu **en** bewaar hetzelfde bericht voor een followup-beurt.
- `interrupt` (legacy): breek de actieve uitvoering voor die sessie af en voer daarna het nieuwste bericht uit.
Steer-backlog betekent dat je na de gestuurde uitvoering een followup-antwoord
kunt krijgen, waardoor streaming-oppervlakken op duplicaten kunnen lijken. Geef
de voorkeur aan `collect`/`steer` als je één antwoord per inkomend bericht wilt.
Steer-backlog betekent dat je een followup-reactie kunt krijgen na de gestuurde uitvoering, waardoor
streaming-oppervlakken op duplicaten kunnen lijken. Geef de voorkeur aan `collect`/`steer` als je
één reactie per inkomend bericht wilt.
Zie voor runtime-specifieke timing en afhankelijkheidsgedrag
Zie voor runtimespecifieke timing en afhankelijkheidsgedrag
[Sturingswachtrij](/nl/concepts/queue-steering).
Configureer globaal of per kanaal via `messages.queue`:
@ -78,50 +78,50 @@ Configureer globaal of per kanaal via `messages.queue`:
## Wachtrijopties
Opties gelden voor `followup`, `collect` en `steer-backlog` (en voor `steer` of legacy `queue` wanneer sturing terugvalt op followup):
Opties zijn van toepassing op `followup`, `collect` en `steer-backlog` (en op `steer` of legacy `queue` wanneer sturing terugvalt op followup):
- `debounceMs`: stil venster voordat wachtrij-followups worden verwerkt. Kale getallen zijn milliseconden; eenheden `ms`, `s`, `m`, `h` en `d` worden geaccepteerd door `/queue`-opties.
- `cap`: maximaal aantal wachtrijberichten per sessie. Waarden onder `1` worden genegeerd.
- `drop: "summarize"`: standaard. Verwijder zo nodig de oudste wachtrijitems, bewaar compacte samenvattingen en injecteer die als een synthetische followup-prompt.
- `drop: "old"`: verwijder zo nodig de oudste wachtrijitems, zonder samenvattingen te bewaren.
- `drop: "new"`: wijs het nieuwste bericht af wanneer de wachtrij al vol is.
- `debounceMs`: stil venster voordat followups in de wachtrij worden verwerkt. Kale getallen zijn milliseconden; eenheden `ms`, `s`, `m`, `h` en `d` worden geaccepteerd door `/queue`-opties.
- `cap`: maximaal aantal berichten in de wachtrij per sessie. Waarden onder `1` worden genegeerd.
- `drop: "summarize"`: standaard. Verwijder de oudste items in de wachtrij waar nodig, bewaar compacte samenvattingen en injecteer ze als een synthetische followup-prompt.
- `drop: "old"`: verwijder de oudste items in de wachtrij waar nodig, zonder samenvattingen te bewaren.
- `drop: "new"`: weiger het nieuwste bericht wanneer de wachtrij al vol is.
Standaardwaarden: `debounceMs: 500`, `cap: 20`, `drop: summarize`.
Standaarden: `debounceMs: 500`, `cap: 20`, `drop: summarize`.
## Voorrang
Voor modusselectie lost OpenClaw dit op:
1. Inline of opgeslagen `/queue`-override per sessie.
1. Inline of opgeslagen per-sessie `/queue`-override.
2. `messages.queue.byChannel.<channel>`.
3. `messages.queue.mode`.
4. Standaard `steer`.
Voor opties winnen inline of opgeslagen `/queue`-opties van configuratie. Daarna
worden kanaalspecifieke debounce (`messages.queue.debounceMsByChannel`), Plugin
Voor opties hebben inline of opgeslagen `/queue`-opties voorrang op configuratie. Daarna worden
kanaalspecifieke debounce (`messages.queue.debounceMsByChannel`), Plugin
debounce-standaarden, globale `messages.queue`-opties en ingebouwde standaarden
toegepast. `cap` en `drop` zijn globale/sessie-opties, geen configuratiesleutels
per kanaal.
toegepast. `cap` en `drop` zijn globale/sessieopties, geen configuratiesleutels per kanaal.
## Overrides per sessie
## Per-sessie overrides
- Verstuur `/queue <mode>` als zelfstandige opdracht om de modus voor de huidige sessie op te slaan.
- Stuur `/queue <mode>` als zelfstandige opdracht om de modus voor de huidige sessie op te slaan.
- Opties kunnen worden gecombineerd: `/queue collect debounce:0.5s cap:25 drop:summarize`
- `/queue default` of `/queue reset` wist de sessie-override.
## Scope en garanties
## Bereik en garanties
- Geldt voor auto-antwoord-agentuitvoeringen over alle inkomende kanalen die de Gateway-antwoordpipeline gebruiken (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat, enz.).
- Standaard-lane (`main`) is procesbreed voor inkomend + main Heartbeats; stel `agents.defaults.maxConcurrent` in om meerdere sessies parallel toe te staan.
- Er kunnen extra lanes bestaan (bijv. `cron`, `cron-nested`, `nested`, `subagent`) zodat achtergrondtaken parallel kunnen draaien zonder inkomende antwoorden te blokkeren. Geïsoleerde Cron-agentbeurten houden een `cron`-slot vast terwijl hun interne agentuitvoering `cron-nested` gebruikt; beide gebruiken `cron.maxConcurrentRuns`. Gedeelde niet-Cron `nested`-flows behouden hun eigen lane-gedrag. Deze losgekoppelde uitvoeringen worden bijgehouden als [achtergrondtaken](/nl/automation/tasks).
- Lanes per sessie garanderen dat slechts één agentuitvoering tegelijk een bepaalde sessie aanraakt.
- Geen externe afhankelijkheden of achtergrond-workerthreads; pure TypeScript + promises.
- Van toepassing op auto-reply-agentuitvoeringen over alle inkomende kanalen die de Gateway-antwoordpipeline gebruiken (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat, enz.).
- Standaardlane (`main`) is process-wide voor inkomend + main Heartbeats; stel `agents.defaults.maxConcurrent` in om meerdere sessies parallel toe te staan.
- Er kunnen aanvullende lanes bestaan (bijv. `cron`, `cron-nested`, `nested`, `subagent`), zodat achtergrondtaken parallel kunnen draaien zonder inkomende antwoorden te blokkeren. Geïsoleerde Cron-agentbeurten houden een `cron`-slot vast terwijl hun innerlijke agentuitvoering `cron-nested` gebruikt; beide gebruiken `cron.maxConcurrentRuns`. Gedeelde niet-Cron `nested`-flows behouden hun eigen lane-gedrag. Deze losgekoppelde uitvoeringen worden bijgehouden als [achtergrondtaken](/nl/automation/tasks).
- Per-sessie lanes garanderen dat slechts één agentuitvoering tegelijk een bepaalde sessie aanraakt.
- Geen externe afhankelijkheden of workerthreads op de achtergrond; pure TypeScript + promises.
## Probleemoplossing
- Als opdrachten vast lijken te zitten, schakel uitgebreide logs in en zoek naar regels “queued for …ms” om te bevestigen dat de wachtrij wordt verwerkt.
- Als je wachtrijdiepte nodig hebt, schakel uitgebreide logs in en let op wachtrij-timingregels.
- Wanneer diagnostiek is ingeschakeld, loggen sessies die langer dan `diagnostics.stuckSessionWarnMs` in `processing` blijven een waarschuwing voor een vastgelopen sessie. Actieve embedded uitvoeringen, actieve antwoordbewerkingen en actieve lane-taken blijven standaard alleen-waarschuwingen; verouderde opstartboekhouding zonder actief sessiewerk kan de getroffen sessie-lane vrijgeven zodat wachtrijwerk wordt verwerkt.
- Als opdrachten vast lijken te zitten, schakel verbose logs in en zoek naar regels “queued for …ms” om te bevestigen dat de wachtrij wordt verwerkt.
- Als je wachtrijdiepte nodig hebt, schakel verbose logs in en let op wachtrijtimingregels.
- Codex app-server-uitvoeringen die een beurt accepteren en daarna stoppen met voortgang uitsturen, worden onderbroken door de Codex-adapter zodat de actieve sessielane kan vrijkomen in plaats van te wachten op de timeout van de buitenste uitvoering.
- Wanneer diagnostics zijn ingeschakeld, loggen sessies die langer dan `diagnostics.stuckSessionWarnMs` in `processing` blijven een waarschuwing voor een vastgelopen sessie. Actieve embedded uitvoeringen, actieve antwoordbewerkingen en actieve lanetaken blijven standaard alleen waarschuwingen; verouderde startup-boekhouding zonder actief sessiewerk kan de getroffen sessielane vrijgeven zodat werk in de wachtrij wordt verwerkt.
## Gerelateerd

789
docs/nl/help/testing.md
View File

File diff suppressed because it is too large Load Diff

103
docs/nl/reference/test.md
View File

@ -1,58 +1,59 @@
---
read_when:
- Tests uitvoeren of herstellen
summary: Tests lokaal uitvoeren (vitest) en wanneer je force/coverage-modi gebruikt
title: Tests
- Tests uitvoeren of oplossen
summary: Tests lokaal uitvoeren (vitest) en wanneer je force-/coverage-modi gebruikt
title: Testen
x-i18n:
generated_at: "2026-04-29T23:17:48Z"
generated_at: "2026-04-30T18:38:35Z"
model: gpt-5.5
provider: openai
source_hash: 9328d6f0383b5067fa8bb5d0f1bf22a3b9048a267908bf85167842ddc3d12e42
source_hash: 131f2bad3b2806d28394213cec38d632d106ddbf8ff04d06345ab8046fb8bcf2
source_path: reference/test.md
workflow: 16
---
- Volledige testkit (suites, live, Docker): [Testen](/nl/help/testing)
- `pnpm test:force`: Beëindigt elk achtergebleven Gateway-proces dat de standaardcontrolepoort bezet houdt, en draait daarna de volledige Vitest-suite met een geïsoleerde Gateway-poort zodat servertests niet botsen met een draaiende instantie. Gebruik dit wanneer een eerdere Gateway-run poort 18789 bezet heeft achtergelaten.
- `pnpm test:coverage`: Draait de unitsuite met V8-coverage (via `vitest.unit.config.ts`). Dit is een coverage-gate voor geladen bestanden, niet whole-repo all-file coverage. Drempels zijn 70% voor regels/functies/statements en 55% voor branches. Omdat `coverage.all` false is, meet de gate bestanden die door de unit-coveragesuite zijn geladen in plaats van elk split-lane bronbestand als ongedekt te behandelen.
- `pnpm test:coverage:changed`: Draait unit-coverage alleen voor bestanden die sinds `origin/main` zijn gewijzigd.
- `pnpm test:changed`: goedkope slimme gewijzigde-test-run. Deze draait precieze targets uit directe testbewerkingen, naastgelegen `*.test.ts`-bestanden, expliciete bronmappings en de lokale importgraaf. Brede/configuratie-/pakketwijzigingen worden overgeslagen tenzij ze naar precieze tests mappen.
- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: expliciete brede gewijzigde-test-run. Gebruik dit wanneer een wijziging in testharnas/configuratie/pakket moet terugvallen op Vitest's bredere gewijzigde-testgedrag.
- `pnpm changed:lanes`: toont de architecturale lanes die worden geactiveerd door de diff tegen `origin/main`.
- `pnpm check:changed`: draait de slimme gewijzigde-check-gate voor de diff tegen `origin/main`. Deze draait typecheck-, lint- en guard-commando's voor de getroffen architecturale lanes, maar draait geen Vitest-tests. Gebruik `pnpm test:changed` of expliciet `pnpm test <target>` voor testbewijs.
- `pnpm test`: routeert expliciete bestands-/directorytargets via gescopete Vitest-lanes. Niet-getargete runs gebruiken vaste shardgroepen en breiden uit naar leaf-configs voor lokale parallelle uitvoering; de extensiegroep breidt altijd uit naar de per-extensie shardconfigs in plaats van één enorm root-projectproces.
- Testwrapper-runs eindigen met een korte `[test] passed|failed|skipped ... in ...`-samenvatting. Vitest's eigen duurregel blijft het detail per shard.
- Gedeelde OpenClaw-teststatus: gebruik `src/test-utils/openclaw-test-state.ts` vanuit Vitest wanneer een test een geïsoleerde `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, configuratiefixture, workspace, agentdirectory of auth-profielstore nodig heeft.
- Process E2E-helpers: gebruik `test/helpers/openclaw-test-instance.ts` wanneer een Vitest E2E-test op procesniveau een draaiende Gateway, CLI-env, logvastlegging en opschoning op één plek nodig heeft.
- Docker/Bash E2E-helpers: lanes die `scripts/lib/docker-e2e-image.sh` sourcen, kunnen `docker_e2e_test_state_shell_b64 <label> <scenario>` aan de container doorgeven en dit decoderen met `scripts/lib/openclaw-e2e-instance.sh`; multi-home-scripts kunnen `docker_e2e_test_state_function_b64` doorgeven en `openclaw_test_state_create <label> <scenario>` in elke flow aanroepen. Lower-level callers kunnen `scripts/lib/openclaw-test-state.mjs shell --label <name> --scenario <name>` gebruiken voor een shellsnippet in de container, of `node scripts/lib/openclaw-test-state.mjs -- create --label <name> --scenario <name> --env-file <path> --json` voor een sourcebaar host-env-bestand. De `--` vóór `create` voorkomt dat nieuwere Node-runtimes `--env-file` als een Node-flag behandelen. Docker/Bash-lanes die een Gateway starten, kunnen `scripts/lib/openclaw-e2e-instance.sh` binnen de container sourcen voor entrypoint-resolutie, mock-OpenAI-startup, Gateway-foreground/background-start, readiness-probes, state-env-export, logdumps en procesopschoning.
- Full-, extensie- en include-pattern-shard-runs werken lokale timingdata bij in `.artifacts/vitest-shard-timings.json`; latere whole-config-runs gebruiken die timings om langzame en snelle shards te balanceren. Include-pattern-CI-shards voegen de shardnaam toe aan de timingsleutel, waardoor gefilterde shardtimings zichtbaar blijven zonder whole-config timingdata te vervangen. Stel `OPENCLAW_TEST_PROJECTS_TIMINGS=0` in om het lokale timingartefact te negeren.
- Geselecteerde `plugin-sdk`- en `commands`-testbestanden routeren nu via dedicated lichte lanes die alleen `test/setup.ts` behouden, terwijl runtime-zware cases op hun bestaande lanes blijven.
- Bronbestanden met naastgelegen tests mappen naar die naastgelegen test voordat ze terugvallen op bredere directoryglobs. Helperbewerkingen onder `src/channels/plugins/contracts/test-helpers`, `src/plugin-sdk/test-helpers` en `src/plugins/contracts` gebruiken een lokale importgraaf om importerende tests te draaien in plaats van elke shard breed te draaien wanneer het afhankelijkheidspad precies is.
- `auto-reply` splitst nu ook in drie dedicated configs (`core`, `top-level`, `reply`) zodat het reply-harnas de lichtere top-level status-/token-/helpertests niet domineert.
- De basis-Vitest-config gebruikt nu standaard `pool: "threads"` en `isolate: false`, met de gedeelde niet-geïsoleerde runner ingeschakeld in de repo-configs.
- `pnpm test:channels` draait `vitest.channels.config.ts`.
- `pnpm test:extensions` en `pnpm test extensions` draaien alle extensie-/pluginshards. Zware kanaalplugins, de browserplugin en OpenAI draaien als dedicated shards; andere plugingroepen blijven gebatcht. Gebruik `pnpm test extensions/<id>` voor één gebundelde plugin-lane.
- `pnpm test:perf:imports`: schakelt Vitest import-duration- en import-breakdown-rapportage in, terwijl nog steeds gescopete lane-routering wordt gebruikt voor expliciete bestands-/directorytargets.
- `pnpm test:force`: Beëindigt elk achtergebleven Gateway-proces dat de standaardbesturingspoort bezet houdt en voert daarna de volledige Vitest-suite uit met een geïsoleerde Gateway-poort, zodat servertests niet botsen met een draaiende instantie. Gebruik dit wanneer een eerdere Gateway-run poort 18789 bezet heeft achtergelaten.
- `pnpm test:coverage`: Voert de unitsuite uit met V8-dekking (via `vitest.unit.config.ts`). Dit is een dekkingsgate voor geladen bestanden in unit tests, geen all-file-dekking voor de hele repo. Drempels zijn 70% regels/functies/statements en 55% branches. Omdat `coverage.all` false is, meet de gate bestanden die door de unit-dekkingssuite zijn geladen, in plaats van elk split-lane bronbestand als ongedekt te behandelen.
- `pnpm test:coverage:changed`: Voert unitdekking alleen uit voor bestanden die sinds `origin/main` zijn gewijzigd.
- `pnpm test:changed`: goedkope slimme gewijzigde-testrun. Deze voert precieze doelen uit op basis van directe testbewerkingen, naastliggende `*.test.ts`-bestanden, expliciete bronmappings en de lokale importgraaf. Brede/configuratie-/pakketwijzigingen worden overgeslagen tenzij ze naar precieze tests mappen.
- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: expliciete brede gewijzigde-testrun. Gebruik dit wanneer een wijziging aan testharnas/configuratie/pakket moet terugvallen op Vitest's bredere changed-test-gedrag.
- `pnpm changed:lanes`: toont de architecturale lanes die door de diff tegen `origin/main` worden geactiveerd.
- `pnpm check:changed`: voert de slimme gewijzigde-checkgate uit voor de diff tegen `origin/main`. Deze voert typecheck-, lint- en guard-commando's uit voor de getroffen architecturale lanes, maar voert geen Vitest-tests uit. Gebruik `pnpm test:changed` of expliciet `pnpm test <target>` voor testbewijs.
- `pnpm test`: routeert expliciete bestands-/directorydoelen via gescopete Vitest-lanes. Runs zonder doel gebruiken vaste shardgroepen en worden uitgebreid naar leaf-configuraties voor lokale parallelle uitvoering; de extensiegroep wordt altijd uitgebreid naar de per-extensie shardconfiguraties in plaats van één enorm root-projectproces.
- Testwrapper-runs eindigen met een korte samenvatting `[test] passed|failed|skipped ... in ...`. Vitest's eigen duurregel blijft het detail per shard.
- Gedeelde OpenClaw-teststatus: gebruik `src/test-utils/openclaw-test-state.ts` vanuit Vitest wanneer een test een geïsoleerde `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, configuratiefixture, workspace, agentdirectory of auth-profile-opslag nodig heeft.
- Proces-E2E-helpers: gebruik `test/helpers/openclaw-test-instance.ts` wanneer een Vitest-procesniveau-E2E-test een draaiende Gateway, CLI-env, logregistratie en opschoning op één plek nodig heeft.
- Docker/Bash-E2E-helpers: lanes die `scripts/lib/docker-e2e-image.sh` sourcen, kunnen `docker_e2e_test_state_shell_b64 <label> <scenario>` aan de container doorgeven en dit decoderen met `scripts/lib/openclaw-e2e-instance.sh`; scripts met meerdere homes kunnen `docker_e2e_test_state_function_b64` doorgeven en `openclaw_test_state_create <label> <scenario>` in elke flow aanroepen. Callers op lager niveau kunnen `scripts/lib/openclaw-test-state.mjs shell --label <name> --scenario <name>` gebruiken voor een shellsnippet in de container, of `node scripts/lib/openclaw-test-state.mjs -- create --label <name> --scenario <name> --env-file <path> --json` voor een sourcebaar host-env-bestand. De `--` vóór `create` voorkomt dat nieuwere Node-runtimes `--env-file` als een Node-vlag behandelen. Docker/Bash-lanes die een Gateway starten, kunnen `scripts/lib/openclaw-e2e-instance.sh` binnen de container sourcen voor entrypoint-resolutie, mock-OpenAI-start, Gateway-start op voorgrond/achtergrond, readiness-probes, export van status-env, logdumps en procesopschoning.
- Volledige, extensie- en include-pattern-shardruns werken lokale timinggegevens bij in `.artifacts/vitest-shard-timings.json`; latere runs met hele configuraties gebruiken die timings om trage en snelle shards te balanceren. Include-pattern-CI-shards voegen de shardnaam toe aan de timingsleutel, waardoor gefilterde shardtimings zichtbaar blijven zonder timinggegevens voor hele configuraties te vervangen. Stel `OPENCLAW_TEST_PROJECTS_TIMINGS=0` in om het lokale timingartefact te negeren.
- Geselecteerde `plugin-sdk`- en `commands`-testbestanden worden nu via speciale lichte lanes gerouteerd die alleen `test/setup.ts` behouden, terwijl runtime-zware gevallen op hun bestaande lanes blijven.
- Bronbestanden met naastliggende tests mappen naar die naastliggende test voordat ze terugvallen op bredere directoryglobs. Helperbewerkingen onder `src/channels/plugins/contracts/test-helpers`, `src/plugin-sdk/test-helpers` en `src/plugins/contracts` gebruiken een lokale importgraaf om importerende tests uit te voeren in plaats van elke shard breed uit te voeren wanneer het afhankelijkheidspad precies is.
- `auto-reply` wordt nu ook opgesplitst in drie speciale configuraties (`core`, `top-level`, `reply`), zodat het reply-harnas de lichtere top-level status-/token-/helpertests niet domineert.
- De basis-Vitest-configuratie gebruikt nu standaard `pool: "threads"` en `isolate: false`, met de gedeelde niet-geïsoleerde runner ingeschakeld in alle repo-configuraties.
- `pnpm test:channels` voert `vitest.channels.config.ts` uit.
- `pnpm test:extensions` en `pnpm test extensions` voeren alle extensie-/pluginshards uit. Zware kanaalplugins, de browserplugin en OpenAI worden als speciale shards uitgevoerd; andere plugingroepen blijven gebatcht. Gebruik `pnpm test extensions/<id>` voor één gebundelde pluginlane.
- `pnpm test:perf:imports`: schakelt Vitest import-duration- en import-breakdown-rapportage in, terwijl nog steeds gescopete lane-routing wordt gebruikt voor expliciete bestands-/directorydoelen.
- `pnpm test:perf:imports:changed`: dezelfde importprofilering, maar alleen voor bestanden die sinds `origin/main` zijn gewijzigd.
- `pnpm test:perf:changed:bench -- --ref <git-ref>` benchmarkt het gerouteerde changed-mode-pad tegen de native root-project-run voor dezelfde gecommitte git-diff.
- `pnpm test:perf:changed:bench -- --worktree` benchmarkt de huidige changeset in de worktree zonder eerst te committen.
- `pnpm test:perf:profile:main`: schrijft een CPU-profiel voor de Vitest-mainthread (`.artifacts/vitest-main-profile`).
- `pnpm test:perf:changed:bench -- --ref <git-ref>` benchmarkt het gerouteerde changed-mode-pad tegen de native root-projectrun voor dezelfde gecommitte gitdiff.
- `pnpm test:perf:changed:bench -- --worktree` benchmarkt de huidige worktree-wijzigingsset zonder eerst te committen.
- `pnpm test:perf:profile:main`: schrijft een CPU-profiel voor de Vitest-hoofdthread (`.artifacts/vitest-main-profile`).
- `pnpm test:perf:profile:runner`: schrijft CPU- en heap-profielen voor de unitrunner (`.artifacts/vitest-runner-profile`).
- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: draait elke full-suite Vitest leaf-config serieel en schrijft gegroepeerde duurdata plus per-config JSON-/logartefacten. De Test Performance Agent gebruikt dit als baseline voordat hij slow-test-fixes probeert.
- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: vergelijkt gegroepeerde rapporten na een performancegerichte wijziging.
- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: voert elke full-suite Vitest-leafconfiguratie serieel uit en schrijft gegroepeerde duurgegevens plus JSON-/logartefacten per configuratie. De Test Performance Agent gebruikt dit als baseline voordat slow-test-fixes worden geprobeerd.
- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: vergelijkt gegroepeerde rapporten na een prestatiegerichte wijziging.
- Gateway-integratie: opt-in via `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` of `pnpm test:gateway`.
- `pnpm test:e2e`: Draait Gateway end-to-end smoketests (multi-instance WS/HTTP/node-pairing). Gebruikt standaard `threads` + `isolate: false` met adaptieve workers in `vitest.e2e.config.ts`; stem af met `OPENCLAW_E2E_WORKERS=<n>` en stel `OPENCLAW_E2E_VERBOSE=1` in voor uitgebreide logs.
- `pnpm test:live`: Draait live providertests (minimax/zai). Vereist API-sleutels en `LIVE=1` (of provider-specifieke `*_LIVE_TEST=1`) om niet over te slaan.
- `pnpm test:docker:all`: Bouwt de gedeelde live-testimage, verpakt OpenClaw één keer als een npm-tarball, bouwt/hergebruikt een kale Node/Git-runnerimage plus een functionele image die die tarball installeert in `/app`, en draait daarna Docker-smokelanes met `OPENCLAW_SKIP_DOCKER_BUILD=1` via een gewogen scheduler. De kale image (`OPENCLAW_DOCKER_E2E_BARE_IMAGE`) wordt gebruikt voor installer-/update-/plugin-afhankelijkheidslanes; die lanes mounten de vooraf gebouwde tarball in plaats van gekopieerde repobronnen te gebruiken. De functionele image (`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`) wordt gebruikt voor normale built-app-functionaliteitslanes. `scripts/package-openclaw-for-docker.mjs` is de enige lokale/CI-packagepacker en valideert de tarball plus `dist/postinstall-inventory.json` voordat Docker deze consumeert. Docker-lanedefinities staan in `scripts/lib/docker-e2e-scenarios.mjs`; plannerlogica staat in `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` voert het geselecteerde plan uit. `node scripts/test-docker-all.mjs --plan-json` emit het door de scheduler beheerde CI-plan voor geselecteerde lanes, imagekinds, package-/live-imagebehoeften, statusscenario's en credentialcontroles zonder Docker te bouwen of te draaien. `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` beheert processlots en staat standaard op 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n>` beheert de providergevoelige tailpool en staat standaard op 10. Zware lane-caps staan standaard op `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` en `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; providercaps staan standaard op één zware lane per provider via `OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4` en `OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4`. Gebruik `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` of `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` voor grotere hosts. Als één lane de effectieve gewichts- of resourcecap op een host met lage paralleliteit overschrijdt, kan deze nog steeds vanuit een lege pool starten en alleen draaien totdat capaciteit wordt vrijgegeven. Lanestarts worden standaard met 2 seconden gespreid om create-storms in de lokale Docker-daemon te vermijden; overschrijf dit met `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>`. De runner voert standaard een Docker-preflight uit, ruimt verouderde OpenClaw E2E-containers op, emit elke 30 seconden actieve-lane-status, deelt provider-CLI-toolcaches tussen compatibele lanes, probeert tijdelijke live-providerfouten standaard één keer opnieuw (`OPENCLAW_DOCKER_ALL_LIVE_RETRIES=<n>`) en slaat lanetimings op in `.artifacts/docker-tests/lane-timings.json` voor longest-first-volgorde bij latere runs. Gebruik `OPENCLAW_DOCKER_ALL_DRY_RUN=1` om het lanemanifest af te drukken zonder Docker te draaien, `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=<ms>` om statusuitvoer af te stemmen, of `OPENCLAW_DOCKER_ALL_TIMINGS=0` om timinghergebruik uit te schakelen. Gebruik `OPENCLAW_DOCKER_ALL_LIVE_MODE=skip` voor alleen deterministische/lokale lanes of `OPENCLAW_DOCKER_ALL_LIVE_MODE=only` voor alleen live-providerlanes; package-aliassen zijn `pnpm test:docker:local:all` en `pnpm test:docker:live:all`. Live-only-modus voegt main- en tail-live-lanes samen in één longest-first-pool zodat providerbuckets Claude-, Codex- en Gemini-werk samen kunnen inpakken. De runner stopt met het schedulen van nieuwe gepoolde lanes na de eerste fout tenzij `OPENCLAW_DOCKER_ALL_FAIL_FAST=0` is ingesteld, en elke lane heeft een fallback-time-out van 120 minuten die overschrijfbaar is met `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; geselecteerde live-/taillanes gebruiken strakkere caps per lane. CLI-backend-Docker-setupcommando's hebben hun eigen time-out via `OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS` (standaard 180). Per-lane logs, `summary.json`, `failures.json` en fasetimings worden geschreven onder `.artifacts/docker-tests/<run-id>/`; gebruik `pnpm test:docker:timings <summary.json>` om langzame lanes te inspecteren en `pnpm test:docker:rerun <run-id|summary.json|failures.json>` om goedkope getargete rerun-commando's af te drukken.
- `pnpm test:docker:browser-cdp-snapshot`: Bouwt een Chromium-backed source E2E-container, start raw CDP plus een geïsoleerde Gateway, draait `browser doctor --deep` en verifieert dat CDP-rolsnapshots link-URL's, cursor-gepromote clickables, iframe-refs en framemetadata bevatten.
- CLI-backend live-Docker-probes kunnen als gefocuste lanes worden gedraaid, bijvoorbeeld `pnpm test:docker:live-cli-backend:codex`, `pnpm test:docker:live-cli-backend:codex:resume` of `pnpm test:docker:live-cli-backend:codex:mcp`. Claude en Gemini hebben overeenkomstige `:resume`- en `:mcp`-aliassen.
- `pnpm test:docker:openwebui`: Start gedockeriseerde OpenClaw + Open WebUI, meldt aan via Open WebUI, controleert `/api/models` en draait daarna een echte proxied chat via `/api/chat/completions`. Vereist een bruikbare live modelsleutel (bijvoorbeeld OpenAI in `~/.profile`), haalt een externe Open WebUI-image op en wordt niet verwacht CI-stabiel te zijn zoals de normale unit-/e2e-suites.
- `pnpm test:docker:mcp-channels`: Start een geseede Gateway-container en een tweede clientcontainer die `openclaw mcp serve` spawnt, en verifieert daarna gerouteerde gespreksontdekking, transcriptreads, bijlagemetadata, gedrag van live event queue, outbound send-routering en Claude-achtige kanaal- en permissienotificaties via de echte stdio-bridge. De Claude-notificatieassertie leest de raw stdio MCP-frames direct, zodat de smoke weerspiegelt wat de bridge daadwerkelijk emit.
- `pnpm test:e2e`: Voert Gateway end-to-end rooktests uit (multi-instance WS/HTTP/node-pairing). Gebruikt standaard `threads` + `isolate: false` met adaptieve workers in `vitest.e2e.config.ts`; stem af met `OPENCLAW_E2E_WORKERS=<n>` en stel `OPENCLAW_E2E_VERBOSE=1` in voor uitgebreide logs.
- `pnpm test:live`: Voert live providertests uit (minimax/zai). Vereist API-sleutels en `LIVE=1` (of providerspecifiek `*_LIVE_TEST=1`) om ze niet over te slaan.
- `pnpm test:docker:all`: Bouwt de gedeelde live-testimage, verpakt OpenClaw één keer als npm-tarball, bouwt/hergebruikt een kale Node/Git-runnerimage plus een functionele image die die tarball in `/app` installeert, en voert daarna Docker-rooklanes uit met `OPENCLAW_SKIP_DOCKER_BUILD=1` via een gewogen planner. De kale image (`OPENCLAW_DOCKER_E2E_BARE_IMAGE`) wordt gebruikt voor installer-/update-/plugin-afhankelijkheidslanes; die lanes mounten de vooraf gebouwde tarball in plaats van gekopieerde repobronnen te gebruiken. De functionele image (`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`) wordt gebruikt voor normale ingebouwde appfunctionaliteitslanes. `scripts/package-openclaw-for-docker.mjs` is de enige lokale/CI-pakketpacker en valideert de tarball plus `dist/postinstall-inventory.json` voordat Docker deze gebruikt. Docker-lanedefinities staan in `scripts/lib/docker-e2e-scenarios.mjs`; plannerlogica staat in `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` voert het geselecteerde plan uit. `node scripts/test-docker-all.mjs --plan-json` emitteert het door de scheduler beheerde CI-plan voor geselecteerde lanes, image-soorten, pakket-/live-imagebehoeften, statusscenario's en credentialcontroles zonder Docker te bouwen of uit te voeren. `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` beheert processlots en gebruikt standaard 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n>` beheert de providergevoelige tail-pool en gebruikt standaard 10. Zware lane-limieten zijn standaard `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` en `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; providerlimieten zijn standaard één zware lane per provider via `OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4` en `OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4`. Gebruik `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` of `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` voor grotere hosts. Als één lane de effectieve gewichtslimiet of resourcelimiet op een host met lage paralleliteit overschrijdt, kan die nog steeds vanuit een lege pool starten en alleen draaien totdat capaciteit wordt vrijgegeven. Lane-starts worden standaard met 2 seconden gespreid om lokale Docker-daemon-create-stormen te voorkomen; overschrijf dit met `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>`. De runner voert standaard Docker-preflights uit, ruimt verouderde OpenClaw-E2E-containers op, emitteert elke 30 seconden actieve-lanestatus, deelt provider-CLI-toolcaches tussen compatibele lanes, probeert tijdelijke live-providerfouten standaard één keer opnieuw (`OPENCLAW_DOCKER_ALL_LIVE_RETRIES=<n>`) en slaat lanetimings op in `.artifacts/docker-tests/lane-timings.json` voor langste-eerst-volgorde bij latere runs. Gebruik `OPENCLAW_DOCKER_ALL_DRY_RUN=1` om het lanemanifest af te drukken zonder Docker uit te voeren, `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=<ms>` om statusuitvoer af te stemmen, of `OPENCLAW_DOCKER_ALL_TIMINGS=0` om timinghergebruik uit te schakelen. Gebruik `OPENCLAW_DOCKER_ALL_LIVE_MODE=skip` alleen voor deterministische/lokale lanes of `OPENCLAW_DOCKER_ALL_LIVE_MODE=only` alleen voor live-providerlanes; pakketaliassen zijn `pnpm test:docker:local:all` en `pnpm test:docker:live:all`. Live-only-modus voegt main- en tail-live-lanes samen tot één langste-eerst-pool, zodat providerbuckets Claude-, Codex- en Gemini-werk samen kunnen inpakken. De runner stopt met het plannen van nieuwe gepoolde lanes na de eerste fout, tenzij `OPENCLAW_DOCKER_ALL_FAIL_FAST=0` is ingesteld, en elke lane heeft een fallback-time-out van 120 minuten die kan worden overschreven met `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; geselecteerde live-/tail-lanes gebruiken strakkere limieten per lane. CLI-backend-Docker-setupcommando's hebben hun eigen time-out via `OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS` (standaard 180). Logs per lane, `summary.json`, `failures.json` en fase-timings worden geschreven onder `.artifacts/docker-tests/<run-id>/`; gebruik `pnpm test:docker:timings <summary.json>` om trage lanes te inspecteren en `pnpm test:docker:rerun <run-id|summary.json|failures.json>` om goedkope gerichte rerun-commando's af te drukken.
- `pnpm test:docker:browser-cdp-snapshot`: Bouwt een Chromium-backed source-E2E-container, start raw CDP plus een geïsoleerde Gateway, voert `browser doctor --deep` uit en verifieert dat CDP-rolsnapshots link-URL's, cursor-gepromote klikbare elementen, iframe-referenties en framemetadata bevatten.
- CLI-backend-live-Docker-probes kunnen als gerichte lanes worden uitgevoerd, bijvoorbeeld `pnpm test:docker:live-cli-backend:codex`, `pnpm test:docker:live-cli-backend:codex:resume` of `pnpm test:docker:live-cli-backend:codex:mcp`. Claude en Gemini hebben bijpassende `:resume`- en `:mcp`-aliassen.
- `pnpm test:docker:openwebui`: Start gedockeriseerde OpenClaw + Open WebUI, meldt zich aan via Open WebUI, controleert `/api/models` en voert daarna een echte geproxiede chat uit via `/api/chat/completions`. Vereist een bruikbare live-modelsleutel (bijvoorbeeld OpenAI in `~/.profile`), haalt een externe Open WebUI-image op en wordt niet verwacht CI-stabiel te zijn zoals de normale unit-/e2e-suites.
- `pnpm test:docker:mcp-channels`: Start een geseede Gateway-container en een tweede clientcontainer die `openclaw mcp serve` spawnt, en verifieert daarna gerouteerde gespreksdetectie, transcriptreads, bijlagemetadata, gedrag van live-eventqueues, routering van outbound sends en Claude-stijl kanaal- en permissiemeldingen via de echte stdio-bridge. De Claude-meldingsassertie leest de raw stdio MCP-frames rechtstreeks, zodat de smoke weergeeft wat de bridge daadwerkelijk emitteert.
- `pnpm test:docker:upgrade-survivor`: Installeert de verpakte OpenClaw-tarball over een vervuilde fixture voor oude gebruikers, voert een pakketupdate plus niet-interactieve doctor uit zonder live provider- of kanaalsleutels, start vervolgens een loopback-Gateway en controleert of agents, kanaalconfiguratie, Plugin-toestaanlijsten, workspace-/sessiebestanden, verouderde Plugin-`runtime-deps`-status, opstarten en RPC-status behouden blijven.
## Lokale PR-gate
Voor lokale PR-land-/gatecontroles, voer uit:
Voor lokale PR-landings-/gatecontroles voer je uit:
- `pnpm check:changed`
- `pnpm check`
@ -61,7 +62,7 @@ Voor lokale PR-land-/gatecontroles, voer uit:
- `pnpm test`
- `pnpm check:docs`
Als `pnpm test` op een zwaar belaste host flaket, voer het dan een keer opnieuw uit voordat je het als een regressie behandelt, en isoleer daarna met `pnpm test <path/to/test>`. Gebruik voor hosts met beperkte geheugenruimte:
Als `pnpm test` hapert op een zwaar belaste host, voer het dan eenmaal opnieuw uit voordat je het als een regressie behandelt, en isoleer daarna met `pnpm test <path/to/test>`. Gebruik voor hosts met beperkte geheugenruimte:
- `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test`
- `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed`
@ -74,12 +75,12 @@ Gebruik:
- `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10`
- Optionele env: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
- Standaardprompt: “Antwoord met één woord: ok. Geen interpunctie of extra tekst.”
- Standaardprompt: “Antwoord met één enkel woord: ok. Geen interpunctie of extra tekst.”
Laatste uitvoering (2025-12-31, 20 uitvoeringen):
Laatste run (2025-12-31, 20 runs):
- minimax-mediaan 1279 ms (min. 1114, max. 2431)
- opus-mediaan 2454 ms (min. 1224, max. 3170)
- minimax mediaan 1279 ms (min 1114, max 2431)
- opus mediaan 2454 ms (min 1224, max 3170)
## CLI-opstartbenchmark
@ -109,35 +110,35 @@ Presets:
- `real`: `health`, `status`, `status --json`, `sessions`, `sessions --json`, `tasks --json`, `tasks list --json`, `tasks audit --json`, `agents list --json`, `gateway status`, `gateway status --json`, `gateway health --json`, `config get gateway.port`
- `all`: beide presets
Uitvoer bevat `sampleCount`, gemiddelde, p50, p95, min/max, exit-code-/signaalverdeling en max RSS-samenvattingen voor elke opdracht. Optioneel schrijft `--cpu-prof-dir` / `--heap-prof-dir` V8-profielen per uitvoering, zodat timing en profielvastlegging dezelfde harness gebruiken.
Uitvoer bevat `sampleCount`, gemiddelde, p50, p95, min/max, exit-code-/signaalverdeling en samenvattingen van max RSS voor elke opdracht. Optioneel schrijft `--cpu-prof-dir` / `--heap-prof-dir` V8-profielen per run, zodat timing en profielvastlegging dezelfde harness gebruiken.
Conventies voor opgeslagen uitvoer:
- `pnpm test:startup:bench:smoke` schrijft het gerichte smoke-artefact naar `.artifacts/cli-startup-bench-smoke.json`
- `pnpm test:startup:bench:save` schrijft het volledige suite-artefact naar `.artifacts/cli-startup-bench-all.json` met `runs=5` en `warmup=1`
- `pnpm test:startup:bench:update` vernieuwt de ingecheckte baselinefixture op `test/fixtures/cli-startup-bench.json` met `runs=5` en `warmup=1`
- `pnpm test:startup:bench:save` schrijft het full-suite-artefact naar `.artifacts/cli-startup-bench-all.json` met `runs=5` en `warmup=1`
- `pnpm test:startup:bench:update` vernieuwt de ingecheckte baseline-fixture op `test/fixtures/cli-startup-bench.json` met `runs=5` en `warmup=1`
Ingecheckte fixture:
- `test/fixtures/cli-startup-bench.json`
- Vernieuw met `pnpm test:startup:bench:update`
- Vergelijk huidige resultaten met de fixture met `pnpm test:startup:bench:check`
- Vergelijk huidige resultaten met de fixture via `pnpm test:startup:bench:check`
## Onboarding E2E (Docker)
## Onboarding-E2E (Docker)
Docker is optioneel; dit is alleen nodig voor gecontaineriseerde onboarding-smoketests.
Volledige cold-startflow in een schone Linux-container:
Volledige cold-start-flow in een schone Linux-container:
```bash
scripts/e2e/onboard-docker.sh
```
Dit script stuurt de interactieve wizard aan via een pseudo-tty, verifieert config-/workspace-/sessiebestanden, start daarna de Gateway en voert `openclaw health` uit.
Dit script stuurt de interactieve wizard aan via een pseudo-tty, verifieert configuratie-/workspace-/sessiebestanden, start daarna de Gateway en voert `openclaw health` uit.
## QR-importsmoke (Docker)
Zorgt ervoor dat de onderhouden QR-runtimehelper laadt onder de ondersteunde Docker Node-runtimes (standaard Node 24, compatibel met Node 22):
Zorgt ervoor dat de onderhouden QR-runtimehelper wordt geladen onder de ondersteunde Docker Node-runtimes (Node 24 standaard, Node 22 compatibel):
```bash
pnpm test:docker:qr