docs(wiki): align wiki structure with Aetoskia AGENTS.md guidelines

- Renamed `02_architecture.md` to `02_components.md` to match the standard component page naming convention.
- Updated `docs/mkdocs.wiki.yml` to reflect renamed pages and fix navigation label acronym casing (GSDFC, MCP, MkDocs).
- Updated `index.md` to include the mandatory doc model blockquote, standardize section headers with emojis, and accurately map the `Documentation Structure` table to the navigation menu.
- Standardized all wiki pages (`01_overview.md`, `02_components.md`, `03_conventions.md`, `04_iterative_workflow.md`, and `05_development/*`) by:
  - Adding horizontal rules (`---`) between major sections.
  - Applying emoji-prefixed H2 headings for recognizable section types.
  - Appending `## Related` or `## ➡️ Read Next` footers with standard relative cross-links.
  - Adjusting H1 headers to match guide anatomy (e.g., `# Library Overview` on the overview page).

docs/wiki/05_development/01_environment.md

@@ -1,6 +1,8 @@
 # Environment Setup
 
-## Create the environment
+---
+
+## 🚀 Create the environment
 
 ```bash
 python -m venv .venv
@@ -10,7 +12,9 @@ pip install -e .
 
 Requires Python 3.10+ (per `pyproject.toml`).
 
-## Dependencies
+---
+
+## 📦 Dependencies
 
 Development extras include:
 
@@ -18,4 +22,9 @@ Development extras include:
 - `ruff` — lint and format checking
 - `black` — auto-formatting
 - `mypy` — strict typing checks
-- `pydoclint` — docstring ↔ signature consistency checks
+- `pydoclint` — docstring ↔ signature consistency checks
+
+---
+
+## Related
+- [04 – Iterative Workflow](../04_iterative_workflow.md) · [02 – Quality Gates](02_quality_gates.md)

docs/wiki/05_development/02_quality_gates.md

@@ -2,6 +2,10 @@
 
 Run all checks before pushing:
 
+---
+
+## 🚀 Commands
+
 ```bash
 .venv\Scripts\python.exe -m pytest
 .venv\Scripts\python.exe -m ruff check docforge tests
@@ -10,7 +14,9 @@ Run all checks before pushing:
 .venv\Scripts\pydoclint.exe docforge
 ```
 
-## Test layout
+---
+
+## 📁 Test layout
 
 | Path                     | Covers                             |
 |--------------------------|------------------------------------|
@@ -20,4 +26,9 @@ Run all checks before pushing:
 
 CLI tests use the `cli_runner` fixture with `mock_mkdocs_build` and
 `mock_mkdocs_load_config` so they exercise the full flow without invoking a
-real MkDocs build.
+real MkDocs build.
+
+---
+
+## Related
+- [01 – Environment](01_environment.md) · [03 – GSDFC Guide](03_gsdfc_guide.md)

docs/wiki/05_development/03_gsdfc_guide.md

@@ -5,7 +5,9 @@ in the `docforge/__init__.py` package docstring. It describes how to write
 docstrings that render correctly in MkDocs and stay machine-parseable by
 doc-forge, MkDocs, and MCP clients.
 
-## Overview
+---
+
+## 🧭 Overview
 
 - Docstrings are the single source of truth.
 - `doc-forge` compiles docstrings but never rewrites them.
@@ -13,7 +15,9 @@ doc-forge, MkDocs, and MCP clients.
 - Type hints live in signatures; prose entries repeat the type in
   parentheses and must match the signature.
 
-## Module docstrings
+---
+
+## 📦 Module docstrings
 
 Modules use Markdown headings and `---` separators.
 
@@ -23,7 +27,9 @@ Recommended sections:
 - `# Examples` — a representative usage snippet
 - `# Notes` — guarantees, lifecycle, and thread-safety notes
 
-## Class docstrings
+---
+
+## 📦 Class docstrings
 
 Recommended sections, in order:
 
@@ -32,7 +38,9 @@ Recommended sections, in order:
 - `Notes:` — grouped subsections such as **Guarantees**, **Lifecycle**
 - `Example:` — indented `python` code block
 
-## Function and method docstrings
+---
+
+## 📦 Function and method docstrings
 
 Recommended section order:
 
@@ -53,12 +61,16 @@ Formatting rules:
 - Fenced `python` blocks are allowed inside `Example:` sections, indented
   four spaces.
 
-## Property docstrings
+---
+
+## 📦 Property docstrings
 
 Properties document their return values with a `Returns:` section and, when
 meaningful, an `Example:`.
 
