D-Docs — Document Publishing Pipeline

Turns a Markdown file into a self-contained HTML site or PDF in one command, generating the heading hierarchy, table of contents, breadcrumbs, anchors and zoomable diagrams automatically.

Turning document production into a single command

272,152lines of code
503files
1,162commits
12data models

The hard part

Producing a consistent technical document usually means someone doing the layout by hand each time. That is where quality drifts, and why the tenth document rarely looks like the first. Automating it properly means handling the parts people quietly do by hand: hierarchy, navigation, cross-references and output that stands on its own.

Markdown goes in, and a finished, self-contained HTML or PDF document comes out. The heading hierarchy and breadcrumb navigation are generated automatically, which is what keeps long technical material easy to find your way around. Because each document is self-contained, it can be shared as a single file with nothing else to host.

445,422 lines of source; used heavily enough that its own generated output reached 29.6 GB.

What the measurements mean

Only what is unusual for this project. Every sentence names the field it came from; nothing here is asserted that cannot be checked against the data.

How it works

Producing a consistent technical document normally means someone redoing the layout by hand each time, and that is exactly where quality drifts. D-Docs automates the parts people quietly do manually. Heading hierarchy becomes navigable structure, cross-references resolve, and diagrams become zoomable. The output is a single self-contained file that can be handed to someone without assets going missing. Four content flows (linear, chapter, card and progressive) let one source render either as a reference document or as a walkthrough. It is used heavily across this estate: its own generated output reached 29.6 GB, which is why the scanner that inventories the estate carries explicit rules to keep that output from being counted as source.

What it is built from

Each bar is one of this project's own modules, sized by how many times the rest of the project imports it. The counts are measured, not estimated, and the module at the top is the one the rest of the project leans on most.

Module mapInternal modules by how often they are imported: tools 1892 times, core 65 times, generators 56 times, start 13 timestools1892core65generators56start13imports of each internal module, counted across the project

What kind of engineering this is

Six signals counted from the source: files that run models locally, that act without being asked each time, that check their own output, that survive failure, that touch parsers and protocols, and that were measured then improved. Every axis carries its file count.

Depth profileDepth signals: Local inference 23 files, Autonomy 14 files, Verification 24 files, Resilience 142 files, Low level 42 files, Iteration 0 filesLocal inference23 filesAutonomy14 filesVerification24 filesResilience142 filesLow level42 filesIteration0 files

What it is written in

Share of code bytes. Vendored bundles and generated output are set aside before this is computed, which is why it differs from a simple file count.

Language mixPython 63.6%, HTML 30.5%, CSS 5.3%, JavaScript 0.3%, SQL 0.1%, Batchfile 0.1%Python 63.6%HTML 30.5%

What stands out

Grade

Every check names the field it measured. Checks that cannot apply are excluded, never counted as failures.

B
85.7% over 19 of 19 checks100% coverage

Not met

Architecture

Directories carrying real modules, largest first.

Data model

Typed structures and tables found in the source.

Vulnerable dependencies

16 declared dependencies match a published advisory. Checked offline against the OSV database; only pinned versions can be checked, so anything unpinned here is unknown rather than clean.

Vocabulary

Parsed 408 of 408 Python file(s). Counts are exact; the names below are a sample.

4,222functions
1,730methods
445classes
404documented modules

Classes

Functions

Command line

Depth

Signals counted from the code, not asserted.

1160 commits across 86 separate working days over 9.6 months, 252 of them revising existing behaviour

Built from scratch

Closes its own loop

Proves itself

Survives failure

Local inference

Systems

Environment engineering

Working within limits

Distributed systems

GPU & memory management

Model operations

Languages

Built with

Recurring themes in the commit history

Evidence

Taken from the code itself: a module docstring or the opening of the README.

md-to-html CLI — convert a markdown file to HTML (interactive + static). Headless entry point intended for agents and scripts — no Qt/UI dependency. Typical usage: python cli.py INPUT.md # writes to ./output/<name>/ python cli.py INPUT.md -o /tmp/exports # custom base dir python cli.py INPUT.md --single-file # self-contained HTML python cli.py INPUT.md --minimal-output # emit only .md+_share+_late

At a glance

Status
active
Primary language
Python
First commit
2026-01-07
Last activity
2026-10-26
Domain
AI & machine learning