From 37f2fbf4b94470622de06e9e00b03ec622e48819 Mon Sep 17 00:00:00 2001
From: Vishesh 'ironeagle' Bangotra
doc-forge repositorydocs/wiki/doc-forge build --mcp --module docforge into docs/mcp/docs/wiki/ or use the prompt mentioned below
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + 37 + 38 + 39 + 40 + 41 + 42 + 43 + 44 + 45 + 46 + 47 + 48 + 49 + 50 + 51 + 52 + 53 + 54 + 55 + 56 + 57 + 58 + 59 + 60 + 61 + 62 + 63 + 64 + 65 + 66 + 67 + 68 + 69 + 70 + 71 + 72 + 73 + 74 + 75 + 76 + 77 + 78 + 79 + 80 + 81 + 82 + 83 + 84 + 85 + 86 + 87 + 88 + 89 + 90 + 91 + 92 + 93 + 94 + 95 + 96 + 97 + 98 + 99 +100 +101 +102 +103 +104 +105 +106 +107 +108 +109 +110 +111 +112 +113 +114 +115 +116 +117 +118 +119 +120 +121 +122 +123 +124 +125 +126 +127 +128 +129 +130 +131 +132 +133 +134 +135 +136 +137 +138 +139 +140 +141 +142 +143 +144 +145 +146 +147 +148 +149 +150 +151 +152 +153 +154 +155 +156 +157 +158 +159 +160 +161 +162 +163 +164 +165 +166 +167 +168 +169 +170 +171 +172 +173 +174 +175 +176 +177 +178 +179 +180 +181 +182 +183 +184 +185 +186 +187 +188 +189 +190 +191 +192 +193 +194 +195 +196 +197 +198 +199 +200 +201 +202 +203 +204 +205 +206 +207 +208 +209 +210 +211 +212 +213 +214 +215 +216 +217 +218 +219 +220 +221 +222 +223 +224 +225 +226 +227 +228 +229 +230 +231 +232 +233 +234 +235 +236 +237 +238 +239 +240 +241 +242 +243 +244 +245 +246 +247 +248 +249 +250 +251 +252 +253 +254 +255 +256 +257 +258 +259 +260 +261 | |
Β© Aetoskia Internal
diff --git a/doc-forge/wiki/search/search_index.json b/doc-forge/wiki/search/search_index.json index 0db9f36..eb45cf6 100644 --- a/doc-forge/wiki/search/search_index.json +++ b/doc-forge/wiki/search/search_index.json @@ -1 +1 @@ -{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"\ud83d\udd28 docforge \u2014 Docstring-Driven Documentation Forge","text":"docforge is an internal documentation tool that generates reference documentation from Google-Styled Doc-Forge Convention (GSDFC) docstrings and assembles it into per-kind MkDocs sites, alongside hand-written wiki pages and OpenAPI-based API docs.
site/{kind}.pyi stubs, and template conventions Iterative Workflow How a docs build runs end to end Development Environment setup and quality gates Docstring Guide How to write GSDFC-conformant docstrings MCP Guide Building, serving, and consuming the MCP bundle"},{"location":"#related-resources","title":"\ud83d\udd17 Related Resources","text":"doc-forge repositorydocs/wiki/doc-forge build --mcp --module docforge into docs/mcp/\u00a9 Aetoskia Internal
"},{"location":"01_overview/","title":"Overview","text":"docforge turns GSDFC-compliant Python docstrings into maintainable reference documentation. It never edits source docstrings; it reads them, renders them, and assembles documentation sites from all available material.
lib GSDFC docstrings docs/lib/** rendered markdown api OpenAPI JSON spec docs/api/** rendered markdown wiki Hand-written markdown docs/wiki/** (unchanged) mcp GSDFC docstrings + renderers docs/mcp/** structured JSON"},{"location":"01_overview/#per-kind-mkdocs-builds","title":"Per-kind MkDocs builds","text":"Each enabled site kind produces its own MkDocs configuration and build:
--mkdocs (lib) writes docs/mkdocs.lib.yml and builds site/lib/.--api writes docs/mkdocs.api.yml and builds site/api/.--wiki writes docs/mkdocs.wiki.yml and builds site/wiki/.Every site is self-contained (own theme assets and search index) with navigation derived or scoped to that kind. Hand-written wiki content is never overwritten or regenerated \u2014 only its navigation is derived automatically.
"},{"location":"01_overview/#mcp-bundle","title":"MCP bundle","text":"docs/mcp/** is a self-contained, machine-readable reference generated from docforge's own GSDFC docstrings. doc-forge serve --mcp --module docforge serves it over MCP. See the MCP Guide.
docforge is split into four horizontal layers. Everything flows top to bottom through the CLI.
The docforge/loaders package wraps griffe to extract modules, functions, classes, and Google-style docstring sections. Loaded data is normalized into the object model under docforge/models (Project, Module, DocObject).
docforge/nav parses docforge.nav.yml specs (NavSpec, Resolver, and the MkDocs nav emitter) and, since the wiki kind, derives wiki navigation from the file structure via build_wiki_nav.
docforge/renderers turn model data into artifacts:
MkDocsRenderer \u2192 docs/lib/** reference markdownMCPRenderer \u2192 docs/mcp/** structured documentationdocforge/servers serves generated artifacts over live protocols:
MCPServer \u2192 serves a pre-generated docs/mcp/** bundle through MCP resources (docs://index, docs://nav, docs://modules/{module})docforge/cli wires it all together:
commands.py \u2014 the build command and its --mkdocs / --api / --wiki / --mcp modesmkdocs_utils.py \u2014 per-kind config generation (docs/mkdocs.{lib,api,wiki}.yml) with navigation re-rooted to each kind's docs_dirapi_utils.py \u2014 OpenAPI loading and API docs generationAll documented source uses the Google-Styled Doc-Forge Convention (GSDFC): Args:, Returns:, Raises:, and Attributes: sections with properly typed signatures.
The authoritative GSDFC specification lives in the docforge/__init__.py package docstring, which is exported verbatim into docs/mcp/modules/docforge.json, so the MCP bundle is self-documenting.
Key rules:
name (Type):) that match the signature types.# Summary, # Examples, and # Notes sections at module level.Args:, Returns:, Raises:, Yields:, Notes:, and Example: sections at function and method level..pyi stub alongside the .py implementation..pyi stubs","text":"Every module ships a matching .pyi stub kept in sync with the .py implementation. When signatures change, update both files.
docs/wiki/** and is never generated.01_overview.md, 02_architecture.md.05_development/01_environment.md \u2192 group Development.index.md is the site Home at the root, and a section root inside a directory.MkDocs config fragments live in docforge/templates. The mkdocs.wiki.yml fragment carries only the search plugin, since wiki pages contain no mkdocstrings directives.
A docs build runs through the CLI in a single pass.
"},{"location":"04_iterative_workflow/#build-commands","title":"Build commands","text":"# Library reference only\ndoc-forge build --mkdocs --module docforge\n\n# Wiki + library (each an independent MkDocs build)\ndoc-forge build --wiki --mkdocs --module docforge\n\n# Wiki only \u2014 no module required\ndoc-forge build --wiki --site-name docforge\n\n# MCP structured bundle\ndoc-forge build --mcp --module docforge\n"},{"location":"04_iterative_workflow/#what-a-build-does","title":"What a build does","text":"--mkdocs, --api, --wiki, --mcp).docs/lib/** with MkDocsRenderer.docs/api/** when --api is given.docs/wiki/**.docs/mkdocs.{lib,api,wiki}.yml), re-rooting navigation paths to each kind's docs_dir.mkdocs build once per config, emitting self-contained sites site/lib/, site/api/, and site/wiki/.doc-forge build --wiki --mkdocs --module docforge\ndoc-forge serve --wiki # serves site preview from docs/mkdocs.wiki.yml\ndoc-forge serve --lib\ndoc-forge serve --api\n# or target any config directly:\ndoc-forge serve --mkdocs --mkdocs-yml docs/mkdocs.wiki.yml\n"},{"location":"04_iterative_workflow/#serve-the-mcp-bundle","title":"Serve the MCP bundle","text":"doc-forge build --mcp --module docforge\ndoc-forge serve --mcp --module docforge\n"},{"location":"05_development/01_environment/","title":"Environment Setup","text":""},{"location":"05_development/01_environment/#create-the-environment","title":"Create the environment","text":"python -m venv .venv\n.venv\\Scripts\\activate\npip install -e .\n Requires Python 3.10+ (per pyproject.toml).
Development extras include:
pytest, pytest-cov \u2014 test suite and coverageruff \u2014 lint and format checkingblack \u2014 auto-formattingmypy \u2014 strict typing checkspydoclint \u2014 docstring \u2194 signature consistency checksRun all checks before pushing:
.venv\\Scripts\\python.exe -m pytest\n.venv\\Scripts\\python.exe -m ruff check docforge tests\n.venv\\Scripts\\python.exe -m black --check docforge tests\n.venv\\Scripts\\python.exe -m mypy docforge\n.venv\\Scripts\\pydoclint.exe docforge\n"},{"location":"05_development/02_quality_gates/#test-layout","title":"Test layout","text":"Path Covers tests/nav/ Nav spec, resolver, wiki nav tests/cli/ Build command flows and modes tests/renderers/ MkDocs / MCP rendering 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.
This page is the practical companion to the authoritative GSDFC specification 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.
doc-forge compiles docstrings but never rewrites them.Modules use Markdown headings and --- separators.
Recommended sections:
# Summary \u2014 what the subsystem does# Examples \u2014 a representative usage snippet# Notes \u2014 guarantees, lifecycle, and thread-safety notesRecommended sections, in order:
Attributes: \u2014 instance attributes with name (Type): entriesNotes: \u2014 grouped subsections such as Guarantees, LifecycleExample: \u2014 indented python code blockRecommended section order:
Args:Returns:Raises:Yields:Notes:Example:Formatting rules:
Args: entries are name (Type): followed by an indented description.Returns: entries are Type: followed by an indented description.Raises: entries are ExceptionType: followed by an indented condition.Yields: replaces Returns: for generators.python blocks are allowed inside Example: sections, indented four spaces.Properties document their return values with a Returns: section and, when meaningful, an Example:.
def process(foo: Foo, multiplier: int) -> int:\n \"\"\"Process a Foo instance.\n\n Args:\n foo (Foo):\n Foo instance to process.\n\n multiplier (int):\n Value used to scale foo.\n\n Returns:\n int:\n Processed result.\n\n Raises:\n ValueError:\n If multiplier is negative.\n\n Example:\n Process foo:\n\n ```python\n foo = Foo(\"example\", value=10)\n result = process(foo, multiplier=2)\n print(result)\n ```\n \"\"\"\n"},{"location":"05_development/03_gsdfc_guide/#keeping-stubs-in-sync","title":"Keeping stubs in sync","text":"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.
pydoclint (Google style) runs in CI and verifies that Args:/Returns: sections match function signatures, including types.
allow-init-docstring = true \u2014 __init__ docstrings are allowed.skip-checking-raises = true \u2014 Raises: sections are descriptive and are not required to map to literal raise statements.check-class-attributes = false \u2014 Attributes: sections document instance attributes without class-level annotations.Doc-forge can export a machine-readable MCP bundle from a project's GSDFC docstrings and serve that bundle over the Model Context Protocol (MCP). The bundle is self-contained: readers can derive the full API reference \u2014 signatures, docstrings, and structure \u2014 for the documented project.
"},{"location":"05_development/04_mcp_guide/#building-the-bundle","title":"Building the bundle","text":"doc-forge build --mcp --module docforge\n This writes structured JSON into docs/mcp/:
index.json \u2014 project metadata and module countnav.json \u2014 module list with docs://modules/{module} resource URIsmodules/{dotted.path}.json \u2014 per-module serialized documentationdoc-forge serve --mcp --module docforge\n The MCPServer (in docforge/servers/mcp_server.py) exposes:
docs://index Project metadata docs://nav Navigation structure docs://modules/{module} Individual module documentation The server also registers a single diagnostic tool, ping, and is read-only. 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.
Each module resource contains:
path \u2014 dotted module pathdocstring \u2014 the raw GSDFC module docstringobjects \u2014 a recursive mapping of public symbols with name, kind, path, signature, and docstring, plus nested membersBecause 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.
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}.
docs/mkdocs.{kind}.yml is a repo-owned file, not a build byproduct:
doc-forge build --{kind} materializes a copy from the packaged templates (see below) and then builds site/{kind}.site_dir are respected as-is.--refresh \u2014 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.
"},{"location":"05_development/05_mkdocs_configs/#templates","title":"Templates","text":"The built-in defaults live in docforge/templates/:
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.
site/{kind} and is served under /<repo>/{kind}/.mkdocs.yml (for example mongo-ops, whose wiki uses docs_dir: docs/wiki). 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.
docforge is an internal documentation tool that generates reference documentation from Google-Styled Doc-Forge Convention (GSDFC) docstrings and assembles it into per-kind MkDocs sites, alongside hand-written wiki pages and OpenAPI-based API docs.
site/{kind}.pyi stubs, and template conventions Iterative Workflow How a docs build runs end to end Development Environment setup and quality gates Docstring Guide How to write GSDFC-conformant docstrings MCP Guide Building, serving, and consuming the MCP bundle"},{"location":"#related-resources","title":"\ud83d\udd17 Related Resources","text":"doc-forge repositorydoc-forge build --mcp --module docforge into docs/mcp/docs/wiki/ or use the prompt mentioned below # AGENTS.md \u2014 Wiki Authoring Guide (Aetoskia)\n\nThis file instructs AI agents how to create, extend, and maintain the wiki\n(`docs/wiki/**`) for any Aetoskia repository. The reference implementation is\n`mongo-ops` \u2014 its wiki went through several revisions to reach the structure\nbelow and should be treated as the canonical example.\n\n---\n\n## 1. Doc model \u2014 know the two sources of truth\n\nEvery repo keeps two distinct kinds of documentation that must **not** bleed\ninto each other:\n\n| Kind | Source | Where | Audience |\n|-------------------|-----------------------|------------------------------------------|------------------------------------|\n| **Wiki** | Hand-written markdown | `docs/wiki/**` | Humans (how-to, examples, testing) |\n| **API reference** | Docstrings (GSDFC) | Generated \u2192 `docs/lib/**`, `docs/mcp/**` | Consumers (exact contracts) |\n\nRules:\n\n- The wiki is written **for humans** \u2014 how-to guides, recipes, and testing\n patterns. It is never generated.\n- API contracts (signatures, parameter types, exact behavior) live in the\n docstrings and the machine-readable bundle under `docs/mcp/`. **Never**\n duplicate full API documentation in the wiki \u2014 link to the lib site instead.\n- If a page starts to drift into contract territory, cut it down to usage and\n point at `docs/lib/`.\n- This doc model is stated on every index page as a blockquote; keep it there:\n > **Doc model:** this wiki is written for humans \u2014 how\u2011to guides, examples,\n > and testing recipes. The authoritative API contracts live in the code\n > (docstrings) and the machine\u2011readable bundle under `docs/mcp/`.\n\n---\n\n## 2. Directory layout & file naming\n\n```\ndocs/wiki/\n\u251c\u2500\u2500 index.md # site Home\n\u251c\u2500\u2500 01_overview.md\n\u251c\u2500\u2500 02_components.md\n\u251c\u2500\u2500 03_use_cases/ # nested directory \u2192 nav group\n\u2502 \u251c\u2500\u2500 01_basic_crud.md\n\u2502 \u251c\u2500\u2500 02_custom_repo.md\n\u2502 \u2514\u2500\u2500 ...\n\u251c\u2500\u2500 04_best_practices.md\n\u251c\u2500\u2500 06_error_handling.md\n\u2514\u2500\u2500 07_testing_example.md\n```\n\n- Location: `docs/wiki/` (hand-written only).\n- File names: `NN_snake_case_name.md` with a **zero-padded two-digit** numeric\n prefix. e.g. `01_overview.md`, `03_use_cases/07_caching.md`.\n- Top-level pages use `NN_name.md` directly. High-volume sections get their own\n directory, e.g. `03_use_cases/NN_name.md` (nav group \"Use Cases\").\n- **No frontmatter.** Every file opens directly with an H1 `# Title`.\n- Navigation labels are short human titles set explicitly in\n `docs/mkdocs.wiki.yml` (title case) \u2014 often **shorter** than the page H1.\n Example: nav label `Basic CRUD` vs page H1 `Use Case 1: Basic FastAPI CRUD API`.\n Never use the raw filename slug as the label.\n- Renumbering: prefixes order pages. When inserting a page, pick the next\n number in the relevant group (subgroup numbers stay grouped).\n\n---\n\n## 3. Navigation \u2014 `docs/mkdocs.wiki.yml` is the source of truth\n\nEvery wiki page **must** be wired into the nav defined in\n`docs/mkdocs.wiki.yml`. If a page is not in the nav, it is orphaned.\n\n- The `nav:` block mirrors the directory tree; directories become nested\n groups.\n- When a section has many pages, group them **by theme** into nested\n subgroups. mongo-ops groups its use cases into:\n `Getting Started`, `Data & Queries`, `Caching`, `Population`,\n `Advanced Usage`.\n- Keep `index.md`'s **Documentation Structure** table in sync with the nav \u2014\n it is the human-facing version of the same TOC. Every nav entry needs a row\n (or nested bullet group) there.\n- Nav label = human title (title case), not the filename slug.\n\n---\n\n## 4. Page anatomy\n\n### 4.1 `index.md` (Home)\n\n```\n# \ud83e\udde9 <package> \u2014 <slogan>\n<one-paragraph pitch>\n\n> **Doc model:** \u2026 (see \u00a71)\n\n---\n\n## \ud83d\ude80 Key Features (bullet list, emoji per feature)\n## \ud83d\udce6 Installation (code blocks: internal PyPI, extras, local source)\n## \ud83d\udcc1 Documentation Structure (table = TOC, mirrors nav exactly)\n## \ud83d\udd17 Related Resources (bullets: source repo, internal PyPI, CI)\n---\n\u00a9 Aetoskia Internal \u2014 `<package>` <version>\n```\n\n### 4.2 Overview page (`01_*`)\n\n- Opens with `# Library Overview`, one sentence about what the library does,\n then a line stating the page builds the mental model.\n- Sections: `## \ud83c\udfd7\ufe0f Architecture` (ASCII diagram + numbered layer list),\n `## \ud83d\udd04 Lifecycle Rules` (table: step / call / why),\n `## \ud83e\udded Which \u2026 Should You Use?` (decision table).\n- Ends with `## \u27a1\ufe0f Read Next` (cross-links to the next pages to read).\n\n### 4.3 Components page (`02_*`)\n\n- Validated reference for the public API surface \u2014 describes what each\n component is for and how the pieces wire together. Keep it usage-level;\n exact signatures belong in `docs/lib/`.\n- Anatomy: numbered sections, one per component (`## 1. MongoConnectionManager`,\n `## 2. BaseDocument`, \u2026), with `### 8.1`-style sub-numbering for related\n types under a component (e.g. the cache layer's backend / stats / config /\n in-memory / redis implementations). Ends with `## Related`.\n\n### 4.4 Use-case page (the most common)\n\nStandard anatomy, in this order:\n\n```\n# Use Case N: <Human Title>\n\n**Scenario:** <one sentence: the problem this recipe solves>\n\n---\n\n## \ud83d\udce6 What's New? (table: Component | Description \u2014 new API used here)\n## \ud83d\ude80 Example (languaged code block, complete runnable-looking snippet)\n## \ud83d\udca1 Tips (bullets: gotchas, ordering, common mistakes)\n## Related (\u00a75)\n```\n\n### 4.5 Deep-dive / worked-example page\n\nFor intricate flows (population shapes, cache round-trips), use numbered\ndepth-first sections and comparison tables:\n\n```\n## 1. <Write path> (### 1a., ### 1b., \u2026 per sub-case)\n## 2. <Read path>\n## 3. <Round trip / tricky bit>\n## 4. When to use which (comparison table)\n## Related\n```\n\n### 4.6 Best Practices page (`04_*`)\n\n- Flat themed `##` sections (e.g. Layering, Lifecycle, Data & Performance,\n Transactions & Errors, Testing), each a short list of numbered conventions.\n- Pure prose \u2014 no large code blocks.\n\n### 4.7 Error Handling (`06_*`) / Testing pages\n\n- **Error Handling:** an exceptions table (`Exception | Source | Meaning / fix`),\n a `> ` note on which failures are by design, a `## \ud83d\ude80 FastAPI Mapping Example`\n code block, then `## \ud83d\udca1 Tips` bullets, then `## Related`.\n- **Testing example (`07_*`):** `## \ud83d\ude80 Mock-Based Quickstart` (focused code\n block), `## \ud83d\udca1 Notes` tip list, `## Related`.\n\nCommon to all pages: no frontmatter, `---` between every major section, and a\n`## Related` (or variant) footer as the **last** section.\n\n---\n\n## 5. The `## Related` footer\n\nEvery page ends with a cross-link footer. Rules:\n\n- Always the **last** section, always preceded by a `---`.\n- Standard heading: `## Related` (no emoji).\n- One bullet line; links separated by ` \u00b7 ` (middle dot plus spaces).\n- Link label format: `[NN \u2013 Title](relative_path)` \u2014 en-dash, page number, title.\n- Paths are **relative**: same directory \u2192 `02_custom_repo.md`; parent \u2192\n `../01_overview.md`; child \u2192 `03_use_cases/01_basic_crud.md`.\n- Link order follows nav order (each `Related` points to related next/sibling\n pages, plus the overview/components anchor).\n\nExamples (from mongo-ops):\n\n```\n## Related\n- [02 \u2013 Custom repository](02_custom_repo.md) \u00b7 [04 \u2013 Pagination](04_pagination.md) \u00b7 [Overview](../01_overview.md)\n```\n\nVariants:\n\n- `## \u27a1\ufe0f Read Next` \u2014 used on the overview page (linear reading order).\n- `## \ud83d\udd17 Related Resources` \u2014 only on `index.md`, one bullet per external resource.\n\n---\n\n## 6. Tone & formatting rules\n\n- **Written for humans**: short sentences, concrete examples, plain words.\n- Emoji-prefixed H2 headings for recognizable section types\n (`\ud83d\udce6 What's New?`, `\ud83d\ude80 Example`, `\ud83d\udca1 Tips`, `\ud83d\ude80 Key Features`).\n- `---` horizontal rule between every major section.\n- Code blocks always declare a language (```python, ```bash, etc.).\n- Use tables for comparisons and structured decisions; bullets for lists;\n ASCII diagrams for architecture.\n- Bold key terms inline. Use `inline code` for symbols/APIs.\n- Keep pages focused: one recipe/purpose per page. If a page balloons past\n ~10 KB, split it (add a numbered deep-dive page instead).\n- Match tone of existing pages in the repo before writing new ones.\n\n---\n\n## 7. Build & verify workflow\n\nAfter creating or editing wiki pages:\n\n```bash\n# 1. Build the wiki (from the repo root)\ndoc-forge build --wiki # wiki only\ndoc-forge build --wiki --mkdocs --module <pkg> # wiki + lib together\n\n# 2. Preview locally\ndoc-forge serve --wiki\n\n# 3. Collect into the hub (run from the docs/ service repo)\npython collect.py # copies site, regenerates index + nginx.conf\npython collect.py --dry-run # preview without writing\n```\n\nVerification checklist:\n\n- `doc-forge build --wiki` completes with no warnings about missing files.\n- Every new page is present in `docs/mkdocs.wiki.yml` **and** in the index\n Documentation Structure table.\n- Every page ends with a `## Related` block and no dead links (paths resolve).\n- After `collect.py`: the hub card links to both `/wiki/` and `/lib/` and the\n pages render (spot-check with the served site).\n- If code/docstrings changed (no change when wiki-only), run the repo gates:\n `black`, `ruff`, `mypy`, `pytest`.\n\n---\n\n## 8. Before/after checklist\n\n**Before creating a page:**\n\n- [ ] Confirm it is genuinely wiki material (how-to) and not API contract.\n- [ ] Find the right filename (`NN_snake_case.md`) and directory for its theme.\n- [ ] Outline the sections per \u00a74 anatomy that fits the content.\n\n**After creating/editing a page:**\n\n- [ ] Page wired into `docs/mkdocs.wiki.yml` nav (themed subgroup if needed).\n- [ ] `index.md` Documentation Structure table updated.\n- [ ] `## Related` footer present, relative links, nav order.\n- [ ] `---` separators consistent; no frontmatter; emoji headings where apt.\n- [ ] Build passes; collect run; hub shows `/wiki/` + `/lib/` links.\n- [ ] No orphaned files, no dead links.\n\u00a9 Aetoskia Internal
"},{"location":"01_overview/","title":"Overview","text":"docforge turns GSDFC-compliant Python docstrings into maintainable reference documentation. It never edits source docstrings; it reads them, renders them, and assembles documentation sites from all available material.
lib GSDFC docstrings docs/lib/** rendered markdown api OpenAPI JSON spec docs/api/** rendered markdown wiki Hand-written markdown docs/wiki/** (unchanged) mcp GSDFC docstrings + renderers docs/mcp/** structured JSON"},{"location":"01_overview/#per-kind-mkdocs-builds","title":"Per-kind MkDocs builds","text":"Each enabled site kind produces its own MkDocs configuration and build:
--mkdocs (lib) writes docs/mkdocs.lib.yml and builds site/lib/.--api writes docs/mkdocs.api.yml and builds site/api/.--wiki writes docs/mkdocs.wiki.yml and builds site/wiki/.Every site is self-contained (own theme assets and search index) with navigation derived or scoped to that kind. Hand-written wiki content is never overwritten or regenerated \u2014 only its navigation is derived automatically.
"},{"location":"01_overview/#mcp-bundle","title":"MCP bundle","text":"docs/mcp/** is a self-contained, machine-readable reference generated from docforge's own GSDFC docstrings. doc-forge serve --mcp --module docforge serves it over MCP. See the MCP Guide.
docforge is split into four horizontal layers. Everything flows top to bottom through the CLI.
The docforge/loaders package wraps griffe to extract modules, functions, classes, and Google-style docstring sections. Loaded data is normalized into the object model under docforge/models (Project, Module, DocObject).
docforge/nav parses docforge.nav.yml specs (NavSpec, Resolver, and the MkDocs nav emitter) and, since the wiki kind, derives wiki navigation from the file structure via build_wiki_nav.
docforge/renderers turn model data into artifacts:
MkDocsRenderer \u2192 docs/lib/** reference markdownMCPRenderer \u2192 docs/mcp/** structured documentationdocforge/servers serves generated artifacts over live protocols:
MCPServer \u2192 serves a pre-generated docs/mcp/** bundle through MCP resources (docs://index, docs://nav, docs://modules/{module})docforge/cli wires it all together:
commands.py \u2014 the build command and its --mkdocs / --api / --wiki / --mcp modesmkdocs_utils.py \u2014 per-kind config generation (docs/mkdocs.{lib,api,wiki}.yml) with navigation re-rooted to each kind's docs_dirapi_utils.py \u2014 OpenAPI loading and API docs generationAll documented source uses the Google-Styled Doc-Forge Convention (GSDFC): Args:, Returns:, Raises:, and Attributes: sections with properly typed signatures.
The authoritative GSDFC specification lives in the docforge/__init__.py package docstring, which is exported verbatim into docs/mcp/modules/docforge.json, so the MCP bundle is self-documenting.
Key rules:
name (Type):) that match the signature types.# Summary, # Examples, and # Notes sections at module level.Args:, Returns:, Raises:, Yields:, Notes:, and Example: sections at function and method level..pyi stub alongside the .py implementation..pyi stubs","text":"Every module ships a matching .pyi stub kept in sync with the .py implementation. When signatures change, update both files.
docs/wiki/** and is never generated.01_overview.md, 02_architecture.md.05_development/01_environment.md \u2192 group Development.index.md is the site Home at the root, and a section root inside a directory.MkDocs config fragments live in docforge/templates. The mkdocs.wiki.yml fragment carries only the search plugin, since wiki pages contain no mkdocstrings directives.
A docs build runs through the CLI in a single pass.
"},{"location":"04_iterative_workflow/#build-commands","title":"Build commands","text":"# Library reference only\ndoc-forge build --mkdocs --module docforge\n\n# Wiki + library (each an independent MkDocs build)\ndoc-forge build --wiki --mkdocs --module docforge\n\n# Wiki only \u2014 no module required\ndoc-forge build --wiki --site-name docforge\n\n# MCP structured bundle\ndoc-forge build --mcp --module docforge\n"},{"location":"04_iterative_workflow/#what-a-build-does","title":"What a build does","text":"--mkdocs, --api, --wiki, --mcp).docs/lib/** with MkDocsRenderer.docs/api/** when --api is given.docs/wiki/**.docs/mkdocs.{lib,api,wiki}.yml), re-rooting navigation paths to each kind's docs_dir.mkdocs build once per config, emitting self-contained sites site/lib/, site/api/, and site/wiki/.doc-forge build --wiki --mkdocs --module docforge\ndoc-forge serve --wiki # serves site preview from docs/mkdocs.wiki.yml\ndoc-forge serve --lib\ndoc-forge serve --api\n# or target any config directly:\ndoc-forge serve --mkdocs --mkdocs-yml docs/mkdocs.wiki.yml\n"},{"location":"04_iterative_workflow/#serve-the-mcp-bundle","title":"Serve the MCP bundle","text":"doc-forge build --mcp --module docforge\ndoc-forge serve --mcp --module docforge\n"},{"location":"05_development/01_environment/","title":"Environment Setup","text":""},{"location":"05_development/01_environment/#create-the-environment","title":"Create the environment","text":"python -m venv .venv\n.venv\\Scripts\\activate\npip install -e .\n Requires Python 3.10+ (per pyproject.toml).
Development extras include:
pytest, pytest-cov \u2014 test suite and coverageruff \u2014 lint and format checkingblack \u2014 auto-formattingmypy \u2014 strict typing checkspydoclint \u2014 docstring \u2194 signature consistency checksRun all checks before pushing:
.venv\\Scripts\\python.exe -m pytest\n.venv\\Scripts\\python.exe -m ruff check docforge tests\n.venv\\Scripts\\python.exe -m black --check docforge tests\n.venv\\Scripts\\python.exe -m mypy docforge\n.venv\\Scripts\\pydoclint.exe docforge\n"},{"location":"05_development/02_quality_gates/#test-layout","title":"Test layout","text":"Path Covers tests/nav/ Nav spec, resolver, wiki nav tests/cli/ Build command flows and modes tests/renderers/ MkDocs / MCP rendering 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.
This page is the practical companion to the authoritative GSDFC specification 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.
doc-forge compiles docstrings but never rewrites them.Modules use Markdown headings and --- separators.
Recommended sections:
# Summary \u2014 what the subsystem does# Examples \u2014 a representative usage snippet# Notes \u2014 guarantees, lifecycle, and thread-safety notesRecommended sections, in order:
Attributes: \u2014 instance attributes with name (Type): entriesNotes: \u2014 grouped subsections such as Guarantees, LifecycleExample: \u2014 indented python code blockRecommended section order:
Args:Returns:Raises:Yields:Notes:Example:Formatting rules:
Args: entries are name (Type): followed by an indented description.Returns: entries are Type: followed by an indented description.Raises: entries are ExceptionType: followed by an indented condition.Yields: replaces Returns: for generators.python blocks are allowed inside Example: sections, indented four spaces.Properties document their return values with a Returns: section and, when meaningful, an Example:.
def process(foo: Foo, multiplier: int) -> int:\n \"\"\"Process a Foo instance.\n\n Args:\n foo (Foo):\n Foo instance to process.\n\n multiplier (int):\n Value used to scale foo.\n\n Returns:\n int:\n Processed result.\n\n Raises:\n ValueError:\n If multiplier is negative.\n\n Example:\n Process foo:\n\n ```python\n foo = Foo(\"example\", value=10)\n result = process(foo, multiplier=2)\n print(result)\n ```\n \"\"\"\n"},{"location":"05_development/03_gsdfc_guide/#keeping-stubs-in-sync","title":"Keeping stubs in sync","text":"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.
pydoclint (Google style) runs in CI and verifies that Args:/Returns: sections match function signatures, including types.
allow-init-docstring = true \u2014 __init__ docstrings are allowed.skip-checking-raises = true \u2014 Raises: sections are descriptive and are not required to map to literal raise statements.check-class-attributes = false \u2014 Attributes: sections document instance attributes without class-level annotations.Doc-forge can export a machine-readable MCP bundle from a project's GSDFC docstrings and serve that bundle over the Model Context Protocol (MCP). The bundle is self-contained: readers can derive the full API reference \u2014 signatures, docstrings, and structure \u2014 for the documented project.
"},{"location":"05_development/04_mcp_guide/#building-the-bundle","title":"Building the bundle","text":"doc-forge build --mcp --module docforge\n This writes structured JSON into docs/mcp/:
index.json \u2014 project metadata and module countnav.json \u2014 module list with docs://modules/{module} resource URIsmodules/{dotted.path}.json \u2014 per-module serialized documentationdoc-forge serve --mcp --module docforge\n The MCPServer (in docforge/servers/mcp_server.py) exposes:
docs://index Project metadata docs://nav Navigation structure docs://modules/{module} Individual module documentation The server also registers a single diagnostic tool, ping, and is read-only. 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.
Each module resource contains:
path \u2014 dotted module pathdocstring \u2014 the raw GSDFC module docstringobjects \u2014 a recursive mapping of public symbols with name, kind, path, signature, and docstring, plus nested membersBecause 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.
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}.
docs/mkdocs.{kind}.yml is a repo-owned file, not a build byproduct:
doc-forge build --{kind} materializes a copy from the packaged templates (see below) and then builds site/{kind}.site_dir are respected as-is.--refresh \u2014 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.
"},{"location":"05_development/05_mkdocs_configs/#templates","title":"Templates","text":"The built-in defaults live in docforge/templates/:
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.
site/{kind} and is served under /<repo>/{kind}/.mkdocs.yml (for example mongo-ops, whose wiki uses docs_dir: docs/wiki). 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.