Orca CLI: агентный конвейер из задач в workspace

Как задача превращается в работу отдельного агента

Мне здесь интересен не сам интерфейс Orca, а связка Orca CLI и automations: карточка, перемещенная в Select for development, может стать входом для отдельного агентного запуска. В официальном обзоре и справочнике Orca CLI описаны операции с worktree, терминалами, файлами, diff, встроенным браузером и отчетами о ходе работы. Отдельная документация по scheduled automations подтверждает запуск задач для репозитория или существующего workspace.

Я скачал Orca и поигрался с ним пару часов. Немедленного желания переносить туда весь рабочий процесс не возникло, зато сценарий с Markdown-канбаном хорошо показывает, зачем вообще нужен CLI поверх среды разработки. Orca становится не еще одним экраном с агентом, а исполнительным слоем между задачей и репозиторием.

Предлагаемый конвейер выглядит так:

• задача появляется в канбане Obsidian и меняет статус;
• для нее создается изолированный workspace с отдельной веткой;
• мини-агент выполняет работу и готовит changelog;
• статус и результат возвращаются в Markdown-файл;
• слияние и развертывание остаются отдельными этапами.

Ключевая оговорка: официальные материалы Orca подтверждают работу с изолированными worktree, автоматизациями и Markdown-артефактами, но не готовую интеграцию с Obsidian. По состоянию на 24 августа 2026 года такая связка в собранной документации не описана. Значит, наблюдение за изменениями канбана и обновление vault придется организовать как внешний слой, а не считать встроенной функцией.

Почему файловый канбан здесь важнее интерфейса

Этот подход реально меняет работу с несколькими проектами, но не делает ее магически автономной. Обычный Markdown-файл превращается в очередь заданий, а изолированные workspaces снижают риск смешивания контекста, веток и незавершенных изменений между параллельными агентами.

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

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

Ранее мы разбирали, как параллельные агенты Claude Code проверяют PR и находят race conditions в workflow. Этот подход хорошо дополняет изолированные workspace, где каждому агенту нужна отдельная среда для своей задачи.