diff --git a/src/pages/ui-ux/index.md b/src/pages/ui-ux/index.md
index 321df3a2..64b816b6 100644
--- a/src/pages/ui-ux/index.md
+++ b/src/pages/ui-ux/index.md
@@ -1729,8 +1729,30 @@ operation token или другой domain mechanism.
 
 **Полный ответ**
 
-Формы объединяют ввод, валидацию, ошибки, доступность, backend-ограничения и состояние сохранения. Маленькая неточность
-может привести к потере данных или отказу от сценария.
+Форма одновременно работает с пользовательским вводом, локальным состоянием, бизнес-правилами и server contract. Поэтому
+даже небольшая форма быстро превращается в state machine.
+
+Нужно продумать:
+
+- initial и dirty state;
+- field/form validation;
+- async validation;
+- submitting;
+- backend errors;
+- permissions;
+- сохранение данных после failure;
+- keyboard/focus behavior;
+- autofill;
+- navigation с unsaved changes.
+
+Сложность усиливается тем, что пользователь вводит данные постепенно. Значение может быть временно невалидным в процессе
+набора, а server rule может зависеть от данных, которых client вообще не знает.
+
+Например, email может пройти browser validation, но server все равно отклонит его как уже зарегистрированный. UI должен
+map-ить такую ошибку обратно на поле и не очищать остальные значения.
+
+На интервью: **форма — это не набор inputs, а workflow с состояниями, validation boundaries и recovery path; зрелый
+ответ должен учитывать client, server и accessibility одновременно**.
 
 </td></tr></table>
 </details>
@@ -1746,8 +1768,31 @@ screen reader.
 
 **Полный ответ**
 
-Label объясняет, что нужно ввести в поле. Он нужен для понятности, доступности, автозаполнения и правильной работы
-screen reader.
+Label дает полю устойчивое имя, которое остается понятным до, во время и после ввода.
+
+Для native input лучше использовать настоящий `<label>`:
+
+```html
+<label for="email">Email</label>
+<input
+  id="email"
+  name="email"
+  type="email"
+/>
+```
+
+Связанный label:
+
+- увеличивает clickable area;
+- дает accessible name;
+- помогает screen reader понять назначение поля;
+- сохраняет контекст после ввода значения.
+
+Placeholder может дополнить label примером, но не заменить его.
+
+Для custom components важно сохранить тот же semantic contract через native elements или корректную ARIA-связь.
+
+На интервью: **label — это не декоративная подпись, а часть semantics и interaction contract поля**.
 
 </td></tr></table>
 </details>
@@ -1763,8 +1808,32 @@ Placeholder исчезает при вводе и часто имеет слаб
 
 **Полный ответ**
 
-Placeholder исчезает при вводе и часто имеет слабый контраст. Пользователь может забыть назначение поля, особенно при
-ошибке или автозаполнении.
+Placeholder хорош как дополнительный пример, но плох как единственный источник смысла.
+
+Проблемы:
+
+- исчезает после начала ввода;
+- не дает устойчивого контекста при ошибке;
+- может быть плохо различим;
+- browser autofill может сразу скрыть его;
+- пользователь может принять пример за реальное значение;
+- placeholder не всегда формирует надежный accessible name.
+
+Например:
+
+```html
+<label for="phone">Телефон</label>
+<input
+  id="phone"
+  placeholder="+7 900 000-00-00"
+/>
+```
+
+Здесь label отвечает за смысл поля, placeholder — только за пример формата.
+
+Floating label может визуально начинаться как placeholder, но после ввода должен оставаться видимым как label.
+
+На интервью: **placeholder — transient hint, label — persistent field identity**.
 
 </td></tr></table>
 </details>
@@ -1780,8 +1849,30 @@ Validation message объясняет, почему значение не под
 
 **Полный ответ**
 
