Что идёт после MVP, собранного на вайбе

Задача

«Работает. Люди пользуются. И между этим всем и падением стою только я».

Задача прототипа — выяснить, нужна ли кому-то вообще эта штука. Пока задача такая, прототипу можно держать пароли в .env, иметь единственный путь выкатки, который работает только с вашего ноутбука, и бэклог, который живёт у вас в голове. Выкатить его именно так было правильным решением — благодаря этому у него и появились пользователи.

Как только пользователи появились, эти три вещи перестают быть сокращением пути. Дальше продукту нужен не код. Ему нужна выкатка, через которую любое изменение проходит без вашего участия; окружение, достаточно похожее на продакшен, чтобы на нём имело смысл проверять; секреты где-нибудь, кроме репозитория; и кто-то, кто продолжает делать следующую фичу, пока всё это приводится в порядок.

Это инженерная функция, и обычно выбор такой: быть ею самому по ночам, нанять сильного инженера, который пока не по карману, или взять fractional CTO на несколько часов в неделю. Forge — четвёртый вариант, и он состоит из двух половин: выкатка, которую вы себе ставите, и команда, которая работает так, как работает команда, — в вашем репозитории, через pull request’ы, с ревью перед тем, как что-то попадёт в main.

Половина про выкатку

Forge выкатывается через sc, Simple Container — то же открытое ядро, которым он выкатывает сам себя.

• Одно декларативное описание на сервис. Что это, где это работает, что ему нужно. Отдельный самописный конвейер под каждый сервис не нужен.
• Ваш облачный аккаунт. Разворачивает в Amazon, Google, Yandex Cloud, Kubernetes или на ваших собственных серверах. Аккаунт, данные и счёт остаются вашими.
• Секреты перестают жить в репозитории. Они лежат в зашифрованном реестре и расшифровываются в момент выкатки: в коммитах нет ничего читаемого, и .env больше не надо никому передавать.
• Окружение на каждое изменение. Полную копию сервисов можно поднять на отдельном поддомене, проверить и снести — об этом изолированные стенды .
• Проверять можно не по нашему слову. Лицензия MIT, OpenSSF Best Practices Gold со всеми выполненными критериями, Scorecard 10/10. То, что выкатывает ваш продукт, можно прочитать.

Половина про команду

Знакомая цепочка, но между каждыми двумя шагами стоит валидатор:

От «направить ассистента на тикет» это отличается прежде всего валидатором на переходах. Каждую передачу читает управляющий агент и решает, должна ли следующая роль её получить. Если нет — работа возвращается с конкретными указаниями, а не уезжает дальше, чтобы стать чужой проблемой.

Второе отличие — всё записано. Результат каждой роли — коммит в ветке прогона, поэтому обоснования, отклонённые попытки и вердикты лежат там же, когда вы открываете pull request. Вы ревьюите не вывод чёрного ящика: видно, как он к нему пришёл, и можно вмешаться посреди прогона, закоммитив исправленную передачу самому.

Третье — вливает человек. Автоматическое влитие есть, включается отдельно и ограничено бюджетом автономии, но по умолчанию кнопку нажимаете вы.

С чего начать

Две вещи, в таком порядке, и ни одна из них не переписывание с нуля:

1. Один сервис, одно окружение. Опишите то, что у вас уже работает, и выкатите это через sc один раз. После этого выкатка — команда, а не вечер, и окружение на каждое изменение идёт в комплекте.
2. Один хорошо описанный тикет. Направьте на него цепочку разработки и прочитайте pull request, который она откроет: ветку, коммиты с передачами, вердикты, которые вернули работу назад. Это честная мера того, подходит ли вам такой способ.

Из расплывчатого тикета выйдет расплывчатый pull request: шаг продакта вытаскивает неоднозначность наружу, а не придумывает ответ за вас. Это правильно — но да, сначала она вернётся к вам.

Чем это подтверждается

Самое сильное подтверждение, которое у нас есть, — так собирается сам Forge. Автономный драйвер читает наш роадмап, берёт следующий готовый к работе пункт, запускает на нём эту же цепочку, и полученный pull request вливается в репозитории самой платформы. Сервисы, из которых платформа состоит — control plane, AI-шлюз, рантайм, хранилище, уведомления, — выкатываются тем же ядром sc: в Amazon, а там, где работа должна остаться в России, — в Yandex Cloud.

Эти репозитории закрытые, поэтому мы не будем делать вид, что вы можете пойти и всё проверить сами. Что мы можем — провести вас по реальным прогонам: ветка, коммиты, вердикты, которые вернули работу назад, и те, что подняли вопрос человеку. Это тот же код, который будет работать у вас, и показать лучше его, чем бенчмарк.

Что под капотом

• От тикета до отревьюенного pull request — цепочка разработки подробно
• Многоагентный конвейер — роли и валидатор между ними
• Изолированные стенды — одноразовое окружение, на котором изменение себя доказывает
• Аудит на основе git — почему запись — это коммиты, а не дашборд
• Секреты и исходящий трафик — где лежат доступы и до чего агент может дотянуться
• Наблюдаемость — логи и метрики по каждому ходу любого прогона
• Действенные уведомления — где прогон обращается к вам, когда нужно решение