# Игорь Бартенев


Архитектор ПО / Технический лидер · Польша

2026-09-27 · [bartenev.site](https://bartenev.site/ru/)

Python · FastAPI · PostgreSQL · Elasticsearch · Redis

Архитектор ПО и технический лидер с практической разработкой в commerce, автоматизации бизнеса и инфраструктуре AI-агентов. Превращаю требования в модели данных, модульные backend-сервисы и интеграции и довожу решения до реализации. Опыт производства и ERP помогает связывать программные решения с реальной работой людей.

## Ключевой опыт


### Onlihub · Начало в феврале 2022


Lead Developer · архитектура и техническая ответственность

Присоединился к существующей платформе вторым разработчиком; после ухода лида взял техническую ответственность. Перестроил архитектуру приложения и БД, координировал небольшую межфункциональную команду и работал с CEO над реализуемостью и запуском.

Реализовывал backend-сервисы для каталогов поставщиков, листингов, остатков, заказов и исполнения. Моделировал внешние идентификаторы и правила синхронизации для систем с разными данными и циклами обновления.

### Artekom · Январь 2020 - февраль 2022


1C-разработчик → Python-продукты и автоматизация

Связывал учёт, сайты и API в 1C; в 2021 перешёл к Python-продуктам. Создавал процессы Telegram → ERP и настольный торговый терминал с backtesting стратегий и исполнением операций на бирже.

### Technopark Pozh Tekhnika · 2013 - январь 2020


Инженерия производства → ERP-автоматизация

Проектировал детали, оснастку и процессы ЧПУ для серийного производства. С февраля 2019 внедрял и развивал 1C для материалов, производственных планов, отчётности и зарплаты.

## Примеры инженерной работы


### Настраиваемые бизнес-процессы


Спроектировал и создал платформу для работы ипотечной компании вместе с Encompass. Настраиваемые анкеты, OCR документов, задачи и правила начислений связали клиентские заявки с внутренними операциями. Клиенты отвечали один раз и видели нужные документы; сотрудники получали назначенные задачи с меньшей ручной координацией.

[BOS](https://bartenev.site/ru/work/bos/)

### Масштабный сбор данных


Спроектировал параллельное сканирование, координацию прокси и аккаунтов, нормализацию и пакетную обработку Elasticsearch. Архивный проект данных маркетплейса обрабатывал миллионы листингов около пяти месяцев (исторический масштаб по моему опыту).

[Amazon Data / Trends](https://bartenev.site/ru/work/amazon-data/)

### Управляемый доступ AI-агентов к инструментам


Создал MCP Hub: поиск инструментов, схемы по запросу, сохранённые результаты и выполнение с проверкой прав; использую ежедневно. Отдельная open-source интеграция Unity сократила 48 видимых модели инструментов до 6 с сохранением 377 операций. Сравнение схем опубликовано.

[MCP Hub](https://bartenev.site/ru/work/mcp-hub/) · [Unity MCP Efficient](https://bartenev.site/ru/work/unity-mcp-efficient/)

## Технические инструменты


- Backend и данные: Python, FastAPI, SQL, PostgreSQL, Elasticsearch, Redis; каталог на Rust; сложные запросы, ограничения, триггеры и TTL-кеш.

- Архитектура: Доменные модели; модульные сервисы; порты и адаптеры; документы, формулы, права; идемпотентность и восстановление.

- Интеграции и выполнение: REST, webhooks, OAuth, WebSocket; workers, очереди, пакетные процессы; Docker, Linux и диагностика production.

- AI-инфраструктура: MCP, поиск инструментов и оркестрация; локальные embeddings и гибридный поиск; бюджеты контекста, согласования и история выполнения.

## Образование


Национальный технический университет «Харьковский политехнический институт»
Диплом специалиста · Сентябрь 2008 — февраль 2014
Автоматизация и компьютерно-интегрированные технологии

## Междисциплинарный опыт


TON Tanks: продукт, backend и запуск игры Telegram / TON. Другие работы: модульная техника Unity, 3D-ассеты и эксперименты с локальным AI для речи и документов.

## Компетенции


### Коммерция и интеграции


Каталоги, маркетплейсы, склады, заказы и исполнение: общая модель и границы между системами.

Архитектура и реализация многоканальных платформ

Спроектировал общие модели товаров, остатков и заказов для Onlihub и MySellerHub, связав каналы с разными моделями складов и внешними идентификаторами.

Amazon, Amazon SP-API, Amazon MCF, Shopify, eBay, Walmart, TikTok Shop, Etsy, Zenventory, Ysell, Onedaybundle, Warehouse integrations, Supplier integrations, Multichannel commerce, Canonical data models, Supplier catalogs, Products, SKU mapping, Variants, Listings, Categories, Attributes, Properties and values, Pricing policies, Shipping policies, Warehouses, Virtual warehouses, Inventory synchronization, Reservations, Overselling prevention, Customer orders, Supplier orders, Order routing, Fulfilment, Shipments, Tracking, Payment synchronization, External identifiers, Bidirectional synchronization, Webhooks, Scheduled synchronization, Polling, Callbacks, Retries, Rate limits, Partial failure recovery, Idempotency, Eventual consistency, State reconciliation, Barcode identification, ASIN identification, Product enrichment, Geodata, Route calculation, Estimated delivery time

[Коммерция и интеграции](https://bartenev.site/ru/expertise/#domain-commerce-integrations)

### Бизнес-системы


Для ипотечной компании я связал клиентские анкеты с документами, OCR, задачами сотрудников, начислениями и Encompass. Настраиваемые формы и бизнес-правила позволяют общему ядру поддерживать разные рабочие сценарии.

Моделирование бизнеса, архитектура и собственная разработка

Ответы клиента определяют следующие вопросы и нужные документы. OCR переносит значения из файлов в поля; события документов назначают участников и задачи. Сотрудники пользуются собственными Kanban-досками, а записи и выбранные статусы передаются в Encompass. Расчёты и начисления сохраняют связи с источниками.

Business process modelling, Domain modelling, ERP, 1C, 1C УТП, 1C УНФ, Business accounting, Production planning, Material norms, Material consumption, Procurement, Stock accounting, Stock movements, Cost accounting, Payroll, Expenses, Transport logistics, Reporting, Inter-system exchanges, BOS, CRM, BPM, Organizations, Departments, Users and memberships, Roles and permissions, Workflow, Pipelines, Stages, Processes, Tasks, Operation sequences, Dynamic documents, Conditional forms, Document OCR, Encompass, Kanban, Task assignment, Document types, Multi-step forms, Dynamic fields, Nested fields, Repeatable fields, Calculated fields, Document relationships, Templates, Formula engines, Calculators, Printable forms, File management, Email integration, Email templates, External mailboxes, Notifications, Event-driven automation, Audit history, Salaries, Hourly compensation, Piece-rate compensation, Stripe, Wise, Subscriptions, One-time payments, Checkout, Shopping carts, Payment statuses, Payment webhooks, Transaction ledgers, Transaction categories, Transaction types, Recalculations, Statements, PDF statements, Financial movements, Financial invariants, Document-driven accounting, Transactions, Constraints, Triggers

[Бизнес-системы](https://bartenev.site/ru/expertise/#domain-business-systems)

### Бэкенд, данные и парсинг


Массовый парсинг с параллельной обработкой и пулами прокси; пакетное чтение и запись в Elasticsearch; отдельные пути БД, кеша, чтения и воркеров.

Архитектура, реализация и оптимизация производительности

Amazon data: параллельный сбор и пакетные операции Elasticsearch. Catalog: чтение на Rust, резервный Python и кеш Redis. Onlihub: бизнес-модули с явными прикладными контрактами, портами репозиториев и инфраструктурными адаптерами.

Python, SQL, Rust, C++, FastAPI, Pydantic, asyncio, Multiprocessing, Multithreading, Background processing, Workers, Queues, Batch processing, Schedulers, Service architecture, REST, GraphQL, WebSocket, OAuth, External APIs, Internal APIs, Service-to-service communication, Event processing, Callbacks, Polling, Modular architecture, Module boundaries, Ports and adapters, Dependency inversion, Composition root, PostgreSQL, Elasticsearch, Redis, SQLite, Transactional storage, Search models, Read models, Cache layers, Complex SQL, CTE, Dynamic queries, Aggregations, Full-text search, Execution plans, Indexing, Bulk operations, Bulk indexing, Bulk reading, Transactions, Triggers, Constraints, Data migrations, Large relational schemas, Selenium, BeautifulSoup, Scrapy, Requests, Proxy pools, Proxy rotation, Multi-account parsing, Anti-blocking strategies, Parallel scraping, Data normalization, Deduplication, Data enrichment, Task distribution, Error monitoring, Retry strategies, Request throttling, XLS / XLSX / CSV ingestion, Import monitoring, Processing statuses, Docker, Linux, Git, CI/CD, GitHub Actions, Reverse proxies, Load balancing, Rate limiting, SSH, VPN, Proxy infrastructure, Logging, Monitoring, Bottleneck analysis, Pandas, NumPy, Numba, Matplotlib, PyQt5, PowerBI, yfinance, QThread, Thread, Market data, Charting, SMA, EMA, MACD, TMA, RSI, Backtesting, User-defined trading strategies, Live exchange execution, Commissions, P&L, Results persistence

[Бэкенд, данные и парсинг](https://bartenev.site/ru/expertise/#domain-backend-data)

### Инфраструктура ИИ


MCP Hub объединяет поиск инструментов, локальные embeddings и повторное использование методов с управляемой работой с базами данных, логами, задачами и коммуникациями.

Архитектура и собственная разработка инфраструктуры агентов

Реализовал гибридный поиск знаний, опциональное локальное переранжирование методов и обратную связь по опыту. Схемы по запросу, сохранённые результаты, общие бюджеты runner и запуски автоматизаций в БД помогают управлять исполнением и контекстом.

LLM APIs, Local LLMs, Lightweight models, CPU-first inference, MCP, FastMCP, Tool calling, Tool discovery, Tool RAG, Schemas on demand, Progressive disclosure, Agent orchestration, Specialized agents, Subagents, Agent workflows, Context management, Context compression, Context budgets, Execution memory, Memory, Embeddings, Vector search, Semantic retrieval, RAG-like retrieval, Hybrid retrieval, FTS5, SentenceTransformers, CrossEncoder, Reranking, Reusable methods, Learning feedback, Result handles, Shared budgets, Operation claims, Persistent task runs, Lease recovery, Cron, Event triggers, Human approval, Permission boundaries, Project isolation, Audit, Batch execution, Bounded results, Stored results, Execution receipts, Idempotency, Retry semantics, Duplicate mutation protection, Asynchronous operations, State inspection, Unity domain reload, RU/EN tool search, Schema context measurement, Slack integration, Teamwork integration, Telegram integration, Database tools, Log inspection, OCR, Document recognition, Speech recognition, Transcription, TTS, Whisper, Sherpa-ONNX, Silero, ONNX, GGUF, Speech pipelines, Multilingual processing, Meeting action extraction, AI data enrichment, Product categorization

[Инфраструктура ИИ](https://bartenev.site/ru/expertise/#domain-ai-infrastructure)

### Техническое лидерство


Начать с цели бизнеса, найти решение и реализовать его в коде. Моя работа объединяет архитектуру, обсуждение вариантов с заказчиками, собственную разработку и координацию там, где этого требует проект.

Ответственность за решение, архитектуру и реализацию

Для BOS я предложил и разработал решение, обосновал его архитектуру перед бизнесом и дорабатывал под реальные процессы. В Onlihub принял архитектуру, БД, backend и интеграции после ухода lead-разработчика, координировал разработку и консультировал CEO по реализуемости.

Technical ownership, Hands-on architecture, Architecture decisions, Business discovery, Customer collaboration, Process formalization, Domain modelling, Database design, Backend development, Integration design, Engineering trade-offs, Technical communication, Cross-functional coordination, Task allocation, Delivery, Product development, Product concepts, Product launch, Product promotion, Production debugging, Bottleneck analysis, System evolution

[Техническое лидерство](https://bartenev.site/ru/expertise/#domain-technical-leadership)

### Промышленная инженерия


Производство, CAD/CAM и ЧПУ дали основу: понять материалы, операции и ограничения до автоматизации.

Промышленная инженерия и автоматизация производства

Готовил детали, программы оборудования и документацию для серийного производства; оптимизировал операции и материалы, затем автоматизировал планирование производства и учёт в 1С.

Manufacturing process modelling, Part design, Assembly design, CAD, CAM, CAD/CAM, CATIA, SolidWorks, AutoCAD, CNC, FeatureCAM, CNC Cad, Sheet metal, Nesting, Cutting, Turning, Milling, Coordinate punching, Turn-mill machines, Machine programs, Postprocessors, Tooling, Materials, Material consumption, Operation sequencing, Technical documentation, Production launch, Serial production, Process bottlenecks

[Промышленная инженерия](https://bartenev.site/ru/expertise/#domain-engineering-foundations)

### Игры и 3D


Самостоятельные продукты: игровой бэкенд, TON, физика Unity, модульная техника, процедурные миры и 3D-ассеты.

Самостоятельные продукты и разработка игровых систем

Руководил разработкой TON Tanks, создавал бэкенд и игровую логику. Собственный проект на Unity исследует модульные танки, физику гусениц, повреждения и процедурные города.

Unity, C#, Game backends, Game logic, Game balance, Progression, Rewards, Telegram integration, TON, Blockchain transactions, NFTs, NFT economy, Minting, Ownership, Trading, Marketplace mechanics, Modular vehicle architecture, Vehicle assembly, Independent modules, Damage systems, Physics, Tracked vehicle mechanics, Shooting, Multiplayer experiments, PvP, PvE, Capture zones, Football mode, Procedural environments, Procedural city generation, Vegetation, Game optimization, Blender, 3D modelling, Hard-surface modelling, Materials, Textures, Game-ready assets, Asset optimization, Engine audio banks, Physical engine simulation, Audio generation

[Игры и 3D](https://bartenev.site/ru/expertise/#domain-games-3d)

## Проекты


### Onlihub


Техническая ответственность за commerce-платформу

Lead Developer · архитектура, реализация и развитие

Я взял на себя техническую ответственность за развитие платформы, объединяющей поставщиков, товары, маркетплейсы и исполнение заказов.

[Onlihub](https://bartenev.site/ru/work/onlihub/)

**Подключение магазина — больше, чем API-вызов**

Иллюстративный разбор реализации

Продавец подключает канал продаж. Провайдер может отвечать медленно, а запрос — прийти повторно. Приложение должно знать, что запрошено, кто это обрабатывает и завершилась ли операция.

1. Проверить владельца магазина и возможности интеграции.

2. Сохранить запрос подключения с ключом идемпотентности и записью outbox.

3. Передать задачу воркеру, продлевать срок владения и фиксировать завершение или ошибку.

**Что это даёт**
Запрос подключения имеет сохранённый жизненный цикл и не зависит от одного долгого HTTP-запроса. Повторы и исчерпанные попытки обрабатываются явно.

**Решение и компромисс**
Текущая реализация хранит намерение операции и владение задачей в PostgreSQL, ограничивает параллельность и проверяет lease. Это даёт восстановление, но добавляет управление состоянием и фоновую обработку. Доставка — at least once: внешнее действие требует идемпотентности или сверки; локальный токен не гарантирует однократное исполнение в другом сервисе.

**Задача**
Торговые операции требовали согласованности между разными моделями товаров, складами и внешними системами.

**Как я это реализовал**
После ухода lead-разработчика я возглавил разработку и перестроил архитектуру приложения и базы данных. Реализовал асинхронный backend на FastAPI, сложные запросы PostgreSQL и интеграции торговых и складских систем, одновременно координируя команду и консультируя CEO о реализуемости идей.

**Результат**
Работа охватила жизненный цикл товара от каталога и остатков до заказов, исполнения и отслеживания, с ответственностью за систему целиком.

**От разработчика к техническому руководству**
Я пришёл в стартап рядом с опытным lead. После его ухода взял ответственность за архитектуру, базу данных и backend, координировал небольшую межфункциональную команду и вёл продукт через реализацию, поддержку и дальнейшее развитие. Обсуждения с CEO связывали бизнес-идеи с технической реализуемостью и решениями о разработке.

**Общая модель разных каналов**
Изначальная платформа проектировалась под более широкий multichannel-сценарий: товар из одного источника можно опубликовать в другом канале. Я работал с Amazon, Walmart, eBay, TikTok Shop, Shopify и складскими интеграциями, согласовывая товары, внешние идентификаторы, реальные и виртуальные склады, остатки, заказы и tracking. Этот первоначальный замысел впоследствии стал основой появления MySellerHub.

**Асинхронные сервисы и сложный SQL**
Я создавал и документировал API на FastAPI с асинхронной обработкой, потоками и управлением очередями. Работа с PostgreSQL охватывала динамические запросы и оптимизацию больших наборов данных. Инструменты повторяющихся задач, парсеры и анализ в PowerBI дополняли backend и поддерживали интеграционные и операционные процессы.

**Архитектура, которая менялась вместе с продуктом**
Платформа развивалась в связанные продукты с разными задачами: операции поставщиков, работу ритейлеров и отдельный высоконагруженный каталог. Я занимался и архитектурой, и реализацией, включая подписки и разовые платежи. Позднее Onlihub появился среди интеграций Amazon MCF; это отдельная веха продукта наряду с моей инженерной ответственностью.

**Моя ответственность**
Я присоединился к существующей платформе в феврале 2022 вторым разработчиком. После ухода лида взял ответственность за архитектуру приложения, БД и backend, координировал небольшую межфункциональную команду и работал с CEO над реализуемостью и запуском.

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

- API и фоновая обработка поддерживают интеграции маркетплейсов и складов с согласованием внешних идентификаторов и состояний.

**Публичные данные о продукте**

Опубликованные Onlihub числа описывают заявленный масштаб платформы отдельно от моего вклада и периода работы. Amazon указывает Onlihub среди интеграций MCF.

- 10,000+: магазинов в сети платформы

- 40,000+: исполненных заказов MCF

[Onlihub · показатели продукта](https://onlihub.com/)

[Amazon · страница интеграции](https://supplychain.amazon.com/integrations/onlihub)

Источники проверены: 2026-09-27

**Инструменты и технологии**
Technical ownership, Hands-on architecture, Architecture decisions, Domain modelling, Database architecture, Database design, Backend architecture, Backend development, API integrations, Integration design, Inventory, Fulfillment, Reconciliation, Team coordination, Cross-functional coordination, Technical communication, Engineering trade-offs, Delivery, Product development, System evolution, Suppliers, Products, SKU, Variants, Attributes, Listings, Marketplaces, Warehouses, Reservations, Customer orders, Shipments, Tracking, FastAPI, Python, PostgreSQL, Complex SQL, Dynamic queries, Query optimization, asyncio, Multiprocessing, Multithreading, Queues, Recurring tasks, PowerBI, Selenium, BeautifulSoup, Requests, Scrapy, Multi-account parsing, Proxy pools, Amazon, Walmart, eBay, Etsy, TikTok Shop, Shopify, Zenventory, Ysell, Onedaybundle, API documentation, Virtual warehouses, Background workers, SKIP LOCKED, Outbox, Leases, Retries, Bounded concurrency, WebSocket, Redis Pub/Sub, Realtime delivery, Backpressure, Session authentication, Pillow, Image processing, Concurrency limits, WebP, HTTP caching, CDN, Modular architecture, Domain modules, Module boundaries, Application architecture, Ports and adapters, Repository ports, Dependency inversion, Dependency injection, Composition root, Contracts, Read models, Idempotency

- [Onlihub · торговая платформа](https://onlihub.com/) — Публичный сайт продукта: запасы FBA, сеть продавцов и исполнение заказов через Amazon MCF.

Продукт · Публичная страница · Ссылки проверены: 2026-09-27

- [Onlihub на сайте Amazon MCF](https://supplychain.amazon.com/integrations/onlihub) — Страница интеграции на сайте Amazon описывает передачу заказов Onlihub в Multi-Channel Fulfillment.

Внешний источник · Публичная страница · Ссылки проверены: 2026-09-27

Подтверждает наличие интеграции в каталоге, а не сертификацию продукта или его разработчика.

- [Справочный центр Onlihub](https://support.onlihub.com/) — Публичные инструкции, на которые ссылается сайт Onlihub.

Документация · Публичная страница · Ссылки проверены: 2026-09-27

### BOS / Business Operations System


От анкеты клиента до ипотечных операций

Проектирование решения, архитектура и собственная разработка

Я спроектировал и создал платформу операций для работы действующей ипотечной компании. Клиентские формы с условными переходами, OCR документов, задачи сотрудников и правила начислений соединились с процессами в Encompass.

[BOS / Business Operations System](https://bartenev.site/ru/work/bos/)

**Одна анкета запускает рабочий процесс**

Работа в ипотечной компании · по данным автора

Действующая ипотечная компания обрабатывала заявки в Encompass, а значительную часть сбора данных и координации выполняла вручную. Я создал BOS, чтобы связать новый клиентский сайт с людьми, документами и действиями, необходимыми для каждой заявки.

1. Ответить один раз. Занятость, доход и предыдущие ответы определяют следующие вопросы и нужные документы. Сотрудники и риелторы могут сами настраивать такие формы.

2. Загрузить нужные файлы. Автоматизация создаёт связанные записи документов и задачи; OCR переносит значения в поля, чтобы сотрудники работали со структурированной информацией.

3. Продвигать заявку дальше. Участники работают со своими списками задач и Kanban-досками; документы, внешние ID и выбранные статусы передаются между BOS и Encompass.

**Что это даёт**
Клиенты получили понятный путь от ответов до нужных документов. Сотрудники получали назначенные задачи, сокращая ручную координацию передачи работы. Компания сохранила Encompass и получила связанный с ним приём заявок и операционный процесс.

**Решение и компромисс**
Я сделал формы, схемы документов и бизнес-правила настраиваемыми, чтобы изменение процесса не требовало каждый раз отдельной логики заявки в коде. Ипотечная конфигурация работает на переиспользуемом ядре. Гибкость требует явных условий, правил доступа и переходов состояния. Расчёты, действия по событиям документов и учёт начислений остаются отдельными модулями с определёнными входами и результатами.

**Задача**
Компания работала в Encompass без сайта для заполнения клиентских анкет. Сотрудники вручную собирали информацию, определяли нужные заёмщику документы и координировали дальнейшие действия. Занятость, доход и другие обстоятельства меняли требования и усложняли обработку каждой новой заявки.

**Как я это реализовал**
Я предложил решение, обосновывал архитектурные решения перед бизнесом и разрабатывал систему под реальные рабочие сценарии. Настраиваемые формы определяют поля, шаги и нужные документы по ответам заявителя. События документов создают задачи и назначают участников; OCR заполняет поля из загруженных файлов. Отдельные модули отвечают за расчёты, доступ, начисления и обмены с Encompass. Ядро документов и правил проектировалось для повторного использования за пределами ипотеки.

**Результат**
Компания получила сайт для клиентских анкет, связанный с внутренними операциями. Клиенты могли ответить один раз и увидеть нужные документы; сотрудники получали назначенные задачи и работали со связанными записями, которые передавались в Encompass. Это упростило обработку заявок и сократило ручную координацию.

**Формы, которые учитывают ситуацию заявителя**
Сотрудники и риелторы могут настраивать формы для клиентов. Ответы определяют видимые и доступные поля, следующий шаг и нужные документы. Занятость и доход могут вести по разным веткам, с учётом предыдущих шагов. Завершённая анкета запускает настроенные действия с документами и задачами.

**Загруженные документы становятся рабочими данными**
Клиенты загружают файлы в записи требуемых документов. OCR использует компактную нейромодель для переноса значений в поля; приватность документов была важным требованием к подходу. Настраиваемые колонки и поля позволяют расширять модель данных при изменении требований. Извлечённые значения используются в процессах документов, расчётов и задач.

**Рабочие задачи каждого участника**
Правила назначают участников документов и создают задачи для их части ипотечного процесса. У каждого есть список задач или Kanban-доска; задачу можно переназначить или выполнить повторно. Статусы задач и документов отражают разные виды прогресса. Шаблоны сообщений с параметрами адресуются пользователям или контактам.

**Связь с действующим процессом в Encompass**
BOS обменивается документами с Encompass, связывает внешние ID документов и выбранные статусы. Импорт, экспорт и синхронизация используют сопоставления полей и записи интеграционных задач, соединяя клиентскую анкету с действующей системой компании. Предусмотренный сценарий интеграции — шаг, зависящий от подписи: провайдер вроде PandaDoc может передать статус подписания перед продолжением процесса.

**Организации и доступ**
Ипотечный процесс работает в модели организаций, подразделений, членства и ролей. Права объединяют разрешённое действие с областью доступа и условиями на данные. Так доступ к документам соответствует обязанностям человека в организации.

**Документы и формы с состоянием**
Типы документов задают типизированные поля, справочники и связи родительских и дочерних документов. Многошаговые формы поддерживают вложенные и повторяемые поля, сохраняют ответы и после завершения создают или связывают документы. Ожидаемая версия в запросе позволяет обнаружить устаревшую правку и вернуть конфликт.

**Расчётные потоки**
Расчёт объединяет атрибуты документов, константы и предыдущие результаты формул. Предпросмотр показывает значения и их источники; запуск потока создаёт документ с результатом. Один из сценариев — расчёт дохода для ипотеки. Печатные шаблоны превращают данные документа в PDF.

**Начисления, связанные с работой**
Начисления охватывают фиксированную месячную сумму, премии за закрытые кредиты и вознаграждение при достижении документом участника настроенного статуса. Правила определяют получателя и базу: фиксированные суммы, проценты, базисные пункты и лимиты. Внутренние записи сохраняют документ и правило происхождения, включая удержания и рекомендации; это учёт вознаграждений, а не банковский перевод.

**Моя ответственность**
Я спроектировал и разработал BOS для действующей ипотечной компании: уточнял потребности, предлагал варианты, обосновывал архитектурные решения и дорабатывал реализацию вместе с бизнесом. Моя ответственность охватывала решение и его код.

- Настраиваемые типы документов и многошаговые формы собирают связанные данные. Отдельные расчётные потоки показывают результаты формул или создают новые документы.

- Области доступа и правила событий управляют действиями с документами. Начисления по статусу сохраняют ссылку на документ и правило, а записи транзакций имеют проверки в БД.

**Инструменты и технологии**
Domain modelling, Business process modelling, BOS, CRM, BPM, Organizations, Departments, Users and memberships, Roles & permissions, Roles and permissions, Pipelines, Stages, Processes, Workflow, Tasks, Operation sequences, Dynamic documents, Document types, Dynamic fields, Nested fields, Repeatable fields, Calculated fields, Document relationships, Templates, Formula engine, Formula engines, Calculators, Printable forms, File management, Email automation, Email integration, Email templates, External mailboxes, Notifications, Event-driven automation, Compensation models, Salaries, Financial movements, Conditional forms, Document OCR, Encompass, Kanban, Task assignment, Transactions, Audit history, External APIs, Python, FastAPI, PostgreSQL, Multi-step forms, Divisions, Data modelling, Foreign keys, Constraints, Triggers, Document hierarchy, Background workers, SKIP LOCKED, Outbox, Leases, Retries, Bounded concurrency

### MCP Hub


Оркестрация агентов, знания проектов и повторное использование опыта

Инфраструктура агентов и архитектура интеграций

Я создал сервис, в котором агенты находят инструменты и знания проектов, работают с подключёнными системами и сохраняют полезные методы для следующих задач.

[MCP Hub](https://bartenev.site/ru/work/mcp-hub/)

**Разбор расхождения между подключёнными сервисами**

Иллюстративный разбор реализации

Представим агента, который выясняет расхождение остатков и готовит задачу для его решения. Ему нужны данные подключённых сервисов, достаточный контекст и чёткая граница перед внесением изменений.

1. Найти нужные инструменты в разрешённом каталоге и загрузить только их точные схемы.

2. Читать в пределах общего бюджета; сохранять большие ответы как артефакты с превью.

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

**Что это даёт**
Агент получает рабочий контекст под задачу, а оператор может проверить действие, решение о доступе и сохранённый результат. Согласование привязано к согласованному действию и аргументам.

**Решение и компромисс**
Выборочный поиск добавляет шаг, но не загружает все схемы интеграций в каждый запрос. Превью сокращают текущий контекст; полные артефакты нужно запрашивать отдельно, и у них есть срок хранения. Неизвестный результат внешней записи остаётся неизвестным — не превращается в успех или слепой повтор.

**Задача**
Операционные вопросы охватывают несколько систем, тогда как широкий доступ к БД и постоянно растущий каталог инструментов создают проблемы прав и контекста агентов.

**Как я это реализовал**
Я объединил схемы инструментов по запросу, исполнение в рамках прав и сохранённые результаты с локальными embeddings, полнотекстовым поиском и повторно используемыми методами. Собственный runner агентов распределяет общие бюджеты между делегированными задачами; автоматизации сохраняют запуски и состояния подтверждения. Знания, наблюдавшиеся вызовы и обратная связь разделены, чтобы следующие задачи могли использовать опыт с учётом его контекста.

**Результат**
Я использую MCP Hub для исследования ошибок, обзора коммуникаций и анализа активности проектов в БД, логах и рабочих инструментах. Нужные схемы, сохранённые результаты и предыдущие методы можно открывать по мере необходимости, сосредоточив повторные исследования на задаче.

**Найти операцию, затем получить её схему**
Поиск инструментов возвращает краткие результаты с подсказками аргументов, сведениями о риске и ссылкой на схему, проверяемой при вызове. Агент запрашивает точную схему выбранной операции, затем вызывает её по имени. Полный каталог интеграций остаётся за пределами промпта, а путь от намерения до актуального контракта инструмента — явным.

**Локальные embeddings и гибридный поиск**
Знания проектов объединяют FTS5 с локальными embeddings SentenceTransformer. Потоковый просмотр векторов отбирает ID лучших фрагментов до загрузки содержимого; хеши позволяют не векторизовать неизменённый текст. Для повторно используемых методов есть отдельный путь: семантический и лексический отбор, после которого опциональный локальный CrossEncoder оценивает соответствие задаче.

**Границы проекта и подтверждения выполнения**
Исследование нескольких систем начинается с разрешённых проектов, ресурсов и операций. В этих границах можно анализировать записи БД, логи и коммуникации. Вызовы, требующие подтверждения, ожидают решения человека. Подтверждения выполнения связывают наблюдавшиеся результаты с текущим запуском, а аудит сохраняет действия и помогает проверить итоговый вывод.

**Методы, сохраняющие контекст и обратную связь**
Агент может сохранить цель, условия применения, план вызовов с ветвлениями и выводы из неудачных попыток. Следующие задачи получают небольшую подборку методов, которые можно использовать, адаптировать или пропустить. Оценка полезности и подтверждённый успех остаются отдельными сигналами. Обучение накапливает и уточняет опыт; неизменённое повторное использование сохраняет существующий метод и его embedding.

**Общее управление делегированной работой**
Встроенный runner агентов использует общий контроллер токенов, вызовов моделей, попыток инструментов, workers и параллельности для делегированной работы. Срок выполнения и отмена действуют на дерево запусков, а резервирование операций отслеживает пересекающиеся запросы. Так оркестрация сохраняет общий бюджет и явную ответственность за исполнение, когда агенты делят задачу.

**Автоматизации с сохранением запусков**
Триггеры cron, interval и event запускают операцию инструмента или многошаговый процесс агента. Состояние запусков хранится в SQLite; workers забирают работу с указанием владельца и lease, а истёкшие lease можно восстановить. Ожидание подтверждения имеет явное состояние. Регулярные проверки активности проектов и коммуникаций используют тот же управляемый интеграционный слой.

**Сохранять результаты и компактный контекст**
Результаты хранятся зашифрованными; доступ по идентификатору учитывает владельца, срок действия и версию политики. Фрагменты знаний читаются выборочно, пакеты памяти ограничивают число записей и символов. Краткие описания методов ведут к большим планам, а небольшие планы содержат условия сразу. Агент может возвращаться к деталям без копирования каждого исходного ответа в разговор.

**Моя ответственность**
Я спроектировал и создал интеграционный слой и собственный runtime агентов: поиск инструментов, знания проектов, контроль выполнения и повторное использование опыта.

- Локальные embeddings и гибридный поиск находят нужные знания. Схемы инструментов и сохранённые результаты открываются по запросу, сохраняя фокус рабочего контекста.

- Агенты и сохраняемые автоматизации используют исполнение в рамках прав, согласования, записи результатов и бюджеты. Завершённая работа может явно пополнять методы; веса модели не обучаются.

**Инструменты и технологии**
MCP, Tool discovery, Agent orchestration, Permissions, Permission boundaries, Human approval, Approval flows, Audit, Project isolation, Stored results, Context management, Context optimization, Automation, Knowledge retrieval, Slack, Teamwork, Telegram, Databases, Logs, Email integration, Internal services, Cross-system investigation, Bounded database operations, Log analysis, Tool RAG, Progressive disclosure, Context efficiency, Execution memory, Project knowledge, Reusable experience, Cross-project context, Recurring automations, User journey investigation, Embeddings, Hybrid retrieval, Reusable methods, FTS5, Vector search, SentenceTransformers, CrossEncoder, Reranking, Learning feedback, Schemas on demand, Schema references, Result handles, Execution receipts, Context budgets, Shared budgets, Operation claims, Subagents, Cron, Event triggers, Persistent task runs, Lease recovery

### Amazon Data / Trends


Масштабный парсинг Amazon и анализ тенденций

Архитектура сбора и обработки данных

Я спроектировал и реализовал сервис данных Amazon, который сканировал категории маркетплейса, кроме книг, и использовал пакетную обработку Elasticsearch для поиска тенденций.

[Amazon Data / Trends](https://bartenev.site/ru/work/amazon-data/)

**От разрозненных листингов к пригодному набору данных**

Исторический процесс · по данным автора

Для изучения товарных тенденций по категориям сбор и хранение должны были работать вместе. Загрузка страниц была лишь первым шагом: неоднородным записям требовались общее представление и эффективный путь к анализу.

1. Параллельно собирать данные категорий, координируя аккаунты, прокси, частоту и повторы.

2. Нормализовать записи перед пакетной индексацией в Elasticsearch.

3. Читать группы записей для анализа вместо отдельного запроса к хранилищу для каждого листинга.

**Что это даёт**
Набор данных по категориям поддерживал анализ тенденций. Архивный сервис обрабатывал миллионы листингов около пяти месяцев; это приведённый мной исторический масштаб, не текущий benchmark пропускной способности.

**Решение и компромисс**
Пакетный подход охватывал запись и чтение, сокращая число отдельных обращений к хранилищу. Компромисс — данные становятся доступны группами, а не мгновенно по одной позиции. Полнота и актуальность зависят от внешнего источника; размер набора не доказывает точность тенденции или прогноза.

**Задача**
Ширина каталога требовала параллельного сбора и стратегии хранения для миллионов объявлений, без отдельного чтения или записи для каждой позиции.

**Как я это реализовал**
Параллельные парсеры объединяли управление аккаунтами и proxy, ограничение частоты и повторные попытки при сканировании категорий. Я организовал нормализацию и работу с Elasticsearch вокруг пакетных записей и чтений, сохраняя пакетный подход при росте данных. Результат использовался для анализа изменений и тенденций.

**Результат**
Сервис работал около пяти месяцев в историческом масштабе порядка миллионов объявлений. Он поддерживал анализ тенденций по категориям, затем команда сменила фокус, а проект был архивирован.

**Исторический охват категорий**
Проект сканировал категории Amazon по каталогу, сознательно исключая книги. Исторический объём данных был порядка миллионов объявлений. Такой охват объединял сбор, нормализацию и хранение в одну задачу: данные категорий должны были стать согласованным набором для пакетного анализа.

**Сбор при внешних ограничениях**
Парсеры должны были учитывать блокировки, несколько аккаунтов, proxy и неудачные запросы. Параллельная обработка, ограничение частоты и повторы были частью архитектуры сбора. Нормализация давала индексации и анализу согласованное представление несмотря на различия собранных данных.

**Пакетная запись и чтение**
Elasticsearch использовался и для пакетной записи, и для пакетного чтения. Пакеты были важны с обеих сторон: собранные записи индексировались вместе, а анализ получал группы записей, чтобы нагрузка не состояла преимущественно из одиночных запросов. Это решение определяло путь данных наравне с выбором поискового движка.

**Анализ тенденций и завершённый этап продукта**
Целью сбора было выявление изменений и тенденций в товарных данных. Сервис работал примерно пять месяцев, затем приоритеты сместились на другую работу. Архивный проект объединяет полную инженерную цепочку: параллельный сбор, нормализацию, пакетный доступ к хранилищу и анализ большого исторического набора данных.

**Моя ответственность**
Я спроектировал и реализовал путь от сбора до анализа: параллельный сбор, нормализацию и пакетный доступ к Elasticsearch.

- Параллельные парсеры учитывают ошибки запросов и внешние ограничения через контроль частоты и повторы; нормализация готовит согласованный набор данных.

- Индексация и анализ работают пакетами, поэтому путь данных не зависит от отдельного запроса к хранилищу для каждого объявления.

**Исторический масштаб · по данным автора**

Сервис работал около пяти месяцев с историческим объёмом порядка миллионов объявлений. Он поддерживал анализ тенденций категорий до архивации проекта.

**Инструменты и технологии**
Data acquisition, Parallel processing, Parallel scraping, Proxy management, Proxy rotation, Multi-account parsing, Retries, Retry strategies, Throttling, Request throttling, Normalization, Data normalization, Elasticsearch, Bulk indexing, Bulk writes, Bulk reads, Bulk reading, Trend analysis, Amazon category scanning, Large datasets, Historical data analysis, Index structures, Bulk operations, Search/read models, Data pipelines

### Liqsale / Daily Snipes


От прайсов поставщиков к маркетплейсу

Архитектура продукта и обработка данных

Я построил процесс, превращающий разрозненные предложения распродажи остатков в структурированные товарные объявления с поиском.

[Liqsale / Daily Snipes](https://bartenev.site/ru/work/liqsale/)

**Задача**
Покупателям приходилось вручную просматривать разнородные таблицы и письма с неполными данными о товарах.

**Как я это реализовал**
Я связал импорт писем и таблиц с нормализацией, идентификацией по штрихкоду или ASIN и обогащением из внешних источников. AI помогал структурировать неполные данные и определять категории, а операторы видели состояния обработки и ошибки.

**Результат**
Файлы поставщиков стали объявлениями, связанными с ценами, остатками и складами, в продукте с покупателями, продавцами, чатами и заказами.

**Инструменты и технологии**
Data ingestion, XLS / XLSX / CSV, XLS / XLSX / CSV ingestion, Email ingestion, Data normalization, ASIN, ASIN identification, Barcode identification, AI enrichment, Product enrichment, Data enrichment, Categorization, Catalog architecture, Supplier catalogs, Categories, Attributes, Listings, Warehouses, Inventory, Prices, Orders, Chats, Admin panel, Import monitoring, Processing states, Processing statuses, Error handling

- [Liqsale · оптовый каталог](https://liqsale.com/) — Публичный каталог оптовых товаров и остатков с информацией о продуктах и складах.

Продукт · Публичная страница · Ссылки проверены: 2026-09-27

- [Daily Snipes · каталог](https://dailysnipes.com/) — Та же линейка оптовых продуктов под названием Daily Snipes, которое также указано на сайте Liqsale.

Продукт · Публичная страница · Ссылки проверены: 2026-09-27

### Unity MCP Efficient


Меньший интерфейс инструментов с доступом к полному каталогу операций

Проектирование и реализация фасада

Я создал слой совместимости, позволяющий агентам находить операции Unity без загрузки всех схем инструментов в контекст.

[Unity MCP Efficient](https://bartenev.site/ru/work/unity-mcp-efficient/)

**Задача**
Большой видимый модели набор инструментов занимал контекст ещё до выбора нужной операции.

**Как я это реализовал**
Я отделил поиск от исполнения: схемы операций загружаются по запросу, а размер ответов ограничен. Пакетное исполнение, сохранённые результаты, квитанции и идемпотентные повторы учитывают дублирование изменений, асинхронную работу и перезагрузки домена Unity.

**Результат**
Опубликованное авторское сравнение от 24 августа 2026 с upstream v10.1.0 показывает 48 → 6 видимых модели инструментов и доступ к 377 операциям. Контекст схем снизился с 23 280 до 915 оценочных токенов (символы ÷ 4); это документированная оценка, а не независимо воспроизведённый тест скорости или стоимости.

**Моя ответственность**
Я спроектировал и реализовал фасад совместимости, отделив поиск операций от исполнения и предоставляя схемы по запросу.

- Компактный видимый модели интерфейс сохраняет поиск и доступ к полному каталогу операций.

- Пакеты, ограниченные результаты, записи выполнения и обработка повторов поддерживают асинхронную работу Unity и перезагрузки домена.

**Опубликованное авторское сравнение**

Сравнение в README от 24 августа 2026 с upstream v10.1.0. Токены схем оценены как символы ÷ 4; это измерение объявлений инструментов, а не всего контекста, скорости или стоимости задачи.

- 23,280 → 915: оценочных токенов схем

- 48 → 6: видимых модели инструментов

- 377: операций остаются доступными

[GitHub · сравнение и методика](https://github.com/Vangardo/unity-mcp-efficient#readme)

Источники проверены: 2026-09-27

**Инструменты и технологии**
MCP, Tool discovery, RU/EN tool search, Schemas on demand, Context optimization, Bounded results, Batch execution, Stored results, Receipts, Idempotency, Retry semantics, Duplicate mutation protection, Unity domain reload, Asynchronous operations, State inspection, Compatibility layers

- [Unity MCP Efficient · GitHub](https://github.com/Vangardo/unity-mcp-efficient) — Открытый код, инструкции настройки и тесты компактного MCP-фасада для Unity.

Исходный код · Публичная страница · Ссылки проверены: 2026-09-27

- [Unity MCP Efficient · методика измерений](https://github.com/Vangardo/unity-mcp-efficient/blob/main/BENCHMARKS.md) — Воспроизводимые измерения размера схем инструментов и компактных результатов, с базовой версией и ограничениями.

Документация · Публичная страница · Ссылки проверены: 2026-09-27

Указанное сокращение относится к объёму контекста, а не стоимости API или общей скорости работы.

### MySellerHub


Общая модель независимых каналов продаж

Multichannel-архитектура и интеграции

Я спроектировал backend-модель товаров, объявлений в каналах, заказов и складов, связав обновление остатков и исполнение заказов между внешними платформами.

[MySellerHub](https://bartenev.site/ru/work/mysellerhub/)

**Задача**
Каждый канал по-своему описывал один и тот же товар и заказ, поэтому синхронизация требовала общей предметной модели.

**Как я это реализовал**
Я отделил товары от объявлений в каналах и сопоставил внешние идентификаторы с общей моделью. Операции Shopify как канала продаж и поставщика имеют отдельные сценарии. Импорт заказов связан с назначением склада, а синхронизация остатков отслеживает целевое количество, его версию и последнее отправленное значение.

**Результат**
Архитектура связала публикацию товара в другом канале с возвратом статуса его исполнения; текущий публичный продукт делает акцент на Shopify и остатках Amazon.

**Канал продаж и поставщик**
Shopify может быть каналом продаж, который получает товары и передаёт заказы покупателей, или поставщиком, который предоставляет каталог и исполняет закупочные заказы. Эти роли имеют отдельные процессы вокруг общей модели товаров и объявлений. Заказ поставщику содержит локальный идентификатор для поиска уже созданного внешнего заказа.

**Остаток может измениться во время обновления**
Каждая цель обновления остатка имеет количество и версию. После отправки worker проверяет, актуальна ли ещё версия. Если остаток успел измениться, запись остаётся в ожидании следующей попытки. Правила резерва и верхнего предела остатка корректируют цель до отправки в канал.

**Продолжение импорта заказа**
Импортированный заказ находится по магазину, интеграции и внешнему ID, а его позиции сопоставляются с объявлениями. Следующая синхронизация может повторить назначение склада для существующих позиций и обновить исполнение и tracking. Частично обработанный заказ остаётся в той же модели.

**Моя ответственность**
Я спроектировал multichannel commerce-модель и пути синхронизации объявлений, остатков, заказов и исполнения.

- Товары и идентификаторы разных каналов согласуются в общей модели публикации и синхронизации остатков.

- Заказы связываются с подходящим источником исполнения, а tracking возвращается в исходный канал.

**Публичные данные о продукте**

Текущий сайт продукта сообщает этот показатель каталога. Его нынешнее предложение отличается от более широкой multichannel-модели, над которой я работал.

- 10,000+: товаров, готовых к публикации

[MySellerHub · сайт продукта](https://mysellerhub.com/)

Источники проверены: 2026-09-27

**Инструменты и технологии**
Multichannel commerce, Canonical data models, SKU mapping, Products, Listings, External identifiers, Inventory synchronization, Supplier orders, Customer orders, Order routing, Fulfillment, Tracking, Warehouses, Pricing policies, Bidirectional synchronization, Retries, Idempotency, Eventual consistency, Reconciliation, State reconciliation, Shopify, Amazon, eBay, Redis, JSON, TTL, Cache invalidation, OAuth, Webhooks, HMAC, State synchronization, Notifications, PostgreSQL, LISTEN/NOTIFY, Event signalling

- [MySellerHub · платформа продавца](https://mysellerhub.com/) — Обзор продукта: подбор товаров, синхронизация остатков и исполнение заказов.

Продукт · Публичная страница · Ссылки проверены: 2026-09-27

- [MySellerHub · Shopify App Store](https://apps.shopify.com/mysellerhub) — Страница опубликованного приложения указывает Onlihub Inc. как разработчика и описывает интеграции каналов продаж.

Внешний источник · Публичная страница · Ссылки проверены: 2026-09-27

- [Справочный центр MySellerHub](https://help.mysellerhub.com/) — Инструкции по началу работы, каталогам, листингам, заказам и доставке.

Документация · Публичная страница · Ссылки проверены: 2026-09-27

### Onlihub Catalog


Разные пути данных для разных нагрузок

Архитектура и реализация сервиса каталога

Я спроектировал и реализовал отдельный сервис каталога Onlihub с основным путём на Rust, резервным на Python, кешированием Redis и Elasticsearch.

[Onlihub Catalog](https://bartenev.site/ru/work/catalog/)

**Задача**
Большие наборы объявлений и тяжёлые запросы требовали модели чтения, соответствующей способам доступа к данным.

**Как я это реализовал**
Я разделил быстрый обслуживающий слой на Rust, резервный Python-путь, кеш и поиск/чтение с транзакционным хранилищем. Балансировка и ограничение частоты сдерживали повторный трафик, а пакетная обработка и оптимизация запросов работали с тяжёлыми операциями над данными.

**Результат**
Поиск и частые чтения получили собственный путь, а транзакционное хранение и бизнес-логика сохранили отдельные обязанности.

**Отдельный сервис и определённые пути данных**
Каталог маркетплейса стал отдельным сервисом с собственной обслуживающей архитектурой. Rust отвечал за основной быстрый путь, рядом работал резервный Python-подход. Я отвечал и за архитектуру, и за реализацию, отделяя нагрузку каталога от более широкого commerce-приложения.

**У кеша, поиска и транзакций разные задачи**
Redis кешировал данные для повторных чтений, Elasticsearch обеспечивал модель поиска/чтения, а PostgreSQL сохранял транзакционные обязанности. Это разделяло получение данных каталога и хранение бизнес-состояния. Пакетные операции и оптимизация тяжёлых запросов дополняли это распределение.

**Контроль повторного трафика на входе**
Балансировка и ограничение частоты были частью дизайна сервиса. Клиентов с избыточными повторными запросами можно было замедлить до преобладания их трафика. Управление запросами, кеш и быстрый обслуживающий слой проектировались вместе, учитывая и поступление запросов, и способ чтения данных.

**Инструменты и технологии**
Rust, Python, PostgreSQL, Elasticsearch, Redis, Read models, Search models, Transactional storage, Caching, Cache layers, Bulk operations, Query optimization, Rate limiting, Request throttling, Load balancing, Backend performance, Python fallback, Index structures, Search/read models, Data pipelines

### Manufacturing Engineering


Физический процесс, который стоит за программой

Технологическое проектирование и CAD/CAM

Мой инженерный фундамент — проектирование деталей, операций обработки и процессов запуска изделий в производство.

[Manufacturing Engineering](https://bartenev.site/ru/work/manufacturing/)

**Задача**
Деталь должна была вписаться в воспроизводимый производственный процесс с реальными ограничениями станков, материалов и последовательности операций.

**Как я это реализовал**
Я работал с CAD/CAM-моделями, программами CNC, постпроцессорами и технологической документацией. Работа охватывала раскрой листового металла, токарные и фрезерные операции, расход материалов и подготовку серийного производства.

**Результат**
Эта работа сформировала мой подход: понять реальный процесс, определить ограничения и только затем проектировать автоматизацию.

**Инструменты и технологии**
Manufacturing process modelling, Part design, Assembly design, CAD, CAM, CAD/CAM, CATIA, SolidWorks, AutoCAD, CNC, FeatureCAM, CNC Cad, Postprocessors, Sheet metal, Nesting, Cutting, Turning, Milling, Coordinate punching, Turn-mill machines, Machine programs, Materials, Material planning, Material consumption, Operation sequencing, Process optimization, Production launch, Serial production, Process bottlenecks, Technical documentation

### ERP / 1C


Перевод операций предприятия в учётную модель

Анализ бизнеса и прикладная разработка

Я создавал и поддерживал решения 1C для украинских компаний, работая напрямую с заказчиками над учётом, планированием производства, расходом материалов и логистикой.

[ERP / 1C](https://bartenev.site/ru/work/erp/)

**Задача**
Бизнес-документы должны были формировать корректные складские и финансовые движения во взаимосвязанных процессах предприятия.

**Как я это реализовал**
Я изучал работу предприятий и переводил её правила в документы, отчёты, запросы и интеграции в 1C УТП/УНФ. Прикладные модули охватывали транспортную логистику и производственные операции, нормы материалов, себестоимость и внутренние обмены данными.

**Результат**
Этот опыт связал программные модели с реальными остатками, деньгами и последствиями операций и стал основой дальнейших финансовых и бизнес-систем.

**Понять компанию до настройки системы**
Я работал напрямую с заказчиками, изучая технологические и административные процессы, в том числе в проектах с нуля. Сначала выяснял реальное движение материалов, документов, остатков и денег, затем настраивал учёт и интеграции. Операционная модель заказчика определяла модель программы.

**Производство, материалы и планы расходов**
Работа охватывала планирование производства, нормы и расход материалов, складские движения, себестоимость, зарплату и планы расходов. Производственный опыт помогал связать цифры в 1C с операциями, которые их создают. Отчёты и сложные запросы делали эту информацию пригодной для планирования и контроля.

**Прикладные модули для реальных операций**
Я разрабатывал модули транспортной логистики и инструменты для ускорения или улучшения производственных операций. Обмены данными и интеграции связывали эти модули с остальным учётом компании. Этот опыт заложил модель «документ → движение», которая позднее появилась в финансовых сервисах и бизнес-платформе на Python.

**Инструменты и технологии**
1C, 1C УТП/УНФ, 1C УТП, 1C УНФ, ERP, Business analysis, Business discovery, Customer collaboration, Process formalization, Accounting, Business accounting, Production planning, Material norms, Material consumption, Procurement, Stock accounting, Stock movements, Cost accounting, Payroll, Expenses, Transport logistics, Reporting, Data exchange, Inter-system exchanges, Document-driven accounting, Complex queries

### Financial Systems


Платежи, документы и целостность данных

Финансовое моделирование и интеграции в разных проектах

В Onlihub и Liqsale я создавал подписки, разовые платёжные сценарии и модели транзакций, связанные с выписками, перерасчётами и бизнес-документами.

[Financial Systems](https://bartenev.site/ru/work/finance/)

**Задача**
Успешный callback платежа был лишь частью задачи согласования балансов, состояний транзакций и бизнес-документов.

**Как я это реализовал**
Я работал со Stripe и Wise, подписками, checkout, платёжными webhooks и PDF-выписками. Также проектировал модели учёта транзакций и исследовал обеспечение финансовых инвариантов через транзакции, constraints и triggers PostgreSQL.

**Результат**
Эта практика соединяет мой опыт ERP с современными платёжными системами: финансовые операции моделируются через явные состояния, категории и движения.

**Платежи внутри торгового процесса**
Моя работа в Onlihub и Liqsale включала подписки, разовые платежи, корзины, checkout и синхронизацию статусов. Интеграции Stripe и Wise были частью финансового процесса приложения, связывая платёжные события с заказом или подпиской клиента и соответствующими записями транзакций.

**Модель транзакций за выписками**
Я работал над типами и категориями транзакций, расчётами, перерасчётами и выписками, включая PDF. Эти записи описывают связь финансовых операций с состоянием приложения и документами. Модель позволяет проследить показанные пользователю цифры до транзакций и движений, которые их сформировали.

**Исследование инвариантов в PostgreSQL**
Я исследовал перенос части финансовых правил в транзакции, constraints и triggers PostgreSQL, включая ограничения баланса и движения от изменения статуса документа. Цель — явно описать важные инварианты на уровне данных. Защита баланса через триггеры была направлением экспериментов в этой работе.

**Инструменты и технологии**
Stripe, Wise, Subscriptions, One-time payments, Checkout, Shopping carts, Payment statuses, Payment webhooks, Transaction ledgers, Transaction categories, Transaction types, Statements, PDF statements, Recalculations, PostgreSQL, Transactions, Constraints, Triggers, Financial invariants, Financial movements, Document-driven accounting

### Zipurch


Торговая активность на карте

Интеграция заказов и геопространственные сценарии

Я работал над объединением активности заказов, информации о товарах и географического контекста на карте.

[Zipurch](https://bartenev.site/ru/work/zipurch/)

**Задача**
Потоку заказов требовался визуальный контекст, связывающий место события с покупаемыми товарами.

**Как я это реализовал**
Я работал с агрегацией заказов, геоданными, tracking и карточками товаров, связанными с commerce-каталогом. При проектировании также рассматривались маршруты и оценки доставки; публичный Product Map показывает продукт.

**Результат**
Работа добавила географическое измерение торговым событиям, связав активность на карте с товарным каталогом.

**Инструменты и технологии**
Order aggregation, Geodata, Product maps, Tracking, Route modelling, Route calculation, Delivery estimates, Estimated delivery time, Catalog integration

- [Zipurch · поиск товаров](https://zipurch.com/) — Страница продукта на базе Onlihub: тенденции покупок, географические данные и анализ рынка.

Продукт · Ранний доступ · Ссылки проверены: 2026-09-27

Страница приглашает в ранний доступ; часть функций отмечена «Coming Soon».

### Meeting-to-Actions


От устных решений к структурированной работе

Интеграция речи и агентных процессов

Я работал над процессом превращения аудио встречи в решения, дальнейшие действия и задачи в Teamwork через MCP.

[Meeting-to-Actions](https://bartenev.site/ru/work/meeting-automation/)

**Задача**
Решения из разговора требовалось превратить в структурированную работу с ответственными, а не оставлять в аудиозаписи.

**Как я это реализовал**
Распознавание речи формировало транскрипт для AI-анализа решений, задач и ответственных. MCP связывал структурированный результат с Teamwork, соединяя обработку аудио с существующей рабочей системой.

**Результат**
Процесс связал содержание встреч с рабочими записями в системе задач команды.

**Инструменты и технологии**
Speech recognition, Transcription, AI analysis, Action extraction, MCP, Teamwork, Workflow integration

### Local AI / Lightweight ML


Выбор модели под конкретную задачу

Прикладные исследования и прототипы процессов

Я исследую локальные модели и легковесное исполнение для речи, документов, поиска и прикладной автоматизации.

[Local AI / Lightweight ML](https://bartenev.site/ru/work/local-ai/)

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

**Как я это реализовал**
Я работаю с локальными LLM, исполнением прежде всего на CPU, ONNX и GGUF, а также речевыми инструментами Whisper, Sherpa-ONNX и Silero. Эксперименты охватывают OCR, embeddings, векторный поиск, многоязычную обработку и TTS.

**Результат**
Прикладные эксперименты формируют мой подход к выбору моделей и их связи с полезными процессами.

**Инструменты и технологии**
Local LLMs, Lightweight models, CPU-first inference, Whisper, Sherpa-ONNX, Silero, ONNX, GGUF, OCR, Document recognition, Embeddings, Vector search, Semantic retrieval, Speech pipelines, Multilingual processing, TTS

### TON Tanks


Telegram-игра: серверные бои и игровые системы

Руководство продуктом, backend и игровые системы

Я участвовал в создании концепции, разработке и запуске Telegram-игры. Backend обрабатывает пошаговые PvP/PvE-бои, способности танков, аренду, крафт и сохранение результатов; игровые активы связаны с кошельками и состоянием NFT.

[TON Tanks](https://bartenev.site/ru/work/ton-tanks/)

**Задача**
Игровой прогресс, цифровое владение, торговля и backend должны были сложиться в цельный продукт.

**Как я это реализовал**
Моя работа охватывала игровую логику, backend, продуктовые решения и координацию задач разработки. Сервер управляет ходами, очками действий, эффектами и уроном, отправляет обновления боя через WebSocket и записывает результаты. Также я занимался запуском, продвижением и TON/NFT-частью продукта.

**Результат**
Моя историческая оценка — 130 тыс. пользователей; её период и способ подсчёта не сопоставлены с числом на сайте продукта. Самостоятельный проект объединил игровые системы, backend-разработку и запуск.

**Боевой цикл**
Серверный бой координирует ходы PvP и PvE. Состояние танка включает здоровье, броню, скорость, способности, эффекты, перезарядку и очки действий. Цикл определяет следующий ход, применяет действия и урон, затем отправляет клиентам доступные действия и изменения состояния через WebSocket.

**Владение, аренда и крафт**
Доступ к танку различает владельца и арендатора и учитывает время восстановления и лимиты аренды. Крафт проверяет исходные танки и их владение, затем записывает документ крафта и полученный игровой танк. Связи с кошельками и состояние NFT входят в модель активов.

**Текущее состояние и сохранённые результаты**
Сервер хранит текущее состояние боя, а клиенты получают обновления. Записи в базе связывают бой с его танками и сохраняют итоговые данные, включая урон и очки. Аутентификация Telegram WebApp связывает сессию игрока с игровым API.

**Моя ответственность**
Я работал над направлением продукта, backend и игровой логикой, координировал задачи разработки и участвовал в запуске.

- Серверные PvP/PvE-бои управляют ходами, эффектами и уроном, отправляют текущие обновления и сохраняют результаты.

- Сессии Telegram, владение через кошельки, аренда и крафт связывают доступ игрока с моделью игровых активов.

**Публичные данные о продукте**

Это количество пользователей приложения с публичного сайта. Отдельный исторический показатель 130 тыс. взят из моего описания проекта и не является той же проверенной метрикой.

- 80,000: пользователей приложения по данным публичного сайта

[TON Tanks · публичная страница проекта](https://tontanks.io/)

Источники проверены: 2026-09-27

**Инструменты и технологии**
Product concepts, Product launch, Product promotion, Task allocation, Game backends, Game logic, Game balance, Progression, Rewards, Telegram integration, TON, Blockchain transactions, NFTs, NFT economy, Minting, Ownership, Trading, Marketplace mechanics, WebSocket, PvP/PvE, Turn-based battles, Rentals, Crafting

- [TON Tanks · сайт игры](https://tontanks.io/) — Официальный обзор игры, её механик и ссылки на Telegram-игру и NFT-коллекцию.

Продукт · Публичная страница · Ссылки проверены: 2026-09-27

- [TON Tanks · коллекция на GetGems](https://getgems.io/tontanks) — NFT-коллекция, на которую напрямую ссылаются сайт игры и её официальный Telegram-канал.

NFT-коллекция · Просмотр с JavaScript · Ссылки проверены: 2026-09-27

GetGems требует JavaScript и может ограничивать автоматические запросы. Ссылка на коллекцию подтверждена источниками проекта; количество NFT и торговые данные не проверялись.

- [TON Tanks · Telegram-канал](https://t.me/ton_tanks_nft) — Официальный канал с сайта tontanks.io: обновления игры и ссылка на коллекцию.

Официальный канал · Публичная страница · Ссылки проверены: 2026-09-27

### Modular Vehicles / Unity


Физика, модульная техника и процедурные миры

Самостоятельная разработка игровых систем

Я разрабатываю и исследую модульную технику, повреждения, физику гусениц и процедурные окружения в Unity.

[Modular Vehicles / Unity](https://bartenev.site/ru/work/unity-games/)

**Задача**
Сборная техника требует независимых модулей, которые вместе работают как цельная физическая и игровая система.

**Как я это реализовал**
Я создаю модульную архитектуру техники с отдельными частями, логикой повреждений, движением на гусеницах и стрельбой. Эксперименты охватывают multiplayer, режимы PvP/PvE, захват зон, процедурные города, растительность и оптимизацию.

**Результат**
Продолжающаяся самостоятельная разработка для проверки взаимодействия физической симуляции, модульного дизайна и игровых механик.

**Инструменты и технологии**
Unity, C#, Modular vehicle architecture, Vehicle assembly, Independent modules, Damage systems, Physics, Tracked vehicle mechanics, Shooting, Multiplayer experiments, PvP, PvE, Capture zones, Football mode, Procedural environments, Procedural city generation, Vegetation, Game optimization

### Blender / 3D


От hard-surface моделей к игровым ресурсам

Самостоятельное моделирование и подготовка ресурсов

Я использую Blender для создания и подготовки hard-surface моделей, материалов и текстур для игровых окружений.

[Blender / 3D](https://bartenev.site/ru/work/blender/)

**Задача**
3D-ресурс должен работать и визуально, и в рамках ограничений приложения реального времени.

**Как я это реализовал**
Я работаю с моделированием, hard-surface геометрией, материалами и текстурами. Подготовка включает оптимизацию для игровых проектов, связывая визуальную работу с техническими требованиями среды исполнения.

**Результат**
Коллекция самостоятельных 3D-работ, дополняющая мой опыт игровых систем и физической инженерии.

**Инструменты и технологии**
Blender, 3D modelling, Hard-surface modelling, Materials, Textures, Game-ready assets, Asset optimization

### Engine Sim Unity Audio


Физическая симуляция как источник игрового звука

Самостоятельная разработка аудиоинструментов

Я работал над автоматизированным созданием банков звуков двигателя для Unity из физического симулятора двигателя.

[Engine Sim Unity Audio](https://bartenev.site/ru/work/engine-audio/)

**Задача**
Результат симуляции требовалось превратить в пригодный для игры набор звуков двигателя.

**Как я это реализовал**
Я связал физическую симуляцию двигателя с автоматизированным созданием аудиобанков. Работа сосредоточена на инструментах между генерацией звука и подготовкой ресурсов для Unity.

**Результат**
Инструментальный проект на пересечении симуляции, автоматизации и производства игровых ресурсов.

**Инструменты и технологии**
Unity, Engine audio banks, Physical engine simulation, Audio generation, Asset automation

- [Engine Sim Unity Audio · GitHub](https://github.com/Vangardo/engine-sim-unity-audio) — Код и документация моего офлайн-генератора аудиобанков на основе Engine Simulator от AngeTheGreat.

Исходный код · Публичная страница · Ссылки проверены: 2026-09-27

### Crypto Trading Terminal


Рыночные данные, стратегии и исполнение в одном инструменте

Самостоятельная разработка приложения

Я создал торговый терминал с рыночными данными, графиками, собственными стратегиями, backtesting и исполнением операций на бирже.

[Crypto Trading Terminal](https://bartenev.site/ru/work/trading-terminal/)

**Задача**
Исследование стратегий требовало связного пути от исторических данных и индикаторов до исполнения и сохранения результатов.

**Как я это реализовал**
Я объединил графики и индикаторы SMA, EMA, MACD, TMA и RSI с пользовательскими стратегиями и backtesting. Исполнение операций на бирже, комиссии, P&L и сохранение результатов сформировали операционную часть терминала.

**Результат**
Приложение связало анализ стратегий и исполнение на бирже в одном процессе с учётом комиссий, P&L и сохранением результатов.

**Инструменты и технологии**
Market data, Charting, SMA, EMA, MACD, TMA, RSI, Backtesting, User-defined trading strategies, Live exchange execution, Commissions, P&L, Results persistence

## Контакт


[Telegram](https://t.me/vangardo)

[LinkedIn](https://www.linkedin.com/in/igor-bartenev-452a92290/)

[Facebook](https://www.facebook.com/igor.bartenev)

[Reddit](https://www.reddit.com/user/Complex-Chance-7258/)

[GitHub](https://github.com/Vangardo)

[Скачать CV](https://bartenev.site/cv/igor-bartenev-ru.pdf)

[Продукты и источники](https://bartenev.site/ru/resources/)