Skip to main content

No. 3

Client shell redesign — canonical vocabulary, additive telemetry, unchanged contract

The Gnostikon client shipped a redesigned shell. The docs side publishes the canonical vocabulary, confirms the API is unchanged, and flags a cross-repo follow-up on chrome.* telemetry.

4 min read

The Gnostikon client shipped a redesigned shell in gnostikon-client#24. The visible change is structural — a persistent Rail, a contextual TopBar, an on-demand Inspector, and a default Today briefing replacing the old module launcher. The docs-side role here is narrow: publish the canonical vocabulary so future copy stays uniform, confirm the public API contract is unchanged, and flag the one cross-repo follow-up the redesign uncovered.

What visibly changed​

The navigation grammar shifted from a hidden drawer with a module launcher on the home route to a persistent, surface-divided shell:

  • The Rail is the persistent left-side navigation (desktop and tablet variants). Replaces the legacy drawer / hamburger menu.
  • The TopBar is the contextual top surface (scope, title, surface-specific actions).
  • The Inspector is the right-side detail pane that opens on-demand for the active selection.
  • The Today briefing is the new default home (/), composed of decisions, continue list, and pulse strip. The legacy module launcher remains reachable as a one-release fallback via /?legacy=1.
  • The Knowledge workspace wraps Index / Graph / Missing / Builder in a single horizontal tab strip under /knowledge/*. The bare /knowledge URL resolves to the Index tab.
  • The Command Palette (⌘K / Ctrl-K) and the Profile Drawer are the principal overlays.

The full vocabulary — definitions, legacy synonyms to avoid, and a back-pointer to the client source for every surface — lives at the Client shell vocabulary page. That page is the citable source going forward; copy in this post that mentions a surface name is a link, not a redefinition.

What stayed the same​

  • The public API contract. No /api/* endpoint was added, renamed, or reshaped by this redesign. See the API reference. Integrators have nothing to migrate.
  • The product-events taxonomy is preserved. The client introduces a new chrome.* family of seven events — emitted from chrome-events.ts — and the family is intended as additive — no existing event from x-005 is renamed and no existing payload is reshaped. See the registry note for the seven names.

Where the canonical vocabulary lives​

The Client shell vocabulary page is the citable source for every chrome surface — definition, legacy synonyms to avoid, and a GitHub back-pointer to the client source. A docs-side glossary exists because copy decay is real: without one citable source, prose drifts back to the old vocabulary the next time anyone writes a use-case page or a release note. PR reviewers should cite the page during review whenever copy mentions a client surface.

Open follow-ups​

  • Backend chrome.* allow-list. As of this post, none of the seven chrome.* event names appear in the backend allow_list.py. The events are emitted by the client but rejected at ingest with rejected_unknown_event, so they do not currently land in the canonical store. A backend PR is needed to add the seven names before analytics consumers can observe the family. The registry note tracks this gap.
  • Client cleanup (Spine fe-006). Residual chrome-migration cleanup (token discipline, gesture wiring, telemetry guard) ships under a separate Spine task and a separate client PR; out of scope for this docs review.
  • Shell screenshots in docs. The docs site does not host product screenshots today (static/img/ is brand and OG assets only). Producing 3-viewport captures of the new shell and finding the right editorial home for them is deferred to a separate visual-refresh task; the audit posture chosen here is "name the surfaces, link the source, defer the visuals."
  • Future renames trigger a follow-up dx-. If a future client release renames or restructures any canonical surface above, a follow-up dx- task is required to keep the glossary truthful. Any divergence between the glossary's back-pointers and the actual client source should be reported.

Mateus H.

Engineering · canonical layer

Notes from the canonical layer, in your inbox.

Engineering posts and field reports. No spam — unsubscribe in one click.