whetstone_DSL/sprint132_plan.md

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