Клієнт усередині пайплайна
SDLC 2.0 Policy: клієнт створює задачі напряму в пайплайні, а low-risk задачі їдуть у прод без очікування людини — human gate замінює не порожнеча, а два AI-гейти. Ризик тримають межі доступу, hard exclusions та авто-роллбек.
Базовий стандарт → Embedded Client
Пайплайн лишився той самий — сім фаз і людська відповідальність. Змінилось, хто заводить задачу і чим замінюється human gate на low-risk потоці
risk:* лейбл до 15 хв; requester бачить, але не змінюєrepo:* лейблами і blocking relationsЧотири правила, які тримають швидкість безпечною
Мета — дати клієнту бути повноцінним учасником delivery, не віддаючи контроль над ризиком
Клієнт визначає ЩО, пайплайн — ЯК
Requester приносить проблему й acceptance criteria. Маршрут, виконавця та швидкість визначає система — це не предмет домовленості в чаті
Автоматизація не змінює scope
Автоматика рухає задачу всередині затвердженого scope і змінює лише її стан. Нова вимога = нова задача, а не розширення поточної руками агента
Швидкість = заміна гейта, а не його пропуск
Fast-track не викидає перевірки. Він міняє human gate на AI gate: код-рев'ю і QA лишаються обов'язковими, просто виконуються за хвилини
«Не може зашкодити проду і даним»
Рівень доступу клієнта обмежений цим принципом. Все, де помилка ламає дані, контракти чи платежі, лишається за пайплайном
Один вхід. Три треки за ризиком
Кожна задача заходить однаково — і розходиться на треки після risk-лейбла. Натисніть трек, щоб побачити правило
Сім фаз — обирайте фазу
Маршрут однаковий для будь-якого клієнта й репозиторію. Колір показує власника фази; на fast-track ворота фаз 04 і 06 виконує AI
Хто за що відповідає
Шість ролей, з них чотири — автоматичні. Людина лишається там, де потрібне рішення, а не виконання
| Роль | Тип | Відповідальність |
|---|---|---|
| Client (Requester) | людина | Створює задачу, дає опис, файли й контекст, приймає результат |
| Linear + Loops | AI | Оцінює ризик задачі, ставить risk:low / medium / high, роутить виконавця та зачеплені репозиторії |
| Cyrus · AI Engineer | AI | Виконує задачі з лейблом risk:low, відкриває PR у межах одного репозиторію |
| AI Code Review · CodeRabbit | AI gate | Перший гейт: якість коду, безпека, регресії |
| AI QA | AI gate | Другий гейт: перевірка acceptance criteria на staging |
| Delivery Lead / Tech Lead | людина | Human gate для risk:medium+, ескалації, ретро fast-track інцидентів, зміна класу репозиторію |
Definition of Ready — вхідний квиток
Задача валідна для пайплайна, коли виконані всі п'ять умов. Спробуйте: увімкніть пункти й подивіться, що станеться
Як задача отримує свій маршрут
Loops аналізує опис, вкладення та зачеплені області кодової бази. Hard exclusions перевіряються до оцінки — і перекривають будь-який вердикт моделі
Спробуйте: який трек отримає ваша задача
Оберіть, чого торкається зміна — праворуч зʼявиться лейбл, маршрут і причина рішення
Шість зон, які ніколи не бувають low-risk
Незалежно від оцінки Loops і від того, наскільки зміна виглядає дрібною
Дані та схеми
Міграції й будь-які зміни схеми даних
Доступ
Автентифікація, авторизація, ролі, permissions
Гроші
Платіжні флоу та білінг
Видалення даних
Видалення або масова зміна даних
Інфраструктура
Секрети, environment variables, CI/CD конфіги
Контракти
Зміни API-контрактів між репозиторіями
Шлях задачі від клієнта до прода
Натисніть «Програти», щоб побачити рух задачі. Увімкніть «Гейт падає» — і трек поверне задачу на людину
Чотири умови, без яких трек не працює
Обидва гейти — APPROVE
Будь-який CHANGES REQUESTED від AI Review або FAIL від AI QA миттєво переводить задачу на human gate. Часткового проходження немає
Максимум 5 self-fix ітерацій
Cyrus має пʼять спроб виправити зауваження AI Review. Наступна невдача — ескалація людині. Ліміт ловить задачі, де проблема в постановці, а не в коді
Guard window
Деплой тільки в робочі години команди. PR, готовий о 23:40, чекає ранку — щоб на інцидент було кому реагувати
Автоматичний rollback-тригер
Сплеск помилок у Sentry або падіння health-check відкочує реліз і створює інцидент-задачу. Рішення про відкат не чекає людини
Коли деплоїмо і що робимо, коли впало
Клієнт пише проблему. Пайплайн ріже на репозиторії
Cyrus працює в межах одного репозиторію на задачу. Тому крос-репозиторні задачі декомпозуються через sub-issues з repo:* лейблами — клієнту не треба думати про репо
| Лейбл | Репозиторій | Клас |
|---|---|---|
repo:marketing-site | Marketing website (static) | client-editable |
repo:shopify-plugin | Shopify plugin + backend API | restricted |
repo:frontend-app | Frontend app (dashboard) | guarded |
repo:demo-shopify-plugin | Demo shopify plugin | guarded |
repo:demo-frontend | Demo frontend | guarded |
Єдиний human gate, який не делегується AI
Cyrus у двох різних репо не має спільного контексту. Без зафіксованого контракту він згенерує два несумісні варіанти. Перемкніть сценарій:
Де можна швидше і як закривається parent
demo Демо їде швидше
QA Дворівневе приймання
Least privilege, згенерований разом із пайплайном
Доступи не роздаються «по запиту в чаті» — вони є частиною конфігурації проєкту
| Ресурс | Доступ клієнта | Обґрунтування |
|---|---|---|
| Linear (проєкт клієнта) | Create / comment / read | Основний канал участі |
Лейбли risk:* | Read only | Ризик визначає система, не requester |
| Staging | Full UI access | Перевірка результату до і після AI QA |
| Preview deployments | Read | Рання перевірка PR |
| Production | Тільки як користувач продукту | Жодних адмін-панелей деплою |
| GitHub / репозиторії | Owner; рівень write — per-repo | Клієнт є власником; межі прямих змін фіксуються для кожного репо окремо |
| CI/CD, інфраструктура | Немає прямого доступу до конфігурації | Зона відповідальності Aimeice, включно з механізмами відкату |
| Sentry / телеметрія | Дайджест у Slack | Дані можуть містити PII |
| Slack-канал проєкту | Учасник | Нотифікації про статуси й релізи |
Питання не у власності, а в безпеці прямих змін
Клієнт — власник репозиторіїв. Кожен репозиторій при генерації пайплайна отримує клас. Оберіть клас:
Fast-track знімає чергу лише з low-risk
Задачі medium і high далі впираються в людські ворота. Без WIP-лімітів конвеєр просто набиває черги перед ними — і виграш fast-track зʼїдається очікуванням решти
Ліміти лише на людських фазах
In Review ≤ 2 на дева · QA ≤ 3 на інженера · Ready to Deploy ≤ 5 на команду. На AI-фазах лімітів немає
Cap на агента
Cyrus веде максимум 3–5 build-задач одночасно. «Закинути 30 задач на ніч» = черга перед рев'ю і поверхневі гейти
Aging-алерт замість стендапа
Задача понад 24 год без руху перед воротами → пінг власника воріт у Slack. Черга — метрика, яку видно
Що ми міряємо на fast-track
Щотижневе ревю метрик — зобовʼязання Aimeice за цією політикою. Ви бачите ті самі цифри, що й ми
Що гарантуємо ми і що бере на себе клієнт
Aimeice Tech
Клієнт
Політика має власний запобіжник
Fast-track не є вічною домовленістю. Потягніть повзунок — це rollback rate за місяць:
Квартальний перегляд
Політика переглядається щокварталу — незалежно від метрик. Критерії risk:low звужуються або розширюються за фактичними даними
Перегляд після інциденту
Кожен production-інцидент, спричинений fast-track релізом, тягне ретро й перегляд політики. Без винятків і без «це разовий випадок»
Вісім правил, на яких усе тримається
Фази — це механіка. Принципи — це причини. Вони відрізняють систему від «накидали AI всюди»
Spec-first
Специфікація важливіша за код. DoR і acceptance criteria затверджуються до старту. Туманна спека = AI заповнює прогалини здогадками про бізнес, якого не знає
AGENTS.md у кожному репо
Один файл із конвенціями, стеком і do/don't для агента. Де-факто стандарт 2026. Дешево, одразу піднімає якість
Маршрут за ризиком, не за зусиллям
Зміна на один рядок у білінгу — high-risk. Зони auth / payments / migrations / PII завжди йдуть до людини, скільки б їх не було
AI рев'юїть, але не себе
Генератор і рев'юер — різні агенти з різними лінзами. Той самий агент має ті самі сліпі плями
Вісім правил, на яких усе тримається
І бонус — те, що клієнти цінують найбільше: ви бачите процес, а не лише результат
Ворота не зникають — вони змінюють виконавця
На fast-track рев'ю і QA виконує AI, але вони обовʼязкові. Пропущений гейт = не швидкий трек, а відсутність процесу
Least privilege за класом репо
Доступ визначає не посада й не власність, а питання «що станеться з продом, якщо тут помилитись»
Кожен авто-реліз має адресу для відкату
Rollback-тригер, tag останнього стабільного релізу, інцидент-задача. Автоматизація без відкату — це не автоматизація
Прозорість за замовчуванням
Результати AI-гейтів, деплої та метрики видимі клієнту в Linear і Slack у реальному часі. Ви бачите, як задача рухається пайплайном
Звичайна сервісна компанія vs Aimeice
Це не «той самий процес, але швидше». Це інша операційна модель
Тиждень 1 — межі, доступи, вхід
Мета: клієнт може створити задачу, і система знає, що з нею робити
repo:* лейбл. Branch protection на guarded, заборона прямих змін на restrictedrisk:* — read only для клієнта. Розширення фіксуються в README пайплайнаТиждень 2 — перший авто-реліз
Мета: задача від клієнта проходить трек наскрізь, а метрики fast-track починають накопичуватись
Ви всередині.
Не в черзі.
Ми не продаємо години розробників. Ми продаємо вимірюваний цикл доставки, у якому клієнт — учасник, а не замовник у черзі.
Готові побудувати разом?
Обговоримо, які ваші репозиторії можуть отримати fast-track уже цього місяця