Альтернативы Linear: почему local-first трекинг задач быстрее, чем вы думаете

Глубина Git-интеграции: больше, чем привязка коммитов к задачам

Большинство трекеров рассматривают Git-интеграцию как галочку: упомяните ID задачи в коммит-мессадже — и на задаче появится ссылка. Полезно, но поверхностно.

Beadbox построен на beads — трекере, где семантика Git является слоем хранения, а не приклеенной интеграцией. Dolt, база данных под капотом, реализует модель данных merkle tree от Git для структурированных данных. Каждое изменение задачи — коммит. У каждого коммита есть родитель. Вы получаете dolt diff, dolt log и dolt merge на истории задач с той же семантикой, что и на коде.

Что это означает на практике:

История задач аудируема. Сама база — граф коммитов. Можно сделать diff между любыми двумя точками и увидеть, какие поля каких задач изменились. Это не «функция аудит-лога», прикрученная сверху. Формат хранения и есть аудит-трейл.

Ветвление работает для задач, не только для кода. Dolt нативно поддерживает ветки. Можно создать ветку базы задач для эксперимента с реорганизацией, а потом смерджить обратно или выбросить.

Синхронизация — push/pull, а не API-вызовы. Совместная работа на нескольких машинах работает как git push и git pull. Без API-токенов, без вебхуков, без OAuth. Укажите Dolt remote на сервер (или DoltHub) и пушьте. Другая машина пуллит.

Замечание о конфликтах: Dolt использует трёхстороннее слияние, как Git. Если два человека редактируют разные поля одной задачи — мерж разрешается автоматически. Если оба редактируют одно и то же поле — получите конфликт, требующий ручного разрешения через Dolt CLI (dolt conflicts resolve). У Beadbox пока нет UI для разрешения конфликтов; конфликты обрабатываются на уровне dolt. На практике конфликты редки, когда каждый работает над разными задачами — это типичный паттерн. Но если команда часто параллельно редактирует одни и те же задачи, это потенциальное трение. Документация Dolt по мержу описывает процесс подробно.

Нативный рендеринг: зачем мы встраиваем Node.js внутрь Tauri

Linear работает во вкладке браузера. Как и Jira, Asana и все остальные SaaS-трекеры. Вкладки конкурируют за память, приостанавливаются ОС и рендерятся через композитор, добавляющий кадры задержки.

Beadbox — нативное десктопное приложение на Tauri. Приложения Tauri обычно крошечные (рантайм Tauri — считанные мегабайты), потому что используют нативный WebView ОС вместо Chromium. Наш бандл больше типичных приложений Tauri — около 160MB, и это осознанный компромисс, который стоит объяснить.

84MB из них — встроенный Node.js. Мы используем sidecar-архитектуру: Tauri запускает сервер Next.js как дочерний процесс, который обрабатывает серверный рендеринг, Server Actions и WebSocket-слой для обновлений реального времени. WebView Tauri указывает на этот локальный сервер. Мы выбрали это вместо чистого Rust-бэкенда, потому что экосистема Next.js даёт React Server Components, Server Actions и скорость итераций на UI. Цена — размер бандла. Эквивалентное Electron-приложение было бы 400MB+. Чистое Rust + Tauri было бы меньше 10MB, но заняло бы втрое больше времени и потеряло бы экосистему React.

Практическая разница с вкладкой браузера: Beadbox рендерится в выделенном WebView-процессе, не разделяющем память с другими 47 вкладками. Раскрытие дерева эпика со 100+ задачами, применение фильтров, переключение воркспейсов — эти операции ощущаются качественно иначе, когда рендерер не конкурирует за ресурсы.

Расширение через CLI, а не REST API

У Linear есть GraphQL API. Он хорошо спроектирован. Но расширение Linear означает написание кода, который общается с их серверами, аутентифицируется их токенами и обрабатывает их лимиты.

Beadbox идёт другим путём: CLI bd и есть API. Каждая операция GUI проходит через bd — тот же инструмент, что вы используете в терминале.

Вот три рабочих процесса, которые можно скопировать прямо сейчас:

Массовое обновление приоритетов для сортировки:

# Установить приоритет 1 (критический) для всех открытых багов
bd list --status=open --type=bug --json | \
  jq -r '.[].id' | \
  xargs -I{} bd update {} --priority=1

Генерация ежедневной сводки:

# Что изменилось за последние 24 часа?
echo "=== Closed today ==="
bd list --status=closed --json | \
  jq -r '.[] | select(.updated > (now - 86400 | todate)) | "\(.id) \(.title)"'

echo "=== Currently blocked ==="
bd blocked --json | \
  jq -r '.[] | "\(.id) \(.title) (blocked by: \(.blocked_by | join(", ")))"'

echo "=== Ready to work ==="
bd ready --json | jq -r '.[] | "\(.id) [P\(.priority)] \(.title)"'

