Быстрый старт

За пять шагов: от чистой установки до первой задачи, которую агент берёт в работу.

1. Отдел

Отдел = группа пользователей MODX, помеченная как отдел. При установке уже создан отдел «Отдел разработки» (группа mxBoard). Свой отдел заводится так:

• создайте группу пользователей в Пользователи → Управление правами → Группы пользователей;
• зарегистрируйте её как отдел — в UI mxBoard (Компоненты → mxBoard → Структура → Отделы) или через API (department_register / POST /departments).

Членство, роли и супер-пользователи берутся из MODX — mxBoard их не дублирует.

2. Пользователи и исполнители

Добавьте людей и агентов в группу-отдел. Исполнителем задачи может стать только член отдела проекта — это проверяется при создании. Автором задачи может быть кто угодно (в том числе из другого отдела: «программист ставит задачу дизайнеру»).

3. Проект и тип задачи

• Проект = доска: владеет колонками (стадиями) и задачами, принадлежит отделу. Проект default уже есть.
• Тип задачи описывает, какие поля обязана заполнить постановка. Готовые типы — bugfix, feature и research. Свой тип обязан иметь хотя бы одно своё поле. См. Типы задач.

4. Токен для агента

Агенту нужен токен для REST/MCP:

1. откройте профиль пользователя в менеджере (от лица sudo);
2. в виджете «Токен агента» выдайте/перевыпустите токен;
3. токен показывается один раз — в базе хранится только sha256-хэш.

Токен привязан к пользователю MODX, поэтому права агента = права его пользователя. Подключение агента — Агенты.

5. Первая задача

Задачу ставит человек в UI или агент-менеджер через MCP/REST. Обязательный минимум: тип, заголовок, дедлайн, исполнитель (член отдела проекта) и обязательные поля типа. Необязательно, но полезно — плановая трудоёмкость в часах (plan_hours).

Дальше карточка живёт по стадиям проекта default:

backlog  →  to_start  →    plan     →  in_progress  →   review    →   done
 старт       автор      исполнитель       автор       исполнитель     автор
           (дал старт)   (вынес план)  (план принят)     (сдал)      (закрыл)

Подпись под стрелкой — кто переводит карточку в эту стадию (move_roles колонки):

• новая карточка появляется в backlog с уже назначенным исполнителем — постановку ещё можно дорабатывать, работа не начата;
• автор переводит карточку в to_start, когда пора начинать: это ручной гейт запуска исполнителя. С этой же стадии доска начинает мерить фактическое время;
• исполнитель изучает постановку, готовит план и переводит карточку в plan;
• автор проверяет план: устраивает — переводит в in_progress, и этот перевод и есть разрешение реализовывать; не устраивает — пишет комментарий, стадию не меняет;
• исполнитель сдаёт работу переводом в review — это его потолок;
• в done (финальная колонка) карточку переводит только автор или менеджер. Это не соглашение в интерфейсе — запрет живёт в процессоре и действует одинаково через UI, REST и MCP.

У каждой стадии коробочного набора есть описание — короткая инструкция тому, чей ход наступил: что сделать и куда двигать карточку дальше. Её видно и в интерфейсе, и в ответах stage_list / board_list, поэтому агент-исполнитель понимает цикл без отдельного промпта.

Кто и куда вправе двигать карточку — задаётся полем move_roles на каждой колонке. Полная модель — Модель прав.