Replace the Dashboard-level Query button with per-tile “Open in Workbench” actions

[BorisTyshkevich]

Problem

The Dashboard header currently contains a global < Query button that switches from the Dashboard surface back to the Workbench.

This is the wrong interaction model:

• it does not identify which Dashboard query the user wants to inspect or edit;
• it behaves like generic back navigation rather than a query-specific action;
• after viewing a tile, the user must separately locate the corresponding query in the Workbench;
• it occupies primary Dashboard toolbar space without carrying useful context.

Required behaviour

Remove the Dashboard-level < Query button from the header.

Add an Open in Workbench icon action to every query-backed Dashboard tile.

Clicking the tile action must:

1. resolve the exact query document represented by that tile;
2. switch to the Workbench/Query surface;
3. open that Dashboard query in the main SQL editor, or select its existing tab when already open;
4. preserve the query's Dashboard provenance so Save continues to target the Dashboard copy rather than the Library source.

Tab identity must use stable document origin, such as dashboardId + dashboardQueryId/member ID, rather than the query name. This should integrate with the provenance and duplicate-name behaviour specified in #464.

Tile action UX

• Place the icon in the tile's own chrome, preferably at the top-right alongside other tile actions.
• Use a code/query or external-edit style icon with tooltip and accessible name: Open in Workbench.
• The action may be visually subtle until tile hover/focus, but it must remain keyboard discoverable and operable.
• Clicking it must not start tile drag, resize, selection, chart interaction, or other tile gestures.
• Render the action consistently in Dashboard View and Edit modes.
• For a genuinely queryless tile, omit or disable the action with an accurate explanation; do not open an unrelated query.

Navigation semantics

This is a document-opening action, not a generic Dashboard back button.

• Opening the same tile query repeatedly selects the existing Workbench tab.
• Different tiles that reference different Dashboard query documents open different tabs, even when their display names are equal.
• The Dashboard's current filters, layout, scroll position, and view/edit state should not be mutated by opening the query.
• Normal browser/history navigation may still be used to return to the Dashboard; no dedicated global < Query control is required.

Acceptance criteria

• The Dashboard header no longer renders the < Query button.
• Every query-backed tile exposes an Open in Workbench icon action.
• The action opens/selects the exact tile query in the main SQL editor.
• Tab reuse is based on stable Dashboard query origin, not display name.
• Saving from the opened tab updates the Dashboard query copy, not a same-named Library query.
• The action works in both Dashboard View and Edit modes.
• Pointer activation does not trigger drag, resize, chart, selection, or tile-body actions.
• Keyboard focus, activation, tooltip, and accessible naming are covered.
• Queryless tiles do not navigate to an arbitrary Workbench document.
• Tests cover two same-named queries in different Dashboards/tiles and reopening an already-open tile query.

Non-goals

• Keeping a generic Dashboard-to-Workbench back button in another location.
• Prefixing tab titles with full Dashboard names.
• Opening the original Library query when the tile owns a Dashboard copy.
• Changing tile query execution or Dashboard rendering behaviour.

[BorisTyshkevich]

Ship log — #471

Branch model: single-phase issue — one branch, one PR off main.

