COMMENT и STATE в трансферных таблицах заполняет только bj2depo: bj их больше не пишет (шапка,
события, BJ_PING). Параметры событий — в PARAMETERS (CONTR_D_ID поручения НРД, номер поручения МНП,
текст причины отказа), EVENT_DATE — фактическое время события в bj. Событий от bj2depo нет: bj не
читает и не помечает DEPO_*, номер документа берёт из FTV_M2M.DOC. Страница «bj ↔ bj2depo» обновлена:
поля, правила, FTV_M2M_PROCESS_WIRING по BJ_ORDER_ACCEPTED/BJ_EXECUTED, примеры SQL, закрытые и
оставшиеся вопросы.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Пакеты НРД из INBOX ИШ (K…, 508…) распознаются по содержимому: квитанция о регистрации (или отказ),
уведомление GS036, отчёт о статусе GS116 (сквитовано / не сквитовано), отчёт об исполнении MS010,
ошибка. В ZIP ответа НРД и выгрузках для регулятора (16 и 16/1) — папки «01 Квитанция о регистрации
поручения — K1699092» и т. д., «Опись.txt» с назначением и реквизитами каждого документа и
«Документы НРД.pdf» (читаемое представление, печать через Chromium; без него — HTML). В карточке
перевода ответы НРД подписаны так же.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Автоматический режим (Настройка → НРД, выключен по умолчанию): входящие переводы — решение по свежей
сверке с DEPO без оператора (пакет только целиком; бумага для квал. инвесторов при неполной или
непрочитанной квалификации — отказ M2M08), поручение 16/1 — как только пришёл черновик MF010,
поручение 16 по исходящим — по черновику. Нет сверки или ИШ — повтор каждые 3 минуты и оповещение,
без сверки ничего не принимается. Обрабатывается только появившееся не раньше суток до включения
(старые черновики в INBOX не подаются). Решение не отправляется повторно по уже отвеченному переводу.
Имитация QUIK МНП (Настройка → QUIK МНП → цикл): регистрация, подпись, снятие и зачисление проходят
как выполненные с пометкой «имитация», в МНП ничего не пишется; события в DEPO — как обычно.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Сверка с DEPO: у бумаги проверяется опция RESTRICTED («Ограничение ценной бумаги по обращению»,
1 — предназначена для квалифицированных инвесторов). Если инвестор не квалифицирован — отказ M2M08;
квалифицирован по всем видам — проходит; по части видов — предупреждение, решает оператор.
Пакет принимается только целиком (решение 16.09): при отказе хотя бы по одной бумаге рекомендация —
отказ по всем с кодом первой отказной, и так же нормализуется отправляемое решение (packageDecisions);
в форме выбор отказа по одной бумаге переключает на отказ все.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
За 30, 14, 7 и 1 день до окончания договора (офлайн-ключ или застрявшее продление — до конца
ключа) bj шлёт уведомление: что продолжит работать, а что отключится. Каждый порог — один раз,
при продлении договора отсчёт заново; проверка раз в час в licenseLoop.
После каждого опроса версий bj запоминает версии внешних систем (МНП QUIK, ИШ, DEPO, экспортёр
ARQA, «Валидата», Java, PostgreSQL, ОС). Если обновления bj недоступны и версия изменилась —
уведомление, что совместимость с новой версией не гарантируется.
Решение: после окончания лицензии цикл QUIK МНП и личный кабинет продолжают работать.
Состояние — /var/lib/bj/.bj/license-watch.json.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
bj собирает версии своих компонентов и внешних систем (в фоне, кэш 10 минут, прогрев при старте):
ядро и модули bj (components.json или «-version»), экспортёр ARQA (служба bj-quikexport, /version),
криптосервис (Health), «Валидата CSP» (zpki1utl), Java, ИШ НРД (deps.json + сайт НРД),
МНП QUIK (VersionInfo), DEPO (OD_DATA_VERSION), PostgreSQL, ОС. «Настройка → Обзор» — таблица
«Версии систем» с кнопкой «Обновить сведения»; в разделах БД, Fancy, QUIK МНП, Экспорт QUIK,
Криптография, НРД, ЛК, НПР и Обновления — строка с версией. В таблице обновлений у компонентов,
выложенных вручную, вместо «неизвестна» — версия самого компонента. bj-component-install: -version.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Код bj-lk перенесён в modules/lk (cmd/bj-lk — запуск, флаг -version); релиз собирает bj-lk
со своей версией (LK_VERSION), unit bj-lk.service встроен в комплект установщика и берёт
адрес bj-server и ключ доступа из /etc/bj/lk.env, а не из unit-файла.
Исправлено: признаки «администратор» и «кабинет клиента» читались из общей переменной
последнего запроса (curReq) — при одновременной работе признак мог достаться чужому запросу.
Теперь из кук своего запроса. Без BJ_URL/BJ_KEY кабинет показывает подсказку настройки
вместо падения службы. Тесты: вход, портфель, health, флаг админа по запросу, без настройки.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
bj-quikexport (modules/quikexport + cmd/bj-quikexport, 127.0.0.1:8084): управление ARQA
quikexport перенесено из bj-server. Настройки у службы в /var/lib/bj/.bj/quik-export/settings.json
(при первом запуске переносятся из setup.json), раздел отдаётся фрагментом с индикатором меню,
действия отвечают X-BJ-Flash. bj-server встраивает раздел в «Настройку», проксирует формы
/admin/setup/quikexport/… и передаёт лицензию (X-BJ-Licensed). Общая проверка служебного
ключа — modules/modkit (им пользуется и bj-npr), общее для прокси — lkgateway/modules.go.
Выделенные из ядра модули (bj-npr, bj-quikexport: Component.FromCore) при обновлении ставятся и
там, где их ещё нет, если входят в лицензию: release.MarkSplitModules, request.json "new",
root-установщик ставит и включает unit-файл из комплекта. Если в обновлении меняется сам
установщик, модули ставятся после перезапуска bj-server (ensureSplitModules).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Модуль вынесен в modules/npr + cmd/bj-npr (127.0.0.1:8083), обновляется
независимо от ядра. Служба читает подключение из setup.json и принимает
запросы только со служебным ключом модулей (/var/lib/bj/.bj/module.key,
создаёт bj-server). Полные страницы отдаются фрагментом (X-BJ-Layout: page).
bj-server хранит настройки и проверку подключения, проксирует /admin/npr
после входа, прав и лицензии и встраивает страницы модуля в общий макет
(admin.modulePage); если служба не отвечает — понятная страница.
Unit bj-npr.service встроен в установщик, установщик включает службы
установленных модулей; build-release.sh собирает bj-npr.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- deploy/iso/build-iso.sh: пересборка официального netinst (xorriso, загрузочные записи
BIOS и UEFI сохраняются), пункт по умолчанию «Установить Bridge&Join», текстовый установщик
- preseed.cfg: русская локаль, Москва, DHCP, SSH и пакеты для bj; спрашиваются только
пароли, диск и подтверждение стирания
- bj-firstboot: при первой загрузке на экране сервера спрашивает ключ продукта и запускает
bj-installer; адрес первичной настройки и код остаются на экране входа
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- cmd/bj-installer (вместо веб-мастера): проверка Debian 13 / Astra, пакеты, пользователь и
каталоги, активация лицензии ключом продукта, PostgreSQL и миграции m2m_core, компоненты
по лицензии с проверкой подписи, root-скрипты и службы, одноразовый код и итоговый экран
с адресом http://<сервер>:8080/first-run; проверка в песочнице (--steps, --root)
- bj: /first-run — пока нет пользователей и установщик оставил код, по коду создаётся
первый администратор (прежние установки без файла работают как раньше)
- internal/release/install.go — общая установка компонентов (bj-component-install и
установщик); bj-component-install стал компонентом ядра
- открытые ключи вынесены в internal/license и internal/release; миграции и файлы
развёртывания встроены (migrations/embed.go, deploy/embed.go); unit bj-server исправлен
- scripts/build-release.sh: сборка с версиями, подпись, публикация на сервер обновлений
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- internal/release/components.go: список компонентов (ядро bj-server, криптосервис, bj-lk,
bj-npr, bj-quikexport) с путём и службой, установленные версии в components.json,
расчёт обновлений по версии каждого файла и sha256 (без отката, модули — только если
уже установлены на сервере)
- cmd/bj-component-install: root-установщик — сам перепроверяет подпись манифеста ключом
/etc/bj/update.pub и sha256, копия прежнего файла, перезапуск только затронутых служб
- updater: bj-server (без прав root) скачивает в update-staging и передаёт установку
root-воркеру (действие component-install); установка в фоне
- настройки: таблица компонентов с версиями, «Обновить» и «Обновить всё»
- bj-release: версия файла из <файл>.version; bj-keymedia-worker: component-install
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
cmd/bj-license-server, cmd/bj-license и deploy/license перенесены в zuevav/lic_Bridge-and-Join-s
(наша инфраструктура, клиентам не поставляется). Здесь остаются клиентская часть
лицензирования, формат токена internal/license и контракт API в docs.
TestTokenCompat — одинаковый тест формата токена в обоих репозиториях.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- bj_exchange и «кран» Fancy убраны: данные модуля ЛК в PostgreSQL (схема lk)
- трансферные таблицы FTV_M2M: создание при установке, события, справочник участников
- сверка с DEPO: счёт, ФИО, дата рождения, ИИС по договору, квал-инвестор из опции DEPO
- боевой ЛК ЕСИА Финанс при тестовом ИШ: журнал, отказ через DEPO, статусы в ЛК
- онлайн-лицензирование в bj, план тестирования M2M для контрагента (интерактивный HTML)
- модули QUIK МНП, экспорт QUIK, НПР/УДС; документы и тестовые материалы
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- bj-license-server: активация по коду и продление токенов (API /v1), кабинет
администратора (клиенты, лицензии, установки, журнал, администраторы)
- защита: доверенные IP установок, jail fail2ban api/admin, раздел «Защита»
с режимом обороны, белым списком и сроками блокировок (root-помощник fw-apply)
- доступ к кабинету: свой адрес вместо /admin, вход только из белого списка,
второй фактор — TOTP или подтверждение в «ЗЕТИТ Ключ» (push/код)
- deploy/license: unit-файлы, fail2ban, path/timer помощника; контракт API в docs
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
При перезапуске bj-server поллер заново вычитывал старые ответы НРД из ИШ и
повторно применял их к заявкам. Для ответов с нулевым GUID (M2Mxx) это давало
ложные «отклонения» по FIFO — все заявки выглядели rejected.
Теперь множество применённых id входящих пакетов хранится в
/var/lib/bj/.bj/poller-processed.json и переживает перезапуск. На самом первом
старте все уже лежащие во входящих пакеты помечаются обработанными, чтобы не
применять исторический backlog к текущим заявкам.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- TransferringDepositoryINN = наш ИНН 7703807489 (ООО ИК «Фонтвьель»,
участник MC0413600000) — иначе M2M17 «неверный ИНН списывающего депозитария»
- место расчётов тест-инвестора = наш реальный тестовый счёт НРД
(MC0413600000 / HL171004001C / 36MC0413600000F00, расч. деп. ИНН 7702165310)
— иначе M2M19 «недопустимое место расчетов»
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Инфраструктура M2M (живой обмен с НРД через ИШ):
- обработка M2MTransferResponse: ERROR(M2Mxx) → заявка Отклонена, сохранение
ответа; INFO → ждём Decision; идемпотентность поллера
- fallback-корреляция ответов с нулевым GUID (M2M14/M2M17) по FIFO
- сырой XML ответа НРД в карточке заявки (для пересылки в ТП)
- тестовый пакет роботу приведён к эталону m2m_robot_samples (CostInfo=Yes,
4 бумаги, IsolationStatus, DocumentSeries=сценарий); override паспорта
- редирект из теста сразу в карточку заявки
Мастер установки ключа Валидаты на флешку (admin/setup/keywizard):
- пошаговый: загрузка .7z+пароль → выбор флешки → запись → справочник
сертификатов (CRL) → перезапуск+проверка ИШ → готово
- привилегированный воркер (bj-keymedia) в host-namespace через файл-обмен,
bj-server остаётся в песочнице
- сохранение структуры профиля архива (spr<N>), перечисление съёмных USB
Прочее:
- пакет-доказательство для ТП НРД + форма регистрации участника M2M
- эталонные образцы робота (DOC/m2m_robot_samples)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Файл автоматически читается Claude Code при старте сессии. Содержит:
- что это за проект (M2M-переводы через MOEX МОСТ НРД)
- текущее состояние + ссылку на REPORT.md
- архитектуру обмена с НРД (bj-server → ИШ → ONYX)
- структуру каталогов и описание DOC/
- неочевидные решения (КриптоПро CSP, не JCP; PKCS#11; mock-робот;
Astra Linux для ИШ; globalRC в admin.go; noProxyClient в news.go)
- команды для разработки и запуска
- описание дев-стендов (10.10.10.22 РЕД ОС, 10.10.10.27 Astra)
- правила (REPORT.md держать актуальным, UI на русском, без emoji
если не просили)
- что НЕ делать (РЕД ОС для ИШ, JCP вместо CSP, выпуск новых сертов)
Это handoff для нового агента — на Astra Linux 10.10.10.27 или на
любой другой ВМ — чтобы он не открывал контекст с нуля.
Переосмысление установщика по фидбеку: установщик должен делать чистую
установку «с нуля», а не миграцию. От пользователя требуется одна
команда и больше ничего:
curl -sSL https://.../install.sh | sudo bash
deploy/astra/install.sh переписан:
- 9 чётких этапов с прогресс-индикатором (секунды от старта)
- Авто-определение ОС: Astra SE → официально, Astra CE/Debian → warn,
Ubuntu → ask, остальные → fail
- Авто-скачивание дистрибутива ИШ (~120 МБ) с old.nsd.ru
- Авто-установка ИШ через dpkg (но если упадёт — это OK, продолжаем)
- НЕинтерактивный режим (--yes) для CI/автоматизации
- Финальная сводка с URL'ами + список ручных шагов
- Дефолтный setup.json создаётся сразу, чтоб bj-server понимал DSN
- ProtectSystem=strict, ReadWritePaths только нужные, PrivateTmp в
systemd unit'е
deploy/astra/migrate-from-redos.sh → переименован в import-data.sh
и стал ОПЦИОНАЛЬНЫМ (для тех кто переезжает с действующего стенда).
Главный путь — чистая установка через install.sh.
deploy/astra/README.md перетряхнут:
- TL;DR с одной командой в самом верху
- Объяснение Astra SE vs Astra CE vs Debian (платное/бесплатное)
- 5 скриптов вместо 6
- Раздел «что произойдёт после установки» — режим эмуляции, что
осталось руками
- 10-этапный путь от чистой ВМ до прохождения теста с роботом MOEX МОСТ
REPORT.md обновлён: установщик описан как «одна команда» вместо
«миграция», % готовности не изменился (но качество улучшилось).
Поскольку Интеграционный шлюз НРД (ИШ) официально работает только на
Astra Linux SE 1.6/1.7 (RPM-версии нет, дистрибутив только .deb для
Debian-based), мигрируем инфраструктуру с РЕД ОС на Astra. Это
заодно проверит «чистую» установку с нуля.
deploy/astra/install.sh — установщик bj-server для свежей Astra ВМ:
- проверка ОС (Astra Linux SE)
- apt-зависимости (curl, git, podman, podman-compose, postgresql-client)
- скачивание Go 1.24+ с go.dev, если нет
- системный пользователь bj + каталоги /opt/bj /var/lib/bj /var/log/bj
- git clone репо в /opt/bj/src
- go build бинарника /opt/bj/bj-server
- podman-compose up -d postgres + накат всех миграций
- systemd unit с безопасными ограничениями (NoNewPrivileges,
ProtectSystem=strict, ReadWritePaths только нужные, PrivateTmp)
- автозапуск + проверка systemctl is-active
- финальная подсказка с URL'ами
deploy/astra/install-validata.sh — установщик Валидата CSP:
- ищет .deb пакеты в dist/validata/ или принимает путь аргументом
- если пакетов нет — печатает текст письма для запроса дистрибутива
у НРД (soed@nsd.ru) или МБ (pki@moex.com)
- dpkg -i + apt-get install -f для зависимостей
- проверка установки в /opt/Validata*
deploy/astra/install-ish.sh — установщик ИШ:
- ищет igate_*_amd64.deb в стандартных местах (dist/ish/, ~/Downloads и т.п.)
- проверяет наличие Валидаты (предупреждает если нет)
- dpkg -i igate_*.deb
- подсказывает следующие шаги (запуск GUI, настройка БД и канала WSL)
deploy/astra/migrate-from-redos.sh — экспорт со старой РЕД ОС ВМ:
- pg_dump БД bj (через podman exec или напрямую)
- копия ~/.bj/setup.json (ищется в нескольких стандартных путях)
- последние 7 дней логов из /var/log/bj и journalctl
- meta.txt с версиями ОС/пакетов
- README.md с инструкциями восстановления на новой ВМ
- итоговый тарбол /tmp/bj-migration-YYYY-MM-DD-HHMM.tar.gz
deploy/astra/healthcheck.sh — проверка после установки:
- 8 разделов: ОС, пользователь/каталоги, systemd, HTTP, PostgreSQL,
Валидата, ИШ, сетевые порты
- цветной вывод OK/WARN/FAIL для каждого пункта
deploy/astra/README.md — пошаговая инструкция миграции из 8 этапов:
- подготовка (Astra ВМ, доступ root, запрос Валидаты у НРД)
- экспорт со старой ВМ
- install.sh на новой ВМ
- restore БД и настроек
- healthcheck
- install-validata.sh + импорт сертификатов УЦ МБ
- install-ish.sh + настройка канала WSL
- первый тест с роботом MOEX МОСТ
- раздел «что НЕ переносится автоматически»
- раздел «откат» (старая ВМ работает до подтверждения миграции)
REPORT.md обновлён:
- общая готовность 72% → 75%
- готовность к роботу 85% → 88%
- новая строка «Установщик/мигратор на Astra Linux: 100% ✅»
- «Установка ИШ на наш стенд» поднялась с 0% до 30%
С официальной страницы НРД (https://www.nsd.ru/workflow/system/programs/web-service/)
скачано всё необходимое для подключения ИШ:
DOC/:
- ruk_install_ish_2025_11_10.pdf (4.7 МБ) — Руководство по установке ИШ
от 10.11.2025, с разделами «6. Технические требования» и «7.3.2 Установка
под Linux»
- ruk_pol_ish.pdf (3.5 МБ) — Руководство пользователя ИШ
- QA_ish.pdf (2.5 МБ) — Часто задаваемые вопросы
- test-case_ish.pdf (1.3 МБ) — Тест-кейсы для проверки работоспособности
- instr_int_sh_01072025.pdf (0.4 МБ) — Инструкция по заявке на тестирование
- web_service_nrd_standard_soap_rest.pdf (2.2 МБ) — техрекомендации
Web-сервиса ONYX
dist/ish/:
- igate_100.0-765_amd64.deb (117 МБ) — дистрибутив ИШ для Astra Linux,
не в git (в .gitignore), но всегда есть для установки
- igate_95.0-716_amd64.SGN — ЭП к дистрибутиву
- README.md — индекс файлов + ссылки на повторное скачивание
Ключевые факты из руководства (попали в REPORT.md и help-страницу):
- ИШ работает на Astra Linux SE 1.6/1.7 (РЕД ОС не упомянута) или Windows
- СКЗИ — Валидата CSP + АПК Валидата Клиент L (НЕ КриптоПро!)
Дистрибутив Валидаты — по запросу soed@nsd.ru / pki@moex.com
- БД — PostgreSQL (обязательна для REST API ИШ) или SQLite
- Сертификат — только от УЦ Московской Биржи (ca.moex.com)
Добавлена help-страница /admin/help/architecture с:
- ASCII-диаграммой полной схемы (bj-server → ИШ → ONYX → робот)
- Таблицей «кто на чьей стороне, какая ОС, какая СКЗИ»
- 8 FAQ-вопросов (включая «ИШ — это сервер НРД?», «можно ли в одну ВМ?»,
«зачем Валидата если есть КриптоПро» и др.)
- Чек-лист «что у нас уже готово»
REPORT.md обновлён:
- общая готовность 70% → 72%
- 7 внешних блокеров вместо 6 (Astra Linux ВМ + Валидата CSP стали явными)
- раздел «Дистрибутив ИШ и полная документация» с описанием каждого файла
Cleanup: .gitignore теперь исключает /dist/ish/*.deb но пропускает
README.md внутри той же папки.
Полный клиент Интеграционного шлюза НРД в internal/nsdadapter/igw/:
client.go — REST endpoint'ы по свежей спецификации НРД:
- POST /api/package/{channel}/file — отправка ZIP (Type=archive, File=base64)
возвращает id пакета (поддерживаются варианты id|package_id|ID)
- GET /api/package/status/{id} — статус NEW|SENT|ERROR (с error-полем)
- GET /api/package?channel=&type=M2MTD|M2MER&date=&id=&count=&excludeErrors=
— список входящих от НРД, с files[] и signs[] (ИШ сам проверяет ЭП и
выдаёт VALID|INVALID)
- GET /api/package/{id} — скачать ZIP (raw или base64-в-JSON, авто-детект
по сигнатуре PK\x03\x04)
- Ретраи только на 5xx/сетевые ошибки (4xx — сразу ошибка)
- HTTP-клиент через options, кастомный таймаут, ретраи
pack.go — упаковщик/распаковщик ZIP по разделу 2.3 инструкции:
- PackRequest(req, docName) — M2MTransferRequest→ZIP с config.xml
- PackXML(xml, docName, packageType) — для эталонных сообщений
- UnpackPackage(zip) → {DocXML, WinfXML, Signature, Filenames}
- ParseDecision / ParseResponse через nsdxml.Unmarshal
Покрыто тестами (10/10 PASS):
- send happy path с проверкой формата JSON-body
- retry на 5xx, без ретраев на 4xx
- GetStatus с числовым id
- ListIncoming как массив (новый формат) и как {items:[]} (старый)
- GetPackage raw ZIP + GetPackage с base64-в-JSON
- упаковка/распаковка: 2 файла в ZIP, имена, содержимое config.xml
- распаковка с .sgn и winf.xml
cmd/bj-server/main.go — NSD-poller адаптирован под новый API
(client.ListIncoming(ctx, ListFilter{}) вместо позиционных параметров;
поля Package.ID/Name/Type/State вместо PackageID/PackageType).
Скачана и положена в DOC/ свежая спецификация (798 KB, 15 стр):
DOC/instr-ish-rest-api.pdf — это исходный документ для нашей реализации.
REPORT.md обновлён:
- общая готовность 65% → 70%
- готовность к роботу 80% → 85%
- добавлен раздел про REST-клиент ИШ
- блокер #6 — отсутствие «Руководства по установке ИШ»
Реализован внутренний робот-эмулятор в internal/nsdadapter/mock/robot.go.
Источник правил: DOC/instruktsiya-po-testirovaniyu-s-robotom.pdf (от
12.05.2026). Когда mock.Sender видит Header.ReceiverCode == MC0012500000
и DocumentSeries в {1111, 2001, 2002, 3333} — формирует Decision по
выбранному сценарию вместо default-логики.
Сценарии:
- 1111 «Ответ с отказом»: все бумаги Rejection, код ошибки берётся из
последних 2 символов DocumentNumber (01..09 → M2M01..M2M09)
- 2001 «Принять все бумаги»: все Confirmation; i-й символ DocumentNumber
= номер депозитария-получателя для i-й секции (1/2)
- 2002 «Принять частично»: 0 = отклонить с M2M05, иначе номер депозитария
- 3333 «Выступить принимающей стороной»: пока только первое сообщение
(отказ M2M05). Встречный M2MTransferRequest от робота — TODO
(требует приёмной стороны bj-server)
Тестовые наборы депозитариев (ИНН 7702165310, depcode MC0012500000,
счёт HL2603250011, разделы 31MC0012500000F00 и 36MC0012500000F00)
зашиты в robotDepositary — соответствуют таблице из инструкции.
Help-страница /admin/help/robot с полным описанием: коды робота,
сценарии, управление через DocumentNumber, тестовые данные, коды ошибок
M2M01-M2M09, как переключиться на реальный TEST3 после получения ИШ.
REPORT.md — сводный отчёт для руководства о ходе работ: ~65% общей
готовности системы, ~80% готовности к интеграционному тесту с роботом
(остальное — внешние блокеры: дистрибутив ИШ, сертификат УЦ МБ).
Расписан план первичного тестирования после получения ИШ — 2-3 недели
до продакшена.
.gitignore: исключены DOC/*.pdf.bak (бэкапы doc-watcher'a).
Когда ИШ НРД не настроен (NSD.IGWBaseURL пустой) или провайдер СКЗИ =
stub — рисуем жёлтую плашку сверху каждой страницы админки с явной
надписью «РЕЖИМ ЭМУЛЯЦИИ — реального обмена с НРД нет» и ссылкой
«Настроить →» на /admin/wizard. Это нужно чтобы пользователь видя
быстро-подтверждённую заявку не думал что это настоящий обмен.
Реализация: добавлено поле IsMockMode/MockReason в page struct,
nowPage() читает globalRC.Snapshot() и заполняет их. globalRC — пакетная
переменная (заполняется один раз в RegisterAdmin), чтобы не таскать
*RuntimeConfig через все renderXxx-вызовы. Сам баннер — в layout.html
перед <main>, поэтому виден везде включая карточку заявки.
Три бага в Doc-watcher / Новостях, всплывшие при первом ручном прогоне:
1. setupFlash после POST в /admin/news/check-docs редиректил на
/admin/setup, а не на /admin/news, и оператор «выпадал» с ленты.
Теперь setupFlash смотрит Referer и возвращает на любой из
/admin/wizard, /admin/news, /admin/setup — на ту страницу с которой
пришёл POST.
2. http.DefaultClient в news.go и cacerts.go подхватывал HTTPS_PROXY
из окружения и шёл через корпоративный zetit, который блокирует
nsd.ru (CONNECT 403). Заменил на noProxyClient с явно отключённой
проксификацией (Transport.Proxy = nil) — doc-watcher всегда идёт
напрямую, независимо от ENV.
3. nsd.ru отдаёт 403 на запросы с UA «bj-server/1.0» (антибот). Заменил
на стандартный Chrome User-Agent + браузерные Accept/Accept-Language.
После этого moex-most-dlya-m2m.pdf найден и скачан, новость
«Обновлена документация» опубликована.
Кроме того, по запросу — убрана форма «Добавить вручную» с /admin/news.
В UI остался только мониторинг: автоматическая лента событий +
ручная кнопка «🔄 Проверить обновления документации сейчас».
Handler /admin/news/add сохранён в коде на случай ручного ввода
инцидентов в будущем.
Новый раздел /admin/news — лента событий системы (окна техработ НРД,
обновления документации, переустановка сертификатов УЦ). Каждая
новость со временем, типом (maintenance/feature/doc-update/system/
manual), опциональным окном действительности (ValidFrom..ValidTo) и
ссылкой на источник. Лента не очищается — служит журналом для аудита.
На дашборде /admin/ — компактный блок «📢 Новости»: показывает максимум
3 актуальных события (активных сейчас или с окном, начинающимся в
ближайшие 7 дней; в остатке — самые свежие). Окна техработ при
наступлении становятся жёлтыми (border-left, ValidFrom..ValidTo).
В ленте можно добавлять новости вручную (форма на /admin/news), скрывать
(soft-delete через Dismissed). Дедуп по ID.
Doc-watcher: горутина в bj-server, раз в сутки качает страницы НРД
(дефолтные источники — moex-most, программы НРД, криптосервис), парсит
HTML на ссылки .pdf, скачивает новые версии в DOC/ (со старыми
переименовывая в .YYYY-MM-DD.pdf.bak для аудита), и публикует
новость «Обновлена документация: <file>». Sha256-дедуп — пере-импорта
неизменённого PDF не будет.
Cacerts.go: FetchCACertificates теперь принимает *RuntimeConfig и при
успешной переустановке сертификата эмитирует NewsItem «Обновлён
сертификат УЦ: <CN>». Если сертификат истекает в ближайшие 14 дней —
отдельная новость-предупреждение. Это закрывает запрос «получает в авто
режиме и предупреждает об этом» из обсуждения.
SeedDefaultNews публикует при старте bj-server две известные новости:
- TEST3 недоступен 18.05.2026 — 22.05.2026 (НРД письмо НРД-И-2026-8452)
- Робот-автотест MOEX МОСТ доступен на TEST3 с 12.05.2026
Скачаны три свежие инструкции с nsd.ru/services/novye-servisy/moex-most-dlya-m2m/:
- DOC/instruktsiya-po-testirovaniyu-s-robotom.pdf (новая, 12.05.2026)
- DOC/instruktsiya-dlya-osuschestvleniya-obmena-soobscheniyami-...-fizicheskim-litsom-samomu-sebe.pdf (новая, 12.05.2026)
- DOC/servis-most-m2m.pdf (актуальная общая инструкция)
Mastered tasks: #46, #47, #48.
Сканирование смонтированных USB-носителей (/run/media/$USER, /media,
/mnt) на папки вида name.000 с *.key — это «контейнер КриптоПро на
флешке». В шаге 3 wizard'а и в /admin/setup появилась таблица
найденных контейнеров с кнопкой «Скопировать в локальное хранилище»
(копирует папку в /var/opt/cprocsp/keys/$USER/, после чего контейнер
виден как \\.\HDIMAGE\name и работает без вставленной флешки).
Дедуп по AlreadyImported — если папка уже есть в HDIMAGE, кнопка не
показывается. Сертификат из контейнера импортируется отдельно через
certmgr -inst -cont (это пока вне UI, подсказка в текст flash-сообщения).
Кроме того — переписан help-блок в шаге 3 wizard'a на основании
«Инструккия M2M.pdf» (стр. 11, 16-19): явно расписано, что в режиме
ИШ подписывает сам ИШ (наш ключ в ИШ), а в режиме прямого ONYX —
bj-server. Таблица «что куда грузить»: УЦ МБ в mroot, УЦ НРД в
mroot+uRoot, наш сертификат в uMy только если без ИШ. Сертификаты
с Рутокена явно отмечены как «не грузить — сами появятся».
zuevav