ANITECH PERFORMANCE — обучающая платформа: Bash, Docker, Traefik, Caddy, Kubernetes, PHP, OOP, алгоритмы, RabbitMQ, Redis, Laravel, Laravel Performance, Inertia, CSS, Tailwind, JS, Vue, TypeScript, Nuxt, Angular, Node.js, Express, NestJS, GraphQL, PostgreSQL, Prisma, Centrifugo; Go Start, Go Pro и Ansible — в работе

Сборный репозиторий с лабораторными работами. Каждая работа подключена как git submodule в отдельной папке и живёт в собственном репозитории — со своей историей коммитов, независимо от остальных. Репозиторий будет пополняться новыми работами.

Витрина всех работ и их описания — на index.html: живая версия — anitech.meeymirita.ru, локально открывается прямо в браузере.

Как это выглядит

На примере Caddy Lab: карточка на главной → страница лабы с описанием → оглавление методички → сама методичка.

Карточки лаб на главной	Страница лабы
Оглавление методички	Методичка

Работы

Нумерация совпадает с витриной сайта (26 лаб): сначала фронтенд (1–7), затем бэкенд (8–20), затем инфраструктура (21–25); Prisma (26) добавлена позже, её номер стоит вне этого порядка — на сайте она в группе бэкенда. Учебный порядок прохождения (что за чем идти) — в окне «Что нужно знать до старта» на сайте и в fixes/common/_order.md. Зависимости между лабами — лабы переиспользуют друг друга: OOP-лаба даёт фундамент для RabbitMQ и Laravel; «Чистый PHP» встал рядом с OOP, потому что тоже про язык, но без фреймворка (её ссылки на Laravel-лабу — в будущем времени, так как та ещё не пройдена). Kubernetes переносит в кластер стек Docker- и Traefik-лаб (в Traefik-лабе он собирается как starter/, шаг 10.5; в самой Kubernetes-лабе код api/ тоже приведён целиком) — знания обеих нужны, проходить её лучше после них. RabbitMQ стоит пройти до Redis (методичка постоянно сравнивает Streams с брокером) и до Laravel-лабы (она ссылается на обе). «Чистый JS» — общий фундамент для Vue и TypeScript; Vue — до TypeScript (сессия 5 использует Vue). NestJS и GraphQL — самостоятельные проекты, каждый со своим доменом: NestJS не собирает бэкенд Vue-лабы (это отдельное изучение технологии с нуля, домен Helpdesk похож на Vue Lab только по смыслу), а GraphQL не требует прохождения NestJS. Nuxt — после Vue и TypeScript: код из них не берёт, но объясняет только то, что Nuxt добавляет поверх Vue (SSR, Nitro, состояние на сервере, режимы рендеринга). PostgreSQL — тоже самостоятельная: разбирает то, что во всех остальных лабах пряталось за ORM, поэтому её можно проходить в любой момент, но полезнее всего — после одной-двух лаб с Laravel, когда Eloquent уже знаком. Inertia — самостоятельный проект на Laravel + Vue, кода из других лаб не берёт, но предполагает знакомство с обоими (Laravel Lab, Vue Lab); логичнее всего идёт после Laravel-лабы. Алгоритмы на PHP — самостоятельная лаба: нужен только синтаксис PHP, идёт рядом с чистым PHP и ООП. Laravel Performance — после Laravel Lab: на приложении Laravel 13 с миллионом заказов в PostgreSQL измеряет и ускоряет его (k6, профилировщики, OPcache, кеш в Redis, Octane); отдельных лаб-предшественников у неё нет, но нужен базовый Laravel. Bash, Docker и Traefik самодостаточны и не завязаны на остальные: Bash идёт первой (скрипты нужны всем следующим), Docker — следом (на нём стоят Traefik, Kubernetes и Ansible; в шаге 11.5 Docker-лабы собирается starter/ — чистая копия сквозного проекта CoffeeShop для лаб-продолжений). Express — часть I (Node с нуля) требует пройденный «Чистый JS»; часть II (Express) — введение перед TypeScript и NestJS. Centrifugo — realtime на Laravel + Vue: нужны основы Laravel и Docker. Caddy — тоже самостоятельная: свой проект Edge (Node.js-бэкенды и PHP-FPM), решает ту же задачу, что Traefik (reverse proxy, TLS), но другим инструментом и подходом — проходить обе не обязательно, но рядом они показывают разницу решений.

Аудит, вычитка и проверка запуском (24.09–04.10.2026). Все методички, кроме Caddy Lab (добавлена позже), вычитаны построчно и исправлены, проверены стыки между лабами (DevOps, фронтенд, бэкенд). 03–04.10 каждая лаба прошла «сухой прогон»: собрана по блокам методички во временной папке (Docker, веб — Chromium), результаты сверены с «Ожидаемым результатом», найденные ошибки исправлены. Что и чем проверено, пошагово и со сносками «*» (аккаунт, домен, ключи, «Production Hell» — задания без подсказок) — на странице «Что чем проверено»; находки и решения — в fixes/ (отдельный репозиторий, сабмодуль), хронология — в «Хронологии». У каждой карточки на главной внизу — сноска «что требуется».

13.10.2026 — стандарт лаб и переписанные лабы. Принят стандарт: минимум 10 сессий, формат как у Caddy, последняя сессия — итоговое ТЗ без готового ответа. По нему доделаны: Bash, Express, Centrifugo, Laravel Performance, JS, PHP, PostgreSQL, CSS, Nuxt (все по 10+ сессий); позже — NestJS (14 сессий, 15.10) и Vue (15 сессий, 16.10) и Docker Lab (переписана в 12 сессий, 77 шагов, со схемами и аналогиями «если совсем просто»); Bash, Express, Docker и Centrifugo собраны ассистентом из Markdown-исходников или получены из другого чата — владелец их ещё не проходила. Остальные лабы (меньше 10 сессий) отложены на потом — список в fixes/common/_state-log.md.

Caddy Lab (24) — добавлена позже (05.10.2026) и в этот аудит не входит, но в тот же день вычитана и проверена отдельно: 31 находка исправлена, сессии 1–6 и 9–11 запущены локально на Caddy v2.11.7, 7, 8, 12 и 13.5 — в Docker (fixes/devops/caddy.md). Не запускались: systemd (13.1), кластер (13.4), Laravel (8.3), публичный домен/Let's Encrypt.

Go Start и Go Pro (06–07.10.2026) — заглушки: репозитории и карточки «Методичка скоро» на главной есть, в учебный порядок и реестры сайта они пока не входят. Методички написаны в другом чате; вычитка и прогон Go Start от 07.10 сделаны другой моделью и не приняты (нужно перепроверить), Go Pro не вычитана и не проверена запуском. Ansible — только план. Подробности — в разделе «В работе» ниже.

№	Папка	Лаба	Сложность	Репозиторий
1	css	CSS с нуля — FrontFest (каскад, @layer, Flexbox, Grid, container queries, :has, темы)	Базовая	css-lab
2	tailwind	Tailwind CSS v4 — Pulse (@theme, варианты, container queries, dark mode)	Базовая	tailwind-lab
3	js	Чистый JS — Vanilla Helpdesk, фундамент без фреймворка	Средняя	js-lab
4	typescript	TypeScript 6 — Warehouse (generics, Zod, API + Vue)	Высокая	typescript-lab
5	vue	Vue 3 — Helpdesk (Router, Pinia, WebSocket, тесты)	Высокая	vue-lab
6	nuxt	Nuxt 4 — Help Center (SSR/SSG/SWR/SPA, Nitro, Drizzle, Nuxt Content)	Высокая	nuxt-lab
7	angular	Angular 22 — RoomBook (сигналы, DI, httpResource, Signal Forms, RxJS)	Высокая	angular-lab
8	php	Чистый PHP — свой роутер, DI-контейнер, PDO, CSRF	Базовая по материалу	php-lab
9	php-coffee	OOP на PHP/Laravel — Coffee Shop API	Базовая по материалу	oop-lab
10	algorithms-php	Алгоритмы и структуры данных на PHP — CoffeeAlgo	Базовая	algorithms-php-lab
11	postgresql	PostgreSQL — Coffee Shop изнутри (EXPLAIN, индексы, изоляция, блокировки, MVCC)	Средняя–высокая	postgresql-lab
12	redis	Redis — кэш, локи, rate limit, Streams	Средняя	redis-lab
13	rabbitmq	RabbitMQ — Transactional Outbox, воркеры, DLQ	Высокая	rabbitmq-lab
14	laravel	Laravel 13 изнутри — TaskFlow (таск-трекер с ролями)	Высокая	laravel-lab
15	laravel-performance	Laravel Performance — CoffeePerf (k6, SPX, OPcache, кеш, Octane)	Базовая	laravel-performance-lab
16	inertia	Inertia 3 + Laravel + Vue — Inkwell, блог-платформа	Средняя	inertia-lab
17	express	Express Lab — Node.js с нуля + ShareBox на Express, в двух частях перед TypeScript и NestJS (19 сессий, ~76 ч)	Низкая–средняя	express-lab
18	nestjs	NestJS — Helpdesk API с нуля (свой DI, JWT-ротация, WebSocket)	Высокая	nestjs-lab
19	graphql	GraphQL — CineGraph, самостоятельный проект (резолверы, DataLoader, Subscriptions)	Высокая	graphql-lab
20	centrifugo	Centrifugo — Realtime Workspace (Laravel + Centrifugo + Vue, 21 сессия, ~62 ч)	Средняя–высокая	centrifugo-lab
21	bash	Bash Lab — CoffeeOps, shell и bash с нуля (10 сессий, ~28 ч)	Базовая	bash-lab
22	docker	Docker Lab — контейнеры с нуля до релиза (12 сессий, ~44 ч)	Базовая по входу, объёмная	docker-lab
23	traefik	Traefik — reverse proxy, service discovery, TLS (11 сессий)	Низкая–средняя	traefik-lab
24	caddy	Caddy 2 — Edge, reverse proxy с автоматическим HTTPS	Средняя	caddy-lab
25	kubernetes	Kubernetes и Helm с нуля	Средняя–высокая	kubernetes-lab
26	prisma	Prisma — «Наследство»: чужая база на Prisma 7 и TypeScript	Средняя–высокая	prisma-lab

Личный прогресс (моя пометка, не часть плана репозитория): ✅ пройдено — RabbitMQ (сессии 1–6 после разбивки 22.10.2026; новые сессии 7–11 ещё не пройдены, они дописаны ассистентом после прохождения). 🔵 сейчас прохожу — Caddy Lab (caddy): сессии 1–2 пройдены (06–07.10.2026), дальше с сессии 3. OOP (php-coffee) — на паузе.

