著者のブログパイプラインは、Org-mode ドキュメントから始まり、これが散文、実行可能なコードブロック、d2 図、参考文献を含む単一の真のソースとなる。Emacs 内にとどまることで、コンテキストスイッチングを避け、コンテンツを支えるすべての計算をその場で評価できる一貫した執筆環境を維持する。この設計は、以前の Emacs 中心の試みの進化を反映しており、出版側をより小さく、型安全で理解しやすくしつつ、Emacs を創造の中心として保つように洗練されている。
公開の時になると、Gleam ベースのコンバーターが各 Org ファイルを処理する：Pandoc を呼び出して Org を引用処理を含む GitHub Flavored Markdown に変換し、 Verse の保存、参考文献のグループ化、パス翻訳のための 3 つのカスタム Lua フィルターを適用し、その結果を Blogatto に渡して最終的な HTML 構造を生成する。同時に、Gleam と Lustre が連携してサイトレイアウト用の型検査済み HTML 要素を生成し、生成されるページが構造的に堅牢であることを保証する。著者は、投稿のリストを受け取り投稿インデックスページ用の Lustre 要素を返す Gleam 関数を例に挙げ、これがパイプライン全体が静的型チェックの恩恵を受けることを示している。
この画像は、2 段落で説明される変換パイプラインを示しており、Org ファイルが Pandoc と Lua フィルターで処理された後に Blogatto が HTML を生成する。
Nix flakes と devenv は、Gleam、Pandoc、make、その他の依存関係の正確なバージョンを固定した再現可能な開発環境を提供し、著者が単純な ‘nix develop’ コマンドで完全に設定されたシェルに入ることを可能にする。この再現性により、グローバルにインストールされたツールへの依存がなくなり、どのマシンでも同じビルド環境を再現できることを保証し、Emacs 内での快適で予測可能なワークフローという著者の目標を支援する。
著者は、Org-mode がこの用途において Markdown より優れている理由を、エディター内でインタラクティブである点だと主張する：ソースコードブロック、図、引用などの機能は、別のビルドステップを経て結果を確認するのではなく、リアルタイムで操作および検証できるからだ。Org-Publish はパイプラインの多くを自動化できるものの、著者は HTML 生成時に構文ハイライトなどの望む QoL 機能を達成するのが難しいと感じており、これが変換ステップを明示的に分離しておく決定を裏付ける。