Інвентаризація поведінки перед змінами

BEHAVIOR_INVENTORY.md описує бізнес-потоки

`BEHAVIOR_INVENTORY.md` потрібен перед змінами в системі, де важлива фактична поведінка. Це не список файлів і не architectural diagram: кожен запис описує business flow, inputs, observable outputs, existing tests, missing checks і candidate на characterization.

Кандидат має мати явне значення `yes` або `no`. `yes` доречний для high-risk/high-business-criticality flow, uncovered edge case або ситуації, де code і documentation суперечать одне одному.

Схема одного запису

П’ять обовʼязкових потоків

• pause/resume subscription — перевірте стан підписки, pause interval, resume date і наступне списання;
• partial refund in the middle of billing period — зафіксуйте суму, період, округлення та observable ledger output;
• failed payment followed by successful retry — розділіть failure, retry schedule, повторний успіх і повідомлення користувачу;
• plan switch on billing day — перевірте precedence дати, старий/новий план і суму на межі періоду;
• upgrade/downgrade in the middle of a period — відокремте prorating, effective date, credits і майбутній invoice.

Inputs, outputs і evidence мають бути відтворюваними

Для кожного flow вкажіть мінімальний набір inputs: ідентифікатор стану, timestamp або billing date, plan, amount, feature flag і зовнішню подію, якщо вона потрібна. Outputs мають бути спостережуваними: status transition, invoice/refund amount, next billing date, persisted record або повідомлення. Не записуйте «працює правильно» без конкретного observable result.

Existing tests покажіть із шляхом і рівнем. Якщо тестів немає, це missing check, а не доказ, що behavior неправильний. Розділяйте confirmed facts, assumptions і manual verification так само, як у ARCHITECTURE_CURRENT.md.

Від inventory до characterization candidate

1. Виберіть приблизно 10–15 найсильніших кандидатів, а не кожну можливу умову.
2. Поставте yes для дорогих, невкритих або суперечливих flows; поставте no, якщо behavior уже достатньо підтверджена і ризик низький.
3. Запишіть reproducible inputs і observable outputs.
4. Додайте evidence anchors і список того, що треба перевірити вручну.
5. Передайте high/high entries у RISK_MAP.md з конкретною дією.
6. Не пишіть characterization tests у межах цього discovery-завдання.