The Activity Rail — the fixed-width icon strip on the far left of the
editor screen. Each cell names a drawer view; the active cell shows a
green edge bar and green glyph. CFG is pinned to the bottom.
The command palette (spec §6: ›-prefixed telescope scope): a fuzzy
list of every leader-tree command. Selecting one executes its
LeaderAction — the palette is a labelled door onto the same actions
the leader sequences fire, never a second implementation.
Directory-only browser state shared by the Preferences screen and the
Onboarding screen. Pure navigation state — each host renders it and
routes keys itself.
The Drawer — the single panel between the activity rail and the
editor. It renders whichever rail view is active: the file browser
(FILES), the Query panel (FIND), or a placeholder for the views that land
in later phases (TAGS, LINKS, OUTLINE, CFG).
The phase-03 drawer views: TAGS, LINKS, and OUTLINE — each a
thin adapter (ListPanelSpec + a RowSource) of the shared
QueryListPanel body, over core’s vault API. Rebuilt on demand
(refresh) — the same engine-per-context pattern the sidebar uses per
directory.
The hint registry — the one place that turns a focus/cursor context
into the key hints the status bar shows. Each surface still declares its
own context hints (hint_shortcuts); this module owns the global hints
(always-on actions, right-aligned on status line 1) and the shared Hint
shape. The leader engine and which-key overlay (phases 05/06) will read
from here so hint text never forks from the actual bindings.
The Overlay trait and its supporting types — the contract every editor
overlay (note browser, Saved Searches modal, or dialog) implements so the
OverlayHost can route input / app-messages / render to it uniformly.
The Panel seam — the persistent editor-screen surfaces (activity rail,
drawer, editor) behind one interface, the persistent-surface counterpart to
the Overlay trait. See CONTEXT.md (“TUI surfaces”).
Query syntax highlighting (spec §9): maps core’s query token spans
onto theme roles. Reused by every query input — the FIND drawer now, the
telescope modal in phase 08 — so the coloring rules live exactly once.
QueryListPanel — the one body shared by every list-shaped drawer view
(TAGS, LINKS, OUTLINE): an optional filter input over a SearchList,
with submit / right-click behavior injected through ListPanelSpec.
Query variables: {name} placeholders the TUI resolves to runtime
values before a query reaches core (see CONTEXT.md “Query variable”
). Core’s query language never sees these.
The saved-search breadcrumb shared by the Query panel and the Ctrl+K note
browser: which saved search the current query came from, with a • edited
marker once the live query diverges (any text divergence counts, including
the order directive — the stored query is saved verbatim). Sticky
provenance — it survives edits, and is dropped only when the query becomes
blank (host-defined: an empty field, or the panel’s default backlinks
query) or another saved search is expanded.
The which-key overlay (spec §8b) — the popup docked above the status
bar that documents the pending leader sequence. It renders the node the
LeaderEngine currently sits on, so it can never drift from the tree:
same data, two surfaces.
Centre a popup occupying percent_x% × percent_y% of area.
A centered rect of fixed cell size, clamped to r — the counterpart to
the percentage-based centered_rect for dialogs with intrinsic sizes.