Corp/docs/guides/frontend/08-UI-REVIEW-CHECKLIST.md

Frontend Guide: UI Review Checklist

Этот документ нужен для self-check перед коммитом и для code review.

1. Geometry

• Используется ли базовая шкала радиусов?
• Нет ли нового rounded-[...] без отдельного обоснования?
• Не используется ли rounded-md там, где нужен normal control/card contract?
• Совпадает ли визуальный вес элементов одного типа?

2. Surfaces

• Понятно ли, где primary panel, а где secondary grouped block?
• Нет ли лишней вложенности card inside card inside card?
• Используются ли app-surface, app-surface-elevated, app-surface-muted по назначению?

3. Forms

• Форма собрана на app-input / app-select / shared select-паттернах?
• Понятно ли, какие поля главные, а какие вторичные?
• Не перегружена ли форма визуально?
• Согласован ли паттерн формы с её сценарием: CRUD, compose, filters, settings, dialog?

4. Dropdowns

• Если нужен поиск или multi-select, используется ли shared select?
• Не стилизован ли native select так, как будто это другой компонент?
• Совпадает ли affordance dropdown-поля с остальным приложением?

5. Actions

• Есть ли один очевидный primary action?
• Не спорят ли secondary и danger actions по визуальному весу с primary?
• Семантика destructive actions понятна?
• В парных action-clusters danger не выглядит ли недорисованным по сравнению с secondary?

6. Responsive

• Экран или модалка читаются на mobile без отдельной layout-ветки?
• Header/footer остаются удобными при длинном контенте?
• Нет ли случайного horizontal overflow?

7. API contract и frontend logic

• Не вычисляет ли фронтенд права доступа через устаревшие role-based эвристики?
• Там, где backend уже отдаёт семантический флаг, используется ли он напрямую?
• UI корректно скрывает действия, которые недоступны по business contract?

Особенно важно для:

• requests
• comments
• decision actions
• admin vs participant-only flows

8. Legacy

• Не копируется ли legacy-решение в новый код?
• Если legacy оставлен, понятна ли причина?
• Можно ли было безопасно привести участок к target state уже в этой задаче?

9. Decision

Если по checklist есть много “нет”, задача не считается просто “визуально нормальной”. Она должна либо быть доделана, либо иметь явный зафиксированный компромисс.