You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(lint): dashboard-action-route-unresolved resolves the apps/NAME head and every later segment
URL_COLLECTION_TO_STACK_KEY had no `apps` entry, so a dashboard header
action's url target like `/apps/no_such_app_nope/crm_lead` was never
checked at all — a button pointing at an app that does not exist passed
lint clean. The loop also returned at the first recognized collection
segment, resolved or not, so a bad app name combined with a bad later
segment (e.g. a bad dashboard name) reported only the later one.
Resolves the apps/NAME head against stack.apps (keyed by name, the same
identity the runtime's /apps/:appName route and REST's GET /meta/apps/:name
read by), and scans every segment of the path instead of stopping at the
first recognized one — one finding per unresolved <collection>/<name> pair.
Behavior change on paths that used to pass clean: a path where an earlier
segment resolves and a later one does not (e.g. /dashboards/exec/views/
bad_view) now reports the later segment instead of staying silent. Called
out as its own changeset bullet.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Vbw3RPgdtqesx4azk9SbW8
`dashboard-action-route-unresolved` now resolves the `apps/NAME` head of a dashboard header action's `url` target against `stack.apps`, and reports every unresolved `<collection>/<name>` segment in the path rather than stopping at the first one it recognizes.
6
+
7
+
Before this, `URL_COLLECTION_TO_STACK_KEY` had no `apps` entry, so an `actionUrl` like `/apps/no_such_app_nope/crm_lead` was never checked at all — a dashboard button pointing at an app that does not exist passed lint clean. Worse, once a bad app name was combined with a second bad segment later in the same path (e.g. `/apps/no_such_app_nope/dashboard/no_such_dashboard_nope`), the old loop returned at the FIRST recognized segment and reported only that one — so a bad app name plus a bad dashboard name reported only the dashboard, never the app.
8
+
9
+
**Behavior change on paths that used to pass clean:** the loop no longer stops scanning a path the moment it recognizes one collection segment, resolved or not. A path like `/dashboards/exec/views/bad_view` — where `exec` is a real dashboard but `bad_view` names no view — used to report nothing (the loop returned as soon as `dashboards/exec` resolved, never reaching `views/bad_view`); it now reports one warning on the `views/bad_view` segment. Any stack with a dashboard `url` action whose path recognizes a valid collection segment followed later by an unresolved one will see a NEW warning here that did not fire before. This is intentional — it is the same false-affordance category the rule already exists to catch — but it is a real, visible change to what a clean `lint` run reports on such stacks, not a pure addition.
0 commit comments