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_007_InputWithoutPlan : IAdrDocument, IHasStructuralLinks
{
public static string _refName = "ADR-007 «Ввод без плана»";
public string Name => "ADR-007. Ввод без плана: вид ИК определяет Сервис";
public string Description =>
@"Как задаётся последовательность действий при вводе и кто определяет вид информационной карты: пользователь выбором плана или Сервис распознаванием.";
public string Version => "0.1";
public string Status => "accepted";
public string[] Comments => new[]
{
"2026-08-18. Заведён по запросу на изменение «Ввод без плана ввода».",
"2026-08-18. Принято: спека приведена в соответствие, реализация пошла этим путём.",
};
public Type? Supersedes => typeof(ADR_001_InputPlanDrivenByCardKind);
public SdaidLink[] Links => new[]
{
Rel.Uses<DOC_CR_2026_08_14_InputWithoutPlan>(),
};
public static string S1_Context = $"""
## Контекст
По {nameof(ADR_001_InputPlanDrivenByCardKind)} ввод шёл по плану ввода:
пользователь выбирал план на форме, план задавал последовательность операций, и из плана
же было известно, карта какого вида вводится.
Практика проработки показала три слабых места такого порядка.
**Выбор плана — лишнее действие на каждой карте.** При архиве около 50 тыс. карт даже
несколько секунд на выбор и следование шагам складываются в десятки часов.
**План допускает ошибку, которую некому поймать.** Пользователь мог выбрать план,
не соответствующий бумаге; расхождение обнаруживалось только на проверке, когда карта
уже введена.
**Вид карты и без того определяется при обработке.** Сегментация и извлечение атрибутов
требуют знать, что за форма перед распознавателем, — то есть вид всё равно распознаётся,
и выбор пользователя оказывается дублирующим утверждением о том же самом.
""";
public static string S2_Decision = $"""
## Решение
**Плана ввода нет.** Пользователь снимает или загружает кадры страниц подряд; каждому
новому кадру присваивается очередной номер, порядок правится перетаскиванием. Ввод карты
завершается командой «Сохранить и перейти к следующей». Сверху действует настраиваемый
предел числа кадров в пакете, по умолчанию пять.
**Вид ИК и форму бланка определяет Сервис** при обработке, он же распределяет кадры
по страницам опознанной формы. Кадр, который к странице не отнесён, считается лишним:
не распознаётся и удаляется без последствий.
**Несогласие пользователя выражается отклонением, а не правкой.** Если вид определён
неверно, пользователь отклоняет его и может указать верный; {GlossaryAnchors.RefTo<InputPacket>("пакет ввода")}
возвращается в очередь с контекстом «такой-то вид отвергнут, верным считать такой-то»,
а пользователь берёт следующий пакет, не дожидаясь результата. Пакет, в котором не опознан
ни один вид, помечается как ошибочный.
**Полноту карты определяют обязательные поля, а не состав кадров.** Если страница не снята,
Сервис просто не предзаполнит её поля — пользователь вносит их сам. Карта не создаётся,
пока не заполнены обязательные поля состава.
""";
public static string S3_Rationale = """
## Обоснование
Решение переносит определение вида с человека на Сервис — туда, где это знание всё равно
добывается. Пользователь перестаёт отвечать за то, что может быть выведено из бумаги,
и отвечает только за то, что видит: правильно ли Сервис прочитал.
Отсюда же форма несогласия. Отклонение вида дешевле правки: пользователю не нужно
разбирать неверно разобранные поля, он одним действием возвращает пакет в очередь
и переходит к следующему. Работа не блокируется ожиданием повторной обработки.
Роль Сервиса при этом определена как помощь, а не контроль: он предзаполняет то, что смог
прочесть, и не мешает пользователю доделать остальное руками.
""";
public static string S4_Consequences = $"""
## Следствия
**Распознавание становится обязательным звеном ввода.** Раньше план гарантировал, что вид
карты известен; теперь это гипотеза модели, и пакет с неопознанным видом не разбирается
вовсе, а не частично.
**Появляется цикл возврата в очередь с обратной связью.** Контекст отклонения — часть
задания на повторную обработку. От бесконечного хождения по кругу защищает возможность
указать верный вид и перевод неопознанного пакета в ошибку.
**Роль кадра заменяется страницей формы.** Кадр больше не несёт вид изображения из
перечисления, он относится к странице опознанной формы; переназначение страницы требует
повторной обработки.
**Отменяются артефакты плана.** Требование о ведении планов ввода, сценарий ввода по плану,
сущности плана и операции ввода, одноимённые термины глоссария.
**Затрагиваются смежные решения.** Ключи файлов кадров содержали вид кадра
({nameof(ADR_002_PacketIdentityAndFileKeys)}); привязка распознанного значения шла к виду
кадра ({nameof(ADR_005_FieldValueSourceBinding)}) — обе привязки переходят на страницу формы.
Полный перечень затронутого — в запросе на изменение {nameof(DOC_CR_2026_08_14_InputWithoutPlan)}.
""";
public static string S5_Alternatives = """
## Рассмотренные альтернативы
**Оставить план, но выбирать его автоматически по первому кадру.** Сервис определяет вид
по первой странице и подставляет план, пользователь при желании меняет. Отвергнуто:
сохраняет всю машинерию планов ради подсказки, которую всё равно даёт распознавание,
и оставляет пользователю возможность ошибиться выбором.
**Спрашивать вид документа один раз в начале смены.** Оператор обрабатывает пачку
однотипных карт, поэтому вид можно задать на всю пачку. Отвергнуто: пачки не всегда
однородны, а ошибка распространяется сразу на десятки карт, вместо одной.
""";
}
}