We are building a tool on this SaaS system for streamlining content migration.
This is a comprehensive feature and will consist on multiple parts. 
When building new functionality always follow existing patterns - especially in UI. Aspects like font-sizes being defined using .rems() mixin and using colour variables
When adding ui components always check if they actually exist - you have added non-existing loader/spinner components multiple times.
When working with data models always check structure - we do not need you hallucinating and assuming some fields exist when you have access to the structure

Build will primarily impact backend-ui, backend-api and backend-api/packages/mercury-data-models, but there also might be some aspects in frontend-api.
Work needs to be done on git branches. when proceeding to the next step, each of the aformentioned locations needs to be switched to the next branch.
e.g. if we start on branch content-migration-1 and finalise tasks from the first file, then after I have reviewed and approved functionality and ask 
to proceed with next step you need to switch to a new sub-brahch content-migration-2 for all affected repositories

The system needs to be available in site settings section, but only if site is not live. Once site is marked as live (live_at),
access to this section is no longer possible. 

Do not hallucinate or assume functionality, if it is unclear ask me.
