Build squishmark.xeek.dev as a self-hosted SquishMark site (marketing + docs + blog)

[x3ek]

Description

Ship the real squishmark.xeek.dev website, running on SquishMark itself, doing three jobs in one site:

1. Documentation (primary) — the user-facing guides the README currently lists as "coming soon" (docs/getting-started.md, docs/theming.md, docs/configuration.md)
2. Dogfood blog (primary) — release notes, design posts, and updates from the maintainers, running through the actual SquishMark pipeline
3. Landing page (light touch) — a single home page that explains what SquishMark is and points at docs + GitHub. No big marketing surface, no theme gallery.

Self-hosted: a new xeek-dev/squishmark-content content repo fetched at runtime by a SquishMark deployment. Eating our own food is the whole point.

Why

• Dogfooding — every gap or sharp edge in SquishMark gets found when we actually run a site on it. The TOC bug we just shipped (Add auto-generated table of contents for posts #49 reviewer pass) is a good example of what dogfooding exposes that automated tests don't.
• Docs are blocked on infra — the README points at docs/*.md files that don't exist. Building the site forces us to write them.
• A real public site — needed before SquishMark 1.0 ships so the project has somewhere to point new users.

Approach

Three phases. Get something live before writing real content — every bug found in the deployment loop is easier to fix when there's nothing precious deployed yet.

Phase 1 — Skeleton + first deploy

Goal: https://squishmark.xeek.dev resolves and serves a SquishMark page (any page). Doesn't have to be good, has to exist.

• Create xeek-dev/squishmark-content repo (public)
• Minimum content scaffolding:
  • config.yml (theme: default, basic site metadata)
  • pages/index.md placeholder ("SquishMark — coming soon" or similar)
  • One stub post in posts/ (so post-listing routes don't 404)
• Decide which bundled theme to ship on (likely default)
• fly launch — create the Fly app (squishmark-site or similar), fly.toml, Docker build
• Configure secrets and env: GITHUB_TOKEN, GITHUB_CONTENT_REPO=xeek-dev/squishmark-content, OAuth secrets if admin is enabled
• Provision squishmark_data volume (per README deploy guide)
• DNS: CNAME squishmark → <app-name>.fly.dev at xeek.dev registrar
• fly certs add squishmark.xeek.dev; verify Let's Encrypt issuance
• fly deploy and smoke-test the live URL

Phase 2 — Real content

Goal: site is actually useful to a visitor. This is the bulk of the work.

• Landing page — replace the placeholder with real copy: what SquishMark is, links to docs + GitHub. Keep it tight.
• Documentation pages (pages/docs/getting-started.md, pages/docs/configuration.md, pages/docs/theming.md, pages/docs/frontmatter.md) — fill in the "coming soon" links from the README
• Changelog page (pages/changelog.md) — canonical release history
• Per-release blog posts — start with a "Welcome to SquishMark" post and a 1.0 release post; changelog answers "what changed," posts answer "why and how"
• Iterate on config.yml (OG metadata, favicon, featured posts)

Phase 3 — Automation + polish

Goal: content updates don't require manual ops; site can be maintained without touching the engine repo.

• Wire xeek-dev/squishmark-content push events to the SquishMark webhook so content changes refresh the cache without redeploying
• File any engine gaps surfaced during Phase 2 as separate issues (e.g. docs sidebar nav, deferred until pain is concrete)

Acceptance criteria

• https://squishmark.xeek.dev resolves (valid TLS) and serves a SquishMark deployment reading from xeek-dev/squishmark-content
• Home page explains what SquishMark is and links to docs + repo
• Docs section covers the three "coming soon" topics from the README at a useful level
• Changelog page exists with at least the 1.0 release as an index entry linking to the GitHub Release
• At least 2 blog posts published (including a 1.0 release post)
• Webhook auto-refresh works — pushing to squishmark-content updates the live site without redeploying the Fly app
• Engine bugs / sharp edges discovered during the build are filed as separate issues, not lumped in here

Out of scope (for this parent issue)

• Marketing copy beyond the home page (theme gallery, screenshots, feature pitch carousels, etc.)
• Custom theme — ship on a bundled one
• Analytics dashboards (we have analytics middleware already)
• Multi-language / i18n
• Comments / reactions

Engine gaps we'll likely surface

Tracked here for visibility; file as separate issues only when the pain is concrete:

• Documentation sidebar nav for the docs section
• Search (Search functionality #11) is much more valuable once docs content exists
• Tag pages / archives (Navigation & Discovery: tag pages, archives, related posts #10) for the blog section
• TOC sidebar (Add auto-generated table of contents for posts #49) gets its first real test on long docs pages

— Claude