Repin conformance harness to the published 0.2.0-alpha.10

[maxisbey]

Repins the conformance harness from the temporary pkg.pr.new build of main@da56f663 to the published @modelcontextprotocol/conformance@0.2.0-alpha.10, and drops the sha256 fetch-and-verify steps that only the tarball URL needed.

Motivation and Context

The pkg.pr.new pin was a stopgap until an npm release carrying conformance #403 (sep-2575 checks aligned with spec #3002) and #406 (per-check expected-failures granularity) shipped. 0.2.0-alpha.10 is now on npm (the alpha dist-tag) with both, so CONFORMANCE_PKG can go back to a plain registry spec — npm's own integrity check replaces the recorded digest.

The release adds two commits beyond the previous pin (conformance #409, #383); neither changes results against this SDK, so both expected-failures*.yml baselines are unchanged apart from comment wording.

How Has This Been Tested?

Ran all six CI legs locally against the 0.2.0-alpha.10 tarball (server active/draft/2026-07-28/all, client all/2026-07-28) — every leg passes with the existing baselines and no stale entries.

Breaking Changes

None; CI-only.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• CI

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[claude]

LGTM — straightforward CI-only repin of the conformance harness to the published npm release.

What was reviewed:

• The workflow diff: CONFORMANCE_PKG moves from the pkg.pr.new tarball URL back to an exact registry spec (0.2.0-alpha.10), and the fetch-and-verify steps that only the URL pin needed are removed symmetrically from both jobs.
• Checked for dangling references to CONFORMANCE_PKG_SHA256 or pkg.pr.new across .github/ — none remain; run-server.sh/run-client.sh consume CONFORMANCE_PKG unchanged.
• expected-failures.yml changes are comment-only (removing stale references to the da56f663 pin); no baseline entries added or removed.

Extended reasoning...

Overview

This PR touches only two CI files: .github/workflows/conformance.yml and .github/actions/conformance/expected-failures.yml. It repins the conformance harness from a temporary pkg.pr.new tarball build (main@da56f663) to the published @modelcontextprotocol/conformance@0.2.0-alpha.10 on npm, and removes the sha256 fetch-and-verify steps that existed solely to pin the bytes of the tarball URL. The expected-failures baseline changes are comment wording only — no entries added or removed, consistent with the PR description's claim that the two extra commits in the release don't change results against this SDK.

Security risks

The supply-chain posture is a mild consideration: the previous state verified a recorded sha256 digest of the tarball, while the new state relies on npm's registry integrity checking for an exact-version spec. Exact versions on the npm registry are immutable, and this restores the workflow's documented normal state (the pre-existing comment said to use a published version spec). This is a return to the established pattern, not a weakening of it. No secrets, permissions, or auth surfaces are touched; the workflow keeps permissions: contents: read and persist-credentials: false.

Level of scrutiny

Low — this is CI-only configuration with no effect on shipped code. The main things worth checking were (a) that the fetch-and-verify removal was symmetric across both jobs (it is), (b) that nothing else references the now-deleted CONFORMANCE_PKG_SHA256 env var or the pkg.pr.new URL (grep over .github/ confirms nothing does), and (c) that the run scripts still receive CONFORMANCE_PKG in a form npx --yes accepts (a plain registry spec, which is the original supported form).

Other factors

The bug hunting system found no issues. The PR author reports running all six CI legs locally against the 0.2.0-alpha.10 tarball with all legs passing and no stale baseline entries, and CI itself will independently verify this claim on the PR — a stale or newly-failing entry would fail the run. There are no outstanding reviewer comments. The change follows the workflow's own documented bump procedure ("Bump deliberately and reconcile both expected-failures*.yml files in the same change").