Naar hoofdinhoud gaan

Documentation Index

Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Dit is de specifieke checklist voor update- en Plugin-validatie. Het doel is eenvoudig: bewijzen dat het installeerbare pakket echte gebruikersstatus kan bijwerken, verouderde legacy-status via doctor kan repareren, en nog steeds plugins uit de ondersteunde bronnen kan installeren, laden, bijwerken en verwijderen. Voor de bredere kaart van testrunners, zie Testen. Voor live provider-sleutels en suites die het netwerk raken, zie Live testen.

​
Wat we beschermen

Update- en Plugin-tests beschermen deze contracten:
  • Een pakkettarball is compleet, heeft een geldige dist/postinstall-inventory.json, en is niet afhankelijk van uitgepakte repobestanden.
  • Een gebruiker kan van een ouder gepubliceerd pakket naar het kandidaatpakket overstappen zonder config, agents, sessies, workspaces, Plugin-allowlists of kanaalconfig te verliezen.
  • openclaw doctor --fix --non-interactive is eigenaar van legacy-opruiming en reparatiepaden. Startup mag geen verborgen compatibiliteitsmigraties krijgen voor verouderde Plugin-status.
  • Plugin-installaties werken vanuit lokale mappen, git-repo’s, npm-pakketten en het registerpad van ClawHub.
  • npm-afhankelijkheden van Plugins worden geïnstalleerd in de beheerde npm-root, vóór trust gescand, en tijdens deïnstallatie via npm verwijderd zodat gehesen afhankelijkheden niet blijven hangen.
  • Plugin-update is stabiel wanneer er niets is gewijzigd: installatierecords, opgeloste bron, geïnstalleerde afhankelijkheidslayout en ingeschakelde status blijven intact.

​
Lokaal bewijs tijdens ontwikkeling

Begin smal: 
pnpm changed:lanes --json
pnpm check:changed
pnpm test:changed
Voer voor wijzigingen aan Plugin-installatie, deïnstallatie, afhankelijkheden of pakket-inventaris ook de gerichte tests uit die de bewerkte overgang afdekken: 
pnpm test src/plugins/uninstall.test.ts src/infra/package-dist-inventory.test.ts test/scripts/package-acceptance-workflow.test.ts
Voordat een pakket-Docker-lane een tarball gebruikt, bewijs je het pakketartefact: 
pnpm release:check
release:check voert driftcontroles voor config/docs/API uit, schrijft de pakketdist-inventaris, voert npm pack --dry-run uit, weigert verboden ingepakte bestanden, installeert de tarball in een tijdelijke prefix, voert postinstall uit en rooktest gebundelde kanaal-entrypoints.

​
Docker-lanes

De Docker-lanes zijn het bewijs op productniveau. Ze installeren of updaten een echt pakket in Linux-containers en controleren gedrag via CLI-opdrachten, Gateway-startup, HTTP-probes, RPC-status en bestandssysteemstatus. Gebruik gerichte lanes tijdens iteratie: 
pnpm test:docker:plugins
pnpm test:docker:plugin-lifecycle-matrix
pnpm test:docker:plugin-update
pnpm test:docker:upgrade-survivor
pnpm test:docker:published-upgrade-survivor
pnpm test:docker:update-restart-auth
pnpm test:docker:update-migration
Belangrijke lanes:
  • test:docker:plugins valideert rooktests voor Plugin-installatie, lokale mapinstallaties, oversla-gedrag bij lokale mapupdates, lokale mappen met vooraf geïnstalleerde afhankelijkheden, file:-pakketinstallaties, git-installaties met CLI-uitvoering, git-updates voor bewegende refs, npm-registerinstallaties met gehesen transitieve afhankelijkheden, npm-update-no-ops, lokale ClawHub-fixture-installaties en update-no-ops, marketplace-updategedrag en Claude-bundel inschakelen/inspecteren. Stel OPENCLAW_PLUGINS_E2E_CLAWHUB=0 in om het ClawHub-blok hermetisch/offline te houden.
  • test:docker:plugin-lifecycle-matrix installeert het kandidaatpakket in een kale container, voert een npm-Plugin door installatie, inspectie, uitschakelen, inschakelen, expliciete upgrade, expliciete downgrade en deïnstallatie na het verwijderen van de Plugin-code. Het logt RSS- en CPU-metrics voor elke fase.
  • test:docker:plugin-update valideert dat een ongewijzigde geïnstalleerde Plugin niet opnieuw installeert of installatiemetadata verliest tijdens openclaw plugins update.
  • test:docker:upgrade-survivor installeert de kandidaat-tarball over een vuile oude-gebruiker-fixture, voert pakketupdate plus niet-interactieve doctor uit, start daarna een local loopback-Gateway en controleert statusbehoud.
  • test:docker:published-upgrade-survivor installeert eerst een gepubliceerde baseline, configureert die via een ingebakken openclaw config set-recept, werkt die bij naar de kandidaat-tarball, voert doctor uit, controleert legacy-opruiming, start de Gateway en probet /healthz, /readyz en RPC-status.
  • test:docker:update-restart-auth installeert het kandidaatpakket, start een beheerde token-auth Gateway, unset de auth-env van de caller-Gateway voor openclaw update --yes --json, en vereist dat de kandidaat-updateopdracht de Gateway herstart vóór de normale probes.
  • test:docker:update-migration is de opruimingszware published-update-lane. Deze begint vanuit een geconfigureerde gebruikersstatus in Discord/Telegram-stijl, voert baseline doctor uit zodat geconfigureerde Plugin-afhankelijkheden een kans krijgen om te ontstaan, seedt legacy-Plugin-afhankelijkheidsresten voor een geconfigureerde verpakte Plugin, werkt bij naar de kandidaat-tarball, en vereist dat post-update doctor de legacy afhankelijkheidsroots verwijdert.