-Validation message объясняет, почему значение не подходит. Хорошее сообщение говорит не только о проблеме, но и о том,
-как ее исправить.
+Validation message должен переводить validation rule в понятное действие.
+
+Плохо:
+
+```text
+Invalid value
+```
+
+Лучше:
+
+```text
+Пароль должен содержать минимум 12 символов.
+```
+
+Сообщение должно быть связано с конкретным полем и появляться в предсказуемый момент.
+
+Для accessibility error text полезно связать с input через `aria-describedby` или подходящий semantic pattern.
+
+Не стоит показывать технические названия rules вроде `minLength`, regex или backend-коды.
+
+Если одновременно нарушено несколько правил, обычно лучше показать наиболее полезную ошибку, а не длинный список из пяти
+сообщений.
+
+На интервью: **validation message должен снижать стоимость исправления: что не так, где проблема и что нужно сделать**.
 
 </td></tr></table>
 </details>
@@ -1797,8 +1888,30 @@ Client-side validation дает быстрый feedback в браузере. Ser
 
 **Полный ответ**
 
-Client-side validation дает быстрый feedback в браузере. Server-side validation является обязательной, потому что сервер
-отвечает за безопасность, бизнес-правила и достоверность данных.
+Client validation оптимизирует UX, server validation защищает систему и является source of truth.
+
+На client удобно проверять:
+
+- required;
+- basic format;
+- length/range;
+- взаимосвязь уже известных полей.
+
+Server должен повторно проверить все важные constraints и дополнительно может знать:
+
+- uniqueness;
+- permissions;
+- текущий domain state;
+- concurrency/version;
+- security rules.
+
+Нельзя считать client validation защитой: request можно отправить без UI.
+
+Важно синхронизировать rules настолько, насколько это разумно. Если client разрешает одно, а server постоянно отклоняет
+другое, пользователь получает плохой UX.
+
+На интервью: **client validation нужна для быстрого feedback, server validation — для корректности и безопасности;
+server остается окончательным источником истины**.
 
 </td></tr></table>
 </details>
@@ -1814,8 +1927,24 @@ Client-side validation дает быстрый feedback в браузере. Ser
 
 **Полный ответ**
 
-Обычно после потери фокуса, попытки отправки или когда пользователь явно завершил ввод. Ошибка во время каждого символа
-может раздражать и мешать.
+Timing ошибки зависит от того, можно ли уже считать ввод завершенным.
+
+Практичный подход:
+
+- до interaction не показывать ошибку;
+- после blur — показывать локальную ошибку;
+- после submit — показать все blocking errors;
+- после того как поле уже было invalid — обновлять feedback быстрее при исправлении.
+
+Для некоторых полей live validation полезна. Например password strength можно обновлять во время ввода, потому что это
+progress feedback, а не обвиняющая ошибка.
+
+Для email ошибка "неверный формат" после первой буквы обычно только шум.
+
+После submit полезно переводить focus к первой ошибке или показывать summary для длинной формы.
+
+На интервью: **ошибка должна появляться тогда, когда пользователь может осмысленно отреагировать, а не просто потому,
+что текущее промежуточное значение не проходит rule**.
 
 </td></tr></table>
 </details>
@@ -1826,13 +1955,32 @@ Client-side validation дает быстрый feedback в браузере. Ser
 
 **Короткий ответ**
 
-Required field - это поле, без которого форму нельзя успешно отправить. Пользователь должен заранее понимать, какие поля
+Required field — это поле, без которого форму нельзя успешно отправить. Пользователь должен заранее понимать, какие поля
 обязательны и почему.
 
 **Полный ответ**
 
-Required field - это поле, без которого форму нельзя успешно отправить. Пользователь должен заранее понимать, какие поля
-обязательны и почему.
+Required field выражает обязательный input contract формы.
+
+В native HTML это можно обозначить:
+
+```html
+<input required />
+```
+
+Но одной technical semantics недостаточно. Пользователь должен понимать обязательность заранее.
+
+Если большинство полей обязательные, иногда проще явно отмечать только optional fields. Главное — consistency внутри
+продукта.
+
+Не стоит делать поле required без продуктовой причины. Каждый обязательный input увеличивает friction и вероятность
+abandonment.
+
+Также нужно учитывать conditional required: поле может становиться обязательным только после выбора определенного
+варианта. UI должен явно показать изменение условия.
+
+На интервью: **required — это не звездочка рядом с label, а часть business contract, которую нужно понятно показать и
+валидировать и на client, и на server**.
 
 </td></tr></table>
 </details>
