Proposal: route a recipe by role under a single URL

--Written with AI assistance--

Following up on #130 (unsupervised role assignment): besides auto-upgrading a user's role, there's a related gap worth splitting into its own proposal.

The problem

Today, giving different tiers of users different visibility (guest/standard/premium) means one URL per tier: wiki-guest, wiki-standard, wiki-premium, each pointing to its own recipe. It works, but it forces you to expose and manage N separate URLs for what's conceptually "one wiki with tiers".

The idea

Let a route definer resolve, at request time, which recipe to compose for a given URL based on the authenticated user's role — without changing the visible URL.

GET /course (always the same URL)
→ role=anon → composes recipe "course-guest"
→ role=standard → composes recipe "course-standard"
→ role=premium → composes recipe "course-premium"

The bags/recipes/priority model itself doesn't change — each recipe stays fixed and deterministic. The only new piece is a layer of indirection: which recipe a URL maps to stops being 1:1 and instead depends on the role resolved for that request.

Why it matters

Avoids duplicating the URL topology for every access tier.
Fits naturally with the auto-upgrade case from #130: if a user's role changes, they simply start getting served a different recipe at the same URL, with no manual link management.
It's a common pattern in tiered SaaS products (same domain, different content per plan).

Questions:

Does this fit MWS's scope, or is it better left to a custom auth/routing layer, as was already suggested in #130 for auth in general?
If it fits, would a declarative option (mapping role → recipe in config) make more sense than requiring a custom route definer?
Is there an existing mechanism that already covers this that I'm missing?

Thanks!

Start by reading the related issue #130 and locating the existing route-definer and authentication flow; this issue names no files or tests. The proposal is complete only after the project’s scope is decided and the role-to-recipe behavior, configuration approach, and acceptance criteria are agreed.