Handbook

The engineering handbook for Curate — architecture, environments, onboarding and how-tos. Access-gated; not public.

Start here if Curate is new to you:

• System overview — what Curate is, and how the running system fits together
• Repo tour — the four repos and what each one holds
• Environments — hostnames, deploy paths, and why staging is disposable

Those three pages are the day-one read. Everything below them is depth, and most of it still lives next to the code it describes.

Today’s source of record

Working docs live in the repo where the work happens, so a doc rides the same merge request as the change that invalidates it.

curate-server is the command centre: infrastructure, backend, and the plans that coordinate all four repos.

Still to land here

The Super Admin manual (the platform role, so it belongs on this site rather than in the public guides) and the translator’s glossary of role names. Both are still in the retired curate-documentation repo, pending a drafting pass.

How this handbook works

The home of record for everything on this site is curate-server/docs/. Pages here are authored views — organized for reading, not mirrored files — and if this site and current curate-server/docs disagree, the repo wins. Three things follow:

• curate-server/docs/ moves fast and reorganizes freely; this site is updated in deliberate passes, not per-commit.
• The gap between the two is tracked by one watermark: .docs-synced at the curate-content repo root — the curate-server commit this site last absorbed. From curate-server, make docs-drift prints how many docs commits the site hasn’t seen, and which ones.
• A stale site isn’t an error — it’s a visible, counted gap until the next update pass, which ends with make docs-mark and committing the bumped watermark alongside the page updates it accounts for.

The full rationale and decision history: curate-server docs/MIGRATION-PLAN.md §9.