A Dashboard the UI cannot reach can make a saved query permanently undeletable

[BorisTyshkevich]

Summary

Once a workspace holds a Dashboard the UI cannot reach, a saved query that
Dashboard references can become permanently undeletable, with a diagnostic
the user has no way to act on.

How to reach it

1. File → Import workspace… with a portable bundle containing two or more
   Dashboards. Since Introduce StoredWorkspaceV3 with a dashboard collection and no UI change #424 every bundled Dashboard is imported (in file order),
   so workspace.dashboards now has more than one entry.
2. Only dashboards[0] — the compatibility Dashboard — is reachable in the UI;
   there is no selector, tree, or route parameter for the others yet.
3. Suppose dashboards[1] has a tile referencing saved query p1, and
   dashboards[0] does not.
4. Delete p1 from the ★ Queries list.

deleteSaved (src/state.ts) correctly carries the whole Dashboard collection
into its candidate, whole-workspace validation
(validateDashboardCollectionSemantics) correctly rejects the candidate with
dashboard-tile-query-missing at dashboards[1].tiles[0].queryId, and
src/ui/saved-history.ts toasts "Couldn't delete: Tile references unknown
saved query …".

Nothing is corrupted — the atomicity contract holds exactly as specified. The
problem is that no UI can reach dashboards[1] to remove that tile, so the
delete can never succeed. The same dead-end applies to any commit that would
dangle a hidden reference, e.g. changing a query's dashboard.role in the Spec
editor.

Why it is new

Before #424 the workspace held zero or one Dashboard, so the rejecting
Dashboard was always the visible one and the user could always repair it by
unstarring the query or deleting the tile. #424's storage change is what makes
an unreachable Dashboard possible, and the owner-approved import-all decision
is what makes one reachable in practice.

Why it is deferred, not fixed here

#424 is explicitly scoped as "storage, validation, repository, migration, and
internal API foundation only", with "Dashboard selector, tabs, dropdown, or
navigation UI" and "creating, deleting, duplicating, renaming, or reordering
Dashboards in the UI" as stated non-goals. The fix needs a surface that can
address a non-compatibility Dashboard, which is exactly what #425 (selection
state) and #426 (Dashboard tree) introduce, and #429 (panel/filter delete
actions) makes repairable.

Suggested resolution

Fold into the #430 programme rather than fixing standalone. Once #425/#426
land, either:

• let the delete diagnostic name the offending Dashboard and offer to navigate
  to it (the diagnostic already carries resource = the Dashboard id and an
  indexed dashboards[i] path), or
• offer the existing remove-affected-tiles repair from
  src/dashboard/application/saved-query-mutation.ts across the whole
  collection — note that planner is written for exactly this and still has no
  production caller.

Until then the exposure is limited to workspaces created by importing a
multi-Dashboard bundle; nothing the app itself authors can produce one.

Reference

• src/state.ts — deleteSaved / candidateFrom
• src/workspace/stored-workspace.ts — validateStoredWorkspaceDocument
• src/ui/saved-history.ts — the failure toast
• src/dashboard/application/saved-query-mutation.ts — the unused repair planner

Found during the #424 review; filed rather than folded into that PR.

[BorisTyshkevich]

Absorbed into #429 and closed — owner decision (2026-07-27): #429 owns all
Dashboard-tree management and click operations, and the repair path this issue
needs is one of them. This matches the resolution this issue itself suggested
("fold into the #430 programme rather than fixing standalone") and what #430
already recorded ("repairable in #429").

Half of the premise has expired

This issue was written when only dashboards[0] was reachable, so the offending
Dashboard could not be opened at all. #426's Dashboard tree fixed that — every
Dashboard in the collection is now reachable and addressable by id, so a user can
navigate to dashboards[1] and remove the tile by hand once #429's trash action
exists. "Permanently undeletable" no longer holds.

What survives is the dead end itself: a delete rejected by a reference on a
different Dashboard, reported through a diagnostic the user cannot act on from
where they are standing. That is a real gap, just a smaller one than filed.

Where it went

#429's "Decide the fate of the repair planner (absorbs #449 and #431)" section
requires, on either branch of the planner decision, that the rejected-delete dead
end closes — the diagnostic names the offending Dashboard (it already carries
resource = the Dashboard id and an indexed dashboards[i] path) and offers to
navigate there, now that the tree can address it, or offers the cross-collection
remove-affected-tiles repair. Your two suggested resolutions, in other words,
kept as the two acceptable outcomes.

Tested in #429 as: deleting a query referenced by a tile on a different Dashboard
names that Dashboard in the diagnostic and offers a way forward, rather than
dead-ending; and refusing a repair leaves the workspace byte-identical.

Exposure noted there too: only workspaces created by importing a multi-Dashboard
bundle can reach it — nothing the app authors itself produces one. #430's
integration-cleanup step no longer lists #431 as something to close later.

Nothing dropped; closing as absorbed, not as rejected.