-## Example
+---
+
+## 🚀 Example
 
 ```python
 def process(foo: Foo, multiplier: int) -> int:
@@ -90,13 +102,17 @@ def process(foo: Foo, multiplier: int) -> int:
     """
 ```
 
-## Keeping stubs in sync
+---
+
+## 🔄 Keeping stubs in sync
 
 Every `.py` module ships a matching `.pyi` stub. When a signature or a public
 symbol changes, update both files. Signature annotations in the stub must
 match the implementation.
 
-## Enforcement
+---
+
+## 🛡️ Enforcement
 
 `pydoclint` (Google style) runs in CI and verifies that `Args:`/`Returns:`
 sections match function signatures, including types.
@@ -105,4 +121,9 @@ sections match function signatures, including types.
 - `skip-checking-raises = true` — `Raises:` sections are descriptive and are
   not required to map to literal `raise` statements.
 - `check-class-attributes = false` — `Attributes:` sections document instance
-  attributes without class-level annotations.
+  attributes without class-level annotations.
+
+---
+
+## Related
+- [02 – Quality Gates](02_quality_gates.md) · [04 – MCP Guide](04_mcp_guide.md)

docs/wiki/05_development/04_mcp_guide.md

@@ -5,7 +5,9 @@ GSDFC docstrings and serve that bundle over the Model Context Protocol (MCP).
 The bundle is self-contained: readers can derive the full API reference —
 signatures, docstrings, and structure — for the documented project.
 
-## Building the bundle
+---
+
+## 🚀 Building the bundle
 
 ```bash
 doc-forge build --mcp --module docforge
@@ -17,7 +19,9 @@ This writes structured JSON into `docs/mcp/`:
 - `nav.json` — module list with `docs://modules/{module}` resource URIs
 - `modules/{dotted.path}.json` — per-module serialized documentation
 
-## Serving the bundle
+---
+
+## 🚀 Serving the bundle
 
 ```bash
 doc-forge serve --mcp --module docforge
@@ -36,7 +40,9 @@ Missing resources are returned as structured error dictionaries rather than
 exceptions. The default transport is `streamable-http`; `stdio` and `sse` are
 supported via `MCPServer.run`.
 
-## Bundle contents
+---
+
+## 📦 Bundle contents
 
 Each module resource contains:
 
@@ -48,4 +54,9 @@ Each module resource contains:
 Because the bundle is generated from docstrings, the quality of the bundle
 equals the quality of the project's GSDFC docstrings. For docforge itself,
 the GSDFC specification is carried in `modules/docforge.json` via the
-`docforge/__init__.py` package docstring, making the bundle self-documenting.
+`docforge/__init__.py` package docstring, making the bundle self-documenting.
+
+---
+
+## Related
+- [03 – GSDFC Guide](03_gsdfc_guide.md) · [05 – MkDocs Configs](05_mkdocs_configs.md)

docs/wiki/05_development/05_mkdocs_configs.md

@@ -5,7 +5,9 @@ repo that documents kind `{kind}` carries a config at `docs/mkdocs.{kind}.yml`
 that sets `docs_dir` to the kind's source directory and `site_dir` to
 `../site/{kind}`.
 
-## File wins
+---
+
+## 📄 File wins
 
 `docs/mkdocs.{kind}.yml` is a repo-owned file, not a build byproduct:
 
@@ -19,7 +21,9 @@ that sets `docs_dir` to the kind's source directory and `site_dir` to
 Because a present file is never rewritten, rerunning a build is a no-op for
 versioned configs: the working tree stays clean.
 
-## Templates
+---
+
+## 🧩 Templates
 
 The built-in defaults live in `docforge/templates/`:
 
@@ -36,7 +40,9 @@ kind fragment, then filling in generation-time values (`site_name`,
 theme `icon` from `docforge.nav.yml`). Pass `--template <path>` to replace the
 built-in templates entirely.
 
-## Supported layouts
+---
+
+## 🏗️ Supported layouts
 
 - **Per-kind config** — the standard layout; each kind builds to
   `site/{kind}` and is served under `/<repo>/{kind}/`.
@@ -45,4 +51,9 @@ built-in templates entirely.
   doc-forge never reads or writes root `mkdocs.yml`; the docs service maps the
   kind to the root `site/` dir in this case.
 
-Commit `docs/mkdocs.{kind}.yml` so served docs are reproducible from source.
+Commit `docs/mkdocs.{kind}.yml` so served docs are reproducible from source.
+
+---
+
+## Related
+- [04 – MCP Guide](04_mcp_guide.md)