Реестр проектов

Описание. Self-hosted корпоративный RAG на Go с Telegram-native ingest: бот архивирует переписку разрешённых групп (append-only) + вложения, чанкует чат-окна и Markdown, эмбеддит (bge-m3) в Postgres+pgvector, отвечает гибридным поиском (RRF вектор+FTS → bge-reranker → локальная LLM) с цитатами. Есть web-консоль (SPA), админка, мультитенантность с per-chat ACL и коннекторы к внешним источникам (Confluence, Jira, сайты, папки). Все модели — локально по HTTP (TEI/Ollama), данные не покидают периметр.

Состояние. Активная разработка, ~664 коммита, 420 Go-файлов / 245 тестовых, 82 user stories, TDD-цикл через агентов. Готово: 01-ingest, 02-chunking, 03-indexer, 04-query, 06-query-ui, 06b-admin-ui, 07-multitenancy-acl, 07b-whoami, коннекторы 08 (framework/folder/confluence/website/jira), web e2e-харнесс (rel-16). Проверен живьём на GPU-сервере (4×V100, qwen2.5 32b/72b) на реальном корп-Confluence. Осталось: 05-privacy-admin (retention/erase — частично), 09-summaries, 10-compliance-pack, добор коннекторов (GitLab, code-repo), MCP-сервер. Не в проде.

Коммерческие перспективы. Средние-высокие при фокусе на нишу. Дифференциация: Telegram как корпус знаний (у Onyx/Khoj/RAGFlow он не first-class источник) + полностью on-prem RAG под 152-ФЗ для РФ/СНГ, где западный SaaS (Glean $40–50/мес, Guru $25/мес) недоступен по комплаенсу. Рынок AI в РФ 60,8→83,2 млрд ₽ (2025→2026, +37%), RAG — почти каждый второй B2B-AI-проект, «коробок» мало — окно открыто. Модель: open-core (бесплатное ядро) + on-prem лицензия и внедрение/поддержка + per-seat за корпоративный UI; публичный SaaS противопоказан позиционированию. Риски: сильные бесплатные конкуренты по «общему» enterprise search, продажа через интеграторов, длинный цикл.

Комментарий от меня. Сделано под конкретного заказчика. Может быть проект будет открыт заново. Остановлен по причине необходимости либо аренды сервера с GPU либо покупки своего. Можно делать коммерческий проект.

Описание. Multichannel-система для продавца на маркетплейсах: принимает данные поставщика (push / pull / ручной ввод), сводит их в канонический каталог, преобразует под требования площадки правилами на expr-DSL (маппинг полей, справочники значений, ценовые формулы, фильтры публикации), публикует листинги и следит за их статусом, забирает обратно заказы, остатки и статусы, считает аналитику продаж, движение товаров и unit-экономику (комиссионные группы, себестоимость, мультивалютность с курсами ЦБ). Go 1.25 monorepo: 9 микросервисов, Kafka (KRaft) + Protobuf-контракты как источник правды, Temporal-воркфлоу, PostgreSQL + TimescaleDB, MinIO; React/TS админка (22 раздела, i18n en/ru/tr), клиентский периметр с ACL по учёткам и брендам. Первая и пока единственная площадка — Lamoda (Seller Center + B2B, двойная авторизация, мок-сервер в репозитории).

Состояние. Активная разработка. Готово и проверено живьём: сквозной поток по реальному кабинету Lamoda (326 товаров, 2492 заказа), identity + ACL, бренды и учётки МП, mapping DSL, поллинг заказов/остатков, дашборды и unit-экономика, демо-стенд показывается. Планы, которые есть, но не реализованы: Wildberries / Ozon / Яндекс.Маркет — шортлист 13 площадок; вынос интеграций в отдельный проект-оркестратор с gRPC-контрактом — только бриф на проектирование; сервисы ingestion, enrichment, storefront-generator заявлены в архитектуре и уже имеют папки миграций, но не написаны; черновики US-101…US-106 из конкурентного анализа (расчёт поставок с прогнозом спроса, генерация УПД в XML для ЭДО, UI ввода себестоимости, аналитика рекламного кабинета, глубина метрик дашборда, инкрементальный курсор поллинга).

