AI-разработка с полной трассируемостью: от идеи до строчки кода
Work Graph связывает бизнес-цель, архитектуру и код в единый граф. Каждая задача имеет контракт, каждое изменение — доказательство.
Три слоя одного цикла разработки
Для агента это не переписка и не сводка прошлой сессии — актуальная карта работ: что открыто, что связано, что уже доказано.
Граф намерений
Каждая задача начинается с разбора: какую проблему решаем, какие варианты, какие границы. Связи между задачами видны явно.
Граф исполнения
Задачи движутся от плана к результату. Агент работает по контракту: ясные входы и выходы, разрешённые действия, обязательные доказательства.
Граф памяти
Закрытые задачи с проверками становятся памятью проекта. Связи к файлам и решениям остаются в git — следующая сессия открывает ту же карту.
Как установить Work Graph
Установка в существующий репозиторий: локальный бэклог, UI и MCP для агента. Нужны Node.js 20+ и npm.
Для агентов:
Установи Work Graph в этот проект https://www.npmjs.com/package/@work-graph/cli и открой локальный UI.
В каталоге проекта выполните:
cd /path/to/your-project
npx @work-graph/cli init .
npm install
npm run workgraph:ui
Откройте в браузере:
http://localhost:4177/
Команда init создаёт .work-graph/config.json, intent/, npm-скрипты и при необходимости .cursor/mcp.json (npx -y @work-graph/mcp, WORKGRAPH_ROOT). Существующие intent/index.bvc и architecture/main.bvc сохраняются. После npm install перезагрузите MCP в IDE.
Проверка: npm run workgraph:doctor
Как начать работу с Work Graph
-
Установите за 2 минуты Выполните npx @work-graph/cli init в проекте. Появится локальная доска, бэклог и MCP для Cursor или другого клиента.
-
Опишите задачу в чате Попросите AI-агента провести разбор или создать задачу. Work Graph автоматически свяжет её с архитектурой.
-
Получите результат с доказательствами Агент выполняет работу по контракту. Вы видите статусы, проверки и доказательства готовности на доске.
Как выглядит Work Graph
Локальный UI Work Graph: от разбора и задач до доски, проверок и памяти — одна карта работ в репозитории, не археология чата.
Аналитика связывает решения с задачами реализации
AN-записи фиксируют аргументацию, варианты и границы до появления work items. Видны lineage, связи с эпиками и реализацией — не отдельный документ, а часть графа намерений в репозитории.
Задача — машиночитаемый BVC-контракт, а не тикет из чата
Вместо разбора длинного треда — контракт задачи в одном месте. Агент знает, какие файлы, команды и проверки обязательны до закрытия.
Доска показывает, как движется работа
Колонки от backlog до ready, doing и done с BVC-задачами и владельцами. Статус — следствие контракта и evidence, а не произвольная метка в переписке.
Проверки решают, можно ли закрыть задачу
Матрица tier A/B/C: детерминированные команды, опциональные проверки и environment-гейты. assert_task_ready_for_done возвращает violations[] — вердикт контракта, а не слова агента.
Память проекта хранит проверенные результаты
Закрытые задачи с проверками становятся памятью проекта. Следующая сессия опирается на git, а не на пересказ прошлого чата.
Архитектура помогает ориентироваться в большом репозитории
Блоки architecture/main.bvc и производные проекции показывают домены и контейнеры без отрыва от intent-графа и бэклога, по которому идёт работа.
Контрактный контур: намерение → исполнение → память
Свяжите стратегию с исполнением: от AN-разбора до проверенной памяти в git — в одном локальном графе работ.
Три слоя одного цикла разработки
Одна карта продукта — три слоя: зачем едем, как идём маршрутом, что уже прошли и запомнили.
Журнал доказательств
Задача закрывается не потому, что агент так сказал. А потому, что у контракта есть проверяемые доказательства — как отметки «участок маршрута пройден» на карте.
Документация для агентов
Критичные страницы имеют Markdown, примеры и машиночитаемое обнаружение, чтобы Cursor, Claude Code и MCP-клиенты использовали сайт как инструмент.
Почему обычного AI-воркфлоу недостаточно?
Чат хранит переписку. Work Graph хранит работу: контракт на задачу, состояние бэклога и доказательства — чтобы на каждой сессии читать карту проекта, а не восстанавливать смысл из токенов.
Задача читается человеком, git и агентом
BVC описывает намерение, projection задаёт исполнение, evidence превращает результат в память.
#ImplementTraceLinksV1@ru<[
Базис:
Текущая трассировка шагов не валидируется в CI
Нет связи work.id ↔ файлы ↔ тесты
Вектор:
Реализовать валидатор трассировки
Добавить MCP-инструмент get_unified_linkage
Цель:
Любая задача с trace.* метками имеет автоматическую проверку целостности
Метки:
profile: work_item
tier: A
trace.codegen: false
Checks:
npm run test:deterministic
bvc lint intent/**/implement-trace-links-v1.work.bvc
]>claim_work_item("implement-trace-links-v1")
→ get_work_contract(work_id)
→ edit target_files
→ run allowed commands
→ validate_evidence(structured_json)
→ assert_task_ready_for_done(work_id)
→ add_work_item_evidence + completeПочему обычного AI-воркфлоу недостаточно?
Обычный AI-воркфлоу
Намерение остаётся в голове или чате
«Готово» = слова агента
Work Graph
Намерение формализовано в графе — карта продукта
«Готово» = доказательства + проверенный гейт
Jira / Linear
Задачи и статусы в облаке
Контракт и доказательства не в git-репозитории
CI / тесты
Проверяет команды
Не знает, зачем была задача
Для кого Work Graph
Для техлида и архитектора
Видите полную картину: от разбора до финального кода. Решения, контракты и доказательства в git, а не в пересказе чата. Пример: за 5 минут находите, какая задача и какой разбор стоят за конкретным коммитом.
Для разработчика
Один бэклог и понятный контракт перед началом работы. Ясные границы файлов и статусы на доске — меньше импровизации, больше предсказуемости.
Для AI-агента
Не выжимать смысл из длинной переписки — читать маршрут задачи и текущую позицию на карте. Исполнять контракт, а не объявлять «готово» словами.
FAQ
Work Graph — это тасктрекер?
Нет, это надстройка над вашим процессом. WG добавляет трассируемость и контрактность к тому, что вы уже используете — Cursor, Claude Code, git. Доска и статусы есть, но единица работы — не тикет из чата, а задача с доказательствами.
Это замена Cursor или Claude Code?
Нет. Вы продолжаете использовать любимую IDE и агента. Work Graph даёт карту работ, контроль контрактов и аудит — слой над исполнением, не вместо него.
Где хранятся данные?
Локально в вашем репозитории. Никакого облака Work Graph, никаких внешних серверов для канона. Вы владеете картой работ.
Что такое BVC?
BVC (Базис · Вектор · Цель) — формат атома намерения: контекст и причина, конкретные действия и критерий успеха. Он понятен человеку, валидируется схемой и помогает LLM точно понимать границы задачи.
Как агент общается с Work Graph?
Через MCP. В конфиге IDE указывается сервер @work-graph/mcp, после чего агент вызывает инструменты вроде get_work_contract, submit_evidence или assert_task_ready_for_done. WG отвечает структурированными данными, а не текстом чата.
Работает ли WG без интернета?
Да. Ядро Work Graph работает локально. Сеть нужна только для доступа агента к модели или серверу IDE; сам WG не требует внешних сервисов.
Я не использую AI-агентов. WG полезен мне?
Да. Структурированный бэклог, связь задач с архитектурой и история решений в git полезны и без агента. С агентом раскрывается автосбор доказательств и проверки готовности.
Как WG связан с CI/CD?
WG не заменяет пайплайны. Он требует их результаты как доказательства. Контракт может требовать npm run test:login; агент запускает команду, передаёт exit code и вывод, а WG проверяет evidence перед done.
Поддерживает ли WG 1С / OneBase?
Да, как доменную вертикаль через специализированные MCP-серверы и evidence-контракты. Доменные метаданные и проверки могут становиться доказательствами в том же контрактном слое.
Как я могу быть уверен, что агент не галлюцинировал закрытие задачи?
Через слой Evidence. Агент не может просто написать «я всё сделал». Он обязан вызвать add_work_item_evidence и передать результат команды, exit code и хеши артефактов. Work Graph валидирует результат по контракту задачи.
Что если агент нарушит контракт?
WG работает как gate. Если агент пытается закрыть задачу без обязательного доказательства Tier A, runtime возвращает PolicyViolation, задача остаётся открытой, а нарушение пишется в аудит-лог.
Для LLM и интеграций: /faq.json