# 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`](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:

```bash
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:

```bash
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/`.