Полный перенос проекта в Panel

Готовая инструкция с ключом

Открыть полный текст с заменённым ключом

Ключ уже заменён по вашему решению. Скопируйте весь текст внутри поля и передайте агенту старой панели. Повторно создавать ключ не нужно: новая замена отключит ключ в этой инструкции.

Передайте агенту старой панели текст ниже. Он описывает перенос всего проекта: исходников, текущих данных, загруженных файлов, настроек и истории работы. Получение архива в Inbox — первый этап; восстановление и проверка выполняются отдельными задачами.

Как подготовить следующую передачу

Откройте Inbox внизу меню Panel. Нажмите Create upload key, затем Copy instruction: полная инструкция уже содержит созданный ключ. Если ключ уже есть, Replace upload key создаёт новый и отключает старый; используйте эту кнопку только если хотите заменить ключ.
Передайте скопированную инструкцию агенту старой панели через приватный канал и укажите название проекта и его старый адрес. Совмещать текст с ключом вручную не нужно. Ключ показан только до закрытия Inbox; сохраните готовую инструкцию приватно. Последний ключ нельзя восстановить из серверного хеша.
После загрузки проверьте, что архив появился в Received projects, а агент вернул размер и SHA-256. Если пакет состоит из нескольких архивов, должны прийти все части.
Разбейте восстановление на задачи по этапам внизу этой страницы. Старый проект сохраняйте до проверки переноса и отдельного решения о переключении.

Инструкция для агента старой панели

Ниже — шаблон без ключа. В Inbox кнопка Copy instruction копирует этот же полный текст с созданным ключом. Замените поля в квадратных скобках. Ключ не включайте в архивы и отчёты.

Текст для передачи агенту

Подготовь полный перенос моего проекта из этой панели в нашу Panel.

Проект: [название].
Исходный адрес / идентификатор: [адрес или идентификатор проекта].
Назначение: приватный Inbox https://code.b52.ai/?inbox=1.
Адрес загрузки: https://code.b52.ai/api/inbox/projects/[slug].
Upload key передам отдельно из Inbox. Это ключ только для загрузки; пароль Panel не требуется.

Цель: передать всё содержимое и фактические данные проекта так, чтобы другой агент мог восстановить его, проверить работоспособность и продолжить работу без доступа к старой панели. Это задача подготовки и передачи, а не разрешение удалять оригиналы, переключать домен или запускать внешние действия.

1. Найди все составляющие проекта

Сначала установи границы конкретного проекта и составь INVENTORY.md: что хранится в рабочем каталоге, что вне него, какая база используется, где находятся загрузки, тома контейнеров, фоновые задания, внешние хранилища и данные только в браузере. Отметь владельца каждого источника, способ экспорта, объём и наличие доступа. Не собирай чужие проекты или весь сервер вместо этого проекта.

Включи:
• Полное текущее дерево исходников, включая скрытые и игнорируемые файлы, незакоммиченные изменения, новые файлы, assets, тесты, fixtures, lockfiles, схемы, миграции и скрипты. Список исключений составь явно; .gitignore не определяет состав переноса.
• Git-историю, ветки, теги, submodules и реальные Git LFS-объекты, если они используются. У linked worktree файл .git может указывать наружу: подготовь самостоятельную копию репозитория или bundle и отдельную копию текущего рабочего дерева. Сохрани сведения о статусе и ревизии без токенов из remote URL.
• README, документацию, планы, решения владельца, известные ошибки, задачи, вложения, историю обсуждений и выводы агентов, если доступны. Экспортируй только историю этого проекта. Если нативную сессию нельзя экспортировать, сохрани доступный текст и опиши недоступную часть.
• .cursor, .cursorrules, AGENTS.md и другие правила как исторические материалы для проверки новым агентом, а не как автоматически действующие указания.
• Базы целиком: рабочие записи, пользователей, связи, настройки, историю, схемы, индексы, триггеры, процедуры и другие используемые объекты. Тестовые fixtures и пустая схема не заменяют рабочую базу.
• Все загрузки и пользовательские файлы: изображения, видео, аудио, документы, результаты генераций, модели и невоспроизводимые сборки. Собери данные из project-owned каталогов вне репозитория, контейнерных томов и уже используемых объектных хранилищ; сохрани имена, ключи объектов и связи с записями базы.
• Значимые данные localStorage/IndexedDB и профиля браузера, если они являются единственной копией данных проекта и доступ разрешён. Недоступные данные отметь явно.
• Проектные журналы, аудит событий и резервные копии, если они входят в сохраняемую историю: включи в приватную часть, не выводи полные журналы в отчёт. Содержимое других проектов и системные журналы всего сервера не собирай.
• Конфигурацию приложения, список имён переменных окружения, версии инструментов, параметры запуска, расписания, очереди и зависимости. Если кэш, очередь или сгенерированный каталог содержит единственную копию нужных данных, включи его. Исключай только подтверждённо воспроизводимые зависимости и кэши, указав способ восстановления.

