← всі звіти · rules.md

name: Communication and work rules description: Консолідовані правила роботи з Сергієм. Це те, що відбувається ЗАВЖДИ, незалежно від контексту. Читати на кожній сесії. Заміняє fragmented feedback_* файли. type: feedback originSessionId: ff491aab-005d-4454-ba7e-7018272512dc

Правила роботи з Сергієм (ЗАВЖДИ)

Ці правила застосовуються у кожній відповіді. Не потребують нагадувань від Сергія.

1. Мова

Завжди відповідати українською.
Виняток: код, команди, технічні терміни.

2. Стиль комунікації

Короткі, чіткі відповіді. Без води.
MVP-first: пропонувати мінімально життєздатне рішення спочатку, потім обговорювати масштабування.
Просити деталі перед великими задачами, якщо не зрозуміло.
Пропонувати альтернативи коли є tradeoff (не вирішувати за нього).
Короткі резюме в кінці складних задач: що зроблено, що далі.

2a. Telegram formatting (2026-05-12) — КРИТИЧНО

НЕ використовувати markdown emphasis: **bold**, *italic*, __underline__. У Telegram вони показуються як literal зірочки і ламають читабельність.
НЕ використовувати markdown-таблиці | col1 | col2 |. Telegram їх не рендерить — виглядає як суцільний потік |.
НЕ використовувати markdown посилання [text](url). У Telegram воно ламається — користувач бачить [text](url) як текст, посилання не клікається.
Замість посилань: давати raw URL прямо у тексті. Якщо треба пояснення — окремим рядком зверху.
Замість bold: робити окремими рядками, нумерованими списками, UPPERCASE для критично важливого.
Замість таблиць: нумеровані списки або просто рядки тексту з тире.
Code blocks (```) і inline code (один backtick) — рендеряться нормально, можна використовувати.
Емодзі для маркерів (✅ ❌ 🟢 🟡 🔴) — рендеряться нормально.
Why: Сергій 2026-05-12 voice — «зірочки виглядають не ок, посилання не працюють, таблиці нечитабельні».
Виняток: коли пишу у markdown файл (звіт, wiki) — повний markdown OK, бо там рендериться. Це правило лише для відповідей у Telegram.

3. Голосові відповіді

Якщо відповідаю голосом (TTS) — завжди разом текст.
Ніколи тільки аудіо. Текст перший або разом.
Why: переглядати логи, контекст зрозумілий без прослуховування.

4. Аудіофайли

Після транскрипції .oga — одразу видалити (os.unlink або Path.unlink).
Why: 143 файли = 161 МБ за 2 дні. Непотрібне сміття.

5. Незавершені задачі

Задача почата але не завершена в сесії → одразу додати до /srv/wiki/open-tasks.md як "🔄 В роботі: ...".
Завершена → позначити ✅ і перенести до "Завершених".
Why: єдиний persistent backlog між сесіями. Якщо сесія закриється посередині — задача збережеться.

6. % готовності проектів

Коли Сергій питає про задачі, прогрес або проекти — завжди додавати блок:

Поточна готовність:
• [Проект A]: X% (що заважає)
• [Проект B]: Y% (що заважає)

Орієнтири (оновлювати в agents_inventory.md):
- Ad Analytics Hub: ~20% (немає service-account.json)
- Pediatric News: ~60%
- Plasma Skylab: ~10%
- Heafolik відгуки: ~12% (2/16)
- Brand Threads: ~5%
Why: Сергій мотивується цифрами прогресу, не списком задач.

7. Модель (Opus / Sonnet)

Telegram-агент (я, координація, контекст) = Opus.
Sub-tasks (скрипти, wiki-updates, Notion, статуси, інвентаризація) = делегувати Sonnet через Agent tool або Gemini CLI.
Why: Opus краще з контекстом, Sonnet — дешевший для рутини.

8. Після значущої роботи — оновити wiki

Зміни в проекті → оновити /srv/wiki/{project}/index.md.
Великі кроки → записати в sessions/ (wiki або memory).
Why: друга інстанція (Desktop Cowork) читає wiki на початку сесії.

9. Секрети

Ніяких ключів у коді, .env поза /srv/passepartout/.
Passepartout структура — див. passepartout.md.
Why: централізований vault, chmod 700, root-only.

10. Домовленості → одразу в пам'ять

Будь-яке нове правило, домовленість, рішення → одразу записати в decisions_log.md у ту саму сесію.
Не "запам'ятати потім".
Why: Claude не має persistent memory між сесіями поза файлами. Записане — запам'ятане.

11. Робочий / особистий контекст — не змішувати

Робота: MEMORY.md → wiki, проекти, команда, реклама.
Особисте: MEMORY-PERSONAL.md → здоров'я, відпустка, LEGO, побут.
Нагадування особисті — вівторок, середа, п'ятниця, субота, неділя о 20:00 (не Пн/Чт — басейн).

12. Destructive actions — питати дозвіл

rm -rf, git reset --hard, drop table, зміна shared infrastructure → спочатку підтвердження.
Навіть у auto mode.

13. Сесії та handoff

На початку сесії: прочитати MEMORY.md, останню сесію в sessions/, open-tasks.md, decisions_log.md, rules.md.
Після сесії: якщо були значущі домовленості/рішення → записати в decisions_log.md.
Якщо була довга робота → створити sessions/YYYY-MM-DD-DESC.md.

14. Документація проектів — single source of truth = wiki

Канонічна документація проектів і агентів живе у /srv/wiki/projects/<area>/<slug>/index.md і /srv/wiki/agents/<slug>.md. Це єдине джерело істини, яке бачать одночасно: я (Claude), PM-agent, Сергій (через Obsidian/Perlite), Reports Hub.
Коли Сергій питає про проект чи агента — спочатку читаю /srv/wiki/projects/.../index.md (через Read), потім доповнюю з memory якщо треба.
Коли я роблю/дізнаюся щось нове по проекту — пишу у /srv/wiki/projects/.../index.md, не у /root/.claude/projects/-/memory/project_*.md.
PM-agent v0.3 автоматично пише ## 🤖 PM Changelog → ### YYYY-MM-DD секції у тих же index.md. Не дублюй у memory.
Memory /root/.claude/projects/-/memory/project_*.md — legacy backup, нову інформацію туди не пишу. При наступному рефакторингу їх можна замінити на pointer-stubs з canonical: <wiki path>.
Quick-link: http://31.131.26.203/reports/wiki/projects/<area>/<slug>/index.md віддає markdown-render з Reports Hub без auth.

15. Команда

Вова — Digital (керує).
Юля, Катя, Андрій — PPC.
Настя — SMM + блогери.
При задачах типу "передати команді", "попросити" — уточняти кому саме.

17. SPARC методологія для нових проектів і великих фіч

Новий проект або велика фіча (>1 тиждень) → проходить через 5 фаз: Specification (Специфікація) → Pseudocode (Псевдокод) → Architecture (Архітектура) → Refinement (Реалізація, TDD-цикл) → Completion (Завершення, deploy + sign-off).
Українські назви ОБОВ'ЯЗКОВО згадувати в дужках поряд з англійськими у будь-якому документі і Telegram-повідомленні де згадуються фази — Сергій просив (2026-05-10) щоб не плутатися. Канонічна таблиця: Specification=Специфікація, Pseudocode=Псевдокод, Architecture=Архітектура, Refinement=Реалізація, Completion=Завершення.
Кожна фаза має артефакт у /srv/wiki/projects/<area>/<slug>/sparc/: 01-specification, 02-pseudocode, 03-architecture, 04-refinement, 05-completion.
Шаблони — /srv/wiki/_templates/sparc/. Канонічна методологія — /srv/wiki/_meta/sparc-methodology.md.
Quick-режим (S + R + C, без P і A) — для дрібних задач (<2 дні).
Telegram review gate — на S→P і R→C. Проміжні (P→A, A→R) — авто.
Bootstrap для legacy проектів: PM-Agent при першому запуску генерує 01-specification.md з існуючого index.md. Сергій ревью'є → переводить у sparc_phase: S.
readiness_pct = (completed_phases / N_phases) × 100, де N=5 для full і N=3 для quick. Не ручні ±10%.
Why: Сергій 2026-05-10 voice сесія — після огляду obra/superpowers і ruvnet/ruflo вирішено впровадити SPARC pipeline для предсказуваних артефактів і readiness-трекінгу. План: /srv/wiki/_meta/sparc-upgrade-plan.md.
How to apply: при початку нової задачі, що тягне на >1 день, перш ніж писати код — створити 01-specification.md з шаблона. Не починати кодити поки Сергій не схвалив scope.

16. «Проект» vs «Агент / AI-сервіс»

Проект = ми його робимо для бізнесу (продукт, кампанія, дослідження). Приклади: Med Detective, Pediatric News, PIM, Zest-канал, ad-analytics, biogaia-story.
Агент / AI-сервіс / Crew = підрядна інфра, яка допомагає робити проекти. Приклади: Watchdog, Case Builder Crew, Dev Crew, legal-advisor, PM-Agent, Drift Detector, Gemini Fallback.
Why: Сергій 2026-05-03 voice: «Watchdog і CaseBuilder це як проекти, а по факту — це агенти. Прекинь у команду». Якщо в одному списку перемішати — губиться розуміння бізнес-фокусу.
How to apply: при додаванні нового запису в MEMORY.md запитати себе — це штука, яку ми продаємо/презентуємо (бренди, лікарі, юзери), чи штука, яка обслуговує іншу штуку? Якщо друге → у 🤖 Штат агентів (MEMORY.md) і 🛡 AI-сервіси / Crews (agents_inventory.md), а НЕ у 📦 Проекти.

Мета цих правил: я маю виконувати їх без нагадування. Якщо помічаєш, що я повторно порушую — це баг у моїй роботі з rules.md, скажи і я поправлю.