Путь репозитория имеет смысл только на машине, которой принадлежит. На ноутбуке и сервере могут быть папки demo, но открытие одной не должно незаметно выбирать другую. Изменения, включённые в Genesis main 9 ноября 2026 года, заменяют учёт недавних проектов в Projects реестром в базе данных и проводят активацию через выбранный узел. Интеграция Projects

Папки проектов в отдельных шкафах для разных хостов с соответствующими метками реестра

Идентичность, сохраняющаяся при повторном открытии

Virtual Context Tree, или VCT, связывает абсолютный путь ОС с канонической точкой, например vct:///projects/demo. Mount — это соответствие, записывающее точку, путь, отображаемое имя и время последнего открытия. Оно даёт навигации стабильную идентичность без перемещения репозитория и без создания монтирования файловой системы. Реализация реестра

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

Постоянное хранение теперь находится в SQLite-таблице vct_mounts хранилища задач. Процесс VCT держит кэш чтения: изменение сначала атомарно записывает всю таблицу, затем меняет кэш. При ошибке сохранения возвращается ошибка, а прежнее состояние остаётся. Успешное изменение отправляет уведомление с узлом, связывая сохранённую идентичность с обновлением интерфейса.

Реестр ограничен: по умолчанию сохраняются 100 новейших mounts, а при превышении удаляются самые старые. Это рабочая навигационная запись, а не безграничный архив всех когда-либо открытых репозиториев. Хранение и ёмкость

Искать и открывать по одним данным

Страница Projects и палитра проектов используют зарегистрированные mounts. Открытие или создание вызывает учитывающий узел интерфейс mount_project, затем перечитывает список. Подсказки сначала ищут введённый текст в зарегистрированных путях без учёта регистра, затем добавляют варианты по префиксу файловой системы и убирают повторы. Знакомого фрагмента пути достаточно для поиска без повторного обхода родительского каталога. Изменения навигации

VCT-точка активного проекта для отображения находится в уже загруженных mounts. Ради подписи новый проект не регистрируется. Забывание проекта удаляет запись реестра, но не файлы репозитория. Это отделяет навигацию от изменений самой работы.

Сохранять выбранный хост в пути выполнения

Представим разработчика с локальным demo и ещё одним на SSH-сервере. Выбор удалённого хоста загружает его список. Пока соединение устанавливается, список пуст, а локальные записи не предлагаются как удалённые проекты. Активация тоже ждёт готовности соединения, чтобы запрос к серверу не выполнился на пока ещё локальном узле. Удалённая загрузка и активация

Удалённые пути трактуются по правилам выбранного хоста, включая поддерживаемые абсолютные POSIX- и Windows-пути. Активация асинхронна, поэтому проверка каталогов и регистрация не блокируют LiveView. Последующее исправление правильно разворачивает результат удалённого mount, чтобы проект получил свою VCT-точку. Исправление удалённого mount

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

Осознанно перенести старые записи

В сборках разработки с этими изменениями миграция создаёт VCT mounts из пригодных старых строк projects, сохраняет непустые имена и разрешает совпадения последних имён. Остаются 100 новейших записей. Пустые и относительные пути журналируются и пропускаются. Если старую таблицу прочитать нельзя, миграция прерывается и откатывается, сохраняя таблицу и строки, вместо трактовки ошибки как пустого списка. Защита миграции и тесты upstream

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

Эта работа показывает границу проекта уже при выборе места работы. О разделении историй кода читайте в статье Genesis с несколькими репозиториями: одна цель, отдельные истории.

← Вернуться к новостямНаверх ↑