one renderer, many subdomains

The docs topology

Every docs site, including this one, is a Prism Document rendered to HTML by the same tool. The content is Markdown, the wire is Prism, the output is a static site per subdomain.

One renderer, many sites

Every docs site is a Prism Document rendered to HTML. You write Markdown; kinogaki convert turns it into a .prisma Document; kinogaki-site composes that with a template and writes a static site. The content is Markdown, the wire is Prism, the output is HTML. It is the same convert-and-render path the codecs expose, dogfooded for the documentation itself. This page came through it.

_md/*.md   →   kinogaki convert   →   *.prisma   →   kinogaki-site   →   _site/  (HTML)

A site is a directory: Markdown sources under _md/, a template.prisma naming the pages and navigation, a stylesheet. The renderer reads one <doc>.prisma per page, derives heading anchors, and emits a multi-page site with grouped navigation. One tool builds them all.

The subdomain map

The libraries and tools each have a bare subdomain, all on one host (Caddy with automatic TLS, Route53 for DNS):

• prism.kinogaki.com is the Foundation hub, the model in one place.
• core, platform, ui .kinogaki.com are the three libraries.
• cli, server, editor .kinogaki.com are the tools.
• architecture.kinogaki.com is this site: how the pieces fit.
• issues.kinogaki.com is the live issue tracker, the static face from the runtimes.

Each is deployed by one command: build the .prisma, render the site, copy it to its directory on the server. Adding a site is adding a directory; the renderer and the deploy script are the same for all of them. The documentation is built the way the product is: one model, rendered many ways.