← Docs hub

UI reference

Every screen on the compiled site (llmwiki build → site/), what it shows, and how to reach it. The site is plain files — open site/index.html in a browser, or publish site/ to any static host.

Top navigation

Every page in the site carries the same header nav. Keyboard: ⌘K opens the command palette from any page.

Mobile: the six middle links collapse into a bottom-nav below 768 px; Search + Theme stay in the top bar.

Home

URL: /index.html

Queue-first landing page. Layout:

1. Automation — settings-only panel from .llmwiki/automation-status.json after install-automation (job, schedule, short Synth backend line with spend hint, Agent hooks, Watch on its own line, last-run log). For Maintain, a one-liner states the site refreshes once after summarization. No pipeline stage timestamps, lint outcome, lint-fail policy reminder, or installer Updated line here (#234).
2. Pipeline state — Home-only table mount (#llmwiki-state-widget, inlined on index.html) with two captioned tables: Eligible sources (Raw → To synthesize → Synthesized (by agent); caption notes On disk can exceed Raw for filtered/orphan pages; handled by shell commands — agent chips say … sessions; Documents is plain text, not a chip) and Knowledge layer (Candidates → Entities / Concepts). The first three columns count eligible sources (synthesize inputs), not markdown files or wiki pages — a document that fans out into several wiki/sources/ part-pages still contributes 1 (#81). A fifth On disk column counts .md files under wiki/sources/ (excluding _-prefixed names): sessions attributed per agent, Documents via raw/docs/ or raw-doc tags, plus a Stubs row (On disk only; other columns show "—") and an Other row when uncategorized non-stub pages remain. There is no under-table Source pages note. The Candidates header and count link to /candidates.html. Each eligible-sources cell is a single count; To synthesize adds estimated USD in parentheses when non-zero. Candidates counts pending stubs already under wiki/candidates/ (not the Candidates (pre-run state): harvestable figure from synth --estimate, which describes current wiki/sources/ before pending sources land). Entities / Concepts count trusted pages after promote. The eligible-sources Total row also shows queue queued / in progress counts and sums On disk. Under the Candidates knowledge table, a lint-error note appears when ops.last_lint_error is non-empty (console-shaped, pre-wrap, ~6 lines). Under the tables, shared collapse sections (llmwiki/render/collapse_section.py) cover Timeline (Oldest pending, Last sync / Last synth / Last build / Last lint with pass/fail, Last queue run — not Automation; no dead Last reflect), not-synthesized sessions/docs, Candidates to review (by kind + stale), Commands (runnable llmwiki … CLI rows + one-shot cd <llm-wiki-checkout> && claude|agent|codex "/wiki-candidates" — Gemini CLI is adapter-scaffold only, so no Home launcher), and estimate warnings.
3. Recent raw documents — newest raw/docs/ entries with title + source meta.

Numbers come from llmwiki-state.js (synth.pipeline + synth.pending + synth.estimate + ops.*), refreshed by llmwiki sync / llmwiki synth --estimate / successful synth and build stamps / lint (JSON + site data sidecar only — lint does not rewrite HTML). Every llmwiki build also recounts pending/stale candidates and trusted entity/concept page counts into synth.pipeline.to_review* / trusted_entities / trusted_concepts (cheap disk walk — #84) and copies the sidecar into site/llmwiki-state.js. llmwiki build still one-shot backfills synth.pipeline rows when the state snapshot predates that key (v1.4→v1.5 upgrade — #70). The session-analytics content (heatmap, stats, project grid) lives on Analytics.

Candidates

URL: /candidates.html

The review gate for pending stubs under wiki/candidates/ (#97). Two tables — Entities (pending) and Concepts (pending) — each with Name (title, slug and age), Description, and Decision.

Decision is a per-row select offering exactly the actions llmwiki candidates apply executes: Promote, Flip and promote, Merge into… and Discard. The last two reveal the field that action needs, and both fields are required before the row can be applied. Every row starts at No decision and stays there until you choose — deciding is browser state, so nothing runs and nothing is sent.

Apply sits in a bar above the tables that stays pinned under the site nav while you scroll, so it is in reach from any row. It assembles the rows you decided — and only those — into the command to run and the JSON batch to pipe into it, shown directly below the bar with Copy command and Copy JSON:

llmwiki candidates apply --vault <vault> --actions -

Merge into… reveals a filterable dropdown of every page merge --into resolves for that table — the trusted pages under wiki/<kind>/ first, then the same-table pending stubs. Press the ▾ button or ↓ to browse the whole list without typing, type any part of a name to narrow it (case-insensitive substring), ↑ / ↓ to move, Enter to choose, Esc to close. The list is the closed set of valid targets: text naming no page is marked as you type, and a row holding one is named on the page instead of going into a batch that would fail at the CLI.

Discard reveals a required reason. discard files that reason beside the archived stub, so a blank one throws the decision away — a row set to Discard with no reason is held back the same way an unresolved merge target is.

A row left at No decision is absent from the batch and stays pending, so a half-finished review can be applied and resumed. Apply refuses an empty batch; when a decided row is not yet executable it names the row, marks the field and moves focus to it, and emits nothing until you finish it. llmwiki candidates apply rebuilds site/ after a successful batch, so reload the page (or reopen the file) to see the remaining queue. Pass --no-rebuild if you are applying several batches and will llmwiki build once at the end. One-off CLI actions and /wiki-candidates do the same wiki work; only apply rebuilds.

Projects index

URL: /projects/index.html

Grid view of every project. Each card shows:

• Project name + slug
• Session count (main + sub-agent)
• Token total for the project
• Freshness badge (days since last session)
• Topic chips (from frontmatter topics: [])
• Agent badges (Claude / Codex / Copilot / Cursor / Gemini)

Clicking a card navigates to /projects/<slug>.html — the project detail page.

Project detail (/projects/<slug>.html)

• Hero — display name plus a Project kind chip, slug, created, updated, main-session and sub-agent counts. The chip is the same one a topic page carries, shown here because a project topic routes to this page instead, so the reader sees the kind either way. The two dates are the earliest and latest date across the project's own sessions, recomputed every build: project stubs carry no date of their own, so nothing is hand-maintained, and a project whose sessions all lack a date shows neither.
• Project summary (auto-synthesised from sessions)
• Connected topics — the topics this project co-occurs with, immediately above the session tables. Same list shape as on a topic page (topic name · shared-session count), and each entry routes exactly as it does everywhere else: ../topics/<slug>.html normally, ../projects/<slug>.html for a neighbour that is itself a project. The whole section is omitted — heading included — when the project's topic node has no connections, or when the vault has too few topics for the topic graph to be used at all.
• Sorted session table (date desc)
• Per-project activity heatmap
• Linked entities + concepts that appear across sessions
• Tool-call distribution bar chart

Sessions index

URL: /sessions/index.html

Sortable table across every project. Default sort: date desc.

Columns: Session · Agent · Project · Date · Cwd · Model · Msgs · Tools.

Filter bar at top: Project · Agent · Model · date range · slug substring (Clear resets; selections persist in sessionStorage for the tab).

Activity timeline above the filter bar — SVG sparkline of sessions/day across the calendar span. Hover, focus, or click a bar to show that day's date and count in the label (native tooltip too).

Clicking a row navigates to /sessions/<project>/<slug>.html.

Session detail (/sessions/<project>/<slug>.html)

• Frontmatter block — model, date, token counts, tool-call summary
• Summary — auto-synthesised 2–4 sentence abstract
• Key claims — bullet list
• Key quotes — blockquote pulls
• Conversation — full transcript, tool outputs collapsible (auto- expand on long blocks)
• Connections — [[wikilinks]] out to entities, concepts, related sessions
• Related — top-3 similarity matches (from heading/body n-gram)
• Download .md — nested sources/<project>/<stem>.md for AI-agent consumption

Models

URL: /models/index.html

Structured info cards for each AI model (per llmwiki/schema.py :: ModelProfile):

• Provider · release date · license
• Context window · max output
• Modalities (text / vision / audio)
• Pricing per 1 M tokens (input, cached_input, cache_write, output)
• Benchmark scores (GPQA Diamond, SWE-bench, MMLU, LiveCodeBench, etc.)

Graph

URL: /graph.html

Interactive force-directed knowledge graph. Details in reference/reader-api.md under the graph section.

What works:

• Pan / zoom (mouse / trackpad)
• Click a node → focuses its 1-hop neighbourhood; in topic mode it also opens the side panel, in page mode it opens the node's compiled page in a new tab
• Double-click a node → opens its page in a new tab — the topic page, or the project page for a topic that routes to one. Double-click is the only gesture that opens a new tab: the side panel's Open page →, its session links, and the right-click menu's Open all navigate in the current tab like every other link in the site
• Search input in the top-right → highlights matching nodes, dims the rest
• Orphan highlighting — nodes with zero inbound links get a red border
• Cluster toggle — group nodes by kind (the wiki/ folder behind each topic)
• Stats overlay (bottom-right) — total pages, edges, orphans, avg connections, top-5 hubs
• Dark / light theme mirrors the main site

Node colours. One colour per kind, at equal saturation — a topic no wiki page describes is a normal citizen of the map, not a faded placeholder. The legend renders one swatch per kind actually present in the graph, so a vault with no syntheses advertises no synthesis swatch.

Red is deliberately not a kind colour: the map already spends it on two states — the orphan border and a live search match — and a kind sharing it would read as an error.

Side panel (topic mode, single click) — topic name, Sessions, Connected topics, then the same identity facts the topic page carries: Kind, Active, Reviewed. Kind always renders, reading Unclassified topic when no wiki page describes the node; the two date rows are omitted when the node lacks the field, so a topic with no dates shows the counts and the kind rather than empty rows. Open page → follows, then the top connections and the bridging sessions.

Built-in assets: every graph.html ships with sibling graph-viewer.js and vis-network.min.js (pinned 9.1.9, vendored at build time and included in the installed package). The canvas works from the built static site over HTTP, file://, or fully offline — no unpkg fetch and no manual host step for vis-network. Offline fallback: if either companion script is missing or fails to load, the page shows an inline notice (#offline-notice) via script-tag onerror, a post-load watchdog when graph-viewer.js never runs, and a typeof vis check inside the viewer when the library alone is missing — not a blank canvas.

Topic pages

URLs: /topics/<slug>.html, /topics/index.html

A topic is a [[wikilink]] target found in wiki/sources/*.md, with spelling variants clustered into one canonical name. Topics are therefore not wiki pages: a topic exists because sessions cited the name, and a topic page renders whether or not any page under wiki/ describes it — an un-promoted candidate, or a name a reviewer declined, keeps its page indefinitely. Reach them by double-clicking a node in the Graph, from ⌘K (type:topic), from topics/index.html, or from the Connected topics list on any other topic or project page.

/topics/index.html lists every topic by reach — session count and link count per row.

Two thresholds decide which topics get a page: a topic mentioned by fewer than 2 sessions is dropped from the graph, and a vault yielding fewer than 5 topic nodes falls back to the page graph, in which case build writes no topic pages at all.

Layout

The title, then an identity line of ·-separated parts in this order — each date part dropped entirely when its source is absent, never filled with a placeholder:

Entity chip · Active 2026-01-09 – 2026-07-30 · Reviewed 2026-08-01 · 7 connected topics · 12 sessions · <slug>

The kind chip names the singular kind — Entity, Concept, Project, Synthesis, Source — or Unclassified topic when no wiki page describes it. The chip is never dropped: the absence of a backing page is itself a fact, and a missing chip would leave a reader unable to tell an unclassified topic from a page that failed to render one. Below the identity line:

• Also tagged as — the alternative spellings sessions used before clustering merged them under this name.
• Page content — the backing wiki page's body (see below). Absent when no page backs the topic or the page records nothing.
• Connected topics — topics sharing at least one session, strongest first, each with its shared-session count. Renders No connected topics. rather than disappearing.
• Sessions — every session mentioning the topic, linked to its compiled session page; a session with no compiled page is listed as text marked (no page).

Where each fact comes from

This is the distinction to keep straight: sessions supply reach and activity, the topic's own wiki page supplies kind, review date and content. Neither substitutes for the other, and neither is invented.

A topic with no backing page therefore shows no review date and no content, and its chip reads Unclassified topic — and one whose page omits last_updated shows no review date even while sessions supply activity dates.

Page content

The topic page is the only browsable surface for entity and concept pages, so it renders their content above the link lists. What survives is everything after the page's own leading # H1, minus ## Connections, ## Sessions, and ## Sources — the topic page renders Connected topics and a collapsible Sources evidence list (Sessions vs Documents) itself from the graph, so the page's hand-written versions would only duplicate them.

• Heading-agnostic. Nothing is keyed to ## Key Facts; a renamed, reordered, or newly added section reaches the reader as written, as does introductory prose sitting above the first heading.
• No empty sections. A heading with nothing under it is dropped rather than rendered as a bare heading — innermost first, so a ## whose only child ### was itself empty goes too.
• [[wikilinks]] resolve. A target naming a topic links to wherever that topic resolved (its topic page, or the project page a project topic routes to); a target naming a session with a compiled page links to it; anything else degrades to the plain text it wrapped rather than a dead link. Code spans and fenced blocks are left exactly as written — a page documenting wikilink syntax keeps its example.

Project topics route to the project page

A topic backed by a page under wiki/projects/ links to /projects/<slug>.html — the full project detail page with its heatmap, session cards and charts — rather than to a thin topic page. The rewrite is applied once at build time and every surface honours it: the map's double-click target, the search index entry, Connected topics lists on topic pages and on project pages, topics/index.html, and [[wikilinks]] cited inside page content.

The match itself identifies which project it is, so an alias spelling routes as correctly as the canonical one. The rewrite is skipped when the build wrote no page for that project: wiki/projects/ is seeded from stubs while site/projects/ comes from session groups, so a project page with no recorded sessions keeps its ordinary topic page rather than being handed a link that 404s.

The type: vocabulary on the backing wiki page, and the origin of every frontmatter field, is Page kinds.

Docs hub

URL: /docs/index.html

The editorial entry point — you're reading a page compiled from the same pipeline. Covered in detail by tutorials/01-installation.md onward. See also style-guide.md.

Prototypes hub

URL: /prototypes/index.html

Review-ready UI states for UX iteration before larger UI changes touch the live templates. Six states:

Every prototype carries a 4 px #7C3AED top stripe and a "Prototype — not a live page" meta block so reviewers never confuse them with real pages.

Recent

URL: /recent.html

Newest raw documents first, one row per logical document — chunked docs (<slug>-01.md … <slug>-NN.md in one folder) collapse into a single row with a part count. Each row shows title, date, and origin source, and links into the Home tree browser.

Analytics

URL: /analytics.html

Session analytics plus usage-led wiki value (#52) and the candidates review gate (#84). The page opens with a hero line (main sessions · sub-agent runs · projects) and a row of stat cards — tokens (total + per-session average over sessions with token data, labeled e.g. 10.0K / session (4 with token data); cumulative billed throughput including cache_read, not context-window occupancy — #223), best cache hit, heaviest project by tokens, and heaviest project by MCP usage.

Below that, sections appear in this order:

1. Candidates to review — pending stubs under wiki/candidates/ (total + by kind) and stale count (default ≥30d). Heading / pending count link to /candidates.html. Zero is intentional signal: synthesize-only vaults still show that the review gate exists and is empty.
2. Activity — ~18-month GitHub-style heatmaps: Agents Activity (session counts), Wiki MCP calls, and — when telemetry carries signal — Session-page reads and Doc-page reads split from wiki_read_page hits.
3. Recent activity — last entries from wiki/log.md (including producer breakdown lines such as Processed: 2 Claude · 1 Cursor).
4. Projects — filterable card grid (session counts, date range, topic chips) linking to per-project detail pages.
5. LLM-Wiki MCP usage — merged value block and MCP table in one section (MCP telemetry only, not file:// browsing): retrievals · writes · answer rate · payoff-per-page · distinct attributed projects; optional synthesis cost line; sessions vs documents corpus/read mix; top-earning pages; Dead stock as a shared count-badge collapsible listing every unread synthesized source (collapse_section); per-tool calls, items returned, and zero-hit rate. The live surface is six tools (#196); retired names in historical logs are folded into canonical rows at aggregation time — see mcp.md.

There is no daily bar chart — trends are read from the heatmaps. Durable counts and series are described in reference/state-persistence.md.

Command palette (⌘K)

Press ⌘K (or Ctrl+K on Linux/Windows) from any page.

• Fuzzy match over every page title + body — including topic pages (type: topic) and their alias spellings (#50).
• The badge on each result reads its kind when the entry carries one and its type otherwise, so a topic result says Entity, Concept, Project … — or Unclassified topic — matching what the map and the topic page call it (#108). The underlying type is unchanged.
• Top result on Enter navigates.
• Shows facet chips: Project, Entity type, Lifecycle, Confidence, Tags — click a facet to filter.
• Footer shows the current mode (flat / tree) from search-index.json._mode and the deep-page ratio (see reference/cache-tiers.md for the tree-mode heuristic).
• Keyboard: ↑ / ↓ navigate, Enter open, Esc close.
• Filter by type: type:topic / type:session / type:project / type:docs / type:document / type:slash / type:page. type:topic still matches every topic result whatever its badge says — the badge reads kind, the filter reads type.

Search index + chunks

Two levels:

• site/search-index.json — ~7 KB meta index (projects, static pages, documents, docs, slash commands, topics) + chunk manifest + facet counts + mode badge.
• site/search-chunks/<project>.json — per-project session entries with title, url, type, project, date, model, body, heading_max_depth, heading_count_by_depth.

Topic entries (type: "topic") point at topics/<slug>.html — or at projects/<slug>.html for a topic that routes to a project page; their body includes session count plus also: … aliases so a query using any non-canonical spelling still hits the right page, and their kind carries the human-readable singular label the palette badge shows (Entity, Concept, Project, … or Unclassified topic). kind is present on topic entries only. The same payloads ship as .js sidecars for file:// (#20).

The palette lazy-loads chunks as the query narrows. See reference/reader-api.md for the stable shape.

AI-consumable exports

Every session page links to a nested markdown copy for agents:

• sources/<project>/<stem>.md — raw session markdown (same as the page Download .md button)

Site-level exports AI agents should start with:

Keyboard shortcuts

Press ? on any page to see the shortcuts modal. Current set:

Theming

Site-wide CSS lives in llmwiki/render/css.py. All tokens inherit from the brand system — see ../design/brand-system.md.

Theme toggle (top-right): light / dark, persists via localStorage.theme. System preference (prefers-color-scheme) is honoured when no override is set.

Accessibility

WCAG 2.1 AA targeted across the whole site. Specifics in ../accessibility.md. Notable:

• Every image has an alt attribute
• Skip-to-content link appears on every page on keyboard focus
• Focus ring uses the accent colour with 2 px outline + 2 px offset
• prefers-reduced-motion honoured (all transitions collapse to 0.01 ms)
• Muted text hits ≥ 4.8:1 contrast in light and ≥ 6.9:1 in dark

Related

• CLI reference — every python3 -m llmwiki … subcommand.
• Slash commands reference — the /wiki-* surface.
• Reader API contract — stable shape of every file the build writes.
• Reader-first article shell — opt-in Wikipedia-style layout for individual pages.