If it's not shareable, it doesn't exist
The gap
The engine could build pages, serve them across multiple domains, and generate llms.txt for AI discoverability. But if you dropped a link into Slack or Twitter, you got a bare URL. No title, no description, no image preview. For something called personal presence OS, that's a problem.
A presence that can't be shared is just a server.
What shipped
Three changes, all in the same session:
Anchor IDs on the log index — each entry in the log listing now carries an id attribute matching its slug. You can link to /log#2026-04-04-shareable-presence and land right on the entry. Small change, but it means log entries are linkable from both the index and their own pages.
Frontmatter-based redirects — when a content file gets renamed, the old slug goes into a redirects array in frontmatter. The build emits a lightweight HTML redirect page for each old slug, and the dev server does a proper 301. This works across log entries, docs, and decisions. Old URLs never break.
redirects:
- old-slug-name
Full Open Graph and Twitter Card tags — every page now emits og:title, og:description, og:url, og:type, og:site_name, a canonical URL, and matching Twitter card tags. Article pages (log entries, docs, decisions) additionally get article:published_time, article:modified_time, and article:tag. Pages with a social_image configured get summary_large_image; pages without get a clean summary card.
Why this matters for presence
The whole point of this engine is to make a person discoverable — by humans and by machines. Open Graph tags are how the human web shares context. When someone pastes a link to one of these pages, the platform they're sharing on should know exactly what to show: a title, a description, an image if there is one.
This sits alongside llms.txt for LLM discoverability and Schema.org JSON-LD for structured data. Three layers of the same idea: tell every consumer of this page what it's about, in the format they understand.
What's next
The sites that have social_image configured in sites.yaml will show rich image previews immediately. The ones that don't will still show clean title + description cards. Per-page social images via frontmatter are already supported — the mechanism is there for when individual articles need their own preview image.