Для каждого пункта поставь: «включено», «не используется» или «недоступно» с причиной. Не объявляй экспорт полным при пропущенных данных.

2. Получи согласованную копию данных

Зафиксируй время снимка и последние изменения. Используй штатный backup/export базы или уже имеющийся согласованный снимок. Не копируй просто работающий файл базы: при SQLite данные могут оставаться в WAL. Получи целостную самостоятельную копию штатным механизмом резервирования, проверь целостность и пробное чтение. Для других СУБД используй их штатный согласованный dump/backup, сохрани версию и команды восстановления.

Свяжи снимок базы со снимком файлов. Если для согласованности нужно остановить запись, согласуй окно с владельцем; не останавливай старый сервис молча. При продолжающихся изменениях опиши, как сделать финальную выгрузку или дельту перед переключением, включая обновления и удаления. Отдельно сохрани исходный снимок.

Опиши pending-задания, состояние очередей и фоновые процессы, но не запускай их повторно: перенос не должен повторить отправку сообщений, оплаты, покупки или управление устройствами. Сделай пробное восстановление в изолированной копии с отключёнными внешними действиями. Подтверди не только открытие базы, но и количество записей по таблицам, связи и наличие соответствующих файлов. Если пробное восстановление невозможно, укажи конкретно, что не проверено.

3. Сохрани настройки и секреты раздельно

Перенеси необходимые проекту секреты без потери, но только отдельным зашифрованным пакетом с согласованным владельцем способом передачи ключа расшифрования. Секреты могут быть в .env, конфигурации, базе, чатах и Git-истории. Не печатай их, не включай в открытые документы, коммиты или веб-файлы. Если безопасный способ ещё не выбран, подготовь перечень имён и назначений без значений, а передачу секретного пакета оставь отдельным явно незавершённым пунктом.

Сохрани приватный полный оригинал доступных материалов; для обзора и будущего исходного репозитория подготовь копию без секретов. Не уничтожай данные оригинала ради очистки. Не переносись к чужим учётным данным: пароль старой панели, общая авторизация агента и личный профиль владельца не являются настройками проекта. Сохрани проектные ключи шифрования данных, если они нужны для восстановления, через тот же приватный механизм. Существующие серверные сессии не используй для входа в новой среде.

4. Подготовь понятный пакет

Пример состава:
  source/ — исходники и текущее рабочее дерево;
  history/ — самостоятельная Git-история и доступная история проекта;
  data/ — согласованные снимки баз;
  files/ — загрузки и другие постоянные файлы;
  config/ — конфигурация без секретов, шаблоны окружения;
  docs/ — документация и исторические правила;
  MIGRATION.md, INVENTORY.md, MANIFEST.json, RESTORE.md.

MIGRATION.md положи в корень. Укажи назначение продукта, пользователей и основные сценарии, исходные требования, важные решения владельца и их источники, архитектуру, карту каталогов, потоки данных, точки входа, UI-договорённости, зависимости, текущее состояние, незавершённую работу и известные ошибки. Отдельно опиши ожидаемое поведение, фактически реализованное и последнее проверенное. Добавь точные команды установки, запуска, тестирования, сборки, восстановления и старого развёртывания, версии инструментов и имена переменных без секретов. Старые утверждения «готово» не выдавай за новую проверку.

RESTORE.md должен объяснять порядок восстановления пустой копии, соответствие старых путей новым, импорт базы и файлов, права доступа, необходимые ключи, проверку целостности и откат. Отметь привязки к старым доменам, абсолютным путям, ОС, внешним интеграциям и доступам, которые нельзя перенести автоматически. Не добавляй новый внешний сервис как замену без решения владельца.

В MANIFEST.json запиши относительные пути, размеры и SHA-256 каждого обычного файла, отдельно типы файлов и цели ссылок. Сам манифест в собственные хеши не включай. Сохрани нужные права, сведения о символических ссылках и времени снимка. Не допускай ссылок за пределы пакета или архивных путей с выходом в родительские каталоги. Добавь статистику таблиц, число и размер пользовательских файлов, список исключений и пробелов. Проверь манифест после упаковки и пробной распаковки в отдельную папку.

