using System;
using Ban.Sdaid.Notation.Documents;
using Ban.Sdaid.Notation.Glossary;
using Ban.Sdaid.Icd.ChangeRequests;
using Ban.Sdaid.Icd.Glossary.Terms;
namespace Ban.Sdaid.Icd.Arch.Adr
{
/// <summary>
/// Решение: у пакета четыре состояния вместо пяти подтверждаемых этапов, проверка идёт
/// на двух вкладках. Замещает модель статуса, выводимого из подтверждений.
/// </summary>
public class ADR_008_PacketStatesAndTwoTabs : IAdrDocument, IHasStructuralLinks
{
public static string _refName = "ADR-008 «Четыре состояния пакета и две вкладки проверки»";
public string Name => "ADR-008. Четыре состояния пакета вместо пяти этапов";
public string Description =>
@"Как моделируется прохождение пакета по проверке: подтверждаемыми этапами или состоянием пакета, и во что превращается экран проверки.";
public string Version => "0.1";
public string Status => "accepted";
public string[] Comments => new[]
{
"2026-08-18. Заведён по запросу на изменение «Ввод без плана ввода».",
"2026-08-20. Расширен ADR-014: к четырём состояниям добавлены два машинных — «обрабатывается» и «готов к проверке», обработку запускает фоновая очередь автоматически. Тезис «нет пяти подтверждаемых этапов» сохраняется: новые состояния машинные, не подтверждаются.",
};
public Type? Supersedes => typeof(ADR_003_StageConfirmationModel);
public SdaidLink[] Links => new[]
{
Rel.Uses<DOC_CR_2026_08_14_InputWithoutPlan>(),
};
public static string S1_Context = $"""
## Контекст
По {nameof(ADR_003_StageConfirmationModel)} пакет проходил пять этапов — предобработка,
проверка файлов, полей, экземпляров, экспертизы, — каждый подтверждался пользователем.
Статус пакета не хранился, а вычислялся как ближайший неподтверждённый этап; отзыв
подтверждения каскадно сбрасывал последующие.
Проработка экрана очереди показала, что этапы дробят одну работу. Проверка полей,
подбор экземпляра и сверка экспертизы — это разглядывание одной и той же карты рядом
с одним и тем же изображением; разделение их на три подтверждаемых шага заставляет
пользователя трижды сказать «готово» там, где он один раз посмотрел и один раз решил.
Предобработка же вовсе не этап пользователя: она выполняется Сервисом, и подтверждать
в ней нечего.
""";
public static string S2_Decision = $"""
## Решение
**У {GlossaryAnchors.RefTo<InputPacket>("пакета ввода")} четыре состояния:** в очереди,
проверка, завершён, ошибка. Состояние хранится, а не выводится из подтверждений: подтверждать
больше нечего.
**Проверка идёт на двух вкладках.** «Пакет ввода» — состав кадров, опознанный вид ИК
и распределение кадров по страницам формы. «Проверка карты» — значения полей рядом
с изображением, их правка и создание карты.
**Каскадного отзыва нет.** Проверка заканчивается созданием информационной карты, после
чего пакет не правится; обесценивать нечего.
**Возврат в очередь заменяет отзыв подтверждения.** Правка состава или разметки кадров
делает результаты распознавания недействительными, и пакет ставится в очередь заново —
по команде пользователя, а не автоматически.
> **Дополнено {nameof(ADR_014_PacketProcessingQueue)}.** Между «в очереди» и «проверкой»
> появляются два машинных состояния — «обрабатывается» и «готов к проверке», — а обработку
> запускает фоновая очередь автоматически при постановке в очередь. Это не возвращает
> подтверждаемые этапы: новые состояния меняются системой, пользователь их не подтверждает.
""";
public static string S3_Rationale = """
## Обоснование
Прежняя модель решала реальную задачу: не дать системе утверждать, что данные проверены,
если проверены они были по другому набору изображений. Эта задача осталась, но решается
иначе — не каскадом подтверждений, а возвратом всего пакета в очередь: изменились
исходные данные, значит недействителен весь разбор, а не его часть.
Хранимое состояние возвращает риск, который прежнее решение снимало, — рассинхронизацию
статуса с фактическим положением дел. Цена принимается: состояний четыре, переходы между
ними наперечёт, и каждый вызван явным действием — постановкой в очередь, взятием в работу,
созданием карты, отклонением вида без подсказки.
Взамен исчезает необходимость поддерживать вычисление статуса, каскадный сброс и пять
наборов признаков подтверждения — при том что пользователь всё равно проходил этапы
подряд, не возвращаясь.
""";
public static string S4_Consequences = $"""
## Следствия
**Перечисление этапов обработки упраздняется**, вместе с ним — признаки подтверждения
и сведения о том, кто и когда подтвердил этап.
**Фильтр очереди строится по состояниям**, а не по этапам.
**Машина состояний пакета переписывается**: вместо цепочки подтверждений — переходы
между четырьмя состояниями, с возвратом из проверки в очередь.
**Требование о верификации** ({nameof(Ban.Sdaid.Icd.Requirements.FR_005_Verification)})
переписывается: последовательность этапов заменяется двумя вкладками.
**История проверки становится беднее.** Раньше по подтверждениям было видно, кто и когда
прошёл каждый этап; теперь известно только, кто создал карту. Если понадобится
прослеживаемость, её придётся заводить отдельно — журналом действий, а не состоянием.
Полный перечень затронутого — в {nameof(DOC_CR_2026_08_14_InputWithoutPlan)}.
""";
public static string S5_Alternatives = """
## Рассмотренные альтернативы
**Оставить этапы, но схлопнуть экраны.** Пять подтверждений сохраняются в модели, а на
экране показываются двумя вкладками. Отвергнуто: модель, которую не видно в интерфейсе,
рано или поздно расходится с ним; подтверждения пришлось бы проставлять неявно, за
пользователя.
**Оставить два этапа с подтверждением вместо состояний.** Подтверждение исходных данных
и подтверждение карты. Отвергнуто: подтверждение исходных данных ничем не отличалось бы
от перехода на вторую вкладку, а подтверждение карты — от её создания. Два признака,
дублирующих действия, которые и так фиксируются.
""";
}
}