ADR 0003 — Route shape: org slug, role, `[entity]/[id]`, `?view=`

Status

Accepted 2026-10-23 (owner Q2, confirmed by Q13).

Context

The prompt names "portal/(slug)/[role]/". A route group cannot carry an org value. HMS resolves the org from the host and hides tenant scope; its detail routes have two shapes, nine param names and 17 redirect pages. Evidence: ../research/rq2-route-shape.md, findings/hms-pattern-audit/routes.md §1, findings/hms-pattern-audit/catalog.md §Gap map.

Decision

• Addendum 2026-10-25: the org segment is named [orgSlug] (naming constitution); read [slug] below as [orgSlug].
• Portal root: /[locale]/portal/[slug]/[role]/... inside the (app) route group. [slug] = org slug, [role] = portal role (Q7 demo roles).
• Entity routes: [entity] (list), [entity]/new, [entity]/[id], [entity]/[id]/edit. One param name: [id]. No view/ segment.
• List view modes switch with ?view=list|grid|board|timeline, not a path segment.
• The (marketing) and (auth) groups stay outside the portal (D4).
• The [slug]/[role] layout resolves org + session. Only PortalPage gates the role (invariant 14).

Rejected alternative

Route group (slug) + host-based org resolution (HMS shape). Rejected: no URL segment, so tenant scope is invisible and isolation is hard to test. Host resolution stays a later option.

Consequences

• Isolation specs can hit two org slugs side by side.
• No redirect glue pages; one detail and one edit shape.
• The nav registry and breadcrumbs build hrefs from slug, role, entity, id.
• Typed routes must accept the dynamic segments — checked in the ddx-web scaffold task.