Vishesh 'ironeagle' Bangotra
4b0fdfaf85
- 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).
2.3 KiB
MkDocs Configuration Model
Each documentation kind (lib, api, wiki) is built by its own MkDocs site. A
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
docs/mkdocs.{kind}.yml is a repo-owned file, not a build byproduct:
- Absent —
doc-forge build --{kind}materializes a copy from the packaged templates (see below) and then buildssite/{kind}. - Present — the build uses the file verbatim. Edits to the theme, palette,
plugins, markdown extensions, nav, or
site_dirare respected as-is. --refresh— force-regenerates the file from the templates, replacing any local changes.
Because a present file is never rewritten, rerunning a build is a no-op for versioned configs: the working tree stays clean.
🧩 Templates
The built-in defaults live in docforge/templates/:
| File | Role |
|---|---|
mkdocs.common.yml |
Shared theme + markdown extensions |
mkdocs.lib.yml |
mkdocstrings handler for library reference |
mkdocs.api.yml |
Swagger/OpenAPI plugins and API-side features |
mkdocs.wiki.yml |
Wiki look: horizontal navigation.tabs header, blue grey/teal palette, Roboto |
A per-kind config is generated by deep-merging the common template with the
kind fragment, then filling in generation-time values (site_name,
docs_dir, site_dir, nav, API site_description/site_author, and the
theme icon from docforge.nav.yml). Pass --template <path> to replace the
built-in templates entirely.
🏗️ Supported layouts
- Per-kind config — the standard layout; each kind builds to
site/{kind}and is served under/<repo>/{kind}/. - Legacy root config — a repo with a single kind may instead author root
mkdocs.yml(for example mongo-ops, whose wiki usesdocs_dir: docs/wiki). doc-forge never reads or writes rootmkdocs.yml; the docs service maps the kind to the rootsite/dir in this case.
Commit docs/mkdocs.{kind}.yml so served docs are reproducible from source.