path-types

Навык path-types из открытого репозитория Codex задаёт правила выбора типов для путей в Rust-кодовой базе. Его задача не в том, чтобы автоматически переписать проект, а в том, чтобы дать разработчику устойчивую модель границ между протоколом, локальной файловой системой и данными, которые видит модель. Источник рекомендует рассматривать миграцию к URI как постепенный процесс и выбирать тип с учётом конкретного слоя, а не заменять все строки одним универсальным типом. На границе app-server, где нужно сохранить обратную совместимость с существующими клиентами, следует использовать LegacyAppPathString. После входа в эту границу значение переводится в PathUri и далее обрабатывается как URI. Для exec-server протокол должен использовать PathUri, а во внутренней логике допускаются PathUri или AbsolutePathBuf в зависимости от того, нужен ли переносимый URI или путь, относящийся к локальному хосту. Общие зависимости, которыми пользуются оба сервера, должны опираться на PathUri либо на разделённые API, не смешивающие эти сценарии. Аргументы инструментов, которые генерирует модель, наоборот, следует десериализовать как обычные String и обрабатывать правила пути в коде конкретной функции. Такая схема полезна при изменениях протокола, добавлении новых полей с путями и ревью миграции от native-path strings к URI. Она сохраняет возможность старым app-server клиентам отправлять и получать прежний формат, позволяет app-server хранить URI для чужой платформы и оставляет exec-server API в формате file:// URI. Локальная работа не должна менять текст, который видит модель. Анализ пути должен работать ещё до запуска связанного окружения, потому что ранняя валидация не должна зависеть от уже поднятого executor. Источник отдельно фиксирует ограничения, которые легко нарушить при поспешной миграции. URI не кодирует соглашение о путях или операционную систему executor, поэтому пользователю не следует предлагать отдельную настройку OS/path convention. URI пока не нужно сохранять в rollouts, базах данных и другом постоянном хранилище. Модельные аргументы могут содержать относительные и абсолютные пути разных ОС, и этот случай нельзя свести к одному локальному предположению. Ошибки преобразования должны обрабатываться по риску: для security-relevant paths нужен fail-closed, а для UI и диагностики допустим fail-open. Небольшие сфокусированные методы на PathUri или LegacyAppPathString предпочтительнее локальных helper-функций, а в диагностике PathUri следует показывать как URI. Итоговый критерий хорошей миграции — минимум новых отказов и ясная граница типов, а не формальная замена каждого поля без проверки обратной совместимости.