using System;
using Ban.Sdaid.Notation.Documents;
using Ban.Sdaid.Icd;
namespace Ban.Sdaid.Icd.Arch.Tech.Angular
{
/// <summary>
/// ADR-UI-005: Layout приложения. Основной режим — оболочка (шапка + рабочая область) и единый
/// каркас страницы (page/header/body). Второй режим (экраны входа) и auth — отдельным ADR.
/// </summary>
public class ADR_UI_005_Layout : IAdrDocument, IFolder<ArchAngularFolder>
{
public string Name => "ADR-UI-005. Layout приложения";
public string Description =>
@"Нужно зафиксировать разметку приложения: какую оболочку (шапка + рабочая область) предоставляет
приложение и как страница рабочей области описывает свою внутреннюю структуру. На текущем этапе
фиксируется основной режим; режим «без оболочки» (экраны входа) и механика доступа определяются
отдельным ADR по мере появления ролей и доступа.";
public string Version => "1.0";
public string Status => "accepted";
public string[] Comments => new[]
{
"2026-08-11. Принят основной режим layout; второй режим и auth — отдельным ADR.",
};
public Type? Supersedes => null;
public static string S1_Context = """
## Контекст и постановка задачи
Приложению нужна предсказуемая разметка: единая оболочка (шапка с навигацией, рабочая область) и
стандартный каркас страницы, чтобы гриды, формы и карточки не расходились по отступам и поведению
скролла.
Роли и доступ ICD пока не заданы (открытый вопрос видения — см. `IcdVision`), хотя вход в систему
предполагается. Поэтому фиксируем **основной режим** (рабочее приложение с оболочкой); режим «без
оболочки» (экраны входа/выхода/отказа) и механику доступа (гарды, видимость навигации по правам)
вводим отдельным ADR, не переписывая этот.
""";
public static string S2_DecisionDrivers = """
## Драйверы решения
1. **Единый каркас страницы** — общий скелет (header страницы + body) для гридов, форм, карточек.
2. **Минимум вложенности** — не плодить layout-компоненты под каждый подвид страницы.
3. **Разделение ответственности** — оболочка приложения / каркас страницы / содержимое страницы.
4. **Поэтапность** — auth-режим не заложен преждевременно; основной layout не зависит от ещё не
определённого доступа.
""";
public static string S3_ConsideredOptions = """
## Рассмотренные варианты
- **A. Один layout с условной шапкой** — общая оболочка на все страницы, шапка скрывается на
экранах входа. Минус: оболочка «знает» про состояние авторизации.
- **B. Разные режимы, поэтапно** — основной layout (оболочка рабочего приложения) вводим сейчас;
режим «без оболочки» (экраны входа) и auth — отдельным ADR, когда определятся роли/доступ.
- **C. Сразу полный набор** (основной + отдельный auth-layout + гарды) — преждевременно, пока
доступ не определён.
""";
public static string S4_DecisionOutcome = """
## Решение
Выбран **Вариант B**. На текущем этапе реализуется только **основной режим**.
### Оболочка приложения
Корневая оболочка рабочего приложения содержит:
```
оболочка
├── шапка
│ ├── логотип
│ ├── главное меню (горизонтальное)
│ └── зона профиля пользователя (наполняется с введением auth)
└── рабочая область
└── <router-outlet> ← сюда рендерятся страницы фич
```
Главное меню — **горизонтальное**, в шапке. Конкретный состав пунктов определяется на этапе
UI-спеки страниц (отложено). Видимость пунктов по правам появится вместе с механикой доступа
(отдельный ADR).
### Каркас страницы рабочей области
Любая страница в `<router-outlet>` оборачивается в каркас `page` с двумя зонами:
```html
<icd-page>
<icd-page-header>
<!-- заголовок раздела, кнопки действий; место для breadcrumbs -->
</icd-page-header>
<icd-page-body>
<!-- грид / форма / карточка -->
</icd-page-body>
</icd-page>
```
Каркас собирает зоны через контент-проекцию и задаёт сетку: **header — sticky сверху, body —
скроллящаяся область**. Компоненты — собственные (набор `ui/`, слой layout), классы без суффиксов
(`Page`, `PageHeader`, `PageBody`), селекторы `icd-page` / `icd-page-header` / `icd-page-body`.
Это даёт:
- единые отступы и поведение скролла во всём приложении;
- стандартное место для breadcrumbs (отдельный ADR);
- предсказуемую точку расширения (например, sticky-футер таблицы).
### Соответствие зон
| Зона | Что рендерит |
|---|---|
| Шапка приложения | оболочка (единственная на приложение) |
| Заголовок/действия страницы | `icd-page-header` внутри страницы |
| Рабочая область страницы | `icd-page-body` внутри страницы |
""";
public static string S5_PositiveConsequences = """
## Положительные следствия
- Чёткое разделение: общая оболочка / каркас страницы / содержимое.
- Любая новая страница пишется через `icd-page` без риска разойтись по разметке.
- Основной layout не зависит от ещё не определённого доступа — auth-режим добавится без
переписывания.
""";
public static string S6_NegativeConsequences = """
## Отрицательные следствия и компромиссы
- Структура оболочки жёсткая: sidebar / split-pane потребуют существенного изменения, а не
локальной правки.
- Зона профиля и второй режим (экраны входа) пока «заглушены» — часть шапки наполнится позже.
""";
public static string S7_Validation = """
## Проверка
- Любая страница рабочей области использует `icd-page` с `icd-page-header` + `icd-page-body`.
- Шапка приложения не дублируется в шаблонах страниц — она одна, в оболочке.
- Каркас страницы обеспечивает sticky-header и скролл body без правок на стороне страницы.
""";
public static string S8_OpenQuestions = """
## Открытые вопросы / отложено
- **Второй режим (без оболочки)** — экраны входа/выхода/отказа в доступе и механика доступа
(гарды, видимость навигации по правам) — отдельным ADR по мере определения ролей/доступа.
- **Состав главного меню** — определяется на этапе UI-спеки страниц.
- **Зона профиля пользователя** — наполнение (аватар, выход) появится вместе с auth.
""";
public static string S99_Related = $"""
## Связанные артефакты
- {nameof(Ban.Sdaid.Icd.Arch.Tech.Angular.ADR_UI_003_ProjectStructure)} — Размещение layout-компонентов в наборе `ui/`.
- {nameof(Ban.Sdaid.Icd.Vision.IcdVision)} — Видение: роли и доступ (пока открытый вопрос).
""";
}
}