Сценарий 13 находит использования, группирует кандидатов миграции, оценивает влияние на места вызова и предлагает порядок работ. Это поверхность класса plan-only: workflow не редактирует и не переименовывает файлы исходного кода.
Когда применять
Используйте сценарий для широкой, но конкретной миграции: переименования публичного символа, замены API или изменения сигнатуры во множестве мест. Укажите исходный и целевой символы, компонент, правило совместимости и ревизию.
Для ограниченного изменения с сохранением поведения подходит сценарий 05. Если затронуто несколько репозиториев, сначала выполните сценарий 10.
Предварительные условия и область
Привяжите запрос к принятой задаче реализации и текущей ревизии исходников. Определите исключения, сгенерированный код, требования публичной совместимости, владельцев и максимальный размер этапа.
При недоступном CPG workflow может использовать резервный список целей, извлечённый из запроса. Список уточняет область; надёжный радиус влияния подтверждается актуальным CPG.
Запуск типизированного сценария
from src.digital_employees.runtime.scenarios import (
RoleBoundScenarioInvocationRequest,
invoke_role_bound_scenario_request,
)
request = RoleBoundScenarioInvocationRequest(
query="Спланируй переименование LegacyClient в ServiceClient в ограниченном компоненте.",
employee_id="codegraph_developer",
scenario_id="scenario_13",
event_type="implementation_start",
context={
"project_key": "codegraph",
"namespace": "default",
"task_id": "<task-id>",
"source_refs": ["<revision-ref>", "<compatibility-contract-ref>"],
"file_paths": ["<bounded-source-path>"],
},
)
result = invoke_role_bound_scenario_request(request)
Неоднозначный запрос должен остановиться на уточнении. Нельзя превращать угаданную резервную цель в задачу реализации.
Как читать результат
Проверьте метаданные определения цели, найденные функции, категории мест вызова, evidence и предложенный порядок. Подтвердите каждое значимое использование в привязанной ревизии и сохраните свидетельство вызова вместе с планом.
Категории simple, signature change и complex — эвристики. Они не разрешают автоматическую замену и не подменяют анализ совместимости и тестов.
Управляемое изменение после планирования
Для каждой одобренной группы создайте отдельный этап с точной областью. Минимальные элементы контроля:
approval— разрешение ответственного человека на конкретный этап;tests— RED/GREEN-покрытие контракта и регрессий;rollback— привязанная к ревизии процедура восстановления;- профильные свидетельства архитектуры, AppSec, QA, документации и трассируемости.
Примените и проверьте один этап перед расширением миграции. Выполнение переименования подтверждается проверкой изменённых файлов и тестами.
Ошибки и восстановление
- Запрошено уточнение: укажите одну пару исходного и целевого символов и ограниченный компонент.
- CPG недоступен: пометьте резервный ответ как предварительный и восстановите привязанное к ревизии свидетельство CPG.
- Найдены неожиданные места вызова: остановите этап, обновите область и тесты, затем запросите новое одобрение.
- После этапа возникла регрессия: выполните записанный откат и сохраните свидетельство сбоя до перепланирования.
Контракт с исходным кодом
Статья привязана к следующим источникам:
src/workflow/scenarios/refactoring/mass_migration.py— определение цели, CPG-анализ, fallback, категории и план;src/digital_employees/runtime/scenarios/role_bound_scenario_invoker.py— типизированная маршрутизация;src/digital_employees/runtime/scenarios/employee_scenario_invocation.py— владелец-разработчик и условная политика.
Workflow возвращает состояние и рекомендации; этот контракт не вызывает изменение исходного кода.