Current vs desired behavior: мова фактів

Три частини опису задачі

`Goal` показує напрямок, але не пояснює розрив між поточним і цільовим станом. Для цього окремо фіксують `Current behavior` і `Desired behavior`.

Поточний стан описує спостережувані факти без передчасних висновків про причину. Бажаний стан має бути таким, щоб його можна було перевірити після реалізації.

Факти поточної поведінки

Для багфіксу зафіксуйте точку входу, кроки відтворення, фактичний результат, середовище, workaround і вплив. Для фічі опишіть, з яким обмеженням стикається користувач і як проблему обходять зараз.

На /login вводять правильний email і неправильний пароль.
Після submit сторінка стає порожньою.
Повідомлення про помилку не показується.
Проблема відтворюється локально та на staging.

Desired behavior має бути спостережуваним

• користувач залишається на сторінці входу після неправильного пароля;
• форма не зникає й не очищується без потреби;
• під полем пароля зʼявляється зрозуміле повідомлення;
• успішна авторизація працює так само, як раніше.

Evidence проти hypothesis

Facts-first workflow

1. Запишіть Goal, Current behavior і Desired behavior.
2. Окремо позначте гіпотези, які ще потрібно перевірити.
3. Зберіть логи, кроки відтворення та інші докази.
4. Попросіть Claude спочатку розділити факти й припущення без редагування коду.
5. Перевірте код, схему, обробники, API та події.
6. Лише після підтвердження причин переходьте до плану і правок.
7. Перевірте кожен пункт Desired behavior окремо.

## Гіпотези для перевірки
- Причина може бути у backend-валідації.
- Спочатку перевір її в коді, потім внось зміни.