WIP: stage all uncommitted work — sprints 46-221, graduation headers, specialist fleet, test steps 909-1988

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

sprint132_plan.md

@@ -0,0 +1,40 @@
+# Sprint 132 Plan: MCP Runtime Fingerprinting and Binary Freshness Guarantees
+
+## Context
+
+Even with correct source wiring, stale binaries can expose older MCP surfaces.
+Sprint 132 introduces runtime fingerprints to guarantee clients know what binary
+capabilities they are talking to.
+
+---
+
+## Goals
+
+1. Fingerprint MCP binaries with deterministic capability hashes
+2. Detect stale runtime vs current workspace source at startup
+3. Provide explicit freshness checks for automation and agents
+4. Prevent silent downgrade to older tool surfaces
+
+---
+
+## Steps
+
+### Step 1559: MCP runtime fingerprint schema (10 tests)
+### Step 1560: Capability hash generator from manifest + build metadata (10 tests)
+### Step 1561: Workspace-source freshness comparator model (10 tests)
+### Step 1562: Startup stale-binary detector integration (10 tests)
+### Step 1563: `whetstone_get_runtime_fingerprint` MCP tool (8 tests)
+### Step 1564: `whetstone_check_runtime_freshness` MCP tool (8 tests)
+### Step 1565: Runtime freshness warning/escalation policy (8 tests)
+### Step 1566: Binary capability packet export model (8 tests)
+### Step 1567: Runtime freshness report artifact (8 tests)
+### Step 1568: Sprint 132 integration summary + regression (8 tests)
+
+---
+
+## Architecture Gate
+
+- Fingerprints must be deterministic and reproducible
+- Freshness checks must include explicit source and binary provenance
+- Warnings/escalations must be machine-readable
+- Max 600 lines per header