ADR-0001: Use Actions, Data, and Registered Extension Points
Status
Section titled “Status”Accepted
Context
Section titled “Context”Capell is split into core, admin, frontend, and companion packages. Features often cross package seams: Filament form-builder update core models, frontend rendering depends on core page state, add-ons register schemas and blocks, and install workflows compose package metadata with application setup.
Without a consistent shape, callers can accumulate procedural knowledge about validation, ordering, model writes, package discovery, and extension registration.
Decision
Section titled “Decision”Domain behaviour belongs in Actions. Controllers, commands, Filament pages, Livewire components, listeners, and jobs call Actions instead of embedding domain logic.
Structured state crossing package, HTTP, Livewire, Filament, or rendering seams belongs in Data objects.
Package customisation must use registered Capell extension points such as schema extenders, settings schema registration, block registration, render hooks, subscriber registration, admin tool registration, cache invalidation registration, Tailwind asset registration, and static-site extensions.
Consequences
Section titled “Consequences”Callers get small, stable interfaces for behaviour that would otherwise be repeated across packages.
Tests should target Actions and Data objects first, then cover HTTP, Filament, Livewire, or rendering surfaces where those surfaces add behaviour.
New extension needs should usually become explicit registries, subscribers, or tagged interfaces rather than ad hoc conditionals inside core package code.
This ADR does not require adding a new seam for every variation. A seam is justified when more than one adapter or package needs to vary behaviour.