Merged 2026-07-26 as 3296390, closing this issue. Verified on merged main
(which also absorbed the #459 filter→variable rename touching the same files):
npm test 5630 passing with the per-file coverage gate met, npm run build clean,
npm run test:e2e 269 passing / 1 skipped on chromium + webkit — and every #471
test survived the conflict resolution.

Phase	Status	PR
1 — whole issue	shipped	#477

Handoff

• Landed: the Dashboard toolbar's < Query button removed; a per-tile
  Open in Workbench action on every query-backed tile card (both modes, both
  layout engines, including the grid engine's frameless KPI tiles); the mobile bottom
  nav returned to the Dashboard surface with only its Editor entry.

• Decisions taken (not in the issue body):

  1. No new tab-identity model. The issue proposes identity by dashboardId + dashboardQueryId, and Disambiguate duplicate query names in editor tabs by stable origin #464 proposes a QueryTabOrigin union. Neither was
     built: Separate Library queries from dashboard-owned query copies #427 already makes every panel tile reference a dedicated saved-query
     copy that exactly one member owns, and a tile's queryId is explicitly
     non-patchable (DashboardTilePatch: "tile identity is stable"). Since
     loadIntoNewTab dedups on savedId and commitSavedQuery resolves by id, tab
     reuse, two-tabs-for-same-named-copies and Save-targets-the-Dashboard-copy all
     hold by construction. A parallel origin field would be the second source of
     truth Separate Library queries from dashboard-owned query copies #427 refused. Disambiguate duplicate query names in editor tabs by stable origin #464 is left owning the visible half only (collision
     badges, origin tooltips) — recorded in a comment there and in roadmap Roadmap to 1.0.0 #68.
  2. Owner decision, taken in session and recorded here because it overrides one of
     this issue's own non-goals: removing the button strands a phone on a tile-less
     Dashboard, because the mobile rules hide the sidebar and the bottom nav for a
     full-bleed Dashboard (Add dashboard selection state and a full-size dashboard work surface #425/Add a Databases/Dashboards switcher and dashboard hierarchy tree #426 — Add a Databases/Dashboards switcher and dashboard hierarchy tree #426 restored the button for exactly this
     reason). Of three options offered (keep it only when there are no tiles / remove
     it and file the gap / remove it and give the bottom nav a Workbench entry), the
     owner chose the third. The nav now shows only Editor on this surface, which
     switches surface before selecting the panel and is not painted as the active tab.
     Full-bleed remains a width claim.
  3. Nothing to open renders no control — not a disabled one, and never one
     pointing at another tile's document. A text panel is queryless by capability
     (isQuerylessPanel) and an unresolvable queryId belongs to a tile already
     showing its own missing-query error.
  4. The action is not edit-mode chrome (unlike the grip/delete/resize beside it),
     because inspecting a tile's query is a View-mode act first. That forced the grid
     engine's KPI overlay head to reveal and accept pointer events in View mode.

• Deviations from the spec: none remaining. The first push left a flow-layout
  KPI band member without the action, on the grounds that .dash-kpi-member is
  display: contents and has no box. That was wrong: the repo already reaches through
  to the card for exactly this host (.is-nav-target > *, .dash-drop-target > *), so
  the action is anchored inside the member's first card — no layout or drag-geometry
  change, re-attached on each publish because renderKpiInto replaces that card.
  Flow layout's KPI band members have no delete, grip, resize or title chrome #475 is rescoped to the chrome still genuinely missing there (delete, grip,
  resize, title).

• Two bugs only a real browser caught (both in the ADR addendum, because they are
  the kind that gets reintroduced): the display: contents positioning above, and
  @media (hover: none) being evaluated by no test at all — a 360px desktop
  viewport still reports hover: hover.

• Three defects found by the review pass, all fixed on the branch: a press on the
  action swallowed after a drag released away from its card (pre-existing shape — the
  delete button had it too); two competing margin-left: auto items putting the
  action mid-head on an Edit-mode KPI tile; and that same KPI overlay staying
  invisible on touch in Edit mode because the hover: none override lost a
  same-specificity source-order contest.

• Follow-ups filed: Flow layout's KPI band members have no delete, grip, resize or title chrome #475 (flow KPI band has no per-tile chrome at all —
  no delete affordance either), A whitespace-only tile title survives into accessible names #476 (inbox: a whitespace-only tile title
  survives into accessible names; unreachable via shipped UI today, reachable the
  moment a rename-tile affordance ships). openSavedQuery switches surfaces before resolving the id, and stays silent when it fails #443 (openSavedQuery switches surface
  before resolving the id) is reachable from this new caller only inside the async
  window of a cross-tab delete, and the symptom is a surface switch with no new tab
  rather than an empty Workbench — left to openSavedQuery switches surfaces before resolving the id, and stays silent when it fails #443.

• Second review round (owner, against the first push) — three findings, all fixed
  on the branch and each sabotage-verified:

  1. Back returned the wrong Dashboard, at the top. The URL carries no Dashboard id
     (Add dashboard selection state and a full-size dashboard work surface #425) and opening a query disposes the surface, so adoptRouteMainSurface fell
     back to the compatibility Dashboard. Fixed with a per-entry history.state
     snapshot ({workspaceKey, dashboardId, currentMember, scrollTop}) plus a one-shot
     pendingScrollTop beside pendingFocus. This is the decision most worth
     knowing about for future work: history state, not the URL and not a session-wide
     "last Dashboard" memo — recorded in the ADR addendum with the reasoning.
     Restoring the offset is retried per publish, because at mount the grid is still
     empty and a single write clamps to 0.
  2. Flow KPI tiles now carry the action (see Deviations above).
  3. Keyboard activation could still be swallowed after a drag that released away
     from its card: clearing the suppression on the next pointerdown misses
     Enter/Space, which dispatches a click with no pointer event. The arming now
     self-disarms on a zero-delay timer. A timestamp window was tried and rejected — a
     fast Tab+Enter falls inside any safe window.

• Gate: npm test 5631 passing with the per-file coverage gate met
  (pretest covers check:schemas, check:arch, check:types); npm run build
  clean; npm run test:e2e 269 passing / 1 skipped across chromium + webkit
  (Firefox cannot launch in this sandbox — CI covers it).