Content Ownership Boundary

📌 Rule of thumb: every piece of documentation has exactly one home. If the same content is maintained by hand in both the starter repository and this site, that is a bug — assign it one home.

The Boundary

The starter repository owns adopter-clone content

The starter’s docs/ is canonical for everything that must ship inside adopter clones so agents and developers have context offline:

Implementation guides
Prompt libraries
Patterns
Architecture Decision Records (ADRs)

Edit these in the starter repository. Never edit their published copies here.

This site owns human onboarding

This docs site is canonical for the pages that exist to onboard humans to a product from the web:

Launch demo and quick deploy guides
Tracks (MVP / Showcase) and their comparison
FAQ
Site-level pages (product picker, this page)

These have no copy in the starter; edit them here.

Dual-Homed Content Is Pulled, Never Pushed

Some content classes legitimately appear in both repositories. They are pulled at build time from the product repository — the historical push-based sync (ADR-008) is superseded. Currently pulled:

Content class	Pull mechanism	Enforcement
Version facts (`{{versions.*}}`)	`pnpm run update:versions` from the starter’s versions.json public contract	`drift:check` — the ADR-059 drift gate, hard CI failure
ADR files (`/astro/adr/`)	`pnpm run update:adrs` from the starter’s `docs/adr/`	`validate:adrs` — byte-for-byte freshness gate, hard CI failure

Both pipelines write committed output: builds are deterministic, diffs are reviewable, and offline or PR builds fall back to the committed copy. Both gates follow the same philosophy: a gate that cannot check must not pass, and DRIFT_SKIP=1 is the explicit local-only escape hatch.

The pull pipelines are keyed by the product registry (scripts/src/products.ts), so future products (e.g. the Go starter) pull the same way without new tooling.

What This Means in Practice

A typo in an ADR or an implementation guide? Fix it in the starter. The next update:adrs pull brings it here; editing the copy in this repo will be reverted by the pipeline and flagged by validate:adrs.
A confusing sentence in Quick Deploy or the FAQ? Fix it here.
Adding a new content class that both repos want? Decide its single home first. If it must appear in both, build a pull pipeline with a freshness gate — never copy by hand and never push.