@@ -1848,8 +1996,21 @@ Required field - это поле, без которого форму нельз
 
 **Полный ответ**
 
-Маска помогает ввести данные в нужном формате, но не гарантирует корректность значения. Например, дата может быть
-формально похожа на дату, но быть недопустимой по бизнес-правилам.
+Input mask ограничивает или форматирует представление ввода. Validation проверяет смысл и допустимость значения.
+
+Например `31.02.2026` подходит под шаблон `DD.MM.YYYY`, но это невалидная дата.
+
+Другие примеры:
+
+- телефон правильно отформатирован, но не существует;
+- карта имеет нужное количество цифр, но не проходит checksum;
+- сумма подходит формату, но превышает бизнес-лимит.
+
+Маска также должна хорошо работать с paste, autofill, mobile keyboard и editing в середине строки.
+
+Полезно хранить отдельно raw/domain value и formatted presentation, чтобы formatting не проникал в business logic.
+
+На интервью: **mask помогает вводить, validation решает, допустимо ли значение; это разные уровни ответственности**.
 
 </td></tr></table>
 </details>
@@ -1865,8 +2026,26 @@ Required field - это поле, без которого форму нельз
 
 **Полный ответ**
 
-Валидация должна быть своевременной, конкретной и восстановимой. Важно подсвечивать поле, показывать текст ошибки и
-сохранять введенные данные.
+Хорошая validation flow строится вокруг восстановления.
+
+Нужно определить:
+
+- когда rule проверяется;
+- где показывается error;
+- как поле связано с message;
+- что происходит после submit;
+- сохраняется ли input;
+- какие rules может проверить только server.
+
+Цвета недостаточно: ошибка должна иметь текст и semantic state.
+
+Для длинной формы полезен error summary сверху плюс inline errors у конкретных controls.
+
+После server validation UI должен map-ить field errors обратно на inputs, а form-level errors не пытаться искусственно
+привязать к одному полю.
+
+На интервью: **валидация хороша, если пользователь быстро понимает проблему, исправляет ее и не теряет уже сделанную
+работу**.
 
 </td></tr></table>
 </details>
@@ -1882,8 +2061,25 @@ Required field - это поле, без которого форму нельз
 
 **Полный ответ**
 
-Пока пользователь печатает, значение часто временно невалидно. Ранняя ошибка может создавать ощущение, что интерфейс
-ругается до завершения действия.
+Во время набора многие корректные значения проходят через временно невалидные состояния.
+
+Например email `max@example.com` начинается как `m`, `ma`, `max@` — все эти промежуточные значения не должны
+провоцировать агрессивный error feedback.
+
+Проблемы слишком ранней validation:
+
+- визуальный шум;
+- layout jumping из-за сообщений;
+- пользователь читает ошибку вместо продолжения ввода;
+- screen reader получает лишние announcements.
+
+Хороший compromise — после blur или submit, а затем обновлять сообщение сразу по мере исправления.
+
+Но positive/live guidance полезен для password requirements или character limits, когда он помогает сформировать
+значение.
+
+На интервью: **validation timing должен учитывать естественный lifecycle ввода, а не проверять каждую клавишу как
+финальный submit**.
 
 </td></tr></table>
 </details>
@@ -1899,8 +2095,29 @@ Required field - это поле, без которого форму нельз
 
 **Полный ответ**
 
