FTS: зачем разработчику исполняемая спецификация

FTS — не замена TypeScript, React, Node.js или базе данных. Это маленький язык для той части системы, которую команда обычно пишет трижды: человеческое бизнес-правило в задаче, реализацию в коде и примеры в тестах.

категория «Продажи»

  объект Покупка
    сумма является деньгами

  утилита «Рассчитать скидку»
    принимает Покупка
    возвращает деньги
    начинает с 0

    правило «Большая покупка»
      если сумма не меньше 10000
      то добавить 10 процентов от поля сумма

    пример «Покупка на двадцать тысяч»
      дано сумма равна 20000
      ожидается результат равен 2000

Такой файл можно:

• проверить командой fts check;
• исполнить как чистую утилиту через fts run;
• использовать как набор новых предметных unit-тестов через fts test;
• превратить в TypeScript и node:test через fts generate;
• скомпилировать в канонический JSON для React, Python, Go или агента;
• связать с фактическим snapshot и получить проверяемый сертификат.

Где появляется ценность

Представьте обычную задачу: «постоянный клиент получает ещё 5%, но суммарная скидка не должна быть больше 20%». Аналитик пишет текст, middle-разработчик — ветвления, QA — тест-кейсы, frontend — похожую логику для preview. Через полгода четыре версии расходятся.

В FTS правило, постусловие и контрольные примеры находятся рядом. Backend может исполнить его напрямую, frontend — прочитать структуру, CI — выполнить примеры, а агент — предложить изменение и отдать его тому же компилятору. Ценность не в том, что синтаксис короче TypeScript. Ценность в одном проверяемом источнике предметного решения.

Где FTS не нужен

Не переносите в FTS всё приложение. Цикл React, SQL-запрос, retry HTTP-клиента, транзакция и отправка письма остаются обычным кодом. Хорошая граница выглядит так:

1. приложение читает данные;
2. FTS принимает скалярный snapshot и вычисляет решение;
3. приложение проверяет результат;
4. только затем приложение выполняет внешний эффект.

Если правило невозможно сделать детерминированным или его проще выразить тремя строками, которые никогда не дублируются, FTS может быть лишним.

Маршрут курса

Курс идёт от механики к production:

1. Модель и границы языка.
2. Установка и канонический JSON.
3. Русская и английская запись.
4. Структуры и типы.
5. Утилиты, правила и свойства.
6. Примеры как новый вид unit-теста.
7. Node.js и HTTP.
8. React и формы.
9. DDD и command guards.
10. AI-агенты, Digit и MCP.
11. Доказательства и сертификаты.
12. Интеграция с любым языком.
13. Генерация и CI.
14. Производительность.
15. Сквозной проект «Исполнение заказа».

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

Дальше: модель и границы языка