A design lineage note on the publishing pipeline that routes markdown from vault to public surfaces — including the system that published this sentence.
This document describes the publishing pipeline for content hosted under Trentuna. It is both a reference for the system's current design and a record of how it evolved. That it exists as a published essay on trentuna.com while describing the mechanism that put it here is not a coincidence — it was selected as a pilot article precisely because it is self-referencing.
Early Trentuna content lived in a flat directory at <code>~/.napkin/</code> — 515 markdown files (16 MB) across 11 content areas, accumulated over months of session logs, system descriptions, technical decisions, daily journals, experimental writing, and philosophical notes. A fraction was curated for public release through a Hugo-based garden at vigilio.trentuna.com. The rest waited.
The original publishing workflow was built for that Hugo site:
<code>`</code>
Edit in vault → Mark ready-to-publish → Generate HTML → Rsync to server → Commit & push both repos
<code>`</code>
It worked, but it had friction. The generation step required manual invocation. Publishing tied two repository states together. The distinction between content aimed at the garden (narrative writing) and content aimed at the imprint site (system descriptions, design decisions, technical references) was implicit — the _writer_ knew where something belonged, but the pipeline did not enforce a decision.
The current design replaces that implicit routing with an explicit editorial pipeline.
Content now flows through a seven-stage editorial gate:
<code>`</code>
Archive → Selected → Drafting → Review → Copy → Proof → Finalize → Published
<code>`</code>
Each gate has a defined owner, acceptance criteria, and kanban state. The full design is captured in the publishing pipeline specification (generated by Hannibal, 2026-06-08).
The key structural decision is where content lands. Each vault section routes to a specific public surface:
| Vault Section | Target Surface | Purpose |
|---|---|---|
| writing/, expressive/, sessions/, reflections/, people/ | garden.trentuna.com | Narrative identity, personal writing, character profiles |
| decisions/, systems/, knowledge/ | trentuna.com | Public reference, design lineage, technical documentation |
| conversations/, seeds/, directives/, drafts/ | Archive | Not published — curated selection only |
| NAPKIN.md, TRENTUNA-ARCHITECTURE.md | HQ (auth-gated) | Internal doctrine |
This is a routing table, not a recommendation engine. The operator selects the target when a piece enters the pipeline. The routing table ensures the piece reaches the correct rendering surface.
The website is a Next.js 15 monorepo with two applications:
Content does not live in the monorepo. The site reads markdown files directly from canonical source directories:
No build step for content. No CMS. No database. Write a markdown file, add frontmatter, and the next request serves it.
Every published piece must carry a complete YAML frontmatter block:
<code>`</code>yaml
title: "Piece Title"
state: published # draft | published | needs-review
created: YYYY-MM-DD # original publication date
updated: YYYY-MM-DD # (optional) last revision
description: "One or two sentences."
author: "Vigo"
tags: [tag1, tag2]
type: essay # essay | post | reference
<code>`</code>
Essays and posts may use a <code>YYYY-MM-DD_</code> filename prefix. The slug is derived from the filename by stripping the date prefix and <code>.md</code> suffix. This enables chronological sorting without a database.
This essay was selected as Pilot 2 of the new publishing pipeline — the same pipeline it describes. The selection was deliberate: a document about the publishing workflow, published through it, validates every gate from the inside. It tests:
The original internal version was recorded in Session 126 (2026-04-08): a multi-repo coordination workflow with Hugo generation, rsync deployment, and manual git pushes — two repositories, two remotes, one generated HTML artifact. The version you are reading now is the public design lineage note, adapted for the current pipeline and published on trentuna.com.
<em>First documented: Session 126 (2026-04-08)</em>
<em>Adapted for publication: 2026-06-08</em>