Lighthouse Site Design

This document describes the implementation-facing design of the Lighthouse site repository.

Table of Contents

• Goals
• Content Model
• Automation Boundary
• Public Build Surface
• Design Notes

Goals

Lighthouse is a static-first personal site. It is designed to:

• render entirely as a static Jekyll site
• keep the public site free of runtime mutation surfaces
• support hand-authored pages and photo entries directly in-repo
• accept automation-generated Markdown posts from the deployment pipeline

Content Model

The current repository has four content classes:

1. root pages such as index.html and privacy-policy.md
2. the About section under aboutme/
3. photo entries under _photos/
4. automation-generated posts under _automated_posts/

Shared presentation is owned by:

• _layouts/
• _includes/
• assets/css/site.css
• _data/

Automation Boundary

The deployment pipeline writes only to machine-owned paths:

• _automated_posts/
• assets/generated/

Everything else is treated as hand-maintained site source.

The pipeline is implemented in the separate ../../lighthouse-cli/ repository. It is responsible for:

• syncing source repositories
• rewriting local Markdown references
• generating explicit Jekyll front matter
• copying referenced local assets
• building and deploying the final site

Public Build Surface

Jekyll should only publish the site itself. Repository-only materials such as docs, local tooling notes, vendored gems, and Git metadata are excluded in _config.yml.

The public site output is generated into _site/ and is not tracked as source.

Design Notes

• No WordPress taxonomy model is carried forward.
• The site uses a small number of explicit collections instead of a CMS object model.
• Search is intentionally deferred until after automated blog material is flowing into _automated_posts/.