planSavedQueryMutation still has no production caller; deleteSaved rejects instead of offering its repairs

[BorisTyshkevich]

Noticed while implementing #427; not fixed there.

src/dashboard/application/saved-query-mutation.ts (planSavedQueryMutation, suggestRepairs) has no production caller. Its own doc comment says so: "Note for the caller that eventually wires this up (it has no production caller yet)" (around line 195). The only references to it anywhere in src/ are doc comments in import-planner.ts, tile-membership.ts and layout-registry.ts.

Meanwhile src/state.ts's deleteSaved does not use it: it filters the query out and commits, so deleting a query a Dashboard tile still references is rejected outright by whole-workspace validation (dashboard-tile-query-missing) with no repair offered — exactly the case the planner's remove-affected-tiles / remap-query repairs exist for.

#427 added ownership rules to that planner (a remap may not create multiple owners; deleting an owned query without removing its owner is refused), so it is now ~220 lines of fully-covered code with no runtime path, and its guarantees cannot be integration-proven.

Why deferred

Wiring it up means designing the repair UI — "this query backs a panel on Sales; remove the panel, point it at another query, or cancel" — which is #429's territory (panel/filter removal plus exactly-owned query deletion). Doing it inside #427 would have meant inventing that dialog.

What to do

Either wire deleteSaved (and the role/variant-changing paths of commitSavedQuery) through planSavedQueryMutation as part of #429 and surface suggestRepairs in the UI, or — if #429's own atomic trash action makes the planner redundant — delete it rather than keep a second fully-covered module with no caller.

[BorisTyshkevich]

Absorbed into #429 and closed — owner decision (2026-07-27): #429 owns all
Dashboard-tree management and click operations, which includes member removal
and the owned-query deletion semantics this planner exists for.

This issue already named #429 as the right home ("wiring it up means designing the
repair UI … which is #429's territory"), so the fold follows your own conclusion
rather than overriding it.

#429 now carries a "Decide the fate of the repair planner (absorbs #449 and
#431)" section holding your facts intact: planSavedQueryMutation /
suggestRepairs has no production caller (its own doc comment says so; the only
src/ references are doc comments in import-planner.ts, tile-membership.ts
and layout-registry.ts), deleteSaved filters and commits instead of using it,
so a delete blocked by a live tile reference is rejected with
dashboard-tile-query-missing and no repair offered — and #427's ownership rules
made it ~220 lines of fully-covered code whose guarantees cannot be
integration-proven.

Two changes to how it's framed:

1. It must decide, not defer. Dashboard tree management: direct Dashboard and Panel actions #429 states the choice explicitly — wire
   deleteSaved (and the role/variant-changing paths of commitSavedQuery)
   through the planner and surface suggestRepairs, or delete the module if
   Dashboard tree management: direct Dashboard and Panel actions #429's own atomic trash makes it redundant — and requires the PR to say which.
   A test asserts no fully-covered no-caller module survives the issue.
2. A Dashboard the UI cannot reach can make a saved query permanently undeletable #431 folded in with it, since it is the user-visible face of the same gap.
   Either branch must also close the dead end: the diagnostic names the offending
   Dashboard (it already carries resource = the Dashboard id and an indexed
   dashboards[i] path) and offers navigation there, or offers the
   cross-collection remove-affected-tiles repair.

Nothing dropped; closing as absorbed, not as rejected.