# System Feedback

> Спроектировать и проверить видимую обратную связь для уже выбранного перехода состояния: принято ли действие, продолжается ли операция, окончателен ли результат и что сохранилось при сбое. Использовать для невидимых, отложенных, оптимистичных и фоновых действий, async-данных и интерфейсов, где человек может разумно сомневаться в состоянии системы. Не использовать для мгновенного самоочевидного результата, выбора самого поведения, поиска всех корнеров или визуальной полировки.

- Skill: `hanumatori/system-feedback` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add hanumatori/system-feedback`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hanumatori/system-feedback/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: hanumatori (https://skillmd.com/u/hanumatori)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/hanumatori/system-feedback

---


# system-feedback

Обратная связь нужна не каждой кнопке, а каждой **разумной неопределённости**:
приняла ли система действие, продолжается ли работа, окончателен ли результат и
что теперь можно делать.

Не добавлять тост или спиннер по ритуалу. Если результат сразу и однозначно
виден в самом объекте, отдельное сообщение только дублирует интерфейс.

## Сначала зафиксировать переход

Одной строкой описать только реально достижимые состояния:

`до → намерение принято → ожидание или предварительный результат → подтверждено / не удалось → что сохранилось`

Если неизвестно, какое состояние должно наступить, нужен продуктовый выбор или
`edge-hunt`, а не этот скилл. Не придумывать обязательный набор из пустоты,
загрузки и ошибки: проектировать только состояния, достижимые в этом переходе.

## Найти момент неопределённости

Для каждого перехода проверить:

- виден ли сам факт принятия действия;
- может ли молчание спровоцировать опасный повтор;
- различает ли человек предварительный и окончательный результат;
- понятно ли при сбое, что изменилось, а что сохранилось;
- остаётся ли доступно следующее безопасное действие.

Неизвестное поведение не маскировать текстом. Если система сама не знает,
прошла ли операция, сначала определить способ сверки или восстановления.

## Выбрать самый дешёвый достаточный сигнал

| Форма | Когда подходит |
|---|---|
| Сам результат | Изменение сразу видно и нельзя разумно прочитать иначе |
| Локальный статус | Результат невидим или задержан, но относится к одному элементу |
| Статус области | Операция меняет список, форму или другой цельный участок |
| Устойчивый глобальный статус | Операция продолжается после ухода с экрана или влияет на несколько мест |

Сигнал показывать там, где находится внимание и последствия действия. Он должен
жить столько, сколько живёт неопределённость: не исчезать раньше результата и
не оставаться после того, как уже ничего не сообщает.

## Различать тип результата

- **Мгновенный и видимый:** отдельное подтверждение обычно не нужно.
- **Отложенный:** показать принятое намерение и не выдавать ожидание за успех.
- **Оптимистичный:** обозначить предварительность, если поздний откат заметно
  меняет смысл или данные.
- **Фоновый:** состояние должно быть доступно после ухода с исходного экрана.
- **Частичный:** назвать выполненную и невыполненную часть отдельно.
- **Неуспешный:** сообщить, что не произошло, что сохранилось и какое безопасное
  действие доступно дальше.

Не придумывать причину ошибки и не обещать автоматический повтор, если система
этого не гарантирует. Решение о подтверждении, отмене или допустимости повтора
принимать в модели поведения; здесь проверять только то, видны ли последствие и
восстановление.

## Проверить живой переход

Проверять не статичный макет, а последовательность во времени. Для самых
рискованных переходов воспроизвести доступные варианты: задержку, сбой, повтор,
уход с экрана и поздний результат. В каждый момент спросить:

- что человек сейчас считает произошедшим;
- совпадает ли это с реальным состоянием системы;
- не подтолкнёт ли интерфейс к опасному повтору или уходу раньше сохранения;
- сможет ли человек восстановиться без догадки.

Проверка должна наблюдать тот же канал, что и человек. Успешный API-тест не
подтверждает, что интерфейс сообщил результат; красивый тост не подтверждает,
что данные действительно сохранились.

## Подробнее

- `references/01-heuristics.md` — типовые разрывы между состоянием системы и
  представлением человека
- `references/02-checklist.md` — проверка по типам переходов