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.
SourcesPanel — the Ask workspace’s drawer view (CONTEXT.md: Sources
view, Source reader): a ranked per-turn source list that
reveals the full note — the retrieved section highlighted — in an inline
preview, without leaving the answer.
ThreadPanel — the editor area’s Ask-workspace content (see CONTEXT.md:
Ask workspace, Thread). Owns the conversation Thread,
the docked question composer, and the live RagClient (when the Kimün
server can answer questions).
AttachmentView — the read-only surface the editor area shows when an
Attachment is opened (see CONTEXT.md), in place of the text editor.
Renders the attachment’s metadata plus, for text files, a scrollable
preview of its content; binary files show metadata only. It never edits:
the attachment’s verb is open externally (FollowLink, default Ctrl+N),
handled by the editor screen.
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.
The CFG drawer view as a component — the same shape as its sibling
views (Tags/Links/Outline), so DrawerHost’s dispatch stays uniform: one
arm per view, never inline view logic in the host.
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”).
Shared text helpers for the note-preview surfaces (the Query panel’s context
preview and the note browser’s preview pane). Both highlight query needles in
a note’s body and wrap long lines; the case-insensitive matching is the one
piece that is both subtle (must stay on character boundaries for every
non-ASCII case fold) and was previously implemented twice — once correctly,
once dropping highlights for length-changing folds. It lives here now; each
surface keeps its own span styling.
The Query panel’s note-preview: the expand state machine (Collapsed →
Context → Full), the content scroll (anchored vs user-owned), and the
content render. Lifted out of the panel so the scroll/anchor logic — the
subtle part — is testable on its own, without a vault, a SearchList, or a
Frame. The panel composes one of these and feeds it the selected note’s
text + highlight needles; the panel keeps owning the list and the engine’s
wheel-routing region (set_content_rect).
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.
Semantic search surface (P4): a server-backed RowSource that queries the
RAG server for similar chunks and lists the matching notes. Lives behind a
drawer view; only usable when a server is configured and reachable.
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.
Put text on the OS clipboard and flash the outcome: done_msg on
success, "clipboard: {e}" on failure. The seam for every OS-clipboard
write in the TUI — list-row yanks, ask answers and sources, and the editor’s
own Ctrl+C/Ctrl+X.