Roadmap: Runtime Surfaces и Prompt Server

Этот документ нужен как единая дорожная карта по развитию TextFoundry из desktop workbench в multi-surface runtime platform.

Он связывает три линии развития:

  • C++ local как canonical public local surface

  • Python local как first-class local bindings layer

  • Prompt Server и language-specific remote clients

1. Цель roadmap

Roadmap должен ответить на четыре вопроса:

  • в каком порядке развивать local и remote surfaces;

  • что является обязательной базой для следующего этапа;

  • что можно считать MVP, а что уже относится к более зрелой платформенной стадии;

  • где проходит критический путь, а где можно вести работу параллельно.

2. Исходная точка на April 16, 2026

Что уже есть:

  • canonical implementation в C++ engine

  • desktop workbench поверх local engine

  • модель Draft / Published

  • deterministic render semantics

  • подробные docs по Prompt Server и Runtime Surfaces

Чего ещё нет:

  • оформленного public C++ local SDK

  • Python local bindings

  • Prompt Server runtime

  • C++ remote client

  • Python remote client

3. Принцип этапности

Roadmap строится вокруг простой идеи:

  • сначала нужно стабилизировать local semantic contract;

  • потом можно безопасно расширять его на Python local;

  • только после этого стоит фиксировать first server runtime;

  • remote clients должны идти после server boundary, а не определять её заранее.

Это снижает риск:

  • случайно спроектировать server под convenience bindings;

  • спутать authoring-capable и published-only boundary;

  • начать обещать parity до того, как определён supported subset.

4. Этапы roadmap

Фаза 0. Документальная фиксация

Статус:

  • уже выполнена.

Что вошло:

  • function-level набор Runtime Surfaces

  • function-level набор Prompt Server

  • matrix по C local / Python local / C remote / Python remote

  • explain-документы по sync strategy и MVP

Результат:

  • тема перестала быть "одним длинным ADR";

  • архитектурная ставка и product scope теперь согласованы.

Фаза 1. Public C++ local surface

Цель:

  • выделить supported public local contract поверх существующего engine.

Ключевые работы:

  • определить, какие engine operations входят в public supported set;

  • отделить public contract от GUI-oriented helper paths;

  • описать compatibility expectations;

  • подготовить golden fixtures для render/version/error semantics.

Критерий завершения:

  • есть понятный public C++ local contract, пригодный для parity baseline.

Фаза 2. Python local MVP

Цель:

  • сделать Python first-class local surface поверх того же semantic contract.

Ключевые работы:

  • выбрать binding technology;

  • отразить supported local subset в Python;

  • проверить local parity по golden fixtures;

  • описать packaging/distribution story.

Критерий завершения:

  • Python local покрывает agreed local subset без semantic drift.

Фаза 3. Prompt Server MVP

Цель:

  • реализовать published-only remote boundary.

Ключевые работы:

  • выбрать first server topology;

  • реализовать registry/resolve/render path;

  • закрепить published-only policy тестами;

  • оформить authn/authz и compatibility policy в минимально достаточном виде.

Критерий завершения:

  • server умеет published-only registry + resolve + render.

Фаза 4. C++ remote и Python remote

Цель:

  • сделать оба языка first-class remote consumers одного server contract.

Ключевые работы:

  • реализовать typed client для C++;

  • реализовать idiomatic client для Python;

  • проверить remote parity;

  • формализовать compatibility matrix client/server.

Критерий завершения:

  • обе remote surfaces покрывают один и тот же supported remote contract.

Фаза 5. Platform hardening

Цель:

  • перевести capability из MVP-состояния в устойчивый platform layer.

Ключевые работы:

  • hardening release process;

  • расширение regression suite;

  • улучшение deployment/runtime story;

  • observability, incident handling и compatibility governance.

Критерий завершения:

  • продукт пригоден не только для первого пилота, но и для повторяемой эксплуатации.

5. Критический путь

Критический путь выглядит так:

  1. Runtime Surfaces docs

  2. public C++ local contract

  3. Python local MVP

  4. Prompt Server MVP

  5. C++ remote и Python remote

Почему именно так:

  • без local contract непонятно, что именно должно быть parity baseline;

  • без Prompt Server нет remote boundary;

  • remote clients не должны диктовать форму server contract.

Параллельно можно вести:

  • evaluation fixtures;

  • compatibility policy draft;

  • packaging research;

  • deployment research;

  • security review preparation.

6. Рекомендуемая MVP-граница

Если резать scope жёстко, то MVP стоит считать достигнутым в точке, где есть:

  • public C++ local surface

  • Python local MVP

  • published-only Prompt Server

  • один минимальный remote client, лучше Python remote

Если хочется более симметричного MVP, то можно считать MVP завершённым только при наличии:

  • C++ remote

  • Python remote

Но это уже более тяжёлый и менее быстрый первый релиз.

7. Mermaid Gantt

Diagram

8. Карта зависимостей

Diagram

9. Основные риски roadmap

  • слишком рано начать server implementation без stabilizing C++ local contract

  • выбрать binding strategy до фиксации supported local subset

  • смешать rollout Python local и Python remote

  • сделать server authoring-capable раньше, чем доказан published-only MVP

  • не выделить ownership на parity review

10. Что обновлять вместе с roadmap

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