plugins: preserve qveris runtime surfaces

[linfangw]

Summary

• Problem: bundled plugin public-surface resolution and legacy QVeris global installs could interfere with the fork's runtime web-search/provider loading after build or update flows.
• Why it matters: QVerisBot needs the bundled qveris plugin and its web search surface to win consistently in the packaged runtime, and local diagnostics should not report false gateway exposure alarms.
• What changed: added the extensions/qveris/web-search-provider.ts public surface, taught bundled public-surface resolution to prefer built artifacts, skipped legacy global qveris shadows in the manifest registry, moved dotenv / file-type / ipaddr.js loads behind runtime seams, removed the old bundled web-search registry, and updated the affected tests.
• What did NOT change (scope boundary): no protocol changes, no upstream repo targeting changes, and no new external service surface beyond the existing QVeris integration.

Change Type

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #
• This PR fixes a bug or regression

Root Cause

• Root cause: the fork still had mixed source-vs-built plugin public-surface resolution and a legacy global qveris install path could shadow the bundled plugin during manifest loading.
• Missing detection / guardrail: runtime path selection and duplicate-manifest handling did not have enough coverage for the fork's packaged/runtime layout.
• Contributing context (if known): the fork carries QVeris-specific plugin wiring on top of upstream changes, so runtime path assumptions need to stay explicit.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/plugins/public-surface-runtime.test.ts, src/commands/gateway-status.test.ts, src/cli/update-cli.test.ts, test/scripts/test-install-sh-docker.test.ts
• Scenario the test should lock in: packaged/runtime resolution prefers built bundled artifacts, gateway diagnostics stay deterministic, and install/update flows keep the expected runtime plugin surfaces.
• Why this is the smallest reliable guardrail: the regression lives at the runtime seam between bundled plugin metadata, dist layout, and fork-specific plugin wiring.
• Existing test that already covers this (if any): src/plugins/public-surface-runtime.test.ts
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Bundled QVeris runtime/provider loading now prefers the packaged public surface instead of drifting to source-layout assumptions.
• Legacy global QVeris plugin leftovers under the state dir no longer shadow the bundled plugin.
• Doctor network exposure warnings now use deterministic host-side bind resolution for diagnostics.

Diagram

Before:
[bundled qveris runtime] -> [mixed source/dist lookup or legacy global shadow] -> [wrong plugin surface picked]

After:
[bundled qveris runtime] -> [prefer built public artifact + ignore legacy shadow] -> [stable bundled provider surface]

Security Impact

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local Node 22 workspace
• Model/provider: N/A
• Integration/channel (if any): QVeris bundled plugin runtime surfaces
• Relevant config (redacted): default local fork setup

Steps

1. Run env OPENCLAW_LOCAL_CHECK=0 pnpm test src/plugins/public-surface-runtime.test.ts src/commands/gateway-status.test.ts src/cli/update-cli.test.ts test/scripts/test-install-sh-docker.test.ts.
2. Run pnpm build and inspect the runtime-postbuild chain.
3. Verify the branch pushes cleanly to QVerisAI/QVerisBot and opens against main.

Expected

• Bundled runtime/public-surface resolution stays stable and the targeted tests pass.

Actual

• Targeted tests passed locally. pnpm build reached runtime-postbuild without surfacing a compile error, but the local run did not terminate cleanly in this sandboxed session, so I did not record a green full-build exit.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification

• Verified scenarios: targeted tests above, clean commit, clean push to origin/QVerisAI/QVerisBot, and PR target set to main.
• Edge cases checked: source checkout vs built artifact resolution, legacy global qveris shadow handling, deterministic doctor bind-host resolution.
• What you did not verify: a fully completed local pnpm build exit in this sandbox session.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: fork-specific runtime path logic can drift again if upstream changes the bundled plugin dist layout.
  • Mitigation: keep the public-surface runtime tests and install/update regression tests covering the packaged layout.

[gemini-code-assist]

Code Review

This pull request updates the OpenClaw ecosystem to version 2026.4.14, introducing new agent skills for QA testing and secret scanning, an incident response plan, and stricter contribution limits. Key technical changes include local MLX-based speech synthesis for macOS, remote TTS support for Android, and a new execution approval workflow for iOS and Apple Watch. Feedback for the Android app identifies a logic discrepancy where manual gateway connections fail if the port is left blank, despite UI placeholders suggesting a default of 18789.

[gemini-code-assist]

The composeGatewayManualUrl function returns null for non-TLS connections if the port is empty. However, the UI placeholder in ConnectTabScreen and OnboardingFlow suggests a default port of 18789 for non-TLS connections. This discrepancy causes a validation error when a user leaves the port field blank, expecting the default behavior. It should default to 18789 to match the parseGatewayEndpoint logic and UI expectations.

Suggested change

	val port = if (portTrimmed.isEmpty()) {
	if (tls) 443 else return null
	} else {
	portTrimmed.toIntOrNull() ?: return null
	}
	val port = if (portTrimmed.isEmpty()) {
	if (tls) 443 else 18789
	} else {
	portTrimmed.toIntOrNull() ?: return null
	}