# Sprint 151 Plan: Toolchain Abstraction and Diagnostics Normalization

## Context

After core constructive mechanics are language-neutral, Sprint 151 integrates
build/test toolchains through a provider abstraction with normalized diagnostics.

---

## Goals

1. Define language/toolchain provider abstraction for build and test
2. Normalize diagnostics from CMake/CTest, Cargo, npm/tsc/jest, and pytest
3. Preserve deterministic mapping from raw diagnostics to editor actions
4. Report provider readiness and compatibility per language

---

## Steps

### Step 1749: Toolchain provider interface schema (10 tests)
### Step 1750: Provider routing and fallback policy model (10 tests)
### Step 1751: Diagnostic normalization canonical model (10 tests)
### Step 1752: Source-location and fix-hint mapping model (10 tests)
### Step 1753: `whetstone_list_toolchain_providers` MCP tool (8 tests)
### Step 1754: `whetstone_probe_toolchain_provider` MCP tool (8 tests)
### Step 1755: `whetstone_normalize_diagnostics` MCP tool (8 tests)
### Step 1756: Provider compatibility packet model (8 tests)
### Step 1757: Toolchain readiness report artifact (8 tests)
### Step 1758: Sprint 151 integration summary + regression (8 tests)

---

## Architecture Gate

- Provider abstraction must be language-agnostic and deterministic
- Normalized diagnostics must preserve provenance to raw tool output
- Provider fallback behavior must be explicit and reproducible
- Max 600 lines per header