Nuttige published-upgrade-survivor-varianten: 
OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC=openclaw@2026.4.23 \
OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=versioned-runtime-deps \
pnpm test:docker:published-upgrade-survivor

OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC=openclaw@latest \
OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=bootstrap-persona \
pnpm test:docker:published-upgrade-survivor
Beschikbare scenario’s zijn base, feishu-channel, bootstrap-persona, plugin-deps-cleanup, configured-plugin-installs, stale-source-plugin-shadow, tilde-log-path en versioned-runtime-deps. In geaggregeerde runs breidt OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues uit naar alle gerapporteerde issue-vormige scenario’s, inclusief de geconfigureerde Plugin-installatiemigratie. Volledige updatemigratie is bewust gescheiden van Full Release CI. Gebruik de handmatige workflow Update Migration wanneer de releasevraag is: “kan elke gepubliceerde stabiele release vanaf 2026.4.23 bijwerken naar deze kandidaat en Plugin-afhankelijkheidsresten opruimen?”: 
gh workflow run update-migration.yml \
  --ref main \
  -f workflow_ref=main \
  -f package_ref=main \
  -f baselines=all-since-2026.4.23 \
  -f scenarios=plugin-deps-cleanup

​
Pakketacceptatie

Pakketacceptatie is de GitHub-native pakketgate. Deze lost één kandidaatpakket op naar een package-under-test-tarball, legt versie en SHA-256 vast, en voert daarna herbruikbare Docker-E2E-lanes uit tegen exact die tarball. De workflow-harness-ref staat los van de pakketbron-ref, zodat huidige testlogica oudere vertrouwde releases kan valideren. Kandidaatbronnen:
  • source=npm: valideer openclaw@beta, openclaw@latest of een exacte gepubliceerde versie.
  • source=ref: pak een vertrouwde branch, tag of commit in met de geselecteerde huidige harness.
  • source=url: valideer een HTTPS-tarball met verplichte package_sha256.
  • source=artifact: hergebruik een tarball die door een andere Actions-run is geüpload.
Full Release Validation gebruikt standaard source=artifact, gebouwd vanuit de opgeloste release-SHA. Geef voor post-publish-bewijs package_acceptance_package_spec=openclaw@YYYY.M.D mee, zodat dezelfde upgradematrix in plaats daarvan het verzonden npm-pakket target. Releasecontroles roepen Pakketacceptatie aan met de pakket/update/herstart/Plugin-set: 
doctor-switch update-channel-switch update-corrupt-plugin upgrade-survivor published-upgrade-survivor update-restart-auth plugins-offline plugin-update
Wanneer release-soak is ingeschakeld, geven ze ook door: 
published_upgrade_survivor_baselines=last-stable-4 2026.4.23 2026.5.2 2026.4.15
published_upgrade_survivor_scenarios=reported-issues
telegram_mode=mock-openai
Dit houdt pakketmigratie, wisselen van updatekanaal, tolerantie voor corrupte beheerde Plugins, opruiming van verouderde Plugin-afhankelijkheden, offline Plugin-dekking, Plugin-updategedrag en Telegram-pakket-QA op hetzelfde opgeloste artefact, zonder dat de standaard releasepakketgate elke gepubliceerde release doorloopt. last-stable-4 lost op naar de vier nieuwste stabiele npm-gepubliceerde OpenClaw-releases. Releasepakketacceptatie pint 2026.4.23 als de eerste compatibiliteitsgrens voor Plugin-updates, 2026.5.2 als grens voor churn in de Plugin-architectuur, en 2026.4.15 als een oudere published-update-baseline van 2026.4.1x; de resolver dedupliceert pins die al in de nieuwste vier zitten. Voor uitputtende dekking van gepubliceerde updatemigratie gebruik je all-since-2026.4.23 in de afzonderlijke Update Migration-workflow in plaats van Full Release CI. release-history blijft beschikbaar voor handmatige bredere sampling wanneer je ook het legacy-anker van vóór de datum wilt. Wanneer meerdere published-upgrade-survivor-baselines zijn geselecteerd, shardt de herbruikbare Docker-workflow elke baseline in een eigen gerichte runner-job. Elke baseline-shard voert nog steeds de geselecteerde scenarioset uit, maar logs en artefacten blijven per baseline en de wandkloktijd wordt begrensd door de traagste shard in plaats van één grote seriële job. Voer handmatig een pakketprofiel uit wanneer je vóór release een kandidaat valideert: 
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=package \
  -f published_upgrade_survivor_baselines="last-stable-4 2026.4.23 2026.5.2 2026.4.15" \
  -f published_upgrade_survivor_scenarios=reported-issues \
  -f telegram_mode=mock-openai
Gebruik suite_profile=product wanneer de releasevraag MCP-kanalen, cron/subagent-opruiming, OpenAI-webzoekopdrachten of OpenWebUI omvat. Gebruik suite_profile=full alleen wanneer je volledige Docker-dekking van het releasepad nodig hebt.

​
Release-standaard

Voor releasekandidaten is de standaard bewijsstack:
  1. pnpm check:changed en pnpm test:changed voor regressies op bronniveau.
  2. pnpm release:check voor integriteit van pakketartefacten.
  3. Pakketacceptatie met het package-profiel of de aangepaste release-check-pakketlanes voor install/update/herstart/Plugin-contracten.
  4. Cross-OS-releasecontroles voor OS-specifieke installer-, onboarding- en platformgedrag.
  5. Live suites alleen wanneer het gewijzigde oppervlak provider- of hosted-service-gedrag raakt.
Op maintainer-machines moeten brede gates en Docker/pakket-productbewijs in Testbox draaien, tenzij expliciet lokaal bewijs wordt gedaan.

​
Legacy-compatibiliteit

Compatibiliteitstolerantie is smal en tijdgebonden:
  • Pakketten tot en met 2026.4.25, inclusief 2026.4.25-beta.*, mogen al verzonden hiaten in pakketmetadata in Pakketacceptatie tolereren.
  • Het gepubliceerde pakket 2026.4.26 mag waarschuwen voor al verzonden stampbestanden met lokale buildmetadata.
  • Latere pakketten moeten aan moderne contracten voldoen. Dezelfde hiaten falen in plaats van te waarschuwen of over te slaan.
Voeg geen nieuwe startupmigraties toe voor deze oude vormen. Voeg een doctor-reparatie toe of breid die uit, en bewijs die daarna met upgrade-survivor, published-upgrade-survivor of update-restart-auth wanneer de updateopdracht eigenaar is van de herstart.

​
Dekking toevoegen

Wanneer je update- of Plugin-gedrag wijzigt, voeg je dekking toe op de laagste laag die om de juiste reden kan falen:
  • Pure pad- of metadatalogica: unit-test naast de bron.
  • Pakket-inventaris of packed-file-gedrag: package-dist-inventory of tarball-checkertest.
  • CLI-install/updategedrag: Docker-lane-assertie of fixture.
  • Migratiegedrag van gepubliceerde releases: published-upgrade-survivor-scenario.
  • Update-eigen herstartgedrag: update-restart-auth.
  • Register-/pakketbrongedrag: test:docker:plugins-fixture of ClawHub-fixture-server.
  • Afhankelijkheidslayout of opruimgedrag: assert zowel runtime-uitvoering als de bestandssysteemgrens. npm-afhankelijkheden kunnen onder de beheerde npm-root worden gehesen, dus tests moeten bewijzen dat de root wordt gescand/opgeruimd in plaats van uit te gaan van een pakketlokale node_modules-boom.
Houd nieuwe Docker-fixtures standaard hermetisch. Gebruik lokale fixture-registers en neppakketten, tenzij live registergedrag het punt van de test is.

​
Fouttriage

Begin met de artefactidentiteit:
  • Samenvatting van Pakketacceptatie resolve_package: bron, versie, SHA-256 en artefactnaam.
  • Docker-artefacten: .artifacts/docker-tests/**/summary.json, failures.json, lane-logboeken en rerun-opdrachten.
  • Samenvatting van upgrade-survivor: .artifacts/upgrade-survivor/summary.json, inclusief baselineversie, kandidaatversie, scenario, fasetimings en receptstappen.
Geef de voorkeur aan het opnieuw uitvoeren van de exacte mislukte lane met hetzelfde pakketartefact boven het opnieuw uitvoeren van de volledige releaseparaplu.