Программная инженерия
Составьте карту радиуса воздействия изменения кода
Карта воздействия проводит предлагаемое изменение через вызывающий код, зависимости, данные, развёртывания, тесты и пути клиентов, выявляя скрытые последствия до реализации.
Процесс
Делай в этом порядке.
- Определите предлагаемое изменение, ревизии base и head, желаемый результат, файлы в области, допущения и решения, для которых карта должна дать информацию.
- Изучите diff и прямых зависимых, затем найдите вызывающий код, импорты, интерфейсы, сгенерированный код, конфигурацию и тесты только доступными инструментами.
- Постройте статическую карту доказательств последствий через API, чтение и запись данных, очереди, задачи, разрешения, feature flags, настройки развёртывания и пути, видимые клиенту.
- Сопоставьте владельцев, покрытие тестами, наблюдаемость, зависимости и ограничения миграции, классифицируя каждую поверхность как прямую, вероятную, возможную или неизвестную и отделяя статические доказательства от предположений выполнения.
- Выявите пробелы в валидации, доступности, совместимости, откате и наблюдаемости; предложите самые маленькие безопасные проверки, но не запускайте здесь тесты, команды пакетов или runtime-пути.
- Суммируйте влияние и обратимость, укажите чувствительные данные и недоверенный код и запросите отдельное одобрение на выполнение любых тестов или команд пакетов.
- Сохраните карту и несекретные исходные доказательства в целевой рабочей области Latch, сообщите пределы покрытия и нерешённые риски и остановитесь без изменения репозитория или удалённого состояния.
Принеси это
Входы, которые кот спросит.
- ревизии base и head или diff
- предлагаемое изменение и область
- контекст выполнения и развёртывания
- допустимый риск и владельцы проверки
Роутер + один playbook
Сначала маршрут. Выбери один.
Cat Paw открывает один playbook на задачу, не смешивает несколько. Начни с этого роутера; остальные пути — кандидаты именно этого workflow.
- Роутер:
code-graph-pack skills/code-graph-pack/code-change-blast-radius-map/SKILL.md
Границы
Границы едут вместе с промптом.
- Перед началом проверьте реальные инструменты, учётные записи, разрешения и рабочую область; никогда не утверждайте, что недоступный инструмент, учётная запись, источник или возможность существует.
- Используйте Latch/target-workspace для приватного кода, артефактов, живых проверок или непубличных данных; если доступ недоступен, остановитесь на границе и сообщите о блокировке, не подменяя её догадкой.
- Приостановите работу для явного одобрения перед внешними действиями с последствиями; верните доказательства, нерешённые риски, допущения и любое действие, ожидающее одобрения.
Готово значит
Проверяемый финиш.
Статическая карта доказательств проводит указанный diff через код, данные, зависимости, развёртывание, тесты и пользователей, включая ранжированные риски, предлагаемые проверки, пределы покрытия и нерешённые риски, не изменяя репозиторий или удалённое состояние.
Источники
Откуда взялся этот процесс.
- github.com/Graphify-Labs/graphify/tree/4c735618f3d56fd622c2049771584621c31ba9ff/
- docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review
- c4model.com/
Источники задают рисунок workflow. Посты Reddit и сообщества, если они есть, — байки практиков, не универсальные факты.
