Чому рішення з чатів зі ШІ губляться і де їх зберігати

Рішення, ухвалені в розмові з ChatGPT чи Claude, губляться, бо в чату немає стану. Ніщо в ньому не позначає рядок як «ось що ми вирішили», ніщо не пов’язує цей рядок із роботою, на яку він впливає, а новий чат починається з чистого аркуша. Розв’язок — щоб ШІ записував рішення там, де живе робота, коротким записом із причинами, а наступна сесія читала ці записи, перш ніж щось робити.

Weft робимо ми. Факти про інші продукти взято з їхніх офіційних сторінок, перевірено 27 жовтня 2026 року. Ідея, що тред «не має стану», — зі статті Hypertask про треди в Slack. Цей посібник застосовує її до чатів зі ШІ.

Чому зникають рішення, ухвалені з ChatGPT чи Claude?

Ти сорок хвилин зважуєш з асистентом двох провайдерів баз даних, дві цінові моделі чи два способи побудувати API. Обираєш один. Аргументи добрі, асистент погоджується, і ти переходиш до наступного.

За тиждень висновок досі лежить у тому чаті, десь над двомастами іншими повідомленнями. Новий чат про нього нічого не знає. Колега його ніколи не бачив. А якщо наступного дня ти відкриєш інший ШІ-клієнт, наприклад агента для коду в терміналі, той почне з нуля і може радо запропонувати варіант, який ти відкинув.

Справа не в дисципліні. Розмова — це послідовність повідомлень. У ній немає поля «вирішено», немає відповідального, немає зв’язку із завданням і немає способу сказати «це замінює те, що ми казали у вівторок». Вирішене питання і покинуте виглядають однаково, щойно зникають за межами екрана.

Хіба пам’ять чату цього не розв’язує?

Не для цього завдання. Багато асистентів тепер можуть пам’ятати щось про тебе між чатами, і це корисно для вподобань і загального контексту. Але така пам’ять належить одному продукту й одному обліковому запису. Вона написана для використання цим асистентом, а не як запис, який людина може переглянути рядок за рядком, і інший ШІ-клієнт не може її прочитати. До того ж вона не каже, якого завдання стосувався вибір і який попередній вибір він замінив.

До журналу рішень вимоги інші. Його мають легко знаходити люди й агенти, що працюють над проєктом; його має читати будь-який ШІ-клієнт, який наступним візьметься за роботу; він має бути прив’язаний до цієї роботи й чесно показувати історію: коли рішення змінюється, старе має лишатися видимим разом із причиною, чому його замінили.

Яке рішення варто записувати?

Записуй вибір, коли хтось цілком міг би обрати інакше, а сам вибір визначатиме подальшу роботу. Добрі приклади:

• Вибір одного інструмента, постачальника чи бібліотеки замість іншого.
• Свідома відмова від чогось («цього кварталу без реферальної програми»).
• Правило, якого має дотримуватися робота («в ЄС усі ціни показуємо з ПДВ»).
• Зміна попереднього вибору — із причиною.
• Урок, засвоєний на власних помилках («не запускати міграцію в робочі години»).

Не записуй:

• Ідеї, які ти накинув, але не прийняв.
• Кроки самої роботи (їм місце в завданні та його результаті).
• Те, на що людина ще не погодилася, — хіба що це чітко позначено як пропозицію.
• Факти, які будь-хто знову знайде за хвилину.

Корисний тест: якби нова сесія ШІ збиралася скасувати цей вибір, чи хотів би ти, щоб вона зупинилася й прочитала, чому його зробили? Якщо так — запиши.

Який вигляд має добрий запис рішення?

Пиши коротко і зберігай причини. Формат нижче — полегшена версія MADR (Markdown Architectural Decision Records), яку використовує інструмент record_decision у Weft:

Title:        Завантаження файлів: об’єктне сховище, а не база даних
Outcome:      Завантажені файли йдуть в об’єктне сховище; база даних
              зберігає лише ключ файлу й метадані.
Status:       accepted
Context:      Користувачі прикріплюють файли до 50 МБ. Якщо тримати їх
              у базі, резервні копії стануть повільними й великими.
Options:      1. Об’єктне сховище + дешево, бекапи лишаються малими
                                   - ще один сервіс, який треба налаштувати
              2. Колонка в базі   + усе в одному місці
                                   - бекапи ростуть з кожним завантаженням
Consequences: Для завантаження потрібні підписані URL.
              Видалення завдання має видаляти і його файли.
