TF TextFoundry
Вводная презентация

Prompt engineering как управляемая система артефактов

TextFoundry — это desktop-first workbench для хранения, сборки, версионирования, просмотра и controlled AI-assisted редактирования prompt-артефактов, с целевой траекторией в сторону published prompt registry и deterministic render API.

Зачем это нужно Документация Сравнить с DSPy
Проблема

Когда prompts становятся продуктовым активом, хаос быстро накапливается

Во многих командах prompt-логика живёт в чатах, заметках, markdown файлах и строковых литералах. Это удобно только до тех пор, пока prompt не нужно сопровождать как долгоживущий артефакт.

  • Трудно понять, какая версия сейчас считается рабочей.
  • Удачные фрагменты сложно переиспользовать системно.
  • AI-правки смешиваются с ручными правками и теряется контроль.
  • Один длинный prompt плохо сравнивается и плохо эволюционирует.

TextFoundry нужен не для того, чтобы ещё раз вызвать модель. Он нужен для того, чтобы prompt engineering перестал быть хаотичной ручной практикой.

Подход

В центре не один большой prompt, а библиотека управляемых частей

TextFoundry строится вокруг доменной модели, в которой prompt разбивается на переиспользуемые блоки, собирается в композиции и рендерится детерминированно. Следующий шаг этой модели — server-side published registry и render delivery для внешних клиентов.

Block Composition Version Render AI-assisted workflows
1 Создать или изменить блоки и сохранить их как управляемые версии.
2 Собрать композицию из блоков, статических фрагментов и разделителей.
3 Выполнить deterministic render с runtime-параметрами.
4 По явному действию запустить AI generation, slicing, normalization или rewrite.
5 Просмотреть результат и вручную принять или отклонить изменение.
Следующий шаг

Prompt Server как published prompt registry

Целевая серверная траектория продукта — это не generic LLM gateway, а published-only слой, который умеет адресовать версии блоков и композиций, resolve-ить их и отдавать deterministic render по API.

  • Published blocks and compositions становятся server-side сущностями.
  • Backend и Python clients получают единый runtime contract.
  • Authoring и delivery остаются разными поверхностями.
  • Сервер не должен читать drafts и не должен становиться remote editor.
Позиционирование

Где это может быть особенно полезно

  • Когда prompt assets нужно использовать из нескольких сервисов.
  • Когда нужен render по version-aware API, а не чтение markdown-файлов.
  • Когда команда хочет отделить authoring workbench от runtime consumption.
  • Когда нужен prompt registry/render layer вместо самописного prompt storage.
Roadmap

Как TextFoundry превращается из workbench в runtime platform

Следующая траектория продукта теперь выглядит как последовательный путь, а не как набор несвязанных идей про Python и сервер.

  1. Выделить public C++ local surface поверх canonical engine.
  2. Сделать Python local first-class способом работы с тем же semantic contract.
  3. Реализовать Prompt Server как published-only registry, resolve и render boundary.
  4. Добавить C++ remote и Python remote clients поверх одного server contract.
  5. Перейти к hardening, compatibility governance и platform maturity.
Почему порядок важен

Что нельзя перепутать

  • Сначала stabilizing local semantic contract, потом bindings.
  • Сначала server boundary, потом полноценные remote clients.
  • Python не должен оставаться вторичным thin client.
  • Server не должен проектироваться только под convenience bindings.
  • Parity должна измеряться по capability и semantics, а не по буквальной форме API.
Библиотека блоков

Что уже умеет продукт

  • Создание и редактирование блоков.
  • Поиск, просмотр и версионирование.
  • AI generation и AI revise как черновые предложения.
  • Ручной выпуск новой версии вместо скрытой публикации.
Композиции

Управление сборкой prompt

  • Редактор композиции с упорядоченными фрагментами.
  • Version history и controlled save новой версии.
  • Update Blocks To Latest и Compare With Latest.
  • Normalize и Rewrite Blocks как отдельные workflows.
Рендер и просмотр

Проверка итогового результата

  • Raw, Rendered и Normalized preview.
  • Deterministic render без обязательного участия LLM.
  • Runtime parameters, copy и export результата.
  • Qt/QML GUI и FTXUI TUI для рабочих сценариев.
Полный охват

Какие функции уже существуют в продукте

