ColophonMarkdown Blog Engine

Colophon turns a folder of Markdown files into a complete static publication. You write essays as plain text files, run one build, and get a home page, an archive, subject pages, browser search, and RSS, Atom, and JSON feeds, with no database and no running app server. The content, the build, and the output all stay as files you can open and read.

51 checks pass, every generated internal link resolves, and browser checks covered theme switching, article navigation, the table of contents, search, empty results, and 390px overflow. There were no deployments and no external service calls. The Markdown support is a subset; I would not promise full CommonMark compatibility without testing it against a larger conformance set. There is no watch mode, so every edit means a manual rebuild.

This one went to Codex. Project 36 was on the Codex list in the split file (00-system/capstone-split.md) on September 23, when Claude Code and Codex were working the repo in tandem. The tool guard marks it a Claude Code project, and the split file carries an override that authorized Codex for its rows.

Codex was not starting from zero. Earlier work in the folder had already left a Markdown parser, a syntax highlighter, a YAML parser, and theme strings. Codex tested and reused those, then built the post model, the generator, the feeds, search, the CLI, six sample essays plus one excluded draft, the tests, and a local preview. It hardened paths and data URLs, checked every generated link, ran browser checks, and inspected its own screenshots. No subagents. About 0.15 hours this session, not counting the earlier parser work.

Following the protocol, Codex wrote its LOG-ENTRY.json in the project folder and never touched the shared tracker. Claude Code merged it after checking it.

One coordination detail: the build log still calls this app Quire. #49 PDF to Flashcards also shipped as Quire the same day, and this one was renamed Colophon so the two would not clash.

• Model a build as a pure map of file paths to text. That makes builds easy to compare for reproducibility, and every internal link can be checked before anything touches disk.
• Slugs are filesystem inputs. Post slugs need strict validation, and tag labels need their own safe identifiers instead of being used as paths directly.
• An explicit publication cutoff date keeps a build reproducible and makes future-dated posts visibly excluded.
• Keep the previous output. The CLI stages the new build and moves the old one into a local backup, so a bad build never leaves stale or half-written files.

The real carry-forward here is the coordination, not code. This was one of the first Codex rows, and it shows the split working: Codex built in its own folder, logged in its own file, and Claude Code checked and merged. The name clash with #49 was one of the real problems that protocol surfaced and fixed. No modules from this project were imported by later ones.

I would add a watch mode and an image-copy pipeline, then run the parser against a proper CommonMark fixture set before claiming more than a subset.