40 lines
1.4 KiB
Markdown
40 lines
1.4 KiB
Markdown
# 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
|