Implementation Status

Текущее состояние реализации

Назначение

Этот раздел фиксирует фактическое состояние проекта на текущий момент и служит точкой синхронизации документации перед дальнейшей формализацией через spec kit. Ниже описано не целевое видение, а то, что уже реализовано в кодовой базе.

Снимок проекта

  • Версия проекта: 0.2.3

  • Дата синхронизации: 2026-04-13

  • Основной стек: C++23, CMake, ObjectBox, FTXUI, Qt 6 / QML

  • Основной формат хранения доменных сущностей: versioned Block и Composition

Что уже реализовано

Core engine

Реализован основной движок tf::Engine, который покрывает базовый жизненный цикл доменных сущностей:

  • публикация, обновление, загрузка, перечисление и удаление Block

  • публикация, обновление, загрузка, перечисление и удаление Composition

  • получение последней версии и списка версий для блоков и композиций

  • валидация сущностей перед использованием

  • рендеринг композиций и отдельных блоков

Доменная модель

В проекте есть рабочая модель для:

  • Block с шаблоном, defaults, schema параметров, тегами, языком и описанием

  • Composition с версионированием, StyleProfile, описанием и revision comment

  • Fragment, включая BlockRef, StaticText и Separator

  • детерминированного Renderer с поддержкой StructuralStyle

  • SemanticStyle как отдельного слоя для явных AI-операций

Хранилище

Persistence-слой на ObjectBox уже подключён и используется как основной репозиторий для блоков и композиций. Движок умеет работать с репозиториями через интерфейсы, но штатная инициализация проекта ориентирована именно на ObjectBox.

AI-интеграции

Реализован отдельный модуль textfoundry_ai_openai с OpenAI-compatible адаптерами. На текущий момент в проекте есть:

  • normalizer для семантической нормализации текста

  • block generator для генерации структурированных block draft

  • composition block rewriter для block-preserving rewrite workflow

  • HTTP transport на Qt Network

AI-функции не применяются автоматически во время обычного render-пайплайна и требуют явного вызова соответствующих API движка или GUI workflow.

CLI

Есть отдельное приложение tf на базе CLI11 и FTXUI. В кодовой базе реализованы:

  • команды для работы с блоками

  • команды для работы с композициями

  • render и validate сценарии

  • TUI-вкладки для blocks, compositions, render и settings

GUI

Есть отдельное Qt/QML-приложение tf-gui. На текущий момент в GUI реализованы:

  • страницы Blocks, Compositions, Render, Settings

  • workspace-редактирование блоков и композиций

  • revision-aware сценарии публикации новых версий

  • preview и compare сценарии для composition render / raw prompt

  • workflow Rewrite Blocks с preview и apply

  • настройки AI-подключения: base URL, model, API key, timeout

Сборка и поставка

В проекте уже оформлены:

  • сборка core, AI-модуля, CLI, GUI и примеров через CMake

  • пакетная конфигурация для установки TextFoundryConfig.cmake

  • RPM packaging pipeline

  • desktop integration для Linux GUI-сборки

Тесты

Подключён doctest, есть набор unit/integration-style тестов для core engine и части AI-интеграций. Тестовый таргет сейчас один: core_tests.

Что считается рабочим пользовательским сценарием

На текущем этапе проект уже поддерживает следующий реальный контур работы:

  1. Создание и публикация versioned блоков

  2. Сборка композиции из ссылок на блоки и статических фрагментов

  3. Рендеринг композиции с runtime-параметрами

  4. Редактирование блоков и композиций через выпуск новых версий

  5. AI-assisted генерация и rewrite при явной настройке совместимого API

Ограничения и текущие границы

Следующие моменты важно фиксировать как текущие ограничения реализации:

  • SemanticStyle не является частью автоматического render path

  • AI-возможности завязаны на внешнюю совместимую OpenAI-compatible endpoint

  • публичная документация API (doc/doc.adoc) частично описывает целевой контракт и требует дальнейшей синхронизации с реальными именами методов

  • PRD (doc/prd.adoc) остаётся архитектурным документом и не должен восприниматься как точное описание уже завершённой реализации

Что синхронизировано этим шагом

В рамках первого шага документация приведена к следующему правилу:

  • doc/prd.adoc описывает целевую архитектуру и ограничения

  • doc/status.adoc фиксирует фактическое состояние реализации

  • doc/doc.adoc остаётся слоем API-документации и будет синхронизироваться отдельно по мере следующих шагов