Revisit when: Знадобиться пошук усередині вмісту файлів.
Task:         Завантаження файлів

• Title називає рішення, щоб його можна було знайти, пробігши очима.
• Outcome — одне речення, за яким може діяти новачок.
• Context — те, що було правдою на той момент. Саме ця частина першою зникає з пам’яті.
• Options перелічує лише те, що справді зважували, а не альтернативи, вигадані заднім числом.
• Consequences містить і мінуси, з якими ви погодилися, щоб ніхто згодом не «відкривав» їх як баги.
• Revisit when каже, що зробить цей вибір хибним.

Як Weft зберігає записи рішень?

Weft — це дошка завдань, до якої твої ШІ-клієнти звертаються через MCP за адресою https://letsweft.com/api/mcp. Три з її 32 інструментів працюють із рішеннями:

• record_decision приймає назву й результат, а також контекст, до п’яти варіантів із плюсами й мінусами, наслідки й умову, за якої варто переглянути рішення. Його можна прив’язати до завдання (taskId) або проєкту. Записи незмінні: щоб змінити рішення, ШІ записує нове з supersedesId, що вказує на старе, а старий запис лишається з позначкою superseded.
• get_context повертає чинні рішення й уроки робочого простору, від найновіших, упаковані в бюджет токенів (за замовчуванням 800). Його можна звузити до проєкту чи завдання. Кожен рядок має дату, замінене рішення ніколи не з’являється, а рядки, що не вмістилися, підраховуються, а не ховаються.
• get_task_history у режимі decisions показує всі рішення, записані щодо одного завдання, зокрема вердикти рев’ю та їхні причини.

У record_decision є і друге застосування: передати вердикт, який людина дала в розмові щодо роботи, що чекає на її рев’ю (прийнято, на доопрацювання, відкинуто чи відкладено). Опис інструмента каже ШІ, що тут він лише посланець, а не той, хто вирішує, тож ніколи не має використовувати це, щоб прийняти власну роботу.

Оскільки записи ніколи не редагуються на місці, історія лишається чесною. Якщо в березні ти зміниш провайдера, січневе рішення нікуди не дінеться — воно буде позначене як замінене, а березневий запис пояснить чому.

Як попросити ШІ записувати рішення?

Підключи Weft до свого ШІ-клієнта, а потім встав на початку чату — або в кастомні інструкції чи файл проєкту клієнта, якщо вони є, — інструкцію на кшталт цієї:

Коли ми в цьому чаті робимо справжній вибір (обираємо один варіант замість
іншого, від чогось відмовляємося або змінюємо попередній вибір), запиши його
у Weft через record_decision, перш ніж ми підемо далі:
- title: рішення, назване кількома словами
- outcome: вибір одним реченням
- context: що було правдою і змусило зробити цей вибір
- options: лише ті варіанти, які ми справді зважували, з плюсами й мінусами
- consequences: що з цього випливає, добре й погане
- confirmation: коли нам варто його переглянути
- taskId або project: завдання чи проєкт, якого це стосується
Якщо це змінює попереднє рішення, передай supersedesId замість редагування.
Не записуй балачки, здогадки чи те, на що я не погодився.
Якщо я ще не визначився, став статус "proposed".
На початку будь-якої нетривіальної роботи спершу виклич get_context і скажи
мені, які минулі рішення тут застосовні.

Підключення займає хвилину. У ChatGPT Weft — це опублікований застосунок у каталозі плагінів, доступний на будь-якому тарифі, зокрема Free (налаштування). У Claude Code це одна команда (налаштування). Claude.ai і Claude Desktop додають його як кастомний конектор. Вхід — через OAuth у браузері, тож копіювати ключ не треба, а Weft видає refresh-токени, тож клієнт сам поновлює вхід. Сторінки налаштування для інших клієнтів, зокрема Cursor і Codex, — у документації.

Що буде, коли наступного дня я перейду з ChatGPT на Claude Code?

Ось випадок, під який і написано цю інструкцію.

