TileDown treats Markdown as the author-owned format. The parser reads front matter, CommonMark blocks, and typed tile directives into a structured model.

The formatter can then rewrite a document to one canonical profile:

swift run tiledown fmt --check source.md
swift run tiledown fmt --write source.md

That keeps the source stable enough for reviews and future visual editing while still being a plain text format.

Swift unit tests cover the parser, model, renderer, and output contracts. They do not fully prove generated browser behavior.

The project now has a Playwright gate that builds a fixture site, serves it locally, and checks behavior in Chromium: image loading, tables, theme switching, draft exclusion, feeds, and local tile JavaScript.

TileKit targets macOS and Linux. The Linux path matters because the generator is an engine and CLI, not just a local macOS tool.

The repository runs Swift build and tests in a Linux container. The browser gate also runs on Linux, so generated-site behavior is checked where the public Pages build is produced.

Local Linux runs can use Docker, Colima, Lima, or a native Linux machine.

This post lives in posts/custom-source-url/, but its front matter publishes it at /posts/reference-routing/.

The same build resolves internal references. For example, this link points to the feature tour through a page: reference: Feature Tour.

External links can also go through generated redirect shims, such as the design notes.

The engine already has service contracts and service-form rendering tests. A service-form tile can bind to a typed operation contract, render browser-safe HTML, and avoid leaking server credentials.

The CLI does not yet load service bindings from tiledown.yml, so this public site does not render a live service form. That is intentional: the missing work is configuration and deployment plumbing, not a hidden demo path.