test(e2e): align mcp-bridge-dev with the supported OpenShell version boundary #6426

Agent Diagnostic

• Investigated GitHub Actions run 28909889309, job mcp-bridge-dev, including the uploaded artifacts.
• The workflow installed OpenShell 0.0.78-dev.6, while the checked-in credential-boundary manifest and runtime guard require exactly 0.0.72.
• All six concurrent MCP-add attempts (two each for OpenClaw, Hermes, and DeepAgents) failed at the version gate before exercising MCP behavior.
• The same lane failed identically in run 28839573992 against 0.0.78-dev.5; this is deterministic, not flaky.
• The supported stable mcp-bridge lane passed on the same main SHA in run 28909147235.
• Searched open issues for the exact lane/version-mismatch symptom; no dedicated tracker exists.

Description

The explicit mcp-bridge-dev E2E lane installs the moving OpenShell dev channel and then runs success-path MCP lifecycle assertions. NemoClaw intentionally fails closed unless the running OpenShell version exactly matches the reviewed credential-boundary manifest (0.0.72). As soon as the dev channel moves beyond the supported version, every MCP mutation is rejected and the success-path test is guaranteed to fail.

The security version gate is behaving correctly and must not be weakened. The E2E lane needs semantics that distinguish an expected unsupported-version rejection from an actual MCP compatibility regression.

Expected behavior: the explicit dev lane produces actionable compatibility evidence. When dev is outside the reviewed support boundary, it should verify and report the fail-closed mismatch intentionally rather than fail later because zero success-path mutations completed. Full MCP lifecycle assertions should run only after the dev runtime, credential manifest, and supported version boundary have been deliberately reviewed and aligned.

Actual behavior: all three agent scenarios fail the shared concurrency assertion because both add attempts are rejected by the exact-version gate.

Reproduction Steps

1. Dispatch .github/workflows/e2e.yaml on main with jobs=mcp-bridge-dev.
2. Observe that scripts/install-openshell.sh installs the current moving dev release (0.0.78-dev.6 in run 28909889309).
3. Observe both concurrent nemoclaw <sandbox> mcp add ... attempts fail for OpenClaw, Hermes, and DeepAgents.
4. Observe test/e2e/live/mcp-bridge.test.ts fail at the assertion requiring exactly one successful attempt.

Environment

• Workflow: E2E (workflow_dispatch)
• Run: 28909889309
• Main SHA: c1c213861254ced036a45afa8722326718bc390b
• Runner: GitHub-hosted Ubuntu 24.04 x86_64
• Node.js: 22.23.1
• Supported OpenShell: 0.0.72
• Installed OpenShell dev artifact: 0.0.78-dev.6+ga7271169

Debug Output

CI-only E2E contract failure. Job logs and sanitized artifacts are attached to the linked workflow run. The supported stable MCP lane passed on the same main SHA.

Logs

OpenShell credential boundary runtime version check failed: expected 0.0.72, actual 0.0.78-dev.6+ga7271169 (version mismatch). Install OpenShell 0.0.72, or point NEMOCLAW_OPENSHELL_BIN to that version, then retry.

AssertionError: expected [] to have a length of 1 but got +0
  at assertConcurrentAddSerialized (test/e2e/live/mcp-bridge.test.ts:450)

Related Work

• PR #5876 introduced the stable and explicit dev MCP lanes.
• PR #6261 added the exact host OpenShell version gate.
• Issue #6256 tracks the broader credential-boundary runtime attestation requirement.

Acceptance Criteria

• The exact credential-boundary version gate remains fail closed.
• mcp-bridge-dev handles a moving, unsupported OpenShell version as an explicit compatibility result instead of running success-path assertions that cannot pass.
• Full dev MCP lifecycle assertions run only when the dev artifact and reviewed credential manifest/support boundary are aligned.
• Workflow contract tests cover both the expected mismatch path and the aligned-runtime success path.
• The stable mcp-bridge release-evidence lane remains unchanged and green.

Checklist

• I confirmed this bug is reproducible
• I searched existing issues and this is not a duplicate