Book-as-context: проектирование сложной архитектуры с ИИ через подложку из книги

Проблема

Если сказать Claude или Cursor «сделай передачу заказов из интернет-магазина в ERP» — на выходе будет наколеночный файловый обмен по FTP и рапорт «готово». Дальше разработчики смеются и делают вывод «ИИ не тянет архитектуру».

Причина не в модели. Модель опирается на «среднюю температуру по интернету» — усреднённый код из открытых источников, где production-grade интеграции встречаются реже, чем туториалы. Без предметной базы агент не знает, что правильный ответ здесь — event-driven с гарантиями доставки, idempotency (идемпотентностью) и согласованностью данных между системами. На уровне intake ту же дыру закрывает clarify gate в Jira (#11): пока в тикете нет цели, scope и AC, задача не уходит в разработку.

Сквозной пример: магазин → ERP

Один и тот же класс задачи, два разных результата.

Без подложки: «Сделай передачу заказов из интернет-магазина в ERP» → CSV, cron, FTP, «готово».

С wiki Таненбаума — реальная постановка: интеграция 1С-Битрикс → ERP «Галактика» → CRM Creatio. Агент идёт по графу концептов:

«ERP может быть недоступна часами, заказы не должны теряться»
  → message-oriented middleware (MOM):
    persistent communication — очередь хранит сообщение до доставки
    vs transient communication — получатель должен принять прямо сейчас
  → message queue systems — не email: гарантии доставки, журнал, балансировка
  → AMQP: unsettled → settled → forgotten — три шага фиксации доставки
  → two-phase commit (2PC) — если две БД должны обновиться атомарно

Что реально вышло на выходе

Фрагмент реального ТЗ: агент с wiki-подложкой по задаче 1С-Битрикс → ERP «Галактика» → CRM Creatio.

Источник событий — Битрикс после фиксации заказа. Событие фиксируется через transactional outbox, преобразуется в каноническую модель и попадает в персистентный брокер. Адаптеры асинхронно доставляют данные в ERP и CRM; сквозное состояние — в журнале интеграции. Повторы — через idempotency, экспоненциальный backoff и DLQ; порядок изменений одного заказа сохраняется по causal ordering (причинному порядку событий).

Логическая схема из §7.1:

[ИМ 1С-Битрикс] --(Outbox/событие)--> [Интеграционный сервис]
                                      |
                    Канонизация, валидация, обогащение НСИ
                                      |
                         [Брокер сообщений (персистентные очереди)]
                         /                              \
            [Адаптер ERP «Галактика»]          [Адаптер CRM Creatio]
                         \                              /
                          `--> [Журнал состояний / сквозная БД] <--'

Приоритет транспорта к ERP — файловый обмен не основной путь:

SLO и отказоустойчивость (§6.1)

Частичный успех ERP + CRM (§12.3)

eventual consistency — конечная согласованность без автоматического two-phase commit.

• Инвариант: успешная запись в целевой системе не откатывается автоматически.
• ERP принял, CRM временно недоступна → повторы в CRM с тем же idempotency key; ERP не трогаем.
• ERP принял, CRM исчерпала повторы → partial success, событие в DLQ, алерт.
• ERP недоступна → повторы к ERP; CRM не вызывается до первичного успеха ERP.

Безопасность каналов (§8)

• TLS 1.2+ на всех каналах; mTLS между компонентами интеграции.
• Webhook от ИМ: HMAC или JWS + защита от replay (nonce, окно 5–15 мин).
• Rate limiting, лимиты размера сообщений; переполнение очередей → DLQ + алерт.

Traceability: wiki → ТЗ (Приложение А)

В §1.2 документ ссылается на wiki: middleware вместо point-to-point, failure models, семантика повторов (at-least-once и т.п.). Запрещённые предпосылки из §6.2 — fallacies of distributed computing: «the network is reliable», «latency is zero», «topology never changes».

Методика

Заземлить агента на конкретную авторитетную книгу по предметной области.

1. 1. Выбор книги. Под архитектуру / хайлоад / событийку — Таненбаум, «Распределённые системы: принципы и парадигмы». Это уровень «как Котлер у маркетологов»: жёсткий сопромат с формулами.
2. 2. Нарезка в wiki. Пайплайн olw (obsidian-llm-wiki): fast-модель на ingest, heavy на compile. На текущем прогоне по Таненбауму: 30 source-чанков → 116 concept-страниц в .drafts/.
3. 3. Параметры. Несколько итераций по чанкам / токенам / моделям. Стоимость полного прогона — порядка $1.5 через OpenRouter. Три прогона olw дали 16 + 14 + 23 note(s).
4. 4. Подкладка в проект. Wiki кладётся в репозиторий. Агент ходит по индексу — через hybrid-search MCP (разбор #02) либо индексацию Cursor. Контекст не деградирует: агент бегает по файлам, не загружая книгу целиком в окно.
5. 5. Агентный слой поверх поиска. Wiki + retrieval — инфраструктура. Поверх — query routing, интерпретация scores, traversal от бизнес-требования к паттерну. Запросы формулируются в терминах автора:

   Плохой запрос	Хороший запрос (термин автора + plain language)
   «найди что-то про Kafka»	reliable multicast + FIFO ordering — порядок доставки и надёжная рассылка
   «как синхронизировать заказы»	persistent vs transient communication — очередь хранит vs получатель online сейчас
   «гарантии доставки»	AMQP: unsettled → settled → forgotten — три состояния фиксации доставки

6. 6. Эффект. Планы работ, API-контракты, инфраструктурные решения и вайб-кодинг идут через оптику книги. Уровень держится «с одного промпта».

Механика переносима: wiki — текст, копируется между проектами. Под разные фазы — разные книги: «Чистый код» на разработке, Фаулер на ревью, Савин на QA.

Анатомия vault'а: три слоя

Реальная структура каталога tanenbaum/wiki/:

tanenbaum/wiki/
├── raw/tanenbaum-full_rag_00012.md            # чанк книги + YAML
├── wiki/sources/Tanenbaum Full_Rag_00012.md   # summary + Concepts
├── wiki/.drafts/Передача сообщений.md          # concept-статья
├── wiki/index.md                               # индекс 30 источников
├── wiki/log.md                                 # журнал прогонов olw
└── wiki.toml                                   # модели, ctx, language

Слой 1 — raw-чанк

rag_chunk: 12
rag_total_chunks: 30
rag_chunk_size: 51542
rag_overlap: 800

Слой 2 — source-страница

Concepts (оглавление чанка у автора): IBM WebSphere MQ, message channels, routing tables, message transmission — агент видит индекс до чтения полного текста.

Слой 3 — concept-статья

Фрагмент wiki/.drafts/Передача сообщений.md:

Системы очередей сообщений обеспечивают гарантированную доставку,
приоритеты, ведение журналов, [[балансировку нагрузки]] и [[отказоустойчивость]]
[[Tanenbaum Full_Rag_00012]].

Процесс передачи сообщений в [[AMQP]] включает три этапа:
1. Сообщение в "неустановленном состоянии" на отправителе и сервере.
2. Получатель обработал → "установленное состояние".
3. Отправитель забывает о сообщении, получатель формально отмечает settled
   [[Tanenbaum Full_Rag_00012]].

## See Also
[[Модели с ориентацией на сообщения]] · [[Двухфазный протокол фиксации]]
· [[Tanenbaum Full_Rag_00012]]

Перекрёстные ссылки важны: агент идёт от «заказы не должны теряться» к persistent communication (очередь хранит сообщение), дальше к состояниям доставки AMQP (unsettled → settled), и только потом — к Kafka/RabbitMQ как реализации.

Frontmatter + quality flags:

confidence: 0.35
status: draft
sources:
  - raw/tanenbaum-full_rag_00012.md

<!-- olw-auto: low-confidence (0.35) — verify before publishing -->
<!-- olw-auto: single-source — cross-reference recommended -->

Параметры прогона

Из wiki.toml реального vault'а:

fast = "google/gemini-2.0-flash-lite-001"   # ingest
heavy = "google/gemini-2.5-flash"           # compile
fast_ctx = 24000                            # ≈ 12k символов на чанк
max_concepts_per_source = 25
language = "ru"

Пайплайн olw: raw/ → ingest → compile → lint → approve. Команда: olw run.

Артефакт

Инструмент: obsidian-llm-wiki (форк) — локальный пайплайн Karpathy-style LLM Wiki.

• Вход: PDF или текст книги, чанки в raw/
• Выход: Obsidian-vault с wikilinks и source traceability
• Retrieval: obsidian-hybrid-search как MCP (разбор #02)
• Applied: Kafka = 2PC, outbox (разбор #09)

olw init my-book-wiki
# положить чанки в raw/
olw run

Для кого и почему

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