Reckon currently stores haiku, sonnet, and opus in plan metadata, sprint items, followups, prompts, schemas, examples, and UI tags. Those names describe one provider’s product families rather than the ability a task requires. They also age poorly: a newer lower-cost model can outperform an older premium model, while high-risk work may still require orchestrator-level judgment regardless of nominal family.
This plan replaces provider names in persisted state with a model-neutral capability request. Provider and model selection remains a runtime concern. Historical values must continue to parse during migration, but newly authored state must not depend on a vendor taxonomy.
Persist requirements; resolve a concrete worker only at dispatch time.
§2 — Contract ✓ landed 2026-07-29
A versioned neutral class plus structured reasoning, context, autonomy,
verification, and risk floors now travels through plans, sprint items,
followups, semantic HTML, MCP operations, JSON Schema, and the SPA.
§3 — Matching and compatibility ✓ landed 2026-07-29
Runtime-advertised workers are matched deterministically, including
one-below selection, cross-family fallback, and explicit escalation.
Historical tier values map on read with audit warnings and are never
rewritten implicitly.
§4 — Verification ✓ landed 2026-07-29
Commits b1c9a5d, c1c6eeb, and
0b9339c landed with 19 matcher regressions, 1,087 combined
integration tests, and the 1,270-test full suite passing. See the
landed evidence.
§ Decisions
What should be persisted as the task’s capability requirement?
A compact neutral class supports scheduling while structured requirements preserve risk, verification, context, autonomy, and reasoning constraints that cannot be represented by one ordinal.
How should existing haiku/sonnet/opus values migrate?
Legacy provider-family values remain readable with deterministic mapping and audit diagnostics; rewriting occurs only through explicit migration or ordinary state edits.
§ Followups
Implement the provider-neutral capability contract
Inventory every persisted and rendered tier field, lock the capability representation, then migrate the complete schema-to-dispatch vertical slice.
Project: reckon
Plan: model-capability-schema (http://localhost:8765/reckon/model-capability-schema.html)
Section: full plan
Tier: opus
Context
Provider model-family names are persisted throughout the current plan system.
Replace them with portable task requirements and runtime capability matching.
State to read
reckon/_schema.py, reckon/mcp.py, reckon/_plan_html.py, docs/ui/
skills/reckon-create/, skills/reckon-edit/, skills/reckon-ship/
Scope locks / constraints
Preserve legacy reads and the audit trail. Do not encode current provider or model ids.
Done-when
1. schema, migration, dispatch and UI changes land with compatibility tests
2. tests still green
3. followup written into plan + this followup marked resolved
Provider-neutral capability contract landed in b1c9a5d and c1c6eeb, integrated by 0b9339c; 19 matcher regressions, 1,087 combined schema/reference tests and 1,270 full-suite tests passed.
Consume neutral capability requests in bounded execution
The versioned capability class, structured hard requirements, deterministic runtime matcher and legacy diagnostics are shipped. The dependent execution work can now persist capability requirements without storing provider identities.
Project: reckon
Plan: execution-orchestration-hardening (http://localhost:8765/reckon/execution-orchestration-hardening.html)
Section: capability-aware dispatch and ledger
Capability: orchestrator
Requirements: deep reasoning, strict verification, elevated migration risk
Context
The provider-neutral schema and runtime matcher shipped with deterministic same-family preference, cross-family fallback, one-below selection, and explicit escalation signals. Integrate this contract into bounded execution after the remaining distributed state work lands.
State to read
GET /plan/reckon/model-capability-schema
GET /plan/reckon/execution-orchestration-hardening
docs/archive/model-capability-schema-s2-s4-landed.html
Locked decisions to honour
capability-shape → class-plus-requirements
legacy-migration → read-map-warn
Open decisions to surface (do not resolve)
none
Constraints
Persist capability requests only; resolve concrete provider/model identities at dispatch. Keep effort separate and retain elevated-risk escalation.
Done-when
1. bounded execution reads capability requests and runtime advertisements
2. ledger records fallback and escalation evidence without provider policy
3. interruption and worker-failure fixtures retain capability context
4. tests stay green
5. followup written into the plan and this followup marked resolved
