docs: illustrate bundled help guides and render Markdown examples

CHANGELOG.md

@@ -13,6 +13,7 @@ Leafdown uses lightweight [Keep a Changelog](https://keepachangelog.com/en/1.1.0
 
 ### Changed
 
+- Rewrite the bundled help guides with numbered window illustrations, task-by-task instructions, menu paths and shortcuts, and Markdown examples pairing source with its rendered result. The guides and illustrations work offline and follow the current appearance.
 - Redesign the help pages, keyboard shortcuts, What's new, and Changelog as one family. Each opens larger, taking most of the window's height and as much width as its text needs, with its title in a header and its text at 15 px. A help page with several sections, and the Changelog, list them beside the text in a wide window to jump between. What's new alternates its highlights' drawings from side to side, starts each change with its first sentence in bold, and folds a release's fixes behind a count you can open. The Changelog lays out every release the same way, with its fixes listed, and the shortcuts sit in cards side by side.
 - Show shortcuts and key hints as raised keycaps across menus, the command palette, the welcome screen, the shortcuts reference, help, and release notes. Keycaps name the platform's keys: Ctrl on Windows and Linux, and modifier symbols on macOS, with full names for screen readers.
 - Write an inserted horizontal rule with the run the document's breaks agree on, including its length and internal spacing. Where the breaks disagree or there are none, use `***`. Typed markers keep their spelling, and a run that would be read as another construct still uses a safe fallback.

CONTRIBUTING.md

@@ -22,6 +22,16 @@ A release's section may name a few highlights, which What's new shows first, eac
 
 If a proposed implementation would change product direction, architecture, or release scope, reach agreement in an issue before substantial implementation. Update the owning documentation as part of the accepted change.
 
+### Bundled Help Authoring
+
+Keep user guides as Markdown under `docs/help/`. Lead with a task, explain the result of each action, and write menu paths in bold with shortcuts in inline code. Use `Mod` for the platform's primary modifier. A command without a default shortcut should not acquire an invented one. Link to another guide with its filename, or to a section on the current page with its GitHub heading fragment.
+
+For a source/result card, use a `text` code fence with exactly `example=commonmark`, `example=gfm`, or `example=leafdown` after the language. Use a longer outer fence when the example contains fences. The `text` language keeps formatters from rewriting extension syntax as standard Markdown. GitHub shows ordinary source; the app adds a syntax-family badge and a read-only rendering using the document editor. Put a description of the result and any menu path or shortcut in surrounding prose. Results are visual illustrations, with inert controls, no document or folder context, and no remote image loading. The source and explanation remain available to assistive technology. Keep examples small; do not rely on an actual local file, interactive control, or network resource for their meaning.
+
+Put line drawings in `docs/help/illustrations/` and embed them as `![Description](illustrations/name.svg)`. Only these bundled SVGs render as images in Help; other image destinations show their alt text without loading. Use the empty-state drawing style and `--art-*`, `--primary`, `--primary-foreground`, `--card`, or `--foreground` colors with light-theme fallbacks. SVGs are trusted repository assets: do not include scripts, external references, or event handlers. Give informative drawings alt text and explain numbered areas in the prose; use empty alt text for purely decorative drawings.
+
+Use an ordinary blockquote beginning with **Tip:** for advice. A list whose items each start with a link to a bundled guide becomes navigation cards in the app and remains a readable list on GitHub. Preview changes in light and dark appearances at narrow and wide sizes.
+
 ### AI-Assisted Contributions
 
 AI assistance is allowed, but the human author remains responsible for understanding, reviewing, verifying, and explaining the contribution and for addressing review feedback. Do not submit generated changes that you cannot evaluate or maintain.

docs/architecture.md

@@ -32,6 +32,8 @@ Application composition lives under `src/components/` in `layout/` and `screens/
 
 The `release-notes` feature owns the changelog bundled into the frontend, the highlight illustrations bundled with it, current-version selection, and persisted launch and seen-version history. It renders notes with the `help` feature's bundled-page Markdown renderer, so both Help surfaces share one link policy, and it does not access document or session state.
 
+The `help` feature bundles guide Markdown and trusted SVG illustrations. Example code fences request the `editor` feature's read-only Markdown preview, created when the example enters view and destroyed when it leaves the page. Each preview has an isolated editor with no document path, folder context, or session bridge; its controls are inert and subsequent content and selection transactions are rejected. The authored source and surrounding explanation provide the accessible equivalent of the visual result. Only illustrations imported from `docs/help/illustrations/` are inserted as SVG; arbitrary Markdown image destinations remain text and cannot trigger a fetch.
+
 The `session` feature owns the window's open documents and their relationship to the folder context, plus workflows spanning multiple features. Dependencies flow left to right:
 
 `application components -> commands -> session -> domain features -> shared UI/lib`