В работе (заглушки, без номера в витрине):

Папка	Лаба	Сложность	Репозиторий	Состояние
go-start	Go Start — CoffeeGo, Go с нуля до middle (12 сессий, ~55 ч)	Базовая	go-start-lab	методичка есть; вычитка и прогон от 07.10 сделаны другой моделью и не приняты — перепроверить
go-pro	Go Pro — CoffeeGo Platform, от middle до senior (13 сессий, ~72 ч)	Высокая	go-pro-lab	методичка есть; вычитка не завершена, запуском не проверена
ansible	Ansible Lab — управление серверами как кодом (10 сессий, ~40 ч по плану)	Средняя	ansible-lab	только план ansible_lab_plan.md, методички нет

---|---|---|---|---| | go-start | Go Start — CoffeeGo, Go с нуля до middle (12 сессий) | Базовая | go-start-lab | методичка есть; вычитка и прогон от 07.10 сделаны другой моделью и не приняты — перепроверить | | go-pro | Go Pro — CoffeeGo Platform, от middle до senior (13 сессий) | Высокая | go-pro-lab | методичка есть; вычитка не завершена, запуском не проверена | | bash | Bash Lab — CoffeeOps, shell и bash с нуля (10 сессий, ~28 ч) | Базовая | bash-lab | методичка есть (11.10.2026, собрана ассистентом; на сайте 24-я лаба); не вычитана человеком: все команды выполнены в Docker при сборке, но прохождения не было | | express | Express Lab — Node.js с нуля + ShareBox на Express, в двух частях перед TypeScript и NestJS (19 сессий, ~76 ч) | Низкая–средняя | express-lab | методичка переписана в две части ассистентом 14.10.2026 (9 находок, все исправлены, 2 открытых без решения; на сайте 25-я лаба); весь вывод — настоящий прогон в Docker (PostgreSQL для сессий 12–18); прохождения человеком не было | | centrifugo | Centrifugo — Realtime Workspace (Laravel + Centrifugo + Vue, 21 сессия) | Средняя–высокая | centrifugo-lab | методичка есть (11.10.2026, из другого чата); не вычитана и не проверена запуском |

---

1. CSS Lab — FrontFest (css/)

Сложность: базовая. Проект самостоятельный, кода из других лаб не берёт. Нужны только HTML и умение открыть страницу в браузере. Во фронтенд-треке идёт первой — до Tailwind и JavaScript.

О чём: современный CSS с нуля на сайте фронтенд-конференции: главная, программа-таймлайн, регистрация. Разметка выдаётся готовой, пишутся только стили. Каскад и слои → токены, цвет и темы → Flexbox → Grid и subgrid → адаптив, container queries, :has() и формы → позиционирование, анимации, view transitions и сборка.

Стек: чистый CSS, без фреймворков и препроцессоров.

Формат: методичка css.html — методичка готова и вычитана (30.09), прохождение впереди.

Что внутри (10 сессий, ~34 часа): основы и каскад; токены, цвет, темы, текст; Flexbox; Grid; адаптив, container queries, :has(), формы; позиционирование, движение, view transitions, сборка; печать и прокрутка; новые возможности как прогрессивное улучшение; производительность и stylelint; итоговое ТЗ без решения. Разделы 1–9 — теория, раздел 10 — сессии, разделы 11–14 — чек-лист, глоссарий, вопросы, что дальше.

---

2. Tailwind Lab — Pulse (tailwind/)

Сложность: базовая. Проект самостоятельный, кода из других лаб не берёт. Нужно уверенное знание CSS — удобнее после CSS Lab: Tailwind не заменяет каскад, flex, grid и :has(), а записывает их классами. Во фронтенд-треке идёт второй, до JS.

О чём: Tailwind CSS v4 с нуля на сервисе аналитики «Pulse»: маркетинговый лендинг, дашборд и страница настроек. Азбука утилит → тема через @theme → варианты и состояния → адаптив и container queries → тёмная тема, формы и переиспользование → продакшн. Разметку пишете сами; почти в каждой сессии шаг «сломать → починить» (динамический класс, которого нет в сборке, peer, который «не видит» чекбокс, @apply с «unknown utility»).

Стек: Tailwind CSS 4.3, Vite + @tailwindcss/vite, чистый HTML и немного JS; Docker (dev на Vite, prod на nginx).

Формат: методичка tailwind.html — методичка готова и вычитана (30.09), прохождение впереди.

Что внутри (10 сессий, ~28,5 ч): стенд и азбука; тема @theme; варианты и состояния; адаптив и container queries; тёмная тема, формы, @layer components, typography; продакшн и таблица «CSS-лаба ↔ Tailwind-лаба»; свои JS-плагины (matchUtilities, addVariant); RTL, логические свойства, forced-colors/prefers-contrast; производительность сканирования, stylelint, Production Hell; итоговое ТЗ без решения. Сессии 7–10 (22.10.2026) написаны ассистентом по содержанию, без вычитки и без прогона в Docker. Разделы 1–9 — теория, раздел 10 — сессии, 11–14 — чек-лист, глоссарий, вопросы, что дальше.

---

3. Чистый JS Lab — Vanilla Helpdesk (js/)

Сложность: средняя. Не требует предыдущих лаб — нужен только базовый синтаксис JS. Это общий фундамент для Vue Lab и TypeScript Lab, поэтому логично проходить её первой из трёх.

О чём: JavaScript с нуля, без единого фреймворка и без бандлера — то, что Vue и другие фреймворки обычно прячут: как на самом деле работают var/let/const и hoisting, this и замыкания, прототипы под капотом class, event loop, DOM и модули. Домен практики (тикеты) намеренно совпадает с Vue Lab — Helpdesk, чтобы в финале явно сравнить «vanilla vs Vue»; код при этом полностью свой, без единой связи с тем репозиторием.

Стек: JavaScript (ES2022+, без TypeScript и без сборки) + Node 24+ (LTS) для сессий-песочниц; в браузере — нативные ES-модули без бандлера; json-server как мок-API (только db.json, ноль кода); собственный ~15-строчный сервер на node:http; тесты — встроенный node --test; Docker (compose-файл создаётся в сессии 1).

Формат: методичка js.html — готова, прохождение впереди.

Что внутри (10 сессий): восемь сессий — язык, event loop, DOM, модули, мини-SPA; сессия 9 — надёжная асинхронность; сессия 10 — итоговое ТЗ (консольный отчёт по тикетам) без решения.

• Сессия 1 — переменные, область видимости, hoisting: воспроизведён и починен баг с var в цикле тремя способами
• Сессия 2 — типы, приведение, объекты, массивы: рефакторинг императивного кода в функциональный на методах массивов
• Сессия 3 — this, замыкания, паттерны: каррирование, мемоизация, приватность до и после #private
• Сессия 4 — прототипы, class, Symbol, коллекции: цепочка прототипов руками → class → сравнение с Map/Set
• Сессия 5 — event loop, Promises, fetch, debounce/throttle: своя очередь задач, реальный fetch к json-server, тесты на node --test
• Сессия 6 — DOM без фреймворка: список тикетов рендерится и обновляется без единой строки фреймворка
• Сессия 7 — модули (ESM), Storage, своя реактивность на Proxy
• Сессия 8 — финал: мини-SPA (свой роутер на history.pushState, стор на Proxy, рендер шаблонными строками) с явной таблицей сравнения «что Vue даёт бесплатно»

Разделы 1–14 методички — теория языка и рантайма (от типичных багов без понимания фундамента до event loop, DOM и модулей), раздел 15 — стек, структура проекта и поток данных, раздел 16 — сессии заданий, разделы 17–20 — чек-лист, глоссарий, вопросы для собеседования, что дальше.

---

4. TypeScript Lab (typescript/)

Сложность: высокая — абстрактное мышление на уровне типов (generics, conditional/mapped types) непривычно после динамического PHP. Нужно перед стартом: тот же JavaScript, что для Vue-лабы; логично проходить после или параллельно с ней (сессия 5 использует Vue).

О чём: типизация домена складского учёта (Warehouse) с нуля — без фреймворков до последней сессии, чтобы увидеть TypeScript в чистом виде и потом узнавать его в Nest/Vue. Что типы реально ловят (перепутанные аргументы, NaN от строки вместо числа, undefined в рантайме), а что — нет.

Стек: TypeScript 6.0 (код проверен и на 5.9) + Node 24+ (LTS) + tsx + Vitest + Zod, в финале — Express и Vue 3 + TS. Отдельный репозиторий на npm workspaces: packages/core, cli, api, web. Всё в Docker.

Формат: методичка typescript.html — 10 сессий (сессии 6–10 добавлены 21.10.2026); статус ✅: проверена запуском и вычитана ассистентом (24.10.2026); ниже план по оглавлению. Каждый шаг заканчивается зелёным npm run typecheck — это главный критерий готовности.

Что внутри (10 сессий, порядок строгий):

• Сессия 1 — стенд (Docker, workspaces, tsconfig.base, tsx, Vitest); песочница: аннотации, вывод типов, примитивы/объекты, union и литералы, type vs interface, функции, any/unknown/never, strict, as const
• Сессия 2 — домен склада: branded IDs, размеченное объединение Movement, exhaustive switch, Result вместо исключений, type predicates, readonly — applyMovement с тестами, невозможные состояния невыразимы на уровне типов
• Сессия 3 — generics и абстракции: Repository<T>, TypedEmitter<Events>, mapped/conditional/template literal types, satisfies — сервис Warehouse, собранный из типизированных кубиков
• Сессия 4 — CLI: parseArgs, команды как union из template literal types, валидация через Zod и z.infer, unknown в catch, .d.ts для JS, сборка esbuild — рабочий wh: item:add, stock:in/out/transfer/list/low, import:csv
• Сессия 5 — сквозная типизация: ApiContract, generic-клиент с conditional types, Express + Zod на бэкенде, Vue 3 + TS (defineProps/defineEmits с generics, типизированный store), vue-tsc — один источник типов и в API, и в браузере
• Сессия 6 — conditional types и infer: голый и обёрнутый параметр, infer K extends …, Filter<T>, FilterKey из template literal, граница строки --query — stock:filter в CLI
• Сессия 7 — стандартные декораторы TS 5 (метод, класс, аксессор), context.addInitializer, Token<T> и Container, bootstrap() вместо ручной сборки (в тестах Vitest 5 нужен unplugin-swc)
• Сессия 8 — тесты на типы: когда expectTypeOf на самом деле проверяет, *.types.test.ts, регрессия на MovementOf, скрипт-аудит @ts-expect-error
• Сессия 9 — project references: composite, tsc -b, declaration maps, два условия в exports, paths, .tsbuildinfo, кеш в CI
• Сессия 10 — итоговое ТЗ без решения: журнал аудита складских операций

