@aitne-sh/aitne 0.1.7 → 0.1.9

package/agent-assets/docs/features/wiki/dashboard.md

@@ -0,0 +1,255 @@
+---
+schema_version: 1
+slug: features/wiki/dashboard
+title: Wiki Dashboard Surfaces
+id: wiki-dashboard
+aliases:
+  - wiki dashboard
+  - wiki ui
+  - wiki page
+  - wiki timeline page
+  - wiki settings page
+  - /wiki
+  - /wiki/timeline
+  - /settings/wiki
+category: features
+summary: |
+  Reference for the three dashboard surfaces the wiki feature renders:
+  `/wiki` (workspace summary + index + recent activity), `/wiki/timeline`
+  (full chronological log + latest health report), and `/settings/wiki`
+  (configuration). Explains what each card shows, where the data comes
+  from on disk, and what to do when a card is empty.
+section: wiki
+tags:
+  - wiki
+  - dashboard
+  - reference
+  - core
+status: stable
+ask_examples:
+  - What does the /wiki page show?
+  - Where do I find the wiki health report?
+  - Why is the Recent activity card empty?
+  - How do I see every !ingest run for a workspace?
+  - Where is the wiki configuration page?
+  - What is _index.md and where does the wiki page render it?
+  - How is /wiki different from /wiki/timeline?
+  - What does the Enable Wiki button do?
+locale: en-US
+created: 2026-05-21
+updated: 2026-05-28
+keywords:
+  - /wiki
+  - /wiki/timeline
+  - /settings/wiki
+  - wiki dashboard
+  - workspace summary card
+  - _index.md
+  - log.md
+  - health report
+  - 90_meta/health
+  - recent activity
+  - timeline filter
+  - Enable Wiki CTA
+  - vault path picker
+related:
+  - features/wiki/overview
+  - features/wiki/commands
+  - features/wiki/workspaces
+  - features/wiki/cost-and-approval
+  - guides/build-your-wiki
+  - guides/maintain-wiki-health
+  - guides/use-an-existing-obsidian-vault
+ui_anchors:
+  - /wiki
+  - /wiki/timeline
+  - /settings/wiki
+api_endpoints:
+  - /api/wiki/workspaces
+  - /api/wiki/:workspace/index
+  - /api/wiki/:workspace/files/log.md
+  - /api/wiki/:workspace/health
+  - /api/wiki/:workspace/estimate
+  - /api/wiki/:workspace/compile/preview
+process_keys:
+  - wiki.ask
+  - wiki.compile
+  - wiki.ingest_url
+  - wiki.lint
+  - wiki.trace
+  - wiki.connect
+---
+
+# Wiki Dashboard Surfaces
+
+The wiki has three distinct pages in the dashboard. The split mirrors
+Aitne's broader IA: content browsing lives under **My Life**,
+configuration lives under **Setup → Settings**. The pages share a
+single read path through the daemon's `/api/wiki/*` routes — every
+request carries an `x-process-key: wiki.ask` header so the safety
+layer can attribute reads correctly.
+
+## `/wiki` — workspace home
+
+The page you open most often. Three cards stacked top-down:
+
+### 1. Workspace summary
+
+A single card with the workspace name, root path, kind badge
+(`Internal` / `External`), language badge, and a stats table:
+
+| Stat | Source |
+|---|---|
+| Raw notes | Count of files under `10_raw/` |
+| Wiki pages | Count of files under `20_wiki/` |
+| Outputs | Count of files under `30_outputs/` |
+| Last ingest | `wiki_workspaces.last_ingest_at` |
+| Last compile | `wiki_workspaces.last_compile_at` |
+
+Two action buttons at the bottom of the card: **Timeline & health**
+(jumps to `/wiki/timeline`) and **Configuration** (jumps to
+`/settings/wiki`).
+
+### 2. Index
+
+Renders the latest `20_wiki/_index.md`, the LLM-maintained catalogue
+of wiki pages. The agent rewrites this file at the end of every
+`!compile` run.
+
+States:
+- **Empty** — no `_index.md` yet; the CTA tells you to run `!compile`
+  from a DM.
+- **Loaded** — the file is rendered verbatim as a monospaced code
+  block (the index uses wikilink syntax, so rendering as markdown
+  would lose information).
+
+### 3. Recent activity
+
+The last 8 entries from `log.md`, the wiki's append-only operational
+log. Each entry shows the wiki process key (`wiki.ingest_url`,
+`wiki.compile`, `wiki.ask`, `wiki.lint`, `wiki.trace`, `wiki.connect`),
+the operation (`write`, `delete`, …), the affected path, and the
+timestamp. A **View full timeline** button at the top of the card
+opens `/wiki/timeline`.
+
+A freshly-enabled wiki has no `log.md` yet — the route returns 404
+and the card shows the "No activity yet" hint instead of a scary
+error toast.
+
+### Disabled state
+
+When no `active=1` workspace exists in `wiki_workspaces`, the page
+shows an **Enable Wiki** CTA that jumps to `/settings/wiki`. The
+sidebar entry is always visible (gated only on the workspace
+catalogue being reachable), so this disabled state is reachable via
+the sidebar, a deep link, or browser history.
+
+## `/wiki/timeline` — full chronological history + health
+
+Two surfaces stacked on one page:
+
+### 1. Latest health report
+
+Renders the newest `90_meta/health/<YYYY-MM-DD>.md` produced by
+`!lint`. The card shows:
+
+- A purple date badge and the source file path.
+- A `## Summary` block (bulleted list).
+- An `## Action items` list (the punch-list of orphan notes, broken
+  wikilinks, schema drift, taxonomy candidates, and stale-note
+  warnings).
+- A collapsible **View full report** button that reveals the raw
+  Markdown body of the report.
+
+Empty state: "No health reports yet — send `!lint` from a DM to
+generate the first one."
+
+### 2. Activity timeline
+
+A reverse-chronological view of `log.md` with a process-key filter.
+The filter dropdown lists every distinct `wiki.*` key found in the
+log plus an **All commands** default. Entries render the same way
+they do in the `/wiki` recent-activity card — process-key badge,
+operation, path, timestamp.
+
+Both surfaces read live from the wiki API; the timeline page is a
+pure rendering pass over files the wiki skills already produce — no
+extra daemon-side schema backs them.
+
+## `/settings/wiki` — configuration
+
+The configuration surface. Two-state:
+
+### Disabled (no active workspace)
+
+A two-card chooser:
+
+- **Internal** (recommended) — managed by Aitne in its data directory
+  (default `~/.personal-agent/wiki`), schema seeded automatically.
+  The **Enable internal wiki** button turns it on with nothing else
+  to configure.
+- **Existing Obsidian vault** (external) — point Aitne at a folder you
+  already own via the path picker, then confirm with **Use this
+  folder**.
+
+The path picker opens your OS-native folder dialog (Finder on macOS,
+File Explorer on Windows, the system folder dialog on Linux) and shows
+an inline validation banner once you pick a path:
+
+- Path-collision rules — the external root must not overlap
+  `dataDir`, your primary Obsidian vault, or another wiki workspace.
+- Existing-Obsidian-vault detection — when the picker finds an
+  Obsidian vault at the target, the wiki layout is detected and
+  migrated on demand so you can import the vault's content (see
+  [guides/use-an-existing-obsidian-vault](../../guides/use-an-existing-obsidian-vault.md)
+  and [features/wiki/workspaces](workspaces.md)).
+
+### Enabled
+
+The full configuration:
+
+- **Workspace** — name, kind (internal / external), root path, language.
+- **Dispatch mode** for `!ingest` (Parallel / Serial) and the
+  concurrency cap.
+- **Write strategy** (`fs` / `cli` / `auto`) — internal workspaces
+  always use `fs`; external workspaces start in `auto` and probe on
+  first write (see [features/wiki/workspaces](workspaces.md)).
+- **Git auto-commit before `!compile full`** toggle (only meaningful
+  on a git-tracked external vault).
+- **Approval threshold (USD)** for `!compile full`.
+- **Commands & models** — per-command selectors for the backend,
+  model, turn limit, and per-run budget on each `wiki.*` process key
+  (`wiki.ingest_url`, `wiki.compile`, `wiki.ask`, `wiki.lint`,
+  `wiki.trace`, `wiki.connect`). All six default to the medium tier
+  (Claude Sonnet 4.6) with a sensible `maxTurns` / `maxBudgetUsd`; you
+  can override per key.
+- **Archive / delete** — archive keeps the row but flips `active=0`;
+  delete drops the row (data on disk is untouched on external mode).
+
+The top of the enabled page carries a **Browse wiki** link that jumps
+back to `/wiki`.
+
+## Where each surface reads from
+
+| Surface | API route | On-disk source |
+|---|---|---|
+| Workspace summary | `GET /api/wiki/workspaces` | `wiki_workspaces` table |
+| Index card | `GET /api/wiki/:ws/index` | `20_wiki/_index.md` |
+| Recent activity | `GET /api/wiki/:ws/files/log.md` | `log.md` |
+| Health report | `GET /api/wiki/:ws/index` + `/files/...` | `90_meta/health/<date>.md` |
+| Activity timeline | `GET /api/wiki/:ws/files/log.md` | `log.md` |
+| Settings | `GET /api/wiki/workspaces`, `PATCH /api/wiki/workspaces/:ws` | `wiki_workspaces` table |
+
+Every wiki API request is gated by the `x-process-key` header. The
+dashboard uses `wiki.ask` as the closest read-only intent; the
+auth layer accepts any `wiki.*` key for GETs (see
+`authorizeWikiRequest` in `packages/daemon/src/api/routes/wiki.ts`).
+
+## Contextual help
+
+Every wiki page in the dashboard exposes a `?` Help button in the
+top-right action strip. Clicking it opens the relevant wiki doc in a
+slide-over for in-context reading (mirrors the global help pattern
+used everywhere else in the dashboard). `/wiki/timeline` opens this
+doc; `/wiki` opens [features/wiki/overview](overview.md) and
+`/settings/wiki` opens [features/wiki/workspaces](workspaces.md).

