Как устроен бот

Эта глава объясняет логику работы без программных деталей: откуда берутся цифры, зачем пресеты и почему иногда расчёты запускаются «сами».

Две «складки» настроек

1. Карта чата — дата/время рождения, координаты, аянамша (и связанные поля). Это источник истины для натальных расчётов.
2. Пресеты (/presets) — ваши предпочтения по школам и опциям для отдельных инструментов (варги, йоги, шадбала и т.д.). Они хранятся отдельно и подмешиваются при каждом вызове соответствующего расчёта.

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

Кто запускает расчёты

• Диалог с ботом / агентом — модель или сценарий решают, какой инструмент нужен (например, «посчитай дашу»), и передают аргументы.
• Автоматический префетч (предзагрузка) — после появления новой карты для чата бот может заранее прогнать ядро расчётов (шадбала, йоги, варги, даша, авастхи и др.), чтобы ответы и натальный паспорт опирались на готовые слепки, а не на урезанный набор.

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

Три слоя паспорта (натал + периодика + ремедии)

В агенте для одной и той же сохранённой карты (чат + «отпечаток» geo) могут одновременно подмешиваться три независимых JSON-слоя. Это не три копии одного документа, а разные роли контекста.

1. Натальный астро-паспорт (основной)

Структурированное резюме натала: лагна, планеты по знакам и домам, краткие списки йог и т.д. Сюда же кодом подмешиваются жёсткие блоки (то, что не «придумал» текст модели): например ганданта, ишта/кашта из шадбалы и другие вычисленные вставки.

Для вас:

• Любые цифры и флаги из этого слоя и из логов расчётов — опорные.
• Связный текст «интерпретация» внутри паспорта — тоже должен не противоречь статике карты.

2. Слой периодики (тайминг / прогноз)

Отдельная запись в базе (последняя по этой карте), смысл — сроки, годы, варши, сводки прогноза, а не базовый натал.

• В JSON может быть своё поле period_key (например, день day:…, месяц month:…, неделя week:…, солнечный год varsha:…) — чтобы разные горизонты не затирали друг друга без нужды.
• В промпт модели попадает не весь JSON подряд, а компактная выжимка: сводки summary_* / digest_*, при необходимости короткий interpretation.

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

Если пользователь спрашивает про год, а слой пустой или про другой период — нужен свежий расчёт под этот год, а не догадки.

3. Слой ремедий (чакры, камни, духовка)

Ещё одна отдельная последняя запись: ремедиальная линия — чакры, камни, мантры/ракурты, если вы их заполняете в продукте. В промпт снова уходит урезанная выжимка, чтобы не раздувать контекст.

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

Как это читать вместе

Супервизор видит три блока подряд: натал → периодика → ремедии (если для карты что-то сохранено). Для бытового объяснения пользователю:

Слой	Вопросы, на которые опирается
Натальный	Кто я по карте, структура, йоги, сила
Периодика	Что сейчас за фаза/год/варша, куда смотреть по времени
Ремедии	Чакры, камни, «что делать мягко» в духовной/ремедиальной логике

(В CRM может быть отдельный «паспорт клиента» для карточек клиентов — это другая сущность, не эти три слоя чата.)

Handyman и один раз vs всегда

Удобная модель мышления:

• Пресеты — «как я хочу считать обычно».
• Параметры одного запуска (если интерфейс это позволяет) — «только сейчас переопредели вот это поле».

Пустой набор переопределений означает: всё как в пресетах и дефолтах.

Библиотека

Поиск по книгам (семантический и текстовый) — отдельная ветка: карта может быть не нужна, зато нужны запрос и при семантическом поиске — разумная формулировка (желательно с санскритскими терминами в IAST там, где это важно).

См. tajika-library-chakra.md.

CRM и два человека (кута, нади)

Для совместимости (ашта-кута, нади) бот может взять второго человека из базы клиентов по имени или подставить координаты из формы. Первым партнёром часто остаётся текущая карта чата. Точные сценарии зависят от того, как у вас настроен клиентский слой; если что-то не срабатывает — проверьте, что карта сохранена и имена клиентов существуют в базе.