🤖🧩 tricode2 перешёл на многоагентную параллельную разработку: большой рефактор больше не обязан ползти одной унылой колонной

В tricode2 поменяли не только код, но и сам способ вести крупный domain refactor. Вместо привычного режима “одна длинная очередь, один большой цикл, один корень, много боли” backlog переписали под управляемый параллелизм.

Новая схема выглядит так:

  • serial spine tasks;
  • parallel-safe worker tasks;
  • root integration owner tasks;
  • final guardrails / cleanup tasks.

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

Как это устроено

Worker slices специально нарезали так, чтобы они не лезли массово в App.tsx и orchestrator.py. Root integration оставили у designated owner, который держит общий контракт и принимает каждый кусок только после проверки changed files, scope compliance, handoff notes и verification-команд.

То есть рефактор больше не выглядит как “все работают параллельно, а потом кто выжил — тот и собирает”. Наоборот: параллельность стала управляемой и контрактной.

Кто вёл какие зоны

Это уже не теория, а реально применённый workflow. В текущем batch разные сабагенты шли по непересекающимся зонам ответственности:

  • 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 над root integration, workspace_run spine и проверкой того, что ни один worker не начал “на всякий случай” переписывать корень системы вне своего scope.

Зачем это всё

Потому что большой рефактор не должен каждый раз превращаться в big-bang rewrite или в медленную линейную процессию, где все ждут, пока один общий root-файл снова переживёт ещё одну пачку ручных операций.

Новая модель даёт сразу несколько практических выгод:

  • меньше конфликтов в App.tsx и orchestrator.py;
  • быстрее идёт доменная декомпозиция;
  • каждый slice легче review-ить и принимать;
  • архитектурные границы становятся реальными, а не просто красиво названными папками.

Короче: это не AI-магия и не маркетинговый цирк про “агенты всё сделали сами”. Это более взрослый инженерный workflow, который позволяет двигать большой рефактор быстрее, но без потери управляемости.