User Docs — Mermaid Diagrams Plan
Created 2026-06-21. Source: the docs-visuals-analysis multi-agent run over docs/{en,ru}/user/.
Goal
Add Mermaid diagrams to the highest-value user-doc pages. The analysis kept 29 diagrams (20 high, 9 medium) out of 80 raw ideas — dropping decorative two-node flows and comparisons that are better as Markdown tables. Ready-to-paste, syntax-checked code for every kept diagram is in § Diagrams below.
Conventions
- Mermaid renders inside ```mermaid fences — see
docs/en/user/mermaid.mdfor the supported diagram types. - Label line breaks use
<br/>, never\n(literal\nshows as text). All code below is already cleaned. - Insert faithfully — every diagram must reflect only what the page already describes; invent no product behavior.
- ASCII-art spots are replacements, not additions: protocol "pipeline" + "federation",
mcp"How it works",llm-wiki"Two modes" already ship ASCII art — swap the block for the diagram. - Locate by heading/section, not by the line numbers in the table (those are EN snapshots and drift).
Scope of the first pass
This pass inserts each diagram into the language the analysis sourced it from: EN pages + the RU-only pages (oauth, Импорт из Telegram, Публикация через аккаунты, change_webhooks, cron_webhooks). RU twins of EN pages are not edited yet — they need localized labels and several are flagged for rewrite in the docs audit. See RU parity follow-up.
Not doing
- Datacharts — none recommended. No numeric/time-series data on these pages; the existing
*.datachart.csvfixtures already cover the only quantitative datasets. - Admin screenshots via e2e — fully analyzed (admin-screen → doc-page manifest + a dual-use Playwright
toHaveScreenshot()/CAPTURE_DOCSharness), but deferred: too complex for now. The manifest and harness plan are recoverable from thedocs-visuals-analysisrun if revisited.
Priority table
| Priority | Page | Type | Location |
|---|---|---|---|
| high | federation.md (+ru) | sequenceDiagram | "Adding a private peer" — two-step HMAC key exchange |
| high | federation.md (+ru) | flowchart | "Federation graph" — turn the 7-status table into a debug tree |
| high | two-way-sync.md (+ru) | stateDiagram | "Status indicator" — the colored-dot lifecycle |
| high | protocol.md (+ru) | flowchart | "The pipeline" — replace the ASCII art |
| high | search.md (+ru) | flowchart | Intro — hybrid BM25 + vector merged by RRF |
| high | monetization.md (+ru) | flowchart | "How access works" — access decision tree |
| high | user_management.md (+ru) | flowchart | Unassigned-note visibility — the security pitfall |
| high | oauth.md (RU-only) | sequenceDiagram | "Как это работает" — email-must-match invariant |
| high | webhooks.md / change_webhooks.md | sequenceDiagram | Signed change-webhook round-trip + expected_hash |
| high | forms.md (+ru) | flowchart | "Submitting via GraphQL" — server decision tree |
| high | mcp.md (+ru) | sequenceDiagram | "How it works" — replace the ASCII box |
| high | llm-wiki.md (+ru) | flowchart | "Two modes of agent retrieval" — replace 2 ASCII blocks |
| high | telegram.md | flowchart | Top of page — setup-to-publish flow |
| high | telegram.md | flowchart | "Editing published posts" — live vs Reset |
| high | update_notes.md (+ru) | sequenceDiagram | Checkbox toggle (patch use case) |
| high | selfhosted.md (+ru) | flowchart | Service topology (Caddy / MinIO / trip2g) |
| high | getting-started.md (+ru) | flowchart | Top — onboarding roadmap |
| high | Импорт из Telegram.md (RU-only) | flowchart | "Как это работает" — naming + dedup + re-import |
| high | default-template.md (+ru) | flowchart | Header/footer/sidebar resolution order |
| high | templates.md (+ru) | flowchart | "How templates work" — Step 1 / Step 2 |
| medium | renderlayout.md (+ru) | sequenceDiagram | "AI agent workflow" — preview loop |
| medium | webhooks.md / cron_webhooks.md | flowchart | Cron — synchronous vs asynchronous (60s cutoff) |
| medium | forms.md (+ru) | sequenceDiagram | Turnstile two-pass submit |
| medium | protocol.md (+ru) | flowchart | "Federation" — replace ASCII art |
| medium | search.md (+ru) | flowchart | "Excluding notes from search" |
| medium | mcp.md (+ru) | flowchart | "Named entry points (?method=)" |
| medium | update_notes.md (+ru) | flowchart | expectedHash read-transform-write retry loop |
| medium | Публикация через аккаунты.md (RU-only) | flowchart | "Как работает публикация" — tag fan-out |
| medium | default-template.md (+ru) | flowchart | "Title display" — frontmatter vs H1 edge case |
RU parity follow-up
After this pass, mirror each (+ru) diagram into its RU twin with localized labels (reuse the page's existing Russian terms; keep labels terse; never translate code/property names). Hold these back until handled:
ru/user/telegram.md— a 70-word stub; rewrite the page before adding the setup/editing flows.- Pages with no RU twin (
publishing, the combinedwebhooks) — covered by the broader EN↔RU parity work in the docs audit.
Status
- First pass: EN + RU-only pages — done 2026-06-21 (31 blocks across 22 pages; ASCII art replaced in protocol/mcp/llm-wiki)
- RU parity pass: mirror
(+ru)diagrams with localized labels - Render-check each diagram on the built site (catch any Mermaid syntax the platform rejects)
Diagrams (ready-to-paste)
1. docs/en/user/federation.md (+ ru twin) — sequenceDiagram (high)
Where: ### Adding a private peer — the two-step HMAC key exchange (lines 59-87)
Why: The single most error-prone setup on any of these pages: who generates the secret, who pastes it, and which direction. A sequence diagram removes the who-does-what ambiguity that prose cannot.
sequenceDiagram
participant You as Your hub
participant Ch as Trusted channel
participant Bob as Bob's hub
Note over Bob: Admin -> Federation -> Add inbound secret
Bob->>Bob: Generate secret for kid "alice-2026"<br/>pick allowed subgraphs
Bob->>Ch: Send kid + secretHex
Ch->>You: kid + secretHex
Note over You: Admin -> Federation -> Add outbound secret
You->>You: Save kid, secretHex, Bob's kb_url
You->>You: Create KB-note (mcp_federation_kb_url)
Note over You,Bob: Now your agent can federated_search Bob's base
Note over You,Bob: Reverse direction (optional): repeat the other way
2. docs/en/user/federation.md (+ ru twin) — flowchart (high)
Where: ### Federation graph (self-hosted panel) — the 7-status edge table (lines 124-140)
Why: Turns a 7-row status table into a diagnostic decision tree (KB-note? secret? matching inbound? granted subgraph?). Gives self-host operators a mental model for debugging a broken link — highest-value content on the page after the key exchange.
flowchart TD
A{KB-note points<br/>at peer?} -->|No, but outbound secret exists| ORPH[orphan_secret]
A -->|Yes| B{Target is a<br/>pool instance?}
B -->|No| EXT[external]
B -->|Yes| C{Outbound secret?}
C -->|No| NA[no_auth - peer 401s]
C -->|Revoked| REV[revoked]
C -->|Yes| D{Peer has matching<br/>inbound secret for kid?}
D -->|No| OW[one_way - peer 401s]
D -->|Yes| E{Inbound grants<br/>at least 1 subgraph?}
E -->|No| NAC[no_access - 0 results]
E -->|Yes| OK[ok - link works]
3. docs/en/user/two-way-sync.md (+ ru twin) — stateDiagram (high)
Where: Section "Status indicator" — alongside/replacing the colored-dot legend (lines 38-46)
Why: The colored status dot IS a state machine; the legend only lists colors. A stateDiagram shows the actual lifecycle (server-changes/local-changes/both/conflict) and how each resolves back to synced — the strongest state-machine candidate across all groups.
stateDiagram-v2
[*] --> Synced
Synced --> ServerChanges: server edited a file
Synced --> LocalChanges: you edited a file
ServerChanges --> BothChanged: you also edit
LocalChanges --> BothChanged: server also edits
BothChanged --> Conflict: same file, both sides
ServerChanges --> Synced: sync downloads (blue)
LocalChanges --> Synced: sync uploads (green)
BothChanged --> Synced: auto-merge (orange)
Conflict --> Synced: resolve - keep / accept / both (red)
4. docs/en/user/protocol.md (+ ru twin) — flowchart (high)
Where: Section "The pipeline" — replace the ASCII art block (lines 14-22)
Why: Drop-in replacement for existing ASCII art; strictly an upgrade. Makes the 'each stage independent, stop at website' branching visible at a glance, which the linear preformatted block cannot.
flowchart TD
A[Obsidian vault] -->|sync plugin| B[trip2g server<br/>your instance]
B -->|rendering| C[Website<br/>HTML pages, sitemap, RSS]
C -.optional.-> D[Telegram channel]
C -.optional.-> E[MCP server]
C -.optional.-> F[AI assistant]
5. docs/en/user/search.md (+ ru twin) — flowchart (high)
Where: Intro / how the two algorithms combine (lines 7-13, before 'What this means in practice')
Why: Textbook hybrid-search visual: one query fans into BM25+morphology and OpenAI vector simultaneously, merged by RRF into final ranking. Trivial to add and makes the 'two independent algorithms, merged by RRF' sentence tangible.
flowchart LR
Q[Your query] --> T[Text search<br/>BM25 + morphology]
Q --> S[Semantic search<br/>OpenAI vector, nearest in meaning]
T --> R[RRF<br/>Reciprocal Rank Fusion<br/>merge by position]
S --> R
R --> F[Final ranking]
6. docs/en/user/monetization.md (+ ru twin) — flowchart (high)
Where: How access works (top of page, around free vs private notes section)
Why: Unifies three scattered prose sections (How access works / Paywall preview / How subscribers authenticate) into one access-decision tree — the conceptual spine of the whole page.
flowchart TD
Open[Reader opens a note] --> Free{free: true?}
Free -->|Yes| Public[Served to everyone]
Free -->|No| Login{Signed in?}
Login -->|No| Paywall[Show preview + paywall / redirect to sign in]
Login -->|Yes| Sub{Active subscription?}
Sub -->|Patreon / Boosty / crypto / Telegram group| Grant[Show full note]
Sub -->|No active access| Paywall
7. docs/en/user/user_management.md (+ ru twin) — flowchart (high)
Where: Warning: notes without a subgraph are visible to all signed-in users (unassigned-note visibility section)
Why: Visualizes the page's explicit security pitfall: untagged notes leak to every signed-in user, and the frontmatter patch reassigns them to notes_without_subgraph (granted to nobody) to hide them. The security warning that newcomers most need to internalize.
flowchart TD
N[Note] --> Q{Has subgraph / subgraphs?}
Q -->|No, untagged| Leak[Visible to EVERY signed-in user]
Q -->|Yes: assigned subgraph| Gated[Visible only to granted users]
Leak -. apply frontmatter patch .-> Patched[Reassigned to notes_without_subgraph]
Patched --> Hidden[Nobody is granted it -> invisible to regular users]
Hidden --> AdminNote[Admins always see everything]
Gated --> AdminNote
8. docs/ru/user/oauth.md (+ advanced.md OAuth section) — sequenceDiagram (high)
Where: Как это работает — admin pre-adds user, then OAuth email must match
Why: Makes the key invariant visual: OAuth does NOT grant access automatically — the provider email must match a pre-registered user. This rule is easy to miss in prose and causes real lockouts.
sequenceDiagram
participant Admin
participant trip2g as Trip2G
participant Reader
participant Provider as Google / GitHub
Admin->>trip2g: Add user (email + role)
Reader->>Provider: Sign in (one click)
Provider-->>trip2g: Verified email
alt Email matches a registered user
trip2g->>Reader: Access granted
else No matching email
trip2g->>Reader: Access denied
end
9. docs/en/user/webhooks.md + docs/ru/user/change_webhooks.md — sequenceDiagram (high)
Where: Change webhooks intro / payload + 'Applying changes from your service' (RU: ### Как это работает)
Why: The request/response contract is split across three prose sections (payload, signature, applying changes). One sequence diagram shows the full signed round-trip incl. expected_hash verification — the page's core mechanism.
sequenceDiagram
participant Author
participant trip2g
participant Service as Your service
Author->>trip2g: Save / delete a note
Note over trip2g: Note matches a path pattern
trip2g->>Service: POST payload (changes[], instruction)
Note right of trip2g: Signed: X-Webhook-Signature sha256
Service->>Service: Run AI / index / notify
Service-->>trip2g: { status: ok, changes[] }
Note over trip2g: Verify expected_hash
trip2g->>Author: Apply corrected note
10. docs/en/user/forms.md (+ ru twin) — flowchart (high)
Where: Submitting via GraphQL — after the response __typename table
Why: Unifies can_submit permission, Turnstile gating, and field validation into one server-side decision tree ending in the four response payloads. Currently spread across three sub-sections; consolidates exactly what the server returns and why.
flowchart TD
A[submitForm received] --> B{can_submit allows<br/>this viewer?}
B -->|admin only, not admin| R1[FormSubmitDeniedPayload<br/>reason admin_required]
B -->|paid_user| R2[FormSubmitDeniedPayload<br/>reason not_implemented]
B -->|allowed| C{Valid Turnstile<br/>token?}
C -->|No| R3[TurnstileRequiredPayload<br/>siteKey]
C -->|Yes or disabled| D{Fields pass<br/>validation?}
D -->|No| R4[ErrorPayload<br/>byFields]
D -->|Yes| R5[SubmitFormPayload<br/>submitId]
11. docs/en/user/mcp.md (+ ru twin) — sequenceDiagram (high)
Where: ### How it works — replace the ASCII box + numbered steps (lines 11-24)
Why: Drop-in ASCII replacement and strict upgrade. Shows the actual ordered question-to-answer round trip (ask -> vector search -> notes + author instructions -> grounded answer) instead of static topology.
sequenceDiagram
participant Client as AI client
participant MCP as MCP server (trip2g.com)
participant KB as Knowledge base (your notes)
Client->>MCP: Ask a question
MCP->>KB: Vector search
KB-->>MCP: Relevant notes
MCP-->>Client: Note text + author instructions
Note over Client: Composes answer grounded in your knowledge
12. docs/en/user/llm-wiki.md (+ ru twin) — flowchart (high)
Where: ### Two modes of agent retrieval — replace the two ASCII flow blocks (Mode A 54-60, Mode B 68-76)
Why: Replaces two plain-text arrow lists with one branching diagram comparing index-first traversal (Mode A) vs search/RAG-assisted retrieval (Mode B) from a single question. Makes the mode choice tangible.
flowchart TD
Q[Question] --> Mode{Base size<br/>& structure}
Mode -->|Curated / smaller| A1[read index.md]
A1 --> A2[open relevant pages]
A2 --> A3[follow wikilinks]
A3 --> AC[Answer with citations]
Mode -->|Large / less structured| B1[search query]
B1 --> B2[inspect matches & TOC]
B2 --> B3[note_html to load sections]
B3 --> B4[follow wikilinks]
B4 --> B5[verify sources]
B5 --> AC
13. docs/en/user/telegram.md (+ ru twin) — flowchart (high)
Where: Top of page / before 'Set up a bot' — overall setup-to-publish flow
Why: telegram.md is a long linear procedure; a one-glance setup-to-publish map (BotFather -> admin panel -> channel admin -> note frontmatter -> sync -> instant/queued -> live) orients the reader before the step-by-step.
flowchart TD
A[Create bot in BotFather] --> B[Add bot token in admin panel TG bots]
B --> C[Create Telegram channel]
C --> D[Add bot as channel admin<br/>Post messages + Add members]
D --> E[Write note in Obsidian]
E --> F[Add telegram_publish_at + telegram_publish_tags]
F --> G[Sync the note]
G --> H{Tag matches?}
H -->|Instant Tag| I[Publish immediately]
H -->|Scheduled tag| J[Queued until publish_at]
I --> K[Post live in channel]
J --> K
14. docs/en/user/telegram.md (+ ru twin) — flowchart (high)
Where: Section 'Editing published posts' — what updates live vs what needs Reset
Why: Collapses a two-list can/cannot section into one actionable path: text/formatting/links propagate on re-sync; media/post-type/photo-count/rename require Reset -> edit -> sync. A frequent real-world stumbling point.
flowchart TD
E[Want to change a published post] --> Q{What changes?}
Q -->|Text, formatting,<br/>links, lists| A[Edit note in Obsidian -> Sync<br/>Post updates automatically]
Q -->|Photos, videos, post type,<br/>number of album photos| B[Open post in admin -> Reset]
Q -->|Rename the note| B
B --> C[Edit note in Obsidian]
C --> D[Sync again<br/>Re-queued and published]
15. docs/en/user/update_notes.md (+ ru twin) — sequenceDiagram (high)
Where: Checkbox toggle (patch use case) — after the numbered 'How it works' list
Why: Ties the data-line/find/replace mechanics together incl. the PatchNotFound branch on duplicate task text. A reader-driven round trip that prose describes only piecemeal.
sequenceDiagram
participant Reader
participant Frontend
participant Server
Note over Frontend: Note rendered with data-line attrs<br/>(allow_task_toggle: true)
Reader->>Frontend: Click checkbox
Frontend->>Server: updateNotes patch<br/>find=unchecked, replace=checked
alt find appears exactly once
Server-->>Frontend: UpdateNotesSuccessPayload
Frontend->>Reader: Optimistic UI update
else duplicate task text
Server-->>Frontend: UpdateNotesPatchNotFoundPayload
Frontend->>Reader: cannot toggle - duplicate task
end
16. docs/en/user/selfhosted.md (+ ru twin) — flowchart (high)
Where: Section 'What this setup runs' / 'Caddyfile' — service topology (lines 13-21, 222-258)
Why: The Caddy/MinIO/trip2g hostname-to-port mapping is the single most confusing part of the self-host page. A topology diagram clarifies why only Caddy exposes ports and how the two public hostnames map to internal services.
flowchart TD
Net[Internet] -->|443| Caddy[Caddy<br/>ports 80/443]
Caddy -->|docs.example.com| T[trip2g :8081]
Caddy -->|files.example.com| M[MinIO :9000]
T -->|S3 API| M
subgraph compose_network_internal
T
M
end
17. docs/en/user/getting-started.md (+ ru twin) — flowchart (high)
Where: Top of page, after intro paragraph (line 8) — onboarding roadmap before 'How the service works'
Why: Gives newcomers a skimmable map of the entire setup (instance -> sign in -> admin panel -> BRAT plugin -> API key -> connect -> publish -> make public) so they know how many steps remain. High value for the most-read page.
flowchart LR
A[Get an instance] --> B[Sign in by email]
B --> C[Configure admin panel]
C --> D[Install plugin via BRAT]
D --> E[Create API key]
E --> F[Connect plugin to site]
F --> G[Create _index note]
G --> H[Sync]
H --> I[Add free: true]
I --> J[Page is public]
18. docs/ru/user/Импорт из Telegram.md — flowchart (high)
Where: Section 'Как это работает' — naming + dedup + re-import logic
Why: Captures the easy-to-miss branching dedup rules: title from first 7 words (strip emoji/formatting), append message ID on collision, skip if already imported, attach metadata. Prose hides the branching.
flowchart TD
P[Пост из канала] --> S{Уже импортирован?}
S -->|Да| SK[Пропустить]
S -->|Нет| T[Заголовок из первых 7 слов<br/>без эмодзи и форматирования]
T --> C{Заголовок уже занят?}
C -->|Да| ID[Добавить ID сообщения]
C -->|Нет| K[Создать заметку]
ID --> K
K --> M[Метаданные:<br/>channel_id, message_id, publish_at]
M --> ML[Скачать фото и видео]
ML --> WL[Ссылки на посты -> wikilinks]
19. docs/en/user/default-template.md (+ ru twin) — flowchart (high)
Where: Section 'Functional notes: header, footer, and sidebars' — the resolution-order list (lines 28-33)
Why: Turns a 4-step priority list (per-note frontmatter -> glob section -> _header.md/_footer.md auto-load -> absent) into a visible top-to-bottom resolution path. Core mechanic of the template page.
flowchart TD
Start([Resolve a section]) --> A{Per-note frontmatter?<br/>header: [[my-header]]}
A -->|set| UseA[Use that note]
A -->|none| B{Matching glob section?<br/>header_includes: blog/*}
B -->|matches| UseB[Use highest-priority match]
B -->|none| C{Auto-load file exists?<br/>_header.md / _footer.md}
C -->|yes| UseC[Use the auto-load note]
C -->|no| None[Section absent]
20. docs/en/user/templates.md (+ ru twin) — flowchart (high)
Where: Section 'How templates work' (lines 13-41) — the Step 1 / Step 2 flow
Why: Makes the 'markdown stays clean, template decides presentation' idea concrete: note + layout frontmatter feed the Jet engine in _layouts/, which emits the full HTML page. Entry-point concept for the templating docs.
flowchart LR
Note[Markdown note<br/>layout: my-page] --> Engine{Jet template engine}
Layout[_layouts/my-page.html<br/>note.Title, note.HTMLString] --> Engine
Engine --> Page[Complete HTML page]
21. docs/en/user/renderlayout.md (+ ru twin) — sequenceDiagram (medium)
Where: Section 'AI agent workflow' (lines 240-251)
Why: Captures the iterative POST/preview loop: agent posts layout+note, server renders into in-memory ring buffer (nothing written to vault), returns previewURL + warnings; agent fixes Jet errors and re-posts; human opens the link. The page's signature workflow.
sequenceDiagram
participant Agent
participant API as /_system/renderlayout
participant Buffer as Ring buffer (10, in-memory)
participant Human
Agent->>API: POST { layout.src, note.src }
API->>Buffer: store rendered HTML (nothing written to vault)
API-->>Agent: { previewURL, warnings }
alt warnings non-empty
Agent->>Agent: read Jet error, fix template
Agent->>API: POST again
else all warnings empty
Agent-->>Human: share previewURL
Human->>API: GET ?preview_id=xxx
API-->>Human: rendered HTML
end
22. docs/en/user/webhooks.md + docs/ru/user/cron_webhooks.md — flowchart (medium)
Where: Cron webhooks — Synchronous vs asynchronous responses (replace/precede the two JSON blocks)
Why: The 60-second cutoff is the deciding factor between sync (return changes, trip2g applies) and async (202 Accepted, write back later via API token) and is currently buried in prose.
flowchart TD
A[Cron fires: POST to your endpoint] --> B{Task finishes<br/>under 60s?}
B -->|Yes| C[Return status: ok + changes]
C --> D[trip2g applies changes]
B -->|No| E[Return 202 Accepted]
E --> F[Agent keeps working]
F --> G[Write back later via API token]
23. docs/en/user/forms.md (+ ru twin) — sequenceDiagram (medium)
Where: Spam protection -> turnstile (after the 'How it works' bullet list)
Why: The two-pass submit flow is non-obvious from the bullet list: first submit returns TurnstileRequiredPayload{siteKey}, the layout renders the widget and resubmits with the token, then the server accepts.
sequenceDiagram
participant Visitor
participant Page
participant Server
Visitor->>Page: Fill form, click Submit
Page->>Server: submitForm (no token)
Server-->>Page: TurnstileRequiredPayload { siteKey }
Page->>Visitor: Render Turnstile widget
Visitor->>Page: Solve captcha
Page->>Server: submitForm (turnstileToken)
Server-->>Page: SubmitFormPayload { submitId }
Page->>Visitor: Redirect to success_url
24. docs/en/user/protocol.md (+ ru twin) — flowchart (medium)
Where: Section 'Federation: connecting nodes' — replace ASCII art block (lines 150-157)
Why: Drop-in ASCII replacement; edge labels make the per-edge auth method (no auth / HMAC) concrete for federation topology. Pairs with the federation.md hub diagram.
flowchart TD
Agent[Your agent] --> Hub[Your trip2g hub]
Hub -->|no auth| Public[Public base]
Hub -->|HMAC key| Private[Private peer]
Hub -->|HMAC key| Adapter[External adapter<br/>GitHub / Telegram]
25. docs/en/user/search.md (+ ru twin) — flowchart (medium)
Where: ### Excluding notes from search (lines 22-42)
Why: Compresses three separately-described exclusion rules (underscore-prefixed path/filename, search:false direct or via patch glob) into one checklist a reader can follow to predict indexing.
flowchart TD
N[Note] --> U{Filename or any<br/>path folder starts with _ ?}
U -->|Yes| EX[Excluded - system note]
U -->|No| SF{search: false in frontmatter?<br/>direct or via frontmatter patch glob}
SF -->|Yes| EX
SF -->|No| IDX[Indexed - appears in search]
26. docs/en/user/mcp.md (+ ru twin) — flowchart (medium)
Where: ### Named entry points (?method=) (lines 148-183)
Why: Shows how one knowledge base serves multiple agent personas: each ?method= URL selects a different initialize-instructions note, with access control gating premium personas behind a subgraph while tools stay constant.
flowchart LR
A[/_system/mcp] --> D[mcp_method: initialize<br/>default persona]
B[/_system/mcp?method=wiki] --> W[mcp_method: wiki<br/>free: true -> public]
C[/_system/mcp?method=premium_advisor] --> P{Subscriber?}
P -->|Yes| PA[mcp_method: premium_advisor<br/>in-depth advisor]
P -->|No| E[Method not found 401]
D --> T[Same tool set]
W --> T
PA --> T
27. docs/en/user/update_notes.md (+ ru twin) — flowchart (medium)
Where: Conflict detection with expectedHash — after the bullet list describing the check
Why: Makes the read-transform-write retry loop explicit: write with expectedHash, on mismatch get UpdateNotesHashMismatchPayload{actualHash}, re-fetch and retry. The loop is hard to see in prose.
flowchart TD
A[Read note + content hash] --> B[Transform content]
B --> C[updateNotes with expectedHash]
C --> D{Hash still<br/>matches?}
D -->|Yes| E[UpdateNotesSuccessPayload<br/>change applied]
D -->|No| F[UpdateNotesHashMismatchPayload<br/>actualHash]
F --> A
28. docs/ru/user/Публикация через аккаунты.md — flowchart (medium)
Where: Section 'Как работает публикация' — one tag fanning out to channels via bot and/or account
Why: Makes the 'один тег -> несколько каналов' and dual-sender (bot + account on the same channel) behavior concrete — the page's central routing concept.
flowchart LR
N[Заметка с тегом Новости] --> R{Каналы с этим тегом}
R --> C1[Канал A]
R --> C2[Канал B]
C1 --> B1[Бот]
C2 --> B2[Бот]
C2 --> A2[Аккаунт]
B1 --> T1[Пост в канале A]
B2 --> T2[Пост в канале B через бота]
A2 --> T3[Пост в канале B через аккаунт]
29. docs/en/user/default-template.md (+ ru twin) — flowchart (medium)
Where: Section 'Title display' (lines 269-286)
Why: Captures the title-resolution rule incl. the both-set edge case where frontmatter title wins but an in-content H1 still suppresses the template's own title element. A subtle behavior worth a diagram.
flowchart TD
Start([Determine page title]) --> T{title frontmatter set?}
T -->|yes| UseT[Title = frontmatter value<br/>used in title tag, OG, listings]
T -->|no| H{Leading H1 in body?}
H -->|yes| UseH[Title = H1 text<br/>no separate title element rendered]
H -->|no| File[Title = filename]
UseT --> H1check{Leading H1 also present?}
H1check -->|yes| Skip[Template skips its own title element<br/>shows only the in-content H1]
H1check -->|no| Render[Template renders its title element]