chore(release): 0.0.7

Squash-merge lib-standardisation: adopt repo standards across packaging,
tooling, docs, and CI.

- standardize pyproject.toml (canonical packaging, lint config, extras, GSDFC pydoclint)
- add py.typed marker, modernize type hints and Google-style docstrings
- nest generated docs under docs/lib and docs/mcp; add hand-written wiki
- adopt standard Type A PyPI CI pipeline (tag==version guard + quality gate)
- promote generated CHANGELOG.md; bump version to 0.0.7

docforge/__init__.py

@@ -22,29 +22,49 @@ pip install doc-forge
 
 # CLI usage
 
-## Generate an MkDocs site from a Python package:
+Each site kind (`lib`, `api`, `wiki`) is built independently into `site/{kind}`.
+
+## Build the library reference from a Python package:
 
 ```bash
 doc-forge build --mkdocs --module my_package
 ```
 
+## Build the API reference from an OpenAPI spec:
+
+```bash
+doc-forge build --api --openapi-spec spec.json
+```
+
+## Build the hand-written wiki:
+
+```bash
+doc-forge build --wiki --site-name my_package
+```
+
 ## Generate MCP JSON documentation:
 
 ```bash
 doc-forge build --mcp --module my_package
 ```
 
-
-## Generate MkDocs site and MCP JSON documentation:
+## Build several kinds in one pass:
 
 ```bash
-doc-forge build --mcp --mkdocs --module my_package
+doc-forge build --mcp --mkdocs --wiki --module my_package
 ```
 
-## Serve MkDocs locally:
+Each enabled kind gets its own MkDocs config (`docs/mkdocs.{lib,api,wiki}.yml`)
+and its own site under `site/`.
+
+## Serve a site locally:
 
 ```bash
-doc-forge serve --mkdocs --module my_package
+doc-forge serve --wiki        # preview from docs/mkdocs.wiki.yml
+doc-forge serve --lib
+doc-forge serve --api
+# or any config directly:
+doc-forge serve --mkdocs --mkdocs-yml docs/mkdocs.wiki.yml
 ```
 
 ## Serve MCP locally:
@@ -129,7 +149,9 @@ GSDFC defines how docstrings must be written so they render correctly in MkDocs
 
 - Use **Markdown headings** at package and module level.
 - Use **Google-style structured sections** at class, function, and method level.
-- Use type hints in signatures instead of duplicating types in prose.
+- Use type hints in signatures.
+- Use parenthesized types in prose entries (`name (Type):`) that match the
+  signature types. This keeps docstrings self-contained and machine-parseable.
 - Write summaries in imperative form.
 - Sections are separated by `---`
 
@@ -189,7 +211,10 @@ Example:
                 engine.run()
                 ```
 
-Avoid fenced code blocks inside structured sections.
+Avoid fenced code blocks inside argument descriptions and other prose lines.
+
+Inside `Example:` sections, fenced `python` code blocks are allowed and must be
+indented four spaces, matching the examples below.
 
 ---
 
@@ -521,6 +546,20 @@ Example:
 
 ---
 
+# Type parity (`.pyi` stubs and `py.typed`)
+
+Documented APIs ship matching type information:
+
+- Each `.py` module has a synchronized `.pyi` stub in the same package.
+- Packages expose a `py.typed` marker so type checkers (and consumers)
+  use the authored signatures instead of `Any`.
+- When signatures change, update the `.py` implementation and its `.pyi`
+  stub together.
+- Doc-forge documents the docstrings in `.py`; the `.pyi` stub is the
+  machine-consumable signature surface.
+
+---
+
 # Parsing guarantees
 
 GSDFC ensures doc-forge can deterministically extract: