Architecture

Workspace packages organized in tiers. Lower layers never depend on higher ones — autodoc extensions consume shared infrastructure, and the presentation layer wires everything together for downstream projects.

The sidebar groups these packages into navigation buckets (Domain Packages, UX, Utils, Internal) — a reader-facing grouping that is orthogonal to the dependency-ordered tier map below.

Tier 1: Shared infrastructure

The rendering pipeline that every autodoc extension consumes:

sphinx-ux-badges

Badge primitives, colour palette, and CSS infrastructure. All badge colours live in one place (SAB.* constants).

sphinx-ux-badges
sphinx-ux-autodoc-layout

Structural presenter for api-* entry components. Parameter folding, managed signatures, card regions.

sphinx-ux-autodoc-layout
sphinx-autodoc-typehints-gp

Annotation normalization and type rendering. Replaces sphinx-autodoc-typehints + sphinx.ext.napoleon.

sphinx-autodoc-typehints-gp

Tier 2: Autodoc extensions

Domain-specific autodoc extensions that consume Tier 1 and add project-specific rendering logic. Each ships directives that generate documentation from a particular source-construct family:

sphinx-autodoc-api-style

Subject: standard Python. Directives: autofunction, autoclass, automodule.

sphinx-autodoc-api-style
sphinx-autodoc-argparse

Subject: argparse parsers — programs, options, subcommands, positionals. Directives: argparse (custom argparse domain).

sphinx-autodoc-argparse
sphinx-autodoc-docutils

Subject: docutils directives and roles. Directives: autodirective, autorole.

sphinx-autodoc-docutils
sphinx-autodoc-fastmcp

Subject: FastMCP tools, prompts, resources. Directives: fastmcp-tool, fastmcp-tool-summary.

sphinx-autodoc-fastmcp
sphinx-autodoc-pytest-fixtures

Subject: pytest fixtures (extends the py domain). Directives: autofixture, autofixtures, auto-pytest-plugin.

sphinx-autodoc-pytest-fixtures
sphinx-autodoc-sphinx

Subject: Sphinx config values. Directives: autoconfigvalue, autoconfigvalues.

sphinx-autodoc-sphinx

Each autodoc extension calls app.setup_extension() to auto-register its infrastructure dependencies — downstream projects only need to add the package to their extensions list.

Tier 3: Theme and coordinator

Package

Role

gp-sphinx

Coordinator. merge_sphinx_config() wires up the full stack.

sphinx-gp-theme

Furo-based theme with CSS variables and SPA navigation.

gp-furo-theme

Tailwind v4 port of upstream Furo for git-pull projects.

sphinx-fonts

IBM Plex via Fontsource — preloaded web fonts.

Build tooling

Cross-cutting build utilities that operate outside the docs-build runtime — one is a PEP 517 build backend invoked when wheels are produced; the other is an opt-in extension that drives the Vite watcher during sphinx-autobuild. Both let theme authors keep build artefacts (static/styles/*.css, static/scripts/*.js) out of VCS while still shipping working wheels and seamless live-reload during authoring.

sphinx-vite-builder

PEP 517 build backend (or hatchling build hook via [tool.hatch.build.hooks.vite]) that runs pnpm exec vite build before delegating wheel/sdist construction to hatchling. Also a Sphinx extension that auto-orchestrates vite build --watch during sphinx-autobuild and one-shot vite build during plain sphinx-build. Source builds error loudly without pnpm/Node; wheels ship turn-key. Publishable for use outside this workspace — any vite + Sphinx project can adopt either activation path without depending on the gp-sphinx coordinator.

sphinx-vite-builder

How the tiers connect

Every autodoc extension shares the same badge palette, the same componentized HTML output structure, and the same type annotation pipeline — so Python APIs, pytest fixtures, Sphinx config values, docutils directives, and FastMCP tools all look like they belong together.

This is the one autodoc design system principle: a change to the shared infrastructure propagates instantly and consistently across every autodoc extension in the workspace.