THEMES.md section 5's module-default-view step is unexercised across the entire fleet

standards/THEMES.md §5 defines the view resolution chain as:

configured surface/tenant/site theme → parent theme chain → module default view → application fallback

The third step has never been exercised by anything in the fleet.

Evidence

• theme-default's views directory holds a single .gitkeep.
• No foundation module has a resources/views directory at all. Not identity-core, not profiles, not organizations-teams.
• Only the -livewire flavour packages ship views, and those are components rather than overridable default views.

So the chain currently degrades to configured theme → application fallback, and the step that makes a module renderable without host edits is theoretical.

Why it matters

§5 also forbids a theme owning routes, actions or domain services. That is the right constraint, and it makes the module-default-view step the only mechanism by which a module's own presentation reaches a page. A product extracting ~100 modules depends on it working.

ecommerce-laravel's storefront plan is built on §5 as written — routes and cross-module pages in the host, per-module default views shipping with the module, layouts and tokens in a theme. The first commerce module to ship a default view will be exercising this path for the first time anywhere.

Ask

Confirm §5's third step is intended to be live rather than aspirational, and — separately, filed per package — give the foundation modules a view layer so the chain has something to resolve to.

Found while auditing ecommerce-laravel against the standards.

Start with standards/THEMES.md §5 and compare its documented view-resolution chain with the evidence in the issue: theme-default/views contains only .gitkeep, while the named foundation modules have no resources/views directories. Confirm whether the module-default-view step is intended to be live, and treat foundation-module view layers as separate package issues.