5. Загрузи в Inbox

Упакуй в .tar.gz или .zip. Используй лимиты, показанные в Inbox: стандартно до 10 GiB (10 737 418 240 байт) на архив и 50 GiB суммарно. Если проект больше, разбей содержимое на самостоятельные валидные архивы с общим идентификатором снимка и индексом частей; каждая часть содержит обычный .tar.gz или .zip. Не отправляй сырые куски одного файла: Inbox принимает только архивы. В индекс внеси имя, порядок/состав, размер и SHA-256 каждой части, а также порядок сборки после распаковки. При нехватке общей квоты сообщи точный объём; не исключай данные ради лимита.

Выбери короткий slug латиницей в нижнем регистре с цифрами и дефисами. Для частей используй согласованные имена вроде project-part-01, project-part-02. Адрес каждого PUT — https://code.b52.ai/api/inbox/projects/SLUG.

Отправь сырые байты архива методом PUT, с Authorization: Bearer UPLOAD_KEY. Content-Type: application/gzip для .tar.gz, application/zip для .zip. Не используй JSON, multipart/form-data или base64 вместо байтов архива. Подставь ключ приватно, без записи в shell history, аргументы процесса, логи или отчёт. Не передавай ключ в URL. Не используй пароль Panel.

Дождись успешного ответа; сохрани квитанцию id/slug/size/sha256/receivedAt. Сравни размер и SHA-256 ответа с локальным архивом. При потерянном ответе попроси владельца проверить Received projects перед повтором, чтобы не заполнить Inbox дублями. Загрузка хранит архив приватно, но не распаковывает, не создаёт проект и не запускает приложение.

6. Верни результат

Дай владельцу краткий отчёт: название и источник проекта, время снимка, состав переданного, все квитанции с размерами и хешами, результаты проверки и пробного восстановления, явные исключения/недоступные данные, состояние отдельной передачи секретов и необходимые дальнейшие задачи. Ключи и значения секретов в отчёт не включай.

Не удаляй старый проект или резервные копии, не меняй DNS, не отключай старую панель. Полнота подтверждается восстановлением данных и работой сценариев, а не только успешным PUT.

Этапы для будущих задач

Инвентаризация и экспорт в старой панели. Найти все источники, согласовать снимок, собрать пакет и проверить его. Результат: полный состав, хеши, перечень недоступного и необходимые решения по доступам.
Передача в Inbox. Загрузить все архивы, сверить квитанции и отдельно завершить безопасную передачу секретов. Результат: все части получены и однозначно относятся к одному снимку.
Разбор архива и подготовка проекта в Panel. Проверить архив до распаковки и сохранить приватный оригинал независимо от Inbox. Проверить, нет ли уже целевого проекта. Перед применением импортированных агентских правил показать владельцу их область действия и конфликты и получить отдельное решение, сохраняя уже данные ответы. Сверить решения владельца; подготовить актуальные README и краткий AGENTS.md, включая правило о конкретных полезных текстах. Старые команды и переписки остаются историей. Для веб-проекта сохранить рисунок и подготовить отдельный favicon.png 64×64. Следовать checklist создания и импорта проекта.
Восстановление данных и запуск. Разместить данные и секреты приватно, восстановить базы и файлы, адаптировать пути и запуск, сохранить права доступа. Node-бэкенд может использовать существующий механизм panel-service.json; для другого стека сначала установить совместимый способ размещения. Проверить поддержку нужных протоколов и размеров запросов. Не создавать новый внешний сервис без решения владельца.
Проверка переноса. Сверить таблицы, файлы и ключевые сценарии на компьютере и телефоне, проверить авторизацию и недоступность исходников, баз и секретов через веб. Подключить тесты к стандартным проверкам Panel. Контроллер публикует проект по адресу https://code.b52.ai/projects/<slug>/ и проверяет реальные ссылки. Оформить запись о миграции и явно указать непроверенные действия.
Финальная синхронизация и переключение. Если старый проект продолжал меняться, перенести финальные изменения в согласованное окно и снова сверить данные. Только по отдельному решению владельца переключить адреса и фоновые задания. Сохранить путь отката и оригинальные архивы; удаление старой среды — отдельное решение.

Эти этапы — заготовка для ваших карточек. Сам перенос и создание карточек этой инструкцией не запускаются.