Flow

Imported from azizmac/Flow (AGENTS.md). Install upstream with npx skills add azizmac/Flow. Copyright stays with the author.

Flow — трекер задач по проектам (C#, .NET 10)

Слойная архитектура

Flow.Api           → единственный backend-хост: контроллеры (только IMediator + IActorAccessor), MCP-сервер (Mcp/*, /mcp), Auth-модуль, fallback-политика «всё закрыто», Auth/ClaimsActorAccessor, Auth/ApiExceptionFilter, Bootstrap/BootstrapOwnerSeeder (миграции ядра + профиль bootstrap-пользователя)
Flow.Auth          → Razor Class Library: ASP.NET Core Identity + BCrypt, OpenIddict server и локальная validation (code+PKCE, refresh, client_credentials), страницы входа/смены пароля, AuthDbContext в схеме auth; подключается через AddAuthModule
Flow.Auth.Contracts→ публичная граница Auth-модуля: IAccountService и AccountResult
Flow.Shared        → DTO-контракты (Boards, Tasks, Users) для API и клиента
Flow.Application   → Features/{Boards,Tasks,Users,Bootstrap,Search,Attachments,About}/{Commands,Queries}/*, Features/Tasks/Mentions (MentionParser/MentionResolver), Abstractions (IBoardRepository, IBoardMemberRepository, ITaskItemRepository, ITaskCommentRepository, ITaskActivityRepository, IUserRepository, IUnitOfWork, IActorAccessor, IPermissionService), Security (PermissionService, ActorResolver, ProjectAccess, ProjectRoles), Exceptions (UnauthorizedActorException → 401, ForbiddenException → 403)
Flow.Domain        → сущности Board, BoardMember, ProjectRole, ProjectPermission, Status, TaskType, TaskTypeKind, DefaultTaskTypes, TaskPriority, TaskItem, TaskCode, StatusType, DefaultStatuses, TaskComment, TaskCommentMention, TaskActivity, TaskActivityType, Attachment, User, UserLink, UserLinkType, UserRole, UserStatus, UserPreferences, SidebarMode, StartPage, Dashboard, DashboardWidget, WidgetType
Flow.Infrastructure→ EF Core (Postgres/Npgsql + pgvector), репозитории, UnitOfWork, миграции, Search/* (эмбеддер, очередь и воркер индексации)
Flow.Client        → библиотека Razor-компонентов (Microsoft.NET.Sdk.Razor), не приложение: хостит и рендерит её Flow.Api, режим InteractiveServer с намеренно выключенным prerender. Экраны «Проекты» (/ и /boards), «Задачи» (/tasks и /boards/{id} — один Pages/Tasks.razor), задача (/tasks/{id}), «Люди» (/users), профиль (/users/{id}), поиск (/search), настройки (/settings); UI-кит MudBlazor 9.x поверх своих токенов (Services/FlowTheme.cs), сервисы интерфейса регистрирует DependencyInjection/AddFlowClientServices — своего Program.cs у библиотеки нет. За данными страницы ходят через Services/IFlowApi; реализация InProcessFlowApi лежит в Flow.Api (клиент по слоям видит только Shared) и зовёт IMediator в том же процессе, без HTTP

Зависимости: Application → Domain + Shared + Auth.Contracts; Infrastructure → Application; Auth → Auth.Contracts; Api → Application + Infrastructure + Auth + Shared. Shared намеренно не ссылается на Domain (свои enum StatusType, TaskTypeKind, TaskPriority, UserLinkType, UserRole, UserStatus, TaskActivityType; маппинг — UserMappingExtensions.ToResponseRole/ToDomainRole/ToResponseStatus, TaskMappingExtensions.ToResponseType/ToResponsePriority/ToDomainPriority, BoardMappingExtensions.ToResponseKind/ToDomainKind).

Ключевые инварианты Board (aggregate root)

• Key: ^[A-Z][A-Z0-9]{1,9}$, префикс для TaskCode.
• Create(name, key) — единственная публичная точка создания; сажает 4 статуса из DefaultStatuses и 5 типов задач из DefaultTaskTypes.
• Типы задач (docs/TZ_task_model.md §1, этап 1A) — Board.TaskTypes, как статусы: TaskType (Name ≤ 50, уникально в проекте без учёта регистра, Kind : TaskTypeKind Epic/Story/Task/Bug/Subtask, SortOrder, IsDefault, IsArchived). Уровень иерархии выводится из вида (TaskTypeKind.Level(): эпик 1 → история 2 → задача/ошибка 3 → подзадача 4) и в БД не хранится; иконка и цвет — тоже от вида (клиент, Services/TaskMeta). Ровно один тип по умолчанию (AddTaskType(isDefault)/SetDefaultTaskType переносят флаг), тип по умолчанию не архивируется; удаления нет — только SetTaskTypeArchived. CreateTask(..., typeId) без типа — тип по умолчанию, архивный или чужой — InvalidOperationException. EF: TaskType.Id — ValueGeneratedNever(), иначе новый тип, добавленный в уже сохранённую доску, EF считает существующим и шлёт UPDATE на 0 строк.
• Ровно 1 начальный и минимум 1 финальный статус на доску (см. «Статусы проекта»).
• CreateTask: без statusId → в начальный; NextTaskNumber++ → TaskCode; новые задачи регистрируются через ITaskItemRepository.Add, не через коллекцию Board.Tasks.
• Все поля { get; private set; }, мутации только через методы.

User (профиль, не учётная запись)

• User.Create(username, email, firstName, lastName) — единственная точка создания; username/email нормализуются в lower, username ^[a-z0-9][a-z0-9._-]{0,30}[a-z0-9]$.
• Внешние ссылки — коллекция UserLink (SetLink/RemoveLink), не более одной на UserLinkType; телефон хранится в E.164 (+79991234567).
• Роль и статус (docs/TZ_user_roles.md, #15): User.Role : UserRole (Reader 0 … Owner 4, порядок = сила, сравнивать >=; по умолчанию Member) и User.Status : UserStatus (Invited при создании → Active после первого GET /users/me через MarkActive() → Deactivated). IsActive/CanBeAssigned вычисляются из Status (builder.Ignore), в БД их нет — в запросах фильтровать по Status != Deactivated. ChangeRole только меняет роль; «последний Owner» и права — Application (#18). Deactivate() бросает для Owner (сначала понизить) и повторно; Activate() — только из Deactivated; MarkActive() для Deactivated — ошибка. Пароли в домене отсутствуют намеренно (живут в Flow.Auth). Из UI деактивация убрана до #20.
• Личные настройки интерфейса — value object User.Preferences : UserPreferences (SidebarMode Auto/Expanded/Collapsed, StartPage Projects/Tasks/MyTasks/Dashboard, TasksPageSize из AllowedTasksPageSizes = 10/25/50/100, TasksView List/Board/Tree/Backlog/Calendar/Roadmap — вид экрана «Задачи»), меняется целиком через ChangePreferences (→ bool, no-op без сохранения). В EF — complex type, колонки PrefSidebarMode/PrefStartPage/PrefTasksPageSize прямо в Users (миграция AddUserPreferences, существующим профилям — размер 100, а не 0). Команды UserGetPreferencesQuery/UserUpdatePreferencesCommand (PATCH-семантика) работают только с самим actor: UserId у них нет, строки в матрице прав тоже — свои настройки меняет любая роль, чужие не читает никто. Клиент: Services/PreferencesState (один GET на circuit; режим меню уходит в AppState.SetSidebarMode), размер страницы читает Tasks.razor до монтирования таблицы, стартовая страница действует только на корень / (Boards.razor уводит на tasks или tasks?who={me}), /boards и логотип ведут на проекты всегда.
• TaskItem.CreatedById : Guid? (FK → Users, Restrict, индекс) — кто создал, для «своей задачи» у Member; Board.CreateTask(..., createdById). TaskCreate пишет туда actor.
• Планирование задачи (этап 1A): TypeId (FK → TaskTypes, Restrict; ChangeType — тип того же проекта, не архивный), Priority : TaskPriority (None 0 … Critical 4, фиксированная шкала, не справочник), StartDate : DateOnly? (SetSchedule(start, due): начало ≤ срок; SetDueDate проверяет то же), StoryPoints : decimal? (0…999.9, шаг 0.1, numeric(5,1)), EstimateMinutes : int? (0…999 рабочих дней по 8 ч; учёта фактического времени нет намеренно), UpdatedAt — ставит UnitOfWork (TaskItem.Touch) у каждой задачи в состоянии Modified, а не доменные методы: новое поле не сможет забыть «тронуть» дату. Комментарии и вложения UpdatedAt не двигают. Миграция AddTaskTypesAndPlanning (Up переписан руками: типы по умолчанию каждому проекту, задачам — тип «Задача», UpdatedAt = CreatedAt).

Пользовательские поля (docs/TZ_task_model.md §4, этап 1D)

• CustomFieldDefinition — часть агрегата Board (таблица CustomFields: Key по ^[a-z][a-z0-9_]{1,29}$, неизменяем, unique (BoardId, Key); Type : CustomFieldType Text/LongText/Number/Date/Select/MultiSelect/User/Checkbox/Url — не меняется; Options — jsonb через OwnsMany(...).ToJson(); TaskTypeIds — uuid[], пусто — все типы; IsRequired, SortOrder, IsArchived). Мутации — Board.AddCustomField/UpdateCustomField/ReorderCustomFields, удаления нет. CustomField.Id — ValueGeneratedNever, BoardRepository грузит поля вместе с доской.
• Значения — TaskItem.CustomFieldsJson (колонка CustomFields jsonb, GIN jsonb_path_ops), ключ — Id поля. Менять только TaskItem.SetCustomField (→ старое/новое JSON или null): CustomFieldValidator в Domain нормализует (Text ≤ 500, LongText ≤ 10000, Url http/https, Date yyyy-MM-dd, Select/User — Id строкой, MultiSelect — массив Id, пустое — очистка), обязательное не очищается. Удалённый вариант задачи не трогает — клиент показывает «(удалённое значение)».
• Application: Features/CustomFields — CustomFieldCreate/Update/Reorder (ManageConfig, ответ BoardResponse), TaskSetCustomFields (EnsureCanEditTask). Путь записи один — TaskCustomFields.ApplyAsync (человек для User — активный, журнал CustomFieldChanged, Upsert в поиске при правке Text/LongText); TaskCustomFields.EnsureRequired — в TaskCreate (значения приходят в команде) и в TaskUpdate при смене типа. Текстовые значения — в чанке задачи (SearchSourceReader).
• FQL cf.<key>: SQL-функции flow_cf_text/number/date/any создаёт миграция AddCustomFields, в EF они — Persistence/CustomFieldSql (DbFunction). TaskFilterCustomField(FieldIds, Type, Op, Value) — все поля с этим ключом в видимых проектах. ILIKE всюду с явным ESCAPE '\': без него Npgsql ставит ESCAPE '', и %/_ в строке становились шаблоном.
• Клиент: Components/CustomFieldsDialog (значок «Поля проекта» в топбаре «Задач», ManageConfig), CustomFieldsEditor — пары meta-k/meta-v в сетке слайдера, карточки и формы создания (компактные MudTextField/MudNumericField/MudDatePicker/MudSelect/MudCheckBox — у фасада DsInput вид поля формы, а не строки мета-сетки), Services/CustomFieldMeta (подписи, отображение), журнал «поле «X»: A → B».

Иерархия и ручной порядок (docs/TZ_task_model.md §3, §7, этап 1B)

• TaskItem.ParentId : Guid? (FK на себя, Restrict, индекс) — родитель в том же проекте и строго выше по уровню типа (TaskTypeKind.Level()), поэтому циклов и глубины больше четырёх нет по построению. SetParent(parent, ownType, parentType) — типы приносит хендлер; ChangeType(type, parentLevel, minChildLevel) держит уровень между родителем и детьми. Команды: TaskCreate(…, ParentId), TaskSetParent (журнал ParentChanged у задачи, ChildRemoved/ChildAdded у старого и нового родителя; индекс не трогает), TaskDelete(…, Cascade) — с детьми без флага 400, с флагом хендлер сам собирает поддерево (каскада в БД нет: он прошёл бы мимо очереди индексации и S3) и проверяет права на каждой задаче. TaskResponse несёт ParentId, ChildCount, ChildDoneCount (CountChildrenAsync — один GROUP BY с join статусов; в ответах команд 0, клиент переносит счётчики TaskMeta.WithCountsOf). TaskTreeQuery → GET /boards/{id}/tree?rootId= — рекурсивный CTE с путём из рангов через / (меньше любой цифры base-62), COLLATE "C". Экран дерева (этап 2C) — см. «Дерево».
• TaskItem.Rank : string — дробный индекс Flow.Domain/Ranking/FractionalIndex (порт алгоритма Гринспена: целая часть переменной длины + дробная, base-62 в порядке ASCII). Колонка varchar(200) COLLATE "C" (по правилам локали 'a' < 'B', и порядок ключей ломается — тест гоняется на ICU-базе), unique (BoardId, Rank) = TaskItemConfiguration.RankIndexName. Ключ считает сервер: новая задача — в конец проекта (GetMaxRankAsync), TaskRankCommand(…, AfterId?, BeforeId?) → POST /tasks/{id}/rank — второго соседа берёт сам (GetNeighborRankAsync). Гонка: UnitOfWork переводит 23505 по этому индексу в RankConflictException, TaskRanks.SaveAsync пересчитывает ключ по свежим соседям, до трёх попыток. Смена одного ранга UpdatedAt не двигает и в журнал не пишется. TaskSortField.Rank, фильтр GET /tasks?parentId=. Миграция AddTaskHierarchyAndRank: существующим задачам d0001… по CreatedAt внутри проекта.
• Клиент: Components/ParentSelect (поиск через GET /tasks, только уровнем выше), Components/SubtaskList (прогресс, быстрый ввод подзадачи — тип TaskMeta.ChildTypeFor), чип «2/5» в строке списка, тексты журнала со ссылками на задачи, подтверждение удаления с поддеревом. Слайдер зовёт OnHierarchyChanged — список перечитывается.

Слияние, разделение, перенос (docs/TZ_task_model.md §6, этап 1E)

• Features/Tasks/Restructure: TaskMergeCommand (дубль закрывается первым финальным статусом и связью Duplicates; комментарии — TaskComment.TransferTo с «из КОДА», вложения без повторов по хешу, связи и подзадачи переходят к основной; с предком/потомком и подзадачами, которые не станут ниже основной, — 400 до изменений), TaskSplitCommand (1–20 частей: родитель, тип, приоритет, активный исполнитель, поля; связь SplitFrom у каждой, журнал Split у исходной, она не закрывается), TaskMoveCommand + TaskMovePreviewQuery (поддерево целиком, TaskMovePlanner: статус — карта → вид → начальный, тип — карта → вид → по умолчанию, поля — тот же ключ и тип, варианты по подписи, иначе потеря; подзадача не ниже родителя — 400; спринт и веха сбрасываются), TaskGetByCodeQuery. Права: слияние — правка обеих; разделение — правка + CreateTask; перенос — правка каждой задачи поддерева + CreateTask в целевом.
• Прежний код — TaskCodeAlias (таблица TaskCodeAliases, PK код, каскад от задачи, миграция AddTaskCodeAliases); GetByCodeAsync ищет живой код, потом алиас. Вложения: Attachment.Relocate + IFileStorage.CopyAsync до транзакции, старые ключи удаляются после коммита. Комментарии и вложения для правки — GetByTaskIdForUpdateAsync (обычные списки читаются без трекинга). Индекс: Upsert задач, комментариев и вложений с новым проектом. Журнал Merged/Split/Moved.
• API: POST /tasks/{id}/merge, /tasks/{id}/split (201), /tasks/{id}/move/preview, /tasks/{id}/move; GET /tasks/by-code/{code}. Клиент: RowMenu.ShowRestructure, Components/TaskRestructure + SplitTaskDialog/MergeTaskDialog/MoveTaskDialog, Pages/TaskByCodePage (/tasks/{код}).

Повторяющиеся задачи (docs/TZ_task_model.md §9, этап 1F)

• Образец — сама задача с правилом TaskRecurrence (одно на задачу, каскад от неё): RecurrenceRule complex type (Frequency Daily/Weekly/Monthly/Yearly, Interval 1…99, WeekDays битовой маской, MonthDay 1…31 или -1), StartsOn/EndsOn, LeadDays 0…60, DueOffsetDays 0…365, CopyAssignee, CopyChecklist, IsActive, CreatedById, GeneratedUntil, LastError. Вхождения TaskRecurrenceOccurrences — PK (RecurrenceId, OccursOn), TaskId SetNull: идемпотентность и защита от возврата удалённой копии. Миграция AddTaskRecurrences.
• Генерация — RecurrenceGenerateCommand по одному правилу (воркер Infrastructure/Recurrence/RecurrenceWorker, Recurrence:{Enabled, IntervalMinutes=15, TimeZone=Europe/Moscow}, scope на правило): копии на даты (GeneratedUntil, сегодня + LeadDays], не старше 7 дней; копия — название, описание, тип, приоритет, поля, родитель (если ниже по уровню), снятый чек-лист, активный исполнитель; статус начальный, срок = дата + DueOffsetDays, автор — автор правила, связь Clones → образец, журнал Created с NewValue = "по расписанию", Upsert в поиске. Образца нет или автор деактивирован — Pause с причиной; TaskRecurrenceSet с IsActive возобновляет от имени actor'а. Права — EnsureCanEditTask образца.
• API: GET/PUT/DELETE /tasks/{id}/recurrence, GET/POST /tasks/{id}/recurrence/preview?count=. Клиент: TaskRecurrenceBlock + RecurrenceDialog, Services/RecurrenceText.

Интеграция с Git-хостингами (docs/TZ_git_integration.md, этапы 5A–5E)

• Код и контракты области именуются Git*, namespaces и папки — GitIntegration. SQL-таблицы — GitHostConnections, GitRepositories, GitRepositoryBoards, GitDevelopmentLinks, GitIntegrationJobs; переход со старых имён Scm* с сохранением данных выполняет миграция RenameScmTablesToGit. Маршруты области — /api/git и /hooks/git. Исторические миграции, секция настроек Scm, переменная SCM_PUBLIC_BASE_URL и DataProtection purpose Flow.Scm сохранены для совместимости с развёрнутой системой.
• Доступ к Git-сущностям разделён по отдельным репозиториям: IGitHostConnectionRepository, IGitRepositoryCatalog, IGitRepositoryBoardRepository, IGitDevelopmentLinkRepository, IGitIntegrationJobRepository. EF-реализации — в Infrastructure/Persistence/Repositories, общий FlowDbContext и сохранение через IUnitOfWork. Каталог хранит GitRepository; задания интеграции — вебхуки и дозагрузка истории. Тесты и фейки этой области именуются Git*.
• Модель — Domain/GitIntegration/: GitHostConnection (GitHub/GitLab/Gitea/Forgejo, BaseUrl для self-hosted, токен — SecretProtected), GitRepository (вебхук и его секрет, IsActive; отключение не удаляет связи), GitRepositoryBoard (привязка к проекту — коды ищутся только в привязанных проектах), GitDevelopmentLink (Branch/Commit/PullRequest, unique (TaskId, RepositoryId, Kind, ExternalId), каскад от задачи), GitIntegrationJob (очередь, jsonb-Payload — уже нормализованный GitEvent). Миграция AddScmIntegration. Права: подключения — глобальные Admin+ (EnsureCanManageIntegrations), привязка — ProjectPermission.ManageGit (администратор проекта), «Разработка» — видимость проекта.
• Features/GitIntegration: TaskCodeDetector, GitSignatures (HMAC-SHA256 / токен GitLab, постоянное время), GitPayloadParser, GitWebhookReceiveCommand (подпись → повтор по Id доставки → нормализация → очередь), GitIntegrationJobProcessCommand (ветки, коммиты — плюс коммиты ветки с кодом, PR; автор по e-mail или логину из ссылок профиля; удалённая ветка закрывает связь), админ-команды подключений/репозиториев и TaskDevelopmentQuery. Коды находятся и по алиасу после переноса задачи.
• Приём — Flow.Api/Controllers/GitWebhookController (POST /hooks/git/{id} вне /api, аноним + подпись, 5 МБ: 202/200 повтор/401/404/413), шифрование — Flow.Api/GitIntegration/DataProtectionGitSecretProtector, клиенты API — Infrastructure/GitIntegration/GitProviderClient, разбор — GitWorker. Настройки Scm:{PublicBaseUrl, WorkerEnabled, PollIntervalSeconds, DeliveryRetentionDays}; в compose — SCM_PUBLIC_BASE_URL.
• Клиент: «Настройки → Интеграции» (Admin+), «Репозитории проекта» в топбаре «Задач», блок «Разработка» (Components/TaskDevelopment), значок PR (TaskResponse.PullRequestState) в списке и на канбане.
• Этап 5B. Дозагрузка истории — не отдельная таблица, а GitIntegrationJob с событием flow:backfill в той же очереди: ставится при новой привязке и POST /git/repositories/{id}/backfill (второе поверх стоящего — нет), разбирается тем же Processor (IGitProviderClient.GetHistoryAsync: 100 PR + коммиты ветки по умолчанию за 30 дней, Scm:Backfill*). Лимит запросов хостинга (429; 403 с нулевым *RateLimit-Remaining или Retry-After) — GitRateLimitException → GitIntegrationJob.Postpone без траты попытки. GitHub App — GitHostConnection.AuthKind/AppId/InstallationId (миграция AddScmGitHubApp), секрет — PEM, JWT RS256 → токен установки, кэш GitHubAppTokens (singleton). Диагностика — FailedDeliveries у репозитория, POST /git/deliveries/{id}/retry (только Failed), клиент Components/GitIntegrationJobsDialog. FQL development = openPR | mergedPR | noPR — TaskFilterPullRequest, EXISTS по GitDevelopmentLinks.
• Этап 5C. Автоматизация привязки — колонки GitRepositoryBoard.OnPullRequestOpenedStatusId/OnPullRequestMergedStatusId (FK SetNull на статус) и SmartCommits, PUT /boards/{id}/repositories/{repoId} с телом (пустое — только привязать); миграция AddScmAutomation. Логика — Features/GitIntegration/GitAutomation через TransitionGuard (обхода нет), отказ — GitDevelopmentLink.Note, не ошибка доставки. Actor автоперехода — автор PR с правом править задачу, иначе GitIntegrationBot (фиксированный Id, деактивированный профиль без учётки, создаётся лениво, в workflow — роль Member). Смарт-коммиты — SmartCommitParser, только ветка по умолчанию, только сопоставленный активный автор с его правами, без повтора для уже виденного коммита. Журнал — TaskActivity.Source/SourceUrl (FromSource, «PR #42», «коммит a1b2c3d»). Дозагрузка истории автоматизацию не запускает.
• Этап 5D. Действия из Flow — Features/GitIntegration/GitTaskActions (TaskGitBranchCreateCommand, TaskGitPullRequestCreateCommand): право проекта ProjectPermission.WriteGit (17, Developer+), только активный репозиторий, привязанный к проекту задачи; имя ветки — GitUrls.ValidateBranch; связь пишется сразу (автор — actor), новый PR проходит автопереход «PR открыт» от имени создавшего; отказ хостинга (GitProviderException) → 400 с его текстом; ответ — TaskDevelopmentResponse (он же несёт Repositories и CanWrite). Описание PR и комментарий — GitUrls.TaskComment с адресом GitOptions.TaskUrl ({PublicBaseUrl}/tasks/{КОД}). Комментарий в новом PR — флаг привязки GitRepositoryBoard.CommentOnPullRequests (миграция AddScmPullRequestComments): после разбора доставки на новую связь PR (не история, не закрытый, не если адрес задачи уже в описании), отказ — GitDevelopmentLink.Note. Клиент — «Создать ветку»/«Создать PR» в TaskDevelopment → Components/GitCreateDialog, галочка «Комментарий в новом PR» в BoardRepositoriesDialog.
• Этап 5E. PR и коммиты в поиске — SearchSourceType.Development (6), источник — GitDevelopmentLink (ветки не индексируются). Текст — SearchSourceReader.ReadDevelopmentAsync («PR #42 Заголовок» + ветки; первая строка коммита + короткий sha), проект и закрытость — от задачи. Очередь — Features/GitIntegration/GitSearch (Upsert/Delete расширения над ISearchIndexQueue): разбор доставки — новая связь или изменившийся текст (дозагрузка — приоритет 1), PR из Flow, TaskDelete (Delete связей), TaskMove (Upsert с новым проектом). Старые связи ставит миграция IndexScmLinksInSearch. Выдача — join GitDevelopmentLinks в SearchQueryRepository (ParentId = задача). Клиент — вкладка «Разработка» в поиске, SearchPresentation.KindLabel.

Связи и чек-лист задачи (docs/TZ_task_model.md §5, §8, этап 1C)

• TaskLink — отдельная сущность (Source, Target, TaskLinkType Blocks/Duplicates/RelatesTo/Clones/SplitFrom, CreatedBy), задачи могут быть в разных проектах. TaskLink.Create запрещает связь на себя и упорядочивает концы у симметричной RelatesTo. БД: FK на обе задачи cascade (удаление задачи/проекта уносит связи), unique (Source, Target, Type), индекс (Target, Type). Команды TaskLinkCreate (вторая задача по Id или коду; Inward — «эта задача заблокирована»; скрытая или несуществующая — 400; дубль — 409; цикл Blocks — не отказ, а CycleWarning, обход в ширину до 500 задач) и TaskLinkDelete (правка любой из двух задач). TaskLinkListQuery — обе стороны, TaskLinkPeer.Restricted для задачи в невидимом проекте (без кода и названия). Журнал LinkAdded/LinkRemoved — у обеих задач: OldValue = вид со стороны задачи (Blocks / Blocks:in), NewValue = Guid второй. TaskResponse.BlockedByCount — входящие Blocks от незакрытых задач, GROUP BY с join статусов.
• Чек-лист — owned-коллекция TaskItem.Checklist (TaskChecklistItem: Text ≤ 500, IsDone, SortOrder, DoneAt, DoneById; таблица TaskChecklistItems, Id — ValueGeneratedNever), до 100 пунктов, методы Add/Edit/SetDone/Remove/ReorderChecklist. Команды TaskChecklist{Add,Update,Delete,Reorder} отвечают чек-листом целиком; журнал ChecklistChanged («3/5» → «4/5») — только когда меняется прогресс. UnitOfWork «трогает» UpdatedAt задачи и при правке её пунктов (owned-записи — отдельные записи трекера). TaskResponse.ChecklistDone/ChecklistTotal точны и в ответах команд.
• Счётчики ответов для чтения собирает один Features/Tasks/TaskResponses (комментарии, подзадачи, блокировки — по GROUP BY на каждый); новый счётчик добавлять туда, а не в хендлеры запросов.
• Клиент: Components/TaskChecklist, Components/TaskLinks (вид связи сегментом, поиск второй задачи по всем видимым проектам), чипы «заблокирована» и «☑ 4/5» в строке списка, тексты журнала; TaskTimeline.NoteActivity дописывает локальные записи.

Фильтр задач, FQL и сохранённые фильтры (docs/TZ_task_views.md §7, этап 2A)

• Features/Tasks/Fql: FqlTokenizer → FqlParser (рекурсивный спуск, OR < AND < NOT, скобки, IN (…), IS [NOT] EMPTY, = EMPTY, функции, ORDER BY) → FqlBinder (имена в Id через IFqlLookup; реализация FqlLookup видит только проекты actor'а — ключ скрытого проекта отвечает «не найден») → TaskFilterNode (Abstractions/TaskFilter.cs: And/Or/Not, In по ссылкам, IsEmpty, виды, Compare, Text, Blocked, PullRequest) + TaskOrder. Ошибки — FqlException(message, position, length) → 400 FqlErrorResponse, в InProcessFlowApi — ApiResult.FqlError. Всё чистые функции, тесты без БД. Каталог полей и словарей — FqlFields (один на биндер и подсказки); sprint/milestone отвечают «появится на этапе…». Относительные даты от UTC-даты сервера; created = день — интервал суток; оценка — 30m/2h/1d (день = 8 ч).
• TaskListFilter.Condition/Orders ← TaskSearchQuery.Fql (GET /tasks?fql=): условие складывается с панелью через AND и действует и на страницу, и на счётчики; ORDER BY из FQL заменяет колонку сортировки (несколько ключей). SQL строит Infrastructure/.../TaskFilterTranslator выражениями (значения через замыкание — параметры, а не константы; C#-семантика null у отрицаний: assignee != X включает задачи без исполнителя). childrenOf, linkedTo, blockedBy биндер разворачивает в наборы Id заранее.
• Подсказки — FqlSuggester.Analyze (слот у курсора по последним токенам) + FqlSuggestQuery → GET /tasks/query/suggest?q=&pos=.
• SavedFilter (Name ≤ 80, Query FQL ≤ 4000, View, Private/Shared) и SavedFilterStar (избранное), Features/Filters: личный чужой — 404, править — автор, удалить — автор или Admin+ для общего; запрос проверяется биндингом при сохранении. Общий фильтр хранит запрос, а не задачи — каждому считается его правами. API /filters (+ PUT/DELETE /filters/{id}/star). Миграция AddSavedFilters.
• Клиент: Components/FqlBar (обычный input с подсказками; CodeMirror-режим FQL отложен) — второй режим поля поиска в топбаре «Задач», а не отдельная полоса: чип «FQL» в SearchBox (OnFql) ставит строку на место поля (при включённой панели — «Показать как FQL»: панель и набранный текст переезжают в запрос), крестик строки возвращает обычный поиск; текст ошибки с подчёркнутым местом — Components/FqlErrorLine под рядом фильтров, FilterMenu, SaveFilterDialog, Services/SavedFiltersState, раздел «Фильтры» в сайдбаре (избранные). Адрес: ?fql=, ?filter={id} — правки открытого фильтра живут в ?fql= до «Сохранить».

Статусы проекта (docs/TZ_workflow_config.md §1, этап 3A)

• Статусы — часть агрегата Board; мутаторы Status internal, менять только через Board: AddStatus, RenameStatus, SetStatusFinal, SetInitialStatus, SetStatusType, ReorderStatuses (полная перестановка), RemoveStatus(id, moveTo). Инварианты: ровно один начальный, минимум один финальный (их может быть несколько), начальный не бывает финальным, имена уникальны без учёта регистра. ReorderStatuses выдаёт SortOrder выше текущего максимума — так unique (BoardId, SortOrder) переживает перестановку без DEFERRABLE. Status.Id — ValueGeneratedNever (иначе новый статус существующего проекта уходит UPDATE'ом).
• Команды StatusCreate/Update/Delete/Reorder — право EnsureCanManageConfig, ответ BoardResponse. Удаление переводит задачи статуса (ITaskItemRepository.GetByStatusIdAsync) в moveTo с StatusChanged в журнале и Upsert в очереди поиска; смена IsFinal ставит Upsert задачам статуса (меняется IsClosed). Эндпоинты: POST /boards/{id}/statuses, PATCH/DELETE /boards/{id}/statuses/{statusId} (DELETE ?moveTo=), PUT /boards/{id}/statuses/order. Клиент — Components/StatusesDialog (+ StatusTypeSelect), подписи видов — StatusColors.TypeLabel.

Workflow (docs/TZ_workflow_config.md §2, этап 3B)

• Board.WorkflowMode (Free — как было, Restricted — только по переходам) и Board.Transitions (StatusTransition: FromStatusId? — null значит «из любого», ToStatusId, Name, условия MinRole/RequireAssignee/RequireChildrenDone/RequireChecklistDone колонками). Меняется только целиком — Board.SetWorkflow(mode, specs): в Restricted без тупиков (DeadEnds() — нефинальный статус без исходящих), иначе 400 с именами. CheckTransition(from, to, ctx) — прямые, потом глобальные, хватает любого с выполненными условиями; причины отказа — русским текстом. Admin/Owner граф не обходят: обход — это переход с MinRole = Admin в самом графе. RemoveStatus уносит переходы статуса; CreateTask в Restricted не в начальный статус — только при глобальном переходе в него.
• Контекст собирает Features/Tasks/TransitionGuard (роль в проекте, исполнитель, чек-лист; подзадачи грузит, только если их требует какой-то переход). Путей смены статуса два — TaskUpdate и перенос на канбане (TaskRankCommand со StatusId), проверка до любых правок, отказ → TaskUpdateResult.TransitionNotAllowed → 400 { message, reasons }; служебный перенос при удалении статуса не проверяется. Новый путь (канбан 2B, смарт-коммиты) обязан звать тот же guard.
• StatusTransitions: FK на доску и оба статуса cascade, unique (BoardId, FromStatusId, ToStatusId) с NULLS NOT DISTINCT; StatusTransitionConfiguration, миграция AddWorkflow. Клиент: Pages/WorkflowPage (/boards/{id}/workflow: режим, матрица с «Из любого», условия по шестерёнке, граф SVG, <text> через MarkupString: Razor его резервирует), StatusSelect в Restricted выключает недоступные статусы с причиной (TaskId/Restricted).
• Workflow по типу задачи (этап 3E): TaskType.OwnWorkflowMode (null — живёт по проектному) и StatusTransition.TaskTypeId (null — проектный); unique (BoardId, TaskTypeId, From, To) NULLS NOT DISTINCT, миграция AddTypeWorkflows. Домен — WorkflowModeFor/TransitionsFor/HasOwnWorkflow/ResetTypeWorkflow, SetWorkflow(…, typeId?), CheckTransition(…, typeId?); TransitionGuard передаёт task.TypeId, поэтому все пути смены статуса учитывают тип сами. API: GET /boards/{id}/workflow?typeId= (inherited), PUT с taskTypeId, DELETE ?typeId=; TaskTypeResponse.HasOwnWorkflow; клиент — «Workflow для» (?type=) на WorkflowPage.
• Редактируемый граф (этап 3D): Status.GraphX/GraphY (null — автораскладка, миграция AddStatusGraphLayout), Board.SetStatusLayout целиком; раскладка — поле layout того же PUT /boards/{id}/workflow (null — не менять, [] — авто) и WorkflowResponse.Layout. Перетаскивание узлов и протягивание перехода — flow.graphAttach (без Drawflow: свой SVG, формула дуги продублирована в JS — graphEdgePath = WorkflowPage.EdgePath), в .NET — только OnNodeMoved/OnConnect.

Шаблоны проектов и перенос конфигурации (docs/TZ_workflow_config.md §4, этап 3F)

• Чертёж — Flow.Domain/Templates/BoardBlueprint (статусы, режим, переходы, типы, поля, экраны, SampleTasks; всё связано локальными ключами, у снимка — Id исходного проекта строкой N, у встроенных — слова), Version = 1. Board.ToBlueprint() — снимок (архивное не входит, на экранах custom:Id → custom:ключ); Board.Create(name, key, blueprint) — проект сразу по чертежу. Живому проекту — ApplyBlueprintStatuses(bp, map) (карта «статус проекта → ключ чертежа», по умолчанию SuggestStatusMap: имя → вид → финальный → начальный; лишние статусы возвращаются в Removals, их задачи переносит вызывающий и зовёт RemoveStatus), ApplyBlueprintTypes/Fields (только добавляют и правят; поле с тем же ключом другого вида — отказ), ApplyBlueprintWorkflow/Screens (заменяют целиком; совпадающий экран правится на месте), Map* — без правок.
• Встроенные шаблоны — Domain/Templates/BuiltInBoardTemplates (постоянные Id 0f10a000-…-00000000000N): «Простой», «Kanban» (WIP), «Scrum», «Баг-трекер» (Restricted, поля, экран создания). Сохранённые — BoardTemplate (таблица BoardTemplates, Payload jsonb + Version, миграция AddBoardTemplates); JSON — Features/Templates/BoardBlueprintJson (enum строками, апгрейдер версий, версия новее текущей — отказ). Битый шаблон из списка выпадает, а не роняет его.
• Команды — Features/Templates: BoardTemplateList/Save/Delete (сохранить и удалить — глобальный Admin+ через EnsureCanCreateBoard, плюс ManageConfig проекта; встроенный не удаляется — 400), BoardCreateCommand(…, TemplateId) (неизвестный — 400; образцы задач — в начальный статус с журналом Created), BoardApplyConfigPreviewQuery/BoardApplyConfigCommand (ConfigParts флагами). Применение — BoardConfigApplier: служебный перенос задач лишних статусов с StatusChanged и Upsert, переиндексация статусов со сменой финальности. Права на все цели проверяются до первой правки; каждая цель — своя транзакция (IUnitOfWork.InTransactionAsync), отказ — DiscardChanges и строка результата, остальные идут дальше; нет изменений по снимку до/после — ничего не пишется (Changed = false). Имена статусов пишутся в два шага (Board.ParkStatusNames/RestoreStatusNames): обмен имён — цикл по unique (BoardId, Name), одним UPDATE его не сохранить.
• API: GET /board-templates, DELETE /board-templates/{id}, POST /boards/{id}/save-as-template (201), /boards/{id}/apply-config/preview, /boards/{id}/apply-config; POST /boards принимает templateId. Клиент: выбор шаблона в CreateBoardDialog (статусы, типы, поля под выбором, «Удалить шаблон» у сохранённого), SaveTemplateDialog и ApplyConfigDialog из меню карточки проекта (RowMenu.ShowSaveTemplate/ShowApplyConfig).

Шаблоны задач (docs/TZ_workflow_config.md §5, этап 3G)

• TaskTemplate — отдельный агрегат проекта (таблица TaskTemplates, миграция AddTaskTemplates): Name ≤ 80 (уникально в проекте без учёта регистра — хендлер), TitlePattern ≤ 500 с {date} (дд.мм.гггг, дата UTC) и {n} (UsageCount + 1, RenderTitle), TypeId? (FK SetNull), Priority, Description, значения полей — jsonb CustomFields (как у задачи, нормализует CustomFieldValidator), чек-лист — text[], подзадачи — jsonb Subtasks (TaskTemplateSubtask(Title, TypeId?, Checklist), до 20), SortOrder, UsageCount. Типы шаблона и подзадач — свои, не архивные, подзадача строго ниже типа шаблона.
• Права — ProjectPermission.ManageTaskTemplates (Developer+, EnsureCanManageTaskTemplates); список видят все, кто видит проект. Features/TaskTemplates/TaskTemplateFeatures.cs: List/Create/Update (полная замена)/Delete и TaskTemplateFromTaskCommand (снимок задачи: тип, приоритет, описание, живые поля, чек-лист, прямые подзадачи по рангу).
• Создание по шаблону — TaskCreateCommand.TemplateId: название, тип, приоритет, описание и поля присылает форма (человек мог поправить), сервер добавляет чек-лист и подзадачи той же транзакцией (тип подзадачи — свой, если ниже родителя, иначе ближайший уровнем ниже, при равных — по умолчанию; обязательные поля — значением родителя; журнал Created + ChildAdded, Upsert в поиске; ранги сразу за родителем, пересчитываются вместе с ним при конфликте) и MarkUsed. Шаблон чужого проекта — 400. Повторяющиеся задачи по-прежнему живут от задачи-образца.
• API: GET/POST /boards/{id}/task-templates (201), PUT/DELETE /task-templates/{id}, POST /tasks/{id}/save-as-template (201); POST /boards/{id}/tasks принимает templateId. Клиент: «Шаблон» в форме создания (TaskDrawer, заполняет поля заново), TaskTemplatesDialog (значок «Шаблоны задач» в топбаре «Задач»), SaveTaskTemplateDialog из меню задачи (RowMenu.ShowSaveTemplate).

Экраны задач (docs/TZ_workflow_config.md §3, этап 3C)

• TaskScreen — часть агрегата Board (таблица TaskScreens: TaskTypeId? — null значит «все типы», Context Create/Detail, Fields — jsonb списка ScreenField(Field, Required, Section), где Field = system:<имя> или custom:<Id поля>; unique (BoardId, TaskTypeId, Context) NULLS NOT DISTINCT, Id — ValueGeneratedNever). Мутации — Board.SetScreen (целиком) и ResetScreen; выбор — Board.ResolveScreen(typeId, context): тип → все типы → встроенный ScreenFields.Default (все поля в прежнем порядке, проект без экранов выглядит как раньше). Скрытое поле значение не теряет.
• На Create — только ScreenFields.OnCreate (тип, приоритет, исполнитель, описание) и пользовательские поля; их «обязательные» проверяет TaskCreateCommandHandler (Board.MissingOnCreateScreen, 400). Исполнитель теперь приходит в TaskCreateCommand.AssigneeId (права — EnsureCanAssign, человек активен), без отдельного PATCH. «Обязательное» на Detail — только подсветка .meta-k.req.
• Команды ScreenSet/ScreenReset (ManageConfig, ответ BoardResponse, в нём Screens). Клиент считает раскладку сам — Services/ScreenLayout повторяет правило сервера; TaskDrawer, TaskPage и форма создания рисуют строки по раскладке (SystemValue(name) — фрагмент на системное поле, CustomFieldsEditor FieldIds=[id] — на пользовательское), статус всегда первым. Редактор — Components/ScreensDialog (значок «Экраны задач» в топбаре «Задач»).
• Переход с RequireFields (колонка uuid[] у StatusTransitions): Board.CheckTransition смотрит TransitionContext.FilledFields (заполненные поля задачи — собирает TransitionGuard), причина «Заполните поле «X»»; в WorkflowPage — мультиселект «Заполнены поля». Миграция AddScreensAndRequireFields.

Канбан (docs/TZ_task_views.md §1, этап 2B)

• Экран «Задачи» — виды список, доска, дерево, бэклог, календарь и роадмап (?view=list|board|tree|backlog|calendar|roadmap, по умолчанию UserPreferences.TasksView, колонка PrefTasksView). Доска — Components/KanbanBoard на MudDropContainer поверх GET /tasks/board (TaskBoardQuery): в проекте колонки — статусы, карточки по Rank; в «Все проекты» — виды статусов + «Другие» (без вида, пустая скрыта), карточки по UpdatedAt. Фильтры те же, что у списка (FQL-ORDER BY не действует); первые 50 на колонку + Count, догрузка — колонка с offset.
• Финальные колонки показывают задачи, сменившие статус за Board.DoneColumnDays (по умолчанию 14; PUT /boards/{id}/done-column-days, ManageConfig) — по TaskItem.StatusChangedAt, который ставит UnitOfWork при изменении StatusId (фильтр TaskListFilter.DoneWindowAt, окно — из проекта каждой задачи). Status.WipLimit (1…999, PATCH статуса wipLimit/clearWipLimit) — мягкий: только красный заголовок. Миграция AddKanban (StatusChangedAt — из журнала).
• Перенос карточки — TaskRankCommand(…, StatusId): смена статуса через TransitionGuard, журнал StatusChanged, Upsert в поиске; без соседей можно только со StatusId. Отказ — TaskUpdateResult.TransitionNotAllowed → 400 { message, reasons } (общий SendUpdate и в контроллере, и в InProcessFlowApi). Клиент: оптимистично, откат с тостом; колонки, куда нельзя, тускнеют при взятии карточки (GET /tasks/{id}/transitions), сброс — по TransactionEnded контейнера: dragend MudBlazor до родителя не доходит. Зоны MudDropZone после смены списка нужно Refresh() — сами не перерисуются.
• Дорожки (исполнитель/родитель/приоритет) раскладывает клиент по загруженным карточкам; через дорожки не переносят. В «Все проекты» перенос только меняет статус (первый статус вида в проекте задачи), в «Другие» бросать нельзя. Клавиатура на карточке: ←/→ — соседняя колонка, ↑/↓ — соседняя карточка, Enter — слайдер. «+ Задача» внизу колонки — быстрое создание в статусе.

Спринты и бэклог (docs/TZ_task_views.md §2, этап 2D)

• Sprint — отдельный агрегат (не коллекция Board): Name ≤ 60, Goal ≤ 500, StartDate/EndDate : DateOnly?, State Planned/Active/Completed, SortOrder. Start — только из Planned, даты обязательны, снимок SprintCommitments(Kind = Committed, StoryPoints); Complete(openTasks, moveOpenTo) — незакрытые уходят в другой незавершённый спринт или в бэклог и пишутся CarriedOver (без этого отчёт не собрал бы «не сделано» после переноса); закрытые остаются навсегда. Один Active на проект — хендлер (400) и частичный unique IX_Sprints_BoardId_Active. Удалить можно только Planned (задачи — в бэклог с журналом). TaskItem.SprintId (FK SetNull, SetSprint — тот же проект, не в завершённый); журнал SprintChanged (Id спринта строкой, null — бэклог).
• Права — ProjectPermission.ManageSprints (Developer+, EnsureCanManageSprints); перенос задачи — правка задачи (EnsureCanEditTask). Оба пути переноса (TaskSetSprint и TaskRankCommand со SprintId/ToBacklog) идут через Features/Sprints/TaskSprints.MoveAsync — новый путь обязан звать его же.
• BacklogQuery (GET /boards/{id}/backlog, фильтры списка + epicId): секции активный → запланированные → «Бэклог» (незакрытые без спринта), внутри — Rank, суммы и нагрузка по исполнителям — сервер. Эпик задачи — ближайший предок вида Epic по GetTreeAsync, сами эпики в секции не попадают.
• SprintReportQuery (GET /sprints/{id}/report): взято/добавлено/сделано/не сделано (задачи и SP), burndown откатом журнала (StatusChanged, SprintChanged, StoryPointsChanged) назад от текущего состояния по концам дней; кандидаты — GetTaskIdsWithValueAsync(SprintChanged, id) + нынешние задачи спринта. Точки — на весь спринт, у будущих дней Remaining = null; идеальная линия — прямая от SP на старте.
• FQL sprint: имя, openSprints(), closedSprints(), EMPTY (IFqlLookup.SprintsAsync, FqlLookup принимает ISprintRepository). Миграция AddSprints.
• Клиент: ?view=backlog (TaskView.Backlog, только в проекте) — Components/BacklogView (панель эпиков, MudDropContainer с зонами «спринт/backlog», оптимистичный перенос с откатом, SprintDialog для создания/правки/старта/завершения на MudDatePicker + Ru.PickerCulture), поле SprintSelect в карточке и слайдере, Pages/SprintReportPage (/boards/{id}/sprints/{sprintId}/report: плитки, MudChart линией — палитра #D07E1F/#3A9D6E проверена против тёмной поверхности, «идеальная» пунктиром, таблица задач).

Вехи (docs/TZ_task_views.md §6, этап 2E)

• Milestone — отдельный агрегат: Name ≤ 80 (уникально в проекте без учёта регистра — MilestoneNames, плюс unique (BoardId, Name)), Description ≤ 2000, TargetDate, State Open/Closed (Close/Reopen), SortOrder. TaskItem.MilestoneId (FK SetNull, индекс), SetMilestone — веха того же проекта, в закрытую новые не добавляются. Журнал MilestoneChanged (Guid строкой). Удаление — через хендлер: снимает веху с задач с журналом, FK SetNull только страхует.
• Права — ProjectPermission.ManageMilestones (Developer+, EnsureCanManageMilestones); поле задачи — EnsureCanEditTask, путь один — Features/Milestones/TaskMilestones.MoveAsync.
• Прогресс — ITaskItemRepository.CountByMilestonesAsync (один GROUP BY с join статусов) + MilestoneProgressCalculator (прогноз по закрытым за 14 дней, StatusChangedAt); любой MilestoneResponse собирается только через него. Команды и запросы — одним файлом Features/Milestones/MilestoneFeatures.cs, как Filters.
• FQL milestone: имя, openMilestones(), closedMilestones(), EMPTY. FqlFields.Future пуст (team появился на этапе 4D). Миграция AddMilestones.
• Общие вехи (этап 2H): Milestone.SharedBoardIds (uuid[], миграция AddSharedMilestones), IsAvailableIn(boardId) в SetMilestone/TaskMilestones; GetByBoardAsync отдаёт и общие; PUT /milestones/{id}/boards (MilestoneShareCommand: ManageMilestones во владельце и в каждом добавляемом, занятое имя — 400, из убранного проекта задачи выходят с журналом); видно из любого проекта вехи, правит владелец.
• Клиент: Pages/MilestonesPage (/boards/{id}/milestones, значок в топбаре «Задач»), Pages/MilestonePage (/milestones/{id}: плитки, MilestoneProgressBar — MudProgressLinear с буфером «в работе», задачи по FQL), MilestoneDialog, поле MilestoneSelect в карточке и слайдере.

Календарь и роадмап (docs/TZ_task_views.md §4–5, этап 2F)

• Календарь: TaskCalendarQuery → GET /tasks/calendar?from=&to= (+ фильтры списка): задачи, чей отрезок [StartDate ?? DueDate, DueDate ?? StartDate] пересекает окно (≤ 100 дней), лимит 1000 и Truncated; условие окна — узлы TaskFilter (TaskCalendarQueryHandler.Window), без своего SQL. Клиент — Components/TaskCalendar (TaskView.Calendar, ?view=calendar, в т. ч. «Все проекты»): месяц/неделя, задача в каждом дне отрезка, 4 в ячейке + «ещё N», перенос на день — MudDropContainer → PATCH /tasks/{id}/schedule со сдвигом обеих дат.
• Роадмап: Components/TaskRoadmap (TaskView.Roadmap, только в проекте) — поверх GET /boards/{id}/tree, вех проекта и GET /boards/{id}/blocks (стрелки Blocks внутри проекта, BoardBlockLinksQuery). Выведенные даты «по подзадачам» (пунктир) считает клиент обратным проходом по обходу; шкала неделя/месяц/квартал, «сегодня», вехи, «Без дат». Этап 2H: полосы тянутся (тело — обе даты, края — одна, ромб — единственная, «Без дат» — на день шкалы неделей) через flow.roadmapAttach — движение в JS, в .NET только итог в днях → PATCH /tasks/{id}/schedule; выведенные не тянутся, право — CanEdit от Tasks.razor.

Дашборды (docs/TZ_task_views.md §8, этап 2G)

• Dashboard (Name ≤ 80, Visibility : SavedFilterVisibility, IsDefault — стартовый у владельца) и DashboardWidget (WidgetType TaskList/Counter/Breakdown/CreatedVsClosed/SprintBurndown/MilestoneProgress/Markdown, Title ≤ 80, Config jsonb, X/Y/W/H в сетке 12 колонок, H ≤ 8), до 30 виджетов; без места — первое свободное. Таблицы Dashboards/DashboardWidgets, миграция AddDashboards.
• Features/Dashboards/DashboardFeatures.cs (CRUD, первый свой — стартовый) и WidgetDataQueryHandler: данные — правами смотрящего, ошибка виджета — поле error (200), не исключение. Конфиг чистится по виду при сохранении, FQL биндится правами автора. Разбивка — ITaskItemRepository.GroupCountAsync (GROUP BY; cf:<ключ> — в памяти по jsonb), не больше DashboardLimits.MaxGroups = 7 групп + «Другие»; «создано / закрыто» — DailyCountsAsync (закрытые — финальный статус по StatusChangedAt); burndown и веха — через SprintReportQuery/MilestoneGetQuery. Права — EnsureCanEditDashboard (автор), EnsureCanDeleteDashboard (автор, общий — ещё Admin+).
• Клиент: /dashboards, /dashboards/{id} (CSS grid, строка 90px), DashboardWidgetView, WidgetDialog, DashboardDialog, общий BurndownChart; StartPage.Dashboard (PrefStartPage = 3) уводит корень на свой стартовый дашборд. Этап 2H: автор переставляет виджеты перетаскиванием (шапка — место, уголок — размер) через flow.gridAttach, итог в клетках → PATCH виджета; наложения сервер не запрещает.

Дерево (docs/TZ_task_views.md §3, этап 2C)

• Третий вид экрана «Задачи» — ?view=tree (TaskView.Tree), только внутри проекта: в «Все проекты» кнопка выключена, вид из настроек падает на список. Components/TaskTree поверх GET /boards/{id}/tree — тот же MudDataGrid (.flow-grid tree-grid), что у списка: строки — видимые узлы в порядке обхода (Items), отступ и стрелка — в первой колонке, прогресс — MudProgressLinear Color.Success.
• TaskTreeQuery принимает фильтры списка (исполнитель, текст, вид типа, приоритет, статус, FQL — его ORDER BY не действует) и MaxDepth. Дерево проекта берётся целиком (GetTreeAsync), подходящие Id — ITaskItemRepository.MatchingIdsAsync тем же SQL-фильтром, что список; дальше в памяти одним обратным проходом: узел виден, если подходит или подходит кто-то в его поддереве (тогда IsContextOnly), VisibleChildCount — видимые дети, Progress — всё поддерево без фильтра (задачи и story points, всего/закрыто). MaxDepth режет по глубине от корня обхода.
• Клиент грузит два верхних уровня (maxDepth = 1), ветку глубже — при раскрытии (rootId = узел, maxDepth = 1, глубины сдвигаются к месту узла); при фильтре или раскрытых глубоких ветках — всё сразу. Смена статуса в строке перечитывает дерево (прогресс предков). Клавиатура: ↑/↓, → раскрыть/к ребёнку, ← свернуть/к родителю, Enter — слайдер. Родитель меняется полем в слайдере, перетаскивания нет.

Права (docs/TZ_user_roles.md, #18)

• Все изменяющие команды Boards/Tasks/Users начинаются с Guid ActorId (контроллеры берут его из IActorAccessor.Require() — claim sub). Запросы (чтение) тоже начинаются с ActorId (этап 4B): им он нужен для видимости приватных проектов.
• Хендлер: ActorResolver.ResolveAsync(ActorId) (нет профиля или Deactivated → UnauthorizedActorException → 401) → IPermissionService.Ensure* (→ ForbiddenException → 403) → бизнес-инварианты (InvalidOperationException → 400). Матрица глобальная: EnsureCanCreateBoard Admin+; EnsureCanManageUsers/EnsureCanCreateUser Admin+ (Admin не выдаёт Admin/Owner, роль не выше своей); EnsureCanEditProfile сам или Admin+; EnsureCanEditCredentials (username/email/пароль) сам или Owner; EnsureCanDeactivate Owner; EnsureCanChangeRole Admin+, не выше своей, себя не повышать, Admin — только цели и роли ниже Admin.
• «Последний Owner» — в UserChangeRoleCommandHandler через CountByRoleAsync (400). Owner нельзя деактивировать (домен; UserDeactivate проверяет до вызова Auth-модуля). UserChangePassword: свой — с текущим паролем (иначе 400), чужой — сброс Owner'ом без текущего.
• Где что проверяется, чтобы одно правило не проверялось дважды: инвариант сущности — в Flow.Domain.Tests; поведение хендлера (лимиты, права, очередь индексации, журнал) — в Flow.Application.Tests на фейках; SQL, каскады, миграции и всё, что зависит от Postgres или S3, — в Flow.Infrastructure.Tests; Flow.Api.Tests — только то, чего нет ниже: коды ответов, заголовки, авторизация и разбор query-string. Api-тест, повторяющий бизнес-правило, — это дубль: правило уже проверено там, где живёт.
• Права внутри проекта (docs/TZ_project_access.md, этап 4A) — не по User.Role, а по роли в проекте: ProjectRole (Viewer < Member < Developer < Admin), права — ProjectPermission, роль → набор прав — Security/ProjectRoles.PermissionsOf (таблица только на сервере; клиент получает список прав). Роль считает IProjectAccess.GetAsync(actor, boardId) = максимум из «по умолчанию» (UserRole.ToProjectRole(): Reader→Viewer, Member→Member, Developer→Developer, Admin/Owner→Admin; срезается потолком Board.DefaultRole, кроме глобальных Admin+) и прямого участия BoardMember (PK (BoardId, UserId), отдельная сущность, не коллекция доски). Без участников и потолка роль равна глобальной — поведение прежнее, старые PermissionTests не менялись. Запретов (deny) нет. Кэша нет намеренно: scope не всегда равен запросу (корневой провайдер в тестах), а снятие участника должно действовать сразу. Проверки: EnsureCanCreateTask(access); EnsureCanEditTask/Assign(actor, access, task) — EditAnyTask/AssignAnyone либо EditOwnTask на своей задаче (удаление задачи — это правка, как раньше); EnsureCanComment(access), EnsureCanEditComment — автор с правом Comment, EnsureCanDeleteComment — автор или DeleteAnyComment; EnsureCanAttach, EnsureCanDeleteAttachment — аналогично; EnsureCanRenameBoard (RenameProject), EnsureCanManageConfig (типы задач), EnsureCanManageMembers(access, role) — роль не выше своей; EnsureCanDeleteBoard(actor, access) — глобальный Admin+ и DeleteProject. Хендлер берёт роль по BoardId задачи/вложения/комментария (для комментария — через его задачу). Участника нельзя добавить деактивированным или несуществующим (400); уже добавленный остаётся (история), права отсекает ActorResolver. - Приватные проекты (этап 4B): Board.Visibility : BoardVisibility (Open 0 — как было, Private 1; PUT /boards/{id}/visibility, ManageMembers). В приватном проекте роль даёт только участие (роль по умолчанию не действует), глобальные Admin/Owner — администраторы и там; ProjectRoles.Effective возвращает null — проект не виден. Невидимое — 404, а не 403: запросы чтения отвечают null/пусто, а любая Ensure* на скрытом проекте бросает ProjectNotFoundException (→ 404 в ApiExceptionFilter и InProcessFlowApi.Guard), иначе код задачи в ссылке подтверждал бы её существование. Все запросы чтения получают ActorId: BoardList/Get, TaskList/Get/Search, TaskCommentList, TaskActivityList, AttachmentList/Meta/Content (значит, и /files/{id} — FilesController берёт actor из cookie через IActorAccessor), BoardMembers, BoardMyAccess (скрытые в ответ не попадают), SimilarTasks, Search. Списки фильтруются IProjectAccess.VisibleBoardIdsAsync (null — глобальный Admin+ или приватных проектов нет вовсе, и фильтра нет): TaskListFilter.VisibleBoardIds (и страница, и счётчики), SearchCriteria.VisibleBoardIds — в CommonFilter обеих половин поиска (чанки без проекта — люди — видны всем), FindSimilarAsync(…, visibleBoardIds) — внутри HNSW-подзапроса, иначе окно ближайших заполнили бы невидимые. В разборе строки поиска скрытый проект не резолвится ни по проект:KEY, ни по коду задачи — остаётся текстом. В приватном проекте нельзя снять или понизить последнего участника-администратора (400). Справочник людей общий.
• Группы (этап 4C): Group (Name ≤ 80, уникально без учёта регистра — хендлер, плюс unique-индекс), GroupMember (PK (GroupId, UserId), индекс UserId) и BoardGroup (PK (BoardId, GroupId), Role, индекс GroupId) — отдельные сущности, каскад от группы и от проекта; миграция AddGroups. Роль участия в BoardAccessData.MemberRole — уже максимум из прямого участия и ролей групп человека (подзапрос MAX в том же запросе, что и раньше; ProjectRoles.Effective о группах не знает), видимость приватного проекта — участие напрямую или через группу. Справочник групп — Features/Groups/GroupFeatures.cs: читают все, меняют глобальные Admin+ (EnsureCanManageGroups), добавляют только активных людей; роль группы в проекте — BoardGroupSet/Remove (ManageMembers, не выше своей), ответ — BoardMembersResponse с Groups (собирает IBoardMemberRepository.MembersResponseAsync). Правило «последний администратор приватного проекта» считает только прямых участников. API: /groups (GET/POST 201, PATCH/DELETE /groups/{id}, PUT/DELETE /groups/{id}/members/{userId}), PUT/DELETE /boards/{id}/groups/{groupId} ({ role }). Клиент: вкладка «Люди → Группы» (Components/GroupsPanel), раздел «Группы» в ProjectAccessDialog.
• Команды (этап 4D): команда — группа с Group.IsTeam (миграция AddTeams), отдельной сущности нет. TaskItem.TeamId (FK → Groups SetNull, индекс) — сущность workspace, при переносе задачи сохраняется; TaskSetTeamCommand → PATCH /tasks/{id}/team ({ teamId }, правка задачи; не команда — 400, прежняя команда остаётся у задачи, но новой не назначается), журнал TeamChanged. Системное поле экрана team (Detail, после исполнителя; клиент прячет строку, пока команд нет). FQL team = имя | myTeams() | EMPTY (IFqlLookup.TeamsAsync, FqlLookup принимает IGroupRepository). Клиент: флаг «Команда» в «Люди → Группы», Components/TeamSelect + Services/TeamDirectory (один GET /groups на circuit, сброс после правок групп), дорожки «Команда» на канбане.
• Наборы прав (этап 4E): PermissionSet (Name ≤ 60 уникально — хендлер + unique-индекс, BaseRole — место на лестнице, не меняется; Permissions — int[], ViewProject всегда; миграция AddPermissionSets). Встроенные наборы — сами роли (ProjectRoles.PermissionsOf), в коде, с постоянными Id PermissionSetRoles.BuiltInId(role), не правятся и не удаляются — свой делают клонированием. BoardMember.PermissionSetId/BoardGroup.PermissionSetId (FK SetNull): участие со своим набором хранит Role = BaseRole, поэтому «не выше своей», максимум ролей и «последний администратор» не изменились. Права — ProjectRoles.Resolve: роль прежняя (максимум), права — объединение источников: роль по умолчанию (в открытом проекте) и каждое участие (BoardAccessData.Grants: прямое и через группы, набор или права роли); наборы грузятся отдельным запросом только если участия на них ссылаются. Глобальные Admin+ — администраторы, как раньше. SetBoardMemberRequest(Role, PermissionSetId?) для участников и групп (встроенный Id — просто роль). Features/PermissionSets: список читают все, правит Owner (EnsureCanManagePermissionSets). API /permission-sets (GET, POST 201, PATCH/DELETE /{id}; встроенный — 400). Клиент: «Настройки → Наборы прав» (Components/PermissionSetsMatrix, Admin+ видит, Owner правит галочками, «Клонировать»), свои наборы в ProjectRoleSelect (Sets/SetId/OnSetChange) в «Доступе» проекта, подписи прав — Permissions.PermissionLabel.
• Тесты: PermissionTests — по тесту на строку матриц, ProjectAccessTests — расчёт роли и таблица §2/§4 ТЗ проекта; TestMediatorFactory и PostgresFixture сеют Owner (OwnerId) — actor по умолчанию в остальных тестах.
• Учётная запись живёт в Auth-модуле, профиль — в ядре; связь по одному Guid. UserCreate(…, Password) сначала in-process создаёт учётную запись через IAccountService.CreateAsync(user.Id, …), и только при успехе — профиль; UserChangeUsername/UserChangeEmail — сначала Auth-модуль, потом копия в Users (нормализуют через домен, откатывают, проверяют, применяют — иначе Fake-репозиторий «находит» самого пользователя); UserDeactivate/UserActivate — DisableAsync/EnableAsync до смены статуса; UserChangePassword(UserId, CurrentPassword?, NewPassword) — только Auth-модуль. Отказ Identity по вводу → ArgumentException → 400.
• Уникальность username/email: локальная копия — быстрый 409 без вызова Auth-модуля (UserCreateResult.IsUsernameTaken/IsEmailTaken, UserUpdateResult.ConflictError); источник истины — Identity (AccountResult.UsernameTaken/EmailTaken); плюс unique-индексы в БД.
• Features/Bootstrap/SeedBootstrapUserCommand — профиль базового пользователя с заданным Id (User.CreateWithId); учётную запись с тем же Id сеет Auth-модуль. Повтор — no-op. Оба сидера запускаются в одном хосте Flow.Api. UserGetMeQuery(ActorId) — профиль текущего actor (null → 401).
• Все изменяющие команды пользователя возвращают общий Features/Users/UserUpdateResult (NotFound | ConflictError | Success). UserUpdateProfile — PATCH-семантика: null не трогать, пустая строка очищает.
• Назначение на задачу: TaskItem.AssigneeId : Guid?, Assign/Unassign; назначать можно только активного пользователя — проверяет TaskAssignCommandHandler (TaskAssignResult: NotFound | ValidationError | Success). TaskListQuery(boardId, assigneeId?) фильтрует по исполнителю.
• IUserRepository.SearchAsync — автодополнение для @ (ILIKE по Username/FirstName/LastName, только активные, %/_ экранируются). GetByUsernamesAsync — резолв @упоминаний одним запросом (деактивированных не фильтрует).

Лента задачи: комментарии, журнал, срок (docs/TZ_task_activity_comments.md)

• TaskActivity — append-only журнал: Type : TaskActivityType (Created, TitleChanged, DescriptionChanged, StatusChanged, AssigneeChanged, DueDateChanged, CommentAdded, CommentDeleted, AttachmentAdded/Removed, PriorityChanged, StartDateChanged, StoryPointsChanged, EstimateChanged, TypeChanged), OldValue/NewValue строками (Guid статуса/пользователя/типа, yyyy-MM-dd для дат, число enum'а для приоритета, invariant-число для оценок, текст для названия, null для описания). Создаётся только фабриками по типу (TaskActivity.StatusChanged(taskId, actorId, old, new) …), мутаций нет. Пишут хендлеры Application (TaskCreate → Created; TaskUpdate — по записи на каждое реально измен

Truncated - read the full file at https://github.com/azizmac/Flow/blob/a0b0ee3564cd363971a7f0ed613167301ba002ac/AGENTS.md.