Skip to content

Terry

Terry это отдельная documentation zone для будущей data ingestion / ETL + notification platform внутри Kit.

Платформа должна принимать данные из внешних источников, проверять их, нормализовать, сохранять, а затем запускать нотификации по шаблонам и каналам доставки. По сути это конфигурируемый parser runtime с API, асинхронным конвейером обработки и едиными правилами валидации.

Лёгкая note про название: Terry названа в честь Terry из Soul. Это branding детали раздела, а не часть технического контракта.

Current Implementation Baseline

В этой ветке Terry уже перестал быть только documentation narrative.

Сейчас в коде есть первый Terry runtime/config foundation:

  • PostgreSQL catalog в schema terry для workspaces, domains, data_sources и versioned loader_configs;
  • versioned loader configuration model с историей и stats на уровне config version;
  • read-only repository layer для runtime lookup конфигурации;
  • universal LoaderActivity, который запускается по data_source_id, резолвит persisted config и строит execution input.

Это ещё не полный Terry pipeline: write-side config management, transformation runtime, persistence outcome model и notification execution остаются следующими шагами.

Scope

Первый фокус Terry:

  • подключение разных source;
  • запуск ingestion job по API или по расписанию;
  • проверка входных данных через validation rule;
  • нормализация record и применение transformation;
  • сохранение результата в sink;
  • формирование notification template и доставка в delivery channel.

Вне текущего scope:

  • exchange-specific Temporal workflows из существующих разделов docs/workflows и docs/activities;
  • детальная документация по конкретным интеграциям до появления кода Terry runtime;
  • UI/console для конфигурирования, если она появится позже.
  • полноценный Terry admin/write-side для создания и изменения catalog entries.

Reference Pipeline

Во всех Terry-страницах используется одна и та же reference pipeline:

source -> ingestion job -> validation -> transformation -> sink -> notification

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

Vocabulary

  • source — внешний источник данных: API, webhook, file feed, HTML page, queue.
  • ingestion job — конфигурируемый запуск, который знает откуда брать данные и какой pipeline применять.
  • record — минимальная единица бизнес-данных после разбора входного payload.
  • validation rule — правило, которое проверяет record или batch до сохранения.
  • transformation — нормализация, enrichment или mapping из source shape в internal shape.
  • sink — место сохранения результата: DB table, event stream, object storage, downstream API.
  • notification template — шаблон сообщения, связанный с событием или rule outcome.
  • delivery channel — канал доставки нотификаций: email, Telegram, Slack, webhook и т.д.

Reading Order

Design Principles

  • capability-oriented docs вместо списка низкоуровневых runtime артефактов;
  • единая терминология на всех страницах;
  • contracts и lifecycle описываются раньше, чем transport или storage детали;
  • Terry развивается как отдельный bounded context и не смешивается с текущими exchange pipelines.