1. У понеділок ти плануєш фічу в ChatGPT. Ви вирішуєте зберігати завантаження в об’єктному сховищі, а не в базі даних, і ChatGPT викликає record_decision з контекстом, обома варіантами й наслідками, прив’язавши запис до завдання «Завантаження файлів».
2. У вівторок ти відкриваєш Claude Code в репозиторії. Якщо ти його ще не підключив: claude mcp add --transport http weft https://letsweft.com/api/mcp.
3. Ти просиш його взятися за завдання із завантаженнями. Перш ніж писати код, він викликає get_context для цього завдання або get_task_history у режимі decisions і отримує понеділковий запис.
4. Він будує рішення на об’єктному сховищі, а не відкриває питання заново. Якщо він знайде вагому причину, чому вибір хибний, то може запропонувати нове рішення, яке замінить понеділкове, — а вирішуєш ти.

Обидва клієнти читають ту саму дошку й ті самі рішення, бо запис живе у Weft, а не в жодному з чатів. Кожне OAuth-підключення — окремий виконавець, а дошка показує ім’я, з яким зареєструвався кожен клієнт, тож видно, яке підключення створило яке завдання. Як запускати кількох агентів на одній дошці без колізій — у статті «кілька ШІ-агентів, одна дошка».

Куди мають потрапляти рішення з ChatGPT?

Чотири поширені місця, порівняні за тим, що потрібно журналу рішень:

Йдеться не про те, що чат чи документи погані. Чат — це місце, де ти думаєш. Рішення треба винести з чату в щось, що має стан, у момент, коли його ухвалено, і зробити це має той, хто вже є в розмові: ШІ.

Чи замінює це нашу документацію чи вікі?

Ні. У Weft немає документів чи вікі, і він не намагається ними стати. Довгі пояснення, посібники для онбордингу й описи дизайну мають жити у твоєму інструменті для документації. Запис рішення навмисно малий: один вибір, його причини і що його замінило. Якщо твоя команда вже веде записи рішень у вікі, а кожен твій ШІ-клієнт може її читати, цього може бути досить. Weft корисний тоді, коли рішення ухвалюються в чатах зі ШІ, а наступним читачем часто буде інший ШІ. Якщо зважуєш для цього Notion, подивися альтернативи Notion для завдань зі ШІ.

Ще два чесні обмеження. Weft не читає твої чати: рішення записується лише тоді, коли ШІ викликає record_decision, — тому інструкція вище й важлива. А ще ШІ може помилитися в тому, що вважати рішенням, тож час від часу переглядай get_context і замінюй усе, що він записав неправильно.

Скільки це коштує?

Записувати й читати рішення можна на безкоштовному тарифі, який включає 50 активних завдань і 200 викликів ШІ-інструментів на місяць. Кожен виклик record_decision чи get_context рахується як один. Pro коштує $7 за місце на місяць або $60 за місце на рік, з необмеженими завданнями й викликами (ціни). У Weft немає ШІ-кредитів: думання відбувається у твоєму власному ШІ-клієнті, а Weft лише зберігає дошку і її записи.

Хіба не можна просто попросити ChatGPT підсумувати рішення наприкінці чату?

Можна, і це допомагає. Але підсумок однаково живе в тому чаті або там, куди ти його вставиш. Він не прив’язаний до завдання, інший ШІ-клієнт не може його прочитати, а коли рішення зміниться, не лишиться запису про те, що воно замінило. Запис кожного рішення в момент ухвалення знімає всі три проблеми.

Чи записуватиме ШІ рішення, якщо його не просити?

Опис інструмента record_decision каже ШІ використовувати його щоразу, коли користувач робить у розмові справжній вибір, тож деякі клієнти так і робитимуть. Не покладайся на це. Вставлена інструкція робить це явним, а ти завжди можеш сказати «запиши це рішення».

Чи можна відредагувати рішення, якщо його записали неправильно?

Не на місці. Записи незмінні. Запиши виправлене рішення з supersedesId, що вказує на хибне. Старий запис лишиться з позначкою superseded, і get_context перестане його показувати.

Чи потрібне рішенню завдання?

Ні. Рішення можна прив’язати до завдання, до проєкту або ні до чого. Якщо прив’язати його до завдання, get_task_history покаже його поруч із цією роботою, а get_context можна буде звузити до нього.

Це те саме, що робоча пам’ять Weft?

Ні. Робоча пам’ять (короткі засвоєні нотатки) — окрема функція Pro. Записи рішень створює record_decision, і код не обмежує їх тарифом Pro.

А якщо я користуюся кількома ШІ-клієнтами?

Саме заради цього це й варто робити. ChatGPT, Claude Code, Cursor чи Codex, підключені до того самого робочого простору Weft, читають ті самі рішення через get_context, тож другий клієнт не відкриває заново питань, які закрив перший.