Назначение эпика: управление задачами и их полным жизненным циклом — список/фильтрация задач и issue-задач, детальная карточка задачи (Details / Requirements / Costs / History) и календарный вид задач по сотрудникам. Центральный операционный экран back-office: сюда стекаются задачи из сервисов (Planned), разовых заявок (Direct), резерваций (Reservation) и инцидентов (Issue).
Участвует в use-cases: UC-1 (recalculation engine → Tasks), UC-2 (исполнение задач), UC-3 (issue → linked task), UC-5 (cost-учёт → Maintenance Report).
Сущности (owns/touches): owns — Task (+ TaskRequirement, TaskCost, TaskEvent, Attachment, Comment). touches — Unit, UnitArea, Employee (owner/assignment), Service/TaskTemplate (источник service-tasks), Issue (linked_task), Reservation.
Экраны: S13 (Tasks list: вкладки All Tasks / Issues), S20 + S25 + S21 + S29 (Task Detail — один экран с вкладками Details / Requirements / Costs / History; «Copy of …»-дубли сведены), S44 (Schedule — календарный вид задач per employee).
Открытые findings: F-filter-hierarchy-assignee (00-overview §3 — модель доступа Vendors к задачам не уточнена); тексты-заглушки в Requirements/Comments — реальные лейблы уточнить у заказчика (technical §Tech debt).
Task: id, name, type[Direct|Schedule|Issue|Reservation], status[Planned|New|In Progress|Finished],
unit, area, department, subdepartment, owner, assignment[], priority,
created_at, due_at, finished_at, started_at, total_time, on_track(bool),
template_id?, service_id?, issue_id?, locked(bool)
Task ─< TaskRequirement (area → tasks + reference + photo + comment)
Task ─< TaskCost (name, type[Task|Hour|Items|Supplies], direct_cost, invoice, total)
Task ─< TaskEvent (time, user, event, before, after) # history
Task ─< Attachment, Comment
Check Wifi.service_id + template_id. Может быть locked (engine не трогает при пересчёте).issue_id, связана обратной ссылкой Issue.linked_task. Пример: Plumbing Repair.service_id + ссылку на reservation. 🟡 [не было додумано] в каталоге S13 type Reservation в строках не встречается явно (видны Direct/Issue), но тип объявлен в модели Task — оставляем как фильтр-значение, источник = recalc по reservation-триггеру (overview §5). (engine: создаёт Schedule/Reservation-task)
│
▼
┌───────────► Planned ──(наступил день/активирована вручную)──► New
│ (Direct/Issue │
│ создаются (assignee начал работу — старт таймера)
│ сразу как New) ▼
│ In Progress
│ (все requirement-задачи отмечены done /
│ assignee завершил, фиксируется finished_at)
│ ▼
└────────────────────────────────────────────────────────► Finished
Описание переходов:
Created Task → New, отдельного Planned→New-события в каталоге нет) — обоснование: статус Planned обязан где-то стать New, иначе задача не доходит до исполнителя.started_at, запускается total_time. Подтверждено событием S29: Changed Task status: New → In Progress (user Sarah Martinez, 13:00).finished_at, фиксируется total_time (S20 показывает Started 11:00, Finished 13:05, Total Time 2h 05m), вычисляется on_track (finished_at ≤ due_at). Дальше задача попадает в snapshot Maintenance Report (E06).3458764671320125392 (canvas x=4275 y=7963, 1440×900). Вкладка Issues делит экран и шапку фильтров с S15 (id 3458764672845971639) — это тот же экран в состоянии вкладки Issues; detail issue-строки принадлежит эпику E05.Tasks → строка вкладок All Tasks | Issues → панель фильтров (5 dropdown + поиск) → data-table → переход в Task Detail по строке (right-side detail / отдельный экран).ID, Task Name, Task (тип задачи / задача-источник), Created, Due, Finished. Дополнительно в строках видны Department (Operations), owner (Sarah Martinez), type-чип (Direct / Issue), status-чип (Planned). Примеры строк: 1 · AC Maintenance · Operations · Planned, 2 · Check Wifi · Direct, 3 · Plumbing Repair · Issue.ID, Unit, Issue, Description, Reported at, Department, Sub Department, Reported by, Linked Task, Linked Task Status. (Контент detail — эпик E05; здесь — только список как вкладка реестра задач.)All Tasks / Issues — tab → переключает набор колонок и источник (Task vs Issue).Department — dropdown (Operations / Housekeeping Coordinator / Handyman / Accounting / Property Services / Owner Services / Vendors) → фильтр по department.Unit — dropdown → фильтр по объекту.Status — dropdown (Planned / New / In Progress / Finished) → фильтр по статусу.Task Type — dropdown (Direct / Schedule / Issue / Reservation) → фильтр по типу. (В контенте видны значения Maintenance/Cleaning/Inspection/Maintenance Issue — это category-значения шаблонных секций; 🟡 [не было додумано] трактуем dropdown Task Type как фильтр по Task.type, а перечисленные категории — как вторичную группировку из TaskTemplate.category; уточнить у заказчика.)Assignment — dropdown → фильтр по назначенному исполнителю.All Tasks (default), tab Issues; filtered (применены dropdown'ы); empty (нет задач под фильтр); loading; error.Task (+ join Unit, Employee owner/assignment, Issue для linked); строки порождаются engine S46 (Schedule/Reservation), ручным созданием (Direct), эскалацией Issue (E05). Клик → Task Detail. Вкладка Issues читает Issue.+ Add Task (controls: только 5 dropdown + 1 input). Но Direct-задачи должны откуда-то создаваться. Минимально: фиксируем, что ручное создание Direct-задачи существует (вероятно из карточки Unit→Tasks или отдельной +-кнопкой) — точку входа уточнить у заказчика, в этом эпике не достраиваем UI создания.Finished пустая для не-Finished задач — это нормальное состояние (см. edge cases).Finished/Due пустые для Planned/New; длинные Task Name — усечение с tooltip; Vendor без прав на строку — строка скрыта; задача без owner/assignment — пустые ячейки (валидно до назначения).Один экран с общей шапкой и 4 вкладками. «Copy of …»-дубли S20/S25/S21/S29 = состояния вкладок Details / Requirements / Costs / History. Не плодить компоненты — один tabbed detail-view.
Details (id 3458764671320866892), S25 Requirements (id 3458764671459037363), S21 Costs (id 3458764671465447325), S29 History (id 3458764671463726827); все canvas 1440×900, кластер Units x≈6081 y≈8000–11000.Details | Requirements | Costs | History → тело активной вкладки → секция Comments (общая, присутствует на Details/Costs/History) → Attachments.Task Name, Unit (Villa Alaya), task_id 120324, Started at (11:00 12 May 2026), Finished at (13:05 12 May 2026), Total Time (2h 05m), On Track (bool-чип).Department: Operations · Owner: Sarah Martinez + + change owner · Subdepartment: Maintenance · Assignment: (список назначенных, каждый с remove) + + add assignee · Task: AC Maintenance · Item: (+ remove) · System Item: · Description: · Due: (May 12, 2026 · 15:00) · Priority: Standard · Comments · Attachments: + + add attachment.+ change owner (button → смена owner), + add assignee / remove (button → правка assignment[]), + add attachment (button → upload в Attachment), Comments (input → добавить Comment). Priority — dropdown (Standard / …; др. значения 🟡 не перечислены в каталоге — минимум Standard; шкалу уточнить).update Task.owner, add/remove Task.assignment[], update Task.due_at, update Task.priority, create Comment, create Attachment. Каждая мутация → пишет TaskEvent (см. History).Check In: / Check Out: · Villa Alaya · адрес (Jl. Raya Semat No.88, Canggu…) · блок Areas → по каждой зоне (Bedroom 1, Bedroom 2, …): список Task + Task Description … + comment … + Area Photos + Comments.Area Photos — галерея (на desktop read; добавление фото — mobile-исполнение E04). 🟡 [не было додумано] на desktop Requirements преимущественно read/конфиг (нет явных контролов в каталоге — input_button×1 = общая + шапки); отметка выполнения и заливка фото происходят на mobile (E04). Обоснование: разделение field-исполнения (mobile) и back-office-просмотра (desktop) задано архитектурой клиентов.TaskRequirement (area → tasks/reference/photo/comment).Cost Name | Details | Direct Cost | Invoice | Total; группы затрат:
Task Cost (2,000,000.00 IDR / 2,500,000.00 IDR)Light Bulb, Pool Pump, Pool Pump (по строке Direct/Invoice)New Linen+ add cost · Comments.+ add cost (button → новая строка TaskCost, выбор type ∈ {Task | Hour | Items | Supplies}), правка direct_cost / invoice (input), Comments (input). Валюта IDR, формат 2,000,000.00 IDR.create/update/delete TaskCost. Total = вычисляемое (direct_cost vs invoice — отображаются обе колонки; итог 🟡 формула суммирования в каталоге не задана — минимально: Total = invoice при наличии, иначе direct_cost; уточнить).Назначение: неизменяемый журнал событий задачи (audit log).
Данные/поля (дословно): группировка Today → таблица Time | User | Event | Before | After. Примеры строк:
13:00 · Sarah Martinez · Changed Task status · New → In Progress12:00 · Sarah Martinez · Created Task · - → NewКонтролы: read-only (нет input-контролов; input_button×1 = общая + шапки). Возможна фильтрация по дате (группировка Today).
Мутации: нет (append-only; записи создаются автоматически на каждую мутацию задачи на других вкладках). Source — TaskEvent.
Состояния/вкладки (общие для экрана): active tab ∈ {Details, Requirements, Costs, History}; задача в статусе Planned/New (Started at/Finished at/Total Time пустые) vs Finished (заполнены); loading; error; no-permission (Accounting видит Costs, но Details read-only — 🟡 уточнить).
Связи (data-flow): читает Task + TaskRequirement/TaskCost/TaskEvent/Comment/Attachment; owner/assignment join Employee; unit/area join Unit/UnitArea. Пишет Details/Costs/Comments → TaskEvent (History) → данные Costs снапшотятся в Maintenance Report (E06). Открывается из S13 (клик по строке).
Права: Coordinator/Operations — полный доступ ко всем вкладкам своих department-scoped задач. Accounting — Costs (read+write financial fields), Details read. Owner Services — read. Field staff — карточку видят на mobile (E04), не здесь.
🟡 [не было додумано]:
Standard. Полный набор (Low/Standard/High/Urgent?) — уточнить; в прототипе минимум Standard.On Track вычисляется как finished_at ≤ due_at (S44 даёт парность on track / overdue) — формула выведена логически.Edge cases: задача без costs (вкладка Costs empty → «No costs»); задача без requirements (Direct-задача без шаблона → Requirements empty); History всегда ≥1 строка (Created Task); длинные Description/comment (заглушки «Task Description…» × N) — усечение/скролл; задача в Planned → Started at/Finished at/Total Time/On Track пустые; отсутствие прав на Costs — вкладка скрыта/disabled.
3458764671638361703 (canvas x=4101 y=17611, 1440×900). В IA вынесен из карточки Unit как общий модуль Schedule (overview §2, помечен 🟡).Schedule + навигация периода < > → поиск + фильтр → сетка-календарь: строки = задачи/слоты, ячейка несёт status (on track / overdue), время (00:00 / 02:30), исполнителя (Sarah Martinez), тип задачи (Cleaning).Schedule, навигация < >, search, повторяющиеся Cleaning (тип задачи в ячейке), статус-чипы on track / overdue, время 00:00 / 02:30, исполнитель Sarah Martinez, кнопки clear / apply.< > — button → пред./след. период (день/неделя — 🟡 гранулярность не указана; минимально — навигация периода).search — input → поиск по сотруднику/задаче.clear / apply — button → сброс/применение фильтра.Task (с due_at, assignment/owner, type, on_track) сгруппированные по сотруднику и времени; задачи те же, что в S13 — другой ракурс (календарь vs таблица). Клик → Task Detail.S13 (Tasks list) ──клик по строке──► Task Detail (S20/S25/S21/S29, нужная вкладка)
S13 ──tab Issues──► список issue-задач (detail issue = эпик E05)
S44 (Schedule) ──клик по ячейке──► Task Detail
Task Detail · Details/Costs ──любая мутация──► Task Detail · History (TaskEvent, append-only)
Task Detail · Costs ──снапшот──► Maintenance Report (эпик E06)
Внешние входы/выходы эпика:
Planned. Issue (E05) эскалируется → Issue-задача. Ручное создание → Direct-задача.Ответы со встречи Akira × Sergey (реестр
00-client-questions.md). Перекрывают соответствующие 🟡-допущения ниже.
Q-09 · priority — РЕШЕНО (resolves §6/§8 «Priority-шкала», S20 dropdown): Low / Standard / High / Emergency (4 уровня), дефолт при создании — Standard (можно сменить). Normal/Medium → Standard, Urgent → Emergency. Единый enum tasks/issues/services. → Tier B U1.
Q-06 · task lifecycle / точка создания — РЕШЕНО (resolves §3 «точка создания Direct»): Task всегда создаётся на desktop, из 4 источников: (1) новая бронь → recalc-движок (Reservation-task); (2) ежедневный движок авто-тасков по графикам (Schedule-task); (3) менеджер вручную (Direct); (4) авто из зарепорченного Issue (Issue-task). Исполнение — desktop И mobile (в основном mobile; часть manager-report тасков — desktop). Апрув — desktop. Mobile (E04) — только исполнение. Подтверждает 4-источниковую модель Task.type.
Q-11 · task dates vs reservations — РЕШЕНО: даты задач независимы от дат броней. У каждого таска свои даты (создание + duration/deadline). Reservation-task порождается из брони, но даты у неё свои; issue/периодические/ручные — к броням не относятся.
Q-07 · auto-assignment hierarchy — РЕШЕНО (домен + подход, ADR-001) (resolves finding filter-hierarchy-assignee); открыт только engineering edge-cases → Akira × Соя:
По логике Breezeway. При создании задачи дефолтный ответственный резолвится по самому специфичному заданному уровню:
Engineering/Maintenance: прямого cluster-team-дефолта как у Cleaning нет — авто-логику назначения для инжиниринга нужно допродумать (Akira × Соя; возможны edge-cases).
Реализация (подход ПРИНЯТ 2026-06-23, ADR-001): иерархию НЕ зашивать жёстким хардкодом и НЕ строить пользовательский «конструктор фильтров». Принято: adjacency list (parentId, нейтрально к бэкенду) для иерархии + отдельная сущность назначения со scopeLevel/scopeNodeId + полиморфные targets[] (kind: user|group|role|cluster|department, сохраняет идентичность группы для UI) + резолюция most-specific-wins на чтение (подняться по предкам property, взять ближайшее заданное назначение). ReBAC-движок (OpenFGA/SpiceDB) — overkill на прототипе, держим как мысленную модель. Каскад в UI (Department > Cluster > Assignee) — отражение той же иерархии. Анти-паттерн user_id/group_id (вместо targets[]) — запрещён.
Открыто: engineering-edge-cases авто-логики, нестандартные привязки и tie-break most-specific-wins — после разговора Akira × Соя.
New→In Progress→Finished прямо подтверждены событиями S29; (нет)→Planned следует из recalc-движка (overview §6); Planned→New (наступление дня / ручная активация) достроен логически — иначе плановая задача не доходит до исполнителя. Reopen/cancel НЕ добавлены (нет в скелете). Отклонение от прототипа: минимальное (один недостающий переход).Task Type, источник = reservation-триггер recalc. Уточнить у заказчика наличие живых reservation-задач.+ Add Task нет (только фильтры). Зафиксировано, что ручное создание существует (вероятно из Unit→Tasks); UI-точку входа в этом эпике не достраиваем — уточнить.Task Type dropdown vs category-значения (Maintenance/Cleaning/Inspection в контенте) — трактуем dropdown как фильтр по Task.type, категории — вторичная группировка из TaskTemplate.category. Уточнить.Total = invoice ?? direct_cost (Costs), on_track = finished_at ≤ due_at — выведены логически, формулы в каталоге отсутствуют.