2026-04-13 | 📊 Daily Updates Table Redesign 🔄
🎯 The Mission
🔧 Every day, our automation pipeline touches many files in the Obsidian vault: adding images, inserting internal links, posting to social platforms. 📝 Each change gets recorded in the daily reflection note under an Updates section, so the vault owner can glance at one page and see everything that happened.
🐛 The old format used nested bullet lists: each page appeared as a top-level bullet with indented sub-bullets for each operation. 📏 This worked fine when there were a few updates, but on busy days with dozens of files getting images, links, and social posts, the section ballooned into a long vertical list that was hard to scan.
🎯 The goal was twofold: compress the vertical space using a markdown table, and add a stats summary line so the reader gets an instant birds-eye view of the day’s activity.
🏗️ Architecture: From Text Surgery to Parse, Merge, Render
🔪 The old implementation used index-based text surgery. 📍 It would find the line number of a page entry, count sub-bullets, and splice new text at specific indices. 🐛 This approach was fragile: off-by-one errors, whitespace sensitivity, and difficulty reasoning about correctness.
🧩 The new architecture follows a principled three-phase pipeline. 📖 First, parse the existing updates section into structured data. 🔀 Second, merge new entries with existing ones. 📐 Third, render the merged data into the final table format.
🏷️ The key insight was replacing free-text detail strings with a proper algebraic data type. 📦 Instead of carrying raw text like “posted to BlueSky” or “added 3 internal links,” each update now carries a typed value: ImageAdded, InternalLinksAdded with a count, or PostedTo with a Platform. 🔬 This makes the code self-documenting and eliminates an entire class of string-matching bugs.
📊 The New Format
📈 The stats line appears right below the section header, serving as both a summary and a legend. 🔤 Each stat includes the emoji and a descriptive word, like “2 🖼️ images” and “3 🔗 links” and “1 🦋 Bluesky,” so readers always know what each column represents. 🔢 For internal links, the stat shows the total count across all pages. 📋 For everything else, it shows how many pages received that type of update. 📝 Only non-zero categories appear, keeping the line compact.
📐 The table uses emoji-only column headers to minimize width: image gets a framed picture emoji, links get the link emoji, and each social platform gets its mascot emoji. 📏 Only columns with at least one entry are shown, so if nobody posted to Twitter today, that column simply does not appear.
🎨 Cell values use the column emoji rather than generic checkmarks. 🦋 A Bluesky cell shows the butterfly emoji, 🐘 a Mastodon cell shows the elephant, and 🖼️ an image cell shows the picture frame. 📊 This means even at the bottom of a very large table, you can immediately tell which column you are looking at without scrolling back to the header. 🔢 Internal link cells use numeric counts since the number itself carries important information.
🔧 Wiki links containing pipe characters are escaped as backslash-pipe to prevent breaking the markdown table structure. 📝 Titles like “2026-03-28 | My Reflection” render safely because all pipes within the wiki link brackets are escaped. 📖 The parser handles both escaped and unescaped pipes for backward compatibility with existing data.
🔀 Smart Merging
🧩 One interesting design challenge was how to handle incremental updates. 🔄 The automation runs multiple tasks sequentially: first image backfill, then internal linking, then social posting. 📝 Each task calls the update function separately, so the same page might receive updates from multiple tasks across different invocations.
➕ The merging logic handles this naturally. 📊 For the same page and same column, internal link counts add together (two plus three becomes five), while boolean operations like ImageAdded are idempotent (adding it twice still shows the same emoji). 🆕 New pages get appended as new rows, and new detail types for existing pages expand the column set.
📖 Backward Compatibility
🔄 Existing daily reflections still have the old bullet format. 📖 The parser understands both formats: it detects whether the section contains a table header and dispatches to the appropriate parser. 🔀 When a legacy bullet section receives a new update, the entire section is migrated to table format automatically. ✅ Legacy tables that used checkmark cells instead of emoji cells are also migrated on the next update. 🧹 This means the migration is gradual and requires zero manual intervention.
🧪 Testing Highlights
🔬 The test suite covers twenty-six scenarios including table creation from scratch, incremental accumulation across multiple invocations, idempotency (duplicate details produce no changes), legacy format migration (both bullet and checkmark formats), pipe escaping round-trips, section placement before social media embeds, internal link count summation across pages, legend labels in stats, and property-based testing that content outside the updates section is never lost.
📊 All one thousand seven hundred seventeen tests pass with zero hlint hints.
💡 Reflections on the Approach
🏷️ Introducing the UpdateDetail algebraic data type was the most impactful change. 🔬 It turned a fragile string-matching system into a type-safe one where the compiler catches mistakes. 📦 The Platform type was already defined elsewhere, so PostedTo Platform reuses existing domain modeling perfectly.
🧩 The parse, merge, render pipeline is dramatically simpler than the old approach. 📖 Parsing converts messy text into clean structured data. 🔀 Merging operates on that clean data with clear semantics. 📐 Rendering produces consistent output every time. 🔄 Each phase is independently testable and composable.
🔧 The column-narrowing feature, where only active columns appear, prevents the table from growing unnecessarily wide. 📏 On a day with only image updates, the table has just two columns: Page and the image emoji. 📊 On a busy day with all five update types, all columns appear automatically.
📚 Book Recommendations
📖 Similar
- Domain-Driven Design by Eric Evans is relevant because the core insight of this change was modeling update details as domain types instead of raw strings, which is a central theme of the book.
- Algebra-Driven Design by Sandy Maguire is relevant because the merging behavior forms a natural algebraic structure where idempotent and additive operations compose predictably.
↔️ Contrasting
- The Pragmatic Programmer by David Thomas and Andrew Hunt offers a perspective where quick-and-dirty text manipulation is sometimes the right choice for throwaway scripts, contrasting with the principled typed approach taken here.
🔗 Related
- Thinking with Types by Sandy Maguire explores how Haskell’s type system can encode domain constraints and eliminate entire classes of runtime errors, which directly applies to the UpdateDetail ADT design.