Refactor File menu for multi-Dashboard creation, import, and export

[BorisTyshkevich]

Related to #430 and follows the unified File menu from #452.

Problem

The File menu now shows workspace, Library, and Dashboard operations in one stable list, but its Dashboard behaviour still assumes that one exact Dashboard is already open:

• there is no New dashboard… command;
• Import Dashboard… is disabled on the Query surface with “Open a dashboard”;
• importing may target or replace an exact open Dashboard instead of adding a new Dashboard to the workspace;
• Export Dashboard… is unavailable unless an exact Dashboard is open, even when the workspace contains Dashboards that could be selected.

That interaction model no longer fits a workspace that can contain multiple Dashboards. The global File menu should manage workspace documents without requiring the user to navigate to one first.

Product decisions

Menu order

Use this stable order on every surface:

New workspace…
New dashboard…
────────────────────────
Import workspace…
Import queries…
Import dashboard…
────────────────────────
Export workspace…                  .json
Export dashboard…                  .json
────────────────────────
Download Library as Markdown       .md
Download Library as SQL            .sql
────────────────────────
<N> Library queries · <M> dashboards

Use sentence case consistently: dashboard, not Dashboard, inside menu labels.

The existing rule remains: surface and workspace context may change enabled state, reason text, or a command’s resolved target, but must not hide or reorder rows.

New dashboard

Add New dashboard… immediately after New workspace….

Behaviour:

1. require a writable current workspace;
2. ask for the Dashboard name using the existing anchored dialog/menu primitives;
3. trim and validate the name;
4. mint a stable Dashboard id;
5. append a new empty Dashboard document to the latest committed workspace aggregate;
6. preserve all existing Dashboards and queries byte-for-byte;
7. commit through app.mutateWorkspace / the repository validation path;
8. open the new Dashboard in Dashboard Edit mode after a successful commit.

Rules:

• duplicate display names are allowed; identity is the Dashboard id;
• Cancel and Escape commit nothing;
• a failed commit leaves navigation and local state unchanged and surfaces the diagnostic;
• do not create a compatibility replacement or overwrite dashboards[0];
• do not create any saved query, panel, variable configuration, or Library entry.

Disabled reason:

• no writable workspace: No workspace or the repository’s established unavailable wording.

Import dashboard

Redefine Import dashboard… as an additive workspace operation:

Import one portable Dashboard as a new Dashboard in the current workspace.

It must no longer require an open Dashboard and must be available from Query, Dashboard View, Dashboard Edit, and the empty-Dashboard placeholder whenever a writable workspace exists.

Behaviour:

• decode and validate the portable bundle before committing;
• select the Dashboard from the bundle when the format can contain more than one;
• import the selected Dashboard as a new Dashboard document;
• remint local Dashboard identity when required by the import contract;
• import or reconcile its dependent queries through the existing conflict planner;
• never replace or merge into the currently open Dashboard implicitly;
• open the imported Dashboard in Edit mode after a successful commit.

If replacement/merge is needed later, expose it as an explicit Dashboard-context operation rather than overloading the global File command.

Disabled reason:

• no writable workspace: No workspace.

Remove Open a dashboard, Edit mode only, and exact-open-Dashboard targeting from this command.

Export dashboard

Make Export dashboard… workspace-aware rather than surface-gated.

Behaviour:

• zero Dashboards: disabled with No dashboards;
• one Dashboard: export that Dashboard directly;
• multiple Dashboards with an exact Dashboard currently open: preselect that Dashboard;
• multiple Dashboards with no exact Dashboard open: show a Dashboard chooser;
• the chooser lists Dashboard names and enough secondary identity to distinguish duplicate names;
• export uses the existing portable bundle builder and includes the selected Dashboard’s dependency closure;
• export is available in both Dashboard View and Edit modes and from the Query surface.

The selected export target must always be exact by Dashboard id. No fallback to the first Dashboard is allowed.

Menu model and UI

Update src/core/file-menu-model.ts and src/ui/file-menu.ts so the pure model remains the sole authority for:

• row order;
• separators;
• labels and extensions;
• enabled/disabled state and reason text;
• whether export can resolve directly or requires a chooser.

Add a new action id for new-dashboard and choose a Dashboard/add icon distinct from new-workspace where practical.

The footer remains:

1 Library query · 1 dashboard
2 Library queries · 3 dashboards

with correct singular/plural forms at every count, including zero.

Tests

Cover the File-menu model and UI for:

• Query, Dashboard View, Dashboard Edit, empty collection, unresolved Dashboard selection, missing workspace, one Dashboard, and multiple Dashboards;
• identical row order on every surface;
• New dashboard… availability and successful append/navigation;
• duplicate Dashboard names with distinct ids;
• cancelled and rejected creation;
• additive import from every surface;
• import preserving existing Dashboards;
• zero/one/many export targeting;
• chooser preselection from the currently open Dashboard;
• exact-id export with duplicate names;
• no fallback to dashboards[0];
• keyboard operation, focus return, Escape, and outside-click dismissal;
• current footer counts and grammar.

Acceptance criteria

• The File menu contains New dashboard… in the agreed stable position on every surface.
• Creating a Dashboard appends it to the current workspace and opens it in Edit mode.
• Import dashboard… is additive and does not require an open Dashboard.
• Export dashboard… works from Query and Dashboard surfaces and selects an exact Dashboard safely.
• Existing Dashboards and Library queries are never overwritten by implicit fallback behaviour.
• Menu rows do not appear, disappear, or reorder when the work surface changes.
• npm test, npm run check:arch, and relevant Chromium/WebKit E2E tests pass.

