Команди, промпти і каркаси файлів для кожного кроку завдання С4: зібрати чинні правила своєї функції в spec.md (L1), змінити їх через пропозицію (L2), застосувати зміну і перевірити узгодженість (L3) — і здати через merge request. OpenSpec CLI — за бажанням: без нього ті самі файли і ручний чек-лист.
gitlab.com/koldovsky/ai-qa-ba-c4
У теці клону є: templates/validation-checklist.md
Форк і клон — як у С1–С3, але проєкт новий. Агента запускаєте у своїй теці submissions/ваш-username/: там він створить openspec/, і там же лежатиме звіт. Лише браузер — теж можна: пункт унизу розділу.
Де / що: gitlab.com · крок 0 README · пошта в комітах · уже зробили в С1–С3 — пропустіть
аватар → Edit profile → Commit email → Use a private email → Update profile settings
Очікуваний результат: У полі Commit email — прихована адреса вигляду …@users.noreply.gitlab.com. Коміти з браузера і через GitLab MCP не покажуть вашої справжньої пошти.
Де / що: Браузер · сторінка gitlab.com/koldovsky/ai-qa-ba-c4
Fork → namespace: ваш username → Fork project
Очікуваний результат: Відкрилася ваша копія: gitlab.com/ваш-username/ai-qa-ba-c4.
Форк робіть зі сторінки koldovsky/ai-qa-ba-c4, а не з чужої копії — інакше в merge request потраплять чужі файли.
Де / що: Термінал: Windows — PowerShell, macOS — Terminal · замініть ваш-username на свій username gitlab.com
cd ~ git clone https://gitlab.com/ваш-username/ai-qa-ba-c4.git cd ai-qa-ba-c4
Очікуваний результат: Тека ai-qa-ba-c4 у домашній теці, термінал — у ній. Усередині — README.md, OPENSPEC.md, templates/, examples/00-demo/ і submissions/.
Перевірка Git — git --version. На Windows Git зазвичай уже встановлено разом із Claude Code; на macOS після цієї команди система сама запропонує встановити Git. Не вдалося клонувати — найчастіше помилка в username: скопіюйте адресу зі своєї копії (Code → Clone with HTTPS).
Де / що: Термінал у корені клону (ai-qa-ba-c4) · далі все робите в submissions/ваш-username
mkdir submissions/ваш-username cd submissions/ваш-username claude
Очікуваний результат: Claude Code запущено у вашій теці. Тека вже є — mkdir повідомить, що вона існує: це нормально, cd і claude спрацюють.
Назва теки — саме ваш username на gitlab.com, без помилок у «submissions»: тека з іменем замість username чи «submisions» — і роботу не знайдуть.
Без клону і терміналу теж можна: агент чи AI-чат пише файли за шаблонами з templates/, а ви створюєте їх у своїй копії через + → New file (розділ 8). Не виходить файлами — вставте вміст кожного файлу в c4.md, розділ «Додаток», блоками коду: зараховується так само. CLI тоді не потрібен — перевірка ручним чек-листом (розділ 6).
Claude Code зі вступного пакета: інший агент чи AI-чат теж підійде, але інструкція до OpenSpec CLI — лише для Claude Code. Акаунт на gitlab.com — той самий, що в С1–С3. Git — для клону. Для CLI — ще Node.js 20.19 або новіший (розділ 5).
Агент працює з джерелами, а не з пам'яті. Джерела — ті самі, що в С2–С3. Спершу перевірте, що агент їх бачить, — і лише потім просіть специфікацію. NN — номер варіанту, NN-slug — назва теки з таблиці варіантів у README (наприклад, 01-courier-slots).
Де / що: Браузер · матеріали С2 · замініть NN-slug
https://gitlab.com/koldovsky/ai-qa-ba-c2/-/tree/main/materials/variants/NN-slug
Очікуваний результат: requirement.md — вимога, sources.md — матеріали до неї, bug-report.md — звіт про дефект.
Де / що: Браузер · база знань С3 · замініть NN-slug
https://gitlab.com/koldovsky/ai-qa-ba-c3/-/tree/main/kb/NN-slug
Очікуваний результат: overview.md — продуктова сторінка, decisions.md — журнал рішень, support-faq.md — FAQ контакт-центру.
Де / що: Браузер · задачі трекера С3 · замініть NN у кінці мітки на номер варіанту — або клікніть «варіант::NN» у таблиці README
https://gitlab.com/koldovsky/ai-qa-ba-c3/-/issues?label_name%5B%5D=%D0%B2%D0%B0%D1%80%D1%96%D0%B0%D0%BD%D1%82%3A%3ANN&state=all
Очікуваний результат: Задачі варіанту — і відкриті, і закриті. Рішення часто лише в коментарях: відкрийте кожну задачу. Задача з міткою тип::сторі — ваша зміна для L2.
Без &state=all видно лише відкриті задачі. У варіантах 01, 02 і 08 сторі вже закрита і випущена — вона частина чинної правди L1, а для L2 беріть інше (розділ 4).
Де / що: Claude Code у submissions/ваш-username · чи підключено GitLab MCP із С3
/mcp
Очікуваний результат: У списку є GitLab зі статусом connected — агент читатиме сторінки й задачі через MCP.
GitLab немає — у С3 ви, найімовірніше, підключали MCP через .mcp.json копії С3, а він працює лише в тій теці. Додайте сервер для всіх тек (наступна картка) або працюйте без MCP (пункт унизу розділу). GitLab — failed або not connected: /mcp → GitLab → Authenticate.
Де / що: Термінал, до запуску claude · лише якщо GitLab немає в /mcp · одним рядком, як у SETUP.md С3
claude mcp add -s user --transport http GitLab https://gitlab.com/api/v4/mcp --header "X-Gitlab-Enabled-Mcp-Server-Toolsets: core,work_items,repository"
Очікуваний результат: Сервер GitLab додано для всіх ваших тек (-s user). Далі: claude у submissions/ваш-username → /mcp → GitLab → Authenticate → вхід у браузері.
Не набирайте вручну — копіюйте. «MCP server GitLab already exists» — сервер уже додано: claude mcp list. 403 «MCP server not enabled for any of your groups» — як у С3: потрібне членство в групі курсу; подробиці — SETUP.md С3.
Де / що: Claude Code у submissions/ваш-username · перевірка джерел · замініть NN і NN-slug
Через GitLab MCP покажи назви всіх задач з міткою варіант::NN у koldovsky/ai-qa-ba-c3 — відкритих і закритих, зі станом і посиланням — і список файлів у kb/NN-slug/ того самого проєкту та в materials/variants/NN-slug/ проєкту koldovsky/ai-qa-ba-c2. Нічого не змінюй.
Очікуваний результат: Задачі [NN-1]… з посиланнями на gitlab.com і станом; у kb/ — overview.md, decisions.md, support-faq.md; у С2 — requirement.md, sources.md, bug-report.md. Claude Code просить дозволу на виклики GitLab — це читання.
Задач не знайдено — мітка варіант::NN пишеться кирилицею, потрібні і відкриті, і закриті. У записі демо 1 агент спершу набрав мітку частково латиницею («variант::00»), отримав порожній список і сам повторив пошук з «варіант::00».
Ваш варіант: відкрийте файли й задачі за посиланнями вище і вставте текст у чат агента або збережіть у підтеку sources/ своєї теки — усі файли: requirement.md, sources.md, bug-report.md (С2), overview.md, decisions.md, support-faq.md (С3) і issues.md — задачі з коментарями. У задачах копіюйте й коментарі — з авторами й датами. Потім у промпті L1 замініть блок «Джерела» рядком нижче. Демо-варіант 00: готові копії джерел уже є в клоні — examples/00-demo/sources/ (вимога С2, три сторінки бази знань і задачі [00-1]–[00-3] з коментарями). Тоді в промпті заборону «теки examples/ не відкривай» звузьте до готових відповідей examples/00-demo/l1/, l2/ і l3/.
Джерела: лише локальні файли в sources/ цієї теки — <перелік файлів>. Задачі — разом із коментарями. Інших файлів не відкривай.
Поточна правда на 14 жовтня 2026. Де джерела розходяться — вирішують дати рішень, як у С3: хто, коли і де вирішив. Пізніше рішення власника продукту — у decisions.md чи в задачі — важить більше за старішу редакцію сторінки. Скасована обіцянка в специфікацію не потрапляє. Відкрита, ще не реалізована сторі — ще не чинна правда: це зміна для L2. Чого немає в джерелах — у відкриті питання звіту, а не в SHALL.
Файл openspec/specs/<capability>/spec.md. Capability — назва теки варіанту без номера: courier-slots, refuse-return, trusted-person, home-pickup, damage-claim, loyalty-points, partial-cod, notifications, locker-booking, promo-codes. Щонайменше 6 вимог: одна поведінка, SHALL або MUST, рядок «Джерело: …», у кожної — сценарій WHEN/THEN; серед сценаріїв — щонайменше 2 негативні або межові (QA — 3). Перевірка — openspec validate назва-функції (розділ 5) або чек-лист, розділи А і В (розділ 6).
Де / що: Claude Code у submissions/ваш-username · нова сесія · замініть усе в <…>; QA — «QA-інженер» і «щонайменше три негативні або межові»
Ти — <бізнес-аналітик / QA-інженер> команди «<команда вашої функції з kb/team.md С3>» сервісу «Пакунок». Склади специфікацію функції «<назва функції з таблиці README>» у форматі OpenSpec: файл openspec/specs/<capability>/spec.md. Джерела (читай через GitLab MCP): - koldovsky/ai-qa-ba-c2: materials/variants/<NN-slug>/ — requirement.md, sources.md, bug-report.md; - koldovsky/ai-qa-ba-c3: kb/<NN-slug>/ — overview.md, decisions.md, support-faq.md; задачі з міткою варіант::<NN> (відкриті й закриті) разом із коментарями. Правила: - спека описує поточну правду на 14.10.2026; де джерела розходяться — бери новіше рішення (дата, хто ухвалив); - відкрита, ще не реалізована сторі — не поточна правда, у спеку її не включай; - формат: # <capability> Specification, ## Purpose (2–4 речення), ## Requirements; кожна вимога — ### Requirement: …, одна поведінка, «Система SHALL …»; під описом — рядок «Джерело: …» (файл і розділ або задача і коментар із датою); у кожної вимоги щонайменше один #### Scenario: з - **WHEN** … - **THEN** …; серед сценаріїв щонайменше два негативні або межові; - заголовки, SHALL/MUST і WHEN/THEN — англійською, решта — українською; - нічого не вигадуй: чого немає в джерелах — окремим списком «Відкриті питання» у відповіді, не в спеці. Інших варіантів і теки examples/ не відкривай.
Очікуваний результат: Claude Code просить дозволу на читання через GitLab (get_repository_file, list_work_items, get_work_item) і на запис spec.md. У відповіді — як агент розв'язав розбіжності, що свідомо не включив, відкриті питання. У записі демо 1: 10 вимог, у кожної «Джерело» і 2 сценарії; агент узяв новіші рішення (межа 20:00 з 19.05, галочка «Зробити це відділення основним» з 12.08 і релізу 3.4, сайт перенесено на 2027), а відкриту сторі [00-3] не включив. Валідатора агент не запускав — формат перевіряєте ви: розділ 5 або 6.
Агент відкриває інші варіанти чи examples/ — зупиніть його (Esc) і повторіть промпт. Без MCP — замініть блок «Джерела» (розділ 2, «MCP не працює»). Вимога без джерела, вигадане число чи строк — не помилка формату: validate їх не побачить, перевіряєте ви.
Де / що: Каркас spec.md · openspec/specs/<capability>/spec.md · повний шаблон з підказками — templates/spec-template.md
# <capability> Specification ## Purpose <2–4 речення: що робить функція і для кого> ## Requirements ### Requirement: <назва: одна поведінка> Система SHALL <що робить і за яких умов>. Джерело: <файл і розділ / задача і коментар із датою / власний запит, п. N>. #### Scenario: <назва звичайного сценарію> - **WHEN** <умова або дія> - **THEN** <видимий результат> #### Scenario: <назва негативного чи межового сценарію> - **WHEN** <умова не виконана або на межі правила> - **THEN** <що робить система>
Очікуваний результат: Блок від ### Requirement до останнього сценарію повторіть для кожної вимоги — щонайменше 6. Заголовки — дослівно, з такою самою кількістю решіток. Коментарі-підказки шаблону перед здачею видаліть.
Великими латинськими літерами, у тексті вимоги під заголовком — не лише в назві. SHALL або MUST — обов'язково: у джерелі звучить як «лише», «не більше двох», «завжди». SHOULD — рекомендовано, відхилення — з причиною: «бажано», «рекомендовано». MAY — дозволено, не обов'язково: «за бажанням». Не пом'якшуйте правило до SHOULD, якщо джерело цього не каже. Для QA: порушене SHALL — дефект, SHOULD — зауваження, відсутність того, що MAY, — не дефект. Шаблон фрази:
Система SHALL дозволяти не більше двох змін адреси на одну посилку.
Одна поведінка: «і ще», «а також», два правила в одному реченні — це дві вимоги. Перевірювана: без «зручно», «швидко», «за потреби»; «швидко» без числа — у відкриті питання. Без «як»: без технологій, полів бази даних, API і верстки; назви кнопок і тексти повідомлень, які бачить користувач, — можна. Текст вимоги — усе від заголовка до першого сценарію, разом із рядком «Джерело: …», — до 500 символів; деталі — у сценаріях. Швидкий тест: напишіть до вимоги сценарій. Не виходить один THEN, який можна перевірити, — вимогу треба ділити або уточнювати.
Заголовок — рівно чотири решітки: #### Scenario: <назва>. З трьома OpenSpec сценарію не бачить. Рядки — пункти списку: - **WHEN** — умова або дія; - **THEN** — видимий результат; - **AND** — ще одна умова чи ще один результат. Позитивний — умови виконано, результат настає. Негативний — умову порушено, відмова передбачувана. Межовий — край правила: останнє «можна» і перше «не можна». Назви — без чисел правила: «Строк минув», а не «8-й день». Для QA сценарій — заготовка тест-кейсу: WHEN — кроки й дані, THEN — очікуваний результат. Приклад із демо-функції:
#### Scenario: Оплата не пройшла - **WHEN** оплата 30 грн за другу зміну не пройшла - **THEN** адреса лишається попередньою, гроші не списуються
Під текстом кожної вимоги: файл і розділ або задача і коментар із датою. Власна ідея — «Джерело: власний запит, п. N». Цього рядка OpenSpec не вимагає — його вимагає курс: так вимогу можна перевірити і сказати, чи вона ще чинна. BA додає, хто вирішив, якщо правило змінювали, як у прикладі README: «— рішення власниці продукту Оксани». Рядок стоїть до першого сценарію і входить у межу 500 символів — пишіть його стисло. Приклади з демо-варіанту:
Джерело: decisions.md, 28.04.2026 (діє з 04.05.2026); overview.md, «Куди можна змінити». Джерело: [00-2], коментар Оксани 12.08.2026; реліз 3.4, 01.09.2026. Джерело: власний запит, п. 3.
Читайте spec.md як чернетку від колеги і звіряйте з джерелами: що агент вигадав — правила чи числа немає в джерелах; що пропустив; де взяв застаріле правило, яке пізніше рішення вже змінило; чи не потрапила відкрита сторі як чинна. Без підказки агент пише здебільшого позитивні сценарії — негативні й межові просіть явно. Знахідки — у звіт, розділ 4 «Перевірка згенерованого»; чого немає в джерелах — у розділ 6 «Відкриті питання». Як агент сам виписав розбіжності й відкриті питання — запис демо 1 на сторінці «Демо» (demo.html#demo1).
BA: для кожної вимоги, правило якої змінювали, — хто і коли вирішив (дата рішення): у рядку «Джерело: …» і в таблиці звіту. Наприклад: «Джерело: decisions.md, запис 28.04.2026 — рішення власниці продукту Оксани». QA: щонайменше 3 негативні або межові сценарії і таблиця «сценарій → тест-кейс» у звіті: вимога, сценарій, назва тест-кейсу і тип — позитивний, негативний чи межовий.
Вигадана функція вигаданого продукту, розміром як варіант: наприклад, «бронювання переговорної кімнати». Спершу запишіть у звіті «сирий запит» замовника — 5–10 пронумерованих пунктів: це єдине джерело. Біля вимог — «Джерело: власний запит, п. N»; чого в запиті немає — у відкриті питання. Номер варіанту і роль усе одно вкажіть. Промпт — той самий, але замість блоку «Джерела»:
Джерело — лише сирий запит нижче, між рядками ===. Біля кожної вимоги — «Джерело: власний запит, п. N». === 1. … 2. … ===
Зміна — окрема тека openspec/changes/<id>/: proposal.md, tasks.md і delta specs/<capability>/spec.md. За замовчуванням — сторі вашого варіанту (тип::сторі): її AC і рішення з коментарів стають delta. Сторі вже закрита і випущена (варіанти 01, 02, 08) — візьміть питання з коментарів, на яке ще немає відповіді: оформіть зміну як пропозицію, а рішення лишіть відкритим питанням до власника; або новий запит. Власна ідея — новий запит до своєї функції. Id — латиницею, малими літерами, через дефіс: status-change-during-edit.
Де / що: З CLI · Claude Code у submissions/ваш-username, після openspec init і перезапуску claude (розділ 5) · замініть усе в <…>
/opsx:propose <id-зміни> — зміна до функції <capability> за сторі [<NN-N>] у koldovsky/ai-qa-ba-c3: опис, AC і всі коментарі з датами (читай через GitLab MCP). Чинна специфікація — openspec/specs/<capability>/spec.md. Рішення з коментарів — теж джерело; у кожної вимоги в delta — рядок «Джерело: …». Якщо зміна зачіпає чинну вимогу — MODIFIED з повним текстом і всіма сценаріями. tasks.md — не код: група BA (сторі, UAT, сторінки бази знань, FAQ, хто погоджує) і група QA (тест-кейси додати, змінити, прибрати; регресія). Чого немає в джерелах — не вигадуй, винеси у відкриті питання.
Очікуваний результат: Тека openspec/changes/<id-зміни>/: proposal.md, specs/<capability>/spec.md, tasks.md; design.md агент може пропустити — у С4 він не потрібен. У відповіді — що в delta і відкриті питання. У записі демо 2: 4 ADDED і 1 MODIFIED з повним текстом і всіма чинними сценаріями, повернення 30 грн — з рішення в коментарях, питання без відповіді лишилося відкритим; openspec validate --strict — valid.
/opsx немає в меню — розділ 5. Агент викликає команди openspec у Bash і просить дозволу — читайте, що дозволяєте. У записі демо 2 два виклики Bash не пройшли перевірку дозволів Claude Code, і агент записав файли інструментом Write: перевірте файли і validate самі.
Де / що: Без CLI · Claude Code або інший агент у submissions/ваш-username · замініть усе в <…>
Підготуй зміну у форматі OpenSpec з id <id-зміни> до функції <capability> за сторі [<NN-N>] у koldovsky/ai-qa-ba-c3: опис, AC і всі коментарі з датами (читай через GitLab MCP). Чинна специфікація — openspec/specs/<capability>/spec.md. Створи в openspec/changes/<id-зміни>/: - proposal.md — ## Why (1–2 речення з джерелом), ## What Changes, ## Impact; - specs/<capability>/spec.md — delta: ## ADDED Requirements для нової поведінки; ## MODIFIED Requirements, якщо зміна зачіпає чинну вимогу (повний текст вимоги з усіма сценаріями, потім правка); у кожної вимоги — рядок «Джерело: …» і сценарії WHEN/THEN; - tasks.md — чек-лист - [ ] 1.1 …: група BA (сторі, UAT, сторінки бази знань, FAQ, хто погоджує) і група QA (тест-кейси додати, змінити, прибрати; регресія). Рішення з коментарів — теж джерело. Чого немає в джерелах — не вигадуй, винеси у відкриті питання у відповіді.
Очікуваний результат: Ті самі три файли. У записі «без CLI» (окрема сесія) агент розподілив інакше: 3 ADDED і MODIFIED «Платна друга зміна» з поверненням 30 грн усередині; перевірка CLI згодом — valid. Сторінок kb/ агент у тому записі не відкривав — лише чинну спеку і сторі [00-3] з коментарями (demo.html#demo2-nocli). Інший розподіл ADDED / MODIFIED — нормальний, якщо поведінка та сама і кожна MODIFIED повна. Перевірка — чек-лист, розділи Б і В (розділ 6).
Де / що: Каркас openspec/changes/<id>/proposal.md · шаблон — templates/change/proposal.md
# Proposal ## Why <навіщо зміна, 1–2 речення. Джерело: задача і коментар із датою / рішення з датою / власний запит, п. N> ## What Changes - <що додається: нова поведінка> - <що змінюється: було → стало> ## Capabilities ### New Capabilities - Немає ### Modified Capabilities - `<capability>`: <які вимоги змінюються> ## Impact - <кого і що зачіпає: BA — сторі, UAT, сторінки бази знань, FAQ, хто погоджує; QA — тест-кейси, регресія>
Очікуваний результат: Why — 1–2 речення з джерелом. Кожному пункту What Changes — вимога в delta, і навпаки. Impact: BA — сторі, UAT, сторінки бази знань, FAQ, хто погоджує; QA — які тест-кейси додати, змінити, прибрати, регресія.
Де / що: Каркас delta · файл саме spec.md: openspec/changes/<id>/specs/<capability>/spec.md · шаблон — templates/change/delta-spec.md
## ADDED Requirements ### Requirement: <назва нової вимоги: одна поведінка> Система SHALL <що робить і за яких умов>. Джерело: <задача і коментар із датою / рішення з журналу / власний запит, п. N>. #### Scenario: <назва звичайного сценарію> - **WHEN** <умова або дія> - **THEN** <видимий результат> #### Scenario: <назва негативного чи межового сценарію> - **WHEN** <умова не виконана або на межі правила> - **THEN** <що робить система> ## MODIFIED Requirements ### Requirement: <назва вимоги — дослівно як в основній специфікації> Система SHALL <новий текст правила>. Джерело: <рішення, яке змінило правило: задача і коментар із датою / журнал рішень, дата>. #### Scenario: <назва старого сценарію 1 — дослівно> - **WHEN** <умова — без змін або під нове правило> - **THEN** <результат — без змін або під нове правило> #### Scenario: <назва старого сценарію 2 — дослівно> - **WHEN** <умова> - **THEN** <результат> #### Scenario: <назва нового сценарію, якщо потрібен> - **WHEN** <умова> - **THEN** <результат>
Очікуваний результат: Лишіть лише потрібні розділи, порожні видаліть разом із заголовком. ## Purpose у delta не потрібен. REMOVED і RENAMED — пункт унизу розділу.
Де / що: Каркас openspec/changes/<id>/tasks.md · шаблон — templates/change/tasks.md · лишіть групу своєї ролі, другу — за бажанням
# Tasks ## 1. BA: вимоги і документація - [ ] 1.1 Оновити сторі <номер задачі>: AC за новою вимогою «<назва вимоги>» - [ ] 1.2 Оновити сценарій UAT «<назва>»: <що змінилося> - [ ] 1.3 Оновити сторінку бази знань <файл>, розділ «<розділ>», і записати рішення з датою в журнал рішень - [ ] 1.4 Оновити відповідь FAQ «<питання>» для контакт-центру - [ ] 1.5 Погодити зміну з власником продукту ## 2. QA: тести - [ ] 2.1 Додати тест-кейси для нових сценаріїв: «<назва сценарію>», «<назва сценарію>» - [ ] 2.2 Змінити тест-кейси для вимоги «<назва вимоги>»: <було → стало> - [ ] 2.3 Прибрати застарілі тест-кейси: «<назва>» — правило більше не діє - [ ] 2.4 Регресія: перевірити суміжні вимоги «<назва>», «<назва>» - [ ] 2.5 Оновити таблицю «сценарій → тест-кейс»
Очікуваний результат: Кожна задача — одна дія, яку можна позначити виконаною: - [x] 1.1 …. Не «оновити документацію», а що, де і чому. Виконане позначте до archive.
Де / що: З CLI · Claude Code · правка чернетки після перевірки · опишіть, що виправити; без CLI — той самий текст звичайним промптом
/opsx:update <id-зміни> У MODIFIED «<назва вимоги>» бракує сценаріїв з основної специфікації — скопіюй вимогу повністю, з усіма сценаріями. <Правило чи ліміт>, якого немає в джерелах, прибери і винеси у відкриті питання.
Очікуваний результат: Агент узгоджено виправляє proposal, delta і tasks. Перечитайте файли і перевірте ще раз: openspec validate id-зміни або чек-лист.
MODIFIED замінює вимогу в основній специфікації цілком: чого в блоці немає — після archive зникне. 1) Скопіюйте з openspec/specs/<capability>/spec.md увесь блок: заголовок, текст, «Джерело» і всі сценарії до наступної вимоги. 2) Лише потім правте: нове правило, нове джерело з датою, зміст сценаріїв, нові сценарії. 3) Назву вимоги не змінюйте; потрібна нова назва — розділ RENAMED. 4) Назв старих сценаріїв не змінюйте й не видаляйте: сценарій суперечить новому правилу — перепишіть WHEN і THEN, а назву лишіть. 5) Кожна вимога — в одному розділі й один раз. ADDED — лише справді нова поведінка; якщо така вимога вже є — це MODIFIED. Назва не збігається з основною специфікацією — validate може пройти, а archive зупиниться (розділ 9). 6) Довжина: текст MODIFIED від заголовка до першого сценарію, разом із рядком «Джерело: …», — до 500 символів. Перевірка зміни цього не ловить навіть з --strict, а після archive вимога стає частиною основної специфікації — і validate --all --strict зупиниться. Так було в демо 3. Нові умови — у нові сценарії, а не в текст вимоги.
REMOVED — заголовок вимоги (назва дослівно) і два рядки, без сценаріїв: Reason — чому вимога більше не діє, з джерелом; Migration — що діє замість неї. RENAMED — змінюється лише назва: по парі рядків FROM і TO на вимогу. Якщо перейменовану вимогу ще й змінюють — у MODIFIED вона під новою назвою.
## REMOVED Requirements ### Requirement: <назва вимоги — дослівно як в основній специфікації> **Reason**: <чому вимога більше не діє; джерело — рішення з датою> **Migration**: <що діє замість неї> ## RENAMED Requirements - FROM: `### Requirement: <стара назва — дослівно як в основній специфікації>` - TO: `### Requirement: <нова назва>`
Типові огріхи: у MODIFIED бракує частини сценаріїв; у вимоги немає джерела; рішення з коментаря задачі не потрапило в delta; агент вигадав правило чи ліміт, якого в джерелах немає; tasks.md написано для розробки, а не для BA і QA. What Changes має збігатися з delta. Що знайшли і виправили — у звіт, розділ 7.
Зміна status-change-during-edit за відкритою сторі [00-3] демо-варіанту — у тому самому сеансі, що й демо 1: сторі з коментарями агент уже прочитав там, тож цього разу GitLab не викликав — лише команди openspec (new change, status, instructions) і запис файлів. ADDED — повторна перевірка статусу і межі 20:00 під час «Підтвердити», автоповернення 30 грн (рішення в коментарях 14–15.09), стан кнопки після відмови. MODIFIED «Платна друга зміна» — повний текст з усіма чинними сценаріями плюс два нові. design.md агент пропустив як необов'язковий. Чи зараховується невдала спроба до ліміту двох змін — у джерелах відповіді немає, і агент лишив це відкритим питанням, а не вигадав. Промпти, повний запис і файли — на сторінці «Демо» (demo.html#demo2).
CLI додає команди /opsx:* у Claude Code і перевірку та злиття змін у терміналі — їх робить програма, а не модель. Балів за CLI не додають і не знімають. Займає ≈15 хвилин; на заняттях — версія 1.14.1. Команди openspec і claude запускайте в submissions/ваш-username: там лежить openspec/. Вивід нижче — із записаних прогонів на демо-функції change-address. Записи на сторінці «Демо»: init — розділ 1 (demo.html#prep), validate → archive → validate --all --strict — розділ 5 (demo.html#demo3), виправлення попередження — розділ 6 (demo.html#demo3-fix).
Де / що: Термінал: Windows — PowerShell, macOS — Terminal
node --version
Очікуваний результат: v20.19.0 або новіша, наприклад v22.… чи v24.…. v18.… або v20.18.… — застара.
Node.js немає або версія застара — встановіть LTS з nodejs.org; на робочому ноутбуці можуть знадобитися права адміністратора. Прав немає — працюйте без CLI (розділ 6).
Де / що: Термінал · один раз на комп'ютер · завжди з @latest
npm install -g @fission-ai/openspec@latest openspec --version
Очікуваний результат: Номер версії, наприклад 1.14.1. На Windows потрібна 1.13.2 або новіша — @latest це забезпечує.
macOS: EACCES або «permission denied» — є права адміністратора: та сама команда з sudo на початку; немає — без CLI. Windows: «openspec не знайдено» чи «running scripts is disabled» — пункти внизу розділу. Оновлення — та сама команда, потім openspec update у теці, де лежить openspec/.
Де / що: Термінал · один раз · OpenSpec за замовчуванням надсилає авторам статистику використання
openspec config set telemetry.enabled false
Очікуваний результат: Телеметрію вимкнено. Інший спосіб — змінна середовища OPENSPEC_TELEMETRY=0.
Де / що: Термінал · у своїй теці, не в корені репозиторію · замініть ваш-username
cd ~/ai-qa-ba-c4/submissions/ваш-username openspec init --tools claude --language "Ukrainian"
Очікуваний результат: Запис: «✔ Setup complete for Claude Code», «6 skills and 6 commands in .claude/», «Config: openspec/config.yaml (schema: spec-driven)». У теці — openspec/ (config.yaml, specs/, changes/archive/) і .claude/ — її в MR не додавати.
--language "Ukrainian" записує в openspec/config.yaml правило для агента: файли — українською, структурні заголовки і SHALL/MUST — англійською. Файлів project.md і openspec/AGENTS.md не буде — так і має бути.
Де / що: Термінал у тій самій теці (submissions/ваш-username) · якщо claude уже працює — спершу /exit
claude
Очікуваний результат: Наберіть /opsx — Claude Code покаже команди /opsx:propose, /opsx:explore, /opsx:apply, /opsx:update, /opsx:sync, /opsx:archive.
Команд немає — пункт «/opsx не з'являється» внизу розділу.
Де / що: Термінал у submissions/ваш-username · L1 · замініть назва-функції на свою capability
openspec validate назва-функції
Очікуваний результат: Specification '<ваша capability>' is valid — формат правильний (так вивід описано в OPENSPEC.md). Інакше — рядки ✗ [ERROR] чи ⚠ [WARNING] з вимогою: розділ 9.
Додайте --strict у кінці команди: тоді й попередження (немає SHALL/MUST у тексті вимоги, текст довший за 500 символів) зупиняють перевірку; для L3 вона однаково потрібна.
Де / що: Термінал у submissions/ваш-username · L2 · замініть id-зміни
openspec validate id-зміни
Очікуваний результат: Запис демо 3: «Change 'status-change-during-edit' is valid». Інакше — «Change '…' has issues» і рядки ✗ [ERROR] з файлом і вимогою: розділ 9. Validate перевіряє формат, а не зміст: джерела, вигадане і застаріле перевіряєте ви.
Де / що: Термінал у submissions/ваш-username · L2 · що зміна робить з кожною вимогою
openspec show id-зміни --diff
Очікуваний результат: Текст proposal.md, далі «Specifications Changed (diffs)»: кожна вимога з позначкою ADDED: …, MODIFIED: … — як diff (рядки з - було, з + стало); так само REMOVED і RENAMED. Окремої команди openspec diff немає.
Де / що: Термінал у submissions/ваш-username · L3 · спершу позначте виконане в tasks.md: - [x]
openspec archive id-зміни --yes
Очікуваний результат: Запис демо 3: «Task status: 0/16 tasks», «Warning: 16 incomplete task(s) found. Continuing due to --yes flag.», «+ 4 added», «~ 1 modified», «Specs updated successfully.», «Change 'status-change-during-edit' archived as '2026-10-14-status-change-during-edit'». Дата в назві теки — день archive. Порядок злиття: RENAMED → REMOVED → MODIFIED → ADDED.
«Aborted. No files were changed.» — назва вимоги в MODIFIED чи FROM не збігається з основною специфікацією (розділ 9). Зміну з помилками формату archive не зливає — спершу validate.
Де / що: Термінал у submissions/ваш-username · L3 · після archive
openspec list --specs
Очікуваний результат: Запис демо 3: «change-address requirements 14» — 10 вимог L1 + 4 ADDED. Самоперевірка: вимог = L1 + ADDED − REMOVED. --changes — активні зміни, --archived — архів.
Де / що: Термінал у submissions/ваш-username · L3 · з --strict перевірку зупиняють і попередження
openspec validate --all --strict
Очікуваний результат: Усе гаразд — «✓ spec/<capability>» і «Totals: … 0 failed». Запис демо 3 після archive: «✗ spec/change-address», «⚠ [WARNING] requirements[7]: Requirement text is very long (>500 characters)» — злита MODIFIED-вимога вийшла задовгою; requirements[7] — восьма вимога, лік від нуля. Як її виправили — розділ 7, крок 2.
З'являються після init і перезапуску claude: агент уже знає формат OpenSpec. design.md, який створює /opsx:propose, у С4 не потрібен — можна видалити або лишити.
/opsx:propose [ідея] створює changes/<id>/ і чернетки proposal, delta, design, tasks — L2 і друга зміна L3 /opsx:explore [тема] обговорює задачу, порівнює варіанти; файли пише лише з вашої згоди /opsx:apply [зміна] виконує tasks.md пункт за пунктом — у С4 не потрібна: коду немає /opsx:update [зміна] узгоджено виправляє proposal, delta і tasks; коду не чіпає /opsx:sync [зміна] агент зливає delta в specs/; зміна лишається активною /opsx:archive [зміна] перевіряє, пропонує sync, переносить теку в changes/archive/YYYY-MM-DD-<id>/
/opsx:archive <id> у Claude Code зливає агент (модель): зручно в діалозі, але він може переформулювати вимогу чи загубити сценарій — після нього обов'язково перечитайте основну специфікацію. openspec archive <id> --yes у терміналі — програма за сталими правилами: спершу перевірка, з помилками не зливає, порядок RENAMED → REMOVED → MODIFIED → ADDED. Для L3 радимо термінал: результат передбачуваний. Обидва переносять теку в changes/archive/YYYY-MM-DD-<id>/.
Тека, куди npm ставить програми, не в Path. Подивіться її командою нижче — зазвичай це тека npm у вашому профілі користувача Windows; скопіюйте шлях, який вона покаже. Далі: Пуск → пошук «змінні середовища» (або «environment variables») → змінні середовища для облікового запису → Path → Змінити → Створити → вставте теку → OK. Закрийте термінал і відкрийте новий; перевірка — openspec --version. Не виходить — без CLI.
npm prefix -g
Пишіть openspec.cmd замість openspec, наприклад openspec.cmd --version. Налаштувань безпеки не змінюйте. Якщо таку помилку отримує агент у Claude Code — попросіть його викликати openspec.cmd.
Claude Code запущено до openspec init або не в тій теці. /exit → перейдіть у свою теку → claude (команди нижче). Перевірте, що в теці є .claude/commands/opsx/. Не допомогло — викличте скіл напряму: /openspec-propose з тим самим текстом.
cd ~/ai-qa-ba-c4/submissions/ваш-username claude
Це інструкції до версії 1.0.0: ці команди й файли прибрали. Чинні команди — /opsx:*, контекст проєкту — openspec/config.yaml. Скажіть агенту про це прямо.
Ті самі файли — з агентом за шаблонами з templates/, бали ті самі. Замість openspec validate — templates/validation-checklist.md: ті самі правила плюс зміст. У звіт: L1 — розділи А і В; L2 — Б і В для кожної зміни; L3 — Б, В і Г після обох змін. Позначте пункти [x] і напишіть, що знайшли і виправили. Перевіряйте сирий текст файлу — у редакторі або Display source на gitlab.com: на відображеній сторінці не видно решіток і коментарів.
Де / що: Чек-лист А · основна специфікація · суть; повний текст — templates/validation-checklist.md
- [ ] Файл — openspec/specs/<capability>/spec.md; <capability> латиницею, малими літерами, через дефіс - [ ] ## Purpose і під ним текст — не коротше за 50 символів, без TBD і TODO - [ ] ## Requirements - [ ] Кожна вимога — ### Requirement: <назва> (три #), під заголовком — текст вимоги - [ ] У тексті кожної вимоги — SHALL або MUST, а не лише в назві - [ ] Текст вимоги — від заголовка до першого сценарію, разом із рядком «Джерело» — не довший за 500 символів - [ ] У кожної вимоги — щонайменше один #### Scenario: <назва> (чотири #) з текстом
Очікуваний результат: Помилку openspec validate не пропустив би; попередження — Purpose коротше за 50 символів, немає SHALL/MUST, понад 500 символів — не пропустив би з --strict. Виправляйте і те, й інше.
Де / що: Чек-лист Б · зміна openspec/changes/<id>/ · суть
- [ ] Id — лише малі латинські літери, цифри й дефіси між словами - [ ] Delta — у changes/<id>/specs/<capability>/spec.md, не specs/spec.md і не delta-spec.md - [ ] Розділ дослівно, з двома #: ## ADDED / ## MODIFIED / ## REMOVED / ## RENAMED Requirements - [ ] Під розділом — хоча б одна ### Requirement: (у RENAMED — пара рядків FROM і TO) - [ ] Кожна ADDED і MODIFIED — текст із SHALL/MUST і щонайменше один #### Scenario: з текстом - [ ] MODIFIED — усі сценарії вимоги з основної специфікації, з тими самими назвами, плюс нові - [ ] Кожна вимога — лише в одному розділі й лише один раз - [ ] Назви в MODIFIED, REMOVED і FROM — дослівно як в основній специфікації - [ ] Порожніх розділів немає - [ ] proposal.md має ## Why і ## What Changes
Очікуваний результат: Назви, що не збігаються з основною специфікацією, validate не помітить: archive зупиниться на MODIFIED чи RENAMED, а з REMOVED лише попередить — і стара вимога лишиться. Довжину тексту MODIFIED перевірка зміни теж не ловить (попередження про 500 символів — лише для ADDED): рахуйте її самі, разом із «Джерело». Після archive вона стане вимогою основної специфікації, і розділ А її перевірить.
Де / що: Чек-лист В · зміст — validate цього не перевіряє
- [ ] Одна вимога — одна поведінка: без «і ще», «а також» - [ ] Біля кожної вимоги — «Джерело: …»; BA — хто і коли вирішив, якщо правило змінювали - [ ] Лише чинні правила: де джерела розходяться — пізніше рішення - [ ] Відкрита, ще не реалізована сторі не стала вимогою основної специфікації - [ ] Нічого не вигадано: кожне число, строк, сума і статус є в джерелі - [ ] Без «як реалізувати»: без технологій, полів бази даних, API і верстки - [ ] Сценарії перевірювані; серед них є негативні й межові - [ ] Зміна: Why — з джерелом; What Changes збігається з delta, і навпаки - [ ] tasks.md — групи ## 1. … і задачі - [ ] 1.1 … вашої ролі - [ ] Коментарі-підказки з шаблонів видалено
Очікуваний результат: Тут — лише ви. Знайдене — у звіт: що агент вигадав, пропустив, де взяв застаріле правило і що ви виправили.
Де / що: Archive вручну з агентом · Claude Code у submissions/ваш-username · L3 · замініть <…>; дата — день злиття
Злий зміну <id-зміни> в основну специфікацію вручну, за правилами OpenSpec: у openspec/specs/<capability>/spec.md застосуй delta з openspec/changes/<id-зміни>/specs/<capability>/spec.md у порядку RENAMED → REMOVED → MODIFIED → ADDED. MODIFIED замінює вимогу цілком на її місці, ADDED — у кінець розділу ## Requirements. Більше нічого не змінюй. Потім перенеси теку openspec/changes/<id-зміни>/ в openspec/changes/archive/<РРРР-ММ-ДД>-<id-зміни>/.
Очікуваний результат: В основній специфікації немає розділів ## ADDED чи ## MODIFIED Requirements; тека зміни — в changes/archive/ з датою, у changes/ її більше немає. Перечитайте специфікацію і пройдіть чек-лист Г: MODIFIED замінили стару вимогу, а не стали поруч; вимог із REMOVED немає.
У файлі openspec/specs/<capability>/spec.md, у такому порядку: 1) RENAMED — змініть назву вимоги з FROM на TO; 2) REMOVED — видаліть вимогу цілком, з усіма сценаріями; 3) MODIFIED — замініть вимогу цілком на блок із delta; 4) ADDED — додайте нові вимоги в кінець розділу ## Requirements. Потім перенесіть теку openspec/changes/<id>/ у openspec/changes/archive/YYYY-MM-DD-<id>/, де дата — день злиття, наприклад:
openspec/changes/archive/2026-10-18-status-change-during-edit/
Delta злита, в основній специфікації немає розділів ADDED чи MODIFIED. Тека зміни — в changes/archive/. Вимог із REMOVED немає, MODIFIED замінили старий текст. Основна специфікація проходить розділ А. Між вимогами немає суперечностей: одне правило не описано двічі по-різному. Кожен сценарій відповідає чинному правилу — числа, строки, статуси з нового рішення. Друга зміна взяла MODIFIED із уже злитого тексту. Похідні артефакти оновлено, посилання — в обидва боки.
Файлами не виходить — вставте вміст кожного файлу у звіт блоками коду, розділ «Додаток» шаблону, зі шляхом файлу в заголовку. Зараховується так само.
Репетиція фінального проєкту: застосувати зміну L2, зробити другу зміну тієї самої поведінки повним циклом і перевірити, що пакет лишився узгодженим. Після archive основна специфікація — нова поточна правда: прочитайте її.
Де / що: Крок 1 · з CLI · термінал у submissions/ваш-username · виконане в tasks.md спершу позначте - [x]
openspec archive id-зміни --yes openspec list --specs openspec validate --all --strict
Очікуваний результат: Тека зміни — в changes/archive/РРРР-ММ-ДД-id-зміни/, у списку — нова кількість вимог; validate --all --strict — «✓ spec/…» і «0 failed». Вивід — розділ 5. Потім відкрийте openspec/specs/<capability>/spec.md і прочитайте: це нова поточна правда. Без CLI — archive вручну (розділ 6) і чек-лист Г.
«Requirement text is very long (>500 characters)» — крок 2. Через агента — /opsx:archive id-зміни: злиття пише модель, тож специфікацію після нього перечитайте особливо уважно.
Де / що: Крок 2 · Claude Code у submissions/ваш-username · якщо validate --all --strict показав «Requirement text is very long (>500 characters)»
openspec validate --all --strict показує: <вставте рядок ✗ і рядок ⚠ [WARNING] з виводу>. Знайди цю вимогу в openspec/specs/<capability>/spec.md після archive і виправ: кожна вимога — одна поведінка, приклади й винятки — у сценарії. Зміст, тексти повідомлень і рядки «Джерело: …» не змінюй і нічого не додавай від себе. Потім запусти openspec validate --all --strict.
Очікуваний результат: Запис демо 3 (demo.html#demo3-fix): попередження requirements[7] стосувалося восьмої вимоги — злитої MODIFIED «Платна друга зміна». Агент лишив у тексті одну поведінку — «Система SHALL вимагати за другу зміну адреси 30 грн, сплачені платіжною карткою до підтвердження зміни.» — умови вже були в її сценаріях. Повторна перевірка: «✓ spec/change-address», «Totals: 1 passed, 0 failed (1 items)».
Перевірте самі, що жодне правило не зникло: кожна прибрана з тексту умова має лишитися в сценарії цієї вимоги.
Де / що: Крок 3 · Claude Code у submissions/ваш-username · новий id · без CLI — той самий опис звичайним промптом (розділ 4)
/opsx:propose <id-другої-зміни> — друга зміна до функції <capability>: <пізніше рішення або новий запит — з джерелом і датою>. Вона зачіпає ту саму поведінку, що й заархівована зміна <id-першої-зміни>. Чинна специфікація — openspec/specs/<capability>/spec.md після archive: MODIFIED бери з уже злитого тексту — повністю, з усіма сценаріями, назви дослівно. У кожної вимоги — рядок «Джерело: …». tasks.md — група BA і група QA, з посиланням на похідний артефакт (<uat.md / tests.md / розділ звіту>). Чого немає в джерелах — не вигадуй, винеси у відкриті питання.
Очікуваний результат: Нова тека openspec/changes/<id-другої-зміни>/. Далі той самий цикл: перевірка чернетки → validate → archive. Якщо друга зміна змінює вимогу, яку додала перша, застосувати її можна лише після archive першої.
Власна ідея — новий запит до тієї самої функції, записаний у звіті. Зразок другої зміни — examples/00-demo/l3/…/2026-10-15-failed-attempt-rules: це вигаданий для прикладу запит, а не джерело для вашої роботи.
Де / що: Крок 4 · Claude Code у submissions/ваш-username · після обох змін · замініть <…>
Перевір узгодженість після обох змін. Читай openspec/specs/<capability>/spec.md, теки в openspec/changes/archive/ і <похідний артефакт: uat.md / tests.md / розділ звіту>. Таблиця: що перевірили | що знайшли | що виправити. Перевір: чи немає двох вимог, що суперечать одна одній, і чи старе правило не лишилося поруч із новим; чи кожен сценарій відповідає чинному правилу (числа, строки, статуси); чи артефакт посилається на вимогу і на зміну, а tasks.md чи ## Impact — на артефакт. Нічого не змінюй.
Очікуваний результат: Таблиця-чернетка для звіту, розділ 8. Кожен рядок перевірте самі — у звіт беріть те, що перевірили. Плюс вивід openspec validate --all --strict або чек-лист Б, В і Г.
1) Застосувати зміну L2: openspec archive <id> --yes, /opsx:archive або вручну. 2) Перечитати основну специфікацію. 3) Друга зміна, що зачіпає ту саму поведінку (пізніше рішення або новий запит), — повний цикл: proposal → delta → tasks → archive; MODIFIED — з уже злитого тексту. 4) Похідні артефакти: BA — сторі чи UAT або сторінка бази знань; QA — таблиця «сценарій → тест-кейс»: що змінилося, що застаріло. 5) Перевірка узгодженості і openspec validate --all --strict або чек-лист. У звіт — таблиця «що перевірили → що знайшли → що виправили».
Артефакт — файл у вашій теці (наприклад, uat.md чи tests.md) або розділ звіту. «Туди»: артефакт посилається на вимогу в spec.md і на зміну. «Назад»: зміна — tasks.md або ## Impact у proposal.md — посилається на артефакт. Наприклад:
uat.md: Вимога «<назва вимоги>» — openspec/specs/<capability>/spec.md; зміна <id-зміни> tasks.md: - [x] 1.2 Оновити сценарій UAT «<назва>» у uat.md
Основна специфікація після archive двох змін і архів обох: 2026-10-14-status-change-during-edit і 2026-10-15-failed-attempt-rules. Друга зміна — вигаданий для прикладу запит від 15.10.2026: у джерелах варіанту 00 такого рішення немає. Приклад таблиці перевірки узгодженості — не в теці l3/, а в README зразка (examples/00-demo/README.md, розділ про l3). Порівнюйте зі своєю роботою після власної спроби.
Звіт — за шаблоном templates/c4-report.md у submissions/ваш-username/c4.md. Файли — у гілку c4 своєї копії, потім merge request у koldovsky/ai-qa-ba-c4. Теку .claude/, яку створює openspec init, не додавайте; openspec/config.yaml можна лишити.
Де / що: Звіт · скопіюйте templates/c4-report.md у свою теку з такою назвою
submissions/ваш-username/c4.md
Очікуваний результат: Саме submissions, без templates/ на початку. Шапка — пункт унизу розділу. Розділи 1–6 і 9 — L1, 7 — L2, 8 — L3. Посилання на файли — повні, на gitlab.com, у гілці c4 вашої копії. Чернетку звіту може скласти агент — перевірте кожне посилання і твердження.
Де / що: Спосіб 1 · Claude Code з GitLab MCP · замініть ваш-username
Відправ усі файли з теки submissions/ваш-username, крім .claude/, у нову гілку c4 моєї копії ваш-username/ai-qa-ba-c4 одним комітом
Очікуваний результат: Claude Code просить дозволу на виклики GitLab, що створюють гілку і коміт: у параметрах — ваша копія, гілка c4, без .claude/. Коміт піде від вашого акаунта з прихованою поштою (крок 0).
Де / що: Спосіб 2 · Git · термінал, повертаємося в корінь клону · замініть адресу на ту, що в Edit profile → Commit email, і ваш-username
cd ~/ai-qa-ba-c4 git config user.email "ваша-адреса@users.noreply.gitlab.com" git switch -c c4 git add submissions/ваш-username/c4.md submissions/ваш-username/openspec git status git commit -m "С4: моя робота" git push -u origin c4
Очікуваний результат: У git status — лише ваші файли, без .claude/. Гілка c4 з'явилася у вашій копії на gitlab.com.
Без git config user.email локальний коміт бере пошту з налаштувань git — часто робочу, — і вона стане публічною у форку. Інші свої файли додайте так само: git add submissions/ваш-username/tests.md.
Де / що: Спосіб 3 · лише браузер · своя копія на gitlab.com · для кожного файлу
Code → Branches → New branch → c4 → Create branch → гілка c4 → + → New file → submissions/ваш-username/openspec/specs/назва-функції/spec.md → Commit changes
Очікуваний результат: Теки з'являються самі з повного шляху в назві файлу. Коміт — у гілку c4.
Де / що: Code → Merge requests → New merge request: зліва — ваша копія і c4, справа — koldovsky/ai-qa-ba-c4 і main → Compare branches and continue → Title
С4 · ваш-username · варіант NN
Очікуваний результат: Власна ідея — «С4 · ваш-username · варіант NN · власна ідея». Шаблон опису C4, чек-лист → Create merge request. У Changes — лише файли з submissions/ваш-username/, без .claude/.
Чужі файли в Changes — форк зроблено з чужої копії: зробіть новий форк зі сторінки koldovsky/ai-qa-ba-c4.
Прізвище та ім'я — як у списку учасників курсу, прізвище першим: їх, як і звіт, видно публічно. Варіант — той самий, що в С1–С3; для власної ідеї номер теж потрібен. У заголовку файлу «С4 · Звіт · ваш-username» — свій username на gitlab.com.
**Прізвище та ім'я:** Прізвище Ім'я **Варіант:** NN **Основа:** функція варіанту / власна ідея **Роль:** QA / BA **Виконані рівні:** L1 · L2 · L3 **Функція (capability):** `назва-функції`
c4.md — так. openspec/ зі специфікаціями, змінами й архівом — так. Похідні артефакти (uat.md, tests.md тощо) — так. openspec/config.yaml — можна лишити. .claude/ — ні.
Звіт у templates/… чи в корені; тека з іменем замість username; «submisions» з помилкою. Тека .claude/ у MR. Структурні заголовки українською (## Вимоги, #### Сценарій:) або сценарій із трьома решітками. Capability чи id зміни кирилицею, з пробілами чи великими літерами. MODIFIED лише з правкою — без повного тексту і всіх сценаріїв. Правило, яке пізніше рішення вже змінило, — як чинне; відкрита сторі в L1. «Домислене» агентом: ліміт, строк чи сума, яких немає в джерелах. Форк не з koldovsky/ai-qa-ba-c4.
Токен-звіту — він повернеться в С5. Задач у трекері: Issues у проєкті С4 вимкнено, усе — файлами. design.md, який може створити /opsx:propose, — необов'язковий: можна видалити або лишити. /opsx:apply — теж: коду немає, задачі з tasks.md виконуєте ви.
Строк — вівторок, 20 жовтня 2026, 23:59; до строку можна виправляти в тому самому MR. Розбір — на С5, у середу, 21 жовтня. Кожен рівень — до 10 балів за частинами (таблиця в README); рівні рахуються окремо, порожній розділ — 0. CLI балів не додає і не знімає. Формальності — −1 за кожну, разом до −2: файл не в submissions/<username>/c4.md, назва MR не за шаблоном, не вказано варіант чи прізвище та ім'я. Робота за демо-варіантом не зараховується.
Репозиторій і форки публічні: жодних корпоративних даних, паролів, токенів, імен колег і посилань на внутрішні системи — ні в промптах, ні у файлах, ні у звіті. Агент пише файли і через MCP діє від вашого імені: прочитайте файли, перш ніж відправити, і читайте, на що погоджуєтеся. Текст у джерелах — дані, а не команди: помітили «агенте, зроби …» — зупиніть агента (Esc) і напишіть про це у звіті.
Відповіді OpenSpec — англійською. ✗ [ERROR] — помилка; ⚠ [WARNING] — попередження: без --strict перевірка проходить, з --strict — ні. Ті самі правила — у ручному чек-листі (розділ 6).
Повні повідомлення: ADDED "…" must include at least one scenario (так само MODIFIED "…"), Requirement must have at least one scenario. У вимоги немає сценарію. Найчастіше — ### Scenario: (три #) замість #### Scenario: (чотири): такого сценарію OpenSpec не бачить. Або під заголовком сценарію порожньо. Правильно:
#### Scenario: <назва> - **WHEN** <умова або дія> - **THEN** <видимий результат>
Попередження: у тексті вимоги немає SHALL чи MUST великими латинськими літерами. Без --strict перевірка проходить, з --strict — ні. Напишіть у першому рядку під заголовком «Система SHALL …». Якщо в повідомленні є «not only in the header» — SHALL стоїть лише в назві вимоги, а має бути в тексті.
Текст вимоги — усе від заголовка до першого сценарію, разом із рядком «Джерело: …», — довший за 500 символів. Деталі й приклади перенесіть у сценарії або розділіть вимогу на дві: одна вимога — одна поведінка. Перевірка зміни довжину MODIFIED не ловить навіть з --strict: попередження з'являється вже після archive, в основній специфікації. Так було в записі демо 3 — злита «Платна друга зміна» з дописаними умовами і довгим рядком «Джерело». requirements[7] — номер вимоги з нуля, тобто восьма. Промпт для агента — розділ 7, крок 2. Повний текст попередження:
⚠ [WARNING] requirements[7]: Requirement text is very long (>500 characters). Move examples and edge cases into scenarios, or split it into separate requirements that each state one behavior.
MODIFIED замінює вимогу цілком. Скопіюйте в MODIFIED усі сценарії цієї вимоги з основної специфікації — їхні назви є в повідомленні — і лише потім правте. Назв старих сценаріїв не змінюйте.
У delta немає жодного розділу ## ADDED Requirements, ## MODIFIED Requirements, ## REMOVED Requirements чи ## RENAMED Requirements — або назву написано інакше: українською, з помилкою, з ### замість ##. Ще причина — delta лежить не в openspec/changes/<id>/specs/<capability>/spec.md.
Заголовки розділів є, а жодної вимоги ### Requirement: … під ними немає. Допишіть вимоги; порожні розділи видаліть разом із заголовком.
Назва вимоги в MODIFIED або в рядку FROM розділу RENAMED не збігається з назвою в основній специфікації. Validate при цьому проходить, а archive — ні. Скопіюйте назву з основної специфікації дослівно — до літери і пробілу.
Назва в REMOVED не збіглася з основною специфікацією — стара вимога лишилася в специфікації. Виправте назву в delta і повторіть archive або видаліть вимогу з основної специфікації вручну.
Id — лише малі латинські літери, цифри й дефіси: status-change-during-edit. Не можна: кирилицю, великі літери, пробіли, _, дефіс на початку чи в кінці, два дефіси поспіль.
Це не помилка: archive з --yes попереджає про невиконані задачі в tasks.md і все одно архівує зміну — у записі демо 3 «Task status: 0/16 tasks». Виконане позначайте - [x] до archive.