ИИ-агент создаёт и берёт задачу:

# Агент обнаруживает баг, фиксирует и берёт его
ISSUE_ID=$(bd create \
  --title "Fix race condition in auth middleware" \
  --type bug \
  --priority 1 \
  --json | jq -r '.id')

bd update "$ISSUE_ID" --status=in_progress --assignee=agent-3

# ... агент делает работу ...

bd update "$ISSUE_ID" --status=closed
bd comments add "$ISSUE_ID" --author agent-3 \
  "Fixed in commit abc1234. Root cause: mutex not held during token refresh."

Если вы используете ИИ-кодинг-агентов (Claude Code, Cursor, Copilot Workspace), они уже знают, как выполнять CLI-команды. Без клиентских библиотек, без танцев с аутентификацией. Просто Unix-пайпы и shell-скрипты.

Попробуйте Beadbox, чтобы увидеть визуализацию этих процессов в реальном времени.

Офлайн-first — это не фича, это архитектура

Некоторые облачные трекеры предлагают «офлайн-режим», кэширующий недавние данные и синхронизирующий при переподключении. Это фича, прикрученная к принципиально онлайн-архитектуре. Режимы отказа предсказуемы: устаревший кэш, конфликты синхронизации, операции, молча встающие в очередь и потом падающие.

Beadbox работает офлайн, потому что никогда не был онлайн. Во встроенном режиме вся база задач — директория на вашей файловой системе. Нет серверного процесса. Нет демона. Нет сетевого сокета. CLI bd читает и пишет в эту директорию. Beadbox следит через fs.watch() и рендерит найденное.

Нечего синхронизировать, потому что нет ничего удалённого. Если позже захотите совместной работы — push/pull Dolt обеспечит явную, видимую синхронизацию. Но по умолчанию — локально. По умолчанию — ваше.

Как с безопасностью? Если вы оцениваете Beadbox для изолированных или чувствительных сред:

• Шифрование в покое: Beadbox не шифрует директорию .beads/ сам. Он опирается на шифрование на уровне ОС (FileVault на macOS, LUKS на Linux, BitLocker на Windows). Если ваша модель угроз требует шифрования на уровне базы данных — это пробел.
• Бэкапы: Директория .beads/ — обычная директория. cp -r, rsync, Time Machine или dolt push на удалённый — всё работает. История коммитов Dolt означает, что случайные изменения можно откатить через dolt reset.
• Что покидает машину: Во встроенном режиме — ничего. Ноль сетевых вызовов. В десктопном приложении есть два опциональных исходящих соединения: GitHub API для проверки обновлений Beadbox (можно отключить в настройках) и PostHog-аналитика по opt-in (по умолчанию отключена, PII не собирается). Ни то, ни другое не передаёт данные задач.

Для изолированных сред, секретных проектов или разработчиков в самолётах и поездах — это не приятный бонус. Это единственная работающая архитектура.

Без ловушки оплаты за рабочее место

Linear берёт $8/month за участника на плане Standard. Разумно для команды из пяти человек. Менее разумно, когда "команда" включает 13 ИИ-агентов, которым нужно читать и писать задачи.

Модель оплаты за место предполагает стабильные команды человеческого размера. Агентный инжиниринг ломает это предположение. Можно запустить 3 агента для багфикса и 13 для релиза. Каждому нужен доступ к API. В SaaS-ценообразовании каждый агент — рабочее место. Каждое место — строка в счёте. Стоимость растёт линейно для ресурса, который ты масштабируешь экспоненциально.

beads — open-source. CLI бесплатный. Нет платы за место, нет тарифных уровней, нет «свяжитесь с отделом продаж для enterprise». Можно запустить 2 агента или 200 на одной локальной базе — стоимость не меняется.

Beadbox (GUI) бесплатен во время бета-тестирования. Цена после беты пока не определена, но не будет за рабочее место. Агенты — не люди. Брать деньги за агента так же бессмысленно, как за окно терминала.

Open-source экосистема

beads — не закрытый сад. CLI открыт на github.com/steveyegge/beads, и сообщество построило 30+ инструментов: кастомные репортеры, CI-интеграции, скрипты оркестрации агентов, расширения дашбордов и адаптеры экспорта.

Что это значит на практике:

Можно инспектировать всё. Формат хранения — Dolt, запрашиваемый стандартным SQL. Исходный код CLI написан на Go, читаемый и форкаемый. Если bd create делает что-то неожиданное, можно прочитать выполняемый код.

Можно расширять без разрешения. Нет процесса одобрения маркетплейса, нет партнёрской программы, нет переговоров по API-лимитам. Пиши shell-скрипт, Go-плагин или Python-обёртку. Флаг --json CLI на каждой команде даёт структурированный вывод для пайпинга в то, что строишь.

