Home dashboard

Home dashboard

The Web workspace can open a home note as its landing view instead of the search screen, and any note can embed dashboard widgets — a recent-notes list, today's journal shortcut, and pinned links — that render both in the live workspace and on this published site.

Back to track.

A home note

Point the workspace at a landing note in your vault config:

# <vault>/.track/config.yml
web:
  home: Home

home takes a note title or a numeric id. When set, track web opens that note at / instead of the search hero. Leave it unset to keep the search home. web.home is a vault setting: it lives in the vault config, so the landing note travels with the notes it points at. A published site has a home of its own — see "The published site's config" below.

Dashboard widgets

Fence a block with dashboard — the same way a mermaid fence draws a diagram — and fill it with a small YAML config:

```dashboard
recent: 5          # a list of the 5 most-recently-updated notes
journal: true      # a shortcut to today's journal
pinned:            # notes you want one click away
  - Syntax
  - Web workspace
```

Every field is optional. The engine resolves the block to ordinary Markdown — bulleted [[wiki links]] under a heading per widget — so it renders identically in the live workspace (resolved on each view, so the recent list stays current) and in this static export (resolved at build time). Because the widgets are just links, they get hover previews, backlinks, and navigation for free.

Here is a live one, resolved from a real dashboard block:

Recent notes

• Babel
• Block links
• Charts
• CLI

Pinned

• Syntax
• Web workspace

Note icons

An icon can sit beside a note's title in search results — in the live workspace and on a published site alike; that is the one surface that draws it today. It is note-level metadata, so it never lives in the body: it is the note's sidecar icon, or a mapping in the vault config.

Map an emoji to a tag or a note kind in your vault config (<vault>/.track/config.yml):

icons:
  tags:
    idea: ��
    book: ��
  kinds:
    journal: ��
    note: ��

The first of a note's tags that has a mapping wins; otherwise its kind's mapping applies. A single note can override both from the command line — or in the metadata editor (the web Meta dialog's icon field, the icon: line in the Neovim :Track meta popup), which edits the same sidecar value:

track meta --title "Reading list" --icon ��

Precedence is simple: a per-note --icon override beats a tag mapping, which beats a kind mapping. Set an empty --icon "" to clear the override and fall back to the mapping. Icons are cosmetic — they never change a note's title, id, or how [[links]] resolve.

What the site says about itself

A published site is a vault, so everything it says about itself it already had somewhere: each page's icon, tags, cover image, props, and parent live in that page's sidecar, and the site-wide settings live in the vault config that travels with the vault (<vault>/.track/config.yml). Nothing is read from the machine publishing it — the same vault has to publish the same way on your laptop and in CI.

# <vault>/.track/config.yml
journal: false       # a vault kept in a repository wants no day-by-day record of when it was worked on
gen: false           # ...and no snapshot of every past state
web:
  home: track        # the landing note, live and published alike
  icon: assets/logo.png   # the published site's brand mark and favicon
icons:
  kinds:
    note: ��

• web.home is the landing note — the workspace opens on it, and the published site lands on it. It names a note by title or id. export-site --root <id> still overrides it, but there is no need: a site's front door is the same wherever it is deployed, so it belongs with the content.
• web.icon is the site icon: one image, a path relative to the vault root. The published site shows it as the top-left brand mark and derives the favicon from the same file — no second asset. Leave it unset to keep the built-in track mark. A configured icon that is missing fails the build.
• icons takes tags and kinds, consulted by the one resolver in the precedence above.
• journal: false / gen: false turn off what a vault otherwise accumulates on its own. Both are worth setting on a vault you publish or commit: the journal tree records which days its author worked, and .track/gen/ keeps a copy of every past state.

Unknown keys are a build error naming the file and the key — as is a second --- document, which a single decode would never read — not a silent drop: a mistyped key in a config you only exercise at publish time would otherwise ship the wrong site without a word.

What is not site config: --base-url, --out, and --frontend. They describe one build of the content, not the site — where the output is written, which frontend build goes into it, which origin it is served from — and this one docs/help vault is published twice, to GitHub Pages and, for every pull request, to a preview URL. So they stay build flags.