A repository consolidation is complete when a clean checkout reproduces every in-scope project, boundary and CI checks pass, accepted history queries work, and each deployment owner can identify the canonical path.
Turn the old repositories into test cases
Before moving code, list the behavior each source repository must contribute. Include installation, local startup, production build, unit and integration tests, generated clients, packaging, release commands, and deployment preparation. Capture the environment and secret assumptions without copying secrets into the test record. This baseline lets the team distinguish migration defects from failures that already existed.
Select representative acceptance cases for every deployable unit and shared library. A service may need a health response and contract test, while a package may need a consumer build and published artifact check. The scope should state which existing failures are accepted as inherited debt. Otherwise the conversion can become an open-ended repair project.
Test the workspace as one system
Clone the target repository into an empty environment and install only from committed manifests and lockfiles. Run root commands and direct package commands, then verify that dependency boundaries match the approved map. An accidental import can make the build pass while coupling projects that were supposed to remain independent, so boundary checks belong beside ordinary tests.
CI should run the correct work for a change. Nx documents affected-task detection as a way to limit builds and tests to projects influenced by a change. Whatever tool is chosen, test a shared-library change, an isolated application change, and a configuration change. The evidence should show which jobs ran and why.
Record ownership and release acceptance
Every application and package needs an owner, build command, test command, and release or deployment path. Reviewers should be able to start from the repository root and locate those facts without relying on the migration author. Run one production-shaped release preparation for each in-scope deployable unit, stopping before an external release unless the buyer explicitly authorizes it.
Reality Contact, LLC prepares the technical checks and records the results. The buyer approves inherited failures, package boundaries, credentials, environments, and every production release. The final acceptance record should link the target commit, test outputs, exceptions, preserved-history checks, and named ownership so the canonical designation is reproducible.
Where the service stops
Reality Contact, LLC performs the scoped repository conversion and prepares technical evidence, but the buyer owns source rights, licensing decisions, repository access, product behavior, deployment authority, and final acceptance of the canonical branch. The buyer approves the package and history map, reviews the acceptance record, designates the canonical repository, and moves active development and deployment ownership to it. This is technical implementation and documentation based on buyer-authorized repositories, and it does not replace legal, security, licensing, compliance, or professional advice. The buyer controls source rights, credentials, branch protection, history policy, acceptance cases, deployment authority, and every production release.
Sources: Nx documentation for affected CI tasks; SonarQube documentation for quality gates.