-Лучше дать пример рядом с полем или короткую подсказку до ошибки. Формат должен быть написан языком пользователя, а не
-регулярным выражением или названием backend-типа.
+Формат лучше объяснять до первой ошибки, если он неочевиден.
+
+Можно использовать helper text:
+
+```text
+Дата рождения
+ДД.ММ.ГГГГ
+```
+
+или example:
+
+```text
+Например: 31.12.1994
+```
+
+Если browser может принять несколько эквивалентных форматов, не стоит заставлять пользователя вручную соблюдать
+presentation, которую приложение может нормализовать само.
+
+Для locale-sensitive значений дата, число и currency должны соответствовать ожиданиям пользователя.
+
+Technical syntax вроде regex или ISO format уместен только для developer-oriented продукта.
+
+На интервью: **хороший интерфейс объясняет формат до ошибки и берет на себя нормализацию там, где это возможно**.
 
 </td></tr></table>
 </details>
@@ -1916,8 +2133,28 @@ Required field - это поле, без которого форму нельз
 
 **Полный ответ**
 
-Нужно показать, где ошибка, что именно не так и какой формат ожидается. Если возможно, стоит предложить исправление или
-сохранить введенное значение без сброса формы.
+Recovery должен требовать минимального повторного труда.
+
+Хорошая ошибка отвечает:
+
+- какое поле проблемное;
+- что именно нарушено;
+- как выглядит корректное значение;
+- можно ли исправить автоматически.
+
+Например вместо очистки телефона после ошибки лучше сохранить input и дать пользователю поправить одну цифру.
+
+Для длинной формы после submit полезно:
+
+1. показать summary;
+2. перевести focus к первой ошибке;
+3. сохранить остальные valid values;
+4. после исправления не требовать повторно заполнять соседние поля.
+
+Если приложение может безопасно исправить формат — например убрать лишние spaces — лучше сделать это автоматически.
+
+На интервью: **цель error handling — не доказать, что пользователь ошибся, а сократить путь от ошибки до успешного
+состояния**.
 
 </td></tr></table>
 </details>
@@ -1928,13 +2165,38 @@ Required field - это поле, без которого форму нельз
 
 **Короткий ответ**
 
-Сообщение “invalid value” не помогает восстановиться. Пользователю нужен следующий шаг: “Введите email в формате
-name@example.com”.
+Сообщение "invalid value" не помогает восстановиться. Пользователю нужен следующий шаг: "Введите email в формате
+name@example.com".
 
 **Полный ответ**
 
-Сообщение “invalid value” не помогает восстановиться. Пользователю нужен следующий шаг: “Введите email в формате
-name@example.com”.
+Сам факт failure редко полезен без recovery instruction.
+
+Плохо:
+
+```text
+Ошибка в поле
+```
+
+Лучше:
+
+```text
+Введите email в формате name@example.com.
+```
+
+Для server conflict:
+
+```text
+Этот email уже используется. Войдите или восстановите пароль.
+```
+
+Так сообщение не просто описывает проблему, а продолжает user flow.
+
+Важно не обвинять пользователя словами вроде "Вы ввели неправильные данные", если проблема может быть вызвана
+неоднозначным UI.
+
+На интервью: **error message — часть navigation по recovery path; хороший текст превращает тупик в конкретное следующее
+действие**.
 
 </td></tr></table>
 </details>
@@ -1950,8 +2212,31 @@ name@example.com”.
 
 **Полный ответ**
 
-Ошибки нужно сопоставить с полями, если это возможно, а общие ошибки показать на уровне формы. Технические коды стоит
-перевести в понятный текст.
+Backend errors полезно разделить на field-level и form-level.
+
+Например server response может содержать:
+
+```json
+{
+  "field": "email",
+  "code": "already_exists"
+}
+```
+
+Frontend может map-ить этот code на локализованный message рядом с email.
+
+Ошибки вроде "операция временно недоступна" или "конфликт версии" относятся ко всей форме и должны отображаться
+отдельно.
+
+Нельзя полагаться на human-readable backend text как на UI copy: он может измениться, быть техническим или не
+локализоваться.
+
+После error нужно сохранить input и только в редких случаях сбрасывать форму.
+
+Если server вернул новую актуальную data/version, UI должен решить conflict явно, а не просто повторять request.
+
+На интервью: **backend error contract лучше строить на стабильных codes/fields, а presentation и localization оставлять
+frontend**.
 
 </td></tr></table>
 </details>