Помимо базового авторинга и рендера, в текущем продукте уже есть отдельные capability, оформленные как самостоятельные workflow с явным контролем пользователя.

  • Block Authoring и Composition Authoring для управляемого создания и версионирования prompt-артефактов.
  • Block Generation для генерации reviewable block draft по инструкции.
  • Prompt Slicing для декомпозиции большого prompt в набор предлагаемых блоков.
  • Normalization для явной семантической нормализации текста и composition.
  • Composition Rewrite для block-preserving rewrite с preview и apply.
  • Update Blocks To Latest для controlled обновления ссылок композиции на latest block versions.
  • Compare With Latest для read-only сравнения выбранной версии композиции с latest published.
  • Render Preview для Raw, Rendered и Normalized preview с runtime params.
Статус

Что уже работает, а что ещё в planned слое

  • Основная рабочая поверхность продукта сейчас — desktop GUI/TUI workbench поверх local engine и storage.
  • Все authoring, slicing, normalization, compare, rewrite и render workflows уже существуют как desktop capabilities.
  • Prompt Server зафиксирован как planned published-only runtime boundary, но ещё не реализован в кодовой базе.
  • Runtime Surfaces описывают целевую модель `C++ local`, `Python local`, `C++ remote` и `Python remote`, но кроме внутреннего `C++ local` слоя они пока не оформлены как продуктовые поверхности.
  • Это важно для честного позиционирования: сегодня TextFoundry — уже работающий workbench, а не готовая server platform.
Особенность

Что делает TextFoundry нетипичным prompt-инструментом

  • Prompt assets хранятся как доменные сущности, а не как случайные тексты.
  • Versioning встроен в модель блоков и композиций.
  • Deterministic render отделён от AI-assisted editing.
  • Human-in-the-loop публикация является нормой, а не исключением.
  • Инструмент проектируется как workbench, а не как тонкая оболочка над API.
Практический эффект

Почему это важно в реальной команде

  • Меньше copy-paste prompt engineering.
  • Меньше неявных расхождений между рабочими версиями.
  • Проще обсуждать изменения как артефакты, а не как «новый длинный текст».
  • AI можно использовать безопаснее, потому что у него нет скрытого commit path.
Сравнение

Почему TextFoundry — это не просто замена DSPy

У этих инструментов есть пересечение, но они решают разные классы задач. DSPy естественно мыслится как framework для программируемой LLM-логики и экспериментов в коде. TextFoundry строится как продукт для управления prompt-артефактами, версиями и authoring workflow.

Где сильнее TextFoundry

  • Asset-centric модель: блоки, композиции, версии.
  • Visual workbench с GUI и TUI.
  • Controlled publishing и review-first workflow.
  • Deterministic render как отдельное ядро.
  • Локальная библиотека prompt assets как first-class объект.
  • Целевая серверная траектория: prompt registry и render API.

Где сильнее DSPy

  • Python-first ecosystem и code-centric orchestration.
  • Более естественная среда для research и optimization workflows.
  • Framework-мышление для module-based experimentation.
  • Встраиваемость в программные LLM pipelines.
  • Более широкий контекст именно для runtime-программирования.
TextFoundry лучше как prompt asset workbench DSPy лучше как Python-centric LLM framework
Практическая польза

Чем продукт помогает команде

  • Превращает хаотичную prompt-базу в обозримую систему артефактов.
  • Упрощает сопровождение длинных system prompts.
  • Позволяет контролируемо использовать AI как редакторский инструмент.
  • Даёт основу для prompt governance, quality review и дальнейшей автоматизации.
  • В целевой траектории даёт общий server-side registry/render слой для нескольких клиентов.
Честная позиция

Что важно не обещать лишнего

  • TextFoundry не является универсальной заменой всех framework-сценариев.
  • Продукт сильнее в authoring and delivery, чем в full-scale research automation.
  • Часть operational и evaluation практик ещё развивается.
  • Prompt Server описан как planned capability, но ещё не реализован в runtime.
  • Python local и remote surfaces уже описаны как целевая capability, но ещё не реализованы как продуктовый слой.
Короткий питч

TextFoundry — это workbench для prompt engineering. Он даёт библиотеку версионируемых блоков, композиции, deterministic render и controlled AI-assisted workflow. В отличие от DSPy, он строится не вокруг Python framework runtime, а вокруг prompt assets, visual authoring и ручного контроля публикации.