🤖🛠 tricode2 перестроила сам рефактор: теперь доменные slices режут параллельно, а root-файлы трогает только integration owner
Главная проблема большого domain refactor в tricode2 была довольно приземлённой: слишком много логики осело в apps/frontend/src/App.tsx и apps/backend/studio/orchestrator.py. Пока вся команда или все агенты вынуждены возвращаться в одни и те же корневые файлы, безопасный параллелизм быстро превращается в красивую сказку про merge-conflicts и patchwork code.
Поэтому в текущем цикле поменяли не только структуру кода, но и сам workflow. Теперь refactor идёт по модели, где сначала выделяют доменные slices, потом режут работу на serial spine, parallel workers, final root integration и guardrails.
Как это выглядит на практике
Каждый сабагент получил свою зону ответственности и свой write scope:
- Boole — runner frontend;
- Nash — runner backend;
- Mill — platform-ops frontend;
- Boyle — admin frontend;
- Cicero — platform-ops backend;
- Copernicus — admin-config backend.
При этом integration owner сохраняет serial control над workspace_run, root integration и проверкой результатов каждого worker slice. То есть никакой “свободы для всех” в корневых файлах нет: наоборот, именно root-файлы теперь защищены строже всего.
Почему это снижает риск
Потому что вместе с write scope агент получает контракт: changed files, verification, handoff notes, ограничения по корню. Если worker внезапно начинает лезть туда, куда ему не назначали ownership, такой результат просто не должен приниматься как нормальная часть batch.
Это даёт очень практический эффект:
- меньше хаоса при параллельной работе;
- меньше случайных столкновений в корневых слоях;
- лучше читается ownership доменов;
- проще review-ить и интегрировать slices по очереди.
Именно так большой рефактор перестаёт быть лотереей между “делаем медленно” и “ломаем быстро”.