diff --git a/docs/nl/ci.md b/docs/nl/ci.md index f5086122e..8ebd45e6f 100644 --- a/docs/nl/ci.md +++ b/docs/nl/ci.md @@ -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= ## 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:` 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:`-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=`, `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=`, `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 # download Docker artifacts and print combined/per-lane targeted rerun commands pnpm test:docker:timings # 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) diff --git a/docs/nl/concepts/agent-loop.md b/docs/nl/concepts/agent-loop.md index 1b70818cf..4f3b4065c 100644 --- a/docs/nl/concepts/agent-loop.md +++ b/docs/nl/concepts/agent-loop.md @@ -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..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..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..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..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 diff --git a/docs/nl/concepts/queue.md b/docs/nl/concepts/queue.md index 001c82377..2026f205a 100644 --- a/docs/nl/concepts/queue.md +++ b/docs/nl/concepts/queue.md @@ -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:`) 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:`) 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.`. 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 ` als zelfstandige opdracht om de modus voor de huidige sessie op te slaan. +- Stuur `/queue ` 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 diff --git a/docs/nl/help/testing.md b/docs/nl/help/testing.md index 3e69b3441..19df38c9c 100644 --- a/docs/nl/help/testing.md +++ b/docs/nl/help/testing.md @@ -2,208 +2,208 @@ read_when: - Tests lokaal of in CI uitvoeren - Regressietests toevoegen voor model-/providerbugs - - Debuggen van Gateway- en agentgedrag + - Gateway + agentgedrag debuggen summary: 'Testkit: unit-, e2e- en live-suites, Docker-runners en wat elke test dekt' title: Testen x-i18n: - generated_at: "2026-04-29T22:51:31Z" + generated_at: "2026-04-30T18:38:59Z" model: gpt-5.5 provider: openai - source_hash: c7b506350f11431195cb55c84cb10e99efb5f43b934079528b982627024d1ffc + source_hash: 470a96c6b47c2708950d05adc4a4efba5fe290f0675a131e2888d2d0032d5953 source_path: help/testing.md workflow: 16 --- OpenClaw heeft drie Vitest-suites (unit/integratie, e2e, live) en een kleine set -Docker-runners. Dit document is een handleiding voor "hoe we testen": +Docker-runners. Dit document is een gids voor "hoe we testen": - Wat elke suite dekt (en wat deze bewust _niet_ dekt). -- Welke opdrachten je uitvoert voor veelvoorkomende workflows (lokaal, vóór pushen, debugging). -- Hoe live tests inloggegevens vinden en modellen/providers selecteren. -- Hoe je regressies toevoegt voor model-/providerproblemen uit de praktijk. +- Welke commando's je uitvoert voor gangbare workflows (lokaal, vóór push, foutopsporing). +- Hoe live-tests inloggegevens ontdekken en modellen/providers selecteren. +- Hoe je regressies toevoegt voor echte model-/providerproblemen. -**QA-stack (qa-lab, qa-channel, live transport-lanes)** wordt afzonderlijk gedocumenteerd: +**QA-stack (qa-lab, qa-channel, live transport lanes)** wordt apart gedocumenteerd: - [QA-overzicht](/nl/concepts/qa-e2e-automation) — architectuur, commandosurface, scenario's schrijven. - [Matrix-QA](/nl/concepts/qa-matrix) — referentie voor `pnpm openclaw qa matrix`. - [QA-kanaal](/nl/channels/qa-channel) — de synthetische transport-Plugin die wordt gebruikt door repo-ondersteunde scenario's. -Deze pagina behandelt het uitvoeren van de reguliere testsuites en Docker/Parallels-runners. De QA-specifieke runnersectie hieronder ([QA-specifieke runners](#qa-specific-runners)) vermeldt de concrete `qa`-aanroepen en verwijst terug naar de referenties hierboven. +Deze pagina behandelt het uitvoeren van de reguliere testsuites en Docker/Parallels-runners. De sectie met QA-specifieke runners hieronder ([QA-specifieke runners](#qa-specific-runners)) vermeldt de concrete `qa`-aanroepen en verwijst terug naar de referenties hierboven. ## Snel starten -Meestal: +Op de meeste dagen: -- Volledige gate (verwacht vóór pushen): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` -- Snellere lokale volledige suite-run op een ruime machine: `pnpm test:max` -- Directe Vitest-watch-loop: `pnpm test:watch` -- Directe bestandstargeting routeert nu ook extension-/kanaalpaden: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Geef de voorkeur aan gerichte runs wanneer je aan één failure werkt. +- Volledige gate (verwacht vóór push): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` +- Snellere lokale volledige suiterun op een ruime machine: `pnpm test:max` +- Directe Vitest-watchloop: `pnpm test:watch` +- Directe bestandsselectie routeert nu ook extension-/kanaalpaden: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Geef de voorkeur aan gerichte runs wanneer je aan één fout itereert. - Docker-ondersteunde QA-site: `pnpm qa:lab:up` - Linux-VM-ondersteunde QA-lane: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` -Wanneer je tests aanraakt of extra zekerheid wilt: +Wanneer je tests wijzigt of extra vertrouwen wilt: - Coverage-gate: `pnpm test:coverage` - E2E-suite: `pnpm test:e2e` Bij het debuggen van echte providers/modellen (vereist echte inloggegevens): -- Live suite (modellen + Gateway-tool-/image-probes): `pnpm test:live` -- Richt stil op één live bestand: `pnpm test:live -- src/agents/models.profiles.live.test.ts` -- Docker live model-sweep: `pnpm test:docker:live-models` - - Elk geselecteerd model voert nu een tekstbeurt plus een kleine file-read-achtige probe uit. - Modellen waarvan de metadata `image`-input adverteert, voeren ook een kleine image-beurt uit. +- Live-suite (modellen + Gateway-tool-/afbeeldingsprobes): `pnpm test:live` +- Richt je stil op één live-bestand: `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Docker live-modelsweep: `pnpm test:docker:live-models` + - Elk geselecteerd model voert nu een tekstbeurt uit plus een kleine probe in bestandsleesstijl. + Modellen waarvan de metadata `image`-input adverteert, voeren ook een kleine afbeeldingsbeurt uit. Schakel de extra probes uit met `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` of - `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0` wanneer je provider-failures isoleert. - - CI-dekking: de dagelijkse `OpenClaw Scheduled Live And E2E Checks` en handmatige + `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0` wanneer je providerfouten isoleert. + - CI-coverage: dagelijkse `OpenClaw Scheduled Live And E2E Checks` en handmatige `OpenClaw Release Checks` roepen beide de herbruikbare live/E2E-workflow aan met - `include_live_suites: true`, wat afzonderlijke Docker live model - matrixjobs omvat, geshard per provider. + `include_live_suites: true`, inclusief afzonderlijke Docker live-model + matrix-jobs geshard per provider. - Voor gerichte CI-herhalingen dispatch je `OpenClaw Live And E2E Checks (Reusable)` met `include_live_suites: true` en `live_models_only: true`. - - Voeg nieuwe provider-secrets met hoge signaalwaarde toe aan `scripts/ci-hydrate-live-auth.sh` + - Voeg nieuwe providergeheimen met hoge signaalwaarde toe aan `scripts/ci-hydrate-live-auth.sh` plus `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` en de - geplande/release-callers daarvan. + geplande/release-aanroepers daarvan. - Native Codex bound-chat-smoke: `pnpm test:docker:live-codex-bind` - - Voert een Docker live lane uit tegen het Codex app-server-pad, bindt een synthetische + - Voert een Docker live-lane uit tegen het Codex app-server-pad, bindt een synthetische Slack-DM met `/codex bind`, oefent `/codex fast` en - `/codex permissions`, en verifieert daarna dat een gewone reactie en een image-bijlage - via de native Plugin-binding lopen in plaats van ACP. + `/codex permissions`, en verifieert daarna dat een normaal antwoord en een afbeeldingsbijlage + via de native Plugin-binding worden gerouteerd in plaats van ACP. - Codex app-server-harness-smoke: `pnpm test:docker:live-codex-harness` - Voert Gateway-agentbeurten uit via de Plugin-eigen Codex app-server-harness, verifieert `/codex status` en `/codex models`, en oefent standaard image, - cron MCP, sub-agent en Guardian-probes. Schakel de sub-agent-probe uit met + cron MCP, sub-agent- en Guardian-probes. Schakel de sub-agent-probe uit met `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0` wanneer je andere Codex - app-server-failures isoleert. Voor een gerichte sub-agent-check schakel je de andere probes uit: + app-server-fouten isoleert. Voor een gerichte sub-agent-check schakel je de andere probes uit: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=1 pnpm test:docker:live-codex-harness`. Dit stopt na de sub-agent-probe tenzij `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0` is ingesteld. -- Crestodian rescue command-smoke: `pnpm test:live:crestodian-rescue-channel` - - Opt-in extra controle voor de message-channel rescue command - surface. Deze oefent `/crestodian status`, zet een persistente modelwijziging in de wachtrij, - antwoordt `/crestodian yes` en verifieert het audit-/config-write-pad. +- Crestodian rescue-command-smoke: `pnpm test:live:crestodian-rescue-channel` + - Opt-in riem-en-bretels-check voor de message-channel rescue-command + surface. Deze oefent `/crestodian status`, zet een permanente modelwijziging + in de wachtrij, antwoordt `/crestodian yes`, en verifieert het audit-/config-schrijppad. - Crestodian planner Docker-smoke: `pnpm test:docker:crestodian-planner` - - Voert Crestodian uit in een configloze container met een nep-Claude-CLI op `PATH` - en verifieert dat de fuzzy planner-fallback wordt vertaald naar een geaudite typed - config write. + - Voert Crestodian uit in een configloze container met een nep-Claude CLI op `PATH` + en verifieert dat de fuzzy planner fallback wordt vertaald naar een geaudite, getypte + configschrijfactie. - Crestodian first-run Docker-smoke: `pnpm test:docker:crestodian-first-run` - Start vanuit een lege OpenClaw-state-dir, routeert kale `openclaw` naar - Crestodian, past setup/model/agent/Discord Plugin + SecretRef-writes toe, - valideert config en verifieert auditvermeldingen. Hetzelfde Ring 0-setuppad wordt + Crestodian, past setup/model/agent/Discord Plugin + SecretRef-schrijfacties toe, + valideert config en verifieert audit-items. Hetzelfde Ring 0-setuppad wordt ook gedekt in QA Lab door `pnpm openclaw qa suite --scenario crestodian-ring-zero-setup`. -- Moonshot/Kimi cost-smoke: met `MOONSHOT_API_KEY` ingesteld, voer - `openclaw models list --provider moonshot --json` uit en voer daarna een geïsoleerde +- Moonshot/Kimi-kostensmoke: met `MOONSHOT_API_KEY` ingesteld, voer + `openclaw models list --provider moonshot --json` uit, en voer daarna een geïsoleerde `openclaw agent --local --session-id live-kimi-cost --message 'Reply exactly: KIMI_LIVE_OK' --thinking off --json` - uit tegen `moonshot/kimi-k2.6`. Verifieer dat de JSON Moonshot/K2.6 rapporteert en het + uit tegen `moonshot/kimi-k2.6`. Verifieer dat de JSON Moonshot/K2.6 rapporteert en dat het assistenttranscript genormaliseerde `usage.cost` opslaat. -Wanneer je slechts één falende case nodig hebt, geef dan de voorkeur aan het beperken van live tests via de allowlist-env-vars die hieronder worden beschreven. +Wanneer je slechts één falende case nodig hebt, geef dan de voorkeur aan het versmallen van live-tests via de allowlist-env-vars die hieronder worden beschreven. ## QA-specifieke runners -Deze opdrachten staan naast de hoofdtestsuites wanneer je QA-lab-realisme nodig hebt: +Deze commando's staan naast de hoofdtestsuites wanneer je QA-lab-realiteit nodig hebt: -CI voert QA Lab uit in dedicated workflows. `Parity gate` draait op matchende PR's en +CI voert QA Lab uit in toegewijde workflows. `Parity gate` draait op overeenkomende PR's en via handmatige dispatch met mockproviders. `QA-Lab - All Lanes` draait elke nacht op `main` en via handmatige dispatch met de mock parity gate, live Matrix-lane, Convex-beheerde live Telegram-lane en Convex-beheerde live Discord-lane als parallelle jobs. Geplande QA- en releasechecks geven Matrix `--profile fast` -expliciet mee, terwijl de standaardwaarde van de Matrix-CLI en handmatige workflowinput -`all` blijft; handmatige dispatch kan `all` sharden naar `transport`, `media`, `e2ee-smoke`, -`e2ee-deep` en `e2ee-cli`-jobs. `OpenClaw Release Checks` draait parity plus -de snelle Matrix- en Telegram-lanes vóór releasegoedkeuring, met +expliciet mee, terwijl de Matrix CLI en de handmatige workflowinput standaard +`all` blijven; handmatige dispatch kan `all` sharden naar `transport`, `media`, `e2ee-smoke`, +`e2ee-deep` en `e2ee-cli`-jobs. `OpenClaw Release Checks` voert parity plus +de snelle Matrix- en Telegram-lanes uit vóór releasegoedkeuring, met `mock-openai/gpt-5.5` voor release-transportchecks zodat ze deterministisch blijven en normale provider-Plugin-startup vermijden. Deze live transport-Gateways schakelen memory search uit; memory-gedrag blijft gedekt door de QA parity-suites. -Volledige release live media-shards gebruiken -`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, waarin -`ffmpeg` en `ffprobe` al aanwezig zijn. Docker live model/backend-shards gebruiken de gedeelde -`ghcr.io/openclaw/openclaw-live-test:`-image die één keer per geselecteerde -commit wordt gebouwd, en halen die daarna op met `OPENCLAW_SKIP_DOCKER_BUILD=1` in plaats van opnieuw te bouwen -binnen elke shard. +Volledige release live-media-shards gebruiken +`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, dat al +`ffmpeg` en `ffprobe` bevat. Docker live-model-/backend-shards gebruiken de gedeelde +`ghcr.io/openclaw/openclaw-live-test:`-image die eenmaal per geselecteerde +commit wordt gebouwd, en pullen die daarna met `OPENCLAW_SKIP_DOCKER_BUILD=1` in plaats van +opnieuw te bouwen binnen elke shard. - `pnpm openclaw qa suite` - Voert repo-ondersteunde QA-scenario's rechtstreeks op de host uit. - Voert meerdere geselecteerde scenario's standaard parallel uit met geïsoleerde Gateway-workers. `qa-channel` gebruikt standaard concurrency 4 (begrensd door het - geselecteerde aantal scenario's). Gebruik `--concurrency ` om het aantal workers - af te stemmen, of `--concurrency 1` voor de oudere seriële lane. - - Stopt met non-zero wanneer een scenario faalt. Gebruik `--allow-failures` wanneer je + aantal geselecteerde scenario's). Gebruik `--concurrency ` om het aantal + workers af te stemmen, of `--concurrency 1` voor de oudere seriële lane. + - Stopt met een niet-nul exitcode wanneer een scenario faalt. Gebruik `--allow-failures` wanneer je artifacts wilt zonder falende exitcode. - Ondersteunt providermodi `live-frontier`, `mock-openai` en `aimock`. `aimock` start een lokale AIMock-ondersteunde providerserver voor experimentele - fixture- en protocol-mockdekking zonder de scenario-bewuste + fixture- en protocol-mock-coverage zonder de scenario-bewuste `mock-openai`-lane te vervangen. - `pnpm test:gateway:cpu-scenarios` - - Voert de Gateway-startup-bench plus een klein mock QA Lab-scenariopakket uit + - Voert de Gateway-startup-bench uit plus een klein mock QA Lab-scenariopakket (`channel-chat-baseline`, `memory-failure-fallback`, `gateway-restart-inflight-run`) en schrijft een gecombineerde CPU-observatie- samenvatting onder `.artifacts/gateway-cpu-scenarios/`. - Markeert standaard alleen aanhoudende hot-CPU-observaties (`--cpu-core-warn` - plus `--hot-wall-warn-ms`), zodat korte startup-bursts als metrics worden vastgelegd - zonder eruit te zien als de minutenlange gateway peg-regressie. + plus `--hot-wall-warn-ms`), zodat korte startpieken als metrics worden vastgelegd + zonder eruit te zien als de minutenlange Gateway-peg-regressie. - Gebruikt gebouwde `dist`-artifacts; voer eerst een build uit wanneer de checkout nog geen verse runtime-output heeft. - `pnpm openclaw qa suite --runner multipass` - Voert dezelfde QA-suite uit binnen een wegwerpbare Multipass Linux-VM. - - Houdt hetzelfde scenarioselectiegedrag als `qa suite` op de host. - - Hergebruikt dezelfde provider-/modelselectieflags als `qa suite`. - - Live runs forwarden de ondersteunde QA-auth-inputs die praktisch zijn voor de guest: - env-gebaseerde providersleutels, het QA live provider-configpad en `CODEX_HOME` + - Behoudt hetzelfde scenarioselectiegedrag als `qa suite` op de host. + - Hergebruikt dezelfde provider-/modelselectievlaggen als `qa suite`. + - Live-runs forwarden de ondersteunde QA-auth-inputs die praktisch zijn voor de guest: + env-gebaseerde providersleutels, het QA live-providerconfigpad en `CODEX_HOME` wanneer aanwezig. - - Outputdirs moeten onder de repo-root blijven zodat de guest via - de gemounte workspace terug kan schrijven. + - Outputdirs moeten onder de repo-root blijven zodat de guest kan terugschrijven via + de gemounte workspace. - Schrijft het normale QA-rapport + samenvatting plus Multipass-logs onder `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - - Start de Docker-ondersteunde QA-site voor operator-achtige QA-werkzaamheden. + - Start de Docker-ondersteunde QA-site voor operatorstijl-QA-werk. - `pnpm test:docker:npm-onboard-channel-agent` - - Bouwt een npm-tarball uit de huidige checkout, installeert die globaal in + - Bouwt een npm-tarball vanuit de huidige checkout, installeert deze globaal in Docker, voert niet-interactieve OpenAI API-key-onboarding uit, configureert standaard Telegram, - verifieert dat het inschakelen van de Plugin runtime-dependencies on demand installeert, - voert doctor uit en voert één lokale agentbeurt uit tegen een gemockt OpenAI- + verifieert dat het inschakelen van de Plugin runtime-afhankelijkheden op aanvraag installeert, + voert doctor uit en voert één lokale agentbeurt uit tegen een gemockt OpenAI endpoint. - Gebruik `OPENCLAW_NPM_ONBOARD_CHANNEL=discord` om dezelfde packaged-install - lane met Discord te draaien. + lane met Discord uit te voeren. - `pnpm test:docker:session-runtime-context` - - Voert een deterministische built-app Docker-smoke uit voor embedded runtime context- - transcripts. Deze verifieert dat verborgen OpenClaw-runtimecontext wordt bewaard als een - niet-weergegeven custom message in plaats van te lekken in de zichtbare gebruikersbeurt, - seedt daarna een affected broken session JSONL en verifieert dat - `openclaw doctor --fix` deze herschrijft naar de actieve branch met een backup. + - Voert een deterministische built-app Docker-smoke uit voor ingebedde runtime-context- + transcripties. Deze verifieert dat verborgen OpenClaw-runtimecontext wordt bewaard als een + niet-weergegeven aangepast bericht in plaats van te lekken naar de zichtbare gebruikersbeurt, + seedt daarna een getroffen kapotte sessie-JSONL en verifieert dat + `openclaw doctor --fix` deze herschrijft naar de actieve branch met een back-up. - `pnpm test:docker:npm-telegram-live` - - Installeert een OpenClaw-packagecandidate in Docker, voert installed-package- + - Installeert een OpenClaw-pakketkandidaat in Docker, voert installed-package onboarding uit, configureert Telegram via de geïnstalleerde CLI en hergebruikt daarna de - live Telegram-QA-lane met dat geïnstalleerde package als de SUT Gateway. + live Telegram QA-lane met dat geïnstalleerde pakket als de SUT-Gateway. - Standaard is `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`; stel `OPENCLAW_NPM_TELEGRAM_PACKAGE_TGZ=/path/to/openclaw-current.tgz` of - `OPENCLAW_CURRENT_PACKAGE_TGZ` in om in plaats van installeren uit de registry een opgeloste lokale tarball te testen. - - Gebruikt dezelfde Telegram-env-inloggegevens of Convex-credentialbron als + `OPENCLAW_CURRENT_PACKAGE_TGZ` in om in plaats van installatie uit het registry een opgeloste lokale tarball te testen. + - Gebruikt dezelfde Telegram-env-inloggegevens of Convex-inloggegevensbron als `pnpm openclaw qa telegram`. Stel voor CI-/releaseautomatisering `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` in plus - `OPENCLAW_QA_CONVEX_SITE_URL` en de rol-secret. Als - `OPENCLAW_QA_CONVEX_SITE_URL` en een Convex role secret in CI aanwezig zijn, - selecteert de Docker-wrapper automatisch Convex. + `OPENCLAW_QA_CONVEX_SITE_URL` en het rolgeheim. Als + `OPENCLAW_QA_CONVEX_SITE_URL` en een Convex-rolgeheim aanwezig zijn in CI, + selecteert de Docker-wrapper Convex automatisch. - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` overschrijft de gedeelde `OPENCLAW_QA_CREDENTIAL_ROLE` alleen voor deze lane. - GitHub Actions stelt deze lane beschikbaar als de handmatige maintainer-workflow `NPM Telegram Beta E2E`. Deze draait niet bij merge. De workflow gebruikt de - `qa-live-shared`-environment en Convex CI-credentialleases. -- GitHub Actions stelt ook `Package Acceptance` beschikbaar voor productproof als side-run - tegen één candidate package. Deze accepteert een vertrouwde ref, gepubliceerde npm spec, + `qa-live-shared`-omgeving en Convex CI-credentialleases. +- GitHub Actions stelt ook `Package Acceptance` beschikbaar voor side-run productbewijs + tegen één kandidaatpakket. Deze accepteert een vertrouwde ref, gepubliceerde npm-spec, HTTPS-tarball-URL plus SHA-256, of tarball-artifact uit een andere run, uploadt - de genormaliseerde `openclaw-current.tgz` als `package-under-test` en voert daarna de + de genormaliseerde `openclaw-current.tgz` als `package-under-test`, en voert daarna de bestaande Docker E2E-scheduler uit met smoke-, package-, product-, full- of custom lane-profielen. Stel `telegram_mode=mock-openai` of `live-frontier` in om de - Telegram-QA-workflow tegen hetzelfde `package-under-test`-artifact te draaien. - - Nieuwste beta-productproof: + Telegram QA-workflow tegen hetzelfde `package-under-test`-artifact uit te voeren. + - Nieuwste bèta-productbewijs: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -213,7 +213,7 @@ gh workflow run package-acceptance.yml --ref main \ -f telegram_mode=mock-openai ``` -- Exacte tarball-URL-proof vereist een digest: +- Exact tarball-URL-bewijs vereist een digest: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -223,7 +223,7 @@ gh workflow run package-acceptance.yml --ref main \ -f suite_profile=package ``` -- Artifactbewijs downloadt een tarball-artifact uit een andere Actions-run: +- Artefactbewijs downloadt een tarball-artefact uit een andere Actions-run: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -234,32 +234,32 @@ gh workflow run package-acceptance.yml --ref main \ ``` - `pnpm test:docker:bundled-channel-deps` - - Pakt de huidige OpenClaw-build in en installeert deze in Docker, start de Gateway - met OpenAI geconfigureerd en schakelt daarna gebundelde kanaal-/Plugins in via config- - bewerkingen. - - Verifieert dat setupdetectie ongeconfigureerde runtime-afhankelijkheden van Plugins - afwezig laat, dat de eerste geconfigureerde Gateway- of doctor-run de runtime- - afhankelijkheden van elke gebundelde Plugin op aanvraag installeert, en dat een tweede herstart - afhankelijkheden die al waren geactiveerd niet opnieuw installeert. + - Pakt en installeert de huidige OpenClaw-build in Docker, start de Gateway + met OpenAI geconfigureerd, en schakelt daarna gebundelde kanalen/Plugins in + via configuratiebewerkingen. + - Verifieert dat setup-discovery niet-geconfigureerde runtimeafhankelijkheden + van Plugins afwezig laat, dat de eerste geconfigureerde Gateway- of doctor-run + de runtimeafhankelijkheden van elke gebundelde Plugin op aanvraag installeert, + en dat een tweede herstart afhankelijkheden die al waren geactiveerd niet + opnieuw installeert. - Installeert ook een bekende oudere npm-baseline, schakelt Telegram in voordat - `openclaw update --tag ` wordt uitgevoerd, en verifieert dat de post-update - doctor van de kandidaat gebundelde runtime-afhankelijkheden van kanalen repareert zonder - postinstall-reparatie aan de harness-kant. + `openclaw update --tag ` wordt uitgevoerd, en verifieert dat de + post-update doctor van de kandidaat gebundelde kanaal-runtimeafhankelijkheden + herstelt zonder postinstall-herstel aan de kant van de testharnas. - `pnpm test:parallels:npm-update` - - Voert de native update-smoke voor packaged install uit op Parallels-gasten. Elk + - Voert de native update-smoke voor verpakte installaties uit over Parallels-gasten. Elk geselecteerd platform installeert eerst het gevraagde baselinepakket, voert daarna - de geïnstalleerde opdracht `openclaw update` uit in dezelfde gast en verifieert de - geïnstalleerde versie, updatestatus, gereedheid van de Gateway en één lokale agent- - beurt. + het geïnstalleerde commando `openclaw update` uit in dezelfde gast en verifieert de + geïnstalleerde versie, updatestatus, Gateway-gereedheid en één lokale agentbeurt. - Gebruik `--platform macos`, `--platform windows` of `--platform linux` tijdens - iteratie op één gast. Gebruik `--json` voor het pad van het samenvattingsartifact en + iteratie op één gast. Gebruik `--json` voor het pad naar het samenvattingsartefact en de status per lane. - De OpenAI-lane gebruikt standaard `openai/gpt-5.5` voor het bewijs met een live agentbeurt. Geef `--model ` door of stel `OPENCLAW_PARALLELS_OPENAI_MODEL` in wanneer je bewust een ander OpenAI-model valideert. - - Wikkel lange lokale runs in een host-timeout, zodat vastgelopen Parallels-transport - niet de rest van het testvenster kan verbruiken: + - Wikkel lange lokale runs in een host-time-out zodat vastlopende Parallels-transporten + de rest van het testvenster niet kunnen verbruiken: ```bash timeout --foreground 150m pnpm test:parallels:npm-update -- --json @@ -268,55 +268,54 @@ gh workflow run package-acceptance.yml --ref main \ - Het script schrijft geneste lane-logs onder `/tmp/openclaw-parallels-npm-update.*`. Inspecteer `windows-update.log`, `macos-update.log` of `linux-update.log` - voordat je aanneemt dat de buitenste wrapper vastloopt. - - Windows-update kan op een koude gast 10 tot 15 minuten besteden aan post-update doctor-/ - runtime-afhankelijkheidsreparatie; dat is nog steeds gezond wanneer het geneste + voordat je aanneemt dat de buitenste wrapper is vastgelopen. + - Windows-update kan op een koude gast 10 tot 15 minuten besteden aan post-update + doctor-/runtimeafhankelijkheidsherstel; dat is nog steeds gezond wanneer de geneste npm-debuglog vooruitgaat. - - Voer deze aggregate wrapper niet parallel uit met afzonderlijke Parallels- - macOS-, Windows- of Linux-smoke-lanes. Ze delen VM-status en kunnen botsen op + - Voer deze aggregatiewrapper niet parallel uit met individuele Parallels + macOS-, Windows- of Linux-smoke-lanes. Ze delen VM-status en kunnen botsen bij snapshotherstel, pakketservering of Gateway-status van de gast. - - Het post-updatebewijs voert het normale gebundelde Plugin-oppervlak uit omdat - capability-facades zoals spraak, beeldgeneratie en media- - begrip worden geladen via gebundelde runtime-API's, zelfs wanneer de agentbeurt - zelf alleen een eenvoudige tekstantwoordcontrole uitvoert. + - Het post-updatebewijs gebruikt het normale oppervlak van gebundelde Plugins omdat + capability-facades zoals spraak, beeldgeneratie en mediabegrip worden geladen via + gebundelde runtime-API's, zelfs wanneer de agentbeurt zelf alleen een eenvoudige + tekstrespons controleert. - `pnpm openclaw qa aimock` - - Start alleen de lokale AIMock-provider-server voor directe protocol-smoke- - tests. + - Start alleen de lokale AIMock-providerserver voor directe protocol-smoketests. - `pnpm openclaw qa matrix` - - Voert de Matrix live QA-lane uit tegen een disposable Tuwunel-homeserver met Docker-backend. Alleen source-checkout — packaged installs leveren `qa-lab` niet mee. - - Volledige CLI, profiel-/scenariocatalogus, env-vars en artifactindeling: [Matrix QA](/nl/concepts/qa-matrix). + - Voert de Matrix live QA-lane uit tegen een wegwerpbare Docker-ondersteunde Tuwunel-homeserver. Alleen source-checkout — verpakte installaties leveren `qa-lab` niet mee. + - Volledige CLI, profiel-/scenariocatalogus, omgevingsvariabelen en artefactindeling: [Matrix QA](/nl/concepts/qa-matrix). - `pnpm openclaw qa telegram` - - Voert de Telegram live QA-lane uit tegen een echte privégroep met de driver- en SUT-bottokens uit env. + - Voert de Telegram live QA-lane uit tegen een echte privégroep met de driver- en SUT-bottokens uit de omgeving. - Vereist `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` en `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. De groeps-id moet de numerieke Telegram-chat-id zijn. - - Ondersteunt `--credential-source convex` voor gedeelde gepoolde referenties. Gebruik standaard env-modus, of stel `OPENCLAW_QA_CREDENTIAL_SOURCE=convex` in om gepoolde leases te gebruiken. - - Sluit af met een niet-nulstatus wanneer een scenario faalt. Gebruik `--allow-failures` wanneer je - artifacts wilt zonder falende exitcode. - - Vereist twee verschillende bots in dezelfde privégroep, waarbij de SUT-bot een Telegram-gebruikersnaam blootlegt. - - Schakel voor stabiele bot-naar-bot-observatie Bot-to-Bot Communication Mode in `@BotFather` in voor beide bots en zorg dat de driverbot groepsbotverkeer kan observeren. - - Schrijft een Telegram QA-rapport, samenvatting en artifact met waargenomen berichten onder `.artifacts/qa-e2e/...`. Antwoordscenario's bevatten RTT vanaf het verzendverzoek van de driver tot het waargenomen SUT-antwoord. + - Ondersteunt `--credential-source convex` voor gedeelde gepoolde inloggegevens. Gebruik standaard de env-modus, of stel `OPENCLAW_QA_CREDENTIAL_SOURCE=convex` in om gepoolde leases te gebruiken. + - Sluit af met een niet-nulcode wanneer een scenario faalt. Gebruik `--allow-failures` wanneer je + artefacten wilt zonder falende afsluitcode. + - Vereist twee verschillende bots in dezelfde privégroep, waarbij de SUT-bot een Telegram-gebruikersnaam exposeert. + - Schakel voor stabiele bot-tot-bot-observatie Bot-to-Bot Communication Mode in `@BotFather` in voor beide bots en zorg dat de driver-bot groepsbotverkeer kan observeren. + - Schrijft een Telegram QA-rapport, samenvatting en observed-messages-artefact onder `.artifacts/qa-e2e/...`. Antwoordscenario's bevatten RTT van driver-verzendverzoek tot geobserveerd SUT-antwoord. -Live transport-lanes delen één standaardcontract zodat nieuwe transports niet afwijken; de dekkingsmatrix per lane staat in [QA-overzicht → Live transport-dekking](/nl/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` is de brede synthetische suite en maakt geen deel uit van die matrix. +Live transport-lanes delen één standaardcontract zodat nieuwe transporten niet afdrijven; de dekkingsmatrix per lane staat in [QA-overzicht → Live transport-dekking](/nl/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` is de brede synthetische suite en maakt geen deel uit van die matrix. -### Gedeelde Telegram-referenties via Convex (v1) +### Gedeelde Telegram-inloggegevens via Convex (v1) Wanneer `--credential-source convex` (of `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) is ingeschakeld voor -`openclaw qa telegram`, verkrijgt QA lab een exclusieve lease uit een pool met Convex-backend, verstuurt Heartbeats -voor die lease terwijl de lane draait, en geeft de lease vrij bij afsluiten. +`openclaw qa telegram`, verkrijgt QA lab een exclusieve lease uit een door Convex ondersteunde pool, heartbeats +die lease terwijl de lane draait, en geeft de lease vrij bij afsluiten. -Referentieprojectscaffold voor Convex: +Referentiescaffold voor Convex-project: - `qa/convex-credential-broker/` Vereiste env-vars: - `OPENCLAW_QA_CONVEX_SITE_URL` (bijvoorbeeld `https://your-deployment.convex.site`) -- Eén secret voor de geselecteerde rol: +- Eén geheim voor de geselecteerde rol: - `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` voor `maintainer` - `OPENCLAW_QA_CONVEX_SECRET_CI` voor `ci` -- Selectie van referentierol: +- Selectie van inloggegevensrol: - CLI: `--credential-role maintainer|ci` - - Standaard env: `OPENCLAW_QA_CREDENTIAL_ROLE` (standaard `ci` in CI, anders `maintainer`) + - Standaardwaarde via env: `OPENCLAW_QA_CREDENTIAL_ROLE` (standaard `ci` in CI, anders `maintainer`) Optionele env-vars: @@ -326,11 +325,11 @@ Optionele env-vars: - `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (standaard `15000`) - `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (standaard `/qa-credentials/v1`) - `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (optionele trace-id) -- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` staat loopback-`http://`-Convex-URL's toe voor uitsluitend lokale ontwikkeling. +- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` staat loopback-`http://` Convex-URL's toe voor uitsluitend lokale ontwikkeling. -`OPENCLAW_QA_CONVEX_SITE_URL` hoort bij normaal gebruik `https://` te gebruiken. +`OPENCLAW_QA_CONVEX_SITE_URL` moet bij normaal gebruik `https://` gebruiken. -Beheeropdrachten voor maintainers (pool add/remove/list) vereisen specifiek +Maintainer-beheercommando's (pool toevoegen/verwijderen/weergeven) vereisen specifiek `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. CLI-helpers voor maintainers: @@ -342,10 +341,10 @@ pnpm openclaw qa credentials list --kind telegram pnpm openclaw qa credentials remove --credential-id ``` -Gebruik `doctor` vóór live runs om de Convex-site-URL, broker-secrets, -endpointprefix, HTTP-timeout en admin/list-bereikbaarheid te controleren zonder -secretwaarden af te drukken. Gebruik `--json` voor machineleesbare uitvoer in scripts en CI- -hulpprogramma's. +Gebruik `doctor` vóór live-runs om de Convex-site-URL, brokergeheimen, +endpointprefix, HTTP-time-out en bereikbaarheid van admin/list te controleren zonder +geheime waarden af te drukken. Gebruik `--json` voor machineleesbare uitvoer in scripts en CI +utilities. Standaard endpointcontract (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): @@ -359,14 +358,14 @@ Standaard endpointcontract (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1` - `POST /release` - Verzoek: `{ kind, ownerId, actorRole, credentialId, leaseToken }` - Succes: `{ status: "ok" }` (of lege `2xx`) -- `POST /admin/add` (alleen maintainer-secret) +- `POST /admin/add` (alleen maintainer-geheim) - Verzoek: `{ kind, actorId, payload, note?, status? }` - Succes: `{ status: "ok", credential }` -- `POST /admin/remove` (alleen maintainer-secret) +- `POST /admin/remove` (alleen maintainer-geheim) - Verzoek: `{ credentialId, actorId }` - Succes: `{ status: "ok", changed, credential }` - - Actieve lease-guard: `{ status: "error", code: "LEASE_ACTIVE", ... }` -- `POST /admin/list` (alleen maintainer-secret) + - Guard voor actieve lease: `{ status: "error", code: "LEASE_ACTIVE", ... }` +- `POST /admin/list` (alleen maintainer-geheim) - Verzoek: `{ kind?, status?, includePayload?, limit? }` - Succes: `{ status: "ok", credentials, count }` @@ -374,86 +373,86 @@ Payloadvorm voor Telegram-kind: - `{ groupId: string, driverToken: string, sutToken: string }` - `groupId` moet een numerieke Telegram-chat-id-string zijn. -- `admin/add` valideert deze vorm voor `kind: "telegram"` en weigert verkeerd gevormde payloads. +- `admin/add` valideert deze vorm voor `kind: "telegram"` en weigert misvormde payloads. ### Een kanaal toevoegen aan QA -De architectuur- en scenario-helpernamen voor nieuwe kanaaladapters staan in [QA-overzicht → Een kanaal toevoegen](/nl/concepts/qa-e2e-automation#adding-a-channel). De minimumeis: implementeer de transportrunner op de gedeelde `qa-lab`-host-seam, declareer `qaRunners` in het Plugin-manifest, mount als `openclaw qa ` en schrijf scenario's onder `qa/scenarios/`. +De architectuur- en scenario-helpernamen voor nieuwe kanaaladapters staan in [QA-overzicht → Een kanaal toevoegen](/nl/concepts/qa-e2e-automation#adding-a-channel). De minimumbalk: implementeer de transportrunner op de gedeelde `qa-lab`-hostseam, declareer `qaRunners` in het Plugin-manifest, mount als `openclaw qa `, en schrijf scenario's onder `qa/scenarios/`. -## Testsuites (wat draait waar) +## Testsuites (wat waar draait) -Zie de suites als “toenemende realiteitsgraad” (en toenemende flakiness/kosten): +Zie de suites als “toenemend realisme” (en toenemende instabiliteit/kosten): -### Unit / integration (standaard) +### Unit / integratie (standaard) -- Opdracht: `pnpm test` -- Config: niet-getargete runs gebruiken de `vitest.full-*.config.ts`-shardset en kunnen multi-project-shards uitbreiden naar per-project-configs voor parallelle planning +- Commando: `pnpm test` +- Configuratie: niet-gerichte runs gebruiken de shardset `vitest.full-*.config.ts` en kunnen multi-projectshards uitbreiden naar per-projectconfiguraties voor parallelle planning - Bestanden: core-/unit-inventarissen onder `src/**/*.test.ts`, `packages/**/*.test.ts` en `test/**/*.test.ts`; UI-unittests draaien in de toegewezen `unit-ui`-shard -- Scope: - - Pure unittests - - In-process integration-tests (Gateway-auth, routering, tooling, parsing, config) +- Bereik: + - Zuivere unittests + - In-process integratietests (Gateway-auth, routering, tooling, parsing, configuratie) - Deterministische regressies voor bekende bugs - Verwachtingen: - Draait in CI - - Geen echte keys vereist + - Geen echte sleutels vereist - Moet snel en stabiel zijn - - Resolver- en public-surface-loadertests moeten breed `api.js`- en - `runtime-api.js`-fallbackgedrag bewijzen met gegenereerde kleine Plugin-fixtures, niet met - echte gebundelde Plugin-bron-API's. Echte Plugin-API-loads horen thuis in + - Resolver- en public-surface-loader-tests moeten breed fallbackgedrag van `api.js` en + `runtime-api.js` bewijzen met gegenereerde kleine Plugin-fixtures, niet met + echte bron-API's van gebundelde Plugins. Echte Plugin-API-loads horen thuis in Plugin-eigen contract-/integratiesuites. - - Niet-gerichte `pnpm test`-runs voeren twaalf kleinere shard-configuraties uit (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) in plaats van één gigantisch native root-projectproces. Dit verlaagt de piek-RSS op belaste machines en voorkomt dat auto-reply-/extensiewerk niet-gerelateerde suites verdringt. - - `pnpm test --watch` gebruikt nog steeds de native root-projectgrafiek `vitest.config.ts`, omdat een watch-loop met meerdere shards niet praktisch is. - - `pnpm test`, `pnpm test:watch` en `pnpm test:perf:imports` routeren expliciete bestands-/directorydoelen eerst via gescopete lanes, zodat `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` de volledige opstartkosten van het root-project vermijdt. - - `pnpm test:changed` breidt gewijzigde git-paden standaard uit naar goedkope gescopete lanes: directe testbewerkingen, aangrenzende `*.test.ts`-bestanden, expliciete bronmappings en lokale afhankelijken in de importgrafiek. Config-/setup-/package-bewerkingen voeren tests niet breed uit, tenzij je expliciet `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` gebruikt. - - `pnpm check:changed` is de normale slimme lokale check-gate voor smal werk. Deze classificeert de diff in core, core-tests, extensies, extensietests, apps, docs, releasemetadata, live Docker-tooling en tooling, en voert daarna de bijpassende typecheck-, lint- en guard-commando's uit. Vitest-tests worden niet uitgevoerd; gebruik `pnpm test:changed` of expliciet `pnpm test ` voor testbewijs. Versiebumpen met alleen releasemetadata voeren gerichte versie-/config-/root-afhankelijkheidschecks uit, met een guard die package-wijzigingen buiten het top-level versieveld afwijst. - - Bewerkingen aan de live Docker ACP-harness voeren gerichte checks uit: shellsyntaxis voor de live Docker-authscripts en een dry-run van de live Docker-scheduler. `package.json`-wijzigingen worden alleen meegenomen wanneer de diff beperkt is tot `scripts["test:docker:live-*"]`; dependency-, export-, versie- en andere package-oppervlakbewerkingen gebruiken nog steeds de bredere guards. - - Import-lichte unittests uit agents, commands, plugins, auto-reply-helpers, `plugin-sdk` en vergelijkbare pure utility-gebieden lopen via de `unit-fast`-lane, die `test/setup-openclaw-runtime.ts` overslaat; stateful/runtime-zware bestanden blijven op de bestaande lanes. - - Geselecteerde helperbronbestanden voor `plugin-sdk` en `commands` mappen changed-mode-runs ook naar expliciete aangrenzende tests in die lichte lanes, zodat helperbewerkingen vermijden dat de volledige zware suite voor die directory opnieuw draait. - - `auto-reply` heeft aparte buckets voor top-level core-helpers, top-level `reply.*`-integratietests en de subtree `src/auto-reply/reply/**`. CI splitst de reply-subtree verder in agent-runner-, dispatch- en commands/state-routing-shards, zodat één import-zware bucket niet de volledige Node-staart bezit. - - Normale PR/main-CI slaat bewust de extensiebatch-sweep en de release-only `agentic-plugins`-shard over. Volledige Release Validation dispatcht de aparte child-workflow `Plugin Prerelease` voor die plugin-/extensie-zware suites op releasekandidaten. + - Niet-gerichte `pnpm test` draait twaalf kleinere shardconfiguraties (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) in plaats van één gigantisch native rootprojectproces. Dit verlaagt de piek-RSS op belaste machines en voorkomt dat auto-reply-/extensiewerk niet-gerelateerde suites uithongert. + - `pnpm test --watch` gebruikt nog steeds de native root-`vitest.config.ts`-projectgraaf, omdat een watch-lus met meerdere shards niet praktisch is. + - `pnpm test`, `pnpm test:watch` en `pnpm test:perf:imports` leiden expliciete bestands-/directorydoelen eerst via gescopete lanes, zodat `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` de volledige opstartkosten van het rootproject vermijdt. + - `pnpm test:changed` breidt gewijzigde git-paden standaard uit naar goedkope gescopete lanes: directe testbewerkingen, naastliggende `*.test.ts`-bestanden, expliciete bronmappings en lokale importgraaf-afhankelijken. Configuratie-/setup-/packagebewerkingen voeren geen brede testrun uit, tenzij je expliciet `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` gebruikt. + - `pnpm check:changed` is de normale slimme lokale check-gate voor nauw werk. Deze classificeert de diff in core, core-tests, extensies, extensietests, apps, docs, releasemetadata, live Docker-tooling en tooling, en voert daarna de bijbehorende typecheck-, lint- en guard-commando’s uit. Deze draait geen Vitest-tests; roep `pnpm test:changed` of expliciet `pnpm test ` aan voor testbewijs. Versiebumpen met alleen releasemetadata draait gerichte versie-/config-/root-dependency-checks, met een guard die packagewijzigingen buiten het versieveld op topniveau afwijst. + - Bewerkingen aan de live Docker ACP-harness draaien gerichte checks: shellsyntaxis voor de live Docker-auth-scripts en een dry-run van de live Docker-scheduler. Wijzigingen in `package.json` worden alleen meegenomen wanneer de diff beperkt is tot `scripts["test:docker:live-*"]`; dependency-, export-, versie- en andere package-oppervlakbewerkingen gebruiken nog steeds de bredere guards. + - Importlichte unit-tests uit agents, commands, plugins, auto-reply-helpers, `plugin-sdk` en vergelijkbare pure utility-gebieden lopen via de `unit-fast`-lane, die `test/setup-openclaw-runtime.ts` overslaat; stateful/runtime-zware bestanden blijven op de bestaande lanes. + - Geselecteerde helperbronbestanden uit `plugin-sdk` en `commands` mappen runs in changed-modus ook naar expliciete naastliggende tests in die lichte lanes, zodat helperbewerkingen de volledige zware suite voor die directory niet opnieuw draaien. + - `auto-reply` heeft aparte buckets voor core-helpers op topniveau, `reply.*`-integratietests op topniveau en de `src/auto-reply/reply/**`-subtree. CI splitst de reply-subtree verder in shards voor agent-runner, dispatch en commands/state-routing, zodat één importzware bucket niet de volledige Node-staart bezit. + - Normale PR-/main-CI slaat bewust de extensie-batchsweep en de release-only `agentic-plugins`-shard over. Full Release Validation start de aparte `Plugin Prerelease`-childworkflow voor die plugin-/extensiezware suites op releasekandidaten. - + - - Wanneer je inputs voor message-tool discovery of Compaction-runtimecontext wijzigt, behoud beide dekkingsniveaus. + - Wanneer je message-tool-discovery-invoer of runtimecontext voor Compaction wijzigt, behoud dan beide dekkingsniveaus. - Voeg gerichte helperregressies toe voor pure routing- en normalisatiegrenzen. - - Houd de embedded runner-integratiesuites gezond: + - Houd de integratiesuites van de ingebedde runner gezond: `src/agents/pi-embedded-runner/compact.hooks.test.ts`, `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` en `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`. - - Die suites verifiëren dat gescopete ids en Compaction-gedrag nog steeds - via de echte `run.ts`- / `compact.ts`-paden stromen; tests met alleen helpers zijn - geen voldoende vervanging voor die integratiepaden. + - Die suites verifiëren dat gescopete id’s en Compaction-gedrag nog steeds + door de echte `run.ts`- / `compact.ts`-paden stromen; alleen helpertests + zijn geen voldoende vervanging voor die integratiepaden. - + - De basisconfiguratie van Vitest gebruikt standaard `threads`. - De gedeelde Vitest-configuratie zet `isolate: false` vast en gebruikt de - niet-geïsoleerde runner voor de root-projecten, e2e- en live-configuraties. - - De root-UI-lane behoudt zijn `jsdom`-setup en optimizer, maar draait ook op de - gedeelde niet-geïsoleerde runner. - - Elke `pnpm test`-shard erft dezelfde standaardwaarden `threads` + `isolate: false` - van de gedeelde Vitest-configuratie. + niet-geïsoleerde runner in de rootprojecten, e2e- en live-configuraties. + - De root-UI-lane behoudt zijn `jsdom`-setup en optimizer, maar draait ook + op de gedeelde niet-geïsoleerde runner. + - Elke `pnpm test`-shard erft dezelfde `threads` + `isolate: false`-standaarden + uit de gedeelde Vitest-configuratie. - `scripts/run-vitest.mjs` voegt standaard `--no-maglev` toe voor Vitest-child-Node- - processen om V8-compile-churn tijdens grote lokale runs te verminderen. + processen om V8-compileverloop tijdens grote lokale runs te verminderen. Stel `OPENCLAW_VITEST_ENABLE_MAGLEV=1` in om te vergelijken met standaard V8- gedrag. - + - - `pnpm changed:lanes` toont welke architecturale lanes een diff activeert. - - De pre-commit-hook doet alleen formattering. Deze staged geformatteerde bestanden opnieuw en - voert geen lint, typecheck of tests uit. - - Voer `pnpm check:changed` expliciet uit vóór handoff of push wanneer je + - `pnpm changed:lanes` toont welke architectuurlanes een diff triggert. + - De pre-commit-hook is alleen voor formattering. Deze staged geformatteerde bestanden opnieuw en + draait geen lint, typecheck of tests. + - Draai `pnpm check:changed` expliciet vóór overdracht of push wanneer je de slimme lokale check-gate nodig hebt. - `pnpm test:changed` routeert standaard via goedkope gescopete lanes. Gebruik `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` alleen wanneer de agent @@ -461,40 +460,41 @@ Zie de suites als “toenemende realiteitsgraad” (en toenemende flakiness/kost Vitest-dekking nodig heeft. - `pnpm test:max` en `pnpm test:changed:max` behouden hetzelfde routinggedrag, alleen met een hogere workerlimiet. - - Automatisch schalen van lokale workers is bewust conservatief en schaalt terug - wanneer de gemiddelde hostbelasting al hoog is, zodat meerdere gelijktijdige - Vitest-runs standaard minder schade aanrichten. + - Lokale automatische workerschaling is bewust conservatief en schaalt terug + wanneer de load average van de host al hoog is, zodat meerdere gelijktijdige + Vitest-runs standaard minder schade doen. - De basisconfiguratie van Vitest markeert de projecten/configbestanden als - `forceRerunTriggers`, zodat reruns in changed-mode correct blijven wanneer test- - wiring wijzigt. + `forceRerunTriggers`, zodat herhalingen in changed-modus correct blijven wanneer testbedrading + wijzigt. - De configuratie houdt `OPENCLAW_VITEST_FS_MODULE_CACHE` ingeschakeld op ondersteunde hosts; stel `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path` in als je - één expliciete cachelocatie voor directe profiling wilt. + één expliciete cachelocatie wilt voor directe profilering. - + - - `pnpm test:perf:imports` schakelt Vitest-importduurrapportage plus - import-breakdown-output in. - - `pnpm test:perf:imports:changed` beperkt dezelfde profilingweergave tot + - `pnpm test:perf:imports` schakelt Vitest-rapportage van importduur plus + import-breakdown-uitvoer in. + - `pnpm test:perf:imports:changed` scopet dezelfde profileringsweergave naar bestanden die sinds `origin/main` zijn gewijzigd. - - Shard-timingdata wordt geschreven naar `.artifacts/vitest-shard-timings.json`. - Runs voor de volledige configuratie gebruiken het configuratiepad als sleutel; CI-shards met include-pattern - voegen de shardnaam toe, zodat gefilterde shards apart kunnen worden gevolgd. - - Wanneer één hete test nog steeds het grootste deel van zijn tijd besteedt aan opstartimports, - houd zware dependencies achter een smalle lokale `*.runtime.ts`-seam en - mock die seam direct in plaats van runtime-helpers diep te importeren alleen - om ze door te geven aan `vi.mock(...)`. + - Shardtimingdata wordt geschreven naar `.artifacts/vitest-shard-timings.json`. + Runs van de hele configuratie gebruiken het configuratiepad als sleutel; include-pattern-CI- + shards voegen de shardnaam toe, zodat gefilterde shards apart kunnen worden gevolgd. + - Wanneer één hete test nog steeds de meeste tijd kwijt is aan opstartimports, + houd zware dependencies dan achter een smalle lokale `*.runtime.ts`-seam en + mock die seam direct in plaats van runtimehelpers diep te importeren alleen + om ze door `vi.mock(...)` te geven. - `pnpm test:perf:changed:bench -- --ref ` vergelijkt gerouteerde - `test:changed` met het native root-projectpad voor die gecommitte diff en print wall time plus maximale macOS-RSS. + `test:changed` met het native rootprojectpad voor die gecommitte diff en drukt + wandtijd plus macOS max RSS af. - `pnpm test:perf:changed:bench -- --worktree` benchmarkt de huidige - dirty tree door de lijst met gewijzigde bestanden via + vuile tree door de gewijzigde-bestandenlijst via `scripts/test-projects.mjs` en de root-Vitest-configuratie te routeren. - - `pnpm test:perf:profile:main` schrijft een CPU-profiel van de main-thread voor - Vitest-/Vite-opstart- en transform-overhead. - - `pnpm test:perf:profile:runner` schrijft runner-CPU+heap-profielen voor de - unitsuite met bestandsparallellisme uitgeschakeld. + - `pnpm test:perf:profile:main` schrijft een CPU-profiel van de main thread voor + Vitest-/Vite-opstart en transform-overhead. + - `pnpm test:perf:profile:runner` schrijft CPU+-heapprofielen van de runner voor de + unit-suite met bestandsparallellisme uitgeschakeld. @@ -504,49 +504,49 @@ Zie de suites als “toenemende realiteitsgraad” (en toenemende flakiness/kost - Commando: `pnpm test:stability:gateway` - Configuratie: `vitest.gateway.config.ts`, geforceerd naar één worker - Scope: - - Start standaard een echte loopback-Gateway met diagnostiek ingeschakeld - - Stuurt synthetische gateway-berichten, memory- en large-payload-churn door het diagnostische eventpad + - Start een echte loopback-Gateway met diagnostiek standaard ingeschakeld + - Stuurt synthetische gatewayberichten, geheugen- en large-payload-verloop door het diagnostische eventpad - Queryt `diagnostics.stability` via de Gateway WS RPC - - Dekt helpers voor persistentie van de diagnostische stabiliteitsbundel - - Bevestigt dat de recorder begrensd blijft, synthetische RSS-samples onder het drukbudget blijven en wachtrijdieptes per sessie teruglopen naar nul + - Dekt persistentiehelpers voor de diagnostische stabiliteitsbundel + - Assert dat de recorder begrensd blijft, synthetische RSS-samples onder het pressure-budget blijven en wachtrijdieptes per sessie teruglopen naar nul - Verwachtingen: - CI-veilig en zonder sleutels - Smalle lane voor opvolging van stabiliteitsregressies, geen vervanging voor de volledige Gateway-suite -### E2E (Gateway smoke) +### E2E (Gateway-smoke) - Commando: `pnpm test:e2e` - Configuratie: `vitest.e2e.config.ts` -- Bestanden: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` en E2E-tests van gebundelde plugins onder `extensions/` -- Runtime-standaardwaarden: - - Gebruikt Vitest `threads` met `isolate: false`, passend bij de rest van de repo. - - Gebruikt adaptieve workers (CI: maximaal 2, lokaal: standaard 1). +- Bestanden: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` en gebundelde Plugin-E2E-tests onder `extensions/` +- Runtime-standaarden: + - Gebruikt Vitest `threads` met `isolate: false`, overeenkomstig de rest van de repo. + - Gebruikt adaptieve workers (CI: tot 2, lokaal: standaard 1). - Draait standaard in stille modus om console-I/O-overhead te verminderen. -- Nuttige overrides: - - `OPENCLAW_E2E_WORKERS=` om het aantal workers te forceren (begrensd op 16). - - `OPENCLAW_E2E_VERBOSE=1` om uitgebreide console-output opnieuw in te schakelen. +- Handige overrides: + - `OPENCLAW_E2E_WORKERS=` om het aantal workers te forceren (afgetopt op 16). + - `OPENCLAW_E2E_VERBOSE=1` om uitgebreide console-uitvoer weer in te schakelen. - Scope: - - End-to-end-gedrag van de Gateway met meerdere instanties - - WebSocket-/HTTP-oppervlakken, node-pairing en zwaardere networking + - End-to-endgedrag van meerdere gateway-instanties + - WebSocket-/HTTP-oppervlakken, node-pairing en zwaardere netwerkfunctionaliteit - Verwachtingen: - Draait in CI (wanneer ingeschakeld in de pipeline) - Geen echte sleutels vereist - - Meer bewegende delen dan unittests (kan trager zijn) + - Meer bewegende delen dan unit-tests (kan langzamer zijn) -### E2E: OpenShell-backend smoke +### E2E: OpenShell-backend-smoke - Commando: `pnpm test:e2e:openshell` - Bestand: `extensions/openshell/src/backend.e2e.test.ts` - Scope: - - Start een geïsoleerde OpenShell-Gateway op de host via Docker + - Start een geïsoleerde OpenShell-gateway op de host via Docker - Maakt een sandbox vanuit een tijdelijk lokaal Dockerfile - Oefent de OpenShell-backend van OpenClaw uit via echte `sandbox ssh-config` + SSH exec - - Verifieert remote-canoniek bestandssysteemgedrag via de sandbox-fs-bridge + - Verifieert remote-canonical bestandssysteemgedrag via de sandbox-fs-bridge - Verwachtingen: - Alleen opt-in; geen onderdeel van de standaard `pnpm test:e2e`-run - Vereist een lokale `openshell`-CLI plus een werkende Docker-daemon - - Gebruikt geïsoleerde `HOME` / `XDG_CONFIG_HOME` en vernietigt daarna de test-Gateway en sandbox -- Nuttige overrides: + - Gebruikt geïsoleerde `HOME` / `XDG_CONFIG_HOME`, en vernietigt daarna de testgateway en sandbox +- Handige overrides: - `OPENCLAW_E2E_OPENSHELL=1` om de test in te schakelen wanneer je de bredere e2e-suite handmatig draait - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` om naar een niet-standaard CLI-binary of wrapperscript te wijzen @@ -557,85 +557,86 @@ Zie de suites als “toenemende realiteitsgraad” (en toenemende flakiness/kost - Bestanden: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` en live-tests van gebundelde plugins onder `extensions/` - Standaard: **ingeschakeld** door `pnpm test:live` (zet `OPENCLAW_LIVE_TEST=1`) - Scope: - - “Werkt deze provider/dit model _vandaag_ daadwerkelijk met echte credentials?” - - Vangt providerformatwijzigingen, eigenaardigheden bij tool-calling, auth-problemen en rate-limitgedrag + - “Werkt deze provider/dit model _vandaag_ echt met echte credentials?” + - Vangt providerformatwijzigingen, eigenaardigheden rond tool-calling, auth-problemen en rate-limit-gedrag op - Verwachtingen: - - Niet ontworpen om CI-stabiel te zijn (echte netwerken, echt providerbeleid, quota, storingen) + - Niet CI-stabiel by design (echte netwerken, echte providerpolicies, quota, storingen) - Kost geld / gebruikt rate limits - - Draai liever afgebakende subsets in plaats van “alles” -- Live-runs sourcen `~/.profile` om ontbrekende API-sleutels op te halen. -- Standaard isoleren live-runs nog steeds `HOME` en kopiëren ze config-/auth-materiaal naar een tijdelijke test-home, zodat unit-fixtures je echte `~/.openclaw` niet kunnen muteren. + - Draai bij voorkeur vernauwde subsets in plaats van “alles” +- Live-runs sourcen `~/.profile` om ontbrekende API-sleutels op te pikken. +- Standaard isoleren live-runs nog steeds `HOME` en kopiëren config-/authmateriaal naar een tijdelijke test-home, zodat unit-fixtures je echte `~/.openclaw` niet kunnen wijzigen. - Stel `OPENCLAW_LIVE_USE_REAL_HOME=1` alleen in wanneer je bewust wilt dat live-tests je echte home-directory gebruiken. -- `pnpm test:live` gebruikt nu standaard een stillere modus: het behoudt `[live] ...`-voortgangsoutput, maar onderdrukt de extra `~/.profile`-melding en dempt Gateway-bootstraplogs/Bonjour-geklets. Stel `OPENCLAW_LIVE_TEST_QUIET=0` in als je de volledige opstartlogs terug wilt. -- API-sleutelrotatie (providerspecifiek): stel `*_API_KEYS` in met komma-/puntkomma-indeling of `*_API_KEY_1`, `*_API_KEY_2` (bijvoorbeeld `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) of per-live override via `OPENCLAW_LIVE_*_KEY`; tests proberen opnieuw bij rate-limit-responses. -- Voortgangs-/Heartbeat-output: +- `pnpm test:live` gebruikt nu standaard een stillere modus: het behoudt `[live] ...`-voortgangsuitvoer, maar onderdrukt de extra `~/.profile`-melding en dempt gateway-bootstraplogs/Bonjour-ruis. Stel `OPENCLAW_LIVE_TEST_QUIET=0` in als je de volledige opstartlogs terug wilt. +- API-sleutelrotatie (providerspecifiek): stel `*_API_KEYS` in met komma-/puntkommaformaat of `*_API_KEY_1`, `*_API_KEY_2` (bijvoorbeeld `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) of per-live override via `OPENCLAW_LIVE_*_KEY`; tests proberen opnieuw bij rate-limit-responses. +- Voortgangs-/Heartbeat-uitvoer: - Live-suites sturen nu voortgangsregels naar stderr, zodat lange providercalls zichtbaar actief zijn, zelfs wanneer Vitest-consolecapture stil is. - - `vitest.live.config.ts` schakelt Vitest-console-interceptie uit, zodat provider-/Gateway-voortgangsregels onmiddellijk streamen tijdens live-runs. - - Stem direct-model-Heartbeats af met `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Stem Gateway-/probe-Heartbeats af met `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. + - `vitest.live.config.ts` schakelt Vitest-console-interceptie uit, zodat provider-/gatewayvoortgangsregels direct streamen tijdens live-runs. + - Stel Heartbeats voor directe modellen af met `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Stel Gateway-/probe-Heartbeats af met `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. ## Welke suite moet ik draaien? Gebruik deze beslissingstabel: -- Logica/tests bewerken: voer `pnpm test` uit (en `pnpm test:coverage` als je veel hebt gewijzigd) -- Gateway-netwerken / WS-protocol / koppelen aanraken: voeg `pnpm test:e2e` toe -- “my bot is down” debuggen / provider-specifieke fouten / toolaanroepen: voer een ingeperkte `pnpm test:live` uit +- Bewerkingslogica/tests: voer `pnpm test` uit (en `pnpm test:coverage` als je veel hebt gewijzigd) +- Raak je Gateway-netwerken / WS-protocol / koppelen aan: voeg `pnpm test:e2e` toe +- Debuggen van “mijn bot ligt eruit” / provider-specifieke fouten / toolaanroepen: voer een versmalde `pnpm test:live` uit -## Live-tests (met netwerktoegang) +## Live (netwerkgebruikende) tests -Voor de live modelmatrix, CLI-backend-smoketests, ACP-smoketests, de Codex app-server +Voor de livemodelmatrix, CLI-backend-smokes, ACP-smokes, Codex-app-server harness en alle live tests voor mediaproviders (Deepgram, BytePlus, ComfyUI, image, -music, video, media harness) — plus credentialafhandeling voor live runs — zie -[Testen — live-suites](/nl/help/testing-live). +music, video, media harness) — plus credentialverwerking voor live-runs — zie +[Testing — live suites](/nl/help/testing-live). -## Docker-runners (optionele controles voor "werkt in Linux") +## Docker-runners (optionele "werkt in Linux"-checks) -Deze Docker-runners zijn verdeeld in twee groepen: +Deze Docker-runners zijn opgesplitst in twee groepen: -- Live-model-runners: `test:docker:live-models` en `test:docker:live-gateway` voeren alleen hun overeenkomende live bestand met profielsleutel uit binnen de Docker-image van de repo (`src/agents/models.profiles.live.test.ts` en `src/gateway/gateway-models.profiles.live.test.ts`), waarbij je lokale configuratiemap en werkruimte worden gemount (en `~/.profile` wordt gesourced als die is gemount). De overeenkomende lokale entrypoints zijn `test:live:models-profiles` en `test:live:gateway-profiles`. -- Docker-live-runners gebruiken standaard een kleinere smokelimiet zodat een volledige Docker-sweep praktisch blijft: +- Livemodel-runners: `test:docker:live-models` en `test:docker:live-gateway` voeren alleen hun overeenkomende livebestand met profielsleutel uit binnen de repo-Dockerimage (`src/agents/models.profiles.live.test.ts` en `src/gateway/gateway-models.profiles.live.test.ts`), waarbij je lokale configuratiemap en werkruimte worden gemount (en `~/.profile` wordt gesourcet als die is gemount). De overeenkomende lokale entrypoints zijn `test:live:models-profiles` en `test:live:gateway-profiles`. +- Docker-live-runners gebruiken standaard een kleinere smoke-limiet zodat een volledige Docker-sweep praktisch blijft: `test:docker:live-models` gebruikt standaard `OPENCLAW_LIVE_MAX_MODELS=12`, en `test:docker:live-gateway` gebruikt standaard `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`, `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000` en `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Overschrijf die env-vars wanneer je expliciet de grotere uitputtende scan wilt. -- `test:docker:all` bouwt de live Docker-image eenmalig via `test:docker:live-build`, verpakt OpenClaw eenmalig als npm-tarball via `scripts/package-openclaw-for-docker.mjs`, en bouwt/hergebruikt daarna twee `scripts/e2e/Dockerfile`-images. De kale image is alleen de Node/Git-runner voor install/update/plugin-dependency-lanes; die lanes mounten de vooraf gebouwde tarball. De functionele image installeert dezelfde tarball in `/app` voor lanes met functionaliteit van de gebouwde app. 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. De aggregaatrunner gebruikt een gewogen lokale scheduler: `OPENCLAW_DOCKER_ALL_PARALLELISM` bepaalt processlots, terwijl resourcecaps voorkomen dat zware live-, npm-install- en multi-service-lanes allemaal tegelijk starten. Als een enkele lane zwaarder is dan de actieve caps, kan de scheduler die nog steeds starten wanneer de pool leeg is en die daarna alleen laten draaien totdat er weer capaciteit beschikbaar is. Standaarden zijn 10 slots, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` en `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; pas `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` of `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` alleen aan wanneer de Docker-host meer speelruimte heeft. De runner voert standaard een Docker-preflight uit, verwijdert verouderde OpenClaw E2E-containers, drukt elke 30 seconden status af, slaat timings van succesvolle lanes op in `.artifacts/docker-tests/lane-timings.json` en gebruikt die timings om langere lanes bij latere runs eerst te starten. Gebruik `OPENCLAW_DOCKER_ALL_DRY_RUN=1` om het gewogen lanemanifest af te drukken zonder Docker te bouwen of uit te voeren, of `node scripts/test-docker-all.mjs --plan-json` om het CI-plan af te drukken voor geselecteerde lanes, package-/imagebehoeften en credentials. -- `Package Acceptance` is de GitHub-native package-gate voor "werkt deze installeerbare tarball als product?" Deze resolveert een kandidaatpackage uit `source=npm`, `source=ref`, `source=url` of `source=artifact`, uploadt deze als `package-under-test` en voert daarna de herbruikbare Docker E2E-lanes uit tegen exact die tarball in plaats van de geselecteerde ref opnieuw te verpakken. `workflow_ref` selecteert de vertrouwde workflow-/harness-scripts, terwijl `package_ref` de source-commit/branch/tag selecteert die moet worden verpakt wanneer `source=ref`; hierdoor kan huidige acceptatielogica oudere vertrouwde commits valideren. Profielen zijn geordend op breedte: `smoke` is snelle installatie/channel/agent plus Gateway/config, `package` is het package/update/plugin-contract en de standaard native vervanging voor de meeste Parallels-package/update-dekking, `product` voegt MCP-channels, Cron/subagent-opschoning, OpenAI-webzoekfunctie en OpenWebUI toe, en `full` voert de Docker-chunks van het releasepad uit met OpenWebUI. Releasevalidatie voert een aangepaste packagedelta (`bundled-channel-deps-compat plugins-offline`) plus Telegram-package-QA uit, omdat de Docker-chunks van het releasepad de overlappende package/update/plugin-lanes al dekken. Gerichte GitHub-Docker-heruitvoercommando's die uit artifacts worden gegenereerd bevatten eerdere package-artifact- en voorbereide image-inputs wanneer beschikbaar, zodat mislukte lanes kunnen vermijden dat het package en de images opnieuw worden gebouwd. -- Build- en releasecontroles voeren `scripts/check-cli-bootstrap-imports.mjs` uit na tsdown. De guard doorloopt de statische gebouwde graph vanaf `dist/entry.js` en `dist/cli/run-main.js` en faalt als pre-dispatch startup packagedependencies zoals Commander, prompt-UI, undici of logging importeert vóór commandodispatch; hij houdt ook de gebundelde Gateway-run-chunk binnen budget en weigert statische imports van bekende koude Gateway-paden. Packaged CLI-smoke dekt ook root-help, onboard-help, doctor-help, status, config schema en een model-list-commando. -- Legacy compatibiliteit van Package Acceptance is begrensd op `2026.4.25` (`2026.4.25-beta.*` inbegrepen). Tot en met die cutoff tolereert de harness alleen metadatahiaten van geleverde packages: weggelaten private QA-inventarisitems, ontbrekende `gateway install --wrapper`, ontbrekende patchbestanden in de uit tarball afgeleide git-fixture, ontbrekende gepersisteerde `update.channel`, legacy plugin-install-record-locaties, ontbrekende marketplace-install-record-persistentie en configmetadatamigratie tijdens `plugins update`. Voor packages na `2026.4.25` zijn die paden strikte fouten. -- Container-smoke-runners: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `test:docker:session-runtime-context`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:browser-cdp-snapshot`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` en `test:docker:config-reload` starten een of meer echte containers op en verifiëren integratiepaden op hoger niveau. +- `test:docker:all` bouwt de live-Dockerimage één keer via `test:docker:live-build`, verpakt OpenClaw één keer als npm-tarball via `scripts/package-openclaw-for-docker.mjs`, en bouwt/hergebruikt daarna twee `scripts/e2e/Dockerfile`-images. De kale image is alleen de Node/Git-runner voor install/update/plugin-dependency-lanes; die lanes mounten de vooraf gebouwde tarball. De functionele image installeert dezelfde tarball in `/app` voor lanes met gebouwde-app-functionaliteit. 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. Het aggregaat gebruikt een gewogen lokale scheduler: `OPENCLAW_DOCKER_ALL_PARALLELISM` beheert processlots, terwijl resourcecaps voorkomen dat zware live-, npm-install- en multiservice-lanes allemaal tegelijk starten. Als één lane zwaarder is dan de actieve caps, kan de scheduler die nog steeds starten wanneer de pool leeg is en houdt die lane daarna alleen draaiend totdat er weer capaciteit beschikbaar is. Standaarden zijn 10 slots, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` en `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; pas `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` of `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` alleen aan wanneer de Docker-host meer ruimte heeft. De runner voert standaard een Docker-preflight uit, verwijdert verouderde OpenClaw E2E-containers, print elke 30 seconden status, bewaart succesvolle lanetimings in `.artifacts/docker-tests/lane-timings.json` en gebruikt die timings om bij latere runs langere lanes eerst te starten. Gebruik `OPENCLAW_DOCKER_ALL_DRY_RUN=1` om het gewogen lanemanifest te printen zonder Docker te bouwen of uit te voeren, of `node scripts/test-docker-all.mjs --plan-json` om het CI-plan te printen voor geselecteerde lanes, package-/imagevereisten en credentials. +- `Package Acceptance` is de GitHub-native package-gate voor "werkt deze installeerbare tarball als product?" Het bepaalt één kandidaatpackage uit `source=npm`, `source=ref`, `source=url` of `source=artifact`, uploadt die als `package-under-test`, en voert daarna de herbruikbare Docker E2E-lanes uit tegen exact die tarball in plaats van de geselecteerde ref opnieuw te verpakken. `workflow_ref` selecteert de vertrouwde workflow-/harnessscripts, terwijl `package_ref` de sourcecommit/-branch/-tag selecteert om te verpakken wanneer `source=ref`; hierdoor kan huidige acceptatielogica oudere vertrouwde commits valideren. Profielen zijn geordend op breedte: `smoke` is een snelle installatie/channel/agent plus Gateway/config, `package` is het package-/update-/Plugin-contract plus de keyless upgrade-survivor-fixture en de standaard native vervanger voor de meeste Parallels-package-/updatedekking, `product` voegt MCP-channels, Cron-/subagent-opruiming, OpenAI-webzoekopdrachten en OpenWebUI toe, en `full` voert de releasepad-Dockerchunks met OpenWebUI uit. Releasevalidatie voert een aangepaste packagedelta uit (`bundled-channel-deps-compat plugins-offline`) plus Telegram-package-QA omdat de releasepad-Dockerchunks de overlappende package-/update-/Plugin-lanes al dekken. Gerichte GitHub-Docker-reruncommando's die uit artifacts worden gegenereerd, bevatten eerdere package-artifacts en voorbereide image-inputs wanneer beschikbaar, zodat gefaalde lanes kunnen voorkomen dat package en images opnieuw worden gebouwd. +- Build- en releasechecks voeren `scripts/check-cli-bootstrap-imports.mjs` uit na tsdown. De guard doorloopt de statische gebouwde graph vanaf `dist/entry.js` en `dist/cli/run-main.js` en faalt als startupimports vóór dispatch packagedependencies importeren, zoals Commander, prompt-UI, undici of logging; die houdt ook de gebundelde Gateway-runchunk binnen budget en weigert statische imports van bekende koude Gateway-paden. De packaged CLI-smoke dekt ook roothelp, onboardhelp, doctorhelp, status, configschema en een model-list-commando. +- Legacycompatibiliteit voor Package Acceptance is begrensd op `2026.4.25` (`2026.4.25-beta.*` inbegrepen). Tot en met die grens tolereert de harness alleen metadatagaten in verzonden packages: weggelaten private QA-inventory-items, ontbrekende `gateway install --wrapper`, ontbrekende patchbestanden in de uit de tarball afgeleide git-fixture, ontbrekende gepersisteerde `update.channel`, legacy Plugin-install-record-locaties, ontbrekende persistentie van marketplace-install-records en configmetadatamigratie tijdens `plugins update`. Voor packages na `2026.4.25` zijn die paden strikte fouten. +- Container-smoke-runners: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `test:docker:upgrade-survivor`, `test:docker:session-runtime-context`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:browser-cdp-snapshot`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` en `test:docker:config-reload` starten één of meer echte containers en verifiëren integratiepaden op hoger niveau. -De live-model-Docker-runners bind-mounten ook alleen de benodigde CLI-auth-homes (of alle ondersteunde wanneer de run niet is ingeperkt), en kopiëren die daarna naar de container-home vóór de run zodat external-CLI-OAuth tokens kan vernieuwen zonder de auth-store van de host te muteren: +De livemodel-Docker-runners bind-mounten ook alleen de benodigde CLI-auth-homes (of alle ondersteunde wanneer de run niet is versmald), en kopiëren die daarna naar de container-home vóór de run, zodat externe-CLI-OAuth tokens kan vernieuwen zonder de auth-store van de host te muteren: - Directe modellen: `pnpm test:docker:live-models` (script: `scripts/test-live-models-docker.sh`) - ACP-bind-smoketest: `pnpm test:docker:live-acp-bind` (script: `scripts/test-live-acp-bind-docker.sh`; dekt standaard Claude, Codex en Gemini, met strikte Droid/OpenCode-dekking via `pnpm test:docker:live-acp-bind:droid` en `pnpm test:docker:live-acp-bind:opencode`) - CLI-backend-smoketest: `pnpm test:docker:live-cli-backend` (script: `scripts/test-live-cli-backend-docker.sh`) -- Smoketest voor het Codex app-server-testharnas: `pnpm test:docker:live-codex-harness` (script: `scripts/test-live-codex-harness-docker.sh`) -- Gateway + ontwikkelagent: `pnpm test:docker:live-gateway` (script: `scripts/test-live-gateway-models-docker.sh`) -- Observability-smoketest: `pnpm qa:otel:smoke` is een private QA-source-checkout-lane. Deze maakt bewust geen deel uit van Docker-release-lanes voor pakketten omdat de npm-tarball QA Lab weglaat. -- Open WebUI live-smoketest: `pnpm test:docker:openwebui` (script: `scripts/e2e/openwebui-docker.sh`) +- Codex app-server-harness-smoketest: `pnpm test:docker:live-codex-harness` (script: `scripts/test-live-codex-harness-docker.sh`) +- Gateway + dev-agent: `pnpm test:docker:live-gateway` (script: `scripts/test-live-gateway-models-docker.sh`) +- Observability-smoketest: `pnpm qa:otel:smoke` is een private QA-lane voor source-checkouts. Deze maakt bewust geen deel uit van Docker-release-lanes voor pakketten, omdat de npm-tarball QA Lab weglaat. +- Open WebUI-live-smoketest: `pnpm test:docker:openwebui` (script: `scripts/e2e/openwebui-docker.sh`) - Onboardingwizard (TTY, volledige scaffolding): `pnpm test:docker:onboard` (script: `scripts/e2e/onboard-docker.sh`) -- Npm-tarball-smoketest voor onboarding/kanaal/agent: `pnpm test:docker:npm-onboard-channel-agent` installeert de ingepakte OpenClaw-tarball globaal in Docker, configureert OpenAI via env-ref-onboarding plus standaard Telegram, verifieert dat doctor geactiveerde runtime-afhankelijkheden van plugins heeft gerepareerd, en voert één gemockte OpenAI-agentbeurt uit. Hergebruik een vooraf gebouwde tarball met `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, sla de host-rebuild over met `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0`, of wissel van kanaal met `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. -- Smoketest voor wisselen van updatekanaal: `pnpm test:docker:update-channel-switch` installeert de ingepakte OpenClaw-tarball globaal in Docker, wisselt van pakket `stable` naar git `dev`, verifieert het opgeslagen kanaal en de werking van plugins na de update, wisselt daarna terug naar pakket `stable` en controleert de updatestatus. -- Smoketest voor sessie-runtimecontext: `pnpm test:docker:session-runtime-context` verifieert persistente transcriptopslag van verborgen runtimecontext plus doctor-reparatie van getroffen gedupliceerde prompt-herschrijftakken. -- Bun-smoketest voor globale installatie: `bash scripts/e2e/bun-global-install-smoke.sh` pakt de huidige tree in, installeert deze met `bun install -g` in een geïsoleerde home, en verifieert dat `openclaw infer image providers --json` gebundelde imageproviders retourneert in plaats van te blijven hangen. Hergebruik een vooraf gebouwde tarball met `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, sla de host-build over met `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0`, of kopieer `dist/` uit een gebouwde Docker-image met `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. -- Docker-smoketest voor installer: `bash scripts/test-install-sh-docker.sh` deelt één npm-cache over de root-, update- en direct-npm-containers. De update-smoketest gebruikt standaard npm `latest` als stabiele baseline voordat wordt geüpgraded naar de kandidaat-tarball. Overschrijf dit lokaal met `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22`, of op GitHub met de `update_baseline_version`-invoer van de Install Smoke-workflow. Niet-root installercontroles houden een geïsoleerde npm-cache aan, zodat cachevermeldingen van root geen lokaal installatiegedrag van de gebruiker verhullen. Stel `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache` in om de root/update/direct-npm-cache bij lokale herhalingen te hergebruiken. -- Install Smoke CI slaat de gedupliceerde directe npm-globale update over met `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; voer het script lokaal zonder die env uit wanneer dekking voor directe `npm install -g` nodig is. -- Smoketest voor agents die gedeelde werkruimte verwijderen via CLI: `pnpm test:docker:agents-delete-shared-workspace` (script: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) bouwt standaard de root-Dockerfile-image, seedt twee agents met één werkruimte in een geïsoleerde container-home, voert `agents delete --json` uit, en verifieert geldige JSON plus behoud van werkruimtegedrag. Hergebruik de install-smoke-image met `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. +- Npm-tarball-smoketest voor onboarding/kanaal/agent: `pnpm test:docker:npm-onboard-channel-agent` installeert de ingepakte OpenClaw-tarball globaal in Docker, configureert OpenAI via onboarding met env-verwijzing plus standaard Telegram, verifieert dat doctor geactiveerde plugin-runtime-deps heeft gerepareerd en voert een gemockte OpenAI-agentbeurt uit. Hergebruik een vooraf gebouwde tarball met `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, sla de host-rebuild over met `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0`, of wissel van kanaal met `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. +- Update-kanaalwissel-smoketest: `pnpm test:docker:update-channel-switch` installeert de ingepakte OpenClaw-tarball globaal in Docker, wisselt van package `stable` naar git `dev`, verifieert het bewaarde kanaal en de werking van plugins na de update, wisselt daarna terug naar package `stable` en controleert de updatestatus. +- Upgrade-survivor-smoketest: `pnpm test:docker:upgrade-survivor` installeert de ingepakte OpenClaw-tarball over een vervuilde fixture van een oude gebruiker met agents, kanaalconfiguratie, plugin-allowlists, verouderde plugin-runtime-deps-status en bestaande workspace-/sessiebestanden. Deze voert een package-update plus niet-interactieve doctor uit zonder live provider- of kanaalsleutels, start daarna een loopback-Gateway en controleert behoud van configuratie/status plus startup-/statusbudgetten. +- Smoketest voor runtimecontext van sessies: `pnpm test:docker:session-runtime-context` verifieert persistentie van verborgen runtimecontext-transcripten plus doctor-reparatie van getroffen gedupliceerde prompt-rewrite-branches. +- Smoketest voor globale Bun-installatie: `bash scripts/e2e/bun-global-install-smoke.sh` pakt de huidige tree in, installeert deze met `bun install -g` in een geïsoleerde home en verifieert dat `openclaw infer image providers --json` gebundelde imageproviders retourneert in plaats van te blijven hangen. Hergebruik een vooraf gebouwde tarball met `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, sla de host-build over met `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0`, of kopieer `dist/` uit een gebouwde Docker-image met `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. +- Installer-Docker-smoketest: `bash scripts/test-install-sh-docker.sh` deelt een npm-cache tussen de root-, update- en direct-npm-containers. De update-smoketest gebruikt standaard npm `latest` als stabiele baseline voordat naar de kandidaat-tarball wordt geüpgraded. Overschrijf dit lokaal met `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22`, of met de `update_baseline_version`-input van de Install Smoke-workflow op GitHub. Niet-root-installatiecontroles houden een geïsoleerde npm-cache aan, zodat root-owned cache-items het gebruikerslokale installatiegedrag niet maskeren. Stel `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache` in om de root-/update-/direct-npm-cache bij lokale herhalingen te hergebruiken. +- Install Smoke CI slaat de dubbele directe globale npm-update over met `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; voer het script lokaal zonder die env uit wanneer directe `npm install -g`-dekking nodig is. +- CLI-smoketest voor agents die gedeelde workspace verwijderen: `pnpm test:docker:agents-delete-shared-workspace` (script: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) bouwt standaard de root-Dockerfile-image, seedt twee agents met één workspace in een geïsoleerde container-home, voert `agents delete --json` uit en verifieert geldige JSON plus behoud van workspace-gedrag. Hergebruik de install-smoke-image met `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. - Gateway-netwerken (twee containers, WS-auth + health): `pnpm test:docker:gateway-network` (script: `scripts/e2e/gateway-network-docker.sh`) -- Browser-CDP-snapshot-smoketest: `pnpm test:docker:browser-cdp-snapshot` (script: `scripts/e2e/browser-cdp-snapshot-docker.sh`) bouwt de source-E2E-image plus een Chromium-laag, start Chromium met ruwe CDP, voert `browser doctor --deep` uit, en verifieert dat CDP-rolsnapshots link-URL's, cursor-gepromoveerde klikbare elementen, iframe-referenties en framemetadata dekken. -- Regressie voor minimale reasoning van OpenAI Responses `web_search`: `pnpm test:docker:openai-web-search-minimal` (script: `scripts/e2e/openai-web-search-minimal-docker.sh`) voert een gemockte OpenAI-server uit via Gateway, verifieert dat `web_search` `reasoning.effort` verhoogt van `minimal` naar `low`, forceert daarna de provider-schema-afwijzing en controleert dat de ruwe details in Gateway-logboeken verschijnen. -- MCP-kanaalbrug (geseed Gateway + stdio-brug + ruwe smoketest voor Claude-notificatieframes): `pnpm test:docker:mcp-channels` (script: `scripts/e2e/mcp-channels-docker.sh`) -- Pi-bundel-MCP-tools (echte stdio-MCP-server + ingesloten Pi-profiel-smoketest voor toestaan/weigeren): `pnpm test:docker:pi-bundle-mcp-tools` (script: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) -- Cron/subagent-MCP-opruiming (echte Gateway + teardown van stdio-MCP-child na geïsoleerde cron- en eenmalige subagent-runs): `pnpm test:docker:cron-mcp-cleanup` (script: `scripts/e2e/cron-mcp-cleanup-docker.sh`) -- Plugins (installatiesmoketest, ClawHub kitchen-sink-installatie/de-installatie, marketplace-updates, en Claude-bundel inschakelen/inspecteren): `pnpm test:docker:plugins` (script: `scripts/e2e/plugins-docker.sh`) - Stel `OPENCLAW_PLUGINS_E2E_CLAWHUB=0` in om het ClawHub-blok over te slaan, of overschrijf het standaard kitchen-sink-pakket/runtime-paar met `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` en `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Zonder `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` gebruikt de test een hermetische lokale ClawHub-fixtureserver. +- Browser-CDP-snapshot-smoketest: `pnpm test:docker:browser-cdp-snapshot` (script: `scripts/e2e/browser-cdp-snapshot-docker.sh`) bouwt de bron-E2E-image plus een Chromium-laag, start Chromium met raw CDP, voert `browser doctor --deep` uit en verifieert dat CDP-rolsnapshots link-URL's, cursor-gepromote klikbare elementen, iframe-referenties en framemetadata dekken. +- Regressie voor minimale reasoning met OpenAI Responses web_search: `pnpm test:docker:openai-web-search-minimal` (script: `scripts/e2e/openai-web-search-minimal-docker.sh`) voert een gemockte OpenAI-server via Gateway uit, verifieert dat `web_search` `reasoning.effort` verhoogt van `minimal` naar `low`, forceert daarna een afwijzing door het providerschema en controleert dat de raw details in Gateway-logs verschijnen. +- MCP-kanaalbridge (geseede Gateway + stdio-bridge + raw Claude-notification-frame-smoketest): `pnpm test:docker:mcp-channels` (script: `scripts/e2e/mcp-channels-docker.sh`) +- Pi-bundel-MCP-tools (echte stdio-MCP-server + embedded Pi-profiel-allow/deny-smoketest): `pnpm test:docker:pi-bundle-mcp-tools` (script: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) +- Cron-/subagent-MCP-cleanup (echte Gateway + stdio-MCP-child-teardown na geïsoleerde cron- en eenmalige subagent-runs): `pnpm test:docker:cron-mcp-cleanup` (script: `scripts/e2e/cron-mcp-cleanup-docker.sh`) +- Plugins (installatiesmoketest, ClawHub kitchen-sink-installatie/-de-installatie, marketplace-updates en Claude-bundle inschakelen/inspecteren): `pnpm test:docker:plugins` (script: `scripts/e2e/plugins-docker.sh`) + Stel `OPENCLAW_PLUGINS_E2E_CLAWHUB=0` in om het ClawHub-blok over te slaan, of overschrijf het standaard kitchen-sink-package/runtime-paar met `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` en `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Zonder `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` gebruikt de test een hermetische lokale ClawHub-fixture-server. - Smoketest voor ongewijzigde plugin-update: `pnpm test:docker:plugin-update` (script: `scripts/e2e/plugin-update-unchanged-docker.sh`) -- Smoketest voor metadata bij config-herladen: `pnpm test:docker:config-reload` (script: `scripts/e2e/config-reload-source-docker.sh`) -- Runtime-afhankelijkheden van gebundelde plugins: `pnpm test:docker:bundled-channel-deps` bouwt standaard een kleine Docker-runner-image, bouwt en pakt OpenClaw één keer in op de host, en mount die tarball daarna in elk Linux-installatiescenario. Hergebruik de image met `OPENCLAW_SKIP_DOCKER_BUILD=1`, sla de host-rebuild over na een verse lokale build met `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0`, of verwijs naar een bestaande tarball met `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. De volledige Docker-aggregate en bundled-channel-chunks van het releasepad pakken deze tarball één keer vooraf in, en sharden daarna gebundelde kanaalcontroles naar onafhankelijke lanes, inclusief aparte update-lanes voor Telegram, Discord, Slack, Feishu, memory-lancedb en ACPX. Releasechunks splitsen kanaalsmoketests, updatedoelen en setup/runtime-contracten op in `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` en `bundled-channels-contracts`; de aggregate chunk `bundled-channels` blijft beschikbaar voor handmatige herhalingen. De releaseworkflow splitst ook provider-installerchunks en installatie-/de-installatiechunks voor gebundelde plugins; legacy chunks `package-update`, `plugins-runtime` en `plugins-integrations` blijven aggregate aliassen voor handmatige herhalingen. Gebruik `OPENCLAW_BUNDLED_CHANNELS=telegram,slack` om de kanaalmatrix te versmallen wanneer de gebundelde lane direct wordt uitgevoerd, of `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx` om het updatescenario te versmallen. Docker-runs per scenario gebruiken standaard `OPENCLAW_BUNDLED_CHANNEL_DOCKER_RUN_TIMEOUT=900s`; het updatescenario met meerdere doelen gebruikt standaard `OPENCLAW_BUNDLED_CHANNEL_UPDATE_DOCKER_RUN_TIMEOUT=2400s`. De lane verifieert ook dat `channels..enabled=false` en `plugins.entries..enabled=false` doctor-/runtime-afhankelijkheidsreparatie onderdrukken. -- Versmal runtime-afhankelijkheden van gebundelde plugins tijdens iteratie door niet-gerelateerde scenario's uit te schakelen, bijvoorbeeld: +- Config-reload-metadata-smoketest: `pnpm test:docker:config-reload` (script: `scripts/e2e/config-reload-source-docker.sh`) +- Runtime-deps van gebundelde plugins: `pnpm test:docker:bundled-channel-deps` bouwt standaard een kleine Docker-runner-image, bouwt en pakt OpenClaw één keer op de host in, en mount die tarball vervolgens in elk Linux-installatiescenario. Hergebruik de image met `OPENCLAW_SKIP_DOCKER_BUILD=1`, sla de host-rebuild na een verse lokale build over met `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0`, of wijs naar een bestaande tarball met `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. De volledige Docker-aggregate en release-path bundled-channel-chunks pakken deze tarball één keer vooraf in en sharden daarna controles van gebundelde kanalen in onafhankelijke lanes, inclusief afzonderlijke update-lanes voor Telegram, Discord, Slack, Feishu, memory-lancedb en ACPX. Release-chunks splitsen kanaal-smoketests, update-targets en setup-/runtimecontracten in `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` en `bundled-channels-contracts`; de aggregate `bundled-channels`-chunk blijft beschikbaar voor handmatige herhalingen. De release-workflow splitst ook provider-installer-chunks en gebundelde plugin-installatie-/de-installatiechunks; legacy `package-update`-, `plugins-runtime`- en `plugins-integrations`-chunks blijven aggregate-aliassen voor handmatige herhalingen. Gebruik `OPENCLAW_BUNDLED_CHANNELS=telegram,slack` om de kanaalmatrix te beperken wanneer de gebundelde lane direct wordt uitgevoerd, of `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx` om het updatescenario te beperken. Docker-runs per scenario gebruiken standaard `OPENCLAW_BUNDLED_CHANNEL_DOCKER_RUN_TIMEOUT=900s`; het multi-target-updatescenario gebruikt standaard `OPENCLAW_BUNDLED_CHANNEL_UPDATE_DOCKER_RUN_TIMEOUT=2400s`. De lane verifieert ook dat `channels..enabled=false` en `plugins.entries..enabled=false` doctor-/runtime-dependency-reparatie onderdrukken. +- Beperk runtime-deps van gebundelde plugins tijdens iteratie door niet-gerelateerde scenario's uit te schakelen, bijvoorbeeld: `OPENCLAW_BUNDLED_CHANNEL_SCENARIOS=0 OPENCLAW_BUNDLED_CHANNEL_UPDATE_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_ROOT_OWNED_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_SETUP_ENTRY_SCENARIO=0 pnpm test:docker:bundled-channel-deps`. Om de gedeelde functionele image handmatig vooraf te bouwen en te hergebruiken: @@ -645,155 +646,157 @@ OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local pnpm test:docker: OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels ``` -Suite-specifieke image-overschrijvingen zoals `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE` winnen nog steeds wanneer ze zijn ingesteld. Wanneer `OPENCLAW_SKIP_DOCKER_BUILD=1` naar een externe gedeelde image verwijst, trekken de scripts deze binnen als deze nog niet lokaal aanwezig is. De QR- en installer-Docker-tests houden hun eigen Dockerfiles omdat ze pakket-/installatiegedrag valideren in plaats van de gedeelde runtime van de gebouwde app. +Suitespecifieke image-overschrijvingen zoals `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE` blijven voorrang hebben wanneer ze zijn ingesteld. Wanneer `OPENCLAW_SKIP_DOCKER_BUILD=1` naar een remote gedeelde image wijst, trekken de scripts deze op als hij nog niet lokaal aanwezig is. De QR- en installer-Docker-tests behouden hun eigen Dockerfiles omdat ze package-/installatiegedrag valideren in plaats van de gedeelde gebouwde-app-runtime. -De Docker-runners voor live modellen binden ook de huidige checkout read-only en -stagen deze in een tijdelijke werkdir binnen de container. Dit houdt de runtime- -image slank terwijl Vitest nog steeds tegen je exacte lokale source/config wordt -uitgevoerd. De stagingstap slaat grote lokale-only caches en app-buildoutputs over, -zoals `.pnpm-store`, `.worktrees`, `__openclaw_vitest__` en app-lokale `.build`- -of Gradle-outputdirectories, zodat Docker-live-runs geen minuten besteden aan het -kopiëren van machinespecifieke artefacten. -Ze stellen ook `OPENCLAW_SKIP_CHANNELS=1` in, zodat Gateway-liveprobes geen echte -Telegram/Discord/etc.-kanaalworkers binnen de container starten. -`test:docker:live-models` voert nog steeds `pnpm test:live` uit, dus geef ook -`OPENCLAW_LIVE_GATEWAY_*` door wanneer je Gateway-live-dekking vanuit die -Docker-lane moet versmallen of uitsluiten. -`test:docker:openwebui` is een compatibiliteitssmoketest op hoger niveau: deze start -een OpenClaw Gateway-container met de OpenAI-compatibele HTTP-endpoints ingeschakeld, -start een gepinde Open WebUI-container tegen die Gateway, meldt zich aan via -Open WebUI, verifieert dat `/api/models` `openclaw/default` aanbiedt, en verzendt -daarna een echt chatverzoek via de `/api/chat/completions`-proxy van Open WebUI. -De eerste run kan merkbaar langzamer zijn omdat Docker mogelijk de Open WebUI-image -moet ophalen en Open WebUI mogelijk zijn eigen cold-start-setup moet afronden. -Deze lane verwacht een bruikbare sleutel voor een live model, en `OPENCLAW_PROFILE_FILE` -(`~/.profile` standaard) is de primaire manier om deze in Docker-runs aan te leveren. +De live-model-Docker-runners koppelen ook de huidige checkout alleen-lezen aan en +plaatsen die in een tijdelijke werkmap binnen de container. Zo blijft de runtime- +image slank terwijl Vitest nog steeds tegen je exacte lokale bron/configuratie draait. +De stagingstap slaat grote lokale caches en app-buildoutputs over, zoals +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` en app-lokale `.build`- of +Gradle-outputmappen, zodat Docker-live-runs geen minuten besteden aan het kopiëren +van machinespecifieke artefacten. +Ze stellen ook `OPENCLAW_SKIP_CHANNELS=1` in, zodat Gateway-liveprobes geen +echte Telegram/Discord/etc.-channel workers binnen de container starten. +`test:docker:live-models` draait nog steeds `pnpm test:live`, dus geef ook +`OPENCLAW_LIVE_GATEWAY_*` door wanneer je Gateway-live-dekking uit die Docker-lane +moet beperken of uitsluiten. +`test:docker:openwebui` is een hogere-orde compatibiliteitssmoke: het start een +OpenClaw Gateway-container met de OpenAI-compatibele HTTP-endpoints ingeschakeld, +start een gepinde Open WebUI-container tegen die Gateway, logt in via +Open WebUI, verifieert dat `/api/models` `openclaw/default` toont, en stuurt dan een +echte chatrequest via Open WebUI's `/api/chat/completions`-proxy. +De eerste run kan merkbaar trager zijn omdat Docker mogelijk de +Open WebUI-image moet ophalen en Open WebUI mogelijk zijn eigen cold-startsetup moet afronden. +Deze lane verwacht een bruikbare live-modelsleutel, en `OPENCLAW_PROFILE_FILE` +(standaard `~/.profile`) is de primaire manier om die in Dockerized runs te leveren. Succesvolle runs printen een kleine JSON-payload zoals `{ "ok": true, "model": "openclaw/default", ... }`. -`test:docker:mcp-channels` is bewust deterministisch en heeft geen echt -Telegram-, Discord- of iMessage-account nodig. Deze start een geseede Gateway- -container, start een tweede container die `openclaw mcp serve` spawnt, en verifieert -daarna routed gesprekdetectie, transcriptlezingen, attachmentmetadata, -live-eventqueuegedrag, routering van uitgaande verzendingen, en kanaal- + -machtigingsnotificaties in Claude-stijl over de echte stdio-MCP-brug. De -notificatiecontrole inspecteert de ruwe stdio-MCP-frames direct, zodat de smoketest -valideert wat de brug daadwerkelijk emitteert, niet alleen wat een specifieke -client-SDK toevallig zichtbaar maakt. -`test:docker:pi-bundle-mcp-tools` is deterministisch en heeft geen live-modelsleutel -nodig. Deze bouwt de repo-Docker-image, start een echte stdio-MCP-probeserver binnen -de container, materialiseert die server via de ingesloten Pi-bundel-MCP-runtime, -voert de tool uit, en verifieert daarna dat `coding` en `messaging` `bundle-mcp`- -tools behouden terwijl `minimal` en `tools.deny: ["bundle-mcp"]` ze filteren. -`test:docker:cron-mcp-cleanup` is deterministisch en heeft geen live-modelsleutel -nodig. Deze start een geseede Gateway met een echte stdio-MCP-probeserver, voert -een geïsoleerde cron-beurt en een eenmalige `/subagents spawn`-childbeurt uit, en -verifieert daarna dat het MCP-childproces na elke run afsluit. +`test:docker:mcp-channels` is opzettelijk deterministisch en heeft geen +echt Telegram-, Discord- of iMessage-account nodig. Het start een seeded Gateway- +container, start een tweede container die `openclaw mcp serve` spawnt, en +verifieert vervolgens gerouteerde gespreksdetectie, transcriptlezingen, attachmentmetadata, +live-eventqueuegedrag, outbound send-routing en Claude-achtige channel- + +permission-notificaties via de echte stdio MCP-bridge. De notificatiecheck +inspecteert de ruwe stdio MCP-frames direct, zodat de smoke valideert wat de +bridge daadwerkelijk emitteert, niet alleen wat een specifieke client-SDK toevallig toont. +`test:docker:pi-bundle-mcp-tools` is deterministisch en heeft geen live- +modelsleutel nodig. Het bouwt de repo-Docker-image, start een echte stdio MCP-probeserver +binnen de container, materialiseert die server via de embedded Pi bundle +MCP-runtime, voert de tool uit en verifieert daarna dat `coding` en `messaging` +`bundle-mcp`-tools behouden terwijl `minimal` en `tools.deny: ["bundle-mcp"]` ze filteren. +`test:docker:cron-mcp-cleanup` is deterministisch en heeft geen live-model- +sleutel nodig. Het start een seeded Gateway met een echte stdio MCP-probeserver, draait een +geïsoleerde cronbeurt en een `/subagents spawn` eenmalige child turn, en verifieert daarna +dat het MCP-childproces na elke run stopt. -Handmatige ACP-smoketest voor thread in gewone taal (geen CI): +Handmatige ACP plain-language thread smoke (geen CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Bewaar dit script voor regressie-/debugworkflows. Het kan opnieuw nodig zijn voor validatie van ACP-threadroutering, dus verwijder het niet. +- Bewaar dit script voor regressie-/debugworkflows. Het kan opnieuw nodig zijn voor ACP-threadroutingvalidatie, dus verwijder het niet. Nuttige env-vars: - `OPENCLAW_CONFIG_DIR=...` (standaard: `~/.openclaw`) gekoppeld aan `/home/node/.openclaw` - `OPENCLAW_WORKSPACE_DIR=...` (standaard: `~/.openclaw/workspace`) gekoppeld aan `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (standaard: `~/.profile`) gekoppeld aan `/home/node/.profile` en ingelezen voordat tests worden uitgevoerd -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` om alleen env-vars te verifiëren die uit `OPENCLAW_PROFILE_FILE` worden ingelezen, met tijdelijke config-/workspace-mappen en zonder externe CLI-auth-koppelingen -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (standaard: `~/.cache/openclaw/docker-cli-tools`) gekoppeld aan `/home/node/.npm-global` voor gecachete CLI-installaties binnen Docker -- Externe CLI-auth-mappen/-bestanden onder `$HOME` worden alleen-lezen gekoppeld onder `/host-auth...` en daarna naar `/home/node/...` gekopieerd voordat tests starten +- `OPENCLAW_PROFILE_FILE=...` (standaard: `~/.profile`) gekoppeld aan `/home/node/.profile` en gesourced voordat tests draaien +- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` om alleen env-vars te verifiëren die uit `OPENCLAW_PROFILE_FILE` zijn gesourced, met tijdelijke config-/workspacemappen en zonder externe CLI-authmounts +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (standaard: `~/.cache/openclaw/docker-cli-tools`) gekoppeld aan `/home/node/.npm-global` voor gecachte CLI-installaties binnen Docker +- Externe CLI-authmappen/-bestanden onder `$HOME` worden alleen-lezen gekoppeld onder `/host-auth...` en daarna naar `/home/node/...` gekopieerd voordat tests starten - Standaardmappen: `.minimax` - Standaardbestanden: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - - Versmalde provider-runs koppelen alleen de benodigde mappen/bestanden die worden afgeleid uit `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - - Overschrijf handmatig met `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` of een kommagescheiden lijst zoals `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` -- `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...` om de run te versmallen -- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` om providers in de container te filteren -- `OPENCLAW_SKIP_DOCKER_BUILD=1` om een bestaande `openclaw:local-live`-image opnieuw te gebruiken voor herhalingen die geen rebuild nodig hebben -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` om te garanderen dat credentials uit de profielopslag komen (niet uit env) -- `OPENCLAW_OPENWEBUI_MODEL=...` om het model te kiezen dat door de Gateway voor de Open WebUI-smoke beschikbaar wordt gesteld -- `OPENCLAW_OPENWEBUI_PROMPT=...` om de nonce-check-prompt te overschrijven die door de Open WebUI-smoke wordt gebruikt -- `OPENWEBUI_IMAGE=...` om de gepinde Open WebUI-image-tag te overschrijven + - Verkleinde providerruns koppelen alleen de benodigde mappen/bestanden die worden afgeleid uit `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` + - Handmatig overschrijven met `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none`, of een kommagescheiden lijst zoals `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` +- `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...` om de run te beperken +- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` om providers binnen de container te filteren +- `OPENCLAW_SKIP_DOCKER_BUILD=1` om een bestaande `openclaw:local-live`-image opnieuw te gebruiken voor reruns die geen rebuild nodig hebben +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` om te garanderen dat creds uit de profile store komen (niet uit env) +- `OPENCLAW_OPENWEBUI_MODEL=...` om het model te kiezen dat door de Gateway voor de Open WebUI-smoke wordt getoond +- `OPENCLAW_OPENWEBUI_PROMPT=...` om de nonce-checkprompt te overschrijven die door de Open WebUI-smoke wordt gebruikt +- `OPENWEBUI_IMAGE=...` om de gepinde Open WebUI-imagetag te overschrijven ## Docs-sanity -Voer docs-controles uit na docs-bewerkingen: `pnpm check:docs`. -Voer volledige Mintlify-ankervalidatie uit wanneer je ook controles van koppen binnen pagina's nodig hebt: `pnpm docs:check-links:anchors`. +Voer docschecks uit na docs-bewerkingen: `pnpm check:docs`. +Voer volledige Mintlify-ankervalidatie uit wanneer je ook headingchecks binnen pagina's nodig hebt: `pnpm docs:check-links:anchors`. ## Offline regressie (CI-veilig) -Dit zijn regressies van de “echte pipeline” zonder echte providers: +Dit zijn regressies van de "echte pipeline" zonder echte providers: -- Gateway-toolaanroepen (mock OpenAI, echte Gateway + agent-loop): `src/gateway/gateway.test.ts` (case: "runs a mock OpenAI tool call end-to-end via gateway agent loop") +- Gateway tool calling (mock OpenAI, echte Gateway + agentloop): `src/gateway/gateway.test.ts` (case: "runs a mock OpenAI tool call end-to-end via gateway agent loop") - Gateway-wizard (WS `wizard.start`/`wizard.next`, schrijft config + auth afgedwongen): `src/gateway/gateway.test.ts` (case: "runs wizard over ws and writes auth token config") -## Betrouwbaarheidsevaluaties voor agenten (Skills) +## Agent-betrouwbaarheidsevals (Skills) -We hebben al enkele CI-veilige tests die zich gedragen als “betrouwbaarheidsevaluaties voor agenten”: +We hebben al een paar CI-veilige tests die zich gedragen als "agent-betrouwbaarheidsevals": -- Mock-toolaanroepen via de echte Gateway + agent-loop (`src/gateway/gateway.test.ts`). -- End-to-end wizardflows die sessiebedrading en config-effecten valideren (`src/gateway/gateway.test.ts`). +- Mock tool-calling via de echte Gateway + agentloop (`src/gateway/gateway.test.ts`). +- End-to-end wizardflows die sessiewiring en configeffecten valideren (`src/gateway/gateway.test.ts`). Wat nog ontbreekt voor Skills (zie [Skills](/nl/tools/skills)): -- **Besluitvorming:** als skills in de prompt worden vermeld, kiest de agent dan de juiste skill (of vermijdt hij irrelevante)? -- **Naleving:** leest de agent `SKILL.md` vóór gebruik en volgt hij vereiste stappen/args? -- **Workflowcontracten:** scenario's met meerdere beurten die toolvolgorde, overdracht van sessiegeschiedenis en sandboxgrenzen bevestigen. +- **Besluitvorming:** wanneer Skills in de prompt worden vermeld, kiest de agent dan de juiste skill (of vermijdt hij irrelevante)? +- **Compliance:** leest de agent `SKILL.md` vóór gebruik en volgt hij de vereiste stappen/args? +- **Workflowcontracten:** multi-turn-scenario's die toolvolgorde, behoud van sessiegeschiedenis en sandboxgrenzen assert-en. -Toekomstige evaluaties moeten eerst deterministisch blijven: +Toekomstige evals moeten eerst deterministisch blijven: -- Een scenariorunner met mockproviders om toolaanroepen + volgorde, skill-bestandslezingen en sessiebedrading te bevestigen. -- Een kleine suite met skillgerichte scenario's (gebruiken vs. vermijden, gating, promptinjectie). -- Optionele live-evaluaties (opt-in, env-gated) pas nadat de CI-veilige suite er is. +- Een scenariorunner met mockproviders om toolcalls + volgorde, skillbestandlezingen en sessiewiring te assert-en. +- Een kleine suite met skillgerichte scenario's (gebruiken versus vermijden, gating, promptinjectie). +- Optionele live-evals (opt-in, env-gated) pas nadat de CI-veilige suite aanwezig is. -## Contracttests (Plugin- en kanaalvorm) +## Contracttests (Plugin- en channelvorm) -Contracttests verifiëren dat elke geregistreerde Plugin en elk geregistreerd kanaal voldoet aan zijn interfacecontract. Ze itereren over alle ontdekte Plugins en voeren een suite met vorm- en gedragsasserties uit. De standaard `pnpm test`-unitlane slaat deze gedeelde seam- en smoke-bestanden bewust over; voer de contractcommando's expliciet uit wanneer je gedeelde kanaal- of provideroppervlakken aanraakt. +Contracttests verifiëren dat elke geregistreerde Plugin en elk geregistreerd channel aan zijn +interfacecontract voldoet. Ze itereren over alle ontdekte plugins en draaien een suite met +shape- en gedragsasserties. De standaard `pnpm test`-unitlane slaat deze gedeelde seam- en smoke-bestanden opzettelijk over; draai de contractcommando's expliciet +wanneer je gedeelde channel- of provideroppervlakken aanraakt. ### Commando's - Alle contracten: `pnpm test:contracts` -- Alleen kanaalcontracten: `pnpm test:contracts:channels` +- Alleen channelcontracten: `pnpm test:contracts:channels` - Alleen providercontracten: `pnpm test:contracts:plugins` -### Kanaalcontracten +### Channelcontracten -Bevinden zich in `src/channels/plugins/contracts/*.contract.test.ts`: +Gelokaliseerd in `src/channels/plugins/contracts/*.contract.test.ts`: -- **plugin** - Basisvorm van de Plugin (id, naam, capabilities) -- **setup** - Setup-wizardcontract -- **session-binding** - Gedrag van sessiebinding -- **outbound-payload** - Structuur van berichtpayload -- **inbound** - Afhandeling van inkomende berichten -- **actions** - Kanaalactiehandlers -- **threading** - Afhandeling van thread-ID's -- **directory** - Directory-/roster-API -- **group-policy** - Handhaving van groepsbeleid +- **plugin** - Basale Plugin-vorm (id, naam, capabilities) +- **setup** - Setupwizardcontract +- **session-binding** - Session-bindinggedrag +- **outbound-payload** - Structuur van messagepayload +- **inbound** - Afhandeling van inbound messages +- **actions** - Channel-actionhandlers +- **threading** - Thread-ID-afhandeling +- **directory** - Directory/roster-API +- **group-policy** - Afdwingen van groepsbeleid ### Providerstatuscontracten -Bevinden zich in `src/plugins/contracts/*.contract.test.ts`. +Gelokaliseerd in `src/plugins/contracts/*.contract.test.ts`. -- **status** - Kanaalstatusprobes -- **registry** - Vorm van Plugin-register +- **status** - Channelstatusprobes +- **registry** - Vorm van Plugin registry ### Providercontracten -Bevinden zich in `src/plugins/contracts/*.contract.test.ts`: +Gelokaliseerd in `src/plugins/contracts/*.contract.test.ts`: -- **auth** - Auth-flowcontract -- **auth-choice** - Auth-keuze/selectie +- **auth** - Authflowcontract +- **auth-choice** - Authkeuze/selectie - **catalog** - Modelcatalogus-API -- **discovery** - Plugin-detectie -- **loader** - Plugin laden -- **runtime** - Provider-runtime -- **shape** - Plugin-vorm/interface -- **wizard** - Setup-wizard +- **discovery** - Plugindiscovery +- **loader** - Pluginladen +- **runtime** - Providerruntime +- **shape** - Pluginvorm/interface +- **wizard** - Setupwizard -### Wanneer uitvoeren +### Wanneer draaien -- Na het wijzigen van plugin-sdk-exports of subpaden -- Na het toevoegen of wijzigen van een kanaal- of provider-Plugin -- Na het refactoren van Plugin-registratie of -detectie +- Na het wijzigen van plugin-sdk-exports of subpaths +- Na het toevoegen of wijzigen van een channel- of provider-Plugin +- Na het refactoren van Plugin-registratie of discovery Contracttests draaien in CI en vereisen geen echte API-sleutels. @@ -801,14 +804,14 @@ Contracttests draaien in CI en vereisen geen echte API-sleutels. Wanneer je een provider-/modelprobleem oplost dat live is ontdekt: -- Voeg indien mogelijk een CI-veilige regressie toe (mock-/stubprovider, of leg de exacte request-shape-transformatie vast) -- Als het inherent alleen live is (rate limits, auth-beleid), houd de live-test smal en opt-in via env-vars -- Richt je bij voorkeur op de kleinste laag die de bug opvangt: - - provider-requestconversie-/replaybug → directe modelltest - - gateway-sessie-/geschiedenis-/toolpipelinebug → gateway-live-smoke of CI-veilige gateway-mocktest -- SecretRef-traversal-guardrail: - - `src/secrets/exec-secret-ref-id-parity.test.ts` leidt één gesampled doel per SecretRef-klasse af uit registermetadata (`listSecretTargetRegistryEntries()`) en bevestigt daarna dat exec-id's met traversal-segmenten worden geweigerd. - - Als je een nieuwe `includeInPlan` SecretRef-doelfamilie toevoegt in `src/secrets/target-registry-data.ts`, werk dan `classifyTargetClass` in die test bij. De test faalt bewust op ongeclassificeerde doel-id's zodat nieuwe klassen niet stilzwijgend kunnen worden overgeslagen. +- Voeg indien mogelijk een CI-veilige regressie toe (mock-/stubprovider, of leg de exacte request-shapetransformatie vast) +- Als het inherent alleen live is (rate limits, authbeleid), houd de live-test smal en opt-in via env-vars +- Richt je bij voorkeur op de kleinste laag die de bug vangt: + - bug in provider-requestconversie/replay → directe modeltest + - bug in Gateway-sessie/geschiedenis/toolpipeline → Gateway-live-smoke of CI-veilige Gateway-mocktest +- SecretRef-traversalguardrail: + - `src/secrets/exec-secret-ref-id-parity.test.ts` leidt één gesampled target per SecretRef-class af uit registrymetadata (`listSecretTargetRegistryEntries()`), en assert daarna dat exec-id's met traversalsegmenten worden afgewezen. + - Als je een nieuwe `includeInPlan` SecretRef-targetfamilie toevoegt in `src/secrets/target-registry-data.ts`, werk dan `classifyTargetClass` in die test bij. De test faalt opzettelijk op niet-geclassificeerde target-id's, zodat nieuwe classes niet stilzwijgend kunnen worden overgeslagen. ## Gerelateerd diff --git a/docs/nl/reference/test.md b/docs/nl/reference/test.md index 479abd4ed..6c66d946d 100644 --- a/docs/nl/reference/test.md +++ b/docs/nl/reference/test.md @@ -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 ` 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