Playable production
Схема роботи команди
15 / 09 / 2026 · ПРОПОЗИЦІЯ
Від ідеї до рекламного HTML

Один процес.
Спільні інструменти.

Колега описує задум у Claude Code. Репозиторій дає код, правила й перевірки. Команда погоджує playable перед передачею в рекламну мережу.

Запропонований процес · автоматизацію ще треба налаштувати
Натисніть на етап → інструменти, дії та результат
GitLab · ab-playablesКод playable, підготовлені assets, правила, тести
Claude Code + skillsРобота на комп’ютері колеги · спільні MD-інструкції
Готовий набір assetsІз playable; повторне витягування не потрібне
↓ Клонуємо репозиторій · встановлюємо залежності · відкриваємо Claude Code ↓
На комп’ютері колеги
GitLab · автоматичні перевірки + рев’ю
Команда / мережа
↶ Помилка тесту або правки на рев’ю → повертаємось до playable → нова збірка → повторна перевірка

Дії та інструменти
    Результат / умова переходу

    Що саме робить кожен інструмент

    Ролі в запропонованому процесі
    Claude Code

    Читає бриф і skills, змінює код, запускає локальні команди. Кожен колега працює зі своїм доступом.

    Skills + CLAUDE.md

    Спільні правила: як брати assets, будувати playable, перевіряти й передавати результат. Project skills — у .claude/skills/.

    Git + Git LFS

    Git зберігає історію. LFS потрібен для отримання великих файлів із game repo, якщо вони зберігаються через LFS.

    Python + Node.js

    Скрипти готують ресурси, збирають HTML та запускають перевірки. Версії залежностей потрібно зафіксувати.

    Playwright

    Автоматично відкриває Chromium / WebKit: input, поворот, пауза, CTA, скриншоти. Також використовується в наявному animation bake.

    GitLab + CI runner

    Спільний repo, гілки, merge requests та автоматичні build / QA. Runner — середовище, що запускає команди після push.

    Cloudflare + Wrangler

    Публікують перевірений HTML як preview. Токен зберігається в CI variables; він не входить у код чи HTML.

    Network preview + телефони

    Фінальна перевірка в середовищі рекламної мережі та на iOS / Android. Browser QA не доводить прийняття мережею.

    Що потрібно підготувати для запуску

    Пропозиція до реалізації
    Основа repo

    Перенести Arcane Blade як перший приклад; додати onboarding, brief template та локальну конфігурацію шляхів.

    Переносимість

    Прибрати персональні шляхи, встановлювати Playwright локально, додати setup / build / test команди.

    Автоматизація

    Налаштувати runner, CI, preview для змін і збереження фінального HTML разом із QA-звітами.

    Перевірка передачі

    Колега на іншому комп’ютері відтворює Arcane Blade, змінює його й отримує preview без ваших локальних папок.

    Факти

    Основа вже є

    У source folder Arcane Blade є build.py, src/, assets/, reference/, qa/ та production guide. Під час огляду 15/09/2026 SHA-256 публічного HTML збігся з qa/build.json. Це перевірка файла, не новий запуск усіх тестів.

    Джерело: outputs/applovin-level-1-1/ARCANE-BLADE-PLAYABLE-GUIDE.md, розділи 1, 8–9; qa/build.json. Наявний preview ↗

    Припущення / пропозиція

    Один спільний repo

    Плануємо ab-playables для кількох ігор, із Arcane Blade як першим прикладом. Claude працює локально; CI запускає звичайні скрипти. Автономний Claude у CI на першому етапі не потрібен.

    Запропоновано зберігати підготовлені assets із playable. Game repo читаємо лише для нового імпорту або оновлення джерела.

    Ще не підтверджено

    Доступи та launch-вимоги

    Потрібні GitLab namespace, runner, політика доступу до assets, конкретні skills і цільова рекламна мережа. Game branch / commit погоджуємо перед новим extraction.

    Поточний build не має налаштованих store URLs. Device QA та network acceptance залишаються відкритими за production guide. Ця схема не означає, що pipeline вже створено.