Строю системы, где деньги должны сходиться.

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

Ядро вынесено в отдельный переиспользуемый модуль: двойная запись, счета, HD-кошельки, депозиты и выводы по четырём сетям, сверка с блокчейном, комиссии, compliance-скрининг. Над ядром — спотовый стакан и prediction-маркет. Приватные ключи не лежат в приложении: подпись изолирована в отдельный сервис. Аутентификация и персональные данные вынесены в самостоятельный сервис — биржа их не хранит вовсе.

Интерфейс — отдельное веб-приложение на Next.js, которое на телефоне должно ощущаться приложением: 80 000 строк TypeScript, 775 тестов, типизированный клиент сгенерирован из спецификации бэкенда, а расхождение версий контракта ловится проверкой на сборке.

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

Открыть лист целиком →

Рис. A-1Сверка резервов на демонстрационных данных: по каждому активу обязательства реестра против того, что лежит в сети, а переводы в пути, комиссии, средства платформы и неопознанные монеты вынесены отдельными колонками — поэтому каждая строка складывается в свой остаток, а не просит поверить. USDT сходится, по BTC необъяснимый избыток, по ETH недостача, и выводы заморозились автоматически.

Задача: партнёрским сетям нужно принимать платежи с опознанием источника и платить сотням получателей пачками — без ручных переводов по одному.

Множественные адреса приёма с атрибуцией, учёт остатка, пачки выплат как центральная сущность, повторяющиеся списания, скрининг входящего. Шесть монет в восьми парах «монета × сеть»: сумма, валюта и сеть всегда ходят вместе — валюта без сети здесь неполная величина, и это правило зашито в модели данных, а не в договорённости.

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

Три правила, которые соблюдает этот прогон, — те, что дорого узнавать на практике. У непрошедшей строки остаётся прежний ключ, поэтому повторная загрузка не может создать второй платёж. «Ушла, подтверждения нет» — единственное состояние, которое система отказывается повторять: деньги уже могли уйти. А поиск платежа находит точное совпадение или ничего — правдоподобный неверный платёж хуже ненайденного.

Открыть лист целиком →

Рис. A-2Пробный прогон, до того как что-либо уйдёт. Уйдут 487 строк, получатели получат 12 480,25 USDT, а со счёта спишется 12 967,25 — комиссия берётся сверх каждой строки, а не внутри неё. Тринадцать строк не уйдут: шесть адресов принадлежат другой сети, семи не хватает средств, и каждая называет, сколько ей было нужно против того, сколько оставалось. Тестовый стенд — суммы не настоящие.

Открыть лист целиком →

Рис. A-3Строки, которые не прошли, и что консоль с ними делает. Деньги ни по одной из трёх не двигались, поэтому их можно загрузить заново — ключ строки прежний, а уже отправленная строка не повторяется никогда. Внизу единственное состояние, которое система отказывается повторять: исход отправки неизвестен, средства остаются удержанными, и разбирается это по хэшу транзакции, а не повторной отправкой. Тестовый стенд.

Открыть лист целиком →

Рис. A-4Приём с атрибуцией по источникам — у каждого источника свой адрес в каждой сети, из которой он платит, поэтому деньги опознают себя самим фактом зачисления, а ключ загрузки не меняется никогда: именно он сводит итог по партнёру при переименованиях. Поиск находит точное совпадение и не угадывает — правдоподобный неверный платёж хуже ненайденного. Тестовый стенд.

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

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

Один принцип держит всё остальное: модель — первоисточник. Помесячный денежный поток, аналитика, налоговая декларация и справка к разговору с банком — производные от неё: их можно выбросить и пересобрать, модель — нельзя. Деньги ходят строками и считаются на Decimal, никогда через float. Типы API на фронте генерируются из OpenAPI-схемы бэкенда, поэтому смена версии контракта ломает сборку, а не чей-то экран. Прогресс длинных задач идёт по SSE, а не по WebSocket: WebSocket потребовал бы токен в query-строке, а оттуда он попадает в логи. Год работы; внутренний продукт, два продакшн-стенда, публичной регистрации нет.

Открыть лист целиком →

Рис. A-5Модель отказывается делать вид, что сойдётся. Из заказанных ₽19 821 470 разместить удастся ₽17 575 600; недобор в ₽2 245 870 разложен по контрагентам, и у каждого названо ограничение, которое пришлось бы сдвинуть. Замечания ниже прямо говорят, что выплатить излишек владельцу уже некуда. Выдуманный бизнес на засеянных цифрах.

Открыть лист целиком →

Рис. A-6Тот же бизнес по месяцам на два года вперёд: сначала обязательный пол — аренда, зарплата и налог с неё, прибыль владельца, банковское обслуживание, а квартальный налог по режиму даёт стопке пилообразный край, — затем лимит трат этого месяца поверх него и остаток запаса до потолка. Полоска под каждым столбцом называет, чем месяц связан: месячным лимитом или тем, сколько способны принять поставщики.

Задача: менеджеры вручную вычитывали PDF кредитных историй из трёх разных бюро и переносили данные в таблицы и карточки сделок. Нужно было убрать ручной этап целиком.

Вебхук из AmoCRM попадает в очередь, воркеры забирают PDF с Google Drive, разбирают форматы трёх бюро — НБКИ, Credistory, Scoring, — сводят результаты в одну картину, заполняют семь блоков рабочей таблицы и возвращают итог заметкой в сделку. Отдельным потоком карточка лида обогащается данными по компании из внешнего реестра. Часть документов — сканы, поэтому в пайплайне есть распознавание текста.

Это второе поколение. Первое было одной большой системой — 444 коммита, 96 500 строк, вместе с ботом, аналитикой и работой с таблицами — и тестов в ней почти не было. Она работала, но менять её было страшно. Поэтому конвейер я вынес в отдельный сервис и переписал, и на этот раз тесты шли первыми. Два поколения вместе: 735 коммитов, около 213 000 строк.

Задача: единственная точка в системе, которая выпускает пользовательские токены, — чтобы остальные сервисы не хранили ни паролей, ни персональных данных.

Вход через Telegram, сессии, токены на эллиптической подписи с публичным набором ключей для проверки соседними сервисами, ключи доступа без пароля (WebAuthn), одноразовые коды, хеширование Argon2, профили и роли, хранение персональных данных в одном месте, связка внутренних идентификаторов с денежными счетами.

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

Задача: когда над одной системой работают несколько AI-агентов в разных репозиториях, им нужен способ договариваться — иначе каждый чинит границу по-своему.

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

На этом инструменте построена реальная разработка: пять ролей — деньги, вход, редакция, фронт, инфраструктура — с уставом команды, границами владения репозиториями и правилом «контракт согласовывается до кода».

Он открыт и лежит под MIT. Но чтобы судить, как я пишу код для систем, где лежат деньги, начинать стоит не с него, а с ledger-reconcile: 2 177 строк библиотеки и команды плюс 3 002 теста, которые находят тринадцать из четырнадцати режимов расхождения из разбора, честно называют четырнадцатый недостижимым и сообщают, чего прогон проверить не смог.