Коммерческие перспективы. Оценка из собственных исследований в репозитории — 45 систем в матрице по 6 рынкам. Как продукт — низкие: оператор сам зафиксировал в AR-004, что уникального торгового предложения нет. Реалистичные ниши: (1) интеграция поставщиков, публикация листингов, mapping DSL, мультимаркетплейс; (2) локальный комплаенс и рутина продавца — УПД/ЭДО, комиссионная модель, себестоимость и маржа, расчёт поставок с прогнозом по истории в TimescaleDB; (3) монетизация не подпиской на SaaS, а внедрением, поддержкой и платными интеграциями поверх открытого ядра — при обязательном условии, что появится лицензия и установка перестанет требовать четырёх инфраструктурных сервисов. Риски: одна работающая площадка из тринадцати запланированных, стоимость каждой следующей интеграции высока, у крупных площадок нет песочниц.

Комментарий от меня. В данный момент в тестовой эксплуатации у заказчика. Но ему нужна только Lamoda. Можно дописать коннекторы к другим маркетплейсам и продавать самостоятельно. Заказчик не против.

Описание. Блокчейн профессиональных гильдий с гибридным консенсусом Proof-of-Reputation + Proof-of-Stake. Анонимная верификация навыков через on-chain challenge-flow, soulbound-репутация с экспоненциальным затуханием по доменам, GUILD-токен (100M genesis) для стейкинга (4 уровня) и двухкворумного управления, commit-reveal арбитраж споров с жюри, VRF-ротация валидаторов по эпохам. Go 1.25 monorepo: node daemon (dpgd) + CLI, 16 internal-пакетов (wallet, reputation, token, skill, staking, governance, dispute, oracle, consensus, p2p, api, crypto, guild, verification, storage, types), REST API (28 эндпоинтов /v1/), BadgerDB, libp2p, Cosmos SDK v0.50.6 / CometBFT v0.38.7 / ibc-go v8.2.0. React/TS фронтенд (6 feature-модулей: wallet, reputation, skill, governance, guild, verification). TDD-цикл через специализированных агентов (red/green/refactor).

Состояние. Реализовано: модули wallet (create/recover/import/login/unlock), reputation (view/accrue/decay), token (genesis/transfer/balance), skill (полный challenge lifecycle с 9 эндпоинтами), staking, governance (proposals), dispute, oracle, consensus engine, p2p, guild directory, address verification, REST API-сервер, фронтенд для 6 фич. Планы, не реализованы: Story 04 (network status), 05 (validator registration), 06 (governance proposals — UI и расширенная логика), 10 (wallet import — спецификация есть, handler-тесты частично), 11 (wallet create local), 12 (transfer coins — спецификация и тесты есть), 13 (guild directory — план Phase 0–8 составлен, Phase 3 governance create_guild отложена до Story 06); handler-тесты skill покрывают 1 из 9 эндпоинтов (план достройки 18 handler + 4 acceptance тестов составлен); IBC-интероперабельность, gRPC-транспорт, DNS/PEX peer discovery — код есть, но не тестировался в реальной сети, только локально на трёх нодах; нет деплоя, тестнета.

Коммерческие перспективы. Грубая оценка: низкие в текущем виде, потенциально средние при выходе на нишу. Рынок credential/skill-verification блокчейнов очень тесный — существуют Dock.io, Galxe, RabbitHole, Layer3, Gitcoin Passport, десятки DID-протоколов (Ceramic, Spruce, Polygon ID). Отличие DPGChain — фокус не на общих credentials, а на профессиональных гильдиях с привязкой репутации к конкретным доменам-навыкам и экономическим стимулом через challenge-deposit, что ближе к вертикали «децентрализованный Upwork/Toptal». Монетизация возможна через комиссию с challenge-депозитов, листинг в skill marketplace, стейкинг-доходность для валидаторов. Риски: гибридный консенсус PoR+PoS не обкатан под нагрузкой, рынок web3 credentials перенасыщен, регуляторная неопределённость токенов.

Комментарий от меня. Сделал и спроектировал сам чисто «for fun» как альтернативу текущим реалиям найма. Есть мысль, что это можно превратить в систему для AI-агентов.

