Panel Route Shape

Panel menu destinations and route declarations must use /${part}/${type}/${action} for type actions or /${part}/${action} for part actions. A bare /${part} path is invalid in panels because the action must be explicit. These segments identify the owning part, optional type, and action; they are a semantic contract used by shared panel infrastructure to resolve route context and data. Apply the same contract to complex, simple, and headless panels. Menu destinations must match the corresponding route declarations and preserve their meaning. Do not substitute display labels, layout names, or arbitrary page aliases for part, type, or action segments. Keep route-context extraction in shared core infrastructure rather than duplicating path parsing in custom panels. Preserve the application home at / as a separate application-level route.

Philosophy

Paths describe application meaning consistently across APIs, panels, and sites; panel designs must preserve that meaning.

Correct

/calls/call/list
/accounts/user/find
/settings/applicationSettings

Incorrect

/calls
/myCalls
/dashboard/calls
/call/list
/calls/call/history/list

Fix

Align menu destinations and route declarations with the owning part, optional type, and action. Reuse shared route-context extraction in core.