Типы задач и поля

Задачи в mxBoard типизированы: у каждого типа свой набор полей, которые обязана заполнить постановка. Цель — формализация: тип с полями превращает «сломался сайт» в конкретные «где / что / как воспроизвести / как должно быть».

Встроенные поля vs поля типа

Встроенные поля есть у любой задачи и в типе не описываются:

Поле	Обязательно	Что это
title	да	Заголовок, ≤250 символов
deadline	да	Дедлайн (дата или unix-время)
type	да	Ключ типа задачи

Плюс всегда доступны assignee (исполнитель), priority, plan_hours (плановая трудоёмкость в часах, 0 — не оценивали, см. План и факт), tor (постановка в markdown), meta (произвольные данные интегратора).

Поля типа (mxboard_field) описывают только дополнительный контент. Их значения хранятся на задаче в JSON-поле fields вида {ключ_поля: значение}.

Правила типа

• Тип обязателен — задач без типа нет.
• Рабочий тип обязан иметь ≥1 своё поле — тип только со встроенными полями бессмыслен (проверяется при создании типа).
• Тип принадлежит отделу; в задаче доступны типы отдела её проекта.

Типы из поставки

Чистая установка получает три нейтральных типа — они осмысленны в любом проекте. Доменные типы конкретного отдела (акции и цены, SEO, вёрстка) в поставку намеренно не входят: это стандарт процесса, а не функциональность доски.

Тип	Поля (обязательные жирным)
bugfix — Багфикс	Где сломалось, Что сломалось, Как воспроизвести, Как должно быть, Окружение, Severity (select: critical / major / minor / cosmetic), Материалы (files)
feature — Фича	Цель, Описание реализации, Критерии приёмки, Страны/контексты, Зависимости, Ссылка на аналог (url), Материалы (files)
research — Исследование	Промт, Формат результата

Состав типов объявлен одним файлом — core/components/mxboard/schema/task-types.php. Из него читает и резолвер пакета, и стендовый сид: пока списков было два, они предсказуемо разъезжались (резолвер не знал ни про environment/severity у багфикса, ни про тип поля select).

Типы из поставки — стартовая точка, а не догма: поля правятся и добавляются в Структуре, свои типы заводятся там же.

Типы полей

Поле (type) может быть одного из:

Тип	Назначение
text	однострочный текст
textarea	многострочный текст
url	ссылка
number	число
date	дата
select	выбор из вариантов (варианты — в options; в UI задаются через |)
user	пользователь
files	файл(ы) — мультизагрузка через медиа-источник (см. Вложения)

Каждое поле имеет key, label, required и position. Тип по умолчанию — text.

Файловый тип называется files

Типа поля file (в единственном числе) не существует — создать такое поле через API нельзя. Единый ключ вложений во встроенных типах — attachments.

Схема типа для агента

Инструмент task_schema (MCP) и GET /types/{key}/schema (REST) возвращают, какие поля нужны для типа: встроенные (обязательные) + поля типа с пометкой обязательности. Агент вызывает его перед task_create, чтобы знать, что заполнять.

При правке карточки fields — частичный патч: непереданные ключи сохраняются, поэтому обновить одно поле можно, не пересылая остальные. Исключение — одновременная смена type: тогда fields считаются полным набором для новой схемы. Неизвестный ключ поля не игнорируется молча, а отклоняется валидационной ошибкой.

ИИ-проверка полноты постановки

mxBoard умеет проверять постановку задачи ИИ-моделью перед сохранением — чтобы не пропускать размытые задачи вроде «сломался сайт, не работает оплата».

Как включить

1. У типа задачи — флаг ai_check («ИИ-проверка полноты»). Включается в UI (Структура → тип) или через API.
2. Заполните настройки провайдера (Настройки → область mxboard_ai): ai_base_url, ai_api_key, ai_model. Пустой ключ = проверка выключена. См. Настройки.

Универсальный провайдер

Клиент говорит на OpenAI-совместимом формате (POST {base_url}/chat/completions, Authorization: Bearer). Работает с любым провайдером: OpenAI, DeepSeek, mimo, локальные vLLM/Ollama — «вставил URL + ключ + модель, и работает». Ответ парсится защитно (JSON из текста), корректно обрабатываются «думающие» (reasoning) модели.

Режимы

Настройка mxboard.ai_check_mode:

• strict (по умолчанию) — неполную задачу создать нельзя: постановщик получит список, чего не хватает.
• soft — предупреждение с возможностью «всё равно создать».

Промпт

Глобальный промпт-шаблон — настройка mxboard.ai_check_prompt. Тип может переопределить его своим полем ai_prompt (пусто → берётся глобальный).

Вердикт

Модель возвращает JSON {complete, score, missing[], summary}. Вердикт:

• сохраняется на задаче (ai_verdict) — с пометкой overridden, если задачу создали в обход «неполной» оценки (soft-режим);
• всегда пишется в журнал (action=ai_check), в том числе при strict-отказе, когда задача не создалась.

Отказоустойчивость

Если провайдер недоступен/таймаут — fail-open: задача пропускается, в лог пишется warning. Сбой стороннего API не парализует доску.

Вложения

Файлы крепятся и к задаче, и к сообщениям чата:

• хранятся в выделенном медиа-источнике MODX (mxboard.media_source, создаётся при установке);
• запись mxboard_attachment с comment_id=0 — файл задачи, comment_id>0 — файл сообщения;
• лимиты — настройки upload_max_size, upload_max_files, upload_extensions (см. Настройки);
• каскад физфайлов: удаление комментария чистит его вложения, удаление задачи — все вложения задачи и её комментов (не только записи в БД).

Поле типа files использует тот же механизм — мультизагрузка с переименованием.