Журнал изменений
Летопись глобальных решений — что изменилось, почему и как было раньше.
Здесь фиксируются глобальные изменения платформы: архитектурные решения, переименования, смена компонентов. Каждая запись отвечает на три вопроса: что изменилось, почему, и как было раньше.
Журнал — краткая летопись решений. Точная построчная история любого файла —
git log --follow <файл> и git diff в репозитории northtech.
2026-07-13 — Разделы серверов собраны в каталог «Сервера»
Стало: «Портал» и «NEURO CORE» — подразделы каталога Сервера;
адреса страниц — /docs/servers/portal/... и /docs/servers/neuro-core/....
Было: два самостоятельных раздела верхнего уровня, /docs/portal/... и
/docs/neuro-core/....
Почему: оба раздела описывают физические серверы платформы — общий каталог отражает архитектуру и разгружает верхний уровень навигации.
2026-07-13 — Запрещены PostgreSQL, ClickHouse, Laravel, NestJS, FastAPI
Стало: перечисленные технологии запрещены во всём проекте — в основном
коде, вспомогательных сервисах, прототипах и зависимостях. Хранилища — только
MongoDB и Qdrant, backend — только Go. Запрет зафиксирован в
Обзоре ТЗ, правилах Cursor (.cursor/rules/forbidden-tech.mdc)
и CLAUDE.md.
Было: ТЗ (раздел 13) предлагало их как «один из рабочих вариантов» стека; формального запрета не существовало.
Почему: команда закрепила единый стек — один язык backend и два хранилища снижают стоимость сопровождения и исключают дрейф технологий.
2026-07-13 — ТЗ оформлено разделом документации
Стало: раздел Техническое задание из семи страниц — первоисточник требований заказчика: кабинеты и роли, профориентационный модуль, персональные данные, модель данных, безопасность, этапы и команда. Зафиксировано согласованное отклонение принятого стека от предложенного в ТЗ.
Было: ТЗ существовало только как docx в documantation.
Почему: ТЗ — главный документ проекта; требования должны быть доступны команде и связаны с реализацией.
2026-07-13 — Реструктуризация репозитория
Стало: docs/ — Fumadocs-сайт документации; documantation/ — рабочие
заметки, входные требования (input/), обзор хостингов (servers/) и ассеты.
Было: сайт в apps/docs/, заметки в docs/, ассеты в корне.
Почему: структура упрощена — один каталог на сайт, один на исходные материалы.
2026-07-13 — Дизайн-система документации
Стало: кастомные компоненты — выноски в стиле Astro (Callout с иконкой и
заголовком), API-референс в стиле Stripe (две колонки, sticky-примеры,
APIMethod/APIField), WebSocket-протокол в диалоговом виде
(WSFlow/WSMessage: сервер слева, клиент справа).
Было: дефолтные блеклые выноски Fumadocs, API одной колонкой markdown-таблицами, WS-события плоским JSON-листингом.
Почему: документация читается заказчиком и командой — важное должно быть видно сразу.
2026-07-13 — Реструктуризация документации
Стало: пять разделов — О проекте / Архитектура / Портал / NEURO CORE / Эксплуатация, у каждой страницы иконка, диаграммы mermaid (sequence, gantt, state).
Было: девять плоских страниц без иерархии (project, portal,
architecture, api, ai-and-rag, security, deployment, sources).
Почему: плоский список перестал отражать структуру системы; API и RAG требовали собственных разделов.
2026-07-13 — Переименование: AI BASE → NEURO CORE
Стало: GPU-сервер называется NEURO CORE, сервис — NEURO CORE Service.
Было: AI BASE / AI BASE Service (это имя осталось в исходных требованиях
documantation/input/).
Почему: решение команды о нейминге продукта.
2026-07-13 — Векторы вынесены в Qdrant
Стало: эмбеддинги и векторный поиск — в выделенной векторной БД
Qdrant; MongoDB хранит данные, реестр документов и текст чанков. Связь по
общему chunk_id / doc_id. Ingest идемпотентен в обеих базах.
Было: всё в MongoDB, включая поле embedding[] в knowledge_chunks и
векторный поиск через $vectorSearch.
Почему: выделенная векторная БД лучше масштабируется под рост базы знаний, даёт payload-фильтрацию и снимает векторную нагрузку с основной СУБД.
2026-07-12 — Зафиксирована двухсерверная архитектура
Стало: WEB PORTAL (Nginx + React + Go + Redis, единственный вход из
интернета) и закрытый GPU-сервер (Go-сервис, MongoDB, vLLM Qwen3, ingest
worker через Asynq). Связь — только POST /v1/chat по внутренней сети.
Было: первоначальная концепция из входных требований — см. Источники.
Почему: экономия (CPU для сайта, GPU для нейросети), стабильность, скорость RAG, независимое масштабирование — подробнее в Архитектуре.
Меняешь что-то глобально (архитектура, имена, компоненты, контракты API) — добавь запись сверху журнала в формате «Стало / Было / Почему» в том же изменении, и зафиксируй его коммитом в git.