Інтеграція інструментів: шість сценаріїв

Інструмент має вести до перевіреної зміни

Зовнішній tool корисний не самим фактом підключення, а тим, що допомагає перейти від сигналу до evidence-backed зміни в коді. Спільний каркас однаковий для tracker, monitoring, БД, дизайну, документації та браузерної перевірки.

Інструмент надає контекст, але не замінює task spec, планування, аналіз коду, тести або рішення людини.

зовнішній сигнал
  → гіпотеза
  → обмежений план
  → мала зміна
  → verification
  → артефакт у репозиторії

Як обрати сценарій

• Скарга або запит команди — issue-to-PR.
• Системний сигнал про помилку — monitoring triage.
• Аномалія у фактичних даних — read-only DB.
• Візуальний reference — design-to-code.
• Факт про API, конфігурацію чи версію — docs lookup.
• Перевірка реального UI — browser check.

Issue-to-PR і monitoring triage

1. Прочитайте issue, коментарі або alert.
2. Сформулюйте симптом і поточну гіпотезу.
3. Знайдіть affected area у codebase.
4. Зафіксуйте scope, non-goals і спосіб відтворення.
5. Внесіть найменшу зміну.
6. Підтвердьте її тестом і review.
7. Збережіть висновок у TASK_SPEC.md або EVIDENCE_LOG.md.

Дані, дизайн і документація

Read-only DB допомагає відповісти, що сталося, але не пояснює чому. Причину потрібно шукати в code path і тестах, а не лікувати дані ручними UPDATE або DELETE.

Макет є візуальним reference, але не дає дозволу на масштабний UI-рефакторинг. Документація уточнює очікуваний API конкретної версії, але її потрібно зіставити зі структурою власного проєкту.