Огляд

Після Вступу хочеться одразу «робочий додаток» — і легко зібрати все: View, Session, Database, Logging. Але тоді незрозуміло, навіщо кожен шар і що зламається, якщо його прибрати. Тому рецепти йдуть крок за кроком: на кожному з’являється одна нова capability у Stack і мінімальний набір файлів, які змінюються. Мета — показати причину, а не «підключіть пакет і воно запрацює».

На ранніх кроках — literal paths і flags у Bootstrap, без config і PathManager. Glue з’явиться в кінці, коли вже видно, що саме варто винести в конфіг. Так ви не плутаєте «як працює HTTP» з «звідки береться шлях до routes».

Принципи — навіщо саме так

• Why first — спочатку біль (ізоляція, явність, тестівність), потім виклик API. Інакше Stack виглядає як чеклист «увімкни все»
• Один крок = одна нова capability (addX()), без прихованих супутніх увімкнень: щоб можна було сказати «це з’явилось саме через цей виклик»
• Кожен крок будує на попередньому — не переписуємо все з нуля, щоб diff лишався читабельним
• Stack не читає config — лише explicit values у Bootstrap-класі. Немає «магії» з .env на ранніх кроках: шляхи й прапорці видно в одному місці
• Middleware lists — у routes/*.php, не в Stack: HTTP-поведінка належить surface додатку, а не «глобальному» bootstrap

Кроки

Таблиця — карта шляху: що саме додаєте на кожному кроці і чи сторінка вже готова. «Далі» — stubs: структура є, проза з’явиться окремим кроком документації.

Перемикання тегів і runtime cache

Каталог storage/ у .gitignore: після git checkout step-0N-… на диску лишаються сесії, логи та (з кроку 7 при APP_DEBUG=0) compile cache Twig/Casting від попереднього кроку. Тоді в браузері можна побачити старий шаблон або «чужу» сесію, хоча код у git уже інший.

На кроках 2–6 Twig compile cache у Bootstrap не вмикаємо — простіше перемикати теги. З кроку 7 — setCacheDir() + setDebug($debug): при APP_DEBUG=1 (default у Docker рецепта) cache вимкнений; при APP_DEBUG=0 — увімкнений.

На кожному кроці в блоці «Запуск» після checkout очищайте runtime перед composer install і Docker:

git checkout step-03-validation
rm -rf storage/cache storage/sessions storage/logs
composer install
cp docker-compose.yml.example docker-compose.yml
docker compose up -d --build

Або скрипт у репозиторії (те саме + composer install):

./scripts/checkout-recipe-step.sh step-03-validation

Каталоги під storage/ створюються знову при першому запиті або рендері — mkdir вручну не потрібен.

Промо-шаблон (index.twig)

На web-кроках головна — промо Core · Extensions · Stack. Верхня панель і hero еволюціонують разом із маршрутами:

• Крок 2 — nav: лише бренд; hero: «How it works» + GitHub → concept-recipes
• Крок 3–5 — nav: Contact → /contact
• Крок 6+ — nav: Contact + Stats → /api/stats (JSON у новій вкладці)

Демо-URL на кшталт /boom (крок 7) у nav не додаємо — перевірка через документацію кроку або CLI.

Файли на кожному кроці

Щоб не губитися в diff-ах, тримаємо стабільний базовий набір файлів із першого кроку. Нові можливості майже завжди додають рядки в Stack bootstrap і, за потреби, route / middleware / controller / view — а не новий entry point.

Базовий набір (крок 1) — те, через що проходить кожен HTTP-запит:

1. public/index.php — entry point (тонкий: emit response)
2. bootstrap/app.php — App + виклик Bootstrap
3. routes/web.php — маршрути (HTTP surface)
4. ApplicationStackBootstrap.php — які capabilities увімкнені
5. Controller — handler конкретного URL

Повний diff і «навіщо саме цей файл змінився» — на сторінці кроку. Огляд лише показує карту; деталі — у рецептах.