Описание. DIY-проект автоматической настольной/балконной NFT-оранжереи на Arduino Uno R3 плюс веб-конструктор к ней. Веб-конструктор webapp/ — React 18 + Vite, без бэкенда, всё в браузере и localStorage: по габаритам, культуре (13 пресетов с EC/pH, DLI, фотопериодом, шагом посадки, сроком до сбора) и методу (NFT/DWC/капля/прилив-отлив) считает число растений и каналов, объём бака, подбирает насос/вентилятор/аэратор из каталога, мощность фитосвета по формуле PPFD × площадь ÷ эффективность LED, воздухообмен, энергобаланс в кВт·ч и ₽, БП, бюджет пинов и реле против Uno/Mega, BOM со сметой; сверху — прогноз урожая диапазоном ±30% (тепловая сумма Q10^((T−Tопт)/10) + свет-лимитированная модель LUE × DLI × дни), переменная себестоимость ₽/кг с амортизацией и без, окупаемость/ROI/цена безубыточности, интерактивный план компоновки вид сверху на canvas. Экспорт: спецификация .md, JSON, сгенерированный config.h, PNG плана, печать.

Состояние. Прототип выходного дня. Готово: прошивка целиком, калибровочный скетч, распиновка (docs/wiring.md), Wokwi-схема со сценарием проверки, веб-конструктор со всеми пятью карточками результата и экспортами, продакшн-сборка в dist/. Планы, которые есть, но не реализованы: главный разрыв — конструктор ушёл далеко вперёд прошивки: в вебе выбираются DWC/капля/прилив-отлив, Arduino Mega, датчики CO₂ (MH-Z19) и освещённости, аэратор, нагреватель раствора, циркуляционный вентилятор, дозаторы pH и EC — прошивка не поддерживает ничего из этого.

Коммерческие перспективы. Исследований на эту тему в папке нет. Грубая оценка: низкие, это учебно-портфолийный DIY-проект, а не продукт. Единственное, что реально отличается, — веб-конструктор: инженерный расчёт + смета + прогноз урожая, себестоимость ₽/кг и окупаемость в одном экране; русскоязычных калькуляторов такой глубины мало, и он мог бы работать как лид-магнит магазина комплектующих (трафик по запросам «гидропоника своими руками» → партнёрские ссылки/продажа наборов с прошитым контроллером) или как платная услуга проектирования под заказ.

Комментарий от меня. Делал по запросу знакомых демку-прототип. Можно делать что угодно — всё равно скорее всего никому не нужно.