@@ -1967,8 +2252,26 @@ name@example.com”.
 
 **Полный ответ**
 
-Нужно показать общий alert или summary рядом с началом формы и сохранить введенные данные. Если ошибка влияет на
-несколько полей, стоит объяснить связь между ними.
+Form-level error нужен, когда проблему нельзя честно привязать к одному control.
+
+Примеры:
+
+- комбинация дат недопустима;
+- server временно недоступен;
+- данные изменились в другой сессии;
+- пользователь потерял permission;
+- операция нарушает cross-field business rule.
+
+Сообщение стоит разместить так, чтобы оно было замечено после submit. Для длинной формы часто удобно использовать
+summary в начале и дополнительно подсветить связанные поля.
+
+Focus management важен: после submit screen reader/keyboard user должен попасть к понятному описанию проблемы или первой
+исправляемой ошибке.
+
+Введенные данные сохраняются, если их использование безопасно.
+
+На интервью: **не нужно искусственно выбирать одно поле для общей ошибки; UI должен отражать реальный scope validation
+rule**.
 
 </td></tr></table>
 </details>
@@ -1984,8 +2287,22 @@ Inline validation показывает feedback рядом с конкретны
 
 **Полный ответ**
 
-Inline validation показывает feedback рядом с конкретным полем. Она удобна, когда ошибка локальная и пользователь может
-исправить ее сразу.
+Inline validation связывает состояние и message непосредственно с control.
+
+Преимущества:
+
+- не нужно искать ошибку в общем списке;
+- recovery происходит рядом с местом ввода;
+- feedback можно показать сразу после meaningful interaction.
+
+Но inline validation не заменяет form summary в длинных формах, особенно после submit, когда ошибок несколько.
+
+Также нужно резервировать или предсказуемо размещать message, чтобы форма не прыгала при каждом появлении ошибки.
+
+Для accessibility input и error text должны иметь semantic relation.
+
+На интервью: **inline validation хороша для локальных problems, а summary нужен для общей навигации по ошибкам; эти
+patterns дополняют друг друга**.
 
 </td></tr></table>
 </details>
@@ -2001,8 +2318,27 @@ Inline validation показывает feedback рядом с конкретны
 
 **Полный ответ**
 
-Это постепенное раскрытие дополнительных полей или настроек только при необходимости. Такой подход снижает шум и
-помогает не перегружать основной сценарий.
+Progressive disclosure оставляет visible только information/actions, которые нужны сейчас, а дополнительные раскрывает
+по контексту.
+
+Например checkbox "Нужен юридический адрес отдельно" может открыть дополнительный address block только после выбора.
+
+Плюсы:
+
+- меньше initial cognitive load;
+- меньше irrelevant fields;
+- проще основной flow.
+
+Риски:
+
+- hidden field может содержать уже введенные данные;
+- user может не понять, что дополнительные options существуют;
+- validation hidden fields не должна неожиданно блокировать submit.
+
+Если section скрывается после изменения выбора, нужно заранее решить, очищать ли ее data или сохранять.
+
+На интервью: **progressive disclosure полезен, когда дополнительные поля действительно conditional; нельзя просто
+прятать сложность без понятного trigger и state contract**.
 
 </td></tr></table>
 </details>
@@ -2018,8 +2354,27 @@ Inline validation показывает feedback рядом с конкретны
 
 **Полный ответ**
 
-Нужно убрать необязательные поля, использовать разумные defaults, автозаполнение, данные профиля и объединение шагов,
-если это не ухудшает понимание. Каждый вопрос формы должен иметь продуктовую причину.
+Лучший способ упростить форму — не спрашивать то, что система может узнать сама.
+
+Можно:
+
+- удалить unused fields;
+- подставить profile/account data;
+- использовать browser autofill;
+- вычислять значения;
+- давать sensible defaults;
+- спрашивать optional details позже;
+- объединять redundant fields.
+
+Важно не маскировать complexity только визуально. Если десять обязательных business inputs спрятаны за accordion, форма
+не стала проще.
+
+Каждое поле имеет цену: время, вероятность ошибки, privacy concern и maintenance.
+
+Полезный вопрос к product: "Что произойдет, если мы перестанем спрашивать это значение?"
+
+На интервью: **оптимизация формы начинается с удаления unnecessary data collection, а не с более красивой верстки тех же
+полей**.
 
 </td></tr></table>
 </details>
