Public content authority #

Cameron.stream deliberately uses different authorities for different kinds of public content. There is no single “canonical Markdown” layer.

Blog: Leaflet only #

Blog posts are authored and stored in Cameron's Leaflet publication as site.standard.document records with pub.leaflet.content bodies:

at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.publication/3md7ylshxzk2y

The repository contains no Blog Markdown copies, Blog projection manifest, importer, writer, or reconciliation job. The site reads the publication from Cameron's PDS at runtime, filters for the blog tag, and converts Leaflet blocks to HTML for Cameron.stream. Editing and publishing happen in Leaflet.

Stable document paths provide the public Cameron.stream routes. Leaflet analytics are independent of repository state: Leaflet aggregates pageviews by publication domain and URL path.

About: Git-backed #

content/about.md is the canonical About document. Its public ATProto record is an outward projection tracked by content/about-atproto-manifest.json and reconciled by pnpm about:sync.

About prose belongs to Cameron. Agents may maintain its loading, validation, preview, synchronization, and deployment path, but must not draft or rewrite content/about.md unless Cameron supplies exact text or explicitly asks for a mechanical edit.

Knowledge and NOW: reviewed Git Markdown #

Reviewed Knowledge entries and NOW live in knowledge/published/. The privacy, review, projection, and receipt contract is documented in public-knowledge.md.

Automatic worker #

cameron-site-content-sync.service is the operational entry point for the deployment and projection worker. Start it manually with:

systemctl --user start cameron-site-content-sync.service
systemctl --user show cameron-site-content-sync.service \
  --property=ActiveState,SubState,Result,ExecMainStatus --no-pager

The service loads the private worker environment and runs scripts/sync-git-backed-content-from-origin.sh for the Git-backed surfaces only: About, Knowledge, NOW, and site code. The script is an implementation detail, not the normal shell entry point. A credential-dark direct run can deploy Fly and then fail before PDS reconciliation. Neither path reads, snapshots, compiles, writes, or reconciles Blog records.

The user unit enters through a stable installed runner and operates on the dedicated clone at ~/.local/share/cameron-site/deploy-checkout. The development clone is never its working tree. Install or refresh the runner and units with:

deploy/systemd/install-content-sync-worker.sh

The installer does not deploy. The worker later takes process locks, recovers interrupted receipt pushes, fast-forwards its clean checkout, installs exact locked dependencies when their fingerprint changes, runs the repository gates, deploys changed source to Fly, reconciles About and Knowledge with CID guards, commits only their receipt manifests, and writes a credential-free completion receipt under ~/.local/state/cameron-site/.

The service verifies that the PDS credential exists, then removes it from the worker environment before dependency installation, tests, Git operations, and Fly deployment. Only the two bounded ATProto apply subprocesses receive it. Read-only plans and failed test diagnostics remain credential-dark.

The installed user timer runs every 15 minutes from deploy/systemd/.