Lexery Wiki

Lexery - Yehor Puhach

5 хв читання

Compiled from

  • raw/github-prs/pr-1.md
  • raw/github-prs/pr-2.md
  • raw/github-prs/pr-3.md
  • raw/github-prs/pr-5.md
  • raw/github-prs/pr-6.md
  • raw/github-prs/pr-8.md
  • raw/github-prs/pr-9.md

Yehor Puhach

Профіль учасника команди Lexery: бекенд-інженер і спеціаліст з інфраструктури, який системно будує основу API, auth і storage, на яку спираються портал і agent pipeline. Матеріал зібраний з публічних PR на lexeryAI/Lexery, згадок у Telegram та контексту роботи в Linear — без психологічних ярликів, придатний для показу самому Єгору.

Роль

  • Функція: backend engineer, infrastructure specialist — межі сервісів, HTTP surface (API & Control Plane), Prisma, інтеграції сховища, auth stack, спільні контракти з agent.
  • GitHub: puhachyeser.
  • Telegram: @puhachyeser (згадується Андрієм у групі Lexery.ai General); учасник групи Lexery.ai.
  • Linear: admin access; завдання переважно на backend-треку.

Стиль комунікації та документування роботи

  • Структуровані PR title: префікси на кшталт [Backend], [Frontend], [Backend / Agent] — одразу видно шар і тип зміни.
  • Пояснює «навіщо», не лише «що»: наприклад, у PR про doclist скрипти — раціонал: перейменувати з dev, щоб не ловити помилки при pnpm dev з кореня monorepo.
  • Трасованість до Linear: у body PR лінкуються issues (наприклад, shared contracts → LEX-198; storage / presigned URLs → LEX-201).
  • Каденція: дуже висока — на спостережуваному відрізку найбільший обсяг PR у команді; інколи кілька PR за один день.

Технічний домен (що саме будує)

ОбластьЩо це дає продукту
NestJSМодулі, service boundaries, HTTP API для порталу та control plane.
PrismaСхема даних і доступ до БД узгоджено з run/workspace state.
AuthenticationЦикл змін: user schema + auth service (#3), refactor auth (#8), ongoing registration infra (#9).
MonorepoМіграція frontend у Turborepo workspace + конфіг під monorepo infra (#1).
Shared contractsZod / типи між backend і agent (#5) — єдина «мова» payload’ів.
File upload / storageController/service, presigned URLs, інтеграція з R2 (або еквівалент) — LEX-201.
DocList / toolingПерейменування script names, щоб не конфліктувати з root pnpm dev (#6).

Детальніше про архітектуру: Lexery - API and Control Plane, Lexery - Contracts and Run Schema, Lexery - Deployment and Infra, Lexery - Retrieval, LLDBI, DocList.

Робочі патерни (виведені з GitHub)

  • Foundational-first: спочатку monorepo (#1), потім storage (#2) і auth foundation (#3), далі shared contracts (#5) і дрібні infra chores (#6, #8).
  • Self-merge, без formal PR reviews на спостережуваних PR — висока довіра й швидкий merge; для агента це означає: контекст краще читати з diff і Linear, ніж очікувати discussion thread у GitHub.
  • Малі, часті PR у гілку dev — зручно трекати через Lexery - PR Chronology та Lexery - GitHub History.

Історія PR (puhachyeser, lexeryAI/Lexery)

Заголовки та дати — як у GitHub на момент оновлення нотатки.

#TitleДата (merge або стан)Статус
1chore: migrate frontend and configurate it to use monorepo infra2026-03-29merged
2[Backend] feat: add storage controller/service with uploading functionality2026-03-31merged
3[Backend] feat: tweak user schema and auth service to match new auth data2026-04-02merged
5[Backend / Agent] feat: add shared contracts(zod/types) for backend and agent2026-04-04merged
6[Agent] chore: change doclist script names to prevent errors2026-04-04merged
8[Frontend] chore: refactor auth2026-04-06merged
9[Frontend] feat: add infra for email/sms/oauth registration— (відкрито з 2026-04-07)open

Посилання на Linear з body PR (для трасування):

Взаємодія з Андрієм (Andriy)

  • Розподіл фокусу: Andriy — Brain / agent architecture та pipeline; Yehor — backend і infra, з якими agent і портал з’єднуються по мережі та контрактам.
  • Формальних cross-reviews немає — домени комплементарні: «нудна», але критична інфраструктура (auth, storage, contracts) з боку Yehor дозволяє Andriy зосередитись на orchestration і retrieval.
  • Практичний наслідок для змін у apps/brain: узгоджувати breaking changes у shared Zod/types з тим, що вже змерджено в backend; див. #5 і Lexery - Contracts and Run Schema.

Взаємодія з Сашею (Sasha)

  • Спільний auth: Yehor — backend auth і refactor (#3, #8, ongoing #9); Саша (frontend) — auth pages (наприклад, PR #7 у репо — автор alexbach093).
  • Shared contracts (#5) задають API surface, який споживає frontend — робота узгоджена через типи та issues, а не через довгі review threads у GitHub.
  • Незалежні PR з координацією по сенсу задачі (auth flow, registration) — типова модель для цієї пари.

Що варто знати агенту, який з ним «працює» через репозиторій

  1. Джерело правди: merged PR + Linear issue, не коментарі в PR (їх може не бути).
  2. Префікси в title швидко підкажуть, чи чіпати backend, frontend чи agent tooling.
  3. Інфраструктурні зміни (auth, upload, env, contracts) майже завжди проходять через його шар — перед великими рефакторами варто перевірити відкриті PR (наразі #9).
  4. Термінологія в GitHub: деякі PR марковані [Frontend], але стосуються auth/registration infra — читати опис і diff, не лише префікс.

Як це видно в продукті

See also

See Also

Вигляд графа

Зворотні посилання