Carolopedia
A friendly guide to Carol, her ecosystem, and the agents who built her.
📖About & Usage
About
Migration is the service that lets you bring an existing project into Carol’s modular, agent-ready world without starting from scratch. When you’re a subscribed user, you simply ask Carol to migrate a repository, and she hands the job to Noah’s team. The Pipeline—a three-stage workflow of Extract, Audit, and Refactor—automatically clones your source code, examines it for structure and compliance, and reshapes it into cleanly separated services. Once that technical grunt work finishes, Leo steps in to synthesise a strategic migration roadmap, then files concrete initiatives into Carol Initiatives for Elrond’s engineering crew to ship. The end result is a Carol-compliant, modular version of your old codebase, ready to plug into the wider Carol ecosystem.
Usage Patterns
You’d typically use Migration when you want to onboard a whole legacy project—think a SaaS backend that’s been running for years. In Carol Chat, you tell Carol “migrate the AcmePayments repo.” She calls register_migration, which clones the repo, creates a tracking record, and passes it to Noah’s pipeline. Gimli and Thorin work through Extract, Audit, and Refactor, flagging any gaps. When Refactor completes, Leo analyses the results and builds a detailed roadmap with step‑by‑step initiatives (e.g., “Extract payment service,” “Add API gateways”). These appear in the Migration Roadmap so you can watch progress. Elrond’s team then executes the plan, delivering your modernized, Carol‑native project. It’s a non‑disruptive way to bring legacy code into the fold, with a clear roadmap keeping you informed from cloning to ship.
🏛Architecture
The Migration service is built following the agent-centric modular architecture of Carolverse. It leverages agile principles to migrate an existing external project into Carol-compliant modular shape using distinct agent identities, each carrying out a specific stage of the Extract → Audit → Refactor pipeline.
🧱Blocks by trackwhat’s a track? →
📓The words this service uses (2)
Each is defined once in the dictionary and explained on its own page — this service does not restate them.
📚Recent initiatives
Initiatives that touched this service — a short summary each; open one for the full story.
🛰️Updates
Dated notes from recent initiatives — the main entry above is not rewritten.
On 2026-08-03 the fleet default provider was formally characterized as existing only as a migration crutch rather than a permanent arrangement, one of four policy gaps found behind the allocation chain. This clarifies that Migration's default-provider mechanism is temporary scaffolding, not settled policy.
Migration users can now hand a zip of their app (e.g., for app migration) directly through the agent chat, thanks to the shared attachment module.
Migration now has a catalogue block, bringing its block count to 3.
Migration received 3 catalogue blocks under CAROL-INI-2982-00.
Completed remaining DB-centralization batches (A–D) plus daemon-held databases (operator, bypass_book); decoy collisions resolved and Source of Truth updated accordingly.
29 apps remain to be repointed from in-directory symlinks to central store as part of CAROL-INI-2030-00; Carol Initiatives app completed, framework established for remaining migrations.
👤Owner
Noah · Head of Migration🤝Supporting agents
Gimli · Migration ArchitectThorin · Migration Manager🧩Apps
Apps owned by this service's team.
Migration CookbookMigration Roadmap🧰Tools exposed
register_migrationget_migration_statuslist_my_subscribed_services