Pins four behavior surfaces as tests so accidental drift fails CI: the wire error-code tables and version constants, the strict/strip/loose line each wire schema draws, the published package set and export maps, and the stdio environment-inheritance safelist. Tests and docs only — zero source changes.

Motivation and Context

Ahead of the 2026-07-28 revision work, surface moves should be deliberate, not silent: the regular suite verifies features work, but it stays green through error-code remaps, schema strictness flips, and export-map changes. A red pin doesn't mean a change is forbidden — it means the change is surface-visible: update the pin in the same PR, with a changeset where consumer-facing. The maintenance protocol lives in docs/behavior-surface-pins.md.

This is a focused port of the inventory from #2258/#2262 (closed, v1.x-based), cut down to the four surfaces where accidental drift is both plausible and expensive. Earlier revisions of this branch pinned much more — protocol runtime details, OAuth message text, shutdown timing, and a few known bugs pinned as-is. That long tail cost more in maintenance than it protected against and is dropped; the known bugs are filed as #2283 and #2284 instead of frozen as behavior.

How Has This Been Tested?

71 assertions across 4 test files, all green against the unchanged source tree. Each structural pin was mutation-checked: widening DEFAULT_INHERITED_ENV_VARS with an unset variable, adding an unlisted workspace package, adding an export-map key, and renumbering an error code each turn the relevant pin red.

Breaking Changes

None. Tests and documentation 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

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

Additional context

Two construction notes, both consequences of mutation-checking the pins:

• The package-set pin scans packages/ instead of trusting a hardcoded list. The workspace glob auto-adopts new directories and changesets publishes any non-private package, so the set of packages is itself published surface — a new package must be classified here deliberately.
• The env-safelist pin compares the source constant against a frozen literal. The behavioral test alone can't catch widening: unset variables never appear in getDefaultEnvironment()'s output, and sensitive variables are exactly the ones typically unset in CI.