Design Proposal: claude-fable-5 kernel/orchestrator compatibility

[Michael J. Jabbour (michaeljabbour)]

Design Proposal: claude-fable-5 Kernel + Orchestrator Compatibility

Status: Ready for discussion (no code changes)
Type: Design Proposal

Summary

This spec defines 12 additive, backward-compatible changes to support Anthropic's claude-fable-5 model class and similar adaptive-thinking models.

Key Changes

1. Message.producer_model — First-class provenance field enabling the model-switch thinking-block strip rule
2. Orchestrator finish_reason consumption — New provider:refusal event with a distinct "refused" terminal status (today a refusal silently ends as "incomplete")
3. Provider-contract docs — Normative stop-reason vocabulary, empty-thinking+signature round-trip clause, model-switch strip rule, effort/output_config params, refreshed stale 200k/4k token examples

Scope

• Modules: amplifier-core, amplifier-module-loop-streaming, amplifier-module-provider-anthropic, contract docs
• Principle: Kernel provides MECHANISM only; policy lives in modules/config. Additive, no breaking changes.

Technical Highlights

• Thinking-block stripping happens provider-side at request-build (providers switch models invisibly via internal fallbacks); refusal retry POLICY stays out of the kernel per mechanism-not-policy
• Dormant streaming path is documented as a known issue, not rewritten (because the live path is non-streaming complete())
• Spec was authored against current main + the live loop-streaming module

What This Delivers

✅ Refusals are now detectable (not silently invisible)
✅ Thinking-block signatures are protected across model switches
✅ Model provenance is traceable end-to-end
✅ Four independent bricks can be implemented/reviewed in parallel

What This Doesn't Do

❌ No automatic retry-on-another-model (that's policy — belongs in provider config or a hook)
❌ No streaming-path rewrite (known issue documented separately)
❌ No breaking changes to any existing API

How to Read This

Start at §1 (Design Decisions) to see the four bricks and why they're shaped this way.
§2-5 are the edits (exact file:line + diffs).
§7 is the testing strategy.
§8 explicitly calls out non-goals and why.

This is for discussion before any implementation PR. Please review the design decisions and suggest feedback.