Миграция проекта в .AI

Когда применять

Пользователь запускает /migrate, выбирает навык migrate или просит перевести текущего клиента на универсальную структуру .AI. Учитывай его уточнения и уже выданное разрешение. Работай из корня выбранного клиента; контейнер Work и соседних клиентов не сканируй.

Когда НЕ применять

Обновление обычных файлов канона, миграция базы данных или кода продукта, создание нового клиента. Наличие .claude само по себе не означает запрос на перенос.

Запуск

До чтения legacy registry/inventory и загрузки canonical package установи достоверность среды по Linux mountguard процедуры. Если mountinfo недоступен/невалиден либо relevant metadata/перемещаемый путь смонтирован, не используй masked данные для выбора config/source: возьми подтвержденные сведения из задачи или retained handoff и перейди к terminal-маршруту процедуры. Это не вывод о происхождении mounts. При собственном pending migration используй исходный handoff/tools/provenance offline; неизвестная provenance, чужой или несколько journals останавливают маршрут до выбора нового поколения.

1. Если пользователь явно предоставил bundle, прочитай migrations/ai-layout.prompt.md из этого пакета и выполни его в текущей сессии, используя три sibling tools из того же пакета одного поколения по его контракту. HTTP-адрес и сеть для этого маршрута не нужны; шаг 2 пропусти. Отсутствующий или пустой промт - остановка с диагностикой, без поиска другого пакета.
2. Иначе найди HTTP-источник канона без вопросов, если он уже известен: явный источник пользователя, иначе canon.raw_base в .claude/canon.yaml, иначе HTTPS source.base в .AI/canon/canon.state.json. Если после миграции источник был офлайн-пакетом, адрес может сохраниться в .ai-bootstrap/legacy/.claude/canon.yaml. Читать архив допустимо; менять его нельзя. Не принимай filesystem-путь за HTTP-источник и не ищи локальный клон канона. Если источник неизвестен или файл неоднозначен, спроси только недостающий адрес. Получи <canon_base>/migrations/ai-layout.prompt.md точными байтами по HTTP и выполни его в текущей сессии. При сетевом отказе, отсутствующем или пустом промте остановись с диагностикой. Не заменяй источник соседним проектом, локальным клоном или другим репозиторием.
3. До legacy inventory и canonical package проверь достоверность среды по mountguard процедуры. Relevant mounts и отказ чтения mountinfo ведут к handoff вне клиента: сама процедура готовит одну команду обычного терминала с matching разрешением. Не выводи host-отсутствие из tmpfs/ro, не удаляй .agents и не снимай policy. Нормальная среда сохраняет прежний маршрут без обязательного терминала.
4. Вся механика переноса, проверки журналов, закрепления SHA, выбора UUID, типов и адаптеров, сохранения памяти, локальных навыков и backup живет в полученной процедуре. Не переписывай ее здесь или в собственной shell-команде; не запускай legacy sync перед миграцией. Сначала процедура определяет, нужен ли перенос, recovery или только проверка уже завершенного состояния.
5. Покажи пользователю короткий план обычным текстом: какая папка, что будет перенесено, что сохранится локально, где backup и что требует отдельного подключения. JSON CLI преобразуй в объяснение; не заставляй пользователя выбирать UUID, копировать SHA или собирать команды. Уточняй только действительно недостающие решения. Применяй конкретный план по разрешению пользователя согласно процедуре; ранее выданное разрешение повторно не запрашивай. После terminal-выполнения проверь собственную квитанцию, root/UUID/request hash и project/state согласно процедуре, затем подхвати файловую задачу. Ошибка, чужой результат или неизвестная provenance не означают успех; recovery только исходными сохраненными tools offline. В конце сообщи результат check и следующий шаг.

В старом проекте навык доставляется в .claude/skills/migrate/; в новом источник - .AI/skills/migrate/, адаптеры предоставляют совместимые пути. Не создавай .agents в legacy-проекте ради видимости навыка в Codex: это мешает поддержанной миграции. Если клиент еще не обнаруживает навык, его можно явно прочитать по локальному пути. Это не объявляет /migrate встроенной командой каждого вендора.

Модель и текущие назначения

Перед новым заданием и запуском применяй маршрутизацию моделей: свежий MODELS выше канонического дефолта. Границы данных и полномочий этого навыка сохраняются.