# Шаг 11. Единый shell карточки внешнего контура

## Зачем нужен этот шаг

Сейчас карточка деталей во `Внешних контурах` решает прикладную задачу, но UX-паттерн у нее другой, чем во `Внутреннем контуре`.

Из-за этого:
- у пользователя ломается ожидаемая логика открытия карточки
- верхний action-bar живет по другим правилам
- повторяется UI-логика, которая уже есть у стандартного peek-shell
- дальнейшее развитие `Внешних контуров` начинает расходиться с остальным продуктом

Следующий шаг должен выровнять не данные, а каркас взаимодействия.

## Целевой результат

По клику на карточку во `Внешних контурах` пользователь получает тот же класс панели, что и во `Внутреннем контуре`:
- закрытие просмотра
- полноэкранный режим
- переключение макета
- подписка или отписка
- копирование ссылки
- меню дополнительных действий

При этом тело карточки остается отдельным и специфичным для `Внешних контуров`.

## Что обязательно сохраняем

Карточка внешнего контура не должна деградировать до обычной карточки `Issue`.

Нужно сохранить:
- source-side режим без обязательного membership в target project
- блок `Маршрутизация`
- зеркалирование комментариев, вложений и activity
- внешний lifecycle `Принять / Отклонить / Ответ во внешний контур`
- правила доступа, отличающиеся от обычного внутреннего рабочего элемента

Иначе мы потеряем главный смысл модуля.

## Что меняем

Меняем только shell и верхний UX-паттерн:
- каркас панели
- поведение открытия и закрытия
- поведение полноэкранного режима
- верхний блок действий
- раскладку заголовка и служебных controls

То есть цель шага — унификация оболочки, а не унификация доменной модели.

## Что не входит

В этот шаг не входят:
- новые колонки `Исходящие / Входящие`
- drag-and-drop
- пользовательские кастомные представления
- перенос всех операций внешнего контура на стандартные issue services
- удаление запроса как обязательное действие из header action set

## Архитектурный принцип

Нельзя копировать целиком реализацию `peek overview` внутреннего контура и натягивать ее поверх внешней сущности.

Правильный путь:
- переиспользовать shell-контракт
- переиспользовать header action pattern
- оставить внешний data-flow отдельным
- оставить body карточки отдельным

То есть нужен не clone существующей карточки, а повторное использование общего слоя представления.

## Рекомендуемое разбиение реализации

### 1. Общий слой shell

Нужен общий контракт боковой карточки, который умеет:
- sidebar-режим
- full-screen режим
- общий overlay и поведение закрытия
- общий header slot
- общий body slot

### 2. Отдельный adapter для `Внешних контуров`

Нужен внешний adapter, который подает в shell:
- title
- служебные действия
- доступные действия меню
- состояние source-only или target-access
- body контент внешнего контура

### 3. Отдельный action set

Нельзя слепо использовать меню обычной задачи.

Нужно отдельное правило доступных действий для внешнего контура:
- закрыть
- fullscreen
- layout toggle
- subscribe/unsubscribe
- copy link
- `...`

При этом `...` для внешнего контура должен быть ограничен собственным набором действий и не обязан повторять delete-flow внутреннего рабочего элемента.

## Риски, которые надо избежать

### 1. Смешение доменных сущностей

Если внешний запрос начать вести как обычный `Issue`, то быстро сломаются:
- source-side права
- логика bridge
- роутинг действий `Принять / Отклонить`
- зеркальная история

### 2. Дублирование shell-кода

Если сделать второй независимый peek-shell только для `Внешних контуров`, то дальше появятся:
- рассинхрон верхних action-bar
- повторная поддержка полноэкранного режима
- повторная поддержка keyboard и close behavior

### 3. Преждевременная универсальная платформа

Не нужно ради одного шага строить абстрактный UI-framework на все возможные будущие сущности.

Нужен только тот общий контракт, который уже доказан двумя режимами:
- `Внутренний контур`
- `Внешние контуры`

## Критерий приемки

- карточка `Внешних контуров` открывается по тому же UX-паттерну, что и во `Внутреннем контуре`
- верхняя панель действий выглядит и ведет себя единообразно
- body карточки остается внешнеконтурным
- source-only сценарий не ломается
- без прямого доступа в target project пользователь все равно видит рабочую карточку

## Зависимость следующего шага

Этот шаг желательно сделать до полной двусторонней доски.

Причина простая:
- доска `Исходящие / Входящие` увеличит число точек входа в карточку
- если shell не унифицирован заранее, новый board-layer закрепит текущую раздвоенную архитектуру

Следующий связанный шаг описан в:
- [12_STEP_external-contours-bidirectional-board.md](/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/docs_prod/1_STEP_cross-project-task-routing/12_STEP_external-contours-bidirectional-board.md)