Данные портируемы. Push/pull Dolt позволяет базе задач жить на любом сервере, который контролируешь, синхронизироваться с DoltHub или оставаться на файловой системе навсегда. Нет визарда экспорта, потому что экспортировать неоткуда. Данные уже твои, в формате, который можно запрашивать напрямую.

Сообщество строит инструменты для агентов. Разработчики, использующие beads ежедневно, — это те, кто управляет флотами ИИ-агентов. Расширения, которые они создают, решают задачи координации агентов: пакетные операции, скрипты разрешения зависимостей, репортеры состояния флота. Это не теоретическое взаимодействие с сообществом. Это практики, строящие инструменты для своих рабочих процессов и публикующие их.

Координация с учётом агентов

Большинство трекеров рассматривают «автоматизацию» как вебхук, срабатывающий при изменении статуса человеком. Это прикручивание API к человеческому рабочему процессу. beads и Beadbox спроектированы изначально для координации ИИ-агентов.

Структурированная идентичность агентов. У каждого агента есть файл CLAUDE.md, определяющий роль, границы и протокол коммуникации. Флаги --actor и --author CLI bd привязывают каждое действие к конкретному агенту. Когда eng2 берёт задачу и публикует план, система знает, что это eng2, а не обобщённая «автоматизация».

Команда bd prime. Запусти bd prime в любом воркспейсе — и получишь блок контекста, спроектированный для ИИ-ассистентов кодирования. Вставь его в системный промпт агента — и тот знает полный набор команд, форматы вывода и паттерны рабочего процесса. Обучение нового агента использованию beads занимает одну команду, а не страницу документации.

Графы зависимостей, которые агенты реально используют. Агенты не работают с Kanban-досками. Они работают с деревьями и блокерами. beads нативно отслеживает связи родитель/потомок и блокирующие зависимости. bd blocked показывает каждый bead, ожидающий чего-то. bd ready показывает всё разблокированное и готовое к работе. Beadbox визуализирует это как интерактивное дерево зависимостей, где видно с первого взгляда, что застряло и почему.

Видимость флота в реальном времени. Beadbox следит за базой beads и обновляет интерфейс за секунды. Activity Dashboard показывает карточки статуса агентов (кто активен, кто молчит, кто застрял), поток пайплайна (где скапливается работа) и кросс-фильтруемую ленту событий (клик на агента показывает только его действия). Это вид «центра управления миссией», делающий 13 параллельных агентов управляемыми.

Выбор подходящего инструмента для команды

Нет универсально правильного инструмента. Честная раскладка:

Выбирайте Linear, если:

• Команда 10+ человек, нужно централизованное управление проектами
• Вы зависите от интеграций Slack/GitHub/Figma
• Нетехническим заинтересованным сторонам нужен доступ к трекеру
• Хотите управляемую инфраструктуру без операционных расходов
• Вы продуктовая команда с регулярными циклами выпуска

Выбирайте Beadbox, если:

• Вам важен суверенитет данных (задачи никогда не покидают машину)
• Вы регулярно работаете офлайн или в ограниченных сетях
• Управляете ИИ-агентами, которым нужно программно читать и писать задачи
• Хотите Git-нативную историю задач (ветки, diff, мерж)
• Предпочитаете CLI-first рабочие процессы с визуальным помощником
• Вы соло-разработчик или небольшая команда (1–10), которой не нужны enterprise-фичи

Оставайтесь на текущем инструменте, если:

• Стоимость перехода превышает текущее трение
• Команда вложилась в интеграции, зависящие от API текущего трекера
• Рабочий процесс уже соответствует инструменту

Миграция с Linear (или других трекеров)

Скажем прямо: автоматического инструмента миграции Linear-to-Beadbox сегодня нет. Нет визарда импорта CSV, нет API-моста, нет UI для маппинга статусов.

Если начинаете с нуля — без проблем. bd init, создавайте задачи — Beadbox видит их сразу. Ноль трения.

Если есть существующий проект Linear — рабочий путь сейчас скриптовый: экспорт через API Linear (они поддерживают CSV и API-экспорт), трансформация данных, bd create в цикле. Вы потеряете Linear-специфичные метаданные (циклы, виды проектов, SLA-таймеры), но сохраните заголовки, описания, приоритеты и статусы. Скрипт миграции — проект на выходные, не на квартал.

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

Начало работы

Beadbox бесплатен во время бета-тестирования. Установите через Homebrew:

brew tap beadbox/cask && brew install --cask beadbox

Если вы уже используете beads, Beadbox автоматически обнаружит ваши воркспейсы .beads/. Откройте приложение — ваши задачи на месте. Без импорта. Без создания аккаунта.

Если вы новичок в beads, Beadbox проведёт через инициализацию первого воркспейса. Менее чем за 60 секунд вы увидите свои задачи.

Скачайте Beadbox или посмотрите beads, чтобы оценить, подходит ли local-first трекинг вашему рабочему процессу.