Wiki

Rules

• Links: Use standard relative markdown links only ([Name](../entities/foo.md)). Never use Obsidian [[wikilinks]].
• Filenames: Kebab-case always (hybrid-search.md, not HybridSearch.md).
• Cross-references: Every page must have a "See Also" section linking to related pages.
• Diagrams: Use Mermaid.js fenced blocks. Include all relevant nodes — completeness over brevity. Use subgraphs to group when diagrams are large. Use graph TD for hierarchies, graph LR for pipelines, sequenceDiagram for flows, classDiagram for entity relationships.
• Mermaid reserved words: Never use Mermaid keywords as bare node IDs. Reserved words include: graph, subgraph, end, style, classDef, click, linkStyle, class, default, node, edge. Always suffix them (e.g., depGraph, graphTools, endNode).
• Over-fetch: Use higher top values than defaults (see per-phase instructions). Missing context produces shallow pages.
• No bulk reads: Always use local-rag tools (read_relevant, search_symbols, project_map, etc.) to gather information. Do not Read entire source files.
• No guessing signatures: When documenting function signatures, parameter names, method names, or units — only write what read_relevant or search_symbols actually returned. If a chunk shows function foo(query: string, db: RagDB, topK: number), write exactly that. Never invent parameter names, reorder parameters, or assume units (e.g., "tokens" vs "characters") without seeing the source.
• Verify exports: When listing a module's key exports, cross-check against search_symbols(symbol: "<module-prefix>", type: "export") results. Do not list functions that weren't in the results. Do not rename functions to what they "probably" are.

Phase 0: Mode Detection

Check if wiki/_manifest.json exists by trying to read it.

• If it does not exist → run full generation (phases 1–6).
• If it does exist → run incremental update (phase 7).

Phase 1: Discover Structure

Gather the information needed to plan the wiki.

1. Call server_info(). If 0 files are indexed, call index_files() first.
2. Call git_context() to get the current HEAD ref (store this for the manifest).
3. Call project_map(zoom: "directory", maxNodes: 100) to identify top-level modules.
4. Call project_map(maxNodes: 100) for the file-level dependency graph.
5. Call search_analytics() to identify documentation gaps.

From the results, build a list of:

• Top-level modules (directories with multiple files and clear responsibilities)
• Entry point files
• Key relationships between modules

Phase 2: Architecture Pages

Generate the three top-level architecture documents.

1. Call read_relevant("project architecture entry points main modules", top: 20).
2. Call read_relevant("configuration setup initialization", top: 20).
3. Call read_relevant("data flow request handling pipeline processing", top: 20).
4. Call read_relevant("public API exports CLI commands endpoints", top: 20).

Then write:

wiki/architecture.md

# Architecture

## Overview
One-paragraph project summary.

## Module Map
How modules relate to each other.

(Mermaid dependency graph generated from project_map — use graph TD, one node
per module, edges showing import direction)

## Entry Points
Where execution starts, what the public API surface is.

## Configuration
How the project is configured, key config files and options.

## Design Decisions
Key architectural choices and their rationale.

wiki/data-flow.md

# Data Flow

## Overview
How data enters, moves through, and exits the system.

## Primary Flows
Each major flow as a section with a Mermaid sequence diagram.

## Error Paths
How errors propagate through the system.

wiki/api-surface.md

# API Surface

## Public API
Exported functions, classes, endpoints grouped by module.

## CLI Commands
If applicable — command names, arguments, behavior.

## Configuration Options
Public-facing config keys and what they control.

Phase 3: Module Pages

For each top-level module identified in Phase 1:

1. Call project_map(focus: "<module-entry-file>", maxNodes: 100) for internal structure.
2. Call depends_on("<module-entry>") and depended_on_by("<module-entry>").
3. Call read_relevant("<module-name> purpose responsibilities", top: 15).
4. Call search_symbols(symbol: "<module-prefix>", exact: false, type: "export", top: 30) to discover exports.

Then write wiki/modules/<module-name>/index.md:

# <Module Name>

## Purpose
What this module does and why it exists.

## Structure
(Mermaid graph of internal file dependencies — use graph LR, one node per file,
edges showing internal imports)

## Files
- `path/to/file.ts` — brief description of what it does

## Key Exports
- `functionName` — what it does
- `ClassName` — what it represents

## Dependencies
What this module imports from other modules (with links to their module pages).

## Dependents
What other modules depend on this one (with links to their module pages).

## See Also
- Links to related module pages and entity pages for key exports

If the module has 10+ files or 15+ exports, also write wiki/modules/<module-name>/internals.md with a detailed breakdown of internal