Changelog — 2026-05-08 (#1)

Sweep: LFM 0.3.0, Astro 6.3.1, and OpenPanel layered across the fleet

Why Care?

Three things converged today.

One, @lossless-group/lfm v0.3.0 went live on JSR — the first 0.3.x cut, carrying everything the LFM development branch had been accumulating since 0.2.2 (callouts with brand-source detection, the new llm-response and excerpt callout types, callout CSS as a two-tier semantic-token surface). For sites consuming LFM as a published dependency rather than a workspace link, this is the upgrade that lets them stop pretending the local link: was production-equivalent.

Two, Astro 6.3.1 is out and we needed it everywhere. Every actively-maintained site in this pseudomonorepo (and the splash sites that hang off it and its siblings) was lagging — most on 6.0–6.2, the LFM splash all the way back on Astro 5.16. We took the opportunity to also pick up the minor bumps that had piled up: @astrojs/vercel, @astrojs/check, tailwindcss + @tailwindcss/vite, vitest, jsdom, typescript, @types/node. Nothing dramatic on its own. All boring, all green.

Three, OpenPanel.dev joined the analytics evaluation — added alongside the existing Umami and Fathom rather than replacing either. Same <Analytics /> component pattern in every site, gated on import.meta.env.PROD && OPENPANEL_CLIENT_ID so the new block stays inert until each site's clientId is provisioned. We're still comparing platforms; layering preserves the comparison window.

The point isn't that any of these three is hard in isolation. It's that the same per-site <Analytics /> discipline, the same pnpm build verification motion, and the same link: vs JSR mode-switch script all held up across eight separate repos with eight separate git histories. The pseudomonorepo posture earned its keep today.

What's New?

@lossless-group/lfm 0.3.0 on JSR

• Published to jsr.io/@lossless-group/lfm (npm:@jsr/lossless-group__lfm@0.3.0)

• mpstaton-site development was on link:../../../lfm for active LFM dev; merged into main with the dep flipped to JSR via pnpm lfm:jsr

• Both mpstaton-site branches (main and development) now sit at the same merge commit, both consuming JSR

• Sister sites bumped from ^0.2.2 → ^0.3.0 where applicable (twf_site, fullstack-vc)

Astro 6.3.1 across the actively-maintained fleet

lossless-monorepo/site (the legacy lossless.group surface) was deliberately skipped — too much accumulated weight, too high a chance of turning into a rabbit hole.

OpenPanel layered into every Analytics component

• Each site keeps its existing Umami and/or Fathom snippets — nothing removed

• Each site's src/components/Analytics.astro now reads OPENPANEL_CLIENT_ID from import.meta.env and emits the OpenPanel init/script pair when both PROD and the env var are present

• lfm/splash had no Pass-1 analytics at all; it gets OpenPanel as its first tracker

• Three GitHub Pages workflows (astro-knots/.github/workflows/pages.yml, content-farm/.github/workflows/pages.yml, lfm/.github/workflows/pages.yml) were updated to inject OPENPANEL_CLIENT_ID from a repo Variable at build time:

  YAML

  - name: Build
    run: pnpm build
    env:
      OPENPANEL_CLIENT_ID: ${{ vars.OPENPANEL_CLIENT_ID }}

  Variable, not Secret — clientId is publicly visible in rendered HTML by design.

• .env.example files updated where present; lfm/splash got a new .env.example since it had none

The driving prompt — context-v/prompts/Setup-Analytics-Across-Sites.md — was updated with the rollout-status table and the GitHub Pages env-var setup recipe so the discipline is documented, not just performed.

How the day actually went

The arc was three nested loops.

Outer loop: bring mpstaton-site's long-running development branch (which had accumulated callouts, wikilink audits, the YouTube playlist family, OG enrichment, analytics experiments) into main cleanly, with the LFM dep flipped from local link mode back to JSR for production. The lfm-mode.mjs script (which auto-detects branch and swaps package.json between link:../../../lfm and npm:@jsr/lossless-group__lfm@<version>) earned its design — a single pnpm lfm:jsr call did the package.json edit and the lockfile regen. Build was green on the first attempt.

Middle loop: the realization mid-merge that "we might as well update Astro and the rest while we're in here." pnpm outdated in each site, sorted by site, showed a consistent shape — Astro 6.0–6.2 → 6.3.1, plus a clutch of minor patch-bumps across Tailwind, Vercel, vitest, jsdom. Two sites errored on pnpm outdated (Cannot read properties of undefined (reading 'optionalDependencies') — pnpm 10.15 bug, not ours). We worked around by reading the package.json directly and cross-referencing against the npm registry. Eight pnpm install --ignore-workspace --no-frozen-lockfile runs in parallel via background tasks, eight pnpm build runs to verify. All green.

Inner loop: the OpenPanel layer. The original Pass-1 prompt (2026-05-06) had instrumented eight sites with Umami + Fathom in a unified <Analytics /> pattern. Today's job was to extend the same component, not replace it — keep the existing trackers, gate the new OpenPanel block on its own env var, document the per-platform setup in a single-source-of-truth prompt. The pseudomonorepo's instinct toward conventional shape over abstraction paid out here: every site's Analytics.astro is a different specific implementation, but they all answer to the same shape, so the diff was identical-modulo-IDs across all eight files.

The one wrinkle worth recording: GitHub Pages does not read .env files at build time. We had local .env files with OPENPANEL_CLIENT_ID in each splash, but those don't ship to the build runner. The fix is the workflow env: block above, sourcing from a repo Variable. Documented in the prompt so this doesn't get re-discovered next time.

What's still open

• Vercel-deployed sites (mpstaton-site, twf_site, fullstack-vc, hypernova-site) need the OPENPANEL_CLIENT_ID env var set in each project's Vercel dashboard. Until that's done, the OpenPanel block stays inert in production — the gate ({isProd && openPanelClientId && ...}) is doing its job.

• Pages-deployed splashes (astro-knots/splash, content-farm/splash, lfm/splash) need the OPENPANEL_CLIENT_ID repo Variable set. Same gate, same inert-until-set behavior.

• memopop-ai/splash is being relocated from apps/memopop-site/; the new splash will pick up the same Analytics pattern when it lands.

• lossless-monorepo/site stays on its current stack — defer the upgrade to a dedicated session when it's worth the rabbit-hole.

Files touched

This is a parent-level changelog; the per-submodule diffs live in each site's own changelog/ (where present) or git history. The submodule pointers in this repo's master will catch up as each site's child commits get pushed.

• sites/mpstaton-site — pointer bumped to merge commit 61f78f0 (development → main, LFM 0.3.0 from JSR)

• sites/twf_site — Analytics.astro + package.json + lockfile

• sites/fullstack-vc — Analytics.astro + package.json + lockfile + .env.example

• sites/hypernova-site — Analytics.astro + package.json + lockfile

• splash/ — Analytics.astro + package.json + lockfile + .env.example, plus .github/workflows/pages.yml env injection

• (sibling repos: content-farm/splash, lfm/splash got the same treatment in their own histories)