Non-goals

• A permanent + button in the Dashboards sidebar header; this issue establishes the canonical command first.
• Dashboard rename, duplicate, or delete commands.
• Importing into or replacing an existing Dashboard.
• Changing workspace import/export semantics.
• Changing Library download formats.

[BorisTyshkevich]

Ship log — #463

Single-phase issue; one PR off main.

Phase	Status	PR
1 — whole issue	in review	#482

Handoff

• Landed: new-dashboard action + name-prompt dialog; additive
  Import dashboard… on every surface; workspace-aware Export dashboard… with
  an exact-id target or a chooser; menu regrouped by verb behind three
  separators; Dashboard labels in sentence case.
• Decisions taken (not in the issue):
  • "multiple Dashboards with an exact Dashboard currently open: preselect
    that Dashboard" reads two ways. Owner chose: export it directly, no
    chooser — exporting the Dashboard you are looking at stays one click. The
    chooser appears only when no exact Dashboard resolves. The model expresses
    this as DashboardExportTarget = {kind:'exact', dashboardId} | {kind:'choose'}.
  • FileMenuContext.dashboardCount became dashboardIds: readonly string[].
    Export must name an exact target, and a bare count cannot do that without the
    caller reaching back into the aggregate and re-deciding there — which is the
    dashboards[0] fallback the issue forbids. The footer count is the list's
    length.
  • New dashboard defaults the prompt to Dashboard (the title
    createEmptyDashboard already stamped) and refuses a whitespace-only name by
    disabling the confirm button, so no caller has to defend against an untitled
    Dashboard.
  • The export chooser's secondary identity is <N> tiles · <last 6 chars of the id>; tile count alone cannot separate two empty Dashboards with the same
    name.
  • Export is also gated on a resolved workspace: the workspace-not-found surface
    can still be projecting state.dashboard from the workspace the user left.
• Owner feedback on the served build (applied as more commits on the same PR):
  creating a Dashboard from the Query surface opened it but left the upper
  sidebar on Databases, so the tree that lists and selects it stayed hidden.
  revealDashboard now opens in Edit mode and sets
  state.upperRole = 'dashboards'; Import does the same.
• Review round two:
  • Export re-read app.state.workspaceId after awaiting the write flush.
    Dashboard ids are unique within a workspace, not across them, and an imported
    workspace keeps its exported ids — so switching workspace mid-flush let an
    exact-id lookup succeed against the new one. The workspace is pinned when the
    export is chosen (chooser included); the degraded state fallback applies
    only while it is still current. exportWorkspaceAction carries the same pin.
  • The chooser never moved focus in and the shell trapped no Tab. The picker now
    focuses its first row; openDialogShell wraps Tab inside the card and skips
    disabled controls.
  • A fixed six-character id tail is not a tiebreaker (sales-abcdef /
    ops-abcdef), so the pure shortIdFragments widens it until every listed
    fragment differs, falling back to the whole id. The import chooser shows one
    too — reminting after import does not stop the id identifying the SOURCE
    documents while the user is choosing.
• Review round three:
  • currentWorkspace() folded state.dashboard back through the compatibility
    slot. Add dashboard selection state and a full-size dashboard work surface #425 made that projection the SELECTED Dashboard, so [A, B] with B on
    screen rebuilt as [B, B] — a real data loss on the DEGRADED export path
    (blocked/quota/private-mode IndexedDB), which is the recovery route. It now
    folds back by exact id, leaves the committed collection alone for a
    projection that names no stored entry, and seats the projection only when
    nothing is stored. file-menu.ts no longer references the compatibility slot.
  • The export pin covered contents but not the FILE NAME, which was still read
    from live state after the flush. DashboardExportRequest carries
    workspaceName; both exports name themselves from committed truth when it
    loads and the pinned name otherwise (the same fallback an empty Dashboard
    title uses).
  • The Export row kept the target resolved when the menu OPENED. A cross-tab
    refresh does not close an open menu, so a choose whose Dashboards were all
    removed opened an empty chooser and threw on rows[0].focus(). The row now
    re-resolves through liveContext + fileMenuModel on activation (gone →
    toast, one → direct, many → chooser).
• Deviations from the spec: none. The removed
  dashboard-import-target-stale / dashboard-import-collection-not-empty
  diagnostics went with the targeting they guarded — an append has no target that
  can go stale.
• Deferred acceptance criteria: none — all claimed.
• Follow-ups filed: Reconcile the two Dashboard-creation paths behind one action #481 (inbox) — the empty-Dashboard placeholder's
  Create dashboard button is now a second Dashboard-creation path with
  different UX (no name prompt) and a different write primitive
  (withCompatibilityDashboard, not appendDashboard). Safe today, but it is
  the CLAUDE.md rule-5 second-consumer case; deferred because Refactor File menu for multi-Dashboard creation, import, and export #463's non-goals
  cover the adjacent rename / sidebar-+ work.
• Verification: npm test (5661), tsc --noEmit, check:arch, build,
  Playwright chromium + webkit (269 passed; Firefox cannot launch in this
  sandbox). Live-verified end to end against the served build — create, duplicate
  name, direct export, re-import (appended and opened in Edit), the chooser with
  three identically-named Dashboards, and focus return to the File trigger.