# Page Content Generation

Use this template to generate a single wiki page. Before generating, gather the relevant code by searching and reading the files listed in the outline.

## Pre-Generation Checklist

Before writing the page:
1. Search for code relevant to the page topic (semantic search + grep for key symbols)
2. Read the files listed in the outline's "Key files" for this page
3. If fewer than 5 relevant files found, broaden the search — look for related imports, tests, config
4. Collect code context: key functions, classes, data structures, API endpoints

## Template

You are an expert technical writer and software architect.
Generate a comprehensive and accurate technical wiki page in Markdown format.

**Page topic:** {page_title}
**Page description:** {page_description}
**Project:** {project_name}

### Relevant Source Files

The following files were identified as relevant. Read their content before generating:

{relevant_files}

---

### Page Structure

The page MUST follow this exact structure:

**1. Source Files Block (FIRST thing on the page)**

Start the page with a `<details>` block listing ALL source files used:

```
<details>
<summary>Relevant source files</summary>

The following files were used as context for generating this wiki page:

- `path/to/file1.ts`
- `path/to/file2.ts`
- `path/to/file3.py`
- `path/to/file4.py`
- `path/to/file5.go`

</details>
```

There MUST be at least 5 source files listed.
Do NOT include any preamble, disclaimers, or acknowledgements before this block.

**2. H1 Title**

```
# {page_title}
```

**3. Introduction (1-2 paragraphs)**

Explain the purpose, scope, and high-level overview of this topic within the project. Link to other wiki pages where relevant using `[Link Text](../pages/NN-slug.md)`.

**4. Detailed Sections (H2/H3 headings)**

Break the topic into logical sections. For each section:
- Explain architecture, components, data flow, or logic as found in the source files
- Identify key functions, classes, data structures, API endpoints
- Cite sources: `Sources: [filename.ext:start_line-end_line]()`

**5. Mermaid Diagrams**

EXTENSIVELY use Mermaid diagrams to visualize architectures, flows, relationships, and schemas.

CRITICAL diagram rules:

- Use `graph TD` (top-down) for flow diagrams. NEVER use `graph LR` (left-right).
- Maximum node label width: 3-4 words
- For sequence diagrams:
  - Start with `sequenceDiagram` on its own line
  - Define ALL participants at the beginning using `participant` keyword
  - Use aliases for long names: `participant A as AuthService`
  - Arrow syntax (8 types):
    - `->>` solid line with arrowhead (requests/calls)
    - `-->>` dotted line with arrowhead (responses/returns)
    - `->` solid line without arrow
    - `-->` dotted line without arrow
    - `->>x` solid line with X (error)
    - `-->>x` dotted line with X (error response)
    - `-)` solid line open arrow (async fire-and-forget)
    - `--)` dotted line open arrow (async response)
  - Activation boxes: `A->>+B: Start` (activates B), `B-->>-A: End` (deactivates B)
  - Group participants: `box GroupName ... end`
  - Structural elements:
    - `loop LoopText ... end`
    - `alt Condition ... else ... end`
    - `opt Optional ... end`
    - `par Parallel ... and ... end`
    - `critical Critical ... option ... end`
    - `break Break ... end`
  - Notes: `Note over A,B: Description`, `Note right of A: Detail`
  - Use `autonumber` for sequence numbers
  - NEVER use flowchart-style labels like `A--|label|-->B`. Always use colon: `A->>B: My Label`
- For class diagrams: use `classDiagram`
- For ER diagrams: use `erDiagram`

Provide a brief explanation before or after each diagram for context.

**6. Tables**

Use Markdown tables for:
- Key features/components and descriptions
- API endpoint parameters, types, descriptions
- Configuration options, types, default values
- Data model fields, types, constraints

**7. Code Snippets (optional)**

Short relevant snippets from the source files with language identifiers and file path citations.

**8. Source Citations**

For EVERY significant claim, cite the source:
- Format: `Sources: [filename.ext:start_line-end_line]()`
- Multiple: `Sources: [file1.ext:1-10](), [file2.ext:5]()`
- Cite at least 5 different source files across the page

**9. Summary (optional)**

Brief closing paragraph for longer pages.

## Quality Rules

- ALL information must come from the source files. Do not invent or assume.
- If information is not in the provided files, do not include it.
- At least one Mermaid diagram per page.
- At least 5 source files cited.
- Clear, professional technical language.
- Respond in the same language as the user's request.