Описание. Три интерактивные демо-симуляции этого протокола обучения детей с участием LLM под три разные конфигурации заказчика. Три React 18 / Vite SPA без бэкенда, весь сценарий детерминирован в src/*.js: app — школьный вариант (кабинет педагога → сборка сессии → сессия ученика с физически закрытым чатом, перехватом «просто скажи ответ» и срывом модели в объяснение → разбор ролей, с глобальным тумблером разметки педагог/LLM/совместно/ученик); app-tutor — репетиторский (приём → контракт → узел под счётчиком → верификация анонимной сетью проверяющих с якорными работами → расчёт) с моделью ценообразования economics.js, где цена узла выводится из часов и премии за риск, а инвариант «трудный ученик не хуже лёгкого по ставке в час» проверяется функцией при каждом расчёте; app-parent — семейный (раздвоенный синхронный экран «что видит родитель / что видит ребёнок» посекундно, предсказание до занятия, сверка предсказания с реальностью, тренажёр разбора чужих детских работ, граф педагогических умений родителя рядом с графом физики ребёнка). Общий для трёх вариантов граф навыков skillgraph.js (16 узлов, prerequisite-рёбра, состояния освоенности) собран по схеме отдельного проекта school-skills. Отдельно — внутренняя страница razbor/: сравнение трёх конфигураций по структуре сделки, векторам коррозии и проверенным данным.

Состояние. Законченная демонстрация, но не продукт. Планы, которые есть, но не реализованы: пилот на 2–3 учениках описан целиком (§07 — кого брать, что фиксировать, рискованные блоки 3 и 4, контрольные точки без модели). Из демонстраций не следует ни одной серверной части: банк заданий, невидимый исполнителю, сеть обезличенных проверяющих, якорные работы, база норм по другим семьям, затухающий суфлёр — всё нарисовано в интерфейсе и существует только как сценарий в JS. Отдельно помечены неисправленные дефекты: центральная механика родительского варианта (родитель выбирает педагогический ход) признана самой сомнительной частью конструкции — «ошибка не исправлена, только помечена», исправление означает переделку всей фазы; страница razbor/ закрыта только noindex и прямо описана как «не защита».

Коммерческие перспективы. Исследование в папке есть — страница razbor/ (§03 «Данные», §05 «Открытое»): три исследовательских прогона с состязательной верификацией утверждений и ссылками на источники. Исходная рыночная гипотеза: школа возьмёт ИИ как замену учителя и провалится (школа производит присмотр, социализацию и аттестацию, из которых ИИ не заменяет ни одного), протокол подхватят репетиторы — у них единственных есть внешний арбитр (экзамен, не подконтрольный исполнителю), затем рынок развернётся к родителям, потому что он шире. Верификация подтвердила ключевые риски: оплата по результату надёжно геймится (синтез 52 исследований — эффект на целевую метрику нулевой, на её искажение «compelling»; подлог в чикагских школах 4–5% классов ежегодно, таргетированно на 25–50 перцентиль), селекция учеников напечатана прямо в правилах гарантии Tutor.com, ISA как модель схлопнулась (BloomTech, пожизненный запрет CFPB), родители выбирают обучающий продукт по звёздам и не различают методику и баззворды (N=149, d ≥ 0.50), тогда как педагоги различают. Сегмент уже ожидаемого: собственно семейное образование — 3,4% детей (NCES 2022–23), а родители как наставники — слабейший тип (0.23 против 0.50 у учителей), кроме случая обучения узкой процедуре (d = 1.15). Оценка: низкие как у самостоятельного продукта, средние — как у методики и консалтингового артефакта. Продавать пока нечего: бэкенда нет, пилота нет, ни одного измерения на реальных учениках, а сам протокол копируется за вечер — не копируется только дисциплина его соблюдения, которой у массового покупателя нет. Реалистичные ниши: (1) методический материал и обучение педагогов и родителей протоколу — единственная механика с прямым экспериментальным подтверждением (тренажёр разбора чужих работ); (2) продажа трёх демонстраций как консалтингового артефакта — они показывают заказчику, как именно его схема оплаты испортит педагогику; (3) репетиторская конфигурация как продукт для платформы, а не для репетитора — но прецедентов оплаты репетитора по результату не найдено ни одного, и в §05 это признано главной непроверенной ставкой. Риски по собственному списку нерешённого: самый слабый ученик оказывается самым дорогим (рыночная логика прямо противоположна образовательной, внутри схемы неразрешимо — нужен внешний фонд или потолок цены), консенсус сети проверяющих может уехать целиком вместе с якорями, родительские нормы осмысленны только за сотнями занятий, которых у первых семей нет, а бюджет времени родителя (1,5–2 ч в неделю на предмет вглубь, 6–10 на полную программу) выведен из структуры протокола, а не измерен.

Комментарий от меня. Сделано по заказу инициативной группы из министерства образования. Имеет некоторый потенциал продолжения. Я бы на этих идеях сделал систему для репетиторов.

Описание. Мобильное приложение для членов спортивного клуба: информация о клубе, объявления и мессенджер, плюс собственный сервер клуба. Архитектурная особенность — никакого центрального бэкенда: каждый клуб поднимает свой инстанс, пользователь добавляет клуб, вводя URL сервера и почту, и держит в одном приложении несколько клубов сразу.

Состояние. Готово: весь цикл регистрации и аутентификации, информация, объявления, мессенджер, профиль с аватаром и отображаемым именем, offline-кеш на Room, доступность (контраст, фокус, тёмная тема, Switch Access для PIN-пада), локализация на 7 языков. Планы, которые есть, но не реализованы: push-уведомлений нет ни на одной стороне — в ARCHITECTURE они заявлены на FCM с тремя типами событий, бэкенд только хранит device-токены (RegisterToken/DeregisterToken, отправки нет вообще), а в андроиде нет ни зависимости Firebase, ни сервиса сообщений — есть только разрешение POST_NOTIFICATIONS и внутренние event-bus'ы. Загрузка картинок не реализована по существу — и в сообщениях, и в аватарах файл принимается, проверяется content-type и выбрасывается, а в БД пишется выдуманный путь вида /uploads/messages/{id}_{filename} с комментарием «в проде это ушло бы в объектное хранилище». Второго приложения — админского — не существует, хотя по ТЗ именно в нём администратор заводит темы, объявления и контент: в API есть ровно один админский эндпоинт (одобрение регистрации по статическому секрету), ни одного POST/PUT для объявлений, информации или тем нет, и наполнить сервер можно только сидером или руками в SQL. Партнёры — заглушка по ТЗ, съёмка аватара с камеры вынесена за скоуп.

Коммерческие перспективы. Исследований рынка в папке нет. Грубая оценка: низкие как у продукта, средние как у шаблона под заказную разработку. Ниша занята плотно и с обеих сторон: сверху — универсальные платформы для клубов и спортивных секций (Spond, TeamSnap, Heja, Clubo, Sportlyzer, в РФ — CRM для фитнеса вроде Mobifitness и 1С:Фитнес клуб, у которых мобильное приложение члена клуба идёт в комплекте), снизу — обычные Telegram-каналы и чаты, которыми клубы решают ровно эти три задачи бесплатно и без установки ещё одного приложения. Собственный сервер на клуб — это одновременно и единственное реальное отличие, и главный барьер продаж: спортивной секции придётся арендовать VPS, накатывать docker-compose и завести SMTP ради новостей и чата, чего она делать не будет. Реалистичные сценарии: (1) шаблон и демо для заказной разработки мобильных приложений; (2) white-label под конкретного заказчика — федерацию, сеть клубов, крупный клуб, который хочет своё приложение и готов оплатить хостинг; (3) переход от «сервер на клуб» к обычному SaaS с одним бэкендом и админкой, но это фактически другой продукт. Риски: без админского приложения и реального хранилища файлов до пилота ещё заметный объём работы; push-уведомления, на которых держится удержание в мессенджере, не сделаны; конкуренция с бесплатным Telegram неустранима ничем, кроме отраслевой специфики (расписание, посещаемость, абонементы, оплата), которой в проекте пока нет вообще.

Комментарий от меня. Заказчик — федерация айкидо Казахстана. Денег нет и видимо не будет. Только можно рассмотреть преобразование в какой-то конкретный сектор другого рода.

Описание. Сервис учёта остатков поставщиков для дилера напольных покрытий и отделочных материалов. Забирает остатки оттуда, куда их присылают на самом деле: читает почтовые ящики по IMAP, вынимает вложения (.xlsx, .xls OLE2/BIFF8, .pdf), а с 19.08 ещё и ходит по ссылкам, потому что поставщики начали присылать не файл — Google Sheets через export?format=xlsx, постоянную папку Nextcloud с меняющимся файлом и JSON-ленту витрины на 410 КБ. Оригиналы складываются в версионированные папки, дальше формат опознаётся по содержимому, раскладка — по форме листа (19 профилей на 16 поставщиков), строки приводятся к справочникам «поставщик · производитель · категория · товар · единица · тип остатка · склад» и ложатся в PostgreSQL снимками с версионированием: каждая поставка файла — новая версия, актуальность считается по срезу источника, а не по времени письма, поэтому два региона одного поставщика не затирают друг друга. Наружу — HTTP API поиска остатка по частичному названию товара плюс справочники, версии, очередь карантина и уведомления; поверх — Telegram-бот отдельным сервисом.

Состояние. Активная разработка на паузе. Планы, которые есть, но не реализованы: у Telegram-клиента нет таймаута (точка внедрения есть, покрыта тестом); оригинал письма не сохраняется, только вложения. В проде у заказчика нет; стенд живой.

Коммерческие перспективы. Исследований рынка нет. Грубая оценка: высокая ценность как внутренний инструмент конкретного дилера, средние — как тиражируемый продукт. Задача настоящая и массовая: у оптовика на десятки поставщиков нет ни EDI, ни API — остатки приходят почтой в произвольных Excel и PDF, каждый в своей раскладке, и менеджер отвечает клиенту «сейчас уточню» вместо ответа за секунду. Реалистичные ниши: (1) отраслевой сервис для дистрибуции стройматериалов и напольных покрытий, где состав поставщиков устойчив и раскладки меняются редко; (2) продажа не подпиской, а внедрением — профиль на поставщика делается руками, и это скорее сервисная работа, чем самообслуживание (19 профилей на 16 поставщиков — цена входа каждого нового клиента); (3) бот как отдельный, самый дешёвый в продаже кусок: поиск остатка в рабочей группе Telegram без входа в учётную систему. Риски: продукт заточен под одного заказчика.

Комментарий от меня. Работает у заказчика. Можно брать и предлагать в других нишах. Заказчик не против.

Описание. Агентная стохастическая модель жизненных траекторий — попытка численно ответить на вопрос «повезло или сам добился». Популяция из N сущностей (по умолчанию 500–2000), шаг — год жизни; у каждой восемь параметров в диапазоне [0,1] со своими начальными Beta-распределениями (здоровье, богатство, социальные связи, образование, жизненные факторы, личные усилия, интеллект, адаптивность), поверх них — интегральный критерий качества жизни Q с перекрёстными эффектами (синергия «образование × интеллект × усилия», ловушка бедности) и семью зонами от «критической» до «элиты». На каждом шаге считаются детерминированная динамика каждого параметра (старение, доход и расходы, возрастная кривая образования, когнитивное старение, закалка адаптивности по U-образной кривой стресса, mean reversion усилий), асимметричный стохастический шум с редкими событиями (катастрофы здоровья, кризисы, джекпоты) и обратная связь Q → параметры (эффект Матфея). Сверху — семь режимов среды (тоталитаризм, диктатура, авторитаризм, олигархия, консерватизм, демократия, анархия), каждый из которых меняет множитель шума, потолок образования, наследование богатства, вероятность шоков и перераспределение, и полноценная демография: возрастная пирамида на старте с «прогревом» параметров до текущего возраста, рождаемость по формуле от здоровья, богатства (перевёрнутая парабола демографического перехода), образования и режима, наследование параметров от случайной пары родителей 16–45 лет, смертность по Гомперцу после 60 с поправкой на богатство и адаптивность. Go-бэкенд (~2,6k строк): CLI-режим как основной, REST API с очередью задач и TTL, результаты — JSON-файлами без БД; фронтенд (~1,4k строк vanilla JS + canvas): полярный круг зон с анимацией по шагам, плеер, накопительный график распределения по зонам, боковая панель управления. Docker Compose и шаблон nginx с SSL. Вокруг кода — исследовательская обвязка: 12 документов калибровки (~1k строк) со сверкой TFR/CBR, Gini, возрастной структуры и смертности с реальными странами, и цикл статей — основная «Повезло или сам добился? Как оценить», разбор интеллекта (244 строки) и разбор адаптивности (321 строка) с библиографией, плюс их blog- и HTML-версии.

Состояние. Готово: модель целиком по собственному плану — все восемь пунктов от параметров до инфраструктуры калибровки закрыты; калибровка по 12 направлениям выполнена и задокументирована. Вклад личных усилий в качество жизни 15–20%, как интервал между корреляционной оценкой (9–14%) и каузальным экспериментом с фиксированным Effort (30–45%), причём отдача от усилий максимальна в демократии (+45%) и почти отсутствует в анархии (+11%), а в тоталитаризме потолок достигается уже при Ef=0.1. Статьи цикла опубликованы на Habr. Планы, которые есть, но не реализованы: цикл статей не закончен — адаптивность прямо названа «последним фактором в разборе, но не последней статьёй серии».

Коммерческие перспективы. Исследований на эту тему в папке нет. Грубая оценка: как продукт — низкие, как контент и личный бренд — средние. Сама модель продуктом не является и вряд ли станет: веса критерия Q и структура связей подобраны умозрительно, а калибровка — это подгонка констант под известные агрегаты, поэтому академической ценности без внешней валидации у неё нет, а рынка «симуляторов жизненных траекторий» не существует; ближайшие содержательные соседи (микросимуляционные модели вроде MIDAS и DYNASIM, агентные модели неравенства в духе Sugarscape и работ Bouchaud–Mézard, а также вся линия исследований роли случайности в успехе — Pluchino et al. «Talent vs Luck») живут в академии и грантах, а не в продажах. Реальная ценность здесь в другом: тема «повезло или сам добился» массово интересна, у автора уже есть опубликованный цикл на Habr, а цифра «личные усилия — 15–20% результата», полученная двумя независимыми методами и подкреплённая интерактивной картинкой, — это ровно тот материал, который читают и обсуждают. Реалистичные сценарии: (1) довести цикл до конца — разборы оставшихся шести параметров уже наполовину обеспечены собранной библиографией — и конвертировать аудиторию в то, во что она конвертируется у технических авторов: заказы, выступления, репутацию; (2) образовательное применение — наглядный симулятор для курсов по агентному моделированию и статистике, где ценна именно прозрачность формул. Риски: главный — методологический, модель воспроизводит то, что в неё заложили, и в комментариях это скажут первым делом; тестов и валидации нет, автор один.

Комментарий от меня. Тут особо писать нечего — чисто академический интерес. Будут идеи — пишите.

Описание. Граф школьных навыков по математике и физике и поиск межпредметных разрывов — мест, где физика требует математического навыка раньше, чем этот навык проходят по программе математики. Три слоя. Первый — канонический словарь навыков YAML-файлами прямо в репозитории (домен → кластеры → навыки с определением и классами; рёбра трёх типов: prerequisite, composition и cross-discipline-prerequisite), курируется руками и ревьюится через PR. Второй — ETL-утилита на Go: валидирует YAML и ссылочную целостность, подтягивает внешние источники (Common Core через JSON API, российские ФРП с edsoo.ru из PDF, Junyi Academy из вручную выложенных CSV), материализует граф в PostgreSQL и проверяет сам себя против золотого стандарта — сверяет сгенерированный DAG с экспертным графом предпосылок Junyi Academy по точности и полноте рёбер и отказывается импортировать, если среднее ниже 0,7 (ADR-09). Третий — API и веб-админка: аутентификация по приглашению с JWT, интерактивный DAG на D3 с тремя уровнями зума (домен → кластер → навык), фильтрами по классам, поиском, клавиатурной навигацией и подсветкой межпредметных мостов, и таблица разрывов с сортировкой по severity и экспортом в CSV и Markdown. Тяжесть разрыва считается по формуле из ADR-04 как равновзвешенная сумма трёх компонент — сдвиг по классам, когнитивная нагрузка и критичность навыка. Стек: Go (API + ETL + CLI приглашений), PostgreSQL с goose-миграциями, React 19 + TypeScript + Vite + D3, i18n на трёх языках (en/ru/tr), unit-тесты на Vitest и E2E на Playwright, локальный стенд в docker-compose.

Состояние. Планы, которые есть, но не реализованы: из брифа не выполнена часть про программы Китая и европейской страны — в данных только российские ФРП, тайваньский Junyi и американский Common Core.

Коммерческие перспективы. Решение по коммерции принято внутри самого проекта и записано как ADR-11 от 11.05.2026: статус research / non-commercial. Причина лицензионная и жёсткая: три самых полезных датасета — Junyi Academy и KDD Cup 2010 (условия PSLC, только исследования) и ASSISTments (CC-BY-NC-4.0) — запрещают коммерческое использование, поэтому ADR фиксирует «платного тарифа нет, коммерческой лицензии нет, перепродажи производных данных нет», а взамен разблокирует эти датасеты как источники и как золотой стандарт валидации. То есть коммерческие перспективы закрыты не рынком, а собственным осознанным выбором в пользу доступа к данным. Что из этого следует практически: (1) финансирование возможно не продажей, а институционально — методические службы, институты развития образования, издательства учебников и разработчики программ; вопрос «где физика требует математики раньше, чем её проходят» — настоящая и известная боль согласования предметных программ, а инструмент, который отвечает на него числом и ссылкой на конкретное ребро графа, встречается редко; (2) коммерциализация технически возможна только на другом корпусе — если отказаться от исследовательских датасетов и строить граф на открытых программах (ФРП открыт) плюс собственной разметке, лицензионный запрет снимается, но вместе с ним исчезает и Junyi-гейт, то есть единственный внешний способ проверить, что граф не выдуман; (3) сам движок и словарь как основа для адаптивного обучения — здесь рынок есть и он большой (граф навыков лежит в основе Khan Academy, Учи.ру, ЯКласс, Skysmart), но этим продуктам нужна персональная освоенность ученика, которой в проекте нет вообще, и добавление её — не доработка, а другой продукт. Риски: автогенерация мэппингов не завершена, Junyi покрывает только математику и только тайваньскую программу, а без cognitive_load метрика тяжести разрыва опирается на две компоненты из трёх — то есть главный числовой результат проекта пока приблизителен по построению.

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

Описание. Двусторонняя витрина организации спортивных семинаров для Казахстана: одна сторона — организаторы, которые проводят семинары, вторая — владельцы залов, которые сдают под них место. Организатор публикует мероприятие мастером из семи шагов: основное (название, вид спорта из справочника — БЖЖ, бокс, дзюдо, грэпплинг, йога, кроссфит, плавание, теннис, футбол, художественная гимнастика; кто проводит с регалиями, уровень подготовки, возрастное ограничение, требование медсправки или страховки), даты и место (адрес и площадка выбираются из справочника, а не вводятся текстом), участники (максимум, регистрация до, стоимость участия в ₸ или «бесплатно», способы оплаты — карта, наличные, счёт для юрлиц, что входит в стоимость), снаряжение (что обеспечивает организатор, что участник берёт с собой), фото и расписание по дням с пунктами «с какого по какой час + описание». Владелец площадки публикует место мастером из шести шагов: о площадке (тип — зал единоборств, боксёрский зал, универсальный зал, бассейн, открытая площадка, многофункциональная арена; площадь в м², вместимость, время работы), цены и условия (₸ за час и за сутки, минимальная аренда в часах), инфраструктура и допустимые виды спорта (татами, ринг, душевые, раздевалки, парковка, кондиционер, проектор, звуковое оборудование, трибуны, буфет, инвентарь), снаряжение, фото и график занятости — клик по дням календаря закрывает их для запросов. Поверх — витрины «Ближайшие мероприятия» и «Площадки для проведения», карточки с организатором, адресом и составом расписания, счётчик «Осталось мест N» / «Мест нет» с предложением написать организатору в лист ожидания, форма «запросить проведение на даты» с автоматическим расчётом цены по выбранным в календаре дням, предпросмотр «так страницу увидят участники» перед публикацией и переключатель тёмной и светлой темы.

Состояние. Демо-прототип, живой. Развёрнут на most.ax5a.ru. Прототипность признана прямо в интерфейсе: «В прототипе загрузка заменена заглушками» — про фотографии. Планы, которые есть, но не реализованы — фактически всё, что за пределами клика по интерфейсу.

Коммерческие перспективы. Исследований по этому проекту нет. Грубая оценка: низкие в текущем виде, средние — как заказной инструмент под конкретного игрока. Задача реальная: семинары по единоборствам и йоге в Казахстане анонсируются в Instagram и WhatsApp-группах, площадки ищут через знакомых, и обе стороны тратят время на переписку — интерфейс, где сразу видны занятые даты, цена за сутки и что входит в стоимость, эту переписку сокращает. Но как самостоятельный маркетплейс это упирается в классическую проблему двусторонней площадки: организаторы не придут, пока нет залов, залы не придут, пока нет организаторов, а объём ниши в Казахстане мал — спортивные семинары идут десятками в год на страну, а не тысячами, и комиссии с них не хватит на содержание платформы. Конкуренция при этом не в лоб, а снизу: бесплатные соцсети и мессенджеры закрывают ту же задачу с нулевым порогом входа, а сверху лежат общие сервисы бронирования спортплощадок и продажи билетов на события. Реалистичные сценарии: (1) продать не платформу, а продукт конкретному заказчику — федерации, сети залов, промоутеру семинаров, у которого поток мероприятий уже есть и нужна витрина с записью; (2) сузиться до одного вида спорта (по демо-контенту это единоборства) и одного города, где сообщество плотное и запуск возможен вручную; (3) оставить как демонстрацию возможностей для заказной разработки — в этом качестве оно уже работает, потому что живёт по адресу и открывается. Риски: оплаты и авторизации нет вовсе, то есть до работающего продукта здесь не доработка, а основной объём работ; денежные операции в Казахстане требуют локального эквайринга (в первую очередь Kaspi), которого в прототипе нет даже в планах интерфейса.

Комментарий от меня. Заказчик — федерация айкидо Казахстана. Денег нет и видимо не будет, но сотрудничество возможно. Можно рассмотреть преобразование в какой-то конкретный сектор другого рода.