@@ -2035,8 +2390,28 @@ Inline validation показывает feedback рядом с конкретны
 
 **Полный ответ**
 
-Нужно разделить шаги по смыслу, показывать прогресс, сохранять данные и давать возможность вернуться назад без потерь.
-Ошибки лучше связывать с конкретным шагом.
+Шаги должны соответствовать meaningful groups, а не произвольному количеству полей.
+
+Нужно продумать:
+
+- progress indicator;
+- back navigation;
+- сохранение state;
+- validation per step;
+- server validation в финале;
+- deep link/reload, если flow долгий;
+- resume later;
+- summary перед необратимым submit.
+
+Не стоит скрывать cross-step dependency. Если поле на шаге 4 делает невалидным шаг 1, пользователь должен получить
+понятный recovery path.
+
+Back не должен стирать уже введенные данные.
+
+Для длительного onboarding полезно сохранять draft на server, а не только в memory browser.
+
+На интервью: **multi-step form хороша, когда шаги отражают естественную структуру задачи и уменьшают нагрузку, а не
+просто разрезают длинную форму на несколько экранов**.
 
 </td></tr></table>
 </details>
@@ -2052,8 +2427,22 @@ Inline validation показывает feedback рядом с конкретны
 
 **Полный ответ**
 
-Когда один экран становится слишком тяжелым или у данных есть естественные группы. Но разбиение не должно скрывать
-важные зависимости и увеличивать число ненужных переходов.
+Multi-step полезна, когда:
+
+- есть несколько логических этапов;
+- часть вопросов зависит от предыдущих ответов;
+- сценарий длинный и требует progress;
+- пользователь может сохранить draft;
+- каждый этап имеет понятный mini-goal.
+
+Одна страница лучше, если форма короткая и поля нужно сравнивать одновременно.
+
+Разбиение имеет цену: navigation, state persistence, back behavior, progress, cross-step errors.
+
+Нельзя выбирать wizard только потому, что "на экране слишком много полей", не разобравшись, какие поля вообще нужны.
+
+На интервью: **решение определяется mental model задачи и dependency между данными, а не фиксированным числом
+controls**.
 
 </td></tr></table>
 </details>
@@ -2069,8 +2458,30 @@ Inline validation показывает feedback рядом с конкретны
 
 **Полный ответ**
 
-Пользователь может не понимать, что уже сохранено, а что еще нет. Также важны конфликты, восстановление после ошибки и
-защита от случайного сохранения нежелательных изменений.
+Autosave убирает explicit save action, но переносит сложность в state synchronization.
+
+Нужно различать:
+
+- local changed;
+- saving;
+- saved;
+- failed;
+- offline/pending;
+- conflict.
+
+Риски:
+
+- network request на каждый input;
+- out-of-order responses;
+- overwrite изменений из другой сессии;
+- сохранение промежуточного нежелательного значения;
+- пользователь закрывает страницу до завершения save.
+
+Обычно помогают debounce, versioning/ETag, cancellation и явный save status.
+
+Для critical data autosave может быть плохим выбором, если пользователь ожидает review перед commit.
+
+На интервью: **autosave — это distributed state synchronization problem, а не просто отсутствие кнопки Save**.
 
 </td></tr></table>
 </details>
@@ -2081,13 +2492,29 @@ Inline validation показывает feedback рядом с конкретны
 
 **Короткий ответ**
 
