Docs Onboarding an existing project
Onboarding an existing project
Folding an established repository into the mesh by reconciling the standard onto it, not overwriting it.
The second lifecycle runbook. It brings a project that already exists with its
own life — its own history, README, structure, and version scheme — into the
mesh for the first time. The end state is the same as a greenfield setup; the
difference is purely the path. The canonical machine copy lives in the repository
at hub/standards/onboarding-existing-project.md; this page is the readable
summary.
The governing rule
Reconcile, don’t overwrite. An established repository already encodes decisions — a version number, a branch model, a README, maybe its own docs. The standard is folded around those, keeping what is good and recording any deliberate divergence. A blind template copy that flattens existing work is the failure mode this runbook exists to prevent.
The path
Survey what already exists before touching anything (branch model, versioning,
docs, ignores, license, CI). Adopt the dev/main model where it fits cheaply,
but don’t force a master → main rename if it would be disruptive — record
the real branch in the registry instead. Fold each template in around what is
there, seed VERSION from the project’s real version rather than resetting it,
and map existing docs into the notes system by linking rather than duplicating.
Register the project with honest adoption flags — partial adoption is normal
for an existing repository — then commit and fast-forward.
Joining the mesh is a direction, not a single switch: onboard incrementally and tighten over later passes through the adopting-updates runbook. A blank repository instead follows new-project setup.