2024.garden
Tools
What worked
The unified remark/rehype pipeline with consistent plugin ordering and a single code path for all 8 content types has been the backbone — it held up through every subsequent phase without needing restructuring. AST-based link rewriting over regex proved its value under edge cases that would have broken pattern matching. Build-time link graph gives O(1) backlink lookup that scales past 500 pages without performance issues. Sharp-based image compression during sync (quality 80, max 2000px) solved an asset size problem that was quietly making deploys slow.
What broke
Low link density — only 4 cross-page wikilinks across 318 pages. The plumbing works perfectly, but I haven't actually linked my content together, which means the graph features are mostly decorative. No test suite despite Vitest being installed — the complex pipeline is entirely untested, which is a real risk given how many plugins interact. Algolia SDK is installed but never wired for search. Seven files still import from a deprecated backward-compat shim. These are all signs of 'shipped but not maintained' — the kind of debt that accumulates quietly.
Roles
I set the editorial constraints: Obsidian-first rendering, one-way sync (vault is source of truth, never write back), shortest-path wikilink matching to exactly replicate Obsidian behavior. I chose the 8 content types and the maturity indicator scheme. Claude Code wrote the unified pipeline, sync tool, link graph builder, hover previews, dark mode, and every component on the site.
2024.garden (Personal Digital Garden)
Overview
2024.garden is a personal digital garden and publishing platform (andrewlb.com) built on Next.js 14 that transforms an Obsidian vault into a published website. It supports native Obsidian syntax (wikilinks, callouts, embeds, highlights) with bidirectional linking and a build-time link graph. This is the site you're reading.
Target users: Single author (Andrew Lovett-Barron) publishing personal knowledge base.
What It Does
- Publishes 8 content types: blog, reading notes, weekly digests, STEM topics, projects, garden notes, talks, CV
- Renders native Obsidian syntax: wikilinks, callouts, embeds, highlights
- Build-time link graph with backlinks on every page and hover preview tooltips
- Garden maturity indicators (Seedling/Budding/Evergreen) signal content status
- Tag index pages with case-insensitive matching
- Automated vault-to-site sync with publish field validation
- Sharp image compression during sync (quality 80%, max 2000px)
- RSS feed with full-text content
How It Fits Together
A custom sync pipeline copies published markdown from an Obsidian vault to _content/, compressing images with Sharp along the way. Next.js 14 builds static HTML using a unified remark/rehype pipeline (remarkParse -> remarkGfm -> remarkWikiLink -> remarkEmbedContent -> remarkCollectLinks -> remarkObsidianHighlight -> remarkImagePaths -> remarkRehype -> rehypeCallouts -> rehypeSlug -> rehypePrism). The pipeline extracts a link graph at build time for O(1) backlink lookup. Deployed on Vercel as a static site.
Architecture Decisions
- Obsidian-first rendering — Author writes in Obsidian; site must render native syntax directly, not convert to standard markdown
- Unified pipeline for all content types — Single processor, consistent plugin ordering, one code path
- Build-time link graph — O(1) backlink lookup; no performance collapse at 300+ pages
- Shortest-path wikilink matching — Matches Obsidian's own resolution behavior exactly
- AST-based plugins over regex — Robust link/image handling that survives edge cases
- One-way sync — Vault is source of truth; never write back, never risk sync conflicts
- Atomic file writes during sync — Safe even if the process crashes mid-write
What Changed After Dogfooding
The biggest realization is that the graph features are mostly decorative. With only 4 cross-page wikilinks across 318 pages, the bidirectional linking infrastructure is technically solid but editorially underused. The technical system works; the content curation problem is the actual bottleneck. This is a pattern worth noting: AI-assisted development can build sophisticated features faster than one person can create the content to feed them.
Image compression (Phase 8) was a late addition that solved a problem I should have anticipated from day one — hundreds of uncompressed images making deploys slow. The fix was straightforward but the delay was a classic case of deferring production readiness.
Weaknesses & Open Questions
- Low link density — Graph features exist but content isn't linked enough to make them valuable
- No test suite — Vitest installed but unused; the pipeline's plugin interactions are entirely unverified
- Legacy imports — 7 files still reference a deprecated backward-compat shim
- No full-text search — Algolia SDK installed but never wired
- dangerouslySetInnerHTML — Safe today because all markdown is trusted, but fragile if the source model ever changes
- Hardcoded asset routes — Magic strings scattered across files instead of a centralized config
Ecosystem Role
2024.garden is the publishing endpoint for the Obsidian vault that also feeds PM Toolkit and Evolver. Edytor (Phase 5) is designed to analyze and improve content flowing into this site. The site itself is a self-referencing loop — including publishing this writeup about its own construction.