rust/Deal

Table of Contents

Дейл (Deal) — Этап 9: единая карточка (unified card) Implementation Plan

Global Constraints
Ключевые решения (Rulings этапа)
Задачи этапа
Порядок и зависимости

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Перенесено из репозитория (docs/superpowers/plans/2026-09-09-deal-stage9-unified-card.md). Актуальная версия — здесь, в вики.

Дейл (Deal) — Этап 9: единая карточка (unified card) Implementation Plan

Исторический документ этапа 9. Актуальное состояние — docs/superpowers/STATUS.md и docs/technical/Техническая-документация-Дейл.md.

Goal: Устранить дуальность «карточка канбана / проектная карточка». Одна сущность карточка (ядро id/title/source + опциональные модули) работает во всех дашбордах; «лид» как понятие и ProjectCards-дублирование упраздняются; колонки/стадии/зоны — единый контейнер с политиками. Бэк (C#) и фронт (Vue) переписываются на единую модель; данные тестовые, схема пересоздаётся.

Spec: docs/architecture/2026-09-09-unified-card.md; ТЗ: docs/spec/ТЗ-дейл-новая-архитектура.md (термины §2, карточка §5.5, канбаны §6); код: модули Kanban/Projects/Pipeline, Deal.Infrastructure (миграции/адаптеры), Deal.Api (LeadsEndpoints/ProjectsEndpoints/PipelineEndpoints), фронт store/{leads,projects}.js, компоненты LeadCard/ProjectCard/LeadDrawer/ProjectDrawer/Column/ProjectColumn.

Global Constraints

Проект НЕ git; фиксация — отчёты task-N-report.md и progress.md в .superpowers/sdd/deal-stage9-unified-card/.
.NET 10; sln собираются 0 warnings/0 errors; dev-Postgres deal-postgres (:5433); системные миграции — dotnet ef database update --context DealDbContext из src/core; tenant-миграции — провижинер на старте.
Код-стайл: 1 тип = 1 файл; XML-doc на public; русские комментарии; без регионов; без магических чисел; времена DateTimeOffset (UTC); JSON camelCase; ошибки API — {detail}.
Фронт: Vue 3 + чистый JS, без TS/роутера; Composition API; npm run build зелёный после каждого шага.
Тесты: core Deal.Tests.Unit (1139), telegram 118, ai 52, ml 38 — прогон после каждой фазы.
Секреты — только env (DEAL_*).
Вне рамок: Kafka, k8s, саморегистрация, «третий» дашборд (архитектура готова, реализация — позже).

Ключевые решения (Rulings этапа)

R1 — единый агрегат карточки. Ядро Card { Id, Title, Source }; модули-роли (контент, бюджет, контакты, атрибуты, комментарии, ссылки, файлы, ТЗ, история, напоминание, размещение) — опциональные части агрегата (jsonb/колонки одной таблицы), а не классы-наследники. Вид = композиция модулей.
R2 — Source. ISource + варианты: Local/Web/File/Telegram/Row/Api/Ai/Composite (Origin+Pipeline). У карточки из пайплайна — Composite(Origin: Telegram, Pipeline: [Ai/ML]).
R3 — единый контейнер. Одна таблица/реестр контейнеров (kind: inbox/board/stage/archive/trash/ terminal), политики — роли (IContainerPolicy), не enum-свойства. Стадии «Выбранных» — контейнеры kind=stage (предзаданный каталог), доски — kind=board (создаёт пользователь/ИИ).
R4 — переход. Один ICardMover.MoveAsync(card, toContainerId, ctx); «взять в работу» = переход в контейнер planned той же карточки (никакого col=taken + клона в ProjectCards); «Выбранные → архив/ корзина дашборда» запрещено политикой пространства; терминальные зоны — политика.
R5 — API. /api/cards + /api/containers (единый контракт); /api/leads, /api/projects упраздняются; фронт переписывается. SSE-события переходят на карточки.
R6 — пайплайн. Создаёт карточку (не «лид»): CardComposer → ICardStore.Add; дедуп/отсев/ML/ИИ не знают «лидов». Названия в коде/БД: lead→card, project card→card in stage-container.

Задачи этапа

T1. Доменные контракты единой карточки (C#) — модуль Cards: ICard/ICard, ISource-иерархия, модули-роли, IContainer/IContainerPolicy, ICardMover; реестры (контейнеры по умолчанию, стадии, SourceKind). Без изменения поведения текущих модулей (новые типы + тесты чистых правил).
T2. EF-модель и миграция — одна таблица Cards (общие поля + jsonb-модули + source + container_id), таблица Containers (доски/стадии/зоны), удаление ProjectCards/LeadComments-дублей; системная и tenant-миграции; провижининг контейнеров по умолчанию.
T3. Адаптер ICardStore — единый EF-адаптер (слияние KanbanStore/ProjectStore), чтение/запись карточки целиком (jsonb-модули), контейнеры, атомарные append (комментарии/ссылки/файлы), move с историей/напоминаниями.
T4. Сервисы карточек/контейнеров — CardsService (переходы, правила колонок, обучение ML), ContainersService (CRUD колонок, принятие ИИ-предложений, reorder), перенос логики Projects (файлы/ТЗ/напоминания/история) в модули карточки.
T5. Pipeline — создание карточки через ICardStore; терминология; дедуп на карточку.
T6. API единый — /api/cards и /api/containers; SSE; удаление старых ручек; интеграционные тесты/curl-приёмка.
T7. ML-сервис/контракты — обучение на действиях с карточками (колонки/стадии едино), без «lead».
T8. Фронт: store — единый слайс карточек/контейнеров вместо leads.js+projects.js; API-клиент.
T9. Фронт: компоненты — единые LeadCard-база→Card, Column/ProjectColumn→ContainerColumn, LeadDrawer/ProjectDrawer→CardDrawer; экраны Дашборд/«Выбранные» — один канбан по пространству.
T10. Финал — сквозная приёмка, доки (ТЗ/техдок/api-map), чистка, ledger.

Порядок и зависимости

T1 → T2 → T3 → (T4, T5) → T6 → T7 → (T8, T9) → T10. Каждая задача завершается зелёной сборкой и прогоном тестов; API-контракт меняется один раз на T6 (до этого новые типы живут рядом со старыми).

Документы

Процесс

Историческое

Планы • Ревью • Спеки • Архитектура