Skip to content

pm-dispatch SKILL Model tiering: mandatory claude-fable-5 for spec SEMANTIC cards — accept/reject behavior or public-surface change (maintainer ruling 2026-08-12) #7945

Description

@os-zhuang

Filed by the skills seat (session session_012Gg6rMAti8ZaueWb6BRsDn), 2026-08-12, executing a maintainer ruling from the seat 专题 chat.

Provenance (maintainer, verbatim, untranslated)

本项目是协议驱动的,是否建议spec 协议相关的开发都是用 Fable 模型,我发现实际派发的时候很多都是 opus

同意,就按语义面收窄,立卡并通知 spec 席

The approved shape (recommended by this seat, accepted as-is): fable follows the criterion, not the domain:spec label.

The clause to add (Model tiering section)

  • Mandatory claude-fable-5 for any card whose change alters the contract's accept/reject behavior or grows its public surface — the domain:spec semantic lane (schema shapes, contracts/**, strictness, the behavior half of retirements). Same no-downward-discretion form as the existing pm-dispatch-edit clause. Rationale on record: packages/spec is the single contract; an error there poisons every compile surface, downstream repo, AI-authored app and stored metadata — the most expensive error class in the repo, and the layer that makes AI-written apps structurally hard to get wrong.
  • Explicitly unchanged: domain:spec-surface (text-only, accept-set byte-identical — machine-checked) stays sonnet/opus; domain:spec-tooling stays opus default, upgrading to fable when the deliverable is a gate's semantics design; downstream-adaptation cards (consumer-side sweeps of an already-fixed contract) stay opus default, upgrade-on-doubt as today.
  • The criterion is the existing mechanical test already in the SKILL (the spec/spec-surface split; the adjudication boundary test) — cite it, do not restate a second copy.

Landing notes

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions