feat: bundle docs for Tolaria agents
3
.github/workflows/ci.yml
vendored
@@ -50,6 +50,9 @@ jobs:
|
||||
- name: Vite build check
|
||||
run: pnpm build
|
||||
|
||||
- name: Docs build check
|
||||
run: pnpm docs:build
|
||||
|
||||
# ── 1. Coverage-backed tests ──────────────────────────────────────────
|
||||
# The coverage command runs the canonical frontend test suite.
|
||||
- name: Bundle MCP server resources (required by Tauri build)
|
||||
|
||||
24
.github/workflows/release-stable.yml
vendored
@@ -725,10 +725,10 @@ jobs:
|
||||
stable-latest.json
|
||||
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
# Phase 4: Update GitHub Pages
|
||||
# Phase 4: Update GitHub Pages with docs, release history, and download assets
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
pages:
|
||||
name: Update release history page
|
||||
name: Update docs and release pages
|
||||
needs: [version, release]
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
@@ -739,16 +739,32 @@ jobs:
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Setup pnpm
|
||||
uses: pnpm/action-setup@v4
|
||||
with:
|
||||
version: 10
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '22'
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Setup Bun
|
||||
uses: oven-sh/setup-bun@v2
|
||||
with:
|
||||
bun-version: latest
|
||||
|
||||
- name: Build release history page
|
||||
- name: Install dependencies
|
||||
run: pnpm install --frozen-lockfile
|
||||
|
||||
- name: Build docs and release pages
|
||||
env:
|
||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
run: |
|
||||
VITEPRESS_BASE="/${GITHUB_REPOSITORY#*/}/" pnpm docs:build
|
||||
mkdir -p _site/alpha _site/stable _site/release-notes
|
||||
cp -R site/.vitepress/dist/. _site/
|
||||
if [ -d release-notes ]; then cp release-notes/*.md _site/release-notes/ 2>/dev/null || true; fi
|
||||
gh api -H "Accept: application/vnd.github.html+json" repos/${{ github.repository }}/releases --paginate > _site/releases.json
|
||||
PAGES_URL="https://refactoringhq.github.io/${GITHUB_REPOSITORY#*/}"
|
||||
@@ -756,7 +772,7 @@ jobs:
|
||||
curl -fsSL "${PAGES_URL}/alpha/latest.json" -o _site/alpha/latest.json || echo '{}' > _site/alpha/latest.json
|
||||
gh release download --repo ${{ github.repository }} "${{ needs.version.outputs.tag }}" --pattern "stable-latest.json" --output _site/stable/latest.json || echo '{}' > _site/stable/latest.json
|
||||
bun scripts/build-release-download-page.ts --latest-json _site/stable/latest.json --releases-json _site/releases.json --output-file _site/stable/download/index.html
|
||||
bun scripts/build-release-history-page.ts --releases-json _site/releases.json --output-file _site/index.html
|
||||
bun scripts/build-release-history-page.ts --releases-json _site/releases.json --output-file _site/releases/index.html
|
||||
mkdir -p _site/download
|
||||
cp _site/stable/download/index.html _site/download/index.html
|
||||
|
||||
|
||||
24
.github/workflows/release.yml
vendored
@@ -766,10 +766,10 @@ jobs:
|
||||
alpha-latest.json
|
||||
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
# Phase 4: Update GitHub Pages with release history
|
||||
# Phase 4: Update GitHub Pages with docs, release history, and download assets
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
pages:
|
||||
name: Update release history page
|
||||
name: Update docs and release pages
|
||||
needs: [version, release]
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
@@ -780,16 +780,32 @@ jobs:
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Setup pnpm
|
||||
uses: pnpm/action-setup@v4
|
||||
with:
|
||||
version: 10
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '22'
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Setup Bun
|
||||
uses: oven-sh/setup-bun@v2
|
||||
with:
|
||||
bun-version: latest
|
||||
|
||||
- name: Build release history page
|
||||
- name: Install dependencies
|
||||
run: pnpm install --frozen-lockfile
|
||||
|
||||
- name: Build docs and release pages
|
||||
env:
|
||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
run: |
|
||||
VITEPRESS_BASE="/${GITHUB_REPOSITORY#*/}/" pnpm docs:build
|
||||
mkdir -p _site/alpha _site/stable _site/release-notes
|
||||
cp -R site/.vitepress/dist/. _site/
|
||||
if [ -d release-notes ]; then cp release-notes/*.md _site/release-notes/ 2>/dev/null || true; fi
|
||||
gh api -H "Accept: application/vnd.github.html+json" repos/${{ github.repository }}/releases --paginate > _site/releases.json
|
||||
PAGES_URL="https://refactoringhq.github.io/${GITHUB_REPOSITORY#*/}"
|
||||
@@ -797,7 +813,7 @@ jobs:
|
||||
gh release download --repo ${{ github.repository }} "${{ needs.version.outputs.tag }}" --pattern "alpha-latest.json" --output _site/alpha/latest.json || echo '{}' > _site/alpha/latest.json
|
||||
curl -fsSL "${PAGES_URL}/stable/latest.json" -o _site/stable/latest.json || echo '{}' > _site/stable/latest.json
|
||||
bun scripts/build-release-download-page.ts --latest-json _site/stable/latest.json --releases-json _site/releases.json --output-file _site/stable/download/index.html
|
||||
bun scripts/build-release-history-page.ts --releases-json _site/releases.json --output-file _site/index.html
|
||||
bun scripts/build-release-history-page.ts --releases-json _site/releases.json --output-file _site/releases/index.html
|
||||
mkdir -p _site/download
|
||||
cp _site/stable/download/index.html _site/download/index.html
|
||||
|
||||
|
||||
5
.gitignore
vendored
@@ -10,6 +10,9 @@ lerna-debug.log*
|
||||
node_modules
|
||||
dist
|
||||
dist-ssr
|
||||
site/.vitepress/cache/
|
||||
site/.vitepress/dist/
|
||||
_site/
|
||||
*.local
|
||||
|
||||
# Editor directories and files
|
||||
@@ -42,7 +45,7 @@ final_selection.py
|
||||
src-tauri/target
|
||||
|
||||
# Generated mcp-server bundle (built by scripts/bundle-mcp-server.mjs)
|
||||
src-tauri/resources/
|
||||
src-tauri/resources/mcp-server/
|
||||
|
||||
# Python cache
|
||||
__pycache__/
|
||||
|
||||
@@ -49,6 +49,8 @@ Download the [latest release here](https://refactoringhq.github.io/tolaria/downl
|
||||
|
||||
When you open Tolaria for the first time you get the chance of cloning the [getting started vault](https://github.com/refactoringhq/tolaria-getting-started) — which gives you a walkthrough of the whole app.
|
||||
|
||||
The public user docs live in [`site/`](site/) and are published to GitHub Pages. Start with [Install Tolaria](site/start/install.md), then [First Launch](site/start/first-launch.md).
|
||||
|
||||
## Open source and local setup
|
||||
|
||||
Tolaria is open source and built with Tauri, React, and TypeScript. If you want to run or contribute to the app locally, here is [how to get started](https://github.com/refactoringhq/tolaria/blob/main/docs/GETTING-STARTED.md). You can also find the gist below 👇
|
||||
|
||||
@@ -4,7 +4,7 @@ Key abstractions and domain models in Tolaria.
|
||||
|
||||
## Design Philosophy
|
||||
|
||||
Tolaria's abstractions follow the **convention over configuration** principle: standard field names and folder structures have well-defined meanings and trigger UI behavior automatically. This makes vaults legible both to humans and to AI agents — the more a vault follows conventions, the less custom configuration an AI needs to navigate it correctly.
|
||||
Tolaria's abstractions follow the **convention over configuration** principle: standard field names, types, and relationships have well-defined meanings and trigger UI behavior automatically. This makes vaults legible both to humans and to AI agents — the more a vault follows conventions, the less custom configuration an AI needs to navigate it correctly.
|
||||
|
||||
The full set of design principles is documented in [ARCHITECTURE.md](./ARCHITECTURE.md#design-principles).
|
||||
|
||||
@@ -751,6 +751,11 @@ Tolaria tracks managed vault-level AI guidance separately from normal note conte
|
||||
- `restore_vault_ai_guidance` repairs only Tolaria-managed files and creates the optional Gemini shim on explicit request; user-authored custom `AGENTS.md` / `CLAUDE.md` / `GEMINI.md` files are surfaced as custom and left untouched
|
||||
- The status bar AI badge and command palette consume that abstraction to expose restore actions only when the managed guidance is missing or broken
|
||||
|
||||
Vault guidance is intentionally short and vault-specific. General Tolaria product behavior is delivered through the bundled agent docs resource instead:
|
||||
- `scripts/build-agent-docs.mjs` compiles the public `site/` Markdown into `src-tauri/resources/agent-docs/`
|
||||
- `src-tauri/resources/agent-docs/AGENTS.md` orients agents to the generated docs bundle, while `index.md`, section bundles, `all.md`, `search-index.json`, and `pages/` provide fast local lookup
|
||||
- `get_agent_docs_path` exposes the resolved resource folder to the renderer, and `buildAgentSystemPrompt()` tells every app-managed CLI agent to read vault `AGENTS.md` first, then search the bundled docs for Tolaria behavior
|
||||
|
||||
### Getting Started / Onboarding
|
||||
|
||||
`useOnboarding` hook detects first launch:
|
||||
|
||||
@@ -246,7 +246,7 @@ Notes can be opened in separate Tauri windows for focused editing. Secondary win
|
||||
|
||||
Full agent mode — spawns the selected local CLI agent as a subprocess with tool access and MCP vault integration.
|
||||
|
||||
1. **Frontend** (`AiPanel` + `useCliAiAgent` + `aiAgentSession.ts` + `aiAgents.ts` + `aiTargets.ts`) — one normalized session lifecycle for message state, reasoning blocks, tool action cards, response display, onboarding, default-target selection, and the per-vault Safe / Power User permission mode shown in the panel header for coding agents
|
||||
1. **Frontend** (`AiPanel` + `useCliAiAgent` + `aiAgentSession.ts` + `aiAgents.ts` + `aiTargets.ts`) — one normalized session lifecycle for message state, reasoning blocks, tool action cards, response display, onboarding, default-target selection, bundled-docs prompt injection, and the per-vault Safe / Power User permission mode shown in the panel header for coding agents
|
||||
2. **Backend orchestration** (`ai_agents.rs`) — normalizes agent availability, streaming, and the request permission mode before dispatching to per-agent adapters
|
||||
3. **Shared runtime scaffold** (`cli_agent_runtime.rs`) — owns the common request shape, prompt wrapping, JSON-line subprocess lifecycle, normalized error/done handling, version probing, and Tolaria MCP server path resolution used by app-managed CLI agents
|
||||
4. **Agent adapters** — Shared prompts are mode-aware on every turn, including turns with note context snapshots: Vault Safe tells agents not to use or advertise shell, while Power User tells shell-capable agents to keep local commands scoped to the active vault. Claude Code still uses `claude_cli.rs` with `acceptEdits`, strict Tolaria MCP config, and a scoped tool list: Safe enables file/search/edit tools only, while Power User adds Bash to the available tools and pre-approves Bash with `--allowedTools` without using dangerous bypass flags. Codex runtime specifics live in `codex_cli.rs`; Safe runs `codex --sandbox read-only --ask-for-approval untrusted exec --json`, while Power User runs `codex --sandbox workspace-write --ask-for-approval never exec --json` so shell execution stays enabled across repeated turns. OpenCode runs through `opencode run --format json` with transient permissions: Safe denies bash and external directories, while Power User allows bash but still denies external directories. Pi runs through `pi --mode json --no-session` with `npm:pi-mcp-adapter`; both modes currently share the same transient MCP config and the prompt does not promise shell for Pi Power User. Gemini runs through `gemini --output-format stream-json --prompt` so assistant message chunks, tool calls, and final errors are mapped from the CLI event stream instead of relying on a buffered `response` field. Gemini Safe uses `auto_edit` plus `tools.exclude=["run_shell_command"]`; Power User intentionally uses `yolo` against a trusted transient Tolaria MCP entry. Codex, OpenCode, Pi, and Gemini all launch from the active vault cwd with closed stdin and transient MCP config. All app-launched paths use hidden Windows launches and avoid dangerous permission-bypass flags.
|
||||
@@ -254,6 +254,8 @@ Full agent mode — spawns the selected local CLI agent as a subprocess with too
|
||||
|
||||
CLI-agent availability intentionally does not depend only on the desktop app's inherited `PATH`. The detectors check the current process path, the user's login shell, and supported local/toolchain install locations such as native `~/.local/bin`, local `~/.claude/local`, Mise/asdf shims, nvm-managed Node installs, npm-global, Homebrew, Windows `%APPDATA%\npm`/pnpm/Scoop shims, Windows `.exe` launchers, and the macOS Codex app resource path so first-run onboarding works on fresh macOS and Windows installs. App-managed CLI spawns also expand the active vault path before using it as the subprocess working directory, then extend the child process `PATH` with the resolved binary directory plus those common toolchain directories, which lets GUI-launched macOS sessions run Homebrew/npm shims and their `node`-backed MCP subprocesses even when Finder/Dock did not inherit a terminal shell path.
|
||||
|
||||
CLI-agent system prompts also include a local Tolaria docs orientation when the bundled docs resource is present. `scripts/build-agent-docs.mjs` generates `src-tauri/resources/agent-docs/` from the public VitePress Markdown sources, including `index.md`, `AGENTS.md`, per-section bundles, `all.md`, `search-index.json`, and generated per-page files. Tauri bundles that folder as `agent-docs/`; `get_agent_docs_path` resolves the installed resource path, with a repository fallback for development, and `getAgentDocsPath()` caches it before each agent run. Agents are instructed to read the active vault's `AGENTS.md` for local conventions and search the bundled docs for Tolaria product behavior.
|
||||
|
||||
#### Agent Event Flow
|
||||
|
||||
```mermaid
|
||||
@@ -768,6 +770,7 @@ The vault backend (`src-tauri/src/vault/`) is split into focused submodules:
|
||||
| `stream_claude_chat` | Claude CLI chat mode (streaming) |
|
||||
| `check_claude_cli` | Check if Claude CLI is available |
|
||||
| `get_ai_agents_status` | Check Claude Code + Codex + OpenCode + Pi + Gemini availability |
|
||||
| `get_agent_docs_path` | Resolve the bundled local Tolaria docs folder used in AI-agent system prompts |
|
||||
| `stream_ai_agent` | Stream Claude Code, Codex, OpenCode, Pi, or Gemini through the normalized agent event layer |
|
||||
| `register_mcp_tools` | Register MCP in Claude/Gemini/Cursor/generic config for the active vault |
|
||||
| `remove_mcp_tools` | Remove Tolaria's MCP entry from Claude/Gemini/Cursor/generic config |
|
||||
@@ -903,7 +906,8 @@ push to main
|
||||
→ generate alpha-latest.json with darwin-aarch64, darwin-x86_64, Linux, and Windows updater URLs
|
||||
→ publish GitHub prerelease alpha-vYYYY.M.D-alpha.NNNN named Tolaria Alpha YYYY.M.D.N
|
||||
→ pages job:
|
||||
→ build static HTML release history page
|
||||
→ build VitePress public docs into the GitHub Pages root
|
||||
→ build static HTML release history page at /releases/
|
||||
→ publish alpha/latest.json
|
||||
→ refresh latest.json + latest-canary.json as compatibility aliases to alpha
|
||||
→ preserve stable/latest.json
|
||||
@@ -929,6 +933,8 @@ push stable-vYYYY.M.D tag
|
||||
→ generate stable-latest.json with macOS Apple Silicon, macOS Intel, Linux, and Windows updater URLs plus platform-specific manual download URLs
|
||||
→ publish GitHub release Tolaria YYYY.M.D
|
||||
→ pages job:
|
||||
→ build VitePress public docs into the GitHub Pages root
|
||||
→ build static HTML release history page at /releases/
|
||||
→ publish stable/latest.json
|
||||
→ publish stable/download/ and download/ as permanent download pages that keep the browser page visible while the platform installer starts
|
||||
→ preserve alpha/latest.json
|
||||
|
||||
47
docs/PUBLIC-DOCS-PLAN.md
Normal file
@@ -0,0 +1,47 @@
|
||||
# Public Docs Plan
|
||||
|
||||
This document records the phase 1 information architecture for public Tolaria documentation. The public docs source lives in `site/`; the existing `docs/` directory remains contributor, architecture, and agent context.
|
||||
|
||||
## Audiences
|
||||
|
||||
| Audience | Needs | Primary location |
|
||||
|---|---|---|
|
||||
| New users | Install, first launch, understand the app layout, clone the starter vault | `site/start/` |
|
||||
| Active users | Learn concrete workflows such as organizing, Git sync, custom views, and AI | `site/guides/` |
|
||||
| Power users | Understand file layout, frontmatter, filters, release channels, shortcuts, and platform support | `site/reference/` |
|
||||
| Contributors and agents | Architecture, abstractions, ADRs, development workflow | `docs/`, `AGENTS.md` |
|
||||
|
||||
## Hosting Shape
|
||||
|
||||
The GitHub Pages output should reserve the root for public docs and mount release assets underneath it:
|
||||
|
||||
```text
|
||||
/ public docs home
|
||||
/releases/ release history
|
||||
/download/ latest stable download redirect
|
||||
/stable/latest.json
|
||||
/alpha/latest.json
|
||||
/latest.json compatibility alias for alpha latest
|
||||
/latest-canary.json compatibility alias for alpha latest
|
||||
```
|
||||
|
||||
## Current Coverage
|
||||
|
||||
The phase 1 site now covers post-branch features added after the original April docs snapshot:
|
||||
|
||||
- Windows and Linux release artifacts.
|
||||
- Stable and Alpha updater channels.
|
||||
- Direct AI model providers and local/API model setup.
|
||||
- Claude Code, Codex, OpenCode, Pi, and Gemini CLI agent targets.
|
||||
- Explicit MCP setup for external AI tools.
|
||||
- Table of contents, note width, raw mode, and paste-without-formatting workflows.
|
||||
- Media/PDF previews, image attachments, All Notes visibility, and Markdown whiteboards.
|
||||
- System theme mode and sidebar pluralization settings.
|
||||
|
||||
Every user-visible app change should answer:
|
||||
|
||||
```text
|
||||
Public docs impact:
|
||||
- updated: <pages>
|
||||
- not needed because: <reason>
|
||||
```
|
||||
@@ -6,7 +6,16 @@ import tseslint from 'typescript-eslint'
|
||||
import { defineConfig, globalIgnores } from 'eslint/config'
|
||||
|
||||
export default defineConfig([
|
||||
globalIgnores(['dist', 'coverage', 'src-tauri/resources/', 'src-tauri/target/', 'src-tauri/gen/', 'tools/']),
|
||||
globalIgnores([
|
||||
'dist',
|
||||
'coverage',
|
||||
'site/.vitepress/cache/',
|
||||
'site/.vitepress/dist/',
|
||||
'src-tauri/resources/mcp-server/',
|
||||
'src-tauri/target/',
|
||||
'src-tauri/gen/',
|
||||
'tools/',
|
||||
]),
|
||||
{
|
||||
files: ['**/*.{ts,tsx}'],
|
||||
extends: [
|
||||
|
||||
@@ -504,6 +504,8 @@ files:
|
||||
status.zoom.reset: dbf36ab275e5fbd256590e65aa1ca9a3
|
||||
status.feedback.contribute: 96ab5025e38aef43fdb73c9830795264
|
||||
status.feedback.label: 9887a4451812854f0f1b6f669a874307
|
||||
status.docs.open: 2066997d2262d4a9b79de68f255dc4a9
|
||||
status.docs.label: a3907cd461d8739aa3266047bc4b8c0c
|
||||
status.theme.light: 4abf27a209985375949aaa426c7c7f3d
|
||||
status.theme.dark: 541be2a55a52b518b8e510c476c7cc95
|
||||
status.settings.open: bae08226d065231df6f01b08cd681c9b
|
||||
|
||||
@@ -7,7 +7,11 @@
|
||||
"scripts": {
|
||||
"dev": "vite",
|
||||
"build": "tsc -b && vite build",
|
||||
"agent-docs": "node scripts/build-agent-docs.mjs",
|
||||
"bundle-mcp": "node scripts/bundle-mcp-server.mjs",
|
||||
"docs:dev": "vitepress dev site --host 127.0.0.1",
|
||||
"docs:build": "pnpm agent-docs && vitepress build site",
|
||||
"docs:preview": "vitepress preview site --host 127.0.0.1",
|
||||
"lint": "eslint .",
|
||||
"l10n:translate": "lara-cli translate",
|
||||
"l10n:translate:force": "lara-cli translate --force",
|
||||
@@ -103,6 +107,7 @@
|
||||
"typescript": "~5.9.3",
|
||||
"typescript-eslint": "^8.48.0",
|
||||
"vite": "^7.3.2",
|
||||
"vitepress": "^1.6.4",
|
||||
"vitest": "^4.0.18",
|
||||
"ws": "^8.19.0"
|
||||
},
|
||||
|
||||
1013
pnpm-lock.yaml
generated
184
scripts/build-agent-docs.mjs
Normal file
@@ -0,0 +1,184 @@
|
||||
import { mkdir, readdir, readFile, rm, writeFile } from 'node:fs/promises'
|
||||
import path from 'node:path'
|
||||
|
||||
const repoRoot = path.resolve(import.meta.dirname, '..')
|
||||
const siteRoot = path.join(repoRoot, 'site')
|
||||
const outputRoot = path.join(repoRoot, 'src-tauri', 'resources', 'agent-docs')
|
||||
|
||||
const sectionOrder = ['start', 'concepts', 'guides', 'reference', 'troubleshooting', 'download', 'releases']
|
||||
const ignoredDirs = new Set(['.vitepress', 'public', 'node_modules', '.DS_Store'])
|
||||
|
||||
function titleFromSlug(slug) {
|
||||
return slug
|
||||
.replace(/[-_]+/g, ' ')
|
||||
.replace(/\b\w/g, (letter) => letter.toUpperCase())
|
||||
}
|
||||
|
||||
function stripFrontmatter(markdown) {
|
||||
return markdown.replace(/^---\n[\s\S]*?\n---\n/, '')
|
||||
}
|
||||
|
||||
function firstHeading(markdown, fallback) {
|
||||
const match = markdown.match(/^#\s+(.+)$/m)
|
||||
return match?.[1]?.trim() || fallback
|
||||
}
|
||||
|
||||
function sectionForFile(relativePath) {
|
||||
const [firstPart] = relativePath.split('/')
|
||||
if (firstPart === 'index.md') return 'home'
|
||||
return firstPart.replace(/\.md$/, '')
|
||||
}
|
||||
|
||||
async function listMarkdownFiles(dir, base = dir) {
|
||||
const entries = await readdir(dir, { withFileTypes: true })
|
||||
const files = []
|
||||
|
||||
for (const entry of entries) {
|
||||
if (ignoredDirs.has(entry.name)) continue
|
||||
|
||||
const fullPath = path.join(dir, entry.name)
|
||||
if (entry.isDirectory()) {
|
||||
files.push(...await listMarkdownFiles(fullPath, base))
|
||||
} else if (entry.isFile() && entry.name.endsWith('.md')) {
|
||||
files.push(path.relative(base, fullPath))
|
||||
}
|
||||
}
|
||||
|
||||
return files
|
||||
}
|
||||
|
||||
function sortDocs(files) {
|
||||
return files.sort((a, b) => {
|
||||
const sectionDiff = sectionOrder.indexOf(sectionForFile(a)) - sectionOrder.indexOf(sectionForFile(b))
|
||||
if (sectionDiff !== 0) return sectionDiff
|
||||
return a.localeCompare(b)
|
||||
})
|
||||
}
|
||||
|
||||
function docUrl(relativePath) {
|
||||
const withoutExt = relativePath.replace(/(^|\/)index\.md$/, '$1').replace(/\.md$/, '')
|
||||
return `/${withoutExt}`.replace(/\/$/, '/') || '/'
|
||||
}
|
||||
|
||||
function formatDoc(doc) {
|
||||
return `# ${doc.title}\n\nSource: ${doc.path}\nURL: ${doc.url}\n\n${doc.content}`
|
||||
}
|
||||
|
||||
function groupDocsBySection(docs) {
|
||||
const bySection = new Map()
|
||||
|
||||
for (const doc of docs) {
|
||||
const docsInSection = bySection.get(doc.section) ?? []
|
||||
docsInSection.push(doc)
|
||||
bySection.set(doc.section, docsInSection)
|
||||
}
|
||||
|
||||
return bySection
|
||||
}
|
||||
|
||||
function buildIndex(docs) {
|
||||
const bySection = groupDocsBySection(docs)
|
||||
const lines = [
|
||||
'# Tolaria Agent Docs',
|
||||
'',
|
||||
'These docs are generated from the public Tolaria documentation for local AI agent lookup.',
|
||||
'',
|
||||
'Start here, then use `rg` over this folder for specific Tolaria concepts and workflows.',
|
||||
'',
|
||||
]
|
||||
|
||||
for (const section of ['home', ...sectionOrder]) {
|
||||
const docsInSection = bySection.get(section)
|
||||
if (!docsInSection?.length) continue
|
||||
|
||||
lines.push(`## ${titleFromSlug(section)}`, '')
|
||||
for (const doc of docsInSection) {
|
||||
lines.push(`- [${doc.title}](pages/${doc.path})`)
|
||||
}
|
||||
lines.push('')
|
||||
}
|
||||
|
||||
lines.push('## Generated Files', '')
|
||||
lines.push('- `all.md`: all public docs concatenated for fast full-context reads.')
|
||||
lines.push('- `search-index.json`: title, heading, section, path, and URL metadata for quick routing.')
|
||||
lines.push('- `<section>.md`: one compact bundle per docs section.')
|
||||
lines.push('- `pages/`: one generated Markdown file per public docs page.')
|
||||
lines.push('')
|
||||
|
||||
return lines.join('\n')
|
||||
}
|
||||
|
||||
function buildAgentInstructions() {
|
||||
return `# AGENTS.md - Tolaria Docs Bundle
|
||||
|
||||
This folder contains local, generated Tolaria product docs for AI agents.
|
||||
|
||||
Use these docs when a user asks how Tolaria works, when you need product behavior, or before making Tolaria-specific assumptions.
|
||||
|
||||
Recommended lookup flow:
|
||||
|
||||
1. Read the active vault's AGENTS.md for vault-specific conventions.
|
||||
2. Read this folder's index.md for the docs map.
|
||||
3. Use \`rg\` over this folder for advanced concepts, workflows, shortcuts, Git, AutoGit, AI, types, properties, relationships, and troubleshooting.
|
||||
|
||||
Vault-specific AGENTS.md wins for local conventions. These bundled docs win for Tolaria product behavior.
|
||||
`
|
||||
}
|
||||
|
||||
function searchIndexFor(doc) {
|
||||
const headings = [...doc.content.matchAll(/^#{2,3}\s+(.+)$/gm)].map((match) => match[1].trim())
|
||||
return {
|
||||
title: doc.title,
|
||||
path: `pages/${doc.path}`,
|
||||
url: doc.url,
|
||||
section: doc.section,
|
||||
headings,
|
||||
}
|
||||
}
|
||||
|
||||
async function main() {
|
||||
const files = sortDocs(await listMarkdownFiles(siteRoot))
|
||||
const docs = []
|
||||
|
||||
for (const relativePath of files) {
|
||||
const raw = await readFile(path.join(siteRoot, relativePath), 'utf8')
|
||||
const content = stripFrontmatter(raw).trim()
|
||||
const fallbackTitle = titleFromSlug(path.basename(relativePath, '.md'))
|
||||
docs.push({
|
||||
content,
|
||||
path: relativePath,
|
||||
section: sectionForFile(relativePath),
|
||||
title: firstHeading(content, fallbackTitle),
|
||||
url: docUrl(relativePath),
|
||||
})
|
||||
}
|
||||
|
||||
await rm(outputRoot, { force: true, recursive: true })
|
||||
await mkdir(outputRoot, { recursive: true })
|
||||
|
||||
await writeFile(path.join(outputRoot, 'AGENTS.md'), buildAgentInstructions())
|
||||
await writeFile(path.join(outputRoot, 'index.md'), buildIndex(docs))
|
||||
await writeFile(path.join(outputRoot, 'all.md'), docs.map(formatDoc).join('\n\n---\n\n'))
|
||||
await writeFile(path.join(outputRoot, 'search-index.json'), `${JSON.stringify(docs.map(searchIndexFor), null, 2)}\n`)
|
||||
|
||||
for (const doc of docs) {
|
||||
const outputPath = path.join(outputRoot, 'pages', doc.path)
|
||||
await mkdir(path.dirname(outputPath), { recursive: true })
|
||||
await writeFile(outputPath, formatDoc(doc))
|
||||
}
|
||||
|
||||
const bySection = groupDocsBySection(docs)
|
||||
for (const [section, docsInSection] of bySection) {
|
||||
await writeFile(
|
||||
path.join(outputRoot, `${section}.md`),
|
||||
docsInSection.map(formatDoc).join('\n\n---\n\n'),
|
||||
)
|
||||
}
|
||||
|
||||
console.log(`Generated ${docs.length} agent docs in ${path.relative(repoRoot, outputRoot)}`)
|
||||
}
|
||||
|
||||
main().catch((error) => {
|
||||
console.error(error)
|
||||
process.exit(1)
|
||||
})
|
||||
107
site/.vitepress/config.ts
Normal file
@@ -0,0 +1,107 @@
|
||||
import { defineConfig } from "vitepress";
|
||||
|
||||
const base = process.env.VITEPRESS_BASE ?? "/";
|
||||
|
||||
export default defineConfig({
|
||||
title: "Tolaria",
|
||||
description:
|
||||
"Tolaria is a local-first Markdown knowledge base with native relationships, Git history, and AI workflows.",
|
||||
base,
|
||||
cleanUrls: true,
|
||||
head: [
|
||||
["link", { rel: "icon", type: "image/png", href: `${base}landing/favicon.png` }],
|
||||
["meta", { property: "og:title", content: "Tolaria" }],
|
||||
[
|
||||
"meta",
|
||||
{
|
||||
property: "og:description",
|
||||
content:
|
||||
"A second brain for the AI era. Free forever, local-first, Markdown-based, Git-ready, and AI-friendly.",
|
||||
},
|
||||
],
|
||||
],
|
||||
themeConfig: {
|
||||
logo: { src: "/landing/tolaria-icon.png", alt: "Tolaria" },
|
||||
nav: [
|
||||
{ text: "Start", link: "/start/install" },
|
||||
{ text: "Concepts", link: "/concepts/vaults" },
|
||||
{ text: "Guides", link: "/guides/capture-a-note" },
|
||||
{ text: "Downloads", link: "/download/" },
|
||||
],
|
||||
search: {
|
||||
provider: "local",
|
||||
},
|
||||
sidebar: [
|
||||
{
|
||||
text: "Start Here",
|
||||
items: [
|
||||
{ text: "Install Tolaria", link: "/start/install" },
|
||||
{ text: "First Launch", link: "/start/first-launch" },
|
||||
{ text: "Getting Started Vault", link: "/start/getting-started-vault" },
|
||||
{ text: "Open Or Create A Vault", link: "/start/open-or-create-vault" },
|
||||
],
|
||||
},
|
||||
{
|
||||
text: "Concepts",
|
||||
items: [
|
||||
{ text: "Vaults", link: "/concepts/vaults" },
|
||||
{ text: "Notes", link: "/concepts/notes" },
|
||||
{ text: "Editor", link: "/concepts/editor" },
|
||||
{ text: "Properties", link: "/concepts/properties" },
|
||||
{ text: "Types", link: "/concepts/types" },
|
||||
{ text: "Relationships", link: "/concepts/relationships" },
|
||||
{ text: "Files And Media", link: "/concepts/files-and-media" },
|
||||
{ text: "Inbox", link: "/concepts/inbox" },
|
||||
{ text: "Git", link: "/concepts/git" },
|
||||
{ text: "AI", link: "/concepts/ai" },
|
||||
],
|
||||
},
|
||||
{
|
||||
text: "Guides",
|
||||
items: [
|
||||
{ text: "Capture A Note", link: "/guides/capture-a-note" },
|
||||
{ text: "Organize The Inbox", link: "/guides/organize-inbox" },
|
||||
{ text: "Use Wikilinks", link: "/guides/use-wikilinks" },
|
||||
{ text: "Create Types", link: "/guides/create-types" },
|
||||
{ text: "Build Custom Views", link: "/guides/build-custom-views" },
|
||||
{ text: "Connect A Git Remote", link: "/guides/connect-a-git-remote" },
|
||||
{ text: "Manage Git", link: "/guides/commit-and-push" },
|
||||
{ text: "Use The AI", link: "/guides/use-ai-panel" },
|
||||
{ text: "Configure AI Models", link: "/guides/configure-ai-models" },
|
||||
{ text: "Use The Table Of Contents", link: "/guides/use-table-of-contents" },
|
||||
{ text: "Use Media Previews", link: "/guides/use-media-previews" },
|
||||
{ text: "Manage Display Preferences", link: "/guides/manage-display-preferences" },
|
||||
{ text: "Use The Command Palette", link: "/guides/use-command-palette" },
|
||||
],
|
||||
},
|
||||
{
|
||||
text: "Reference",
|
||||
items: [
|
||||
{ text: "Supported Platforms", link: "/reference/supported-platforms" },
|
||||
{ text: "File Layout", link: "/reference/file-layout" },
|
||||
{ text: "Frontmatter Fields", link: "/reference/frontmatter-fields" },
|
||||
{ text: "View Filters", link: "/reference/view-filters" },
|
||||
{ text: "Keyboard Shortcuts", link: "/reference/keyboard-shortcuts" },
|
||||
{ text: "Release Channels", link: "/reference/release-channels" },
|
||||
{ text: "Contribute", link: "/reference/contribute" },
|
||||
{ text: "Docs Maintenance", link: "/reference/docs-maintenance" },
|
||||
],
|
||||
},
|
||||
{
|
||||
text: "Troubleshooting",
|
||||
items: [
|
||||
{ text: "Vault Not Loading", link: "/troubleshooting/vault-not-loading" },
|
||||
{ text: "Git Authentication", link: "/troubleshooting/git-auth" },
|
||||
{ text: "AI Agent Not Found", link: "/troubleshooting/ai-agent-not-found" },
|
||||
{ text: "Model Provider Connection", link: "/troubleshooting/model-provider-connection" },
|
||||
{ text: "Sync Conflicts", link: "/troubleshooting/sync-conflicts" },
|
||||
],
|
||||
},
|
||||
],
|
||||
footer: {
|
||||
message: "Free and open source. Local-first, Git-first, and Markdown-based.",
|
||||
copyright:
|
||||
"Tolaria is AGPL-3.0-or-later. The Tolaria name and logo remain covered by the project trademark policy.",
|
||||
},
|
||||
},
|
||||
});
|
||||
1221
site/.vitepress/theme/LandingHome.vue
Normal file
135
site/.vitepress/theme/Layout.vue
Normal file
@@ -0,0 +1,135 @@
|
||||
<script setup lang="ts">
|
||||
import DefaultTheme from "vitepress/theme";
|
||||
import { onBeforeUnmount, onMounted, watchEffect } from "vue";
|
||||
import { useData } from "vitepress";
|
||||
|
||||
const { frontmatter } = useData();
|
||||
const githubStars = "9,946";
|
||||
|
||||
const scrollClass = "tolaria-scrolled";
|
||||
const landingPageClass = "tolaria-landing-page";
|
||||
const updateScrollClass = () => {
|
||||
document.documentElement.classList.toggle(scrollClass, window.scrollY > 8);
|
||||
};
|
||||
|
||||
watchEffect(() => {
|
||||
if (typeof document === "undefined") {
|
||||
return;
|
||||
}
|
||||
|
||||
document.documentElement.classList.toggle(
|
||||
landingPageClass,
|
||||
Boolean(frontmatter.value.landing),
|
||||
);
|
||||
});
|
||||
|
||||
onMounted(() => {
|
||||
updateScrollClass();
|
||||
window.addEventListener("scroll", updateScrollClass, { passive: true });
|
||||
});
|
||||
|
||||
onBeforeUnmount(() => {
|
||||
window.removeEventListener("scroll", updateScrollClass);
|
||||
document.documentElement.classList.remove(scrollClass);
|
||||
document.documentElement.classList.remove(landingPageClass);
|
||||
});
|
||||
</script>
|
||||
|
||||
<template>
|
||||
<div :class="{ 'tolaria-landing-shell': frontmatter.landing }">
|
||||
<DefaultTheme.Layout>
|
||||
<template #nav-bar-content-after>
|
||||
<a
|
||||
class="github-star-widget"
|
||||
href="https://github.com/refactoringhq/tolaria"
|
||||
target="_blank"
|
||||
rel="noreferrer"
|
||||
:aria-label="`${githubStars} GitHub stars`"
|
||||
>
|
||||
<svg viewBox="0 0 24 24" aria-hidden="true">
|
||||
<path
|
||||
fill-rule="evenodd"
|
||||
clip-rule="evenodd"
|
||||
d="M12 .5C5.65.5.5 5.65.5 12c0 5.09 3.29 9.39 7.86 10.91.58.1.79-.25.79-.56v-2c-3.2.7-3.88-1.54-3.88-1.54-.52-1.33-1.28-1.68-1.28-1.68-1.05-.72.08-.7.08-.7 1.16.08 1.77 1.19 1.77 1.19 1.03 1.76 2.7 1.25 3.36.96.1-.75.4-1.25.73-1.54-2.55-.29-5.23-1.28-5.23-5.68 0-1.25.45-2.28 1.19-3.08-.12-.29-.52-1.46.11-3.04 0 0 .97-.31 3.17 1.18A11 11 0 0 1 12 5.53c.98 0 1.97.13 2.89.39 2.2-1.49 3.17-1.18 3.17-1.18.63 1.58.23 2.75.11 3.04.74.8 1.19 1.83 1.19 3.08 0 4.41-2.69 5.38-5.25 5.67.41.36.78 1.06.78 2.14v3.18c0 .31.21.67.79.56A11.51 11.51 0 0 0 23.5 12C23.5 5.65 18.35.5 12 .5Z"
|
||||
/>
|
||||
</svg>
|
||||
<span>Star</span>
|
||||
<strong>{{ githubStars }}</strong>
|
||||
</a>
|
||||
</template>
|
||||
</DefaultTheme.Layout>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<style scoped>
|
||||
.github-star-widget {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
gap: 7px;
|
||||
height: 34px;
|
||||
margin-left: 8px;
|
||||
padding: 0 10px;
|
||||
border: 1px solid var(--vp-c-border);
|
||||
border-radius: 7px;
|
||||
color: var(--vp-c-text-1);
|
||||
background: var(--vp-c-bg-soft);
|
||||
font-size: 13px;
|
||||
font-weight: 700;
|
||||
line-height: 1;
|
||||
text-decoration: none;
|
||||
transition:
|
||||
border-color 160ms ease,
|
||||
background-color 160ms ease,
|
||||
color 160ms ease;
|
||||
}
|
||||
|
||||
.github-star-widget:hover {
|
||||
color: var(--vp-c-brand-1);
|
||||
border-color: color-mix(in srgb, var(--vp-c-brand-1) 38%, var(--vp-c-border));
|
||||
}
|
||||
|
||||
.github-star-widget svg {
|
||||
width: 18px;
|
||||
height: 18px;
|
||||
fill: currentColor;
|
||||
}
|
||||
|
||||
.github-star-widget strong {
|
||||
padding-left: 7px;
|
||||
border-left: 1px solid var(--vp-c-border);
|
||||
font-weight: 800;
|
||||
}
|
||||
|
||||
@media (min-width: 1280px) {
|
||||
.github-star-widget {
|
||||
order: 1;
|
||||
}
|
||||
|
||||
:global(.VPNavBar .appearance) {
|
||||
order: 2;
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-width: 767px) {
|
||||
.github-star-widget {
|
||||
height: 32px;
|
||||
margin-left: 4px;
|
||||
padding: 0 7px;
|
||||
font-size: 12px;
|
||||
}
|
||||
|
||||
.github-star-widget svg {
|
||||
width: 17px;
|
||||
height: 17px;
|
||||
}
|
||||
|
||||
.github-star-widget span {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.github-star-widget strong {
|
||||
padding-left: 0;
|
||||
border-left: 0;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
BIN
site/.vitepress/theme/assets/RefactoringSans.otf
Normal file
12
site/.vitepress/theme/index.ts
Normal file
@@ -0,0 +1,12 @@
|
||||
import DefaultTheme from "vitepress/theme";
|
||||
import LandingHome from "./LandingHome.vue";
|
||||
import Layout from "./Layout.vue";
|
||||
import "./styles.css";
|
||||
|
||||
export default {
|
||||
extends: DefaultTheme,
|
||||
Layout,
|
||||
enhanceApp({ app }) {
|
||||
app.component("LandingHome", LandingHome);
|
||||
},
|
||||
};
|
||||
230
site/.vitepress/theme/styles.css
Normal file
@@ -0,0 +1,230 @@
|
||||
@font-face {
|
||||
font-family: "RefactoringSans";
|
||||
src: url("./assets/RefactoringSans.otf") format("opentype");
|
||||
font-display: swap;
|
||||
font-style: normal;
|
||||
font-weight: 400 900;
|
||||
}
|
||||
|
||||
:root {
|
||||
--vp-font-family-base:
|
||||
"Inter", -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
|
||||
--vp-font-family-mono: "SF Mono", "Fira Code", ui-monospace, monospace;
|
||||
--tolaria-font-brand:
|
||||
"RefactoringSans", "Inter", -apple-system, BlinkMacSystemFont, sans-serif;
|
||||
--tolaria-bg: #faf9f5;
|
||||
--tolaria-surface: #ffffff;
|
||||
--tolaria-surface-muted: #f7f6f3;
|
||||
--tolaria-text: #1a1a18;
|
||||
--tolaria-text-secondary: #6b6b60;
|
||||
--tolaria-text-muted: #9b9b90;
|
||||
--tolaria-border: #e5e5e0;
|
||||
--tolaria-blue: #155dff;
|
||||
--tolaria-blue-hover: #4a5ad6;
|
||||
--tolaria-blue-soft: #e8eeff;
|
||||
--vp-c-bg: var(--tolaria-surface);
|
||||
--vp-c-bg-alt: var(--tolaria-surface-muted);
|
||||
--vp-c-bg-elv: var(--tolaria-surface);
|
||||
--vp-c-bg-soft: var(--tolaria-surface-muted);
|
||||
--vp-c-text-1: var(--tolaria-text);
|
||||
--vp-c-text-2: var(--tolaria-text-secondary);
|
||||
--vp-c-text-3: var(--tolaria-text-muted);
|
||||
--vp-c-border: var(--tolaria-border);
|
||||
--vp-c-divider: var(--tolaria-border);
|
||||
--vp-c-brand-1: var(--tolaria-blue);
|
||||
--vp-c-brand-2: var(--tolaria-blue-hover);
|
||||
--vp-c-brand-3: var(--tolaria-blue);
|
||||
--vp-c-brand-soft: var(--tolaria-blue-soft);
|
||||
--vp-button-brand-bg: var(--tolaria-blue);
|
||||
--vp-button-brand-hover-bg: var(--tolaria-blue-hover);
|
||||
--vp-button-brand-border: var(--tolaria-blue);
|
||||
--vp-code-bg: #eeeeea;
|
||||
--vp-code-color: var(--tolaria-text-secondary);
|
||||
}
|
||||
|
||||
.dark {
|
||||
--vp-c-bg: #1f1e1b;
|
||||
--vp-c-bg-alt: #191814;
|
||||
--vp-c-bg-elv: #23221f;
|
||||
--vp-c-bg-soft: #23221f;
|
||||
--vp-c-text-1: #e6e1d8;
|
||||
--vp-c-text-2: #b8b1a6;
|
||||
--vp-c-text-3: #7f776d;
|
||||
--vp-c-border: #34322d;
|
||||
--vp-c-divider: #34322d;
|
||||
--vp-c-brand-1: #78a4ff;
|
||||
--vp-c-brand-2: #9bbeff;
|
||||
--vp-c-brand-3: #78a4ff;
|
||||
--vp-c-brand-soft: rgba(120, 164, 255, 0.16);
|
||||
--vp-code-bg: #2d2b27;
|
||||
--vp-code-color: #d8d1c6;
|
||||
}
|
||||
|
||||
html,
|
||||
body,
|
||||
#app {
|
||||
background: var(--vp-c-bg);
|
||||
}
|
||||
|
||||
html.tolaria-landing-page,
|
||||
html.tolaria-landing-page body,
|
||||
html.tolaria-landing-page #app {
|
||||
background: var(--tolaria-bg);
|
||||
}
|
||||
|
||||
.VPNavBarTitle .logo {
|
||||
width: auto;
|
||||
height: 28px;
|
||||
}
|
||||
|
||||
.VPNavBarTitle .title {
|
||||
color: var(--vp-c-text-1);
|
||||
font-family: var(--tolaria-font-brand);
|
||||
font-size: 22px;
|
||||
font-weight: 800;
|
||||
letter-spacing: 0;
|
||||
}
|
||||
|
||||
.tolaria-landing-shell {
|
||||
--vp-c-bg: var(--tolaria-bg);
|
||||
--vp-nav-bg-color: var(--tolaria-bg);
|
||||
}
|
||||
|
||||
.tolaria-landing-shell .VPNav,
|
||||
.tolaria-landing-shell .VPNavBar,
|
||||
.tolaria-landing-shell .VPNavBar:not(.has-sidebar):not(.home.top),
|
||||
.tolaria-landing-shell .VPNavBar:not(.home.top) .content-body,
|
||||
.tolaria-landing-shell .VPNavBar .content-body {
|
||||
background: var(--tolaria-bg);
|
||||
background-color: var(--tolaria-bg);
|
||||
backdrop-filter: blur(14px);
|
||||
}
|
||||
|
||||
.tolaria-landing-shell .VPNavBar .wrapper,
|
||||
.tolaria-landing-shell .VPNavBar .container {
|
||||
width: min(100%, 1280px);
|
||||
max-width: 1280px;
|
||||
margin-right: auto;
|
||||
margin-left: auto;
|
||||
}
|
||||
|
||||
.tolaria-landing-shell .VPNavBar .wrapper {
|
||||
padding-right: 20px;
|
||||
padding-left: 20px;
|
||||
}
|
||||
|
||||
.tolaria-landing-shell .landing-container {
|
||||
width: min(100%, 1280px);
|
||||
}
|
||||
|
||||
@media (min-width: 768px) {
|
||||
.tolaria-landing-shell .VPNavBar .wrapper {
|
||||
padding-right: 40px;
|
||||
padding-left: 40px;
|
||||
}
|
||||
}
|
||||
|
||||
.tolaria-landing-shell .VPNavBar .divider,
|
||||
.tolaria-landing-shell .VPNavBar .divider-line {
|
||||
display: none;
|
||||
background-color: transparent;
|
||||
}
|
||||
|
||||
.tolaria-landing-shell .VPNavBar .divider-line {
|
||||
opacity: 0;
|
||||
transition: opacity 160ms ease;
|
||||
}
|
||||
|
||||
.VPNavBar {
|
||||
position: relative;
|
||||
z-index: calc(var(--vp-z-index-nav) + 2);
|
||||
}
|
||||
|
||||
.tolaria-landing-shell .VPLocalNav {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.VPNavScreen {
|
||||
display: block !important;
|
||||
visibility: visible !important;
|
||||
opacity: 1 !important;
|
||||
bottom: auto !important;
|
||||
height: calc(100vh - var(--vp-nav-height) - var(--vp-layout-top-height, 0px)) !important;
|
||||
z-index: calc(var(--vp-z-index-nav) + 1);
|
||||
background: var(--vp-c-bg);
|
||||
}
|
||||
|
||||
.tolaria-scrolled .tolaria-landing-shell .VPNav {
|
||||
box-shadow: 0 10px 24px rgba(26, 26, 24, 0.06);
|
||||
}
|
||||
|
||||
.tolaria-scrolled .tolaria-landing-shell .VPNavBar .divider-line {
|
||||
opacity: 1;
|
||||
}
|
||||
|
||||
.DocSearch-Button {
|
||||
border-radius: 999px;
|
||||
}
|
||||
|
||||
.tolaria-landing-shell .DocSearch-Button {
|
||||
border: 1px solid var(--tolaria-border);
|
||||
background: #fff;
|
||||
}
|
||||
|
||||
.vp-doc h1,
|
||||
.vp-doc h2,
|
||||
.vp-doc h3 {
|
||||
letter-spacing: 0;
|
||||
}
|
||||
|
||||
.vp-doc a,
|
||||
.VPNavBarMenuLink.active,
|
||||
.VPLink.active {
|
||||
color: var(--vp-c-brand-1);
|
||||
}
|
||||
|
||||
.vp-doc table {
|
||||
display: table;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
.vp-doc th {
|
||||
color: var(--vp-c-text-1);
|
||||
background: var(--vp-c-bg-soft);
|
||||
}
|
||||
|
||||
.vp-doc td,
|
||||
.vp-doc th {
|
||||
border-color: var(--vp-c-divider);
|
||||
}
|
||||
|
||||
.tolaria-landing-shell .VPContent,
|
||||
.tolaria-landing-shell .VPPage,
|
||||
.tolaria-landing-shell .VPDoc,
|
||||
.tolaria-landing-shell .VPDoc .container,
|
||||
.tolaria-landing-shell .VPDoc .content,
|
||||
.tolaria-landing-shell .VPDoc .content-container,
|
||||
.tolaria-landing-shell .VPDoc .main,
|
||||
.tolaria-landing-shell .vp-doc {
|
||||
max-width: none;
|
||||
padding: 0;
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
@media (min-width: 960px) {
|
||||
.tolaria-landing-shell .VPContent {
|
||||
padding-top: var(--vp-nav-height);
|
||||
}
|
||||
}
|
||||
|
||||
.tolaria-landing-shell .vp-doc > div {
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
.tolaria-landing-shell .vp-doc a {
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
.tolaria-landing-shell .VPFooter {
|
||||
display: none;
|
||||
}
|
||||
32
site/concepts/ai.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# AI
|
||||
|
||||
Tolaria has two AI paths: coding agents that can use tools to inspect and edit a vault, and direct model targets that answer in chat mode from note context.
|
||||
|
||||
## Coding Agents
|
||||
|
||||
The AI panel can stream supported local CLI agents through Tolaria's normalized event layer. Current targets include Claude Code, Codex, OpenCode, Pi, and Gemini CLI when they are installed on the machine.
|
||||
|
||||
Coding agents can run in:
|
||||
|
||||
- **Vault Safe** mode, limited to file, search, and edit tools.
|
||||
- **Power User** mode, which can allow local shell commands scoped to the active vault for agents that support shell access.
|
||||
|
||||
## Direct Models
|
||||
|
||||
Direct model targets run in chat mode. They receive the active note, linked context, and conversation history, but they do not receive vault-write tools or shell access.
|
||||
|
||||
Supported provider shapes include:
|
||||
|
||||
- Local models through Ollama or LM Studio.
|
||||
- Hosted providers such as OpenAI, Anthropic, Gemini, and OpenRouter.
|
||||
- Custom OpenAI-compatible endpoints.
|
||||
|
||||
## External MCP Setup
|
||||
|
||||
Tolaria exposes an MCP server for external tools. The setup flow can write Tolaria's MCP entry into Claude Code, Gemini CLI, Cursor, and a generic MCP config path, and it can also copy the exact JSON snippet for manual setup.
|
||||
|
||||
MCP setup is explicit. Closing the dialog leaves third-party config files untouched.
|
||||
|
||||
## Why Git Matters For AI
|
||||
|
||||
AI-generated changes should be inspectable. Git gives you diffs, history, rollback, and a clear boundary between suggestions and committed work.
|
||||
23
site/concepts/editor.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# Editor
|
||||
|
||||
Tolaria offers a rich editor for daily writing and a raw Markdown mode for exact file control. Both modes write back to the same Markdown file.
|
||||
|
||||
## Rich Editing
|
||||
|
||||
The rich editor supports blocks, slash commands, wikilinks, tables, code blocks, images, Mermaid diagrams, LaTeX-style math, and markdown-backed whiteboards.
|
||||
|
||||
Use it when you want to write and reorganize quickly without thinking about Markdown syntax.
|
||||
|
||||
## Raw Mode
|
||||
|
||||
Raw mode shows the Markdown source directly. Use it when you need to edit YAML frontmatter, repair unusual Markdown, or make an exact text change.
|
||||
|
||||
Toggle raw mode with `Cmd+\` on macOS or `Ctrl+\` on Windows and Linux.
|
||||
|
||||
## Table Of Contents
|
||||
|
||||
The table of contents panel builds an outline from headings in the current note. It is useful for long notes, procedures, research files, and generated documents. Toggle it with `Cmd+Shift+T` on macOS or `Ctrl+Shift+T` on Windows and Linux.
|
||||
|
||||
## Width
|
||||
|
||||
Notes can use normal or wide editor width. Set the default in Settings, or override an individual note from the editor toolbar.
|
||||
34
site/concepts/files-and-media.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Files And Media
|
||||
|
||||
Tolaria starts with Markdown notes, but a vault can also contain images, PDFs, media files, whiteboards, and other local files.
|
||||
|
||||
## Mermaid Diagrams
|
||||
|
||||
Use Mermaid code blocks when a note needs a diagram that should stay plain text and versionable.
|
||||
|
||||
````md
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Idea --> Draft --> Review --> Publish
|
||||
```
|
||||
````
|
||||
|
||||
Tolaria renders Mermaid diagrams in the editor while keeping the source in Markdown.
|
||||
|
||||
## Attachments
|
||||
|
||||
Images pasted into the editor are saved into the vault as normal files. They remain portable and can be opened by other tools.
|
||||
|
||||
## Previews
|
||||
|
||||
Tolaria can preview common image files, PDFs, and supported media files in the app. Files without an in-app preview can still be opened in the default system app.
|
||||
|
||||
Settings control whether PDFs, images, and unsupported files appear in All Notes. Folder browsing still shows files in their folders.
|
||||
|
||||
## Whiteboards
|
||||
|
||||
Whiteboards use tldraw in the editor, but their durable representation stays in Markdown. That keeps them inside the vault and versioned by Git with the rest of your notes.
|
||||
|
||||
## Git Boundary
|
||||
|
||||
If generated or local-only files are ignored by Git, Tolaria can hide them from notes, search, quick open, and folders. Use this when build artifacts or private local files should not behave like vault content.
|
||||
29
site/concepts/git.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# Git
|
||||
|
||||
Git is Tolaria's recommended history and sync layer. Tolaria can work with plain Markdown folders, and Git unlocks local history, recovery, remote backup, and multi-device workflows when you want them.
|
||||
|
||||
Tolaria acts as a lightweight Git client for your vault. You can review changes, commit, pull, push, and inspect history without leaving the app.
|
||||
|
||||
## What Tolaria Uses Git For
|
||||
|
||||
- Whole-vault commit history.
|
||||
- Current diff for the vault.
|
||||
- Per-note history.
|
||||
- Current diff for an individual note.
|
||||
- Pull and push.
|
||||
- Conflict detection and resolution.
|
||||
- Remote connection for local-only vaults.
|
||||
|
||||
## History And Diffs
|
||||
|
||||
Each note can show its own history and current diff, so you can understand how that file changed over time or what is unsaved relative to Git.
|
||||
|
||||
Tolaria also shows a history of the whole vault. Use it when you want to review broader changes across multiple notes before committing or syncing.
|
||||
|
||||
## Local Commits
|
||||
|
||||
You can commit changes inside Tolaria without leaving the app. This gives you useful restore points even before a remote is configured.
|
||||
|
||||
## Remotes
|
||||
|
||||
Connect a compatible Git remote when you want sync or backup. Tolaria relies on your system Git authentication, so GitHub CLI, SSH keys, credential helpers, and existing Git configuration can continue to work.
|
||||
23
site/concepts/inbox.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# Inbox
|
||||
|
||||
The Inbox is for notes that have been captured but not yet organized.
|
||||
|
||||
## Why It Exists
|
||||
|
||||
Fast capture should not require perfect structure. The Inbox gives you a place to put incomplete notes, then process them later.
|
||||
|
||||
The Inbox workflow is optional. Turn it off in Settings > Workflow if you prefer every note to appear organized by default.
|
||||
|
||||
## Organizing Inbox Notes
|
||||
|
||||
When reviewing the Inbox:
|
||||
|
||||
1. Give the note a clear H1.
|
||||
2. Set its `type`.
|
||||
3. Add status, dates, or URL if useful.
|
||||
4. Add relationships with wikilinks or frontmatter fields.
|
||||
5. Move it into a folder only if the folder adds value.
|
||||
|
||||
## Healthy Inbox Habit
|
||||
|
||||
Keep the Inbox small enough that it can be reviewed in one focused pass. Tolaria works best when capture is fast and organization is deliberate.
|
||||
34
site/concepts/notes.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Notes
|
||||
|
||||
A note is a Markdown file with optional YAML frontmatter. Tolaria reads the first H1 as the primary title and keeps the file on disk as the durable representation.
|
||||
|
||||
## Anatomy
|
||||
|
||||
```md
|
||||
---
|
||||
type: Project
|
||||
status: Active
|
||||
belongs_to:
|
||||
- "[[workspace]]"
|
||||
---
|
||||
|
||||
# Launch Documentation
|
||||
|
||||
Draft the public Tolaria docs and keep them close to code changes.
|
||||
```
|
||||
|
||||
## Titles
|
||||
|
||||
The first H1 is the note title. Tolaria uses that title wherever the note is displayed: note lists, search results, wikilink suggestions, relationship pickers, tabs, and window titles.
|
||||
|
||||
The title is separate from the filename. The filename stays visible in the breadcrumb so you can see the file on disk, and you can rename it independently when needed.
|
||||
|
||||
Use the breadcrumb action to rename the file to match the title. New untitled notes can also auto-rename from the first H1 the first time they get a real title. Turn this behavior off in Settings > Vault Content > Titles & Filenames if you prefer filenames to stay unchanged until you rename them manually.
|
||||
|
||||
## Body Links
|
||||
|
||||
Use `[[wikilinks]]` to connect notes from the body. Tolaria shows autocomplete suggestions while you type, and links can resolve by filename or title.
|
||||
|
||||
## Frontmatter
|
||||
|
||||
Use frontmatter for structured fields such as type, status, date, URL, and relationships. Keep free-form thinking in the body.
|
||||
26
site/concepts/properties.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Properties
|
||||
|
||||
Properties are frontmatter fields that Tolaria can display, filter, and edit.
|
||||
|
||||
## Suggested Properties
|
||||
|
||||
Suggested properties are the fields Tolaria knows how to create quickly from the Properties panel. When a suggested property is missing, the panel shows a shortcut to add it with the right editor.
|
||||
|
||||
| Field | Purpose |
|
||||
| --- | --- |
|
||||
| `type` | Groups the note into a type such as Project, Person, or Topic. |
|
||||
| `status` | Tracks lifecycle state such as Active, Done, or Blocked. |
|
||||
| `url` | Stores a canonical external link. |
|
||||
| `date` | Represents a single date. |
|
||||
|
||||
## System Properties
|
||||
|
||||
Fields that start with `_` are system properties. They remain in plain text but are hidden from normal property editing.
|
||||
|
||||
Examples include `_icon`, `_color`, `_order`, `_sidebar_label`, `_width`, and `_pinned_properties` on type documents or notes.
|
||||
|
||||
## Property Editing
|
||||
|
||||
The Properties panel is the safest place to edit structured properties. Toggle it with `Cmd+Shift+I` on macOS or `Ctrl+Shift+I` on Windows and Linux.
|
||||
|
||||
Date fields use Tolaria's picker, relationship fields can use wikilinks, and raw Markdown mode is available when you need direct control over YAML.
|
||||
32
site/concepts/relationships.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# Relationships
|
||||
|
||||
Relationships make a vault feel like a graph instead of a pile of documents.
|
||||
|
||||
## Relationship Fields
|
||||
|
||||
Any frontmatter field containing wikilinks can become a relationship. Relationship fields can point to one note or to an array of notes.
|
||||
|
||||
```yaml
|
||||
belongs_to:
|
||||
- "[[product-work]]"
|
||||
related_to:
|
||||
- "[[documentation]]"
|
||||
- "[[editor-research]]"
|
||||
blocked_by:
|
||||
- "[[release-process]]"
|
||||
- "[[sync-conflicts]]"
|
||||
```
|
||||
|
||||
Tolaria supports default relationship fields out of the box: `belongs_to`, `has`, and `related_to`. It also detects custom relationship fields dynamically when they contain wikilinks.
|
||||
|
||||
Default relationships have automatically computed inverses. If a note says it `belongs_to` a project, the project can show that note under its inverse `has` relationship without you writing the reverse link by hand. `related_to` works as a lateral relationship in both directions.
|
||||
|
||||
These outgoing and inverse relationships appear in the Properties panel and in Neighborhood mode, where the note list becomes a graph view around the selected note.
|
||||
|
||||
## Body Links Versus Relationship Fields
|
||||
|
||||
Use body links when the relationship appears naturally in writing. Use frontmatter relationships when the connection is important enough to show in navigation, filters, Neighborhood mode, or the Properties panel.
|
||||
|
||||
## Backlinks
|
||||
|
||||
Tolaria can show incoming links and inverse relationships, making it easier to navigate from a note to the rest of its context.
|
||||
49
site/concepts/types.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# Types
|
||||
|
||||
Types describe what kind of thing a note represents: Project, Person, Topic, Procedure, Event, or any category you create.
|
||||
|
||||
## Type Field
|
||||
|
||||
The `type:` field assigns a note to a type.
|
||||
|
||||
```yaml
|
||||
type: Project
|
||||
```
|
||||
|
||||
Tolaria does not infer type from folder location. Moving a file into another folder does not change its type.
|
||||
|
||||
## Prefer Types Over Folders
|
||||
|
||||
Types are the preferred way to group notes in Tolaria. Folders are supported for existing vaults and fallback organization, but Tolaria is built around types and relationships because they carry stronger meaning than file paths.
|
||||
|
||||
Use types for semantic groups such as Projects, People, Topics, Procedures, Events, and Essays. Use relationships to connect notes across those groups. This gives Tolaria better structure for navigation, filtering, properties, templates, and future automation than folder location alone.
|
||||
|
||||
## Type Documents
|
||||
|
||||
Type documents are Markdown notes with `type: Type` in frontmatter. They describe how a type should appear and what new notes of that type should start with.
|
||||
|
||||
```yaml
|
||||
---
|
||||
type: Type
|
||||
_icon: folder
|
||||
_color: blue
|
||||
_sidebar_label: Projects
|
||||
_order: 10
|
||||
---
|
||||
|
||||
# Project
|
||||
```
|
||||
|
||||
## What Types Control
|
||||
|
||||
- Sidebar grouping.
|
||||
- Type icon and color.
|
||||
- Sidebar order and label.
|
||||
- Pinned properties.
|
||||
- New-note templates.
|
||||
|
||||
## New Note Defaults
|
||||
|
||||
Type documents can define empty properties and relationships. When you create a new note of that type, Tolaria shows placeholders for those fields so you can fill them in from the Properties panel.
|
||||
|
||||
If a type document gives a property a value, that value becomes the default for new notes of that type. For example, a Project type can define `status: Active` so every new project starts active until you change it.
|
||||
35
site/concepts/vaults.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# Vaults
|
||||
|
||||
A vault is the folder Tolaria reads and writes. The filesystem is the source of truth; the app state and cache are derived from files.
|
||||
|
||||
## Core Rules
|
||||
|
||||
- Notes are Markdown files.
|
||||
- YAML frontmatter provides structure.
|
||||
- Attachments are normal files inside the vault.
|
||||
- Type definitions and saved views are also files.
|
||||
- Git can track history and support remote sync.
|
||||
|
||||
## Why Local Files Matter
|
||||
|
||||
Local files keep your notes inspectable. You can open them in another editor, search with command-line tools, back them up with your own system, and version them with Git.
|
||||
|
||||
Tolaria should never become the only way to read your data.
|
||||
|
||||
## Git Is A Capability
|
||||
|
||||
A plain folder of Markdown files can open as a vault. Git-backed vaults unlock history, changes, commits, pull, push, conflict handling, and remote setup.
|
||||
|
||||
If a folder is not a Git repository, Tolaria can initialize Git when you explicitly ask it to. It avoids initializing broad personal folders such as Desktop, Documents, or Downloads unless they are clearly dedicated vault folders.
|
||||
|
||||
## App State Versus Vault State
|
||||
|
||||
Vault-level information should travel with the vault. Machine-specific preferences stay with the app installation.
|
||||
|
||||
| Vault state | App state |
|
||||
| --- | --- |
|
||||
| Type icons and colors | Editor zoom |
|
||||
| Saved views | Window size |
|
||||
| Pinned properties | Recent vault list |
|
||||
| Relationship conventions | Local cache |
|
||||
| Vault AI guidance files | AI target selection |
|
||||
19
site/download/index.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# Download
|
||||
|
||||
Download Tolaria from the latest stable release.
|
||||
|
||||
## Latest Stable
|
||||
|
||||
[Open the installer download page](https://refactoringhq.github.io/tolaria/download/)
|
||||
|
||||
The download page reads the latest stable release metadata and points you to the current macOS, Windows, or Linux artifact.
|
||||
|
||||
## Other Builds
|
||||
|
||||
- [Browse all GitHub releases](https://github.com/refactoringhq/tolaria/releases)
|
||||
- [Read release history](/releases/)
|
||||
- [Learn release channels](/reference/release-channels)
|
||||
|
||||
## Verify The Version
|
||||
|
||||
After launching the app, check the version shown in Tolaria's status bar or release surface.
|
||||
25
site/guides/build-custom-views.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Build Custom Views
|
||||
|
||||
Custom views are saved filters for recurring questions.
|
||||
|
||||
## Good View Candidates
|
||||
|
||||
- Active projects.
|
||||
- People without a recent follow-up.
|
||||
- Drafts ready for review.
|
||||
- Notes changed this week.
|
||||
- Events in a date range.
|
||||
|
||||
## View Definition
|
||||
|
||||
Saved views live as files in the vault. They describe filters, sorting, and visible columns using structured data.
|
||||
|
||||
## Filters
|
||||
|
||||
Custom views can use nested conditions, similar to Notion or Airtable filter groups. Combine `all` and `any` logic when a view needs to answer a more precise question than a single field filter can express.
|
||||
|
||||
Date filters support dynamic natural-language values such as `today`, `yesterday`, or `one week ago`. Use these for views that should keep moving over time, such as recent work, stale follow-ups, or upcoming events.
|
||||
|
||||
## Design The Question First
|
||||
|
||||
Before creating a view, write the question it answers. A good view is not "all fields with all filters"; it is a focused lens.
|
||||
18
site/guides/capture-a-note.md
Normal file
@@ -0,0 +1,18 @@
|
||||
# Capture A Note
|
||||
|
||||
Use capture when you need to get an idea into the vault before you know where it belongs.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Press `Cmd+N` on macOS or `Ctrl+N` on Windows and Linux.
|
||||
2. Write a clear H1.
|
||||
3. Add the rough content.
|
||||
4. Leave structure for later if you are still thinking.
|
||||
|
||||
## Capture Well
|
||||
|
||||
Prefer a useful title over a perfect taxonomy. You can add type, status, and relationships during inbox review.
|
||||
|
||||
## When To Add Structure Immediately
|
||||
|
||||
Add structure while capturing when the note's type or relationships are already obvious. Otherwise, capture the idea first and organize it later.
|
||||
23
site/guides/commit-and-push.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# Manage Git Manually Or With AutoGit
|
||||
|
||||
Tolaria can act as a lightweight Git client for a Git-enabled vault. You can manage commits and pushes yourself, or enable AutoGit to create conservative checkpoints after editing pauses or when the app is no longer active.
|
||||
|
||||
## Manual Git
|
||||
|
||||
1. Open the Git or changes surface.
|
||||
2. Review changed files.
|
||||
3. Write a short commit message.
|
||||
4. Commit locally.
|
||||
5. Push when a remote is configured.
|
||||
|
||||
If the remote has changed, pull first and resolve any conflicts. If the vault has no remote, manual commits still give you local history, diffs, and rollback.
|
||||
|
||||
## AutoGit
|
||||
|
||||
AutoGit is available in Settings for Git-enabled vaults. When enabled, Tolaria automatically commits and pushes saved local changes after an idle pause or after the app becomes inactive.
|
||||
|
||||
Use AutoGit when you want the safety of regular checkpoints without interrupting capture or editing. You can still inspect each note's current diff, review note history, and browse the whole-vault history before making larger manual commits.
|
||||
|
||||
## Use Small Commits
|
||||
|
||||
Small commits make it easier to understand what changed, roll back safely, and review AI-generated edits.
|
||||
25
site/guides/configure-ai-models.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Configure AI Models
|
||||
|
||||
Use model providers when you want chat over note context without giving an agent vault-write tools.
|
||||
|
||||
## Local Models
|
||||
|
||||
Local model targets are for tools such as Ollama and LM Studio. They usually need a base URL and model ID, and they usually do not need an API key.
|
||||
|
||||
## API Models
|
||||
|
||||
API model targets are for hosted providers such as OpenAI, Anthropic, Gemini, OpenRouter, or another OpenAI-compatible endpoint.
|
||||
|
||||
Tolaria does not store provider API keys in vault settings. Choose one of the supported key paths:
|
||||
|
||||
- Save the key locally on this device.
|
||||
- Read the key from an environment variable.
|
||||
- Use no key for local providers that do not require one.
|
||||
|
||||
## Test The Connection
|
||||
|
||||
After adding a provider, use the test action in Settings. A successful test means Tolaria reached the endpoint and the model replied.
|
||||
|
||||
## Select The Target
|
||||
|
||||
Once configured, choose the model from the AI target selector or set it as the default AI target in Settings.
|
||||
23
site/guides/connect-a-git-remote.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# Connect A Git Remote
|
||||
|
||||
Connect a remote when you want backup or sync beyond the current machine.
|
||||
|
||||
## Before You Start
|
||||
|
||||
Make sure the remote repository exists and your system Git can authenticate to it. Tolaria uses system Git rather than storing provider-specific credentials.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Open the bottom status bar remote chip, or run `Add Remote` from the command palette.
|
||||
2. Paste the remote URL.
|
||||
3. Confirm the remote name.
|
||||
4. Fetch or push according to the app prompt.
|
||||
|
||||
## Recommended Auth
|
||||
|
||||
- SSH keys.
|
||||
- GitHub CLI authentication.
|
||||
- Existing Git credential helpers.
|
||||
- macOS Keychain credentials for HTTPS remotes on macOS.
|
||||
|
||||
If authentication fails, see [Git Authentication](/troubleshooting/git-auth).
|
||||
33
site/guides/create-types.md
Normal file
@@ -0,0 +1,33 @@
|
||||
# Create Types
|
||||
|
||||
Create a type when several notes share the same role in your system.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Run `New Type` from the command palette, or click `+` in the Types header in the sidebar.
|
||||
2. Give the type a clear name.
|
||||
3. Add optional icon, color, sidebar order, sidebar label, pinned properties, suggested fields, default values, or a new-note template.
|
||||
|
||||
You can also right-click a type in the sidebar to change its icon and color.
|
||||
|
||||
```yaml
|
||||
---
|
||||
type: Type
|
||||
_icon: briefcase
|
||||
_color: blue
|
||||
_sidebar_label: Projects
|
||||
_order: 10
|
||||
---
|
||||
|
||||
# Project
|
||||
```
|
||||
|
||||
## Use Types Sparingly
|
||||
|
||||
A type should represent a recurring category, not a one-off label. If you only need a temporary grouping, use a saved view or property instead.
|
||||
|
||||
## Templates
|
||||
|
||||
Type documents can include a Markdown template for new notes of that type. Keep templates small and useful: a heading, a few expected fields, and the first checklist are usually enough.
|
||||
|
||||
Type documents can also define fields for new notes. Empty properties and relationships become placeholders in new notes of that type. Properties with values become defaults for new notes of that type.
|
||||
26
site/guides/manage-display-preferences.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Manage Display Preferences
|
||||
|
||||
Display preferences live in local app settings unless a setting is intentionally stored in the note or vault.
|
||||
|
||||
## Theme
|
||||
|
||||
Choose Light, Dark, or System in Settings. System follows the operating system appearance at runtime.
|
||||
|
||||
You can also switch theme mode from the command palette.
|
||||
|
||||
## Note Width
|
||||
|
||||
Set the default rich-editor width in Settings:
|
||||
|
||||
- **Normal** for focused writing.
|
||||
- **Wide** for tables, diagrams, dense notes, and generated documents.
|
||||
|
||||
An individual note can override the default width from the editor toolbar. That override is stored as `_width` in the note frontmatter.
|
||||
|
||||
## Sidebar Labels
|
||||
|
||||
Tolaria can pluralize type names in the sidebar. Turn this off in Settings if your type names should be shown exactly as written, or use `_sidebar_label` on a type document for an explicit label.
|
||||
|
||||
## Vault Content
|
||||
|
||||
Settings also control whether Gitignored files and non-Markdown file categories are visible in the app. Use these controls to keep generated or local-only files out of regular note workflows.
|
||||
31
site/guides/organize-inbox.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# Organize The Inbox
|
||||
|
||||
Inbox review turns quick captures into usable knowledge.
|
||||
|
||||
## Remove A Note From Inbox
|
||||
|
||||
When a note is organized enough, mark it as organized. Use `Cmd+E` on macOS or `Ctrl+E` on Windows and Linux, or click the organize action in the breadcrumb bar.
|
||||
|
||||
That action is what removes the note from Inbox. If auto-advance is enabled in Settings > Workflow, Tolaria opens the next Inbox item immediately after you mark the current note organized.
|
||||
|
||||
## Review Checklist
|
||||
|
||||
- Rename unclear notes.
|
||||
- Add or correct the first H1.
|
||||
- Set `type`.
|
||||
- Add `status` for actionable notes.
|
||||
- Add `belongs_to`, `related_to`, or other relationship fields when useful.
|
||||
- Archive or delete notes that no longer matter.
|
||||
|
||||
## Make Notes Navigable
|
||||
|
||||
A note is organized when you can answer:
|
||||
|
||||
- What kind of thing is this?
|
||||
- What is it connected to?
|
||||
- What is this useful for?
|
||||
- What will I do with it?
|
||||
|
||||
## Avoid Over-Structuring
|
||||
|
||||
Do not add fields just because they exist. Add the structure that will help future navigation, review, or automation.
|
||||
38
site/guides/use-ai-panel.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# Use The AI
|
||||
|
||||
Tolaria gives you two ways to ask for AI help: open the AI panel for an ongoing conversation, or prompt directly from the editor with `Cmd+K` followed by a space.
|
||||
|
||||
## Choose How To Prompt
|
||||
|
||||
- **AI panel** is best for longer conversations, agent work, and requests that need visible back-and-forth.
|
||||
- **Inline prompt** is best when you are already writing. Press `Cmd+K`, type a space, then write the prompt you want the AI to handle from the current note context.
|
||||
|
||||
## Choose A Target
|
||||
|
||||
Open Settings and choose the default AI target:
|
||||
|
||||
- **Coding agent** for tool-backed vault editing through Claude Code, Codex, OpenCode, Pi, or Gemini CLI.
|
||||
- **Local model** for Ollama or LM Studio chat over note context.
|
||||
- **API model** for OpenAI, Anthropic, Gemini, OpenRouter, or an OpenAI-compatible endpoint.
|
||||
|
||||
If a coding agent is missing, install it and reopen Tolaria or switch to another target.
|
||||
|
||||
## Permission Mode
|
||||
|
||||
Coding agents support per-vault permission modes:
|
||||
|
||||
- **Vault Safe** keeps agents limited to file, search, and edit tools.
|
||||
- **Power User** can allow shell commands for agents that support them.
|
||||
|
||||
Direct model targets always stay in chat mode. They can use note context, but they cannot edit vault files through tools.
|
||||
|
||||
## Good Requests
|
||||
|
||||
- "Find notes related to this project."
|
||||
- "Summarize what changed in this note."
|
||||
- "Draft a weekly review from these linked notes."
|
||||
- "Update this checklist based on the current project status."
|
||||
|
||||
## Review Changes
|
||||
|
||||
AI edits are file edits. Review them with Tolaria's diff and Git history before committing.
|
||||
26
site/guides/use-command-palette.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Use The Command Palette
|
||||
|
||||
The command palette is the fastest way to move around Tolaria.
|
||||
|
||||
Open it with:
|
||||
|
||||
- `Cmd+K` on macOS.
|
||||
- `Ctrl+K` on Linux and Windows.
|
||||
|
||||
## Common Commands
|
||||
|
||||
- New Note.
|
||||
- Search.
|
||||
- Open Settings.
|
||||
- Reload Vault.
|
||||
- Add Remote.
|
||||
- Open Getting Started Vault.
|
||||
- Toggle Raw Mode.
|
||||
- Toggle Table of Contents.
|
||||
- Toggle AI Panel.
|
||||
- Use Light, Dark, or System theme.
|
||||
- Open in New Window.
|
||||
|
||||
## Keyboard-First Workflow
|
||||
|
||||
Use the palette when you know what you want to do but do not want to hunt through panels. It is also the best place to discover commands as the app grows.
|
||||
25
site/guides/use-media-previews.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Use Media Previews
|
||||
|
||||
Media previews let you inspect vault files without leaving Tolaria.
|
||||
|
||||
## Open A File
|
||||
|
||||
Select an image, PDF, media file, or unsupported file from a folder or file list. Tolaria opens supported files in the app and offers an external-open action for files that should use the system default app.
|
||||
|
||||
## All Notes Visibility
|
||||
|
||||
Open Settings to choose whether non-Markdown files appear in All Notes:
|
||||
|
||||
- PDFs.
|
||||
- Images.
|
||||
- Unsupported files.
|
||||
|
||||
Folder browsing still shows files in their folders even when a category is hidden from All Notes.
|
||||
|
||||
## Attachments
|
||||
|
||||
When you paste or drop an image into a note, Tolaria copies it into the vault and references the copied file from Markdown.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If a preview does not render, open the file in the default app to confirm the file is valid, then check whether the file is inside the active vault and not blocked by operating-system permissions.
|
||||
23
site/guides/use-table-of-contents.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# Use The Table Of Contents
|
||||
|
||||
The table of contents panel helps you navigate long notes by heading.
|
||||
|
||||
## Open It
|
||||
|
||||
Use the editor toolbar, the command palette, or the shortcut:
|
||||
|
||||
- `Cmd+Shift+T` on macOS.
|
||||
- `Ctrl+Shift+T` on Windows and Linux.
|
||||
|
||||
## How It Works
|
||||
|
||||
Tolaria builds the outline from the current note's headings. The panel updates as the note changes and can jump to sections in the editor.
|
||||
|
||||
## Good Uses
|
||||
|
||||
- Long procedures.
|
||||
- Meeting notes with many sections.
|
||||
- Research notes.
|
||||
- Generated documents that need review.
|
||||
|
||||
If a note has no useful headings, add clear H2 and H3 sections rather than relying on a long uninterrupted document.
|
||||
24
site/guides/use-wikilinks.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Use Wikilinks
|
||||
|
||||
Wikilinks connect notes by name.
|
||||
|
||||
```md
|
||||
This project belongs to [[content-systems]] and is related to [[git-workflows]].
|
||||
```
|
||||
|
||||
## Link From The Body
|
||||
|
||||
Use body links when the connection is part of the sentence you are writing.
|
||||
|
||||
## Link From Frontmatter
|
||||
|
||||
Use frontmatter links when the relationship should become structured metadata.
|
||||
|
||||
```yaml
|
||||
related_to:
|
||||
- "[[git-workflows]]"
|
||||
```
|
||||
|
||||
## Keep Links Stable
|
||||
|
||||
Prefer clear note titles and filenames. Tolaria's wikilink autocomplete helps you pick the right target while you type.
|
||||
10
site/index.md
Normal file
@@ -0,0 +1,10 @@
|
||||
---
|
||||
layout: page
|
||||
sidebar: false
|
||||
aside: false
|
||||
landing: true
|
||||
title: Tolaria
|
||||
description: A second brain for the AI era. Free forever.
|
||||
---
|
||||
|
||||
<LandingHome />
|
||||
BIN
site/public/landing/Ai chat 3.png
Normal file
|
After Width: | Height: | Size: 726 KiB |
BIN
site/public/landing/Block editor.png
Normal file
|
After Width: | Height: | Size: 214 KiB |
BIN
site/public/landing/Luca hello.jpeg
Normal file
|
After Width: | Height: | Size: 287 KiB |
BIN
site/public/landing/ananth.webp
Normal file
|
After Width: | Height: | Size: 13 KiB |
BIN
site/public/landing/favicon.png
Normal file
|
After Width: | Height: | Size: 17 KiB |
BIN
site/public/landing/git-history.png
Normal file
|
After Width: | Height: | Size: 50 KiB |
BIN
site/public/landing/gregor.webp
Normal file
|
After Width: | Height: | Size: 4.7 KiB |
BIN
site/public/landing/jordan.webp
Normal file
|
After Width: | Height: | Size: 1.1 KiB |
BIN
site/public/landing/les-saintes.jpg
Normal file
|
After Width: | Height: | Size: 785 KiB |
BIN
site/public/landing/pulse.png
Normal file
|
After Width: | Height: | Size: 234 KiB |
BIN
site/public/landing/relationships.png
Normal file
|
After Width: | Height: | Size: 279 KiB |
BIN
site/public/landing/simply-files.png
Normal file
|
After Width: | Height: | Size: 287 KiB |
BIN
site/public/landing/tolaria-icon.png
Normal file
|
After Width: | Height: | Size: 13 KiB |
BIN
site/public/landing/tolaria-screenshot-dark.png
Normal file
|
After Width: | Height: | Size: 927 KiB |
BIN
site/public/landing/tolaria-screenshot.png
Normal file
|
After Width: | Height: | Size: 925 KiB |
BIN
site/public/landing/track changes and push.png
Normal file
|
After Width: | Height: | Size: 401 KiB |
BIN
site/public/landing/wikilinks.png
Normal file
|
After Width: | Height: | Size: 157 KiB |
BIN
site/public/landing/yaml frontmatter.png
Normal file
|
After Width: | Height: | Size: 179 KiB |
10
site/public/tolaria-icon.svg
Normal file
@@ -0,0 +1,10 @@
|
||||
<svg width="266" height="363" viewBox="0 0 266 363" fill="none" xmlns="http://www.w3.org/2000/svg">
|
||||
<g clip-path="url(#clip0_111_151)">
|
||||
<path fill-rule="evenodd" clip-rule="evenodd" d="M119.524 5.31219C126.607 -1.77073 138.117 -1.77073 145.2 5.31219C178.844 40.7268 265.61 147.856 265.61 230.195C265.61 303.68 206.29 363 132.805 363C59.3195 363 0 303.68 0 230.195C0 147.856 86.7659 40.7268 119.524 5.31219ZM59.5947 242.88C58.1619 234.744 50.3952 229.074 42.2195 230.195C34.0438 231.316 28.5932 238.799 30.0259 246.935C37.6847 290.425 72.2734 325.622 116.094 334.485C117.821 334.836 119.552 334.864 121.178 334.641C127.269 333.806 132.289 329.26 133.371 322.934C134.756 314.893 129.25 307.054 121.086 305.401C89.7767 299.057 65.0615 273.923 59.5947 242.88Z" fill="#155DFF"/>
|
||||
</g>
|
||||
<defs>
|
||||
<clipPath id="clip0_111_151">
|
||||
<rect width="266" height="363" fill="white"/>
|
||||
</clipPath>
|
||||
</defs>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 889 B |
23
site/reference/contribute.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# Contribute
|
||||
|
||||
Tolaria is free and open source, and any kind of help is useful. Pick the path that matches what you want to do.
|
||||
|
||||
## Sponsor Or Support
|
||||
|
||||
The best way to support Tolaria is to subscribe to [Refactoring](https://refactoring.fm/), Luca's newsletter and community about running good teams and shipping software with AI.
|
||||
|
||||
## Feature Requests
|
||||
|
||||
Use the [product board](https://tolaria.canny.io/) for feature ideas. Search first, upvote existing ideas, and create a new post when the request is genuinely new.
|
||||
|
||||
## Discussions
|
||||
|
||||
Use [GitHub Discussions](https://github.com/refactoringhq/tolaria/discussions) for questions, conversations, show and tell, and broader community context.
|
||||
|
||||
## Contribute Code
|
||||
|
||||
Small, focused pull requests are welcome. Check the product board first so you build the right thing, then open a PR on [GitHub](https://github.com/refactoringhq/tolaria/pulls). The [contributing guide](https://github.com/refactoringhq/tolaria/blob/main/CONTRIBUTING.md) explains the local workflow.
|
||||
|
||||
## Report A Bug
|
||||
|
||||
Use [GitHub Issues](https://github.com/refactoringhq/tolaria/issues) for bugs. Include what happened, what you expected, and clear reproduction steps. If you are reporting from inside Tolaria, use the Contribute panel to copy sanitized diagnostics and attach them to the issue.
|
||||
38
site/reference/docs-maintenance.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# Docs Maintenance
|
||||
|
||||
The public docs live in the app repo so documentation changes can ship with behavior changes.
|
||||
|
||||
## Update Docs When You Change
|
||||
|
||||
- A Tauri command.
|
||||
- A new component or hook that changes user behavior.
|
||||
- A data model or frontmatter convention.
|
||||
- Git, AI, onboarding, or release behavior.
|
||||
- Public release pages, download metadata, or updater channels.
|
||||
- Platform support.
|
||||
- Keyboard shortcuts.
|
||||
|
||||
## Suggested Workflow
|
||||
|
||||
1. Make the code change.
|
||||
2. Update the matching concept, guide, or reference page.
|
||||
3. Add a troubleshooting page if the change creates a new failure mode.
|
||||
4. Run `pnpm docs:build`.
|
||||
5. Check the home page, search, release/download links, and changed docs pages in a browser.
|
||||
|
||||
## Page Types
|
||||
|
||||
| Type | Purpose |
|
||||
| --- | --- |
|
||||
| Start | Helps a new user get into the app. |
|
||||
| Concepts | Explains mental models. |
|
||||
| Guides | Teaches workflows. |
|
||||
| Reference | Gives stable facts and tables. |
|
||||
| Troubleshooting | Starts from a symptom and ends with recovery. |
|
||||
|
||||
## Review Checklist
|
||||
|
||||
- Does the page describe current behavior?
|
||||
- Does it mention macOS primary and Windows/Linux supported-early status when platform support matters?
|
||||
- Are links relative and VitePress-compatible?
|
||||
- Can a user discover the page with local search?
|
||||
41
site/reference/file-layout.md
Normal file
@@ -0,0 +1,41 @@
|
||||
# File Layout
|
||||
|
||||
Tolaria is not opinionated about folder structure. It finds notes recursively across the whole vault, stores new notes in the root by default, and uses types and relationships for real organization.
|
||||
|
||||
```txt
|
||||
my-vault/
|
||||
project-alpha.md
|
||||
weekly-review.md
|
||||
research/
|
||||
source-notes.md
|
||||
attachments/
|
||||
diagram.png
|
||||
source.pdf
|
||||
project.md
|
||||
person.md
|
||||
views/
|
||||
active-projects.yml
|
||||
```
|
||||
|
||||
## Root Notes
|
||||
|
||||
Tolaria works well with a flat vault. Folders are optional and can be useful for compatibility with other tools, but they are not required for people, projects, topics, or any other note category.
|
||||
|
||||
Type is not inferred from folder location. It comes from frontmatter, and relationships are expressed with wikilinks in fields. That is what Tolaria uses for the sidebar, Properties panel, search, custom views, and neighborhood navigation.
|
||||
|
||||
## Special Folders
|
||||
|
||||
| Folder | Purpose |
|
||||
| --- | --- |
|
||||
| `views/` | Saved custom views. |
|
||||
| `attachments/` | Images and other attached files. |
|
||||
|
||||
PDFs, images, and other non-Markdown files stay as normal files. Folder browsing can show them in place, and Settings controls whether PDFs, images, and unsupported files appear in All Notes.
|
||||
|
||||
Whiteboards are Markdown files with durable tldraw data, so they belong with notes rather than in `attachments/`.
|
||||
|
||||
Type definitions are Markdown notes with `type: Type` in frontmatter. New type documents are normal notes, and existing type documents in older folders still work.
|
||||
|
||||
## Git Files
|
||||
|
||||
If the vault is a Git repository, `.git/` belongs to Git. Tolaria reads Git state but does not treat `.git/` as notes.
|
||||
26
site/reference/frontmatter-fields.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Frontmatter Fields
|
||||
|
||||
Tolaria uses conventions instead of a required schema.
|
||||
|
||||
| Field | Meaning |
|
||||
| --- | --- |
|
||||
| `type` | The note's entity type. |
|
||||
| `status` | Lifecycle state. |
|
||||
| `icon` | Per-note icon. |
|
||||
| `url` | External URL. |
|
||||
| `date` | Single date. |
|
||||
| `belongs_to` | Parent relationship. |
|
||||
| `related_to` | Lateral relationship. |
|
||||
| `has` | Contained relationship. |
|
||||
| `_width` | Per-note editor width override. |
|
||||
| `_icon`, `_color` | Type or note appearance metadata. |
|
||||
| `_sidebar_label`, `_order` | Type sidebar label and order. |
|
||||
| `_pinned_properties` | Properties pinned for a type. |
|
||||
|
||||
## Custom Fields
|
||||
|
||||
You can add your own fields. If a field contains wikilinks, Tolaria can treat it as a relationship.
|
||||
|
||||
## System Fields
|
||||
|
||||
Fields starting with `_` are reserved for system behavior and hidden from standard property editing. They remain plain YAML, so they can still be inspected or changed in raw mode when needed.
|
||||
24
site/reference/keyboard-shortcuts.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Keyboard Shortcuts
|
||||
|
||||
| Shortcut | Action |
|
||||
| --- | --- |
|
||||
| `Cmd+K` / `Ctrl+K` | Open command palette. |
|
||||
| `Cmd+P` / `Ctrl+P` | Quick open notes and files. |
|
||||
| `Cmd+N` / `Ctrl+N` | Create a new note. |
|
||||
| `Cmd+S` / `Ctrl+S` | Save current note. |
|
||||
| `Cmd+F` / `Ctrl+F` | Find in the current note. |
|
||||
| `Cmd+Shift+F` / `Ctrl+Shift+F` | Search the vault. |
|
||||
| `Cmd+Shift+V` / `Ctrl+Shift+V` | Paste without formatting. |
|
||||
| `Cmd+\` / `Ctrl+\` | Toggle raw Markdown mode. |
|
||||
| `Cmd+Shift+T` / `Ctrl+Shift+T` | Toggle table of contents. |
|
||||
| `Cmd+Shift+I` / `Ctrl+Shift+I` | Toggle Properties panel. |
|
||||
| `Cmd+Shift+L` / `Ctrl+Shift+L` | Toggle AI panel. |
|
||||
| `Cmd+[` / `Alt+Left` | Navigate back when available. |
|
||||
| `Cmd+]` / `Alt+Right` | Navigate forward when available. |
|
||||
| `Cmd+Shift+O` / `Ctrl+Shift+O` | Open current note in a new window. |
|
||||
| `Cmd+D` / `Ctrl+D` | Toggle favorite for the current note. |
|
||||
| `Cmd+E` / `Ctrl+E` | Mark the current Inbox note organized. |
|
||||
|
||||
Some shortcuts vary by platform because macOS, Linux, and Windows reserve different key combinations.
|
||||
|
||||
Use the command palette to discover the current command set.
|
||||
36
site/reference/release-channels.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# Release Channels
|
||||
|
||||
Tolaria publishes Stable and Alpha release metadata to GitHub Pages.
|
||||
|
||||
## Stable
|
||||
|
||||
Stable follows manually promoted releases. This is the right channel for normal use.
|
||||
|
||||
The stable updater metadata lives at:
|
||||
|
||||
```txt
|
||||
/stable/latest.json
|
||||
```
|
||||
|
||||
The public download page points at the latest stable release.
|
||||
|
||||
## Alpha
|
||||
|
||||
Alpha follows pushes to `main`. It receives fixes and features earlier, but it can be rougher than Stable.
|
||||
|
||||
The alpha updater metadata lives at:
|
||||
|
||||
```txt
|
||||
/alpha/latest.json
|
||||
```
|
||||
|
||||
Compatibility endpoints also point to the alpha metadata:
|
||||
|
||||
```txt
|
||||
/latest.json
|
||||
/latest-canary.json
|
||||
```
|
||||
|
||||
## Before Switching
|
||||
|
||||
Commit or push important vault changes before changing release channel or installing an update. Your notes are local files, but a clean Git state makes recovery simpler.
|
||||
23
site/reference/supported-platforms.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# Supported Platforms
|
||||
|
||||
Tolaria is a desktop app built with Tauri. Releases currently target macOS, Windows, and Linux.
|
||||
|
||||
| Platform | Current support | Notes |
|
||||
| --- | --- | --- |
|
||||
| macOS | Primary | Main development and QA target. Apple Silicon and Intel artifacts are published. |
|
||||
| Windows | Supported, early | NSIS installers and signed updater bundles are published. Menu, shell-path, and credential-helper behavior receive platform-specific fixes as they appear. |
|
||||
| Linux | Supported, early | AppImage and deb artifacts are published. Behavior can depend on distro WebKitGTK packages, Wayland/X11 details, and input-method setup. |
|
||||
|
||||
## Support Policy
|
||||
|
||||
Primary support means the platform is part of normal development and release validation. Supported, early means release artifacts exist and the app is expected to work, but platform-specific bugs can take longer to diagnose than macOS issues.
|
||||
|
||||
## Reporting Platform Bugs
|
||||
|
||||
Include:
|
||||
|
||||
- Tolaria version.
|
||||
- Operating system and version.
|
||||
- CPU architecture.
|
||||
- Whether the vault is local-only or connected to a remote.
|
||||
- Steps to reproduce.
|
||||
33
site/reference/view-filters.md
Normal file
@@ -0,0 +1,33 @@
|
||||
# View Filters
|
||||
|
||||
View filters define saved lists of notes.
|
||||
|
||||
## Common Filter Ideas
|
||||
|
||||
| Goal | Filter direction |
|
||||
| --- | --- |
|
||||
| Active projects | `type` is Project and `status` is Active |
|
||||
| Drafts | `type` is Article and `status` is Draft |
|
||||
| People follow-up | `type` is Person and date is before today |
|
||||
| Recent work | modified date is within a recent range |
|
||||
|
||||
## Sorting
|
||||
|
||||
Useful sorts include:
|
||||
|
||||
- Recently modified first.
|
||||
- Title ascending.
|
||||
- Status ascending.
|
||||
- A custom property ascending or descending.
|
||||
|
||||
## Operators
|
||||
|
||||
Saved views can combine filters for text, dates, relationship fields, and frontmatter values. Relative date expressions are useful for views such as notes changed this week or people that need follow-up.
|
||||
|
||||
Regex filters are available for power-user cases. Keep them narrow and test them on a small view first.
|
||||
|
||||
## Keep Views Focused
|
||||
|
||||
A view should answer one recurring question. If it becomes too broad, split it into two views.
|
||||
|
||||
You can also customize view appearance with the same kind of icon and color controls used by types.
|
||||
17
site/releases/index.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Releases
|
||||
|
||||
Tolaria releases are published on GitHub.
|
||||
|
||||
- [Latest release](https://github.com/refactoringhq/tolaria/releases/latest)
|
||||
- [All releases](https://github.com/refactoringhq/tolaria/releases)
|
||||
- [Download page](/download/)
|
||||
|
||||
## Release Channels
|
||||
|
||||
Stable builds are intended for normal use. Pre-release builds may contain newer features and rougher edges.
|
||||
|
||||
Tolaria also has an Alpha channel for builds generated from pushes to `main`. See [Release Channels](/reference/release-channels) before switching from Stable.
|
||||
|
||||
## Before Updating
|
||||
|
||||
Commit or push important vault changes before updating the app. Your notes are local files, but having a clean Git state makes recovery easier.
|
||||
35
site/start/first-launch.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# First Launch
|
||||
|
||||
The first launch flow is designed to get you into a real vault quickly without hiding the local-first model.
|
||||
|
||||
## What You Choose
|
||||
|
||||
Tolaria asks whether you want to:
|
||||
|
||||
- Create or clone the Getting Started vault.
|
||||
- Open an existing local vault.
|
||||
- Create a new empty vault.
|
||||
|
||||
The Getting Started vault is cloned locally and then disconnected from its remote. That keeps the sample safe to edit without accidentally pushing tutorial changes.
|
||||
|
||||
## What Tolaria Creates
|
||||
|
||||
Tolaria stores app-level settings on the local machine. Your notes stay in the vault folder you choose.
|
||||
|
||||
| Data | Stored in |
|
||||
| --- | --- |
|
||||
| Notes and attachments | Your vault folder |
|
||||
| Type definitions and saved views | Your vault folder |
|
||||
| Window size, zoom, recent vaults | Local app settings |
|
||||
| Cache data | Rebuildable local cache |
|
||||
|
||||
## First Commands To Try
|
||||
|
||||
- `Cmd+K` / `Ctrl+K`: open the command palette.
|
||||
- `New Note`: create a note in the current vault.
|
||||
- `Open Getting Started Vault`: clone the public sample vault.
|
||||
- `Reload Vault`: rescan files after external edits.
|
||||
|
||||
## AI Setup Prompt
|
||||
|
||||
Tolaria can show an optional AI agents prompt after a vault is open. It checks common local install locations for supported coding agents and gives you setup paths, but you can dismiss it and use Tolaria without AI.
|
||||
26
site/start/getting-started-vault.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Getting Started Vault
|
||||
|
||||
The Getting Started vault is a small public sample vault hosted at [refactoringhq/tolaria-getting-started](https://github.com/refactoringhq/tolaria-getting-started).
|
||||
|
||||
It exists to show Tolaria's conventions without requiring you to restructure your own notes first.
|
||||
|
||||
## What It Demonstrates
|
||||
|
||||
- Markdown notes with YAML frontmatter.
|
||||
- Types such as Project, Person, Topic, and Procedure.
|
||||
- Wikilinks in note bodies.
|
||||
- Relationship fields in frontmatter.
|
||||
- A local Git repository that can be connected to a remote later.
|
||||
- Vault guidance files for AI agents.
|
||||
|
||||
## Local-Only By Default
|
||||
|
||||
When Tolaria clones the sample, it removes the remote from the local copy. This makes the sample vault disposable. You can edit it freely, commit locally, and delete it later.
|
||||
|
||||
To connect a vault to your own remote, use the bottom status bar remote chip or run `Add Remote` from the command palette.
|
||||
|
||||
Tolaria also repairs starter-vault guidance files when needed. `AGENTS.md` is the canonical guidance file, `CLAUDE.md` is kept as a compatibility shim, and `GEMINI.md` is only created when you explicitly restore Gemini guidance.
|
||||
|
||||
## When To Move On
|
||||
|
||||
After you understand the sample, open your own vault. Tolaria does not require a special folder structure: a folder of Markdown files is enough to start.
|
||||
36
site/start/install.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# Install Tolaria
|
||||
|
||||
Tolaria publishes desktop builds for macOS, Windows, and Linux. macOS is the primary day-to-day development target, with Windows and Linux builds supported through the release pipeline and fixed as platform issues are found.
|
||||
|
||||
## Download
|
||||
|
||||
Use the latest stable release unless you are intentionally testing pre-release builds:
|
||||
|
||||
- [Download the latest stable build](https://refactoringhq.github.io/tolaria/download/)
|
||||
- [Browse all GitHub releases](https://github.com/refactoringhq/tolaria/releases)
|
||||
- [Read the release notes](/releases/)
|
||||
|
||||
## Homebrew
|
||||
|
||||
On macOS you can install the cask:
|
||||
|
||||
```bash
|
||||
brew install --cask tolaria
|
||||
```
|
||||
|
||||
## Platform Status
|
||||
|
||||
| Platform | Status | Notes |
|
||||
| --- | --- | --- |
|
||||
| macOS | Primary | Apple Silicon and Intel builds are published. Homebrew is available. |
|
||||
| Windows | Supported, early | NSIS installers and signed updater bundles are published. Some shell and menu behavior can still need Windows-specific fixes. |
|
||||
| Linux | Supported, early | AppImage and deb artifacts are published. Desktop behavior depends on distribution WebKitGTK and input-method integration. |
|
||||
|
||||
See [Supported Platforms](/reference/supported-platforms) for the current support policy.
|
||||
|
||||
## After Installing
|
||||
|
||||
1. Open Tolaria.
|
||||
2. Choose the Getting Started vault if you want a guided sample.
|
||||
3. Or open an existing folder of Markdown files as a vault.
|
||||
4. Use the command palette with `Cmd+K` on macOS or `Ctrl+K` on Linux and Windows.
|
||||
24
site/start/open-or-create-vault.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Open Or Create A Vault
|
||||
|
||||
A Tolaria vault is a folder on disk. The folder can contain Markdown notes, attachments, type definitions, saved views, and Git metadata.
|
||||
|
||||
## Open An Existing Folder
|
||||
|
||||
Choose an existing folder if you already have Markdown notes. Tolaria scans `.md` files and uses frontmatter when it exists.
|
||||
|
||||
Good starting points:
|
||||
|
||||
- A folder of plain Markdown files.
|
||||
- An Obsidian-style vault.
|
||||
- A Git repository containing notes.
|
||||
- A copy of the Getting Started vault.
|
||||
|
||||
## Create A New Vault
|
||||
|
||||
Choose a new empty folder if you want Tolaria conventions from the start. New notes and optional type definitions are created as Markdown files.
|
||||
|
||||
## Git Is Recommended, Not Required
|
||||
|
||||
Tolaria works well with a plain folder of Markdown files. You can open, edit, organize, and search notes without making the vault a Git repository.
|
||||
|
||||
Git is recommended when you want local history, diff views, recovery, pull, push, and remote sync without a proprietary backend. If a vault is not already a repository, Tolaria can initialize one when you explicitly ask it to.
|
||||
23
site/troubleshooting/ai-agent-not-found.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# AI Agent Not Found
|
||||
|
||||
Tolaria can only launch local CLI agents that are installed and discoverable.
|
||||
|
||||
## Symptoms
|
||||
|
||||
- The AI panel says no supported agent is available.
|
||||
- Claude Code or another agent works in one shell but not in Tolaria.
|
||||
|
||||
## Checks
|
||||
|
||||
Open a terminal and run the agent command directly. For Claude Code:
|
||||
|
||||
```bash
|
||||
claude --version
|
||||
```
|
||||
|
||||
If the command fails, install or repair the agent first.
|
||||
|
||||
## Path Issues
|
||||
|
||||
Desktop apps can inherit a different `PATH` from your interactive shell. Tolaria checks common install locations, but shell setup can still vary. Prefer installing CLI tools in standard locations or making them available from your login shell.
|
||||
|
||||
26
site/troubleshooting/git-auth.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Git Authentication
|
||||
|
||||
Tolaria uses system Git authentication. It does not manage provider passwords directly.
|
||||
|
||||
## Symptoms
|
||||
|
||||
- Push fails.
|
||||
- Pull asks for credentials repeatedly.
|
||||
- Remote fetch works in one terminal but not in Tolaria.
|
||||
|
||||
## Checks
|
||||
|
||||
1. Open a terminal.
|
||||
2. `cd` into the vault.
|
||||
3. Run `git remote -v`.
|
||||
4. Run `git fetch`.
|
||||
|
||||
If `git fetch` fails in the terminal, fix system Git auth first.
|
||||
|
||||
## Common Fixes
|
||||
|
||||
- Sign in with GitHub CLI.
|
||||
- Configure SSH keys.
|
||||
- Update the remote URL.
|
||||
- Check your credential helper.
|
||||
|
||||
25
site/troubleshooting/model-provider-connection.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Model Provider Connection
|
||||
|
||||
Use this checklist when a local or API model provider does not connect.
|
||||
|
||||
## Local Providers
|
||||
|
||||
For Ollama or LM Studio:
|
||||
|
||||
1. Start the local model server.
|
||||
2. Confirm the base URL in Tolaria matches the server.
|
||||
3. Confirm the model ID is installed and loaded by the provider.
|
||||
4. Use the Settings test action again.
|
||||
|
||||
## API Providers
|
||||
|
||||
For hosted providers:
|
||||
|
||||
1. Confirm the provider kind and endpoint.
|
||||
2. Confirm the model ID exists for your account.
|
||||
3. Confirm the API key is saved locally or available in the configured environment variable.
|
||||
4. Avoid storing secrets in the vault.
|
||||
|
||||
## Chat Mode Boundary
|
||||
|
||||
Direct model targets run in chat mode. If you need file-editing tools, use a coding agent target such as Claude Code, Codex, OpenCode, Pi, or Gemini CLI.
|
||||
20
site/troubleshooting/sync-conflicts.md
Normal file
@@ -0,0 +1,20 @@
|
||||
# Sync Conflicts
|
||||
|
||||
Sync conflicts happen when local and remote changes touch the same content.
|
||||
|
||||
## What To Do
|
||||
|
||||
1. Stop editing the conflicted note.
|
||||
2. Open the conflict resolver if Tolaria presents it.
|
||||
3. Review both sides.
|
||||
4. Choose the correct content or merge manually.
|
||||
5. Commit the resolved file.
|
||||
6. Push again.
|
||||
|
||||
## Prevent Conflicts
|
||||
|
||||
- Pull before starting work on another device.
|
||||
- Push after meaningful sessions.
|
||||
- Keep AI-generated edits in small commits.
|
||||
- Avoid editing the same note on multiple devices at the same time.
|
||||
|
||||
25
site/troubleshooting/vault-not-loading.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Vault Not Loading
|
||||
|
||||
Use this checklist when Tolaria cannot open or refresh a vault.
|
||||
|
||||
## Check The Folder
|
||||
|
||||
- Confirm the folder exists.
|
||||
- Confirm the folder contains readable files.
|
||||
- Confirm Tolaria has permission to access the folder.
|
||||
- Try opening a smaller test vault to isolate the issue.
|
||||
|
||||
## Check Git
|
||||
|
||||
If the vault is a Git repository, verify it is not in a broken state:
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
Resolve interrupted merges or corrupted repository state before retrying.
|
||||
|
||||
## Reload
|
||||
|
||||
Run `Reload Vault` from the command palette. This clears derived cache and rescans the filesystem.
|
||||
|
||||
13
src-tauri/resources/agent-docs/AGENTS.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# AGENTS.md - Tolaria Docs Bundle
|
||||
|
||||
This folder contains local, generated Tolaria product docs for AI agents.
|
||||
|
||||
Use these docs when a user asks how Tolaria works, when you need product behavior, or before making Tolaria-specific assumptions.
|
||||
|
||||
Recommended lookup flow:
|
||||
|
||||
1. Read the active vault's AGENTS.md for vault-specific conventions.
|
||||
2. Read this folder's index.md for the docs map.
|
||||
3. Use `rg` over this folder for advanced concepts, workflows, shortcuts, Git, AutoGit, AI, types, properties, relationships, and troubleshooting.
|
||||
|
||||
Vault-specific AGENTS.md wins for local conventions. These bundled docs win for Tolaria product behavior.
|
||||
1515
src-tauri/resources/agent-docs/all.md
Normal file
394
src-tauri/resources/agent-docs/concepts.md
Normal file
@@ -0,0 +1,394 @@
|
||||
# AI
|
||||
|
||||
Source: concepts/ai.md
|
||||
URL: /concepts/ai
|
||||
|
||||
# AI
|
||||
|
||||
Tolaria has two AI paths: coding agents that can use tools to inspect and edit a vault, and direct model targets that answer in chat mode from note context.
|
||||
|
||||
## Coding Agents
|
||||
|
||||
The AI panel can stream supported local CLI agents through Tolaria's normalized event layer. Current targets include Claude Code, Codex, OpenCode, Pi, and Gemini CLI when they are installed on the machine.
|
||||
|
||||
Coding agents can run in:
|
||||
|
||||
- **Vault Safe** mode, limited to file, search, and edit tools.
|
||||
- **Power User** mode, which can allow local shell commands scoped to the active vault for agents that support shell access.
|
||||
|
||||
## Direct Models
|
||||
|
||||
Direct model targets run in chat mode. They receive the active note, linked context, and conversation history, but they do not receive vault-write tools or shell access.
|
||||
|
||||
Supported provider shapes include:
|
||||
|
||||
- Local models through Ollama or LM Studio.
|
||||
- Hosted providers such as OpenAI, Anthropic, Gemini, and OpenRouter.
|
||||
- Custom OpenAI-compatible endpoints.
|
||||
|
||||
## External MCP Setup
|
||||
|
||||
Tolaria exposes an MCP server for external tools. The setup flow can write Tolaria's MCP entry into Claude Code, Gemini CLI, Cursor, and a generic MCP config path, and it can also copy the exact JSON snippet for manual setup.
|
||||
|
||||
MCP setup is explicit. Closing the dialog leaves third-party config files untouched.
|
||||
|
||||
## Why Git Matters For AI
|
||||
|
||||
AI-generated changes should be inspectable. Git gives you diffs, history, rollback, and a clear boundary between suggestions and committed work.
|
||||
|
||||
---
|
||||
|
||||
# Editor
|
||||
|
||||
Source: concepts/editor.md
|
||||
URL: /concepts/editor
|
||||
|
||||
# Editor
|
||||
|
||||
Tolaria offers a rich editor for daily writing and a raw Markdown mode for exact file control. Both modes write back to the same Markdown file.
|
||||
|
||||
## Rich Editing
|
||||
|
||||
The rich editor supports blocks, slash commands, wikilinks, tables, code blocks, images, Mermaid diagrams, LaTeX-style math, and markdown-backed whiteboards.
|
||||
|
||||
Use it when you want to write and reorganize quickly without thinking about Markdown syntax.
|
||||
|
||||
## Raw Mode
|
||||
|
||||
Raw mode shows the Markdown source directly. Use it when you need to edit YAML frontmatter, repair unusual Markdown, or make an exact text change.
|
||||
|
||||
Toggle raw mode with `Cmd+\` on macOS or `Ctrl+\` on Windows and Linux.
|
||||
|
||||
## Table Of Contents
|
||||
|
||||
The table of contents panel builds an outline from headings in the current note. It is useful for long notes, procedures, research files, and generated documents. Toggle it with `Cmd+Shift+T` on macOS or `Ctrl+Shift+T` on Windows and Linux.
|
||||
|
||||
## Width
|
||||
|
||||
Notes can use normal or wide editor width. Set the default in Settings, or override an individual note from the editor toolbar.
|
||||
|
||||
---
|
||||
|
||||
# Files And Media
|
||||
|
||||
Source: concepts/files-and-media.md
|
||||
URL: /concepts/files-and-media
|
||||
|
||||
# Files And Media
|
||||
|
||||
Tolaria starts with Markdown notes, but a vault can also contain images, PDFs, media files, whiteboards, and other local files.
|
||||
|
||||
## Mermaid Diagrams
|
||||
|
||||
Use Mermaid code blocks when a note needs a diagram that should stay plain text and versionable.
|
||||
|
||||
````md
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Idea --> Draft --> Review --> Publish
|
||||
```
|
||||
````
|
||||
|
||||
Tolaria renders Mermaid diagrams in the editor while keeping the source in Markdown.
|
||||
|
||||
## Attachments
|
||||
|
||||
Images pasted into the editor are saved into the vault as normal files. They remain portable and can be opened by other tools.
|
||||
|
||||
## Previews
|
||||
|
||||
Tolaria can preview common image files, PDFs, and supported media files in the app. Files without an in-app preview can still be opened in the default system app.
|
||||
|
||||
Settings control whether PDFs, images, and unsupported files appear in All Notes. Folder browsing still shows files in their folders.
|
||||
|
||||
## Whiteboards
|
||||
|
||||
Whiteboards use tldraw in the editor, but their durable representation stays in Markdown. That keeps them inside the vault and versioned by Git with the rest of your notes.
|
||||
|
||||
## Git Boundary
|
||||
|
||||
If generated or local-only files are ignored by Git, Tolaria can hide them from notes, search, quick open, and folders. Use this when build artifacts or private local files should not behave like vault content.
|
||||
|
||||
---
|
||||
|
||||
# Git
|
||||
|
||||
Source: concepts/git.md
|
||||
URL: /concepts/git
|
||||
|
||||
# Git
|
||||
|
||||
Git is Tolaria's recommended history and sync layer. Tolaria can work with plain Markdown folders, and Git unlocks local history, recovery, remote backup, and multi-device workflows when you want them.
|
||||
|
||||
Tolaria acts as a lightweight Git client for your vault. You can review changes, commit, pull, push, and inspect history without leaving the app.
|
||||
|
||||
## What Tolaria Uses Git For
|
||||
|
||||
- Whole-vault commit history.
|
||||
- Current diff for the vault.
|
||||
- Per-note history.
|
||||
- Current diff for an individual note.
|
||||
- Pull and push.
|
||||
- Conflict detection and resolution.
|
||||
- Remote connection for local-only vaults.
|
||||
|
||||
## History And Diffs
|
||||
|
||||
Each note can show its own history and current diff, so you can understand how that file changed over time or what is unsaved relative to Git.
|
||||
|
||||
Tolaria also shows a history of the whole vault. Use it when you want to review broader changes across multiple notes before committing or syncing.
|
||||
|
||||
## Local Commits
|
||||
|
||||
You can commit changes inside Tolaria without leaving the app. This gives you useful restore points even before a remote is configured.
|
||||
|
||||
## Remotes
|
||||
|
||||
Connect a compatible Git remote when you want sync or backup. Tolaria relies on your system Git authentication, so GitHub CLI, SSH keys, credential helpers, and existing Git configuration can continue to work.
|
||||
|
||||
---
|
||||
|
||||
# Inbox
|
||||
|
||||
Source: concepts/inbox.md
|
||||
URL: /concepts/inbox
|
||||
|
||||
# Inbox
|
||||
|
||||
The Inbox is for notes that have been captured but not yet organized.
|
||||
|
||||
## Why It Exists
|
||||
|
||||
Fast capture should not require perfect structure. The Inbox gives you a place to put incomplete notes, then process them later.
|
||||
|
||||
The Inbox workflow is optional. Turn it off in Settings > Workflow if you prefer every note to appear organized by default.
|
||||
|
||||
## Organizing Inbox Notes
|
||||
|
||||
When reviewing the Inbox:
|
||||
|
||||
1. Give the note a clear H1.
|
||||
2. Set its `type`.
|
||||
3. Add status, dates, or URL if useful.
|
||||
4. Add relationships with wikilinks or frontmatter fields.
|
||||
5. Move it into a folder only if the folder adds value.
|
||||
|
||||
## Healthy Inbox Habit
|
||||
|
||||
Keep the Inbox small enough that it can be reviewed in one focused pass. Tolaria works best when capture is fast and organization is deliberate.
|
||||
|
||||
---
|
||||
|
||||
# Notes
|
||||
|
||||
Source: concepts/notes.md
|
||||
URL: /concepts/notes
|
||||
|
||||
# Notes
|
||||
|
||||
A note is a Markdown file with optional YAML frontmatter. Tolaria reads the first H1 as the primary title and keeps the file on disk as the durable representation.
|
||||
|
||||
## Anatomy
|
||||
|
||||
```md
|
||||
---
|
||||
type: Project
|
||||
status: Active
|
||||
belongs_to:
|
||||
- "[[workspace]]"
|
||||
---
|
||||
|
||||
# Launch Documentation
|
||||
|
||||
Draft the public Tolaria docs and keep them close to code changes.
|
||||
```
|
||||
|
||||
## Titles
|
||||
|
||||
The first H1 is the note title. Tolaria uses that title wherever the note is displayed: note lists, search results, wikilink suggestions, relationship pickers, tabs, and window titles.
|
||||
|
||||
The title is separate from the filename. The filename stays visible in the breadcrumb so you can see the file on disk, and you can rename it independently when needed.
|
||||
|
||||
Use the breadcrumb action to rename the file to match the title. New untitled notes can also auto-rename from the first H1 the first time they get a real title. Turn this behavior off in Settings > Vault Content > Titles & Filenames if you prefer filenames to stay unchanged until you rename them manually.
|
||||
|
||||
## Body Links
|
||||
|
||||
Use `[[wikilinks]]` to connect notes from the body. Tolaria shows autocomplete suggestions while you type, and links can resolve by filename or title.
|
||||
|
||||
## Frontmatter
|
||||
|
||||
Use frontmatter for structured fields such as type, status, date, URL, and relationships. Keep free-form thinking in the body.
|
||||
|
||||
---
|
||||
|
||||
# Properties
|
||||
|
||||
Source: concepts/properties.md
|
||||
URL: /concepts/properties
|
||||
|
||||
# Properties
|
||||
|
||||
Properties are frontmatter fields that Tolaria can display, filter, and edit.
|
||||
|
||||
## Suggested Properties
|
||||
|
||||
Suggested properties are the fields Tolaria knows how to create quickly from the Properties panel. When a suggested property is missing, the panel shows a shortcut to add it with the right editor.
|
||||
|
||||
| Field | Purpose |
|
||||
| --- | --- |
|
||||
| `type` | Groups the note into a type such as Project, Person, or Topic. |
|
||||
| `status` | Tracks lifecycle state such as Active, Done, or Blocked. |
|
||||
| `url` | Stores a canonical external link. |
|
||||
| `date` | Represents a single date. |
|
||||
|
||||
## System Properties
|
||||
|
||||
Fields that start with `_` are system properties. They remain in plain text but are hidden from normal property editing.
|
||||
|
||||
Examples include `_icon`, `_color`, `_order`, `_sidebar_label`, `_width`, and `_pinned_properties` on type documents or notes.
|
||||
|
||||
## Property Editing
|
||||
|
||||
The Properties panel is the safest place to edit structured properties. Toggle it with `Cmd+Shift+I` on macOS or `Ctrl+Shift+I` on Windows and Linux.
|
||||
|
||||
Date fields use Tolaria's picker, relationship fields can use wikilinks, and raw Markdown mode is available when you need direct control over YAML.
|
||||
|
||||
---
|
||||
|
||||
# Relationships
|
||||
|
||||
Source: concepts/relationships.md
|
||||
URL: /concepts/relationships
|
||||
|
||||
# Relationships
|
||||
|
||||
Relationships make a vault feel like a graph instead of a pile of documents.
|
||||
|
||||
## Relationship Fields
|
||||
|
||||
Any frontmatter field containing wikilinks can become a relationship. Relationship fields can point to one note or to an array of notes.
|
||||
|
||||
```yaml
|
||||
belongs_to:
|
||||
- "[[product-work]]"
|
||||
related_to:
|
||||
- "[[documentation]]"
|
||||
- "[[editor-research]]"
|
||||
blocked_by:
|
||||
- "[[release-process]]"
|
||||
- "[[sync-conflicts]]"
|
||||
```
|
||||
|
||||
Tolaria supports default relationship fields out of the box: `belongs_to`, `has`, and `related_to`. It also detects custom relationship fields dynamically when they contain wikilinks.
|
||||
|
||||
Default relationships have automatically computed inverses. If a note says it `belongs_to` a project, the project can show that note under its inverse `has` relationship without you writing the reverse link by hand. `related_to` works as a lateral relationship in both directions.
|
||||
|
||||
These outgoing and inverse relationships appear in the Properties panel and in Neighborhood mode, where the note list becomes a graph view around the selected note.
|
||||
|
||||
## Body Links Versus Relationship Fields
|
||||
|
||||
Use body links when the relationship appears naturally in writing. Use frontmatter relationships when the connection is important enough to show in navigation, filters, Neighborhood mode, or the Properties panel.
|
||||
|
||||
## Backlinks
|
||||
|
||||
Tolaria can show incoming links and inverse relationships, making it easier to navigate from a note to the rest of its context.
|
||||
|
||||
---
|
||||
|
||||
# Types
|
||||
|
||||
Source: concepts/types.md
|
||||
URL: /concepts/types
|
||||
|
||||
# Types
|
||||
|
||||
Types describe what kind of thing a note represents: Project, Person, Topic, Procedure, Event, or any category you create.
|
||||
|
||||
## Type Field
|
||||
|
||||
The `type:` field assigns a note to a type.
|
||||
|
||||
```yaml
|
||||
type: Project
|
||||
```
|
||||
|
||||
Tolaria does not infer type from folder location. Moving a file into another folder does not change its type.
|
||||
|
||||
## Prefer Types Over Folders
|
||||
|
||||
Types are the preferred way to group notes in Tolaria. Folders are supported for existing vaults and fallback organization, but Tolaria is built around types and relationships because they carry stronger meaning than file paths.
|
||||
|
||||
Use types for semantic groups such as Projects, People, Topics, Procedures, Events, and Essays. Use relationships to connect notes across those groups. This gives Tolaria better structure for navigation, filtering, properties, templates, and future automation than folder location alone.
|
||||
|
||||
## Type Documents
|
||||
|
||||
Type documents are Markdown notes with `type: Type` in frontmatter. They describe how a type should appear and what new notes of that type should start with.
|
||||
|
||||
```yaml
|
||||
---
|
||||
type: Type
|
||||
_icon: folder
|
||||
_color: blue
|
||||
_sidebar_label: Projects
|
||||
_order: 10
|
||||
---
|
||||
|
||||
# Project
|
||||
```
|
||||
|
||||
## What Types Control
|
||||
|
||||
- Sidebar grouping.
|
||||
- Type icon and color.
|
||||
- Sidebar order and label.
|
||||
- Pinned properties.
|
||||
- New-note templates.
|
||||
|
||||
## New Note Defaults
|
||||
|
||||
Type documents can define empty properties and relationships. When you create a new note of that type, Tolaria shows placeholders for those fields so you can fill them in from the Properties panel.
|
||||
|
||||
If a type document gives a property a value, that value becomes the default for new notes of that type. For example, a Project type can define `status: Active` so every new project starts active until you change it.
|
||||
|
||||
---
|
||||
|
||||
# Vaults
|
||||
|
||||
Source: concepts/vaults.md
|
||||
URL: /concepts/vaults
|
||||
|
||||
# Vaults
|
||||
|
||||
A vault is the folder Tolaria reads and writes. The filesystem is the source of truth; the app state and cache are derived from files.
|
||||
|
||||
## Core Rules
|
||||
|
||||
- Notes are Markdown files.
|
||||
- YAML frontmatter provides structure.
|
||||
- Attachments are normal files inside the vault.
|
||||
- Type definitions and saved views are also files.
|
||||
- Git can track history and support remote sync.
|
||||
|
||||
## Why Local Files Matter
|
||||
|
||||
Local files keep your notes inspectable. You can open them in another editor, search with command-line tools, back them up with your own system, and version them with Git.
|
||||
|
||||
Tolaria should never become the only way to read your data.
|
||||
|
||||
## Git Is A Capability
|
||||
|
||||
A plain folder of Markdown files can open as a vault. Git-backed vaults unlock history, changes, commits, pull, push, conflict handling, and remote setup.
|
||||
|
||||
If a folder is not a Git repository, Tolaria can initialize Git when you explicitly ask it to. It avoids initializing broad personal folders such as Desktop, Documents, or Downloads unless they are clearly dedicated vault folders.
|
||||
|
||||
## App State Versus Vault State
|
||||
|
||||
Vault-level information should travel with the vault. Machine-specific preferences stay with the app installation.
|
||||
|
||||
| Vault state | App state |
|
||||
| --- | --- |
|
||||
| Type icons and colors | Editor zoom |
|
||||
| Saved views | Window size |
|
||||
| Pinned properties | Recent vault list |
|
||||
| Relationship conventions | Local cache |
|
||||
| Vault AI guidance files | AI target selection |
|
||||
24
src-tauri/resources/agent-docs/download.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Download
|
||||
|
||||
Source: download/index.md
|
||||
URL: /download/
|
||||
|
||||
# Download
|
||||
|
||||
Download Tolaria from the latest stable release.
|
||||
|
||||
## Latest Stable
|
||||
|
||||
[Open the installer download page](https://refactoringhq.github.io/tolaria/download/)
|
||||
|
||||
The download page reads the latest stable release metadata and points you to the current macOS, Windows, or Linux artifact.
|
||||
|
||||
## Other Builds
|
||||
|
||||
- [Browse all GitHub releases](https://github.com/refactoringhq/tolaria/releases)
|
||||
- [Read release history](/releases/)
|
||||
- [Learn release channels](/reference/release-channels)
|
||||
|
||||
## Verify The Version
|
||||
|
||||
After launching the app, check the version shown in Tolaria's status bar or release surface.
|
||||
441
src-tauri/resources/agent-docs/guides.md
Normal file
@@ -0,0 +1,441 @@
|
||||
# Build Custom Views
|
||||
|
||||
Source: guides/build-custom-views.md
|
||||
URL: /guides/build-custom-views
|
||||
|
||||
# Build Custom Views
|
||||
|
||||
Custom views are saved filters for recurring questions.
|
||||
|
||||
## Good View Candidates
|
||||
|
||||
- Active projects.
|
||||
- People without a recent follow-up.
|
||||
- Drafts ready for review.
|
||||
- Notes changed this week.
|
||||
- Events in a date range.
|
||||
|
||||
## View Definition
|
||||
|
||||
Saved views live as files in the vault. They describe filters, sorting, and visible columns using structured data.
|
||||
|
||||
## Filters
|
||||
|
||||
Custom views can use nested conditions, similar to Notion or Airtable filter groups. Combine `all` and `any` logic when a view needs to answer a more precise question than a single field filter can express.
|
||||
|
||||
Date filters support dynamic natural-language values such as `today`, `yesterday`, or `one week ago`. Use these for views that should keep moving over time, such as recent work, stale follow-ups, or upcoming events.
|
||||
|
||||
## Design The Question First
|
||||
|
||||
Before creating a view, write the question it answers. A good view is not "all fields with all filters"; it is a focused lens.
|
||||
|
||||
---
|
||||
|
||||
# Capture A Note
|
||||
|
||||
Source: guides/capture-a-note.md
|
||||
URL: /guides/capture-a-note
|
||||
|
||||
# Capture A Note
|
||||
|
||||
Use capture when you need to get an idea into the vault before you know where it belongs.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Press `Cmd+N` on macOS or `Ctrl+N` on Windows and Linux.
|
||||
2. Write a clear H1.
|
||||
3. Add the rough content.
|
||||
4. Leave structure for later if you are still thinking.
|
||||
|
||||
## Capture Well
|
||||
|
||||
Prefer a useful title over a perfect taxonomy. You can add type, status, and relationships during inbox review.
|
||||
|
||||
## When To Add Structure Immediately
|
||||
|
||||
Add structure while capturing when the note's type or relationships are already obvious. Otherwise, capture the idea first and organize it later.
|
||||
|
||||
---
|
||||
|
||||
# Manage Git Manually Or With AutoGit
|
||||
|
||||
Source: guides/commit-and-push.md
|
||||
URL: /guides/commit-and-push
|
||||
|
||||
# Manage Git Manually Or With AutoGit
|
||||
|
||||
Tolaria can act as a lightweight Git client for a Git-enabled vault. You can manage commits and pushes yourself, or enable AutoGit to create conservative checkpoints after editing pauses or when the app is no longer active.
|
||||
|
||||
## Manual Git
|
||||
|
||||
1. Open the Git or changes surface.
|
||||
2. Review changed files.
|
||||
3. Write a short commit message.
|
||||
4. Commit locally.
|
||||
5. Push when a remote is configured.
|
||||
|
||||
If the remote has changed, pull first and resolve any conflicts. If the vault has no remote, manual commits still give you local history, diffs, and rollback.
|
||||
|
||||
## AutoGit
|
||||
|
||||
AutoGit is available in Settings for Git-enabled vaults. When enabled, Tolaria automatically commits and pushes saved local changes after an idle pause or after the app becomes inactive.
|
||||
|
||||
Use AutoGit when you want the safety of regular checkpoints without interrupting capture or editing. You can still inspect each note's current diff, review note history, and browse the whole-vault history before making larger manual commits.
|
||||
|
||||
## Use Small Commits
|
||||
|
||||
Small commits make it easier to understand what changed, roll back safely, and review AI-generated edits.
|
||||
|
||||
---
|
||||
|
||||
# Configure AI Models
|
||||
|
||||
Source: guides/configure-ai-models.md
|
||||
URL: /guides/configure-ai-models
|
||||
|
||||
# Configure AI Models
|
||||
|
||||
Use model providers when you want chat over note context without giving an agent vault-write tools.
|
||||
|
||||
## Local Models
|
||||
|
||||
Local model targets are for tools such as Ollama and LM Studio. They usually need a base URL and model ID, and they usually do not need an API key.
|
||||
|
||||
## API Models
|
||||
|
||||
API model targets are for hosted providers such as OpenAI, Anthropic, Gemini, OpenRouter, or another OpenAI-compatible endpoint.
|
||||
|
||||
Tolaria does not store provider API keys in vault settings. Choose one of the supported key paths:
|
||||
|
||||
- Save the key locally on this device.
|
||||
- Read the key from an environment variable.
|
||||
- Use no key for local providers that do not require one.
|
||||
|
||||
## Test The Connection
|
||||
|
||||
After adding a provider, use the test action in Settings. A successful test means Tolaria reached the endpoint and the model replied.
|
||||
|
||||
## Select The Target
|
||||
|
||||
Once configured, choose the model from the AI target selector or set it as the default AI target in Settings.
|
||||
|
||||
---
|
||||
|
||||
# Connect A Git Remote
|
||||
|
||||
Source: guides/connect-a-git-remote.md
|
||||
URL: /guides/connect-a-git-remote
|
||||
|
||||
# Connect A Git Remote
|
||||
|
||||
Connect a remote when you want backup or sync beyond the current machine.
|
||||
|
||||
## Before You Start
|
||||
|
||||
Make sure the remote repository exists and your system Git can authenticate to it. Tolaria uses system Git rather than storing provider-specific credentials.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Open the bottom status bar remote chip, or run `Add Remote` from the command palette.
|
||||
2. Paste the remote URL.
|
||||
3. Confirm the remote name.
|
||||
4. Fetch or push according to the app prompt.
|
||||
|
||||
## Recommended Auth
|
||||
|
||||
- SSH keys.
|
||||
- GitHub CLI authentication.
|
||||
- Existing Git credential helpers.
|
||||
- macOS Keychain credentials for HTTPS remotes on macOS.
|
||||
|
||||
If authentication fails, see [Git Authentication](/troubleshooting/git-auth).
|
||||
|
||||
---
|
||||
|
||||
# Create Types
|
||||
|
||||
Source: guides/create-types.md
|
||||
URL: /guides/create-types
|
||||
|
||||
# Create Types
|
||||
|
||||
Create a type when several notes share the same role in your system.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Run `New Type` from the command palette, or click `+` in the Types header in the sidebar.
|
||||
2. Give the type a clear name.
|
||||
3. Add optional icon, color, sidebar order, sidebar label, pinned properties, suggested fields, default values, or a new-note template.
|
||||
|
||||
You can also right-click a type in the sidebar to change its icon and color.
|
||||
|
||||
```yaml
|
||||
---
|
||||
type: Type
|
||||
_icon: briefcase
|
||||
_color: blue
|
||||
_sidebar_label: Projects
|
||||
_order: 10
|
||||
---
|
||||
|
||||
# Project
|
||||
```
|
||||
|
||||
## Use Types Sparingly
|
||||
|
||||
A type should represent a recurring category, not a one-off label. If you only need a temporary grouping, use a saved view or property instead.
|
||||
|
||||
## Templates
|
||||
|
||||
Type documents can include a Markdown template for new notes of that type. Keep templates small and useful: a heading, a few expected fields, and the first checklist are usually enough.
|
||||
|
||||
Type documents can also define fields for new notes. Empty properties and relationships become placeholders in new notes of that type. Properties with values become defaults for new notes of that type.
|
||||
|
||||
---
|
||||
|
||||
# Manage Display Preferences
|
||||
|
||||
Source: guides/manage-display-preferences.md
|
||||
URL: /guides/manage-display-preferences
|
||||
|
||||
# Manage Display Preferences
|
||||
|
||||
Display preferences live in local app settings unless a setting is intentionally stored in the note or vault.
|
||||
|
||||
## Theme
|
||||
|
||||
Choose Light, Dark, or System in Settings. System follows the operating system appearance at runtime.
|
||||
|
||||
You can also switch theme mode from the command palette.
|
||||
|
||||
## Note Width
|
||||
|
||||
Set the default rich-editor width in Settings:
|
||||
|
||||
- **Normal** for focused writing.
|
||||
- **Wide** for tables, diagrams, dense notes, and generated documents.
|
||||
|
||||
An individual note can override the default width from the editor toolbar. That override is stored as `_width` in the note frontmatter.
|
||||
|
||||
## Sidebar Labels
|
||||
|
||||
Tolaria can pluralize type names in the sidebar. Turn this off in Settings if your type names should be shown exactly as written, or use `_sidebar_label` on a type document for an explicit label.
|
||||
|
||||
## Vault Content
|
||||
|
||||
Settings also control whether Gitignored files and non-Markdown file categories are visible in the app. Use these controls to keep generated or local-only files out of regular note workflows.
|
||||
|
||||
---
|
||||
|
||||
# Organize The Inbox
|
||||
|
||||
Source: guides/organize-inbox.md
|
||||
URL: /guides/organize-inbox
|
||||
|
||||
# Organize The Inbox
|
||||
|
||||
Inbox review turns quick captures into usable knowledge.
|
||||
|
||||
## Remove A Note From Inbox
|
||||
|
||||
When a note is organized enough, mark it as organized. Use `Cmd+E` on macOS or `Ctrl+E` on Windows and Linux, or click the organize action in the breadcrumb bar.
|
||||
|
||||
That action is what removes the note from Inbox. If auto-advance is enabled in Settings > Workflow, Tolaria opens the next Inbox item immediately after you mark the current note organized.
|
||||
|
||||
## Review Checklist
|
||||
|
||||
- Rename unclear notes.
|
||||
- Add or correct the first H1.
|
||||
- Set `type`.
|
||||
- Add `status` for actionable notes.
|
||||
- Add `belongs_to`, `related_to`, or other relationship fields when useful.
|
||||
- Archive or delete notes that no longer matter.
|
||||
|
||||
## Make Notes Navigable
|
||||
|
||||
A note is organized when you can answer:
|
||||
|
||||
- What kind of thing is this?
|
||||
- What is it connected to?
|
||||
- What is this useful for?
|
||||
- What will I do with it?
|
||||
|
||||
## Avoid Over-Structuring
|
||||
|
||||
Do not add fields just because they exist. Add the structure that will help future navigation, review, or automation.
|
||||
|
||||
---
|
||||
|
||||
# Use The AI
|
||||
|
||||
Source: guides/use-ai-panel.md
|
||||
URL: /guides/use-ai-panel
|
||||
|
||||
# Use The AI
|
||||
|
||||
Tolaria gives you two ways to ask for AI help: open the AI panel for an ongoing conversation, or prompt directly from the editor with `Cmd+K` followed by a space.
|
||||
|
||||
## Choose How To Prompt
|
||||
|
||||
- **AI panel** is best for longer conversations, agent work, and requests that need visible back-and-forth.
|
||||
- **Inline prompt** is best when you are already writing. Press `Cmd+K`, type a space, then write the prompt you want the AI to handle from the current note context.
|
||||
|
||||
## Choose A Target
|
||||
|
||||
Open Settings and choose the default AI target:
|
||||
|
||||
- **Coding agent** for tool-backed vault editing through Claude Code, Codex, OpenCode, Pi, or Gemini CLI.
|
||||
- **Local model** for Ollama or LM Studio chat over note context.
|
||||
- **API model** for OpenAI, Anthropic, Gemini, OpenRouter, or an OpenAI-compatible endpoint.
|
||||
|
||||
If a coding agent is missing, install it and reopen Tolaria or switch to another target.
|
||||
|
||||
## Permission Mode
|
||||
|
||||
Coding agents support per-vault permission modes:
|
||||
|
||||
- **Vault Safe** keeps agents limited to file, search, and edit tools.
|
||||
- **Power User** can allow shell commands for agents that support them.
|
||||
|
||||
Direct model targets always stay in chat mode. They can use note context, but they cannot edit vault files through tools.
|
||||
|
||||
## Good Requests
|
||||
|
||||
- "Find notes related to this project."
|
||||
- "Summarize what changed in this note."
|
||||
- "Draft a weekly review from these linked notes."
|
||||
- "Update this checklist based on the current project status."
|
||||
|
||||
## Review Changes
|
||||
|
||||
AI edits are file edits. Review them with Tolaria's diff and Git history before committing.
|
||||
|
||||
---
|
||||
|
||||
# Use The Command Palette
|
||||
|
||||
Source: guides/use-command-palette.md
|
||||
URL: /guides/use-command-palette
|
||||
|
||||
# Use The Command Palette
|
||||
|
||||
The command palette is the fastest way to move around Tolaria.
|
||||
|
||||
Open it with:
|
||||
|
||||
- `Cmd+K` on macOS.
|
||||
- `Ctrl+K` on Linux and Windows.
|
||||
|
||||
## Common Commands
|
||||
|
||||
- New Note.
|
||||
- Search.
|
||||
- Open Settings.
|
||||
- Reload Vault.
|
||||
- Add Remote.
|
||||
- Open Getting Started Vault.
|
||||
- Toggle Raw Mode.
|
||||
- Toggle Table of Contents.
|
||||
- Toggle AI Panel.
|
||||
- Use Light, Dark, or System theme.
|
||||
- Open in New Window.
|
||||
|
||||
## Keyboard-First Workflow
|
||||
|
||||
Use the palette when you know what you want to do but do not want to hunt through panels. It is also the best place to discover commands as the app grows.
|
||||
|
||||
---
|
||||
|
||||
# Use Media Previews
|
||||
|
||||
Source: guides/use-media-previews.md
|
||||
URL: /guides/use-media-previews
|
||||
|
||||
# Use Media Previews
|
||||
|
||||
Media previews let you inspect vault files without leaving Tolaria.
|
||||
|
||||
## Open A File
|
||||
|
||||
Select an image, PDF, media file, or unsupported file from a folder or file list. Tolaria opens supported files in the app and offers an external-open action for files that should use the system default app.
|
||||
|
||||
## All Notes Visibility
|
||||
|
||||
Open Settings to choose whether non-Markdown files appear in All Notes:
|
||||
|
||||
- PDFs.
|
||||
- Images.
|
||||
- Unsupported files.
|
||||
|
||||
Folder browsing still shows files in their folders even when a category is hidden from All Notes.
|
||||
|
||||
## Attachments
|
||||
|
||||
When you paste or drop an image into a note, Tolaria copies it into the vault and references the copied file from Markdown.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If a preview does not render, open the file in the default app to confirm the file is valid, then check whether the file is inside the active vault and not blocked by operating-system permissions.
|
||||
|
||||
---
|
||||
|
||||
# Use The Table Of Contents
|
||||
|
||||
Source: guides/use-table-of-contents.md
|
||||
URL: /guides/use-table-of-contents
|
||||
|
||||
# Use The Table Of Contents
|
||||
|
||||
The table of contents panel helps you navigate long notes by heading.
|
||||
|
||||
## Open It
|
||||
|
||||
Use the editor toolbar, the command palette, or the shortcut:
|
||||
|
||||
- `Cmd+Shift+T` on macOS.
|
||||
- `Ctrl+Shift+T` on Windows and Linux.
|
||||
|
||||
## How It Works
|
||||
|
||||
Tolaria builds the outline from the current note's headings. The panel updates as the note changes and can jump to sections in the editor.
|
||||
|
||||
## Good Uses
|
||||
|
||||
- Long procedures.
|
||||
- Meeting notes with many sections.
|
||||
- Research notes.
|
||||
- Generated documents that need review.
|
||||
|
||||
If a note has no useful headings, add clear H2 and H3 sections rather than relying on a long uninterrupted document.
|
||||
|
||||
---
|
||||
|
||||
# Use Wikilinks
|
||||
|
||||
Source: guides/use-wikilinks.md
|
||||
URL: /guides/use-wikilinks
|
||||
|
||||
# Use Wikilinks
|
||||
|
||||
Wikilinks connect notes by name.
|
||||
|
||||
```md
|
||||
This project belongs to [[content-systems]] and is related to [[git-workflows]].
|
||||
```
|
||||
|
||||
## Link From The Body
|
||||
|
||||
Use body links when the connection is part of the sentence you are writing.
|
||||
|
||||
## Link From Frontmatter
|
||||
|
||||
Use frontmatter links when the relationship should become structured metadata.
|
||||
|
||||
```yaml
|
||||
related_to:
|
||||
- "[[git-workflows]]"
|
||||
```
|
||||
|
||||
## Keep Links Stable
|
||||
|
||||
Prefer clear note titles and filenames. Tolaria's wikilink autocomplete helps you pick the right target while you type.
|
||||
6
src-tauri/resources/agent-docs/home.md
Normal file
@@ -0,0 +1,6 @@
|
||||
# Index
|
||||
|
||||
Source: index.md
|
||||
URL: /
|
||||
|
||||
<LandingHome />
|
||||
79
src-tauri/resources/agent-docs/index.md
Normal file
@@ -0,0 +1,79 @@
|
||||
# Tolaria Agent Docs
|
||||
|
||||
These docs are generated from the public Tolaria documentation for local AI agent lookup.
|
||||
|
||||
Start here, then use `rg` over this folder for specific Tolaria concepts and workflows.
|
||||
|
||||
## Home
|
||||
|
||||
- [Index](pages/index.md)
|
||||
|
||||
## Start
|
||||
|
||||
- [First Launch](pages/start/first-launch.md)
|
||||
- [Getting Started Vault](pages/start/getting-started-vault.md)
|
||||
- [Install Tolaria](pages/start/install.md)
|
||||
- [Open Or Create A Vault](pages/start/open-or-create-vault.md)
|
||||
|
||||
## Concepts
|
||||
|
||||
- [AI](pages/concepts/ai.md)
|
||||
- [Editor](pages/concepts/editor.md)
|
||||
- [Files And Media](pages/concepts/files-and-media.md)
|
||||
- [Git](pages/concepts/git.md)
|
||||
- [Inbox](pages/concepts/inbox.md)
|
||||
- [Notes](pages/concepts/notes.md)
|
||||
- [Properties](pages/concepts/properties.md)
|
||||
- [Relationships](pages/concepts/relationships.md)
|
||||
- [Types](pages/concepts/types.md)
|
||||
- [Vaults](pages/concepts/vaults.md)
|
||||
|
||||
## Guides
|
||||
|
||||
- [Build Custom Views](pages/guides/build-custom-views.md)
|
||||
- [Capture A Note](pages/guides/capture-a-note.md)
|
||||
- [Manage Git Manually Or With AutoGit](pages/guides/commit-and-push.md)
|
||||
- [Configure AI Models](pages/guides/configure-ai-models.md)
|
||||
- [Connect A Git Remote](pages/guides/connect-a-git-remote.md)
|
||||
- [Create Types](pages/guides/create-types.md)
|
||||
- [Manage Display Preferences](pages/guides/manage-display-preferences.md)
|
||||
- [Organize The Inbox](pages/guides/organize-inbox.md)
|
||||
- [Use The AI](pages/guides/use-ai-panel.md)
|
||||
- [Use The Command Palette](pages/guides/use-command-palette.md)
|
||||
- [Use Media Previews](pages/guides/use-media-previews.md)
|
||||
- [Use The Table Of Contents](pages/guides/use-table-of-contents.md)
|
||||
- [Use Wikilinks](pages/guides/use-wikilinks.md)
|
||||
|
||||
## Reference
|
||||
|
||||
- [Contribute](pages/reference/contribute.md)
|
||||
- [Docs Maintenance](pages/reference/docs-maintenance.md)
|
||||
- [File Layout](pages/reference/file-layout.md)
|
||||
- [Frontmatter Fields](pages/reference/frontmatter-fields.md)
|
||||
- [Keyboard Shortcuts](pages/reference/keyboard-shortcuts.md)
|
||||
- [Release Channels](pages/reference/release-channels.md)
|
||||
- [Supported Platforms](pages/reference/supported-platforms.md)
|
||||
- [View Filters](pages/reference/view-filters.md)
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- [AI Agent Not Found](pages/troubleshooting/ai-agent-not-found.md)
|
||||
- [Git Authentication](pages/troubleshooting/git-auth.md)
|
||||
- [Model Provider Connection](pages/troubleshooting/model-provider-connection.md)
|
||||
- [Sync Conflicts](pages/troubleshooting/sync-conflicts.md)
|
||||
- [Vault Not Loading](pages/troubleshooting/vault-not-loading.md)
|
||||
|
||||
## Download
|
||||
|
||||
- [Download](pages/download/index.md)
|
||||
|
||||
## Releases
|
||||
|
||||
- [Releases](pages/releases/index.md)
|
||||
|
||||
## Generated Files
|
||||
|
||||
- `all.md`: all public docs concatenated for fast full-context reads.
|
||||
- `search-index.json`: title, heading, section, path, and URL metadata for quick routing.
|
||||
- `<section>.md`: one compact bundle per docs section.
|
||||
- `pages/`: one generated Markdown file per public docs page.
|
||||
37
src-tauri/resources/agent-docs/pages/concepts/ai.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# AI
|
||||
|
||||
Source: concepts/ai.md
|
||||
URL: /concepts/ai
|
||||
|
||||
# AI
|
||||
|
||||
Tolaria has two AI paths: coding agents that can use tools to inspect and edit a vault, and direct model targets that answer in chat mode from note context.
|
||||
|
||||
## Coding Agents
|
||||
|
||||
The AI panel can stream supported local CLI agents through Tolaria's normalized event layer. Current targets include Claude Code, Codex, OpenCode, Pi, and Gemini CLI when they are installed on the machine.
|
||||
|
||||
Coding agents can run in:
|
||||
|
||||
- **Vault Safe** mode, limited to file, search, and edit tools.
|
||||
- **Power User** mode, which can allow local shell commands scoped to the active vault for agents that support shell access.
|
||||
|
||||
## Direct Models
|
||||
|
||||
Direct model targets run in chat mode. They receive the active note, linked context, and conversation history, but they do not receive vault-write tools or shell access.
|
||||
|
||||
Supported provider shapes include:
|
||||
|
||||
- Local models through Ollama or LM Studio.
|
||||
- Hosted providers such as OpenAI, Anthropic, Gemini, and OpenRouter.
|
||||
- Custom OpenAI-compatible endpoints.
|
||||
|
||||
## External MCP Setup
|
||||
|
||||
Tolaria exposes an MCP server for external tools. The setup flow can write Tolaria's MCP entry into Claude Code, Gemini CLI, Cursor, and a generic MCP config path, and it can also copy the exact JSON snippet for manual setup.
|
||||
|
||||
MCP setup is explicit. Closing the dialog leaves third-party config files untouched.
|
||||
|
||||
## Why Git Matters For AI
|
||||
|
||||
AI-generated changes should be inspectable. Git gives you diffs, history, rollback, and a clear boundary between suggestions and committed work.
|
||||
28
src-tauri/resources/agent-docs/pages/concepts/editor.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Editor
|
||||
|
||||
Source: concepts/editor.md
|
||||
URL: /concepts/editor
|
||||
|
||||
# Editor
|
||||
|
||||
Tolaria offers a rich editor for daily writing and a raw Markdown mode for exact file control. Both modes write back to the same Markdown file.
|
||||
|
||||
## Rich Editing
|
||||
|
||||
The rich editor supports blocks, slash commands, wikilinks, tables, code blocks, images, Mermaid diagrams, LaTeX-style math, and markdown-backed whiteboards.
|
||||
|
||||
Use it when you want to write and reorganize quickly without thinking about Markdown syntax.
|
||||
|
||||
## Raw Mode
|
||||
|
||||
Raw mode shows the Markdown source directly. Use it when you need to edit YAML frontmatter, repair unusual Markdown, or make an exact text change.
|
||||
|
||||
Toggle raw mode with `Cmd+\` on macOS or `Ctrl+\` on Windows and Linux.
|
||||
|
||||
## Table Of Contents
|
||||
|
||||
The table of contents panel builds an outline from headings in the current note. It is useful for long notes, procedures, research files, and generated documents. Toggle it with `Cmd+Shift+T` on macOS or `Ctrl+Shift+T` on Windows and Linux.
|
||||
|
||||
## Width
|
||||
|
||||
Notes can use normal or wide editor width. Set the default in Settings, or override an individual note from the editor toolbar.
|
||||
@@ -0,0 +1,39 @@
|
||||
# Files And Media
|
||||
|
||||
Source: concepts/files-and-media.md
|
||||
URL: /concepts/files-and-media
|
||||
|
||||
# Files And Media
|
||||
|
||||
Tolaria starts with Markdown notes, but a vault can also contain images, PDFs, media files, whiteboards, and other local files.
|
||||
|
||||
## Mermaid Diagrams
|
||||
|
||||
Use Mermaid code blocks when a note needs a diagram that should stay plain text and versionable.
|
||||
|
||||
````md
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Idea --> Draft --> Review --> Publish
|
||||
```
|
||||
````
|
||||
|
||||
Tolaria renders Mermaid diagrams in the editor while keeping the source in Markdown.
|
||||
|
||||
## Attachments
|
||||
|
||||
Images pasted into the editor are saved into the vault as normal files. They remain portable and can be opened by other tools.
|
||||
|
||||
## Previews
|
||||
|
||||
Tolaria can preview common image files, PDFs, and supported media files in the app. Files without an in-app preview can still be opened in the default system app.
|
||||
|
||||
Settings control whether PDFs, images, and unsupported files appear in All Notes. Folder browsing still shows files in their folders.
|
||||
|
||||
## Whiteboards
|
||||
|
||||
Whiteboards use tldraw in the editor, but their durable representation stays in Markdown. That keeps them inside the vault and versioned by Git with the rest of your notes.
|
||||
|
||||
## Git Boundary
|
||||
|
||||
If generated or local-only files are ignored by Git, Tolaria can hide them from notes, search, quick open, and folders. Use this when build artifacts or private local files should not behave like vault content.
|
||||
34
src-tauri/resources/agent-docs/pages/concepts/git.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Git
|
||||
|
||||
Source: concepts/git.md
|
||||
URL: /concepts/git
|
||||
|
||||
# Git
|
||||
|
||||
Git is Tolaria's recommended history and sync layer. Tolaria can work with plain Markdown folders, and Git unlocks local history, recovery, remote backup, and multi-device workflows when you want them.
|
||||
|
||||
Tolaria acts as a lightweight Git client for your vault. You can review changes, commit, pull, push, and inspect history without leaving the app.
|
||||
|
||||
## What Tolaria Uses Git For
|
||||
|
||||
- Whole-vault commit history.
|
||||
- Current diff for the vault.
|
||||
- Per-note history.
|
||||
- Current diff for an individual note.
|
||||
- Pull and push.
|
||||
- Conflict detection and resolution.
|
||||
- Remote connection for local-only vaults.
|
||||
|
||||
## History And Diffs
|
||||
|
||||
Each note can show its own history and current diff, so you can understand how that file changed over time or what is unsaved relative to Git.
|
||||
|
||||
Tolaria also shows a history of the whole vault. Use it when you want to review broader changes across multiple notes before committing or syncing.
|
||||
|
||||
## Local Commits
|
||||
|
||||
You can commit changes inside Tolaria without leaving the app. This gives you useful restore points even before a remote is configured.
|
||||
|
||||
## Remotes
|
||||
|
||||
Connect a compatible Git remote when you want sync or backup. Tolaria relies on your system Git authentication, so GitHub CLI, SSH keys, credential helpers, and existing Git configuration can continue to work.
|
||||
28
src-tauri/resources/agent-docs/pages/concepts/inbox.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Inbox
|
||||
|
||||
Source: concepts/inbox.md
|
||||
URL: /concepts/inbox
|
||||
|
||||
# Inbox
|
||||
|
||||
The Inbox is for notes that have been captured but not yet organized.
|
||||
|
||||
## Why It Exists
|
||||
|
||||
Fast capture should not require perfect structure. The Inbox gives you a place to put incomplete notes, then process them later.
|
||||
|
||||
The Inbox workflow is optional. Turn it off in Settings > Workflow if you prefer every note to appear organized by default.
|
||||
|
||||
## Organizing Inbox Notes
|
||||
|
||||
When reviewing the Inbox:
|
||||
|
||||
1. Give the note a clear H1.
|
||||
2. Set its `type`.
|
||||
3. Add status, dates, or URL if useful.
|
||||
4. Add relationships with wikilinks or frontmatter fields.
|
||||
5. Move it into a folder only if the folder adds value.
|
||||
|
||||
## Healthy Inbox Habit
|
||||
|
||||
Keep the Inbox small enough that it can be reviewed in one focused pass. Tolaria works best when capture is fast and organization is deliberate.
|
||||
39
src-tauri/resources/agent-docs/pages/concepts/notes.md
Normal file
@@ -0,0 +1,39 @@
|
||||
# Notes
|
||||
|
||||
Source: concepts/notes.md
|
||||
URL: /concepts/notes
|
||||
|
||||
# Notes
|
||||
|
||||
A note is a Markdown file with optional YAML frontmatter. Tolaria reads the first H1 as the primary title and keeps the file on disk as the durable representation.
|
||||
|
||||
## Anatomy
|
||||
|
||||
```md
|
||||
---
|
||||
type: Project
|
||||
status: Active
|
||||
belongs_to:
|
||||
- "[[workspace]]"
|
||||
---
|
||||
|
||||
# Launch Documentation
|
||||
|
||||
Draft the public Tolaria docs and keep them close to code changes.
|
||||
```
|
||||
|
||||
## Titles
|
||||
|
||||
The first H1 is the note title. Tolaria uses that title wherever the note is displayed: note lists, search results, wikilink suggestions, relationship pickers, tabs, and window titles.
|
||||
|
||||
The title is separate from the filename. The filename stays visible in the breadcrumb so you can see the file on disk, and you can rename it independently when needed.
|
||||
|
||||
Use the breadcrumb action to rename the file to match the title. New untitled notes can also auto-rename from the first H1 the first time they get a real title. Turn this behavior off in Settings > Vault Content > Titles & Filenames if you prefer filenames to stay unchanged until you rename them manually.
|
||||
|
||||
## Body Links
|
||||
|
||||
Use `[[wikilinks]]` to connect notes from the body. Tolaria shows autocomplete suggestions while you type, and links can resolve by filename or title.
|
||||
|
||||
## Frontmatter
|
||||
|
||||
Use frontmatter for structured fields such as type, status, date, URL, and relationships. Keep free-form thinking in the body.
|
||||
31
src-tauri/resources/agent-docs/pages/concepts/properties.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# Properties
|
||||
|
||||
Source: concepts/properties.md
|
||||
URL: /concepts/properties
|
||||
|
||||
# Properties
|
||||
|
||||
Properties are frontmatter fields that Tolaria can display, filter, and edit.
|
||||
|
||||
## Suggested Properties
|
||||
|
||||
Suggested properties are the fields Tolaria knows how to create quickly from the Properties panel. When a suggested property is missing, the panel shows a shortcut to add it with the right editor.
|
||||
|
||||
| Field | Purpose |
|
||||
| --- | --- |
|
||||
| `type` | Groups the note into a type such as Project, Person, or Topic. |
|
||||
| `status` | Tracks lifecycle state such as Active, Done, or Blocked. |
|
||||
| `url` | Stores a canonical external link. |
|
||||
| `date` | Represents a single date. |
|
||||
|
||||
## System Properties
|
||||
|
||||
Fields that start with `_` are system properties. They remain in plain text but are hidden from normal property editing.
|
||||
|
||||
Examples include `_icon`, `_color`, `_order`, `_sidebar_label`, `_width`, and `_pinned_properties` on type documents or notes.
|
||||
|
||||
## Property Editing
|
||||
|
||||
The Properties panel is the safest place to edit structured properties. Toggle it with `Cmd+Shift+I` on macOS or `Ctrl+Shift+I` on Windows and Linux.
|
||||
|
||||
Date fields use Tolaria's picker, relationship fields can use wikilinks, and raw Markdown mode is available when you need direct control over YAML.
|
||||
@@ -0,0 +1,37 @@
|
||||
# Relationships
|
||||
|
||||
Source: concepts/relationships.md
|
||||
URL: /concepts/relationships
|
||||
|
||||
# Relationships
|
||||
|
||||
Relationships make a vault feel like a graph instead of a pile of documents.
|
||||
|
||||
## Relationship Fields
|
||||
|
||||
Any frontmatter field containing wikilinks can become a relationship. Relationship fields can point to one note or to an array of notes.
|
||||
|
||||
```yaml
|
||||
belongs_to:
|
||||
- "[[product-work]]"
|
||||
related_to:
|
||||
- "[[documentation]]"
|
||||
- "[[editor-research]]"
|
||||
blocked_by:
|
||||
- "[[release-process]]"
|
||||
- "[[sync-conflicts]]"
|
||||
```
|
||||
|
||||
Tolaria supports default relationship fields out of the box: `belongs_to`, `has`, and `related_to`. It also detects custom relationship fields dynamically when they contain wikilinks.
|
||||
|
||||
Default relationships have automatically computed inverses. If a note says it `belongs_to` a project, the project can show that note under its inverse `has` relationship without you writing the reverse link by hand. `related_to` works as a lateral relationship in both directions.
|
||||
|
||||
These outgoing and inverse relationships appear in the Properties panel and in Neighborhood mode, where the note list becomes a graph view around the selected note.
|
||||
|
||||
## Body Links Versus Relationship Fields
|
||||
|
||||
Use body links when the relationship appears naturally in writing. Use frontmatter relationships when the connection is important enough to show in navigation, filters, Neighborhood mode, or the Properties panel.
|
||||
|
||||
## Backlinks
|
||||
|
||||
Tolaria can show incoming links and inverse relationships, making it easier to navigate from a note to the rest of its context.
|
||||
54
src-tauri/resources/agent-docs/pages/concepts/types.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# Types
|
||||
|
||||
Source: concepts/types.md
|
||||
URL: /concepts/types
|
||||
|
||||
# Types
|
||||
|
||||
Types describe what kind of thing a note represents: Project, Person, Topic, Procedure, Event, or any category you create.
|
||||
|
||||
## Type Field
|
||||
|
||||
The `type:` field assigns a note to a type.
|
||||
|
||||
```yaml
|
||||
type: Project
|
||||
```
|
||||
|
||||
Tolaria does not infer type from folder location. Moving a file into another folder does not change its type.
|
||||
|
||||
## Prefer Types Over Folders
|
||||
|
||||
Types are the preferred way to group notes in Tolaria. Folders are supported for existing vaults and fallback organization, but Tolaria is built around types and relationships because they carry stronger meaning than file paths.
|
||||
|
||||
Use types for semantic groups such as Projects, People, Topics, Procedures, Events, and Essays. Use relationships to connect notes across those groups. This gives Tolaria better structure for navigation, filtering, properties, templates, and future automation than folder location alone.
|
||||
|
||||
## Type Documents
|
||||
|
||||
Type documents are Markdown notes with `type: Type` in frontmatter. They describe how a type should appear and what new notes of that type should start with.
|
||||
|
||||
```yaml
|
||||
---
|
||||
type: Type
|
||||
_icon: folder
|
||||
_color: blue
|
||||
_sidebar_label: Projects
|
||||
_order: 10
|
||||
---
|
||||
|
||||
# Project
|
||||
```
|
||||
|
||||
## What Types Control
|
||||
|
||||
- Sidebar grouping.
|
||||
- Type icon and color.
|
||||
- Sidebar order and label.
|
||||
- Pinned properties.
|
||||
- New-note templates.
|
||||
|
||||
## New Note Defaults
|
||||
|
||||
Type documents can define empty properties and relationships. When you create a new note of that type, Tolaria shows placeholders for those fields so you can fill them in from the Properties panel.
|
||||
|
||||
If a type document gives a property a value, that value becomes the default for new notes of that type. For example, a Project type can define `status: Active` so every new project starts active until you change it.
|
||||
40
src-tauri/resources/agent-docs/pages/concepts/vaults.md
Normal file
@@ -0,0 +1,40 @@
|
||||
# Vaults
|
||||
|
||||
Source: concepts/vaults.md
|
||||
URL: /concepts/vaults
|
||||
|
||||
# Vaults
|
||||
|
||||
A vault is the folder Tolaria reads and writes. The filesystem is the source of truth; the app state and cache are derived from files.
|
||||
|
||||
## Core Rules
|
||||
|
||||
- Notes are Markdown files.
|
||||
- YAML frontmatter provides structure.
|
||||
- Attachments are normal files inside the vault.
|
||||
- Type definitions and saved views are also files.
|
||||
- Git can track history and support remote sync.
|
||||
|
||||
## Why Local Files Matter
|
||||
|
||||
Local files keep your notes inspectable. You can open them in another editor, search with command-line tools, back them up with your own system, and version them with Git.
|
||||
|
||||
Tolaria should never become the only way to read your data.
|
||||
|
||||
## Git Is A Capability
|
||||
|
||||
A plain folder of Markdown files can open as a vault. Git-backed vaults unlock history, changes, commits, pull, push, conflict handling, and remote setup.
|
||||
|
||||
If a folder is not a Git repository, Tolaria can initialize Git when you explicitly ask it to. It avoids initializing broad personal folders such as Desktop, Documents, or Downloads unless they are clearly dedicated vault folders.
|
||||
|
||||
## App State Versus Vault State
|
||||
|
||||
Vault-level information should travel with the vault. Machine-specific preferences stay with the app installation.
|
||||
|
||||
| Vault state | App state |
|
||||
| --- | --- |
|
||||
| Type icons and colors | Editor zoom |
|
||||
| Saved views | Window size |
|
||||
| Pinned properties | Recent vault list |
|
||||
| Relationship conventions | Local cache |
|
||||
| Vault AI guidance files | AI target selection |
|
||||
24
src-tauri/resources/agent-docs/pages/download/index.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Download
|
||||
|
||||
Source: download/index.md
|
||||
URL: /download/
|
||||
|
||||
# Download
|
||||
|
||||
Download Tolaria from the latest stable release.
|
||||
|
||||
## Latest Stable
|
||||
|
||||
[Open the installer download page](https://refactoringhq.github.io/tolaria/download/)
|
||||
|
||||
The download page reads the latest stable release metadata and points you to the current macOS, Windows, or Linux artifact.
|
||||
|
||||
## Other Builds
|
||||
|
||||
- [Browse all GitHub releases](https://github.com/refactoringhq/tolaria/releases)
|
||||
- [Read release history](/releases/)
|
||||
- [Learn release channels](/reference/release-channels)
|
||||
|
||||
## Verify The Version
|
||||
|
||||
After launching the app, check the version shown in Tolaria's status bar or release surface.
|
||||
@@ -0,0 +1,30 @@
|
||||
# Build Custom Views
|
||||
|
||||
Source: guides/build-custom-views.md
|
||||
URL: /guides/build-custom-views
|
||||
|
||||
# Build Custom Views
|
||||
|
||||
Custom views are saved filters for recurring questions.
|
||||
|
||||
## Good View Candidates
|
||||
|
||||
- Active projects.
|
||||
- People without a recent follow-up.
|
||||
- Drafts ready for review.
|
||||
- Notes changed this week.
|
||||
- Events in a date range.
|
||||
|
||||
## View Definition
|
||||
|
||||
Saved views live as files in the vault. They describe filters, sorting, and visible columns using structured data.
|
||||
|
||||
## Filters
|
||||
|
||||
Custom views can use nested conditions, similar to Notion or Airtable filter groups. Combine `all` and `any` logic when a view needs to answer a more precise question than a single field filter can express.
|
||||
|
||||
Date filters support dynamic natural-language values such as `today`, `yesterday`, or `one week ago`. Use these for views that should keep moving over time, such as recent work, stale follow-ups, or upcoming events.
|
||||
|
||||
## Design The Question First
|
||||
|
||||
Before creating a view, write the question it answers. A good view is not "all fields with all filters"; it is a focused lens.
|
||||