Project Map

The Wheel of Heaven knowledge base spans ~20 repositories across one GitHub organization. Most contributors only touch two or three. This page shows the whole org at a glance so you can find the one you actually need.

For the full per-repo details — directory layouts, URLs, etc. — see Repository Inventory. This page is the map.

The sites (the output)#

Three production sites, each its own Cloudflare Pages project:

The shared inputs (the source)#

Both www and api read from the same content + theme submodules:

So a single content change in data-content is picked up by both the reading site and the API on the next submodule-pointer bump.

The research core (the meaning)#

core is not a submodule and ships nothing to the sites. It is the authoritative record of what the framework claims and how it reasons, kept separate from the prose that presents those claims in data-content. Public pages may point back to a core claim at an exact version (core_claim_ids / core_versions), so a claim can change without silently redefining the pages that render it.

Pipelines (the processing layers)#

Three repos run pipelines that turn raw inputs into ship-ready outputs. These are not submodules — they’re standalone tools.

Authoring + automation#

How things connect#

flowchart TB
    subgraph submodules["Shared submodules"]
        dc["data-content<br/><i>markdown, 10 languages</i>"]
        dl["data-library<br/><i>books JSON</i>"]
        bf["bifrost<br/><i>theme</i>"]
    end

    www["www"]
    api["api"]
    docs["docs"]

    core["core<br/><i>claims + evidence</i>"]

    dc -.-> www
    dl -.-> www
    bf -.-> www
    dc -.-> api
    dl -.-> api
    bf -.-> docs
    core -. "claim IDs" .- dc

    di["data-images"]
    dcin["data-cinematics"]
    assets["assets"]
    di --> assets
    dcin --> assets

    cf[("Cloudflare Pages")]
    www    --> cf
    api    --> cf
    docs   --> cf
    assets --> cf

Where to start, based on what you want to do#

If you’re not sure which one you need, start with Local Setup — it walks through cloning all the major ones.

Why so many repos?#

The split between www (site code) and data-content (content) lets content authors work without touching site code, and vice-versa. Sharing content as a submodule means the API and the reading site never diverge. Pulling the theme out of the site repo means it could (in theory) be reused. Most of the rest are pipelines that are conceptually independent of the site itself — image processing, EPUB generation, PDF ingestion — and benefit from their own scope.