Repository Migration

Repository migration

The selected target is jack0682/RobotTransformation for current product development, with rx_docs retained and reorganized for evidence and historical material. This page describes the approved direction and gate definitions. The current verified execution checkpoint is recorded below; cutover has not completed.

Verified execution checkpoint — 2026-10-07

M0 preservation, M1 signed bootstrap/governance, M2 exact source import, M3 full required CI and M4 canonical documentation/evidence ownership have passed their technical checks. Issue #1 records preservation limits; its acceptance field is not fabricated from agent verification.

• PR #3: 1,718 source leaves imported with exact blob bytes and modes.
• PR #4: full Rust, clients, UI, native refusal, signing, integrity, compiled identity and same-candidate/old-pinned skills checks on isolated Linux runners.
• PR #5: canonical documentation at 6950d1e35f2b729c5d55877d74127fea529cf95c, with unchanged hash-bound bytes and exact historical origins.
• rx_docs #118: original rejected-CP2 diagnosis published unchanged.
• rx_docs #119: evidence charter and ownership guidance; original normative documents and Run records preserved.

M5 SDK/distribution work is being prepared. T1 cutover, T2 layout and the bounded M8 implementation remain incomplete. main has not been promoted, P/S have not been archived, and original CP2 acceptance is unchanged.

History and source policy

The new repository starts a new signed history: a signed bootstrap followed by signed snapshot import of approved source revisions. Old commit objects are not rewritten or presented as newly signed commits.

The existing rx-platform and rx-solutions repositories preserve their original history, tags, signatures, PRs, and URLs. Verified preservation bundles provide an additional recovery copy. Unmerged branches, uncommitted changes, and local evidence are inventoried separately; they are not silently promoted into the imported product baseline.

The new repository has no inherited historical DCO exceptions. Historical incident ledgers remain provenance records for the repositories to which they apply. The new signed history follows its own contribution checks.

Sequence

Step	Planned result	Stop condition
M0	Preservation inventory and recovery checks before changes.	Missing source/WIP/evidence, unresolved identity, or an unverified backup.
M1	Signed repository bootstrap and initial governance.	Missing signature/signoff, incorrect ownership, or unreviewed public settings.
M2	Approved source snapshot import with component provenance.	Unexpected file, mode, content, license, or dependency difference.
M3	Required CI and root orchestration operate on imported component subtrees.	A former integrity gate is absent, weaker, or reports success after a required child failed.
M4	Current docs and contracts have one declared owner; links and compatibility material are reconciled.	Broken historical meaning, silently changed frozen bytes, or unresolved canonical ownership.
M5	SDK artifacts and isolated consumer verification are available for the declared release scope.	Consumer requires unpublished source, artifact provenance is incomplete, or compatibility is unverified.
M6 / T1	Accepted product-development cutover, followed by old P/S repository archive.	WIP is unpreserved, required release/acceptance is missing, or existing links fail preservation checks.
M7 / T2	Separately reviewed internal layout transition.	Unaccounted identity changes or unsupported reuse of old reviews/qualification.

M8 boundary improvements are later work. They are not a hidden prerequisite for importing the existing implementation.

Preserve the first imported layout

The initial import preserves each component's internal relative layout, Cargo workspaces and lockfiles, SDK inventory, and runtime state formats. A single Git root does not require a single Cargo workspace, a single runtime process, or a single release binary.

Root CI must explicitly select component working directories, cache paths, source contexts, and SDK comparison inputs. Source export records repository + commit + component path + tree identity + file inventory. The exporter selects its component tree explicitly so packaging does not depend on the caller's working-directory assumptions.

Internal layout changes and SDK source-copy removal follow separate gates. Source-based identities can include file paths, Cargo metadata, SDK inventory, and compiler/validator source text. A move with unchanged operational intent can still change an artifact identity and require fresh review or qualification. See Architecture map.

Documents, links, and the compatibility projection

M4 moved current canonical product documentation into docs/ and semantic contracts into contracts/semantic/ and contracts/cell-operations/. Historical documents and evidence stay in rx_docs. Follow Home for the verified canonical checkpoint and current navigation.

Ordinary current-document links are corrected to their new owners. Historical references retain their original repository, commit, path, and meaning. Frozen hash-bound documents are not casually edited to repair relative navigation.

M4 retains two exact historical JSON files totaling 2,852 bytes and adds two navigation-only Markdown pages totaling 1,308 bytes for the uneditable relative links in the hash-bound workflow README. Their exact paths and hashes are checked in the canonical document map. The Markdown pages route to current and historical documents; they are not content mirrors or normative replacements. This finite compatibility set is not a second writable evidence store.

CP2 and rollback

The preserved CP2 environment remains separate from migration builds and installations. Repository work does not authorize restarting it, replacing binaries, releasing held resources, retrying uncertain work, or changing request identity to obtain a passing result.

Before T1, the old product repositories remain the existing source baseline. If a migration gate fails, stop at that gate and repair or revert the new migration change. After T1, undoing a source change remains a reviewed source operation; it does not automatically roll back runtime data or qualification. Old binaries, packages, and identity records remain available for interpreting their historical evidence.

P/S archive is the final T1 action after the accepted cutover. Archiving preserves the repositories and their URLs; deletion, history rewrite, and renaming are outside this plan.