-Нужен явный status: “Сохранено”, “Сохраняем”, “Не удалось сохранить”. Для важных данных полезны время последнего
+Нужен явный status: "Сохранено", "Сохраняем", "Не удалось сохранить". Для важных данных полезны время последнего
 сохранения и понятный retry.
 
 **Полный ответ**
 
-Нужен явный status: “Сохранено”, “Сохраняем”, “Не удалось сохранить”. Для важных данных полезны время последнего
-сохранения и понятный retry.
+Save feedback должен соответствовать реальному состоянию persistence.
+
+Пример lifecycle:
+
+```text
+Есть изменения → Сохраняем... → Сохранено
+                         ↘ Не удалось сохранить
+```
+
+Для autosave status лучше размещать стабильно, чтобы он не выглядел как случайный toast.
+
+Для важных документов полезно показывать время последнего успешного сохранения.
+
+Нельзя показывать "Сохранено" только потому, что local state обновился, если server еще не подтвердил write.
+
+После failure пользователь должен видеть, остались ли изменения локально и можно ли retry.
+
+На интервью: **save status должен отражать confirmed persistence, а не optimistic assumption**.
 
 </td></tr></table>
 </details>
@@ -2103,8 +2530,22 @@ Inline validation показывает feedback рядом с конкретны
 
 **Полный ответ**
 
-Нужно заранее объяснять последствия, выделять destructive action и давать шанс остановиться. Если возможно, лучше
-сделать действие обратимым через undo.
+Для irreversible action главное — предотвратить accidental execution и сделать последствия понятными.
+
+Полезно:
+
+- назвать конкретный объект;
+- описать, что именно исчезнет;
+- отделить destructive action от safe actions;
+- не ставить dangerous button как default focus без причины;
+- при high impact запросить дополнительное подтверждение.
+
+Но confirmation dialog — не единственный инструмент. Иногда soft delete + undo безопаснее и быстрее.
+
+Для особенно критичных операций можно использовать typed confirmation, но только если цена ошибки действительно высока.
+
+На интервью: **чем выше необратимость и стоимость ошибки, тем сильнее должен быть friction перед action; обратимость
+часто лучше дополнительного подтверждения**.
 
 </td></tr></table>
 </details>
@@ -2120,8 +2561,27 @@ Inline validation показывает feedback рядом с конкретны
 
 **Полный ответ**
 
-Он нужен для редких, опасных или необратимых действий. Для частых безопасных действий confirmation только замедляет
-пользователя.
+Confirmation оправдан, если ошибка дорогая и нельзя легко восстановить состояние.
+
+Примеры:
+
+- permanent delete;
+- публикация для большой аудитории;
+- отправка платежа;
+- reset критичной configuration.
+
+Для обычного navigation, закрытия reversible toast или частого save confirmation создает unnecessary friction.
+
+Хороший dialog говорит не "Are you sure?", а конкретно:
+
+```text
+Удалить проект "Apollo"?
+Будут удалены 24 связанных отчета. Отменить это действие нельзя.
+```
+
+Buttons также должны иметь конкретные labels: "Удалить проект", а не generic "Да".
+
+На интервью: **confirmation — инструмент управления risk, а не стандартный wrapper вокруг любого action**.
 
 </td></tr></table>
 </details>
@@ -2137,8 +2597,24 @@ Inline validation показывает feedback рядом с конкретны
 
 **Полный ответ**
 
-Пользователи привыкают автоматически подтверждать диалоги. Если текст общий и действие частое, confirmation становится
-шумом, а не защитой.
+При частых confirmations возникает habituation: пользователь перестает читать содержание и автоматически нажимает
+primary button.
+
+Generic "Вы уверены?" почти не добавляет информации.
+
+Confirmation работает лучше, если:
+
+- появляется редко;
+- содержит конкретный объект и последствия;
+- dangerous action визуально и текстово однозначен;
+- безопасный cancel легко выбрать.
+
+Для reversible action undo часто эффективнее, потому что не заставляет пользователя предсказывать ошибку заранее.
+
+Еще один вариант — design prevention: сделать accidental trigger менее вероятным самим layout/interaction.
+
+На интервью: **confirmation снижает риск только тогда, когда привлекает осмысленное внимание; постоянные dialogs создают
+confirmation fatigue**.
 
 </td></tr></table>
 </details>