---

5. Vue Lab (vue/)

Сложность: высокая, если фронтенд — новая территория. Нужно перед стартом: уверенный JavaScript (ES6+, async/await, деструктуризация); если сомневаетесь в фундаменте — сначала «Чистый JS» (js/). Опыт с Vue или другими фреймворками не требуется, готовый мини-бэкенд (Node) дан за вас.

О чём: Helpdesk (система тикетов) на Vue 3 с нуля — реактивность, компоненты, роутинг и общее состояние, каждое понятие на одном сквозном примере. Бэкенд (готовый мини-бэкенд на Node) дан в первой же сессии — писать его не нужно, только запустить.

Стек: Vue 3.5 + Vite 7 + Vue Router 4 + Pinia 2+ + Vitest, бэкенд — готовый мини-бэкенд (Node). Composition API + <script setup> (Options API — только в теории для сравнения). С сессии 6: vue-i18n, DOMPurify, MSW, Playwright. Всё в Docker.

Формат: методичка vue.html — 15 сессий (с 16.10.2026; сессии 1–5 вычитаны и проверены запуском, сессии 6–15 написаны, построчно не вычитаны); ниже план по оглавлению.

Что внутри (15 сессий, порядок строгий — Pinia раньше Router, потому что guard'ам роутера нужен auth-store):

• Сессия 1 — стенд (docker-compose, скаффолд готового бэкенда и create-vue); готовый мини-бэкенд на Node (auth, tickets, comments, history, WebSocket-gateway) — дан готовым; песочница реактивности: ref/reactive/computed/watch, директивы, v-model, v-for/key; useAsync и первый запрос к API
• Сессия 2 — разбор списка тикетов на компоненты: StatusBadge, TicketCard, TicketList (props/emits, слоты); BaseModal (слоты, Teleport, lifecycle, template refs); тосты через provide/inject; composable useNow/RelativeTime
• Сессия 3 — Pinia: state/getters/actions, storeToRefs, auth-стор с токеном, persist-плагин; оптимистичная смена статуса тикета с откатом при ошибке
• Сессия 4 — Vue Router: маршруты, lazy loading, RouterLink, guards (requiresAuth, роли, redirect после логина), вложенные маршруты, query-синхронизация, 404; страница тикета с вкладками, форма создания, onBeforeRouteLeave
• Сессия 5 — WebSocket (useSocket) с живыми обновлениями через store; канбан-доска (TransitionGroup, defineAsyncComponent, динамический компонент); тесты на Vitest (компонент, composable, store, router guard); production-сборка и деплой за прокси
• Сессия 6 — формы и валидация: defineModel с модификаторами и несколькими привязками, composable useForm (клиентские + серверные ошибки), загрузка вложения с превью и прогрессом
• Сессия 7 — composable-паттерны: useFetch с отменой устаревшего запроса, useLocalStorage, useClipboard, Suspense + defineAsyncComponent, onErrorCaptured
• Сессия 8 — производительность: профилирование в Vue Devtools, v-memo, shallowRef/shallowReactive, виртуальный список на 5000 строк
• Сессия 9 — Pinia в большом приложении: границы между store, композиция store-в-store, аудит действий через $subscribe/$onAction
• Сессия 10 — доступность: focus trap в модалке, aria-label/aria-live на уже кнопочном канбане (сессия 5), контраст, prefers-reduced-motion
• Сессия 11 — интернационализация: vue-i18n, ленивая загрузка локали, множественное число (RU), даты и числа через Intl
• Сессия 12 — безопасность фронтенда: санитайзинг v-html (DOMPurify), хранение токена и CSRF, CSP, wss с авторизацией на подключении
• Сессия 13 — продвинутое тестирование: MSW (подмена сети, а не модуля), e2e на Playwright, детерминированные тесты WebSocket и guard
• Сессия 14 — Production Hell: диагностика сломанного прод-билда (base path, build-time конфигурация, history fallback); SSR и гидратация в сравнении с Nuxt
• Сессия 15 — итоговое ТЗ без ответа: модуль SLA и эскалации, собирающий темы всех предыдущих сессий

Главная мысль лабы: Vue — это реактивность + компоненты + экосистема (Router — состояние адресной строки, Pinia — общее состояние), и каждое задание про то, где живёт состояние и кто его меняет.

---

6. Nuxt Lab — Help Center (nuxt/)

Сложность: высокая. Проект полностью самостоятельный (свой репозиторий nuxt-lab), кода из других лаб не берёт. Vue предполагается знакомым на уровне Vue-лабы (ref, computed, props/emits, Pinia, Router — не объясняются заново), TypeScript — на уровне сессий 1–3 TS-лабы. Логично проходить после Vue и TypeScript.

О чём: публичный центр поддержки, где у каждой зоны свой режим рендеринга: база знаний — prerender (SSG), статус сервисов — SWR-кеш, обращения клиента — SSR с сессией, кабинет агента — SPA (ssr: false). Всё, что Nuxt добавляет поверх Vue: SSR и гидрация, payload, Nitro, состояние на сервере, routeRules, SEO. Почти в каждой сессии — шаг «сначала сломать, потом починить»: двойной запрос, hydration mismatch, потерянная cookie, утечка состояния между пользователями, общий кеш на все запросы.

Стек: Nuxt 4.5+ (с пометками про v5), TypeScript strict + nuxi typecheck, Nitro server routes, SQLite + Drizzle, Zod-схемы в shared/, nuxt-auth-utils, @pinia/nuxt, Nuxt Content v3, @nuxtjs/sitemap + @nuxtjs/robots, Vitest + @nuxt/test-utils, Docker Compose.

Формат: методичка nuxt.html — методичка готова, прохождение впереди. У каждого шага: код → «зачем» → команда → ожидаемый результат → «проверь себя».

Что внутри (10 сессий, ~35,5 ч): шесть сессий (рендеринг, данные, Nitro, авторизация, контент, SEO и продакшн), затем 7 «реальное время» (SSE, WebSocket, задачи Nitro), 8 «i18n», 9 «безопасность», 10 — итоговое ТЗ без решения.

• Сессия 1 — стенд и основы: скаффолд Nuxt 4, файловый роутинг, layouts, что генерирует .nuxt/, SSR vs SPA руками (view-source, ssr: false, ClientOnly)
• Сессия 2 — данные и гидрация: server route и тип ответа из хендлера, payload и двойной запрос через $fetch, useFetch (query, lazy, pick, refresh), ошибки, hydration mismatch
• Сессия 3 — Nitro и БД: Drizzle + SQLite, readValidatedBody + Zod, middleware request-id, одна схема в shared/ на клиент и сервер, форма обращения
• Сессия 4 — авторизация и состояние: nuxt-auth-utils и роли, route middleware, cookie при SSR, утечка состояния через модульный ref → useState/useCookie, Pinia + callOnce, кабинет агента на ssr: false
• Сессия 5 — контент, кеш, рендеринг: Nuxt Content v3, defineCachedEventHandler и ключ кеша, routeRules (пререндер, SWR) на prod-сборке, инвалидация
• Сессия 6 — SEO и продакшн: useSeoMeta, sitemap/robots, runtimeConfig, тесты (unit, компонент, e2e), nuxt build и multi-stage Dockerfile, финал «Vue Lab vs Nuxt Lab»

Разделы 1–10 методички — теория (зачем Nuxt поверх Vue, азбука, рендеринг и гидрация под капотом, режимы рендеринга, данные, Nitro, состояние на SSR, авторизация, контент и SEO, структура проекта), раздел 11 — шесть сессий заданий, разделы 12–15 — чек-лист, глоссарий, вопросы для собеседования, что дальше.

---

7. Angular Lab — RoomBook (angular/)

Сложность: высокая. Проект полностью самостоятельный (свой репозиторий angular-lab), кода из других лаб не берёт. TypeScript — на уровне сессий 1–3 TS-лабы; всё специфичное для Angular (декораторы, DI, сигналы) объясняется в самой лабе. Опыт Vue полезен для сравнений, но не обязателен. Во фронтенд-треке идёт последней, после Nuxt: теория начинается с «зачем Angular после Vue и Nuxt».

О чём: внутренний сервис бронирования переговорных — каталог комнат, расписание дня, форма брони с проверкой пересечений, «мои брони», живые обновления, админка. Современный Angular — это сигналы + DI: реактивность без zone.js, сервисы и провайдеры, httpResource, Signal Forms, guards по ролям и RxJS там, где он правда нужен. Почти в каждой сессии — шаг «сломать → починить»: мутация массива, которую OnPush не видит, гонка ответов поиска, провайдер не на том уровне DI, 409 после проверки «свободно», утечка броней при смене пользователя, накопление SSE-соединений.

Стек: Angular 22 (standalone, zoneless, OnPush по умолчанию), Angular CLI + @angular/build, HttpClient + интерцепторы + httpResource, Signal Forms и Reactive Forms, RxJS 7 + rxjs-interop, Vitest через ng test; готовый API — api/server.mjs на Node 24 без зависимостей; Docker Compose, в проде nginx.

Формат: методичка angular.html — методичка готова, прохождение впереди. У каждого шага: код → «зачем» → команда → ожидаемый результат → «проверь себя».

Что внутри (10 сессий, 39 шагов, ~33,5 ч):

• Сессия 1 (~3 ч) — стенд и основы: готовый API и ng new, компоненты с input/output и @for, signal/computed/model/linkedSignal/effect; ломаем OnPush + zoneless мутацией массива (счётчик растёт, а сетка нет)
• Сессия 2 (~3,5 ч) — DI и HTTP: сервисы, уровни провайдеров и InjectionToken (провайдер не на том уровне), HttpClient + toSignal, httpResource с фильтрами на сервере, поиск без гонки ответов (mergeMap → switchMap), интерцепторы лога и ошибок
• Сессия 3 (~3 ч) — роутер: маршруты, lazy-загрузка, AppShell, дочерние маршруты расписания (и параметры родителя), resolver и индикатор навигации, query params как состояние
• Сессия 4 (~4 ч) — формы: Signal Forms (модель и схема), межполевая валидация, validateHttp для проверки свободного слота, submit и 409 после «свободно», свой контрол, Reactive Forms в админке
• Сессия 5 (~3,5 ч) — авторизация, состояние, потоки: AuthStore, вход, токен и 401, guards canActivate/canMatch/canDeactivate, стор на сигналах и утечка броней при смене пользователя, SSE + RxJS и takeUntilDestroyed
• Сессия 6 (~3,5 ч) — качество и продакшн: pipe и @defer, тесты (компонент, стор, guard) на Vitest, сборка, runtime-конфиг и nginx, финальная карта и сравнение с Vue/Nuxt
• Сессия 7 (~3,5 ч) — SSR и гидратация: серверные маршруты, TransferState, разбор NG0500, nginx перед Node
• Сессия 8 (~3 ч) — доступность и интернационализация: клавиатура, aria-live, @angular/localize, RTL
• Сессия 9 (~3 ч) — безопасность и Production Hell: DomSanitizer, CSP, security-заголовки, сломанный прод без подсказок
• Сессия 10 (~3,5 ч) — итоговое задание без решения

Сессии 7–10 (22.10.2026) написаны ассистентом по содержанию, по прямой инструкции владельца «только контент» — без вычитки и без прогона в Docker. Разделы 1–9 методички — теория (зачем Angular после Vue и Nuxt, азбука, реактивность на сигналах, DI под капотом, RxJS в 2026 году, роутер, формы, HTTP, стек и структура проекта), раздел 10 — десять сессий заданий, разделы 11–14 — чек-лист, глоссарий, вопросы для собеседования, что дальше.

---

8. Чистый PHP Lab (php/)

Сложность: базовая по материалу (нужен только синтаксис PHP и пройденная OOP-лаба — её принципы используются без повторного объяснения), но ближе к концу ощутимо прибавляет: сессии 1–4 — язык, сессии 5–8 — своя инфраструктура (роутер, DI-контейнер, PDO, CSRF).

О чём: чистый PHP 8.4 без единого фреймворка — то, что обычно прячет Laravel: strict_types и copy-on-write массивы, суперглобалы, исключения, замыкания и генераторы, магические методы, современный синтаксис (match, nullsafe), Composer и PSR-4 — и дальше своими руками: роутер, DI-контейнер, PDO-слой, сессии/CSRF. Домен — та же кофейня, что в OOP-лабе, но здесь пишется инфраструктура, которую там давал фреймворк.

Стек: PHP 8.4 CLI, встроенный dev-сервер, PostgreSQL через голый PDO, Composer только для автозагрузки (PSR-4) — без единого стороннего пакета до сессии 7.

Формат: методичка php.html — готова, прохождение впереди.

Что внутри (10 сессий): сессии 1–8 — язык и своя инфраструктура, 9 — валидация, пагинация, идемпотентность, 10 — итоговое ТЗ без решения.

• Сессия 1 — стенд; declare(strict_types=1) + таблица == (чем PHP 7 отличается от PHP 8)
• Сессия 2 — copy-on-write массивов на измерении момента копирования; array_filter vs usort (ключи, мутация); mb_* на кириллице + sprintf + regex
• Сессия 3 — предсказать → проверить: $_GET и приведение типов; php://input — JSON-тело запроса; finally vs exception handler — порядок выполнения
• Сессия 4 — use ($var) vs use (&$var) в замыканиях; генератор vs жадное чтение — измеряем память; свой фасад через __callStatic; match + nullsafe на неполных данных
• Сессия 5 — PSR-4: автозагрузка до и после; свой роутер v1 (наивный) → v2 (regex-параметры)
• Сессия 6 — боль без DI-контейнера (ручное связывание) → контейнер v1 (явные фабрики + singleton) → v2 (autowiring через Reflection)
• Сессия 7 — SQL-инъекция: найти → исправить; транзакция с rollBack после частичного сбоя; CSRF своими руками (сессия + hash_equals); свой .env-парсер
• Сессия 8 — финал: сборка index.php, middleware-цепочка, тесты + таблица «что даёт Laravel»

Разделы 1–12 методички — теория языка и рантайма, раздел 13 — сессии заданий, разделы 14–17 — чек-лист, глоссарий, вопросы для собеседования, что дальше.

---

9. OOP Lab (php-coffee/)

Сложность: базовая по материалу (нужен только синтаксис PHP, фреймворк — с сессии 5), но именно здесь стоит не спешить, если ООП пока даётся тяжело: это фундамент, который потом всплывает во всех остальных лабах.

О чём: объектно-ориентированное программирование на PHP 8.4 с нуля — не абстрактно, а на маленьком API кофейни. Отдельный, ни от чего не зависящий проект (в отличие от Redis/RabbitMQ-лаб не растёт из общей системы заказов).

Стек: Laravel 13 (PHP 8.4) + PostgreSQL 18 + RabbitMQ + Mailpit — брокер появляется только в последней сессии.

Формат: методичка php-coffee.html (вычитана и исправлена 24.09) — ниже план по оглавлению. Первая сессия начинается с чистого PHP без фреймворка, чтобы увидеть ООП "без магии Laravel".

Что внутри (10 сессий):

• Сессия 1 — касса на массивах (и почему это плохо) → первый объект Money → abstract class Drink + enum + полиморфизм → заказ с инвариантами
• Сессия 2 — тесты для Money; иерархия напитков-наследников; фабрика DrinkType + GET /api/menu
• Сессия 3 — интерфейс Beverage; паттерн Decorator для добавок (сироп, шот и т.д.); сущность Order + OrderStatus; Repository + POST /api/orders
• Сессия 4 — DiscountPolicy + Clock; чекаут со стратегиями оплаты (PaymentMethod) + /pay; тесты на стратегиях; эксперимент "а если бы делали через наследование" (чтобы почувствовать разницу с композицией)
• Сессия 5 — EventPublisher + событие order.paid; воркеры (бариста + уведомления) на RabbitMQ (один topic-exchange, две очереди — подробно эту схему разберёте позже в RabbitMQ-лабе); сквозной тест без БД и без брокера; финал "до/после"
• Сессия 6 — SOLID на практике: программа лояльности без правки старого кода (LoyaltyAccount, четвёртая DiscountPolicy-стратегия)
• Сессия 7 — тестирование глубже: тест-дублёры (Stub/Fake/Spy/Mock), #[DataProvider], обработчики воркера без AMQP
• Сессия 8 — Observer, Adapter, Facade: уведомления, внешний платёжный SDK, OrderCheckoutFacade
• Сессия 9 — безопасность и Production Hell: защищённый staff-эндпоинт, разбор сломанного прода без подсказок
• Сессия 10 — итоговое задание без решения: отмена оплаченного заказа с откатом баллов

Проходит через: 4 принципа ООП, abstract class vs interface, наследование vs композиция, паттерны (Factory, Decorator, Strategy, Repository, Observer, Adapter, Facade), SOLID — всё на одном сквозном примере. Сессии 6–10 (22.10.2026) написаны ассистентом по содержанию, по прямой инструкции владельца «только контент» — без вычитки и без прогона в Docker.

---

10. Algorithms PHP Lab — CoffeeAlgo (algorithms-php/)

Сложность: базовая. Проект самостоятельный (свой репозиторий algorithms-php-lab), кода из других лаб не берёт. Нужен только синтаксис PHP; первые сессии используют лишь циклы, массивы и функции, сложное нарастает постепенно.

О чём: алгоритмы и структуры данных на PHP — от «сколько шагов делает цикл» до задач с собеседований. Каждая тема — на задаче кофейни, с тестом PHPUnit и замером времени; в большинстве тем есть шаг «сломать → починить» (невидимый O(n²), вырожденное дерево, обход без пометки посещённых).

Стек: PHP 8.4 CLI, SPL, PHPUnit, Composer (только автозагрузка), Docker.

Формат: методичка algorithms-php.html — методичка готова и вычитана (04.10.2026), прохождение впереди.

Что внутри (13 сессий, ~44 ч): сложность без формул и замер; массивы и строки; хеш-таблицы и множества; стек и очередь; связные списки; рекурсия; бинарный поиск и сортировки (включая устойчивость); два указателя, скользящее окно, префиксные суммы; деревья (BST, обходы); кучи и топ-K; графы (BFS, DFS, Дейкстра); динамическое программирование (размен монет, рюкзак, LCS); разбор собеседований со шаблоном ответа, пятью задачами с замером и шпаргалкой по сложностям.

---

11. PostgreSQL Lab (postgresql/)

Сложность: средняя–высокая. Проект полностью самостоятельный (свой репозиторий postgresql-lab, только SQL-файлы и docker-compose.yml), ни от одной другой лабы не зависит — общая с OOP- и PHP-лабами только идея «кофейни». Входной уровень — «умею SELECT/INSERT»; если JOIN пока «тёмный лес», есть вводная сессия 0. Параллели с Laravel/Eloquent даны по ходу, но фреймворк знать не обязательно.

О чём: Postgres есть почти в каждой лабе, но везде он был «чёрным ящиком за ORM». Здесь — то, что происходит под ORM, на базе кофейни с реальным объёмом данных (20 кофеен, 100 000 клиентов, 1 000 000 заказов, 2,5 млн позиций, 3 млн событий): устройство Postgres изнутри (процессы, страницы, shared buffers, WAL, планировщик), чтение EXPLAIN (ANALYZE, BUFFERS), индексы под конкретный запрос (B-tree, частичные, функциональные, покрывающие, GIN, BRIN), статистика, N+1 глазами базы, изоляция и аномалии, блокировки и дедлоки, MVCC и VACUUM, партиционирование.

Стек: PostgreSQL 18 в Docker + psql + pgbench; расширения pg_stat_statements, pg_trgm, pageinspect, btree_gist. Никакого фреймворка и ORM.

Формат: методичка postgresql.html — методичка готова, прохождение впереди. У каждого шага — «Под капотом» и тренировка с ответами под спойлером; главный артефакт — журнал NOTES.md с планами «до/после».

Что внутри (10 сессий, ~33 ч): семь сессий (JOIN, окружение, EXPLAIN, индексы, транзакции, блокировки, MVCC и партиционирование), затем 8 «роли и RLS», 9 «копии, PITR, репликация», 10 — итоговое ТЗ без решения; нумерация с 1.

• Сессия 0 — JOIN с нуля на песочнице из пяти клиентов и семи заказов: INNER/LEFT/RIGHT/FULL, ловушка «условие в WHERE», self-join, anti- и semi-join, JOIN + GROUP BY
• Сессия 1 — Postgres в Docker с инструментами наблюдения, psql как рабочее место, схема кофейни, миллион заказов за минуту, SQL-инструментарий (CTE, оконные функции, FILTER, LATERAL), как таблица лежит на диске
• Сессия 2 — EXPLAIN и B-tree: от Seq Scan на миллион строк до 20 прочитанных записей, составные индексы, статистика, частичные, функциональные и покрывающие индексы
• Сессия 3 — алгоритмы JOIN и work_mem, GIN и BRIN, расширенная статистика, N+1 через pg_stat_statements, пагинация, охота на медленные запросы
• Сессия 4 — транзакции и изоляция: потерянное обновление через pgbench, Read Committed, Repeatable Read, Serializable и write skew, ограничения как последняя линия обороны
• Сессия 5 — блокировки: FOR UPDATE, очередь на SKIP LOCKED, дедлок, pg_blocking_pids(), миграции без простоя, advisory locks
• Сессия 6 — MVCC и VACUUM изнутри (pageinspect, xmin/xmax, горизонт, HOT, wraparound), партиционирование журнала событий, "Production Hell" — задания без подсказок

Разделы 1–8 методички — теория (чего не видно из ORM, как PostgreSQL устроен внутри, архитектура и схема данных, стек и структура, индексы, как читать EXPLAIN, транзакции и блокировки, MVCC/VACUUM/партиционирование/N+1), раздел 9 — сессии заданий, разделы 10–13 — чек-лист, глоссарий, вопросы для собеседования, что дальше.

---

12. Redis Lab (redis/)

Сложность: средняя. Нужно перед стартом: то же, что для RabbitMQ-лабы (Laravel, Docker), домен заказов переиспользуется. Рекомендуется после RabbitMQ Lab: методичка постоянно сравнивает Streams с брокером.

О чём: Redis как кэш, хранилище сессий, примитив синхронизации и брокер событий — одновременно, на кусочке той же системы заказов. Лаба специально показывает, где каждая из этих ролей "подводит" (что будет при рестарте без AOF, при отвале Pub/Sub-подписчика, при гонке за один и тот же лок).

Стек: Laravel 13 + PostgreSQL 18 + Redis 8.

Формат: методичка redis.html (открывается в браузере, прогресс по чекбоксам сохраняется локально) — ещё не пройдена, ниже план по оглавлению.

Что внутри (11 сессий):

• Сессия 1 — docker-compose и redis.conf, Laravel + .env, миграции; Cache-Aside для карточки товара (ProductRepository); сессии в Redis (SESSION_DRIVER=redis); StreamPublisher — первый producer в Redis Streams; первый consumer (happy path)
• Сессия 2 — distributed lock (SET NX PX) в StockReservationService, чтобы не продать один товар дважды; rate limiter (sliding window); competing consumers + нагрузочный тест; crash-тест на PEL (Pending Entries List) и идемпотентность
• Сессия 3 — retry через XAUTOCLAIM; ручной DLQ-поток; приоритет очереди через ZSET; Pub/Sub-дашборд в реальном времени; "Production Hell" — комплексный сценарий без подсказок
• Сессия 4 — структуры данных глубже: Hash, List, Set, Bitmap, HyperLogLog на реальных задачах каталога
• Сессия 5 — TTL, память и политики вытеснения
• Сессия 6 — кеш-паттерны и инвалидация в Laravel (по тегам и событиям)
• Сессия 7 — транзакции, WATCH, pipeline и Redis Functions вместо Lua-скриптов
• Сессия 8 — распределённые локи и rate limiting глубже (Redlock-подобный подход)
• Сессия 9 — персистентность (RDB/AOF), репликация, Sentinel и Cluster
• Сессия 10 — безопасность, ACL, наблюдаемость и производительность
• Сессия 11 — итоговое задание без решения

Логика подачи материала зеркалит RabbitMQ-лабу (архитектура → сборка по шагам → "под капотом" → что почитать перед следующим шагом), но через призму структур данных Redis вместо AMQP. Сессии 4–11 (21.10.2026) написаны ассистентом по содержанию, по прямой инструкции владельца «только контент» — без вычитки и без прогона в Docker.

---

13. RabbitMQ Lab (rabbitmq/)

Сложность: высокая. Нужно перед стартом: уверенный Laravel/PHP (транзакции, Artisan-команды, очереди хотя бы на уровне концепции), базовые транзакции SQL, Docker Compose «запустить и посмотреть логи».

О чём: асинхронная обработка заказов интернет-магазина через очереди, с упором на паттерны надёжной доставки — то, что в реальных системах спасает от потери и дублирования сообщений.

Стек: Laravel 13 (PHP 8.4) + PostgreSQL 18 + RabbitMQ (Management UI) + Mailpit, всё в Docker Compose.

Архитектура: HTTP-запрос создаёт заказ и сразу пишет "записку" о событии в таблицу outbox_messages — в той же транзакции БД (паттерн Transactional Outbox, чтобы не потерять событие, если публикация в брокер упадёт). Отдельный процесс outbox-relay забирает записки и публикует их в exchange orders.topic. Дальше три независимых воркера (order-worker, email-worker, analytics-worker) разбирают свои копии сообщения из очередей: резервируют склад, шлют письмо, пишут в аналитику.

Что пройдено (владельцем, сессии 1–6 после разбивки на главы 22.10.2026 — раньше это были 3 более крупные сессии, материал тот же):

• Хопы 1–8: путь заказа от HTTP до БД, шаг за шагом, с точками наблюдения (dd(), логи, RabbitMQ UI)
• Что происходит, когда не хватает товара на складе
• Идемпотентный consumer: таблица processed_messages защищает от повторной обработки при redelivery
• Competing consumers + prefetch (basic_qos) — честное распределение нагрузки vs эффект "воркера-заложника" при большом prefetch
• Crash-тесты: docker compose kill (грубое убийство) и падение после коммита, но до ack — на практике поймали баг с SIGKILL на PID 1 в контейнере (ядро Linux его игнорирует), заменили на exit()
• Retry с TTL → DLX для писем: email.retry.1/2/3 (10с/30с/300с) → email.dlx → назад в email.queue или в email.dlq после исчерпания попыток
• Читатель DLQ (worker:failed-email) — ручной разбор "мёртвых" сообщений
• Сравнение с нативными Laravel Queue Jobs ($tries/$backoff/failed_jobs) на том же RabbitMQ — чтобы почувствовать, где ручной AMQP-слой даёт то, чего нет из коробки (идемпотентность, publisher confirms, чужие consumer'ы не на Laravel)
• Priority queues (x-max-priority) с backlog — почему приоритет виден только при накопленной очереди
• Fanout (lab:broadcast / worker:broadcast) — широковещание всем подписчикам через system.broadcast, в отличие от topic-маршрутизации остального проекта

Чего владелец ещё не видела — дописано ассистентом 22.10.2026, только по содержанию, без вычитки и без прогона в Docker:

• В главу 2 (Transactional Outbox) добавлены 2 новых шага сверх пройденного: тест атомарности outbox (откат транзакции не оставляет запись в outbox) и идемпотентность повторного POST того же заказа.
• Пять новых сессий 7–11: Policies и Single Active Consumer (политика на лету вместо ручных x-*, гарантированный порядок на одной очереди); Quorum queues и отказоустойчивость (перевод очереди на quorum, падение узла кластера); Наблюдаемость (rabbitmq_prometheus, алерт на backlog DLQ); Безопасность и Production Hell 2 (vhost с правами только на чтение, TLS до брокера, 6 новых сценариев без подсказок); Итоговое задание — сага «оплачен → резерв → отправка → завершение» с компенсацией, без решения.

Пример выполнения — в самом репозитории rabbitmq-lab (сабмодуль rabbitmq/):

• рабочий код всех воркеров и команд — laravel-app/app/Console/Commands/
• пошаговый разбор пути заказа (хопы, точки наблюдения, что смотреть в БД/UI/логах) — docs/order-path-explained.md
• ответы на все 18 вопросов для самопроверки, привязанные к коду проекта — docs/self-check-answers.md
• подборка справочных материалов по темам лабы — docs/rabbit.md

---

14. Laravel Lab (laravel/)

Сложность: высокая. Нужно перед стартом: базовый Laravel (роутинг, контроллеры, миграции, Blade — даются ссылками на документацию, без разбора), ООП на PHP (см. php-coffee/) и общее представление про очереди (см. rabbitmq/) — лаба на них ссылается, а не объясняет заново.

О чём: Laravel 13 "изнутри" — не "как вызвать", а что происходит на каждом слое фреймворка (~30 компонентов illuminate/*, связанных через контейнер), на сквозном таск-трекере TaskFlow с воркспейсами, ролями и приглашениями.

Стек: Laravel 13 (PHP 8.4) + PostgreSQL 18 + Redis 8 + RabbitMQ 4 + Mailpit + Laravel Reverb; фронт — Vue 3 + Vite (JavaScript, только API-клиент). Всё в Docker.

Формат: методичка laravel.html — не пройдена, ниже план по оглавлению.

Что внутри (10 сессий):

• Сессия 1 — стенд (Docker, Laravel 13, Sanctum/Reverb/RabbitMQ-драйвер), схема данных и миграции
• Сессия 2 — Eloquent: связи, pivot, N+1 — разбираем боль по шагам (hasMany/belongsTo, belongsToMany + свой Pivot-класс, attach/sync/toggle, полиморфные связи, hasManyThrough)
• Сессия 3 — коллекции (groupBy/partition/reduce/keyBy), API Resources (whenLoaded/whenCounted), три вида пагинации
• Сессия 4 — HTTP-слой: Form Requests, своё middleware с параметром, обработка исключений API, полноценный CRUD задач
• Сессия 5 — Service Container и провайдеры: build/bind/call изнутри, contextual binding (when/needs/give)
• Сессия 6 — Auth: Sanctum SPA (cookie + CSRF), Gate и Policy, роли, приглашения по токену + минимальный Vue-фронт (логин, доска)
• Сессия 7 — Observer (жизненный цикл модели), события и Listeners, Job (retry, ShouldBeUnique, failed_jobs) на RabbitMQ — та же схема, что в RabbitMQ-лабе
• Сессия 8 — Mailable (markdown-письма, очередь), Notification (mail + database), Scheduler (дайджест задач)
• Сессия 9 — Cache::remember + инвалидация в Observer, Cache::lock от гонки, RateLimiter, Broadcasting через Reverb + Echo
• Сессия 10 — фабрики для всех моделей, feature-тесты (RefreshDatabase), fakes/моки (Event/Notification/Mail), финальный прогон

Лаба построена вокруг карты Laravel (Kernel → Middleware → Router → Controller, плюс сквозные Container/Events/Auth и менеджеры Database/Cache/Queue/Mail/Broadcasting) и проходит по каждому слою последовательно — от жизненного цикла запроса до тестов.

---

15. Laravel Performance Lab — CoffeePerf (laravel-performance/)

Сложность: базовая. Проект самостоятельный (свой репозиторий laravel-performance-lab), кода из других лаб не берёт. Нужен базовый Laravel (маршруты, контроллеры, Eloquent) и Docker Compose на уровне «поднять и посмотреть логи»; всё остальное — k6, профилировщики, OPcache, Octane — объясняется с нуля.

О чём: измерять, а не гадать. Приложение Coffee Shop с намеренными проблемами (N+1, тяжёлый отчёт без индекса) и миллионом заказов; каждое изменение подтверждается цифрами «до / после» при одних и тех же условиях прогона.

Стек: Laravel 13 (PHP 8.4), PostgreSQL 18, Redis 8, nginx 1.30, k6, Debugbar и Telescope, SPX и Blackfire, OPcache и JIT, Octane + FrankenPHP. Всё в Docker Compose.

Формат: методичка laravel-performance.html — методичка готова и вычитана (04.10.2026), прохождение впереди.

Что внутри (10 сессий, ~38 ч; сессия 10 — итоговое ТЗ без решения):

• Сессия 1 — стенд, датасет в 1 млн заказов, приложение с проблемами; перцентили, первый замер curl и ApacheBench
• Сессия 2 — k6 с нуля: smoke, load, stress, spike, пороги и код возврата; таблица «ДО»
• Сессия 3 — Debugbar и Telescope; запрет lazy loading и починка N+1; почему Telescope нельзя на прод
• Сессия 4 — SPX, wall-time против CPU, flamegraph отчёта, правка и замер; Blackfire
• Сессия 5 — OPcache и его настройки для продакшна, поломка со «старым кодом»; JIT и честный замер
• Сессия 6 — optimize и route:cache, env() вне конфигов, кеш с тегами в Redis, cache stampede и блокировки, индексы и EXPLAIN
• Сессия 7 — Octane на FrankenPHP: модель, запуск в Docker, сравнение с PHP-FPM на k6, перезагрузка воркеров
• Сессия 8 — подводные камни Octane: чужие данные между пользователями, scoped-привязка, утечки памяти; итоговое сравнение
• Сессия 9 — таблица «до → после», бюджет p95 и регрессионный тест k6 в CI, prod-образ, чек-лист «тормозит — что делать»

---

16. Inertia Lab — Inkwell (inertia/)

Сложность: средняя. Проект самостоятельный (свой репозиторий inertia-lab), кода из других лаб не берёт. Предполагается знакомство с Laravel (контроллеры, Eloquent, FormRequest, Policies — уровень Laravel Lab) и с Vue 3 (Composition API — уровень Vue Lab); сам мост Inertia объясняется с нуля. Логичнее всего идёт после Laravel-лабы.

О чём: блог-платформа Inkwell на Laravel 13 + Inertia 3 + Vue 3 + TypeScript, собранная без starter kit. Протокол Inertia (объект страницы, XHR-визиты, конфликт версий, 303-редиректы) → props как публичный API (API Resources, optional/defer/merge/once) → путь формы и валидации без 422 → SSR и его типичные поломки (hydration mismatch, Pinia-утечка между посетителями). Три роли — reader, author, editor — на Policies, без дублирования прав на фронте.

Стек: Laravel 13 (PHP 8.4), inertiajs/inertia-laravel + @inertiajs/vue3 3, Vue 3 (<script setup lang="ts">), TypeScript strict, Pinia, Laravel Wayfinder, Tailwind CSS 4, SQLite.

Формат: методичка inertia.html — методичка готова и вычитана (04.10.2026), прохождение впереди.

Что внутри (10 сессий, ~31,5 ч): протокол и фундамент (Inertia руками, лента, layout, Wayfinder); страница поста (SEO, SSR — включаем, ломаем, чиним); пользователи и формы (сессии, flash, Pinia, Policies, редактор); данные и производительность (фильтры, бесконечная лента, deferred props, polling); тесты, сборка, SSR в проде, Production Hell; реальное время (Reverb и живые комментарии); поиск (Scout, похожие посты); UX как в приложении (instant visits, view transitions, модалка как маршрут); живая валидация (Precognition) и браузерные E2E; итоговое задание без решения. Сессии 6–10 (22.10.2026) написаны ассистентом по содержанию, по прямой инструкции владельца «только контент» — без вычитки и без прогона в Docker. Разделы 1–8 — теория, раздел 9 — сессии, 10–13 — чек-лист, глоссарий, вопросы, что дальше.

---

17. Express Lab — Node.js + ShareBox (express/)

Сложность: низкая–средняя. Две части: часть I (Node с нуля) требует пройденный js-lab; часть II (Express) самостоятельна внутри лабы. Введение перед TypeScript и NestJS.

О чём: Часть I — Node.js с нуля: рантайм, протокол HTTP, свой сервер, процессы, архитектура, тесты, без языка JS (он в js-lab); финал — CLI «Загрузчик страниц». Часть II — Express на сквозном проекте ShareBox (файлообменник со ссылками до 200 МБ); финал — командное пространство ShareBox Teams. В конце части II — таблица «что из этого скрывает NestJS».

Стек: Node 24, Express 5, PostgreSQL 18, Prisma 7, node:test и supertest, Docker.

Формат: методичка express.html — 🟡 переписана в две части ассистентом 14.10.2026 (9 находок, все исправлены, 2 открытых пункта без решения — см. fixes/backend/express.md); весь вывод — настоящий прогон в Docker (PostgreSQL для сессий 12–18); владелец лабу ещё не проходила.

Что внутри (19 сессий, 94 шага, ~76 ч): часть I — Node и npm, файлы/Buffer/Streams, протокол HTTP и свой сервер, процессы и параллелизм, архитектура (слои, свои ошибки, zod), тестирование (моки/стабы), эксплуатационная граница → финал «Загрузчик страниц». Часть II — Express 5 → REST и контракт API → ошибки/валидация → PostgreSQL → Prisma 7 → JWT-аутентификация → файлы → share-ссылки → админка и наблюдаемость → тесты и Docker → финал ShareBox Teams. Справка: шпаргалка, справочник ошибок, глоссарий, вопросы на собеседование.

---

18. NestJS Lab (nestjs/)

Сложность: высокая. Проект полностью самостоятельный — не требует прохождения других лаб. TypeScript-минимум, нужный для Nest, объясняется по ходу в сессии 1. Это полное изучение NestJS с нуля как отдельной технологии: домен Helpdesk похож на Vue Lab только по смыслу, зависимости от неё нет.

О чём: Helpdesk API собирается с нуля слой за слоем, и на каждом шаге видно, что скрывает декоратор @Injectable(), когда его пишут не глядя: свой мини-DI контейнер и метаданные декораторов, границы модулей и provider scopes, DTO и ValidationPipe, Prisma и транзакции, JWT-ротация refresh-токенов с reuse-detection, RBAC и владение через TicketPolicy, доменные события, WebSocket-шлюз с комнатами и своей авторизацией на handshake, свой динамический модуль, unit- и e2e-тесты.

Стек: NestJS 11 + TypeScript (strict), Node 24+ (LTS), Prisma 7 + PostgreSQL 18, class-validator/class-transformer, @nestjs/passport + passport-jwt + @nestjs/jwt + argon2, @nestjs/event-emitter, @nestjs/websockets (Socket.IO), @nestjs/swagger, helmet + @nestjs/throttler, @nestjs/terminus, Jest + supertest. Всё в Docker.

Prisma 7 везде (NestJS- и GraphQL-лабы): в командах стоит @7, потому что на npm у prisma сейчас latest — 8.0 RC. NestJS закреплён на 11 (@nestjs/cli@11): @latest создаёт NestJS 12.

Формат: методичка nestjs.html — открывается в браузере, прогресс по чекбоксам сохраняется локально. Перестроена 12–15.10.2026 с 5 до 14 сессий (37 шагов, формат Caddy); сессия 1 вычитана, сессии 2–14 — нет.

Что внутри (14 сессий, 37 шагов, вычитаны и прогнаны 24.10.2026):

• Сессия 1 — TypeScript для Nest и как на самом деле работает DI: декораторы и метаданные, мини-DI-контейнер руками, первый настоящий модуль
• Сессия 2 — модули, конфигурация, провайдеры: границы модулей, ConfigModule с валидацией env, useValue/useFactory
• Сессия 3 — PostgreSQL и Prisma: Docker Compose, схема, первая миграция, PrismaService, тестовые данные
• Сессия 4 — DTO и ValidationPipe, CRUD тикетов
• Сессия 5 — ошибки Prisma в HTTP, транзакции, слои приложения (история изменений)
• Сессия 6 — регистрация и хэши (argon2), логин и JwtStrategy
• Сессия 7 — guards, @Public()/@CurrentUser(), как Reflector читает метаданные
• Сессия 8 — refresh-токены: ротация и обнаружение повторного использования (reuse detection)
• Сессия 9 — роли и владение ресурсом (TicketPolicy), доменные события
• Сессия 10 — комментарии и внутренние заметки
• Сессия 11 — WebSocket-шлюз: комнаты, авторизация на handshake
• Сессия 12 — middleware, interceptors, Swagger, безопасность (CORS, helmet, rate limit)
• Сессия 13 — unit- и e2e-тесты
• Сессия 14 — свой динамический модуль (аудит), health-чеки, graceful shutdown, Docker, "Production Hell" — финальный сценарий без подсказок

Разделы 1–8 методички — теория (разбор задачи, как NestJS устроен внутри, итоговая архитектура, стек и структура, access/refresh-аутентификация, сценарий жизненного цикла тикета, Pipes/Guards/Interceptors/Filters, real-time и доменные события), раздел 9 — сессии заданий, разделы 10–13 — чек-лист, глоссарий, вопросы для собеседования, что дальше.

---

19. GraphQL Lab (graphql/)

Сложность: высокая. Проект полностью самостоятельный (свой репозиторий graphql-lab), ни от одной другой лабы не зависит — домен другой (каталог фильмов, а не Helpdesk). Из знаний пригодятся основы NestJS (модули, DI, декораторы) и TypeScript на уровне «классы, интерфейсы, async/await» — всё остальное объясняется по ходу.

О чём: CineGraph — каталог фильмов, режиссёров и рецензий, спроектированный так, чтобы естественно упереться во все ключевые темы GraphQL: язык запросов и жизненный цикл запроса, N+1 в резолверах и DataLoader, JWT и права на уровне полей, интерфейсы и юнионы (фильмография, поиск), курсорная пагинация рецензий (Relay Connection), подписки на живую ленту через Redis, защита от тяжёлых запросов (depth limit + query complexity).

Стек: NestJS + @nestjs/graphql + Apollo Server (code-first: @ObjectType/@Field/@Resolver), Prisma 7 + PostgreSQL 18, dataloader для батчинга, @nestjs/jwt + bcryptjs, graphql-subscriptions/graphql-redis-subscriptions + Redis, graphql-query-complexity. Всё в Docker.

Формат: методичка graphql.html — открывается в браузере, прогресс по чекбоксам сохраняется локально.

Что внутри (10 сессий):

• Сессия 1 — инфраструктура и схема: репозиторий и NestJS, docker-compose (Postgres + Redis), модель данных и seed, первые ObjectType/Query, резолверы полей наивно, воспроизводим и считаем N+1, input-типы
• Сессия 2 — DataLoader, мутации, ошибки, права, полиморфизм: DataLoader на каждый запрос, вычисляемые поля, JWT-мутации, мутации рецензий с guard и владением, формат ошибок и маскировка, права на уровне полей и ролей, интерфейсы и юнионы, курсорная пагинация
• Сессия 3 — подписки, Redis, защита, тесты: живая лента рецензий, два инстанса и Redis Pub/Sub, клиент без библиотек (fetch + graphql-ws), depth limit и query complexity, unit- и e2e-тесты, "Production Hell" — финальный сценарий без подсказок
• Сессия 4 — схема как контракт: свои скаляры, middleware резолверов, эволюция схемы без breaking changes
• Сессия 5 — мутации по-взрослому: union-ошибки вместо исключений, транзакции, идемпотентность
• Сессия 6 — кеширование и производительность: Cache-Control, Automatic Persisted Queries, Redis
• Сессия 7 — безопасность: CORS/CSRF, rate limit, refresh-токены, allowlist запросов
• Сессия 8 — федерация: subgraph, gateway, когда она нужна (и когда не нужна)
• Сессия 9 — наблюдаемость: логи, метрики, трассировка резолверов, нагрузочный тест k6
• Сессия 10 — итоговое задание без решения: подборки фильмов

Разделы 1–8 методички — теория (типичные заблуждения о GraphQL, как GraphQL устроен внутри, итоговая архитектура, стек и структура, N+1 и DataLoader, сценарий жизни одной рецензии, ошибки и nullability, пагинация/безопасность/кэш), раздел 9 — десять сессий заданий, разделы 10–13 — чек-лист, глоссарий, вопросы для собеседования, что дальше. Сессии 4–10 (21.10.2026) написаны ассистентом по содержанию, по прямой инструкции владельца «только контент» — без вычитки и без прогона.

---

20. Centrifugo Lab — Realtime Workspace (centrifugo/)

Сложность: средняя–высокая (решение владельца 08.10.2026). Проект самостоятельный; нужны основы Laravel, Docker и HTTP/JSON.

О чём: realtime на Centrifugo: WebSocket-соединения, каналы и namespaces, centrifuge-js, публикация из Laravel, JWT и subscription tokens, proxy, presence и history, recovery и reconnect, Outbox, тесты, production (nginx, Redis engine) и нагрузка. Сквозной проект — Realtime Workspace (Laravel + Centrifugo + Vue).

Стек: Centrifugo ≥ 6.9, centrifuge-js 5.x, Laravel 13 / PHP 8.4, Vue, Redis, PostgreSQL, Docker.

Формат: методичка centrifugo.html — получена из другого чата 11.10.2026 (21 сессия, 138 шагов, ~62 ч); на сайте с 11.10; 🟡 не вычитана и не проверена запуском, кода прохождения нет. План — centrifugo_lab_plan_v4.md.

---

21. Bash Lab — CoffeeOps (bash/)

Сложность: базовая. Самостоятельная лаба: ничего знать заранее не нужно, Docker объясняется в шаге 1.2. Идёт первой в инфраструктурном треке — скрипты нужны всем следующим лабам.

О чём: shell и bash с нуля на проекте CoffeeOps — набор скриптов обслуживания кофейни (заказы, отчёты, бэкап, деплой, тесты). Среда — контейнер из bash:5 с GNU-утилитами (на macOS системный bash — 3.2).

Стек: bash 5.3, shellcheck, jq, GNU coreutils/grep/sed/gawk, Docker.

Формат: методичка bash.html — 🟡 собрана ассистентом 11.10.2026 из Markdown-исходников (bash/src, генератор tools/build-manual.py); все команды выполнены в Docker при сборке, выводы настоящие; не вычитана человеком, прохождения не было.

Что внутри (10 сессий, 54 шага, ~28 ч): терминал и оболочка → первый скрипт, кавычки, аргументы → ввод, условия, case → циклы, коды завершения, строгий режим, trap → функции, getopts, shellcheck → потоки, конвейеры, xargs → массивы и строки → grep, sed, awk, jq → cron, деплой-скрипт с откатом → итоговое ТЗ (подкоманда digest, без ответа).

---

22. Docker Lab (docker/)

Сложность: базовая по входу, но объёмная. Не требует предыдущих лаб — рассчитана на полных новичков в контейнерах; Bash желателен, но не обязателен. Переписана 13.10.2026 в большой формат (бывшие 3 сессии «Docker + Bash» → 12 сессий).

О чём: контейнеры, образы, Dockerfile, сети, тома, Compose, registry и CI разобраны с нуля и «каждое слово объяснено»: в начале почти каждого шага — аналогия «Если совсем просто» и схема.

Стек: сквозной проект CoffeeShop — nginx + Node.js 24 (Express) + PostgreSQL 18 + Adminer, Docker 29, Compose v5, GitHub Actions.

Формат: методичка docker.html — методичка готова (12 сессий, 77 шагов, ~44 ч); все команды выполнены в Docker при сборке, прохождения человеком не было.

Что внутри (12 сессий): азбука и установка → контейнеры и жизненный цикл → образы и слои → Dockerfile полностью → multi-stage, BuildKit, безопасность → сети → тома, права, бэкап PostgreSQL → Compose, части 1 и 2 (+ Production Hell 1) → registry, GHCR, GitHub Actions → итоговый проект, starter/, Production Hell 2 → итоговое ТЗ без ответа. Docker Swarm не вошёл. Шаги с GHCR и запуском workflow на GitHub выполняются самостоятельно (аккаунт и токен).

---

23. Traefik Lab (traefik/)

Сложность: низкая–средняя (инфраструктурная, не про код). Перед стартом Docker знать не обязательно: шаг 1.4 объясняет минимум. Статус: ✅ переписана 18.10.2026 (11 сессий, 69 шагов, ~43 ч), проверена запуском в Docker, владелец не проходила.

О чём: reverse proxy, который сам находит контейнеры: маршруты по меткам, middlewares, балансировка и выкатка без простоя, TLS (mkcert, ACME), TCP/UDP, наблюдаемость.

Стек: Traefik v3.7 + Docker Compose + Node.js API + nginx + PostgreSQL 18 + Adminer; mkcert, Pebble (тестовый ACME-сервер), k6, Prometheus, Grafana.

Формат: методичка traefik.html, собранная из Markdown-исходников (traefik/src/); схемы и «Ожидаемые результаты» настоящие (прогон в Docker-в-Docker). Два режима: «с нуля» и «продолжение» Docker-лабы; итоговая папка starter/ (шаг 10.5) — то, с чего начнётся Kubernetes-лаба.

Что внутри (11 сессий):

• 1–2 — азбука прокси, HTTP и TLS; стенд CoffeeShop; установка Traefik, traefik.yml, docker.sock, первый маршрут, дашборд
• 3–4 — Docker provider, правила и приоритеты, сети и порты; middlewares (пути, redirect, headers и CORS, compress, basicAuth, chain)
• 5–6 — rateLimit, retry, circuitBreaker, forwardAuth, нагрузка k6; балансировка, healthcheck, canary, mirroring, blue/green
• 7–8 — TLS: mkcert, mTLS, TLS options; ACME на Pebble (HTTP-01, TLS-ALPN-01, DNS-01, wildcard), HTTP/3, переезд на сервер
• 9 — TCP (PostgreSQL) и UDP (DNS), сервис вне Docker, реальный IP клиента, плагин на Go, миграция v2 → v3
• 10–11 — журнал JSON, Prometheus и Grafana, трассировка, итоговый стек, Production Hell; итоговое ТЗ без ответа

Модель для понимания: EntryPoint → Router → Middleware → Service — весь курс выстроен вокруг этой цепочки.

---

24. Caddy Lab — Edge (caddy/)

Сложность: средняя. Проект самостоятельный (свой репозиторий caddy-lab), кода из других лаб не берёт. Решает ту же задачу, что Traefik Lab (reverse proxy, TLS), но другим инструментом — методичка не требует Traefik Lab как предшественника.

О чём: один Caddy перед сайтом, API, WebSocket и PHP — от первого запуска до сборки своих модулей на Go. Проект Edge: статический сайт, reverse proxy к Node.js-бэкендам, автоматический HTTPS без единой настройки, балансировка и отказоустойчивость, безопасность, Caddy в Docker, PHP через FastCGI, логи и метрики, продвинутый Caddyfile, Admin API, расширение через xcaddy, продакшн — служба, кластер, чек-лист. Все примеры конфигов проверены на Caddy v2.11.7.

Стек: Caddy 2 (Caddyfile + JSON-конфиг), Docker Compose, PHP-FPM через FastCGI, xcaddy для сборки модулей на Go.

Формат: методичка caddy.html — методичка вычитана и проверена запуском 05.10.2026 (сессии 1–12 и шаг 13.5; не запускались systemd, кластер, Laravel, публичный домен); прохождение впереди.

Что внутри (13 сессий, ~57 ч): первый запуск и Caddyfile; статический сайт (сжатие, кеш, редиректы, SPA, свои страницы ошибок); reverse proxy (WebSocket и SSE без спецнастроек, заголовки X-Forwarded); автоматический HTTPS (локальный CA, Let's Encrypt, On-Demand TLS); балансировка и отказоустойчивость (политики, health-checks, канарейка); безопасность (basic_auth, forward_auth, лимиты); Caddy в Docker и Compose; PHP и FastCGI; логи, метрики, отладка; продвинутый Caddyfile (матчеры, сниппеты, CEL); Admin API и JSON-конфиг; расширение через xcaddy и свой модуль на Go; продакшн — systemd, сеть, кластер, финальный аудит.

---

25. Kubernetes Lab (kubernetes/)

Сложность: средняя–высокая. Нужны знания из Docker Lab и Traefik Lab — сюда переносится ровно их стек (API + frontend + PostgreSQL + Adminer), входная точка — итоговая папка starter/ (шаг 10.5 Traefik-лабы). Лабу можно проходить и самостоятельно. Предзнания — kubernetes/kubernetes_lab_plan.md.

О чём: Kubernetes и Helm с нуля. Знакомый стек из docker-compose.yml переезжает в кластер kind (Kubernetes IN Docker): настоящий control plane и worker-узлы в контейнерах, тот же kubectl и те же объекты, что и в проде. В конце стек упаковывается в собственный Helm chart.

Стек: Kubernetes v1.37 (kind v0.33) + kubectl + Helm 4 + Traefik v3.7 как Ingress-контроллер (не ingress-nginx: проект свёрнут) + Prometheus/Grafana. Приложение то же: Node.js API + frontend + PostgreSQL 18 + Adminer.

Формат: методичка kubernetes.html — 16 сессий, 108 шагов, ~64 ч, 18 схем; в каждой сессии шаг 🔨 «сломать → починить», сессия 8 и 15 — «Production Hell», сессия 16 — итоговое ТЗ без ответа. Собрана из kubernetes/src/*.md (tools/build-manual.py kubernetes).

Статус: ⬜ переписана 20.10.2026 (16 сессий, 108 шагов, ~64 ч, 18 схем); блоки в Docker не прогонялись (в «Ожидаемом результате» стоит пометка «вывод не получен»), построчно не вычитана, прохождения не было. Вход — starter/ из шага 10.5 Traefik-лабы.

Что внутри (16 сессий):

• Сессия 1 · Азбука и окружение — зачем оркестратор, kind-кластер из трёх узлов, kubectl и helm, проверка starter/
• Сессия 2 · Архитектура и объекты — путь apply по компонентам, reconcile, метки и селекторы, API-группы
• Сессия 3 · Pod и Service — Pod, фазы, logs/exec, Service и DNS, образ в kind
• Сессия 4 · Deployment и обновления — ReplicaSet, масштабирование, rolling update, rollout/undo, Recreate
• Сессия 5 · Сети и Ingress — типы Service, DNS кластера, Traefik как Ingress-контроллер, Ingress и IngressRoute, порты kind
• Сессия 6 · Хранение данных — PV/PVC/StorageClass, PostgreSQL 18, StatefulSet, pg_dump и CronJob
• Сессия 7 · Секреты и конфигурация — ConfigMap, Secret, base64 ≠ шифрование, весь стек CoffeeShop вместе
• Сессия 8 · Эксплуатация и диагностика — namespace и квоты, пробы, requests/limits, Job, k9s, таблица диагностики, Production Hell 1
• Сессия 9 · Безопасность и сеть-политики — RBAC, ServiceAccount, securityContext, Pod Security Standards, NetworkPolicy, цепочка поставки
• Сессия 10 · Автомасштабирование — metrics-server, HPA под нагрузкой, VPA и Cluster Autoscaler (обзор)
• Сессия 11 · Наблюдаемость — kubectl top, kube-prometheus-stack, ServiceMonitor, Grafana, логи
• Сессия 12 · Helm, основы — chart, release, свой chart для API, install/upgrade, отладка YAML
• Сессия 13 · Шаблоны Helm — Go template, функции, if/with/range, _helpers, chart для БД, subcharts
• Сессия 14 · Репозитории, релизы, окружения — helm package и репозиторий, atomic/rollback, lint/diff/test, values-dev/prod, секреты
• Сессия 15 · Итоговый проект — umbrella chart CoffeeShop, values-prod, Kustomize, Production Hell 2
• Сессия 16 · Итоговое задание — продакшн-релиз по ТЗ без решения

Справка: шпаргалка kubectl/манифестов/Helm, справочник ошибок «симптом → причина → что делать», глоссарий, 70 вопросов для собеседования, «что дальше».

26. Prisma Lab (prisma/)

Сложность: средняя–высокая. Нужны знания PostgreSQL-лабы (индексы, EXPLAIN, транзакции, блокировки, RLS); TypeScript — по ходу, сессия 2 даёт минимум. Версия — Prisma 7 (на npm latest уже Prisma 8 RC, версии закрепляются).

О чём: читателю достаётся чужая рабочая база прокатной сети — без внешних ключей, с дублями клиентов, датами в трёх форматах и деньгами текстом. За 18 сессий её нужно превратить в типизированный слой данных на Prisma + TypeScript, не останавливая «прод»; внутри — линии «деньги» (ledger, идемпотентность, Decimal) и «мультитенантность» (филиалы, RLS, client extensions).

Стек: Prisma 7 + TypeScript + PostgreSQL 18 + Node.js 24 + Docker + Vitest. Вход — один стартовый дамп базы (starter/).

Формат: методичка prisma.html — 18 сессий и 19-я итоговая без ответа, ~76 ч. Собрана из prisma/src/*.md (tools/build-manual.py prisma).

Статус: ✅ написана 20.10.2026 (19 сессий, 126 шагов, ~76 ч); 22.10.2026 прогнана целиком в Docker (PostgreSQL 18.6, Node 24, Prisma 7.10.1, TypeScript 6.0, Vitest 5): все блоки выполнены по порядку с чистой базы из дампа, 119 блоков «Ожидаемого результата» — настоящий вывод; 24.10.2026 вычитана построчно, все места «сверьтесь» проверены запуском на отдельной базе, проверены PgBouncer 1.26.1 и сборка образа из шага 18.4 (найдена и исправлена ошибка: без rewriteRelativeImportExtensions контейнер не стартовал). Не запускался workflow на самом GitHub (внешний ресурс) и Prisma 8 (только справка). Подробности — fixes/backend/prisma.md; план — prisma/prisma_lab_plan.md.

---

В работе: Go Start, Go Pro, Ansible

Эти лабы заведены как заглушки (карточка «Методичка скоро» на главной, клик открывает README репозитория) либо существуют только как план. Реестры сайта (works/js/lab.js, карта маршрутов, счётчики «N лаб», страницы works/<ключ>.html) для них не заводились — это сделает полный чек-лист, когда появятся проверенные методички (fixes/common/_checklist-new-lab.md). В порядке прохождения они видны на вкладке «Порядок и содержание» страницы «Все работы и прогресс» в блоке «в плане».

• Go Start (go-start/, репозиторий go-start-lab) — Go с нуля до middle на сквозном проекте CoffeeGo: типы и срезы, ошибки как значения, интерфейсы, дженерики, горутины, net/http, database/sql и pgx, тесты, Docker. 12 сессий. Методичка go-start.html написана в другом чате; вычитка и прогон в Docker 07.10 сделаны другой моделью и владельцем не приняты. Кода прохождения нет.
• Go Pro (go-pro/, go-pro-lab) — продолжение: CoffeeGo Platform на трёх сервисах, рантайм и GC, профилирование, gRPC, Outbox, OpenTelemetry, Kubernetes, свой анализатор кода. 13 сессий. Идёт строго после Go Start; до неё желательно Docker, PostgreSQL, Redis, RabbitMQ и Kubernetes. Методичка есть, не вычитана и не проверена запуском.
• Ansible (ansible/, ansible-lab, создана 11.10.2026) — управление серверами как кодом: inventory и ad-hoc, playbook и идемпотентность, переменные и факты, handlers, Jinja2, роли и Galaxy, Vault, Docker через Ansible, кластер и обновление без простоя. 10 сессий, ~40 ч по плану ansible_lab_plan.md. Идёт последней в очереди больших DevOps-лаб (Bash → Docker → Traefik → Kubernetes → Ansible, fixes/common/_standard-lab.md). Методички и кода нет.

---

Возможности сайта

• Справка при наведении. На главной при наведении мыши на карточку лабы открывается панель: место в учебном порядке, уровень входа, что нужно знать до старта, цепочка «Сначала пройти» (обязательно / нужны знания / полезно, с причиной), с чем встретишься, «Что можно проходить дальше», подсказка, а также сноска «что требуется» и статус проверки (они перенесены с карточки; на телефоне остаются на ней). Данные — works/js/prereq.js, для заглушек зависимости зашиты в index.html (предварительные). Только для компьютера с мышью.
• Слайд-переход. При открытии лабы с главной экран «уезжает» в сторону, а страница лабы въезжает; обратно — зеркально. У каждой лабы своё направление (влево/вправо/вверх/вниз, works/js/slide.js). Нужны межстраничные View Transitions (Chrome/Edge 126+, Safari 18.2+); в других браузерах остаётся прежняя заставка PageLoader.

---

Все работы и прогресс (works/progress.html)

Страница с двумя вкладками. «Прогресс» — ссылки на все лабы и общий прогресс по каждой: отметки разделов и шагов из методичек (хранятся в localStorage браузера) складываются в проценты. Кнопка «Все работы» есть в каждой методичке рядом с поиском и переключателем темы, а пункт «прогресс» — в шапке сайта, на страницах лаб и в хронологии. Рядом — страница «Что чем проверено» (python3 tools/build-verification.py, собирается из fixes/common/_verification.md). «Порядок и содержание» (progress.html#order) — путь из 26 лаб в рекомендуемом порядке с накопленными часами, зависимостями («нужна / нужно знать / полезна»), сессиями и справочными разделами каждой методички, а ещё Go Start, Go Pro и Ansible в блоке «в плане»; порядок и зависимости берутся из works/js/prereq.js, сессии и часы — из самих методичек. Страница собирается скриптом python3 tools/build-progress.py (запускать заново при добавлении лабы), а ссылка и правка шаблона вставляются в методички через python3 tools/patch-manuals.py. Прогресс виден, только когда страница и методички открыты с одного адреса (GitHub Pages или python3 -m http.server).

---

Витрина работ (works/)

Отдельный сабмодуль works-lab со стилизованными обзорными страницами каждой лабы (дизайн в стилистике аниме-заставки, тот же, что и у index.html): что внутри, стек, куда открыть методичку и репозиторий. Там же лежат превью-картинки лаб (works/images/), которые использует и главная страница.

Открыть можно прямо по ссылке works/<ключ-лабы>.html, например works/rabbitmq.html. В <head> каждой такой страницы подключён js/slide.js (слайд-переход).

---

Клонирование

Репозиторий использует submodule, поэтому клонировать нужно с флагом --recurse-submodules:

git clone --recurse-submodules https://github.com/meeymirita/anitech-performance.git

Если репозиторий уже склонирован без этого флага:

git submodule update --init --recursive

Добавление новой работы

git submodule add <url-репозитория-лабы> <папка>
git commit -m "Add <название> lab"

Обновление сабмодуля до последнего коммита

cd <папка-лабы>
git pull origin main
cd ..
git add <папка-лабы>
git commit -m "Update <папка-лабы> submodule"

Автор

Все лабы веду и прохожу самостоятельно, попутно ведя заметки и методички по каждой теме.

Лицензия и авторство

Код — MIT, тексты — CC BY 4.0, обложки и иллюстрации не покрыты (см. LICENSE). Кто что сделал: NOTICE.