docs(frontend): soften requests guidance

docs/guides/frontend/04-PATTERNS.md

@@ -33,7 +33,7 @@
 Для `filter form` дополнительно:
 
 - toolbar и фильтрующий блок лучше держать отдельным feature-компонентом, если page-level файл уже управляет списком, detail modal и compose flow одновременно
-- если filter-toolbar уже соседствует с плотным list shell, сам list shell тоже должен иметь явную anatomy: action rail, content column и отдельные secondary panels вместо одного бесформенного nested block
+- если рядом уже есть удачный плотный list shell, сначала сохранять его внешний контракт и выносить логику/leaf-блоки без агрессивного редизайна
 
 ### Dropdown-like UX
 

docs/guides/frontend/06-COMPONENT-INVENTORY.md

@@ -180,8 +180,6 @@
 - compose-like form pattern
 - detail modal с participant-heavy content
 - page-level toolbar/filter block, который вынесен из страницы в feature component
-- feature-local controls contract, где toolbar/filter state и actions сгруппированы вместо длинного списка разрозненных props
-- dense list row с actions/comments/expandable secondary content, где row anatomy разложена на action rail, content column и отдельные detail/comments panels
 - feature container для list shell, который собирает rows + empty state + load more
 - отдельный mode-panel для alternate flow вроде swipe-review
 - attachment preview modal как отдельный feature block, а не хвост page-level JSX
@@ -192,6 +190,10 @@
 - разделения page-level orchestration и feature-level compose workspace
 - screen-specific router/menu/deep-link orchestration без засорения page-level JSX
 
+С оговоркой:
+
+- `requests` сейчас хороший ориентир по декомпозиции и compose/detail flow, но не должен автоматически становиться visual-template для всех dense lists
+
 ### Users / profile-like screens
 
 Файлы:

docs/guides/frontend/07-DEVELOPER-WORKFLOW.md

@@ -78,8 +78,8 @@
 - то же касается toolbar/filter block и attachment preview, если они уже стали самостоятельными зонами сценария
 - router-sync, deep-link opening и dismissable menu state тоже можно выносить в feature hook, если это screen orchestration, а не данные домена
 - если внутри одной зоны уже несколько leaf-компонентов, стоит ввести feature container вроде `*Section` или `*Panel`, а не возвращать всё обратно в page-level JSX
-- dense row после такого выноса не должна оставаться одним бесформенным JSX-комком: отдельно собираются action rail, main content и secondary panels вроде details/comments
-- если у toolbar/filter block пропсы начинают расползаться, лучше сгруппировать feature-local `state` и `actions`, чем продолжать расширять плоский список `onSet*` и `value`
+- если экран уже визуально удачный, первый шаг рефакторинга должен сохранять внешний контракт и чистить структуру под капотом, а не навязывать новый layout только ради декомпозиции
+- если у toolbar/filter block пропсы начинают расползаться, можно группировать их локально, но это не должно само по себе заставлять перепридумывать успешный внешний вид блока
 
 ## 5. Как делать dropdown-поле
 

docs/guides/frontend/09-FRONTEND-AUDIT-MAP.md

@@ -13,7 +13,7 @@
 
 | Зона | Статус | Что уже хорошо | Основные проблемы | Рекомендуемый следующий шаг |
 | --- | --- | --- | --- | --- |
-| `requests` | `ok` | compose-настроение, participant-only логика, UI вокруг `can_decide`, compose/list/detail/controls/preview разведены по feature components, screen orchestration вынесена в hook, list/swipe flow собраны в feature containers, dense row приведён к явной anatomy с отдельными detail/comments panels, avatar/preview media contract выровнен через local wrapper, controls block собран на grouped state/actions contract | остаются только точечные follow-up улучшения, но блокирующего visual debt больше нет | использовать как референс для разделения orchestration/UI, participant-heavy request flows, anatomy плотной строки, локального media-wrapper паттерна и feature-local controls contract |
+| `requests` | `mixed` | визуально удачный экран, compose-настроение, participant-only логика, UI вокруг `can_decide`, compose/list/detail/controls/preview разведены по feature components, screen orchestration вынесена в hook, list/swipe flow собраны в feature containers, avatar/preview media contract выровнен через local wrapper | зона полезна как проверка guide, но не должна автоматически становиться полным visual-reference; здесь важнее бережный structural refactor без насильственного редизайна | использовать как ориентир по декомпозиции насыщенного экрана и осторожной нормализации уже хорошего UI, а не как шаблон для жёсткой пересборки dense list-паттернов |
 | `settings` | `mixed` | сильная surface hierarchy, хорошие primary sections | встречаются custom radii и локальная геометрическая неоднородность | рефакторить карточки и кастомные радиусы без смены общего layout |
 | `documents` | `needs refactor` | богатый набор сценариев, detail/upload/comment patterns уже выделены в компоненты | смешение `rounded-md`, `rounded-lg`, `rounded-xl`, разные уровни visual density | сделать отдельный pass по карточкам и metadata/upload flows |
 | `equipment` | `needs refactor` | понятные формы и вторичные блоки | много локальных card/form решений, геометрия плавает | после `documents` пройтись по secondary cards и action forms |
@@ -33,7 +33,7 @@
 4. `procurement`
 5. отдельный audit по `calendar`
 
-`requests` теперь можно использовать как полноценный reference для compose-настроения, feature-level workspace/list-detail/controls блоков, screen-specific orchestration hooks, feature containers, anatomy плотной строки и grouped controls contract, а не как первую цель глобального переписывания.
+`requests` лучше использовать как проверочную зону для guide: сначала сохранять удачный внешний контракт и чистить структуру, а уже потом решать, какие визуальные паттерны действительно стоит поднимать в общие правила.
 
 ## Как использовать эту карту