Нужно изменить правило видимости архивных статей. В контроллере главной это выглядит как одно условие. Но та же выборка может использоваться в поиске, RSS, карте сайта и блоке похожих материалов. Исполнитель, который сразу исправит первый найденный запрос, способен получить правильную главную и незаметно испортить остальные страницы.
Перед такой правкой полезно отдельное исследование влияния. Его результат — короткая карта фактических связей, а не план переписывания проекта. Рассмотрим, какое поручение дать исследователю и как отличить подтверждённую карту от правдоподобного пересказа архитектуры.
Задайте вопрос с границей
«Изучи проект» не задаёт достаточной точки завершения. Агент может описать каталоги, но не обнаружить потребителя нужного условия. Более полезный вопрос: «Какие публичные выдачи используют правило опубликованности и где можно исключить архив только из свежих материалов?»
Сразу передайте ожидаемое поведение: архив должен оставаться доступным по прежнему адресу и в поиске, но не считаться свежей публикацией. Это требования задачи. Исследователь не должен выводить их из случайного состояния шаблона.
Исследуй влияние изменения выборки свежих статей.
Начни с маршрута главной и проследи запрос до модели.
Найди остальные вызовы общего условия опубликованности.
Отдельно проверь поиск, RSS, sitemap, теги и похожие материалы.
Для каждого вывода укажи файл и символ.
Правки и миграции не выполняй.
Верни подтверждённые связи, неизвестное и минимальные места изменения.Идите по коду в обе стороны
Первый проход идёт от действия пользователя к данным: маршрут, обработчик, запрос, модель, представление. Он объясняет, почему конкретная страница сейчас показывает архив. Второй проход начинается с общего условия и ищет всех потребителей. Без него карта остаётся описанием одного пути.
Названия дают подсказки, но не доказательства. Метод с именем published может проверять статус и дату, а исключение рубрики добавляться выше. Контроллер может передавать в шаблон уже готовую коллекцию. Поэтому в карте нужно указывать действующие условия, а не приписывать смысл имени.
Отдельно проверьте косвенные связи: настройки выбора рубрик, кеш готовой ленты, обработчики сохранения статьи. Если после изменения запрос правильный, а кеш ещё содержит прежнюю выдачу, пользователь продолжит видеть старый результат. Исследование должно назвать владельца сброса кеша и событие, по которому он вызывается.
Записывайте связь, основание и последствие
Я бы ограничил основной отчёт небольшой таблицей. В каждой строке нужен потребитель, ссылка на код, текущее условие и риск предлагаемой правки. Строка «RSS тоже затронут» без основания не помогает выбрать решение.
| Что выясняется | Какое доказательство нужно |
|---|---|
| Главная использует общий scope | Вызов в обработчике и тело scope |
| Поиск применяет тот же scope | Фактическая цепочка запроса, включая дополнительный фильтр |
| RSS кешируется | Место чтения/записи кеша и условия сброса |
| Архив остаётся доступным по URL | Проверка статуса в маршруте статьи и правила перенаправления |
Это список вопросов для условного проекта. Он не утверждает, что любое Laravel-приложение устроено именно так. Отсутствующий механизм тоже результат: если кеширования нет, не надо добавлять его в карту ради полноты схемы.
Оставьте неизвестное неизвестным
По коду нельзя надёжно определить содержимое рабочей БД, активную конфигурацию удалённого сервера или состояние очереди. Исследователь должен отделить «код допускает будущую дату» от «у этой записи будущая дата». Второй вывод требует данных из конкретного окружения.
Для недостающего факта укажите безопасный способ проверки: посмотреть поля одной записи, проверить время приложения, прочитать заголовок кеша. Не превращайте запрос на исследование в разрешение выполнять команды на проде. Доступ к базе и внешним сервисам согласуется в рамках самой задачи.
Если агент не может открыть файл, в отчёте должна остаться эта граница. Подставлять типовую архитектуру фреймворка вместо недоступного кода хуже, чем вернуть неполную карту: исполнитель примет догадку за основание для изменения.
Превратите карту в решение
Владелец задачи читает найденные связи и выбирает место правки. В нашем примере разумной гипотезой будет оставить общее правило опубликованности и сузить только выборку свежих материалов. Но это ещё надо подтвердить по реальному коду и требованиям.
Из карты должны следовать проверки: главная без архива, поиск с архивом, прежний URL доступен, RSS соответствует выбранной политике. Если один пункт не связан ни с требованием, ни с обнаруженным потребителем, выясните, зачем он нужен. Так исследование ограничивает проверку реальными рисками, а не бесконечным перечнем возможных проблем.
Перед передачей отметьте состояние исходников, к которому относится карта. Если другая ветка уже изменила запросы, исполнитель должен пересмотреть затронутые связи. Наличие вчерашнего отчёта не делает его актуальным автоматически.
Для небольшого понятного изменения отдельный исследователь не обязателен. Критерий полезности другой: карта должна раскрыть существенную зависимость или устранить неопределённость, которую исполнитель иначе вынужден был бы исследовать сам. Ответственность за выбранное место изменения и полноту проверки остаётся у человека, принимающего результат.
