1.7 KiB
1.7 KiB
Sprint 156 Plan: Representative Language Runtime Contract Baseline
Context
Sprint 146-155 added multi-language constructive interfaces, but many handlers still return scaffold responses. Sprint 156 defines the concrete runtime contract baseline across representative languages from the 46-120 era.
Goals
- Standardize runtime contract fields across representative languages
- Define canonical representative language set for constructive operations
- Establish per-language support tiers and operation coverage matrix
- Preserve deterministic, machine-readable outputs for all tool responses
Steps
Step 1799: Representative language profile schema (cpp, rust, python, typescript, javascript, go, java, elisp) (10 tests)
Step 1800: Cross-language capability contract normalizer model (10 tests)
Step 1801: Language operation support policy model (edit, sync, regenerate, merge, build_test) (10 tests)
Step 1802: Runtime profile store and lookup model (10 tests)
Step 1803: whetstone_list_representative_language_profiles MCP tool (8 tests)
Step 1804: whetstone_get_representative_language_profile MCP tool (8 tests)
Step 1805: whetstone_validate_representative_language_operation MCP tool (8 tests)
Step 1806: Representative language conformance packet model (8 tests)
Step 1807: Representative language readiness report artifact (8 tests)
Step 1808: Sprint 156 integration summary + regression (8 tests)
Architecture Gate
- Language outputs must use one shared schema envelope
- Representative language list must be explicit and versioned
- Unsupported operations must return structured denial reasons
- Max 600 lines per header