🧩💬 Dev Studio вынесла Architect chat из двух гигантских корневых файлов и перестала чинить его кувалдой через App.tsx
В dev-контуре tricode2 пошёл важный, но внешне не очень глянцевый апдейт: Architect chat начали выносить из старой схемы, где слишком много логики годами копилось в двух огромных корнях — App.tsx и orchestrator.py.
Снаружи это выглядит не как “новая фича”, а как инженерная санитария. Но именно такие апдейты потом определяют, сколько ещё месяцев команда будет чинить чат кувалдой в одном файле на полэкрана и почему любой точечный фикс неожиданно цепляет соседние сценарии.
Что именно разрезали
На фронтенде появился более внятный домен architect-chat. Туда начали переносить то, что раньше жило слишком близко к общему корню приложения:
- очередь сообщений;
- interrupt-before-send логику;
- превращение chat-сообщений в plan-from-chat сценарии;
- chat mutation flow.
На бэкенде отдельный домен architect_chat начал забирать свою часть ответственности:
- правила addendum approval / reject / postpone / cancel;
- recovery для plan approval state;
- recovery addendum task-состояний;
- сохранение architect action proposals.
Параллельно в сторону workspace-домена поехали куски bootstrap loader и селекторы empty-state. То есть Studio медленно, но всё же перестаёт жить в режиме “вся логика мира в одном месте, удачи следующему, кто это откроет”.
Почему это важно, если интерфейс почти не меняется
Потому что самые неприятные регрессии в Architect chat часто рождаются не из “сложных AI-проблем”, а из банального архитектурного перекоса: когда один и тот же корневой файл держит слишком много несвязанных обязанностей, любое локальное изменение становится лотереей.
Теперь расчёт простой:
- фиксы вокруг Architect chat должны становиться более локальными;
- правки меньше тянут за собой случайные побочные эффекты;
- workspace bootstrap и Architect chat получают шанс развиваться как отдельные домены, а не как приложение, прикрученное к двум историческим комбайнам.
Что это значит для dev-контура
Это именно dev-архитектурный апдейт. Он не обещает немедленной магии на уровне публичного API и не продаётся как редизайн продукта. Его смысл в другом: перестать складывать новую логику в те же старые монолиты и подготовить нормальную основу для следующих фаз domain split.
Если говорить совсем по-человечески, команда начала платить старый инженерный налог не в режиме “потом как-нибудь”, а сейчас. Да, пользователь не получает праздничный салют. Зато Studio получает меньше шансов снова споткнуться об очередной случайный комок логики в App.tsx.
Что дальше
Эта фаза — не финал и не большой продуктовый перезапуск. Это первый взрослый шаг к схеме, где:
workspaceживёт своим доменом;architect chatживёт своим доменом;- новые фиксы попадают по адресу, а не в общий контейнер “ну где-то в корне приложения”.
Именно поэтому обновление важно: оно не добавляет декоративный слой, а уменьшает вероятность будущих поломок в одной из самых чувствительных частей Studio.