Какие проблемы ищем
Это карта целевого каталога, а не список уже доступных возможностей. Реальную готовность смотри на странице состояния продукта.
| Группа | Условий в плане | Примеры вопросов к коду |
|---|---|---|
| Архитектура и достижимость | 14 | Нужна ли зависимость? Используется ли код? Попал ли обязательный ресурс в сборку? |
| Контекст исполнения | 14 | На каком actor/executor выполняется код? Соблюдена ли изоляция? Нужен ли переход? |
| Асинхронность | 20 | Не устарело ли состояние после await? Завершится ли Task? Передаётся ли отмена? |
| Ownership, память и ресурсы | 12 | Кто владеет значением? Есть ли цикл удержания, потерянный ресурс или опасный доступ к памяти? |
| Производительность | 17 | Повторяется ли дорогая работа? Нужны ли копия, материализация или полный проход? |
| Безопасность | 26 | Попадают ли секреты в лог? Доходят ли опасные данные до SQL, shell или другого чувствительного API? |
| Значения и коллекции | 19 | Корректны ли индекс, числовое преобразование, сравнение и предположения о последовательности? |
| Потоки событий и транзакции | 7 | Ограничен ли буфер? Завершается ли поток? Корректны ли повтор запроса и транзакция? |
| SwiftUI | 4 | Стабильна ли identity? Правильно ли связаны состояние и обновления? |
| Изменения проекта | 8 | Меняет ли правка API, поведение, привязку вызовов или состав ресурсов? |
Открыть каталог всех 138 правил: поиск, фильтры и отдельные страницы с примерами, доказательствами и границами анализа.
Как выглядит полезная находка
Например, actor читает состояние, выполняет await, а затем принимает решение, считая старое состояние актуальным. Во время приостановки другой вызов мог его изменить. Мы хотим показывать конкретное состояние, точку приостановки и недостающую повторную проверку, когда имеющихся фактов достаточно.
Это иллюстрация целевого async-правила, не заявление о его текущей приёмке. actor сам по себе не устраняет все логические проблемы reentrancy.
Для уже принятой ресурсной области пример проще: обязательный литеральный Bundle.module lookup требует файл, которого нет в подтверждённом составе сборки. Optional lookup или предусмотренный fallback не должны давать такую же диагностику.
Не каждое замечание — ошибка
- Дефект: доказано конкретное нежелательное поведение в области правила.
- Нарушение контракта: код расходится с явно заданным требованием проекта.
- Возможность улучшения: есть аргумент для оптимизации или упрощения.
- Сигнал для ревью: ситуация требует внимания, но полного доказательства нет.
Уверенность, зрелость правила и строгость CI — разные вещи. Experimental не означает автоматически «ошибка», а advisory не превращает догадку в доказательство.
Будем ли добавлять правила?
Сначала доводим текущий каталог и проверяем его на проектах. Расширение поддерживаемых сценариев существующего правила часто полезнее нового номера. Следующие правила должны появляться из обнаруженных пропусков и реальных потребностей.
Подробный целевой список: docs/product/final-rule-catalog.md. Точные идентификаторы и состояния приёмки находятся в материалах 022.