# Спецификация BVC-атома

Базис, Вектор и Цель как машиночитаемый контракт работы.

## Что такое BVC-атом

BVC (Базис–Вектор–Цель) — машиночитаемый контракт одной единицы работы в Work Graph. Это не тикет из чата и не заметка в PM: атом лежит в репозитории как `.bvc`, его читает `get_work_contract`, а закрытие задачи подтверждается evidence и гейтами.

## Обязательные секции

| Секция | Назначение |
|--------|------------|
| **Базис** | Зачем работа существует: контекст, ограничения, связь с решением (AN) |
| **Вектор** | Что меняется: файлы, API, поведение, границы allowlist |
| **Цель** | Как узнать, что готово: наблюдаемый критерий, не «агент сказал done» |

Дополнительно в атоме могут быть **Метки** (`work.id`, `work.status`, `target_files`), **Проверки** (команды и tier-гейты) и **Свидетельства** (structured evidence).

## Жизненный цикл статусов

1. `backlog` — задача описана, контракт черновик или готов к review.
2. `ready` — агент может вызвать `claim_work_item`.
3. `claimed` / `doing` — исполнение в рамках `target_files` и allowlist.
4. `verify` — собраны доказательства, ждёт `assert_task_ready_for_done`.
5. `done` / `verified` — гейт пройден, запись может попасть в память проекта.

## Примеры

**Минимальный атом** — три секции и `work.id`:

```bvc
#Задача_add_llms_txt<[
Базис:
  Агентам нужна стабильная точка входа в документацию WG.
Вектор:
  Добавить /llms.txt с ключевыми страницами и правилами взаимодействия.
Цель:
  Cursor и Claude Code находят docs без скрапинга HTML.

Метки:
  work.id: add-llms-txt
  work.status: backlog
]>
```

**Реалистичный** — с `target_files` и проверками: см. файл [bvc-spec.bvc.example](/docs/bvc-spec.bvc.example).

**Антипример** — атом без **Цели**: линтер backlog-schema и MCP вернут `invalid_bvc_section`; задачу нельзя считать контрактом.

## Связанные MCP-инструменты

- `create_work_item` — создать атом в `intent/`
- `get_work_contract` — прочитать контракт перед правками

Машиночитаемый контекст для авторинга: `/api/docs/bvc-authoring-context`.