package/agent-assets/docs/features/wiki/overview.md

@@ -17,6 +17,7 @@ section: wiki
 tags:
   - wiki
   - knowledge
+  - core
 status: stable
 ask_examples:
   - What is the wiki?
@@ -25,19 +26,53 @@ ask_examples:
   - Can I point the wiki at my Obsidian vault?
 locale: en-US
 created: 2026-05-12
-updated: 2026-05-12
+updated: 2026-05-28
+keywords:
+  - wiki
+  - wiki workspace
+  - 00_inbox
+  - 10_raw
+  - 20_wiki
+  - 30_outputs
+  - 90_meta
+  - wiki layers
+  - external vault
+  - internal vault
+  - opt-in
+  - wiki process keys
+  - wiki dispatcher
+  - dashboard wiki page
 related:
   - features/wiki/commands
-  - features/memory-files
+  - features/wiki/dashboard
+  - features/wiki/workspaces
+  - features/wiki/search
+  - features/wiki/cost-and-approval
+  - concepts/memory-model
   - guides/build-your-wiki
   - guides/use-an-existing-obsidian-vault
   - guides/budget-and-cost-for-wiki
+  - guides/multiple-wikis-for-multiple-domains
+  - guides/maintain-wiki-health
+  - guides/explore-with-trace-and-connect
   - troubleshooting/wiki-write-failed
   - troubleshooting/wiki-ingest-full-blocked
 ui_anchors:
   - /wiki
   - /wiki/timeline
   - /settings/wiki
+api_endpoints:
+  - /api/wiki/workspaces
+  - /api/wiki/:workspace/index
+  - /api/wiki/:workspace/search
+  - /api/wiki/:workspace/estimate
+process_keys:
+  - wiki.ingest_url
+  - wiki.compile
+  - wiki.ask
+  - wiki.lint
+  - wiki.trace
+  - wiki.connect
 ---
 
 # Wiki Overview
@@ -50,6 +85,8 @@ and questions you ask it.
 
 ## What It Does
 
+The three commands you reach for daily:
+
 - **URL ingest**: send `!ingest <url>` from a paired DM channel; the wiki
   agent fetches the source, summarises it, and stores a raw note.
 - **Compile**: `!compile` (incremental) and `!compile full` (full
@@ -58,9 +95,15 @@ and questions you ask it.
 - **Ask**: `!ask <question>` searches the wiki and writes a cited
   answer under `30_outputs/`.
 
-The wiki uses its own process keys (`wiki.ingest_url`, `wiki.compile`,
-`wiki.ask`) with independent backend / model / budget settings, so it
-never competes for budget with daily reactive memory.
+Three more for upkeep and exploration: `!lint` (health report),
+`!trace` (reconstruct an idea's evolution), and `!connect` (bridge two
+domains). `!wiki` prints workspace status. See the
+[commands reference](commands.md) for all of them.
+
+The wiki uses its own process keys — `wiki.ingest_url`, `wiki.compile`,
+`wiki.ask`, `wiki.lint`, `wiki.trace`, `wiki.connect` — each with
+independent backend / model / budget settings, so the wiki never
+competes for budget with daily reactive memory.
 
 ## Internal vs External
 
@@ -95,12 +138,14 @@ process keys can write wiki layers.
 ## Cost Safety
 
 `!compile full` rebuilds the entire wiki from raw notes and is the
-most expensive command. The dashboard banner shows the bracketed
-estimate ($0.5×–$2× the assumed input-token spend) before you run
-it. If the pessimistic estimate exceeds the per-workspace threshold
-(default $2.00), the command escalates to the dashboard `/approvals`
-queue and requires your explicit confirmation before the compile
-starts.
+most expensive command. Before you run it, the dashboard shows a
+bracketed estimate — the optimistic (0.5×) and pessimistic (2×)
+multiples of the assumed input-token spend. If the pessimistic
+estimate exceeds the per-workspace threshold (default $2.00), the
+command escalates to the approval queue and requires your explicit
+confirmation before the compile starts. The pending-approval card
+surfaces on the dashboard home page (`/`), where you Approve or Deny
+it.
 
 On a git-tracked external vault, Aitne also runs
 `git add -A && git commit -m "aitne wiki: pre-compile snapshot <ts>"`
@@ -113,7 +158,7 @@ commit or stash first.
 The wiki has two distinct surfaces in the dashboard. The split mirrors
 how Aitne organises the rest of the app — configuration lives under
 **Setup → Settings**, day-to-day content browsing lives under **My
-Life** next to Knowledge / Reading / Git / Trip / Finance / Health.
+Life** next to Knowledge / Reading / Git.
 
 | Page | Section | Use it for |
 |---|---|---|
@@ -143,3 +188,26 @@ disk until you opt in.
   strategy, git auto-commit toggle, approval threshold, per-command
   model selectors, plus archive / delete. A "Browse wiki" link at the
   top jumps you back to `/wiki`.
+
+## Where to go next
+
+This page is a high-level tour. For depth on a specific surface:
+
+- **[Commands reference](commands.md)** — every wiki bang command
+  (`!ingest`, `!compile`, `!ask`, `!lint`, `!trace`, `!connect`,
+  `!wiki`), the `@<workspace>` addressing token, dispatch modes, and
+  the disabled-state behaviour.
+- **[Dashboard surfaces](dashboard.md)** — what `/wiki`,
+  `/wiki/timeline`, and `/settings/wiki` actually render, where each
+  card reads from on disk, and how the contextual help button maps
+  to this doc set.
+- **[Workspaces, vaults, write strategy](workspaces.md)** — internal
+  vs external, multi-workspace `@<name>` addressing, fs/cli/auto
+  write strategy, dispatch modes, language, and archive vs delete.
+- **[Search and index](search.md)** — how `!ask` / `!trace` /
+  `!connect` find content via `_index.md` and the FTS5 `fts_wiki`
+  virtual table, plus the rebuild path.
+- **[Cost estimation and approval](cost-and-approval.md)** — the
+  bracketed 0.5×/2× cost estimator, the `!compile full` approval
+  threshold, the pre-compile git snapshot, and the `--preview`
+  dry-run.

package/agent-assets/docs/features/wiki/search.md

@@ -0,0 +1,248 @@
+---
+schema_version: 1
+slug: features/wiki/search
+title: Wiki Search and Index
+id: wiki-search
+aliases:
+  - wiki search
+  - wiki fts
+  - wiki full text search
+  - _index.md
+  - wiki index
+  - how ask searches
+  - how trace finds sources
+category: features
+summary: |
+  How `!ask`, `!trace`, and `!connect` find content inside a wiki. The
+  workspace exposes two search surfaces — the LLM-maintained
+  `20_wiki/_index.md` catalogue and a content-less FTS5 virtual table
+  (`fts_wiki`) the daemon syncs on every write. Both are read-only
+  consumers; only `!compile` writes the catalogue.
+section: wiki
+tags:
+  - wiki
+  - search
+  - fts
+  - reference
+status: stable
+ask_examples:
+  - How does !ask find the right wiki pages?
+  - What is _index.md and who writes it?
+  - How does the wiki search work internally?
+  - Can I search the wiki from the dashboard?
+  - Why didn't !ask find my recent ingest?
+  - Does the wiki search Japanese / CJK content?
+  - How do I rebuild the wiki search index?
+  - What is fts_wiki?
+locale: en-US
+created: 2026-05-21
+updated: 2026-05-28
+keywords:
+  - wiki search
+  - fts_wiki
+  - FTS5
+  - content-less FTS
+  - unicode61
+  - tokenizer
+  - _index.md
+  - index catalogue
+  - wiki layer
+  - layer classifier
+  - reindex
+  - backfillWikiFulltext
+  - workspace_id
+  - layer prefix
+  - !ask retrieval
+related:
+  - features/wiki/overview
+  - features/wiki/commands
+  - features/wiki/workspaces
+  - features/wiki/dashboard
+ui_anchors:
+  - /wiki
+  - /wiki/timeline
+api_endpoints:
+  - /api/wiki/:workspace/search
+  - /api/wiki/:workspace/index
+  - /api/wiki/:workspace/reindex
+process_keys:
+  - wiki.ask
+  - wiki.trace
+  - wiki.connect
+  - wiki.compile
+  - wiki.lint
+context_files:
+  - knowledge/wiki
+---
+
+# Wiki Search and Index
+
+The wiki exposes two read paths the skills use to find content:
+
+1. **`20_wiki/_index.md`** — the LLM-maintained catalogue of pages.
+   A short, human-readable list with one bullet per wiki page, kept
+   current by every `!compile` run. Good for "give me the lay of the
+   land" queries.
+2. **`fts_wiki`** — a content-less SQLite FTS5 virtual table the
+   daemon syncs on every successful disk write. Good for "find any
+   page that mentions X" queries.
+
+Both surfaces are read-only consumers; only `!compile` writes the
+catalogue, and only the wiki API write endpoints update `fts_wiki`.
+
+## `_index.md` — the LLM-maintained catalogue
+
+Lives at `20_wiki/_index.md`. The compile skill rewrites it at the
+end of every `!compile` run with one bullet per wiki article, each
+with a short summary, the source slugs that fed it, and a
+`Last touched: <date>`. The dashboard `/wiki` page renders this file
+verbatim as the **Index** card.
+
+The catalogue is **not** authoritative — the source of truth is the
+on-disk files. If `_index.md` drifts (e.g. references a page that
+was renamed), `!lint` flags it under the **drift between
+`20_wiki/_index.md` and the files on disk** check and `!compile`
+rewrites it on the next pass.
+
+`GET /api/wiki/:workspace/index` returns both the parsed catalogue
+and a directory listing the dashboard uses to find the latest
+`90_meta/health/<date>.md` for the timeline page.
+
+## `fts_wiki` — content-less FTS5 search
+
+Aitne mirrors every wiki file into a SQLite FTS5 virtual table
+named `fts_wiki`. The table is **content-less** — the indexed text
+is the file on disk, not a row in another SQL table. This matters:
+
+- The mail FTS pattern (`fts_mail_messages`) uses
+  `AFTER INSERT/UPDATE/DELETE` triggers on `mail_messages_index`
+  because the source rows live in SQLite.
+- Wiki content lives on the filesystem. There's no source table to
+  trigger off, so the wiki API write endpoints
+  (`POST /api/wiki/:ws/files/:path`, `PATCH /api/wiki/:ws/files/:path`,
+  `DELETE /api/wiki/:ws/files/:path`) call
+  `upsertWikiFulltextRow` / `deleteWikiFulltextRow` directly after a
+  successful disk write.
+
+The schema (`packages/daemon/src/db/schema.ts`):
+
+```sql
+CREATE VIRTUAL TABLE IF NOT EXISTS fts_wiki USING fts5(
+    workspace_id UNINDEXED,
+    path UNINDEXED,
+    layer UNINDEXED,
+    title,
+    body,
+    mtime UNINDEXED,
+    tokenize = 'unicode61 remove_diacritics 2'
+);
+```
+
+The `unicode61` tokenizer with `remove_diacritics 2` matches the
+mail FTS table for consistency. CJK content is handled by code-point
+breaking — searches work for Japanese, Chinese, Korean, and
+mixed-script wikis.
+
+### Layer prefixes
+
+The path classifier maps each on-disk file to one of six layers:
+
+- `10_raw/...` → `raw`
+- `20_wiki/...` → `wiki`
+- `30_outputs/...` → `output`
+- `90_meta/...` → `meta`
+- `log.md` (workspace root) → `log`
+- `00_inbox/...` → `inbox`
+
+Only four of these are actually indexed. `upsertWikiFulltextRow`
+**drops `log` and `inbox` rows** before insert: `log.md` is an
+append-only audit trail and `00_inbox/` is human-only, so indexing
+them would bury wiki and raw matches under log noise. So the values
+you ever see in `fts_wiki.layer` are `raw`, `wiki`, `output`, and
+`meta`.
+
+Searches can filter by layer to restrict the result set — e.g.
+`layer=wiki` for only canonical pages, not raw notes.
+
+### Querying the index
+
+`GET /api/wiki/:workspace/search` is the daemon-internal search
+endpoint. The `!ask`, `!trace`, and `!connect` skills call it (via
+`curl`) to pull a candidate set of pages before the LLM picks
+evidence. The query supports:
+
+- `q` — the search query. Each whitespace-separated token is quoted
+  and joined by implicit AND, so a multi-word query narrows the
+  result set. (Tokens are quoted to neutralise FTS5's `AND`/`OR`/
+  `NOT`/`NEAR` operator vocabulary — typing literally `rust AND go`
+  matches those words, it does not parse as a boolean.)
+- `layer` — restrict to a single indexed layer (`raw` / `wiki` /
+  `output` / `meta`). Unknown values are ignored.
+- `limit` — default 20, clamped to the range 1–50.
+- `kind` — `fts` (default) queries `fts_wiki`; `grep` is a literal
+  case-insensitive substring fallback over the files on disk. When
+  an FTS query returns zero hits for a non-empty `q`, the caller gets
+  empty FTS results; an **empty** `q` automatically falls back to
+  grep so `/search?q=` enumerates the workspace.
+
+Each result row carries `path`, `layer`, `title`, a body `snippet`
+(FTS5 `snippet()` output, `<mark>`-wrapped), `mtime` so the caller
+can rank by recency, and a BM25 `rank` (lower is better, `title`
+weighted above `body`).
+
+There is no dashboard content-search bar today — the FTS surface is
+used by the agent, not the user UI. The dashboard timeline
+(`/wiki/timeline`) does carry a process-key filter, but that filters
+over `log.md` rather than searching content.
+
+## Rebuilding the index
+
+The FTS index can fall out of sync if you edit files in the wiki
+root with another tool (e.g. directly editing an external Obsidian
+vault). Two recovery paths:
+
+- **Per-workspace reindex** — `POST /api/wiki/:workspace/reindex`
+  scans the workspace tree and rebuilds every `fts_wiki` row for
+  that workspace. Cheap; runs synchronously.
+- **Boot-time backfill** — `backfillWikiFulltext` runs once on
+  daemon start when `fts_wiki` is detected as empty for any active
+  workspace. This is the recovery path after a clean reinstall or a
+  fresh DB.
+
+The reindex never deletes files on disk; it's a pure read-then-write
+into the SQL index.
+
+## How `!ask` uses both surfaces
+
+A simplified flow for `!ask <question>`:
+
+1. The skill orients on `_index.md` for the lay of the land, then
+   searches and reads relevant `20_wiki/` pages first — running FTS
+   queries against `fts_wiki` to find pages that mention the
+   question's key terms.
+2. It reads `10_raw/` notes only when the wiki pages need source
+   verification.
+3. The LLM synthesises an answer from the pages it pulled.
+4. The answer is written to
+   `30_outputs/<YYYY-MM-DD>-<slug>.md` (the date-prefixed output
+   shape the `OUTPUT_RE` path check enforces). The file records the
+   question, a short answer, the evidence, source links, and any
+   follow-up gaps; if the wiki lacks enough evidence the skill says
+   so and lists what is missing.
+5. The skill ends the turn with a short plain-prose reply forwarded
+   to the channel the command came from, citing pages inline as
+   `see [[<slug>]]` and pointing at the full answer file.
+
+`!trace` and `!connect` follow a similar pattern but with
+trace-specific (chronological) or connect-specific (cross-domain)
+search queries.
+
+## Why no embedding-based search
+
+Aitne's wiki is local-first and keychain-isolated; running embedding
+inference adds either a remote API dependency or a heavy local model
+— neither of which fits the "your laptop, your data" promise. FTS5
+unicode61 covers the common case (find pages by keyword) without a
+network round-trip and without a model file. The compile step's
+wikilinks + the LLM-maintained `_index.md` carry the semantic
+"connect related pages" load.