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

docs/wiki/05_development/01_environment.md

@@ -0,0 +1,30 @@
+# Environment Setup
+
+---
+
+## 🚀 Create the environment
+
+```bash
+python -m venv .venv
+.venv\Scripts\activate
+pip install -e .
+```
+
+Requires Python 3.10+ (per `pyproject.toml`).
+
+---
+
+## 📦 Dependencies
+
+Development extras include:
+
+- `pytest`, `pytest-cov` — test suite and coverage
+- `ruff` — lint and format checking
+- `black` — auto-formatting
+- `mypy` — strict typing 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

@@ -0,0 +1,34 @@
+# Quality Gates
+
+Run all checks before pushing:
+
+---
+
+## 🚀 Commands
+
+```bash
+.venv\Scripts\python.exe -m pytest
+.venv\Scripts\python.exe -m ruff check docforge tests
+.venv\Scripts\python.exe -m black --check docforge tests
+.venv\Scripts\python.exe -m mypy docforge
+.venv\Scripts\pydoclint.exe docforge
+```
+
+---
+
+## 📁 Test layout
+
+| 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.
+
+---
+
+## Related
+- [01 – Environment](01_environment.md) · [03 – GSDFC Guide](03_gsdfc_guide.md)

docs/wiki/05_development/03_gsdfc_guide.md

@@ -0,0 +1,129 @@
+# GSDFC Docstring Guide
+
+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.
+
+---
+
+## 🧭 Overview
+
+- Docstrings are the single source of truth.
+- `doc-forge` compiles docstrings but never rewrites them.
+- Every public symbol should have a complete, accurate docstring.
+- Type hints live in signatures; prose entries repeat the type in
+  parentheses and must match the signature.
+
+---
+
+## 📦 Module docstrings
+
+Modules use Markdown headings and `---` separators.
+
+Recommended sections:
+
+- `# Summary` — what the subsystem does
+- `# Examples` — a representative usage snippet
+- `# Notes` — guarantees, lifecycle, and thread-safety notes
+
+---
+
+## 📦 Class docstrings
+
+Recommended sections, in order:
+
+- summary line describing responsibility
+- `Attributes:` — instance attributes with `name (Type):` entries
+- `Notes:` — grouped subsections such as **Guarantees**, **Lifecycle**
+- `Example:` — indented `python` code block
+
+---
+
+## 📦 Function and method docstrings
+
+Recommended section order:
+
+1. `Args:`
+2. `Returns:`
+3. `Raises:`
+4. `Yields:`
+5. `Notes:`
+6. `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.
+- Summaries are written in the imperative mood.
+- Fenced `python` blocks are allowed inside `Example:` sections, indented
+  four spaces.
+
+---
+
+## 📦 Property docstrings
+
+Properties document their return values with a `Returns:` section and, when
+meaningful, an `Example:`.
+
+---
+
+## 🚀 Example
+
+```python
+def process(foo: Foo, multiplier: int) -> int:
+    """Process a Foo instance.
+
+    Args:
+        foo (Foo):
+            Foo instance to process.
+
+        multiplier (int):
+            Value used to scale foo.
+
+    Returns:
+        int:
+            Processed result.
+
+    Raises:
+        ValueError:
+            If multiplier is negative.
+
+    Example:
+        Process foo:
+
+            ```python
+            foo = Foo("example", value=10)
+            result = process(foo, multiplier=2)
+            print(result)
+            ```
+    """
+```
+
+---
+
+## 🔄 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
+
+`pydoclint` (Google style) runs in CI and verifies that `Args:`/`Returns:`
+sections match function signatures, including types.
+
+- `allow-init-docstring = true` — `__init__` docstrings are allowed.
+- `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.
+
+---
+
+## Related
+- [02 – Quality Gates](02_quality_gates.md) · [04 – MCP Guide](04_mcp_guide.md)

docs/wiki/05_development/04_mcp_guide.md

@@ -0,0 +1,62 @@
+# MCP Guide
+
+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 —
+signatures, docstrings, and structure — for the documented project.
+
+---
+
+## 🚀 Building the bundle
+
+```bash
+doc-forge build --mcp --module docforge
+```
+
+This writes structured JSON into `docs/mcp/`:
+
+- `index.json` — project metadata and module count
+- `nav.json` — module list with `docs://modules/{module}` resource URIs
+- `modules/{dotted.path}.json` — per-module serialized documentation
+
+---
+
+## 🚀 Serving the bundle
+
+```bash
+doc-forge serve --mcp --module docforge
+```
+
+The `MCPServer` (in `docforge/servers/mcp_server.py`) exposes:
+
+| Resource             | Description                       |
+|----------------------|-----------------------------------|
+| `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`.
+
+---
+
+## 📦 Bundle contents
+
+Each module resource contains:
+
+- `path` — dotted module path
+- `docstring` — the raw GSDFC module docstring
+- `objects` — a recursive mapping of public symbols with `name`, `kind`,
+  `path`, `signature`, and `docstring`, plus nested `members`
+
+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.
+
+---
+
+## Related
+- [03 – GSDFC Guide](03_gsdfc_guide.md) · [05 – MkDocs Configs](05_mkdocs_configs.md)

docs/wiki/05_development/05_mkdocs_configs.md

@@ -0,0 +1,59 @@
+# 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 builds `site/{kind}`.
+- **Present** — the build uses the file verbatim. Edits to the theme, palette,
+  plugins, markdown extensions, nav, or `site_dir` are 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 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.
+
+---
+
+## Related
+- [04 – MCP Guide](04_mcp_guide.md)