Skip to content

GUI consistency: the command palette is not fed by the nav registry — 19 destinations unreachable from ⌘K #17561

Closed
#17971
Closed
GUI consistency: the command palette is not fed by the nav registry — 19 destinations unreachable from ⌘K#17561
#17971
Labels
area: frontend-unificationWave 4 · cluster B — Frontend unification & design systembugSomething isn't workingfrontendpriority: high

Description

@mrveiss
mrveiss
opened on Sep 26, 2026

Part of #12730. Topically adjacent to the shared-kit umbrella #14774, but this is shell wiring, not a primitive.

Problem

autobot-frontend has a navigation registry and a command palette, and they share nothing.

  • src/config/navItems.ts holds 19 typed entries — { to, labelKey, icon | iconPaths, iconViewBox, iconRule, iconStroke, featureFlag } — imported by src/App.vue and src/router/index.ts.
  • src/components/CommandPalette.vue builds its own list at line 130: 4 commands, all of them "create" actions (new-task, new-research, new-code, new-analysis).

So none of the 19 navigable destinations is reachable from the palette. Adding a page to the sidebar does not add it to ⌘K, and nothing fails when it does not — the divergence is silent by construction.

Second, narrower gap: NavItem has no keyword field, so even once entries are fed in, palette search can only ever match the translated label. A user who thinks "visitors" or "pipeline" will not find Analytics or CRM.

Approach

  1. Derive the palette's navigation section from navItems, so the registry is the single source and the palette keeps only its own action commands.
  2. Add keywords?: string[] to NavItem — translatable like any other user-facing string, so the keys land in all 11 locales.
  3. Respect featureFlag when projecting entries into the palette, so a flagged-off page is not offered.
  4. Add a test that asserts every navItems entry is reachable from the palette — the guard is the point; without it the two lists drift again.

Acceptance criteria

  • CommandPalette.vue contains no hand-written navigation entry; its nav section is computed from navItems.
  • NavItem declares keywords?: string[], and palette search matches against it.
  • A featureFlag-disabled entry is absent from the palette (test).
  • A test fails if a navItems entry is not offered by the palette.
  • Any new keyword strings exist in all 11 locales.

Implementation Order

Wave: 1
Depends on: —
Unblocks: —

Evidence

src/config/navItems.ts (19 entries) · src/components/CommandPalette.vue:130 (4 commands) · src/App.vue, src/router/index.ts (the only two importers of the registry).

Found during a comparative GUI-standardisation audit — see docs/research/dashboard-shell-and-component-standardisation.md, gap G5.

Activity

  1. mrveiss
    added
    bugSomething isn't working
    priority: high
    frontend
    area: frontend-unificationWave 4 · cluster B — Frontend unification & design system
    on Sep 26, 2026
  2. mrveiss
    added a parent issue on Sep 26, 2026

  3. mrveiss commented on Sep 26, 2026

    @mrveiss
    mrveiss
    on Sep 26, 2026
    OwnerAuthor

    Second GUI: the same gap, one degree worse

    This issue was filed after auditing autobot-frontend only. autobot-slm-frontend has the same divergence in a stronger form:

    • A third nav registry. autobot-slm-frontend/src/components/common/Sidebar.vue:59 declares const navItems: NavItem[] inline — 14 entries, shape { name, path, icon, showBadge }. That is a different shape from autobot-frontend/src/config/navItems.ts ({ to, labelKey, icon | iconPaths, iconViewBox, iconRule, iconStroke, featureFlag }), and it lives inside a component rather than in config.
    • No command palette at all in the SLM GUI — so there is nothing for its 14 destinations to be unreachable from, yet.

    So the target is one registry shape in the shared kit, consumed by both sidebars and both palettes — not two registries each feeding their own palette. Concretely: the kit owns the NavItem type (including the keywords?: string[] this issue adds and a badge field, which SLM already needs for showBadge), each GUI supplies its own entry list, and one palette component consumes whichever list it is given.

    Revised scope: the acceptance criteria above hold for autobot-frontend; add that NavItem lives in libs/autobot-ui, that autobot-slm-frontend/src/components/common/Sidebar.vue consumes it rather than declaring its own, and that its 14 entries move out of the component into config.

    Owner rule 2026-09-26 — "there should not exist any local overrides and design system needs to be enforced" — a nav-item type declared locally in a component is the same class of local override as a colour declared locally.

  4. mrveiss
    added 3 commits that reference this issue on Sep 26, 2026

    docs(research): dashboard shell and GUI-element standardisation audit (…

    1cd6607

    docs(research): dashboard shell and GUI-element standardisation audit (…

    7b82c24

    fix(theme): one themed source for notification colour, and a ratchet …

    4bdabba
  5. mrveiss
    added 2 commits that reference this issue on Oct 4, 2026

    feat(shell): the command palette is fed by the nav registry, and one …

    9c5ac80

    fix(shell): review round -- safe-area clamp for the canvas context me…

    455257d
  6. mrveiss
    closed this as completedin #17971on Oct 4, 2026

  7. mrveiss commented on Oct 4, 2026

    @mrveiss
    mrveiss
    on Oct 4, 2026
    OwnerAuthor

    Delivered by #17971 (merge 90729b5999). Verified against origin/main:

    • CommandPalette.vue contains no hand-written navigation entry; its nav section is computed from navItems.
      • navCommands maps paletteNavItems(userStore.isAdmin) (config/navItems.ts:154). This is primary nav plus profile menu plus, for admins, the admin menu, feature-flag filtered.
      • The only literal entries left are the 4 agent actions.
    • NavItem declares keywords?: string[], and palette search matches against it.
      • navItems.ts:58. filteredCommands matches cmd.keywords.
      • Test: finds an entry by a translated keyword its label never says ("visitors" → Analytics).
    • A featureFlag-disabled entry is absent from the palette (test).
      • leaves out an entry whose feature flag is off, and offers it once on (components/__tests__/CommandPalette.nav.test.ts).
    • A test fails if a navItems entry is not offered by the palette.
      • offers every nav-registry entry, admin entries included for an admin.
    • Any new keyword strings exist in all 11 locales.
      • nav.keywords.* is in all 11 locales, with no value identical to English; the i18n untranslated ratchet passes.
  8. neoneye
    added a commit that references this issue on Oct 4, 2026

    feat(shell): the command palette is fed by the nav registry, and one …

    90729b5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: frontend-unificationWave 4 · cluster B — Frontend unification & design systembugSomething isn't workingfrontendpriority: high

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions