Root Class, Concrete Workshops
A reusable workshop family needs two truths at once. The queue lifecycle may be the same everywhere, and the products are still not the same product. If you erase the second truth, the kernel becomes a god-object that accumulates every domain exception. If you erase the first, every sibling copies claims, stages, reviews, and landing records until they drift.
The root-class approach names the neutral mechanics: delegation identity, status transitions, claim ownership, stage entries, review rounds, launch attempts, and row persistence. It deliberately does not name a quest, publication, accessibility audit, or any other domain outcome. Those nouns belong to concrete workshops.
A concrete workshop configures the kernel with its own table names, templates, brain policy, UI vocabulary, and verification hooks. That is more than branding. The concrete layer decides which stages make sense, what material may attach, which destination is valid, and what a landed record means to the product.
The dependency direction matters. Concrete workshops depend on the kernel; the kernel does not import them. A callback or provider interface lets the product supply policy without teaching the root layer every sibling name. That keeps reuse open while ownership stays local.
Draw the Ownership Line
List every public symbol in the proposed kernel. If a symbol only makes sense after naming one workshop, move it back to the concrete layer or replace it with a neutral capability. The goal is not maximum extraction. It is one-way dependency and one owner per promise.