AGENTS.md instruction chain
Codex поєднує global guidance із project instructions від repository root до current directory. Ближчий AGENTS.md або AGENTS.override.md має вищий пріоритет у своєму scope.
Як налаштувати мультиагентне середовище →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Authenticated browser state
Збережені cookies і headers для повторного використання авторизованої browser session. Такий файл може дозволити impersonation test account, тому його не слід комітити навіть у private repository; shared account підходить лише для tests без конфліктних server-side mutations.
Практика курсу на YOY, домашні завдання та формат ПМП →Authentication state є секретом
State-файл може містити cookies і headers, достатні для impersonation. Офіційний guide радить зберігати його поза Git навіть у private repository.
На сторінці може бути різний контент — що робити? →Авторські приклади API client і Page Object
Pinned приклад пов’язує API client і Page Object із переходом уроку від прямого UI-flow до reusable automation structure. Код не скопійовано через відсутність LICENSE у repository.
Практика курсу на YOY, домашні завдання та формат ПМП → Першоджерело ↗Калібруйте перевірку за ризиком
Repository diff є засобом порівняння, а не доказом якості. Перегляньте й зрозумійте зміну, запустіть релевантний check/test і перевірте observable behavior; для authentication, sensitive data, secrets та safety-critical code потрібен сильніший oversight.
Репозиторій як довідник до модулів →Перевірити hierarchy AGENTS.md
Створи repository-level AGENTS.md і один nested AGENTS.override.md з відмінною test command. Запусти Codex із root та nested directory й попроси показати active instruction sources без виконання змін.
Learner пояснює merge order, scope і те, чому nested override застосовується лише в його subtree.
Entity, DAO, repository та ORM
Entity object відображає таблицю або persistence-модель, DAO інкапсулює низькорівневий доступ до даних, а repository формулює операції мовою домену, наприклад `findUserByEmail`. Межі цих назв різняться між ecosystem, тому важливіше розуміти відповідальність, а не механічно відтворювати всі шари. ORM перетворює об'єкти на relational data та генерує SQL. Він зменшує кількість ручних queries для стандартного CRUD, але не скасовує знання schema, indexes, transactions і joins. Для невеликого test-support helper достатньо вже наявного driver/repository; окремий ORM-шар лише для тестів часто створює дублювання production model.
Commit і push
Commit зберігає перевірений знімок змін у локальному repository. Перед push ще раз перевіряються target branch, commit message і файли в diff. Push передає локальні commits до remote repository. Демонстраційний push у відео завершується SSH permission error, що показує окрему вимогу: SSH URL потребує налаштованого SSH key і доступу до repository.
Доменні межі, кілька застосунків і один стартовий repository
Великий продукт може мати B2C, B2B, back office, tool-sharing або branch-office застосунки зі спільним core. Структуру automation варто повторювати за реальними domain/app boundaries, а common-код піднімати лише тоді, коли він справді спільний. Для нового automation effort рекомендовано починати з одного repository: розділити усталену систему пізніше простіше, ніж одразу координувати кілька репозиторіїв без перевіреної потреби. Один repository також полегшує справжні end-to-end flows через кілька доменів.
Публікація локального проєкту
Для локального проєкту використовується IDE action `Share Project on GitHub`: вказується назва repository та його visibility. Перед першим commit треба переглянути список файлів. `.idea`, логи та інші локальні артефакти не мають випадково потрапити до repository.
Внутрішні registry та контроль залежностей
На enterprise-проєктах доступ до публічних package registries часто обмежують. Дозволені бібліотеки та внутрішні збірки зберігають у корпоративному artifact repository або пропускають через контрольований proxy. Такі сховища дають версіонування, allowlist і сканування вразливостей. Якщо зовнішній пакет не дозволений, команда або погоджує його через встановлений процес, або реалізує мінімально потрібну поведінку самостійно — хоча власний код теж має вартість підтримки й не є автоматично безпечнішим.
Клонування існуючого repository
Якщо repository вже існує на GitHub, GitLab чи Bitbucket, правильний початок — `Git Clone`, а не повторна публікація. З Git hosting копіюється HTTPS або SSH URL, в IDE обирається локальна папка, після чого проєкт клонується. GitHub Desktop може виконати ту саму операцію, але відео демонструє вбудовані IDE-інструменти.
Гілки як знімки стану кожного модуля
[Дивитися з 00:00](https://www.youtube.com/watch?v=FQsfjR_iHoE&t=0s). Для Java- та Python-прикладів підготовлено репозиторії, де окремі гілки відповідають модулям курсу. Перемкнувшись на потрібну гілку, учень бачить реалізацію в тому стані, у якому вона була під час запису заняття. Це дає змогу звірити структуру проєкту, налаштування й код, якщо пояснення у відео було надто швидким або незрозумілим.
Що не можна комітити
До Git додаються source code, Gradle Wrapper і потрібні configuration files. Не комітяться `.gradle`, `build`, `out`, локальна `.idea`, Maven build output та файли з environment variables чи secrets. Виняток для частини `.idea` може бути свідомим командним рішенням, наприклад для спільного code style. `.gitignore` має явно захищати repository від згенерованого сміття та приватних даних.
Старт нового репозиторію без зайвих файлів
У демонстрації виправляється помилка з назвою `.ignore`: для Git потрібен саме `.gitignore`. Схожий суфікс використовують й інші інструменти у власних файлах, наприклад `.cursorignore`, але кожен із них має окреме призначення. Рекомендований стартовий workflow: ініціалізувати Git-репозиторій, створити `.gitignore`, одразу записати відомі локальні каталоги на кшталт `.idea/`, `.venv/` і результатів тестів, а вже потім індексувати потрібні вихідні файли. IDE може запитувати, чи автоматично додавати новостворені файли до Git; це зручно, якщо ignore-правила вже захищають локальні артефакти.
Домашні завдання через GitHub
[Дивитися з 10:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=630s). Щотижня очікується один або кілька нових tests. Перша домашня робота публікується як repository link; наступні — в окремих branches і pull requests порівняно з `main`. Це дає reviewer-у точний diff конкретного модуля, а учневі — невеликий, але реальний portfolio artifact. Якщо PR уже merged, треба чітко вказати commit або зміни, які відповідають домашній роботі.