@@ -2154,8 +2630,26 @@ Inline validation показывает feedback рядом с конкретны
 
 **Полный ответ**
 
-Нужно ясно назвать объект и последствия, использовать отличимое действие и не прятать важную информацию в мелкий текст.
-Для критичных операций можно попросить дополнительное подтверждение.
+Destructive action должен отличаться не только цветом, но и wording/context.
+
+Хорошая схема:
+
+- точное название объекта;
+- описание irreversibility;
+- destructive verb в button label;
+- cancel/safe alternative;
+- focus management;
+- loading state после submit.
+
+Красный цвет помогает, но color alone недостаточно для accessibility.
+
+После click важно предотвратить duplicate request и не закрывать dialog как success до подтверждения server, если action
+критичный.
+
+Если delete можно сделать soft-delete, UI может предложить undo вместо тяжелого confirmation.
+
+На интервью: **destructive UX начинается с ясных последствий и безопасного interaction contract, а не с красной
+кнопки**.
 
 </td></tr></table>
 </details>
@@ -2171,8 +2665,27 @@ Inline validation показывает feedback рядом с конкретны
 
 **Полный ответ**
 
-Сначала действие выполняется, затем пользователь получает короткое окно для отмены. Это хорошо для обратимых операций,
-где ошибка вероятна, но последствия можно безопасно откатить.
+Undo переносит friction после действия: normal flow остается быстрым, а accidental action можно восстановить.
+
+Подходит для:
+
+- archive;
+- remove from list;
+- move;
+- reversible settings;
+- soft delete.
+
+Не подходит, если действие сразу вызывает необратимый внешний side effect, например реально отправляет платеж.
+
+Implementation contract должен быть честным: если server уже permanently deleted data, toast "Undo" не должен быть
+фиктивным.
+
+Можно реализовать soft delete/tombstone с delayed finalization или отдельный restore endpoint.
+
+Undo control должен быть keyboard accessible и достаточно долго оставаться доступным.
+
+На интервью: **undo лучше confirmation для частых reversible actions, потому что уменьшает friction и одновременно дает
+реальный recovery path**.
 
 </td></tr></table>
 </details>
@@ -2183,13 +2696,35 @@ Inline validation показывает feedback рядом с конкретны
 
 **Короткий ответ**
 
-Save button лучше для явного контроля, autosave - для частого редактирования без финального шага, optimistic save - для
+Save button лучше для явного контроля, autosave — для частого редактирования без финального шага, optimistic save — для
 быстрых надежных операций. Выбор зависит от риска, стоимости ошибки и ожиданий пользователя.
 
 **Полный ответ**
 
-Save button лучше для явного контроля, autosave - для частого редактирования без финального шага, optimistic save - для
-быстрых надежных операций. Выбор зависит от риска, стоимости ошибки и ожиданий пользователя.
+У каждого pattern разный control model.
+
+**Save button** подходит, когда пользователь хочет собрать изменения и явно commit-ить их. Хорошо для settings, complex
+forms и risky changes.
+
+**Autosave** подходит для continuous editing, где отдельный commit не имеет смысла: notes, drafts, collaborative
+content. Нужны clear save status, conflict handling и offline behavior.
+
+**Optimistic save** полезен для маленьких быстрых actions, когда success очень вероятен и rollback простой: toggle,
+favorite, reorder.
+
+Критерии выбора:
+
+- обратимость;
+- стоимость ошибочного commit;
+- вероятность server reject;
+- необходимость review перед save;
+- conflict/concurrency;
+- ожидания пользователя.
+
+Иногда patterns комбинируются: draft autosaves, а publish остается explicit action.
+
+На интервью: **save strategy выбирают по risk/control model, а не по моде; чем выше последствия, тем важнее explicit
+confirmation server state**.
 
 </td></tr></table>
 </details>