PR #70035: fix(release-check): assert bundled plugin runtime deps after packed postinstall

• Repository: openclaw/openclaw
• Author: GodsBoy
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/70035

Description (problem / solution / changelog)

Summary

• release-check already validates that bundled plugin runtime deps are staged in the source dist/extensions/<id>/node_modules/ via checkBundledExtensionMetadata, but runPackedBundledChannelEntrySmoke never re-validates after runPackedBundledPluginPostinstall against the installed tarball.
• That gap is how 2026.4.21 published to npm with dist/extensions/whatsapp/node_modules/@whiskeysockets/baileys missing: the source staging passed during build, npm pack strips every node_modules/ path, and the packed postinstall silently failed to reinstall baileys. Release-check never noticed because it did not re-check the installed layout.
• This PR re-uses the existing collectBuiltBundledPluginStagedRuntimeDependencyErrors helper, aimed at the installed packageRoot, right after the packed postinstall runs, and fails release-check if any declared runtime dep is missing from the plugin-local node_modules.

Change Type

• Bug fix (regression guard)
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• CI/CD / infra (release-check)

Linked Issue/PR

• Follow-up to #69842 (closed prematurely relative to npm release: v2026.4.21 was tagged ~11 minutes before the doctor-side repair commit landed, so npm still shipped the broken state)
• Related: #68778 (deeper fragility around RC dep + postinstall hotfix; not addressed here)

Root Cause / Why release-check missed it

• checkBundledExtensionMetadata runs collectBuiltBundledPluginStagedRuntimeDependencyErrors against the repo's own dist/extensions/. At that point the staged node_modules are present, so the check passes.
• collectForbiddenPackPaths then strips all node_modules/ entries from npm pack output (correct, so tarballs stay small and deterministic).
• runPackedBundledChannelEntrySmoke installs the tarball and invokes runPackedBundledPluginPostinstall to reinstall the plugin runtime deps into the installed layout. If that postinstall silently under-installs a bundled plugin's declared deps (as happened for WhatsApp + baileys in v2026.4.21), nothing downstream notices: the compiled channel entry smoke loads entry files but does not force-import the lazy runtime dep, and the completion smoke does not touch it either.
• Net result: release-check ships a "green" tarball whose installed layout is broken for users.

What this PR changes

• scripts/release-check.ts:
  • New exported helper collectInstalledBundledPluginRuntimeDepErrors(packageRoot) that adapts the existing collectBuiltBundledPluginStagedRuntimeDependencyErrors to the installed packageRoot/dist/extensions/ layout.
  • New internal assertInstalledBundledPluginRuntimeDepsResolved(packageRoot) that surfaces each missing dep with its owning plugin id and throws so release-check fails visibly.
  • Wired into runPackedBundledChannelEntrySmoke immediately after runPackedBundledPluginPostinstall(packageRoot).
• test/release-check.test.ts:
  • Unit coverage for the new helper: passes when declared deps are staged under the installed plugin, and surfaces a precise error naming plugin id + missing dep when they are not.

No runtime behavior changes in any plugin, no changes to postinstall logic, no changes to tarball contents.

Regression Test Plan

• Coverage level:
  • Unit test (new)
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient (for the underlying helper)
• Target tests: test/release-check.test.ts ("collectInstalledBundledPluginRuntimeDepErrors") + existing test/scripts/bundled-plugin-staged-runtime-deps.test.ts (already covers the collector).
• Scenario the test locks in:
  • A simulated installed packageRoot with a bundled plugin that declares @whiskeysockets/baileys but has no staged node_modules/@whiskeysockets/baileys/package.json under the plugin dir produces an error naming plugin whatsapp and dependency @whiskeysockets/baileys.
  • The same simulated installed layout with the dep staged returns no errors.
• Why this is the smallest reliable guardrail: the release-check wiring is a thin shim over a helper that is already covered in isolation; the new test asserts only that the shim assembles the packageRoot -> dist/extensions path correctly and threads errors through. The full packed install + postinstall flow is exercised by runPackedBundledChannelEntrySmoke in CI and does not need a parallel unit harness.

Verification

pnpm check:changed
  [check:changed] lanes=tooling
  [check:changed] scripts/release-check.ts: tooling surface
  [check:changed] test/release-check.test.ts: root test/support surface
  [check:changed] conflict markers ... OK
  [check:changed] lint scripts ... Found 0 warnings and 0 errors.
  [check:changed] tests changed ... Test Files 1 passed (1) / Tests 28 passed (28)

User-visible / behavior changes

• Release-check now fails when the packed + installed + postinstalled layout is missing any declared runtime dep of a bundled plugin that opted into stageRuntimeDependencies.
• No change for users running openclaw normally. Only affects the release lane.

Out of scope

• The deeper WhatsApp fragility (RC baileys version, postinstall-only hotfix, doctor self-heal coverage). Tracked in #68778.
• Supply-chain lockfile coverage for bundled plugins. Tracked in #58291.
• The actual doctor-side repair that shipped to main as f9b20c7d17 after v2026.4.21 was tagged. That change is expected to ship in the next release; this PR is an independent regression guard that would have caught the v2026.4.21 publish itself.

Changed files

• scripts/release-check.ts (modified, +32/-1)
• test/release-check.test.ts (modified, +65/-0)