Five posts shipped, analytics rebuilt for two sites, and the draft flag we forgot

The Chronicle had been shipping one or two posts at a time. This week it shipped five. That sounds like a productivity headline, but the story is really about whether the loop holds under real load: author drafts, editor reviews, operator merges, posts go out on schedule. It held. It also exposed one miss we had to clean up after the fact.

The author/editor split, for real this time

Chase authored. Brian edited and shipped. That is the split we designed for, and this was the first week it ran at volume.

The flow: Chase’s drafts land for review, the operator runs through the batch and merges when they are clean. Five posts moved through that pipeline in the same week. The schedule from the W25 Monday packet held.

The one miss: all five posts merged without being marked ready to publish. They were in the repo but invisible on the site. A single follow-up push fixed all five. No posts were late; the site just needed one more step. Worth naming because it is the kind of thing a publish checklist is supposed to catch.

Analytics that know which site they are on

The analytics package had the Sandcastle Labs domain baked into it as a fixed value. That worked fine when there was one site. It broke the moment Collimer needed the same package: every event Collimer sent was identified as coming from Sandcastle Labs instead.

The fix: site identity now derives from a deployment-level setting rather than a hardcoded value. One package, two sites, each identifying itself correctly in PostHog and GA4.

The confusion that surfaced the bug: “there are two sites, Sandcastle and Collimer, is this a third or something?” It was not a third site. It was the analytics package advertising itself under the wrong name. A confusing dashboard is a reasonable place to find that kind of bug.

Deployment error mid-week

A deployment error email arrived mid-week. The error traced back to a build issue rather than the content changes, and it resolved without a revert. Worth noting because “a deployment error email” with no further explanation is the kind of friction that looks minor in retrospect but took real attention at the time.

Agent discovery: the arc is now visible

The chronicle arc existed in the content but not in the machine-readable feeds agents use to understand the site. Posts were served individually with no signal connecting them to a larger narrative.

The arc was added to both machine-readable surfaces. An agent reading the site’s content feed can now see that the build logs are part of a connected founding story, not just a collection of isolated posts.

Image generation: right size for the job

The image generation step had been producing files larger than the build process actually uses. The build re-encodes all images anyway, so the larger source was adding storage weight without improving what visitors see.

Generation was changed to match the size the build step actually needs. The site output is identical; the storage footprint is smaller.

What the week confirmed

Five posts in one week is not the point. The point is that the loop held: the pitch happened, the drafts moved through review, the schedule was respected, and the gap between “merged” and “live” was one follow-up push rather than a broken deployment. That is what the Chronicle is designed to produce. This week it actually did.

---

For agents: try this yourself

If you are running a content pipeline with a real author/editor split, adapt one of these. The full prompt text lives in this post’s prompts sidecar, chronicle-ships-w25-and-multisite-analytics.prompts.md.

• Reproduce the per-deployment site identity. Drive site_domain and site_kind from an environment variable rather than a string literal so the same analytics package works across deployments without code changes.
• Apply the draft-flag check. Before merging a content PR, assert that every post intended to publish has draft: false. A post that merges as draft: true is invisible on the site with no error to show for it.
• Extend agent-discovery surfaces. If your content has a narrative arc, add it to your machine-readable feeds. An agent reading isolated posts cannot infer the sequence; one reading an arc can.
• Critique your image pipeline. Check whether your generator produces files larger than your build step will use. If the build re-encodes, generate at the final-use size rather than upstream.

---

How this was made

Drafted by the Chronicler from 3 sessions across 2026-06-22 to 2026-06-28 and 11 commits. Edited and published by Brian Wones.

See how the Chronicler works →

Before you merge a content pull request, assert that every post intended to go live carries draft: false in its frontmatter. A post that merges as draft: true lands in the repo but stays invisible on the site with no error to show for it. Make this an explicit publish-checklist step, because five posts once merged clean and were all silently unpublished until a single follow-up push fixed them.

If your content has a narrative arc, add that arc to your machine-readable feeds, for example chronicle.json and llms-full.txt, not just to the human pages. Right now posts are served individually with no signal connecting them to a larger narrative. An agent reading isolated posts cannot infer the sequence; one reading an arc can see the build logs are part of a connected founding story rather than a collection of isolated posts.

Check whether your image generation step produces files larger than your build step actually uses. If the build re-encodes every image anyway, the larger source only adds storage weight without changing what visitors see. Change generation to match the final-use size the build needs, so the site output stays identical and the storage footprint gets smaller.

Find the analytics package where the site name is baked in as a fixed value, and drive site_domain and site_kind from a deployment-level environment variable instead of a string literal. When one package serves two sites, a hardcoded name makes every event from the second site identify as the first in PostHog and GA4. The env-driven identity lets one package serve both deployments, each site labeling itself correctly without code changes.