@thjodann/wk 1.0.0

package/dist/templates/symbolsPage.d.ts

@@ -0,0 +1,2 @@
+import type { SymbolRecord } from "../core/schemas";
+export declare function symbolsPage(records: SymbolRecord[]): string;

package/dist/templates/symbolsPage.js

@@ -0,0 +1,25 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.symbolsPage = symbolsPage;
+function symbolsPage(records) {
+    const sorted = [...records].sort((a, b) => a.name.localeCompare(b.name) || a.file.localeCompare(b.file) || a.id.localeCompare(b.id));
+    const body = sorted.length
+        ? sorted.map(renderSymbol).join("\n\n")
+        : "_No symbols captured yet._";
+    return `# Symbols
+
+${body}
+`;
+}
+function renderSymbol(record) {
+    return `## ${record.name}
+
+Kind: ${record.kind}
+
+File: \`${record.file}\`
+
+${record.summary || "_No summary recorded._"}
+
+Record: \`${record.id}\` | Authority: ${record.authority} | Confidence: ${record.confidence}`;
+}
+//# sourceMappingURL=symbolsPage.js.map

package/dist/templates/symbolsPage.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"symbolsPage.js","sourceRoot":"","sources":["../../src/templates/symbolsPage.ts"],"names":[],"mappings":";;AAEA,kCAYC;AAZD,SAAgB,WAAW,CAAC,OAAuB;IACjD,MAAM,MAAM,GAAG,CAAC,GAAG,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CACxC,CAAC,CAAC,IAAI,CAAC,aAAa,CAAC,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,aAAa,CAAC,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,EAAE,CAAC,aAAa,CAAC,CAAC,CAAC,EAAE,CAAC,CACzF,CAAC;IACF,MAAM,IAAI,GAAG,MAAM,CAAC,MAAM;QACxB,CAAC,CAAC,MAAM,CAAC,GAAG,CAAC,YAAY,CAAC,CAAC,IAAI,CAAC,MAAM,CAAC;QACvC,CAAC,CAAC,4BAA4B,CAAC;IAEjC,OAAO;;EAEP,IAAI;CACL,CAAC;AACF,CAAC;AAED,SAAS,YAAY,CAAC,MAAoB;IACxC,OAAO,MAAM,MAAM,CAAC,IAAI;;QAElB,MAAM,CAAC,IAAI;;UAET,MAAM,CAAC,IAAI;;EAEnB,MAAM,CAAC,OAAO,IAAI,wBAAwB;;YAEhC,MAAM,CAAC,EAAE,mBAAmB,MAAM,CAAC,SAAS,kBAAkB,MAAM,CAAC,UAAU,EAAE,CAAC;AAC9F,CAAC"}

package/docs/concepts.md

@@ -0,0 +1,249 @@
+# Concepts
+
+Wikiwiki helps a repo keep its own project knowledge close to the code. It
+works as a deterministic CLI for humans and scripts, then gives agentic IDEs a
+structured way to add judgment when that helps.
+
+The goal is living docs that are local, reviewable, and reproducible. The
+source of truth is not a hosted service, vector database, or hidden memory
+layer. It is plain records committed beside the project.
+
+## Why Wikiwiki
+
+Software teams lose context in the spaces between code:
+
+- why a system exists
+- what a module owns
+- which decisions shaped the current design
+- what changed during a messy implementation session
+- which generated docs should never be edited by hand
+
+Wikiwiki turns that context into repo-local knowledge. Scripts can validate and
+render it with normal terminal commands. Agents can enrich it when they are
+already part of the workflow. Humans browse a wiki that leads with the project,
+not the generator.
+
+## The Loop
+
+The daily loop is intentionally small:
+
+```sh
+wk setup --profile mixed --audience all
+wk status --json
+wk spin --profile mixed --json
+wk article add --title "Getting started" --summary "First successful user path." --body "TODO"
+wk note add --title "Generated file workflow" "Renderer owns generated wiki files." --tags renderer,docs
+wk validate
+wk render
+wk site --audience all
+wk closeout --profile mixed --audience all
+```
+
+That loop can run from a terminal, package script, Git hook, CI job, or
+agentic IDE. It lets a project:
+
+1. Inspect the current knowledge store.
+2. Read working tree changes.
+3. Add or update article records for public wiki pages.
+4. Add concepts, decisions, notes, events, symbols, and links as evidence and maintainer context.
+5. Validate the records.
+6. Render Markdown into `wiki/`.
+7. Render a browseable static site into `wiki-site/`.
+8. Create a closeout draft packet when a meaningful objective is done.
+
+The structured records are the source of truth. Article records are the public
+wiki pages. Concepts, decisions, notes, events, symbols, and links are the
+ledger that explains where those articles came from and what maintainers should
+remember. Markdown stays simple and deterministic for agents. The static site
+is the first-class human wiki.
+
+## Automation Model
+
+Wikiwiki has two layers.
+
+**Deterministic baseline:** install the CLI, keep `.wikiwiki/records/` in the
+repo, and run scripts that validate, render Markdown, and build the static
+site. This path works without AI tools and should stay useful for any project.
+
+**Agent-enhanced layer:** install optional agent instructions so Codex, Cursor,
+Claude Code, or another coding agent knows when to run `wk spin`, when to add
+records, how to set honest `authority` and `confidence`, and how to refresh
+the generated wiki before closeout.
+
+Use scripts for repeatable work. Use agents for judgment: deciding what
+changed, capturing why it mattered, curating homepage-worthy knowledge, writing
+UX/DX draft prose, and adjusting the project theme. That keeps unnecessary LLM
+calls out of the loop while preserving the upside of agentic development.
+
+`wk closeout` is the portable "I finished Objective B" command:
+
+```sh
+wk closeout --profile mixed --audience all --json
+```
+
+It runs status, spin, validation, Markdown rendering, and site generation. It
+also writes a review packet under `.wikiwiki/drafts/closeout/` containing
+record draft JSON files, command hints, a summary, and a manifest. Closeout
+drafts are deterministic prompts, not automatic truth: Wikiwiki never appends
+records from closeout unless a user or agent deliberately applies them.
+
+## What It Stores
+
+Wikiwiki stores records as append-friendly JSONL files under
+`.wikiwiki/records/`.
+
+| Record | Use it for |
+| --- | --- |
+| `article` | Public wiki pages with title, slug, summary, body, categories, aliases, sources, and files |
+| `concept` | Domain terms, systems, patterns, and durable explanations |
+| `decision` | Architecture, product, implementation, or workflow decisions |
+| `event` | Development milestones and meaningful project changes |
+| `note` | Lightweight titled or dated facts, reminders, and working context |
+| `symbol` | Important code symbols and their purpose |
+| `link` | Relationships between records, files, and generated pages |
+
+Each record carries `source`, `authority`, and `confidence` so agents can be
+honest about what they know.
+
+## What It Renders
+
+Wikiwiki renders generated Markdown pages into `wiki/` for agents and
+plain-text review:
+
+```text
+wiki/
+  index.md
+  articles.md
+  articles/
+    getting-started.md
+  concepts.md
+  decisions.md
+  devlog.md
+  notes.md
+  symbols.md
+  links.md
+```
+
+Generated wiki files are plainly marked:
+
+```html
+<!-- Generated by Wikiwiki. Edit structured records instead. -->
+```
+
+That boundary matters. Agents should update article records for public wiki
+changes, use supporting records for evidence and agent context, then run
+`wk render`.
+
+Wikiwiki also renders a static human-facing site into `wiki-site/`:
+
+```text
+wiki-site/
+  index.html
+  articles.html
+  articles/
+    getting-started.html
+  guides.html
+  concepts.html
+  decisions.html
+  devlog.html
+  notes.html
+  symbols.html
+  links.html
+  records/
+    concept/
+      concept_123.html
+  work.html        # optional, developer-only when Beads site output is enabled
+  search.html
+  assets/
+    wikiwiki.css
+    project-theme.css
+    search-index.js
+    wikiwiki.js
+```
+
+The site uses normal `.html` links, article-led home/guides/search pages,
+secondary agent record indexes, responsive navigation, local browser search,
+subtle agent metadata, and a small footer credit. Article records publish as
+public article pages; they do not generate `records/article/*` detail pages.
+The site does not rely on Jekyll routes or raw front matter, so you can open
+`wiki-site/index.html` directly or serve the folder as static files.
+
+There are four generated or structured project surfaces:
+
+| Surface | Audience | Role |
+| --- | --- | --- |
+| `.wikiwiki/records/*.jsonl` | Agents and maintainers | Source of truth: public articles plus evidence records |
+| `wiki/*.md` | Agents and code review | Deterministic Markdown |
+| `wiki-site/*.html` | Humans | Browseable project wiki |
+| `wiki/human/` | Humans and editors | Compiled UX/DX narrative drafts |
+
+## Working With Beads
+
+Wikiwiki and Beads can live in the same repo without either tool absorbing the
+other.
+
+Beads owns the work graph: tasks, blockers, dependencies, ownership, ready
+work, in-progress work, closed work, and agent work memory. Wikiwiki owns the
+knowledge graph: public articles, durable concepts, decisions, notes, events,
+symbols, links, generated Markdown, and the human wiki.
+
+When `.beads/` exists, Wikiwiki automatically detects it. Detailed reads
+through `bd --readonly --json` are opt-in because some Beads versions can touch
+internal storage while serving read commands. With
+`integrations.beads.enabled: true`, clean Beads context appears in JSON reports
+and closeout drafts. Site publishing uses the same explicit opt-in: `work.html`
+is only generated for developer/all audiences when `.wikiwiki/config.json`
+sets `integrations.beads.enabled` to `true`. User-focused sites hide Beads
+from pages, manifests, and search data so task state does not leak into
+standard user documentation.
+
+If Beads is absent, nothing changes. If `.beads/` exists but `bd` is not
+available, Wikiwiki keeps running and shows an unavailable state instead of
+failing the wiki build.
+
+## Audience Tags
+
+Use audience tags on records so Wikiwiki can render the same knowledge base for
+different readers:
+
+- `audience:user`
+- `audience:developer`
+- `audience:all`
+
+Use these conventional topic tags for user-facing material:
+
+- `getting-started`
+- `instructions`
+- `faq`
+- `troubleshooting`
+
+Example:
+
+```sh
+wk concept add \
+  --name "Getting started" \
+  --summary "How a new user gets from install to first useful session." \
+  --tags audience:user,getting-started,instructions
+```
+
+For developer records, prefer tags such as `audience:developer`,
+`architecture`, `data-model`, `generated-files`, `maintenance`, and `symbol`.
+
+## Human Wiki Compilation
+
+Wikiwiki can compile role-oriented human wiki drafts from the same source
+records:
+
+```sh
+wk compile draft --role all --json
+wk compile apply compile_123 --json
+```
+
+`compile draft` creates an agent-mediated work packet under
+`.wikiwiki/drafts/compile/`. Codex, Cursor, Claude Code, or another IDE agent
+can use that packet to write polished UX and DX wiki prose. `compile apply`
+then validates provenance and publishes the human-readable pages into
+`wiki/human/`.
+
+The UX wiki explains the product experience for users and stakeholders. The DX
+wiki explains the developer experience for maintainers and coding agents.

package/docs/reference.md

@@ -0,0 +1,356 @@
+# Reference
+
+This page collects command, profile, theme, publishing, status, and roadmap
+details that are useful after the first quick start.
+
+## Commands
+
+| Command | Purpose |
+| --- | --- |
+| `wk init [--profile mixed\|user\|developer]` | Create the knowledge store and choose a first-pass wiki profile |
+| `wk setup [--profile mixed\|user\|developer] [--audience all\|user\|developer]` | Create repo defaults and safe package scripts for portable wiki automation |
+| `wk closeout [--profile mixed\|user\|developer] [--audience all\|user\|developer] --json` | Create a deterministic closeout draft packet, then validate and render docs |
+| `wk status --json` | Report store status, record counts, generated pages, and Git changes |
+| `wk install-agent codex [--yes] [--force]` | Install the bundled wk skill for Codex-compatible agents |
+| `wk pages init [--audience all\|user\|developer] [--branch <branch>] [--source-base-url <url>]` | Scaffold GitHub Pages publishing for `wiki-site/` |
+| `wk spin [--profile mixed\|user\|developer] --json` | Inspect repo changes and emit a deterministic first-pass wiki recipe |
+| `wk search <query> --json` | Search active records and rendered Markdown |
+| `wk site [--audience all\|user\|developer] [--source-base-url <url>]` | Render a browseable static HTML wiki into `wiki-site/` |
+| `wk theme preview\|init [--mood calm\|vivid\|editorial\|utility\|playful\|dark]` | Preview or write light/dark `.wikiwiki/site-theme.json` palettes from project identity |
+| `wk compile draft --role all --json` | Create UX/DX human wiki drafts for an IDE agent |
+| `wk compile apply <draft-id> --json` | Validate and publish a human wiki draft |
+| `wk article add` | Add a public wiki article |
+| `wk concept add` | Add a durable project concept |
+| `wk decision add` | Add an architecture, product, or workflow decision |
+| `wk event add` | Add a development event |
+| `wk note add` | Add a lightweight note |
+| `wk symbol add` | Add an important code symbol |
+| `wk link add` | Link records, files, or wiki pages |
+| `wk record list/get/update/delete` | Read and revise active records append-only |
+| `wk validate` | Validate records and references |
+| `wk render` | Render Markdown pages into `wiki/` |
+
+## Article Records
+
+Article records are the public wiki surface. Concepts, decisions, notes,
+events, symbols, and links remain the ledger behind them: evidence, provenance,
+maintainer context, and source anchors.
+
+```sh
+wk article add \
+  --title "Skyrim:Alchemy" \
+  --summary "How alchemy works for players and maintainers." \
+  --body "Alchemy combines ingredients into potions and poisons." \
+  --categories gameplay,crafting \
+  --aliases alchemy,potions \
+  --source-records concept_123,decision_456 \
+  --files src/alchemy.ts \
+  --tags audience:all
+```
+
+If `--slug` is omitted, Wikiwiki generates one from the title. Slugs may use
+namespace-style names such as `Skyrim:Alchemy`; generated files still use safe
+filenames such as `Skyrim-Alchemy.html`. Validation rejects active duplicate
+slugs, duplicate generated filenames, and `source_record_ids` that do not point
+to active records.
+
+Articles render to `wiki/articles/` and `wiki-site/articles/`. Article records
+do not generate `records/article/*` detail pages.
+
+## Agent Requests
+
+When a user asks an agent to "Update wk", the agent should follow the
+[agentic update pipeline](setup.md#agentic-update-pipeline). The short version:
+use npm or the repo's JavaScript package manager to update the CLI when
+available; if npm is not available, refresh only the installed `wk` agent skill
+from GitHub raw files and report that the CLI itself still needs a package
+manager or release artifact.
+
+## Wiki Profiles
+
+First-pass wikis should be consistent across machines and agents. `wk spin`
+therefore emits a deterministic seeding recipe with target counts, page
+emphasis, audience tags, and copy-ready draft commands.
+
+```sh
+wk init --profile mixed
+wk spin --profile mixed --json
+```
+
+Available profiles:
+
+| Profile | Use it when | Default emphasis |
+| --- | --- | --- |
+| `mixed` | The wiki should serve users and maintainers | product promise, getting started, FAQ, troubleshooting, architecture, data model |
+| `user` | The first wiki should read like product/user help | getting started, modes/features, privacy, FAQ, troubleshooting |
+| `developer` | The first wiki is mainly for maintainers and agents | architecture, data model, workflow, decisions, symbols |
+
+`mixed` is the default. You can store the default in `.wikiwiki/config.json`:
+
+```json
+{
+  "wiki_profile": "mixed"
+}
+```
+
+The profile is guidance, not a generic content generator. It tells humans and
+agents what shape to create so separate runs against the same repo converge on
+similar record counts and page emphasis.
+
+## Site Options
+
+By default, source file links point back to files beside `wiki-site/` in a
+local checkout. For published sites, pass a source base URL so links point to
+GitHub:
+
+```sh
+wk site --audience all --source-base-url https://github.com/OWNER/REPO/blob/main/
+```
+
+You can also save that default in `.wikiwiki/config.json`:
+
+```json
+{
+  "source_base_url": "https://github.com/OWNER/REPO/blob/main/"
+}
+```
+
+CLI options win over config. Directory links use GitHub `/tree/` URLs when the
+base URL uses `/blob/`.
+
+Render a reader-specific site when needed:
+
+```sh
+wk site --audience user
+wk site --audience developer
+wk site --audience all
+```
+
+Each render replaces the same `wiki-site/` folder. Run the audience variant you
+want to inspect or publish last, or copy `wiki-site/` elsewhere before rendering
+another audience.
+
+`--audience user` keeps shared records and user-facing records while hiding
+developer-only symbols/links and records tagged `audience:developer`.
+`--audience developer` keeps shared and developer records while hiding
+user-only records. `all` is the default.
+
+You can also save a default:
+
+```json
+{
+  "site_audience": "user"
+}
+```
+
+## Optional Beads Integration
+
+If a repo contains `.beads/`, Wikiwiki automatically detects it. Detailed
+Beads reads are opt-in because some `bd --readonly` commands can still touch
+internal storage in `.beads/`. The integration is best-effort and never
+creates, edits, claims, closes, or imports Beads issues.
+
+The detection appears in JSON reports for `wk setup`, `wk status`, `wk spin`,
+and `wk closeout`. When `.wikiwiki/config.json` explicitly sets
+`integrations.beads.enabled: true`, those reports include detailed Beads
+context if `bd` can read without changing `.beads/`. Closeout manifests include
+the same Beads context so an agent can relate durable wiki updates to active
+work without treating tasks as records.
+
+Site publishing is explicit opt-in for task details. `wk site --audience all`
+and `wk site --audience developer` generate `work.html` with ready work,
+in-progress work, and recently closed work only when `.wikiwiki/config.json`
+contains `integrations.beads.enabled: true`. Without that explicit opt-in, site
+manifests keep at most safe Beads counts and omit issue IDs, titles, labels, and
+assignees. `wk site --audience user` hides Beads entirely, including from
+`site-manifest.json` and search data.
+
+Enable Beads site output only for internal developer publishing:
+
+```json
+{
+  "integrations": {
+    "beads": {
+      "enabled": true
+    }
+  }
+}
+```
+
+Disable the integration in `.wikiwiki/config.json` when needed:
+
+```json
+{
+  "integrations": {
+    "beads": {
+      "enabled": false
+    }
+  }
+}
+```
+
+Fallback behavior is intentionally calm:
+
+- no `.beads/`: no Beads output
+- `.beads/` with auto config: detected, with detailed reads skipped
+- `.beads/` plus explicit `enabled: true`: combined task/wiki context when
+  `bd` reads cleanly
+- `.beads/` without `bd`: Wikiwiki reports that Beads context is unavailable
+- `.beads/` that changes during a `bd` read: Wikiwiki reports Beads as
+  unavailable for that run instead of using potentially mutating context
+
+## Project Theme
+
+Agents can make the generated site feel like the project without changing the
+layout. Generated themes include light and dark palettes, and the static site
+ships with Auto, Light, and Dark controls. Preview or create a theme from repo
+identity:
+
+```sh
+wk theme preview --json
+wk theme init --mood editorial
+```
+
+`wk theme preview` and `wk theme init` inspect likely visual sources before
+falling back to README copy: app/global CSS, design tokens, theme files, landing
+page styles, and app shell/layout styles. In styled repos, the generated theme
+can infer a likely default color mode, accent spectrum, radius, font family,
+gradients, glass/gloss, shadows, badges, and tag colors. In plain repos, the
+named mood palettes remain the fallback.
+
+`wk theme init` writes `.wikiwiki/site-theme.json` and refuses to overwrite an
+existing theme unless `--force` is explicit. You can also edit
+`.wikiwiki/site-theme.json` by hand, then run `wk site`:
+
+```json
+{
+  "project_name": "PRISM",
+  "project_description": "A project wiki for PRISM.",
+  "default_color_scheme": "auto",
+  "accent": "#7c3aed",
+  "accent_strong": "#4c1d95",
+  "bg": "#faf9ff",
+  "panel": "#fffaff",
+  "panel_soft": "#f3f0ff",
+  "text": "#1f1b2e",
+  "muted": "#655f75",
+  "border": "#ded7f2",
+  "code_bg": "#f1edf8",
+  "radius": "8px",
+  "font_family": "Inter, ui-sans-serif, system-ui, sans-serif",
+  "modes": {
+    "light": {
+      "accent": "#7c3aed",
+      "accent_strong": "#4c1d95",
+      "bg": "#faf9ff",
+      "panel": "#fffaff"
+    },
+    "dark": {
+      "accent": "#c4b5fd",
+      "accent_strong": "#ede9fe",
+      "bg": "#171225",
+      "panel": "#211936",
+      "text": "#f7f2ff"
+    }
+  }
+}
+```
+
+Top-level color values are treated as the light/default palette for backwards
+compatibility. `modes.light` and `modes.dark` can override them with richer
+visual tokens such as `hero_gradient`, `card_gradient`, `sidebar_bg`, `shadow`,
+`shadow_strong`, `brand_gradient`, `badge_bg`, `tag_bg`, `focus_ring`, and
+`gloss`.
+
+Wikiwiki writes those values into `wiki-site/assets/project-theme.css`, including
+`prefers-color-scheme` rules and explicit `data-theme` overrides. Keep that file
+generated; edit `.wikiwiki/site-theme.json` instead.
+
+Wikiwiki applies basic contrast guardrails for common hex-color themes. For
+example, if a dark `bg` or `panel` would leave text unreadable, generated theme
+CSS adjusts dependent text/surface variables and comments why. For safest
+results, set `bg`, `panel`, `panel_soft`, `text`, `muted`, `border`, and
+`code_bg` together inside each mode.
+
+## GitHub Pages
+
+`wk site` writes static files and a `.nojekyll` marker into `wiki-site/`, so
+GitHub Pages can publish the folder without Jekyll-specific routing. Use
+`wk pages init` to create the publishing workflow:
+
+```sh
+wk pages init --audience all
+```
+
+The command writes `.github/workflows/wikiwiki-pages.yml`, saves the resolved
+`site_audience` and `source_base_url` in `.wikiwiki/config.json`, and reports
+the repository Settings > Pages URL when it can infer one from `origin`.
+
+Defaults are designed for low ceremony:
+
+- audience comes from `--audience`, config, then `all`
+- branch comes from `--branch`, `origin/HEAD`, then `main`
+- source links come from `--source-base-url`, config, then a GitHub `origin`
+
+If the repo is not hosted on GitHub, pass `--source-base-url` explicitly. The
+workflow path defaults to `.github/workflows/wikiwiki-pages.yml`; existing
+different workflows are preserved unless `--force` is explicit. Wikiwiki does
+not call `gh`, change repository settings, create deployment branches, or
+configure custom domains. On GitHub, set Pages Build and deployment Source to
+GitHub Actions if it is not already selected.
+
+The generated workflow uses Node 22, installs project dependencies when present,
+falls back to the documented GitHub source install for `wk`, runs
+`wk validate`, `wk render`, and `wk site`, then publishes `wiki-site/` through
+the official Pages artifact and deploy actions.
+
+## Current Status
+
+Wikiwiki is an article-first CLI foundation. It currently includes:
+
+- TypeScript CLI
+- JSONL record storage
+- first-class article records
+- append-only record revisions and deletion tombstones
+- Zod validation
+- Git-aware `spin` with deterministic `user`, `developer`, and `mixed` profile recipes
+- audience tagging with `audience:user`, `audience:developer`, and `audience:all`
+- Markdown rendering for article pages plus concepts, decisions, events, notes, symbols, and links
+- article-led static HTML site generation into `wiki-site/`
+- audience-focused site rendering with `wk site --audience user|developer|all`
+- project-first generated site UX with curated `guides.html`
+- project theme overrides through `.wikiwiki/site-theme.json`
+- product-identity light/dark theme generation through `wk theme`
+- basic contrast guardrails for common theme overrides
+- agent-mediated UX/DX human wiki compilation
+- local search across articles, active records, and rendered docs
+- agent-readable JSON output
+- scriptable non-AI setup through `wk setup` and repo scripts
+- GitHub Pages workflow scaffolding through `wk pages init`
+- deterministic closeout draft packets through `wk closeout`
+- optional read-only Beads integration with developer-only `work.html`
+- published npm package metadata for `@thjodann/wk`
+- CI and tests
+
+Some planned pieces are not built yet:
+
+- richer symbol extraction
+- draft review flows
+- watch mode
+
+Generated `wiki/` and `wiki-site/` are intentionally not shipped in the npm
+package. Installed users generate their own copies from their own records.
+
+## Roadmap
+
+The turntable metaphor is light, but useful:
+
+- `spin` inspects repo changes and suggests knowledge updates.
+- `scratch` could review recent knowledge, events, and contradictions.
+- `press` could become a friendly alias for rendering docs.
+- `crate` could rebuild indexes and local retrieval data.
+- `ask` could query the repo knowledge base.
+- `watch` could batch near-real-time updates while work is happening.
+
+Wikiwiki should stay local-first, text-first, and agent-friendly even as those
+capabilities grow.