D20 — Module-owned Blade views + Livewire, registered under a module namespace (RESOLVED)
Architecture decision record, relocated verbatim from the retired single-file
docs/tenancy/decision log. Status, thematic clusters, and how to record a new ADR: the decision log index.
modular auto-registers each module's resources/views under the module-name view namespace
(ViewPlugin → backoffice::view.name) and its Blade components under <x-backoffice::…>
(BladePlugin). So a module just drops Blade files in app-modules/<module>/resources/views to
own them.
- Backoffice page views moved into the module:
backoffice::livewire.auth.*,backoffice::livewire.settings.*,backoffice::welcome,backoffice::dashboard. Fortify view bindings +Route::view()reference thebackoffice::namespace; each Livewire Settings component has an explicitrender()returning itsbackoffice::view (Livewire resolves component views from the default namespace otherwise). Verified live (/,/login,/register→ 200) + by the auth/settings feature tests that render these views. - Shared design-system views stay global (
resources/views):layouts/, genericcomponents/(app-logo, auth-header, passkey-*, settings/layout),partials/,flux/overrides. These are the cross-cutting UI kit used by every module's views (and thelayouts::component namespace is already wired). They are a candidate to move into Foundation (e.g.foundation::layouts.*) when worth the reference churn. - Livewire component classes live in the module (
Modules\Backoffice\Livewire\*) and are registered by the Backoffice provider (Livewire::component('settings.*', …)).