docs(plans): план 158 — поля диалога вопроса (#1877) и сверка со слитыми #1528/#1557

[AnnaSIceberg]

Режим работы

• Эксперимент: PR остаётся Draft, гипотеза или контракт ещё меняются
• Поставка: результат проверен, текущий HEAD готов к конвейеру

Plan-PR по #1877, вариант 2 (решение сопровождающего от 05.10.2026): сначала актуализация Plans/158-open-form-programmatically.md с согласованием с #1531, затем реализация полей диалога. Только Plans/, продуктовый код не меняется. Ветка от main 66a9a104.

Refs #1877, #1531

Что меняется в плане 158

1. Сверка со слитым. Новый раздел «Состояние на 2026-10-05»:
   • Нечем спросить пользователя из обработчика: предупреждение с продолжением превращается в запрет или в молчание #1528 слит (PR feat(forms): ПоказатьВопрос — вопрос пользователю из обработчика #1681) с другим контрактом, чем требовал план: третий аргумент — заголовок, ответ — событием Ответ с ВопросОтвет;
   • ответ не связан с выданным диалогом — сервер не хранит варианты, ВопросОтвет — любая строка из POST;
   • ОткрытьФорму() — навигация к другому документу из обработчика кнопки управляемой формы #1557 слит (PR feat(forms): ОткрытьФорму — переход к записи из обработчика #1682) как navigation-only; повторная сверка со всеми критериями среза B в этой актуализации не выполнялась — так и записано.
2. Совместимость. Слитое не ломается: вызовы с двумя и тремя аргументами, событие Ответ и ВопросОтвет остаются. Это замороженный путь совместимости, новых возможностей он не получает. Решение о выводе Ответ из употребления — после A1, не здесь.
3. Разбор аргументов — ПоказатьВопрос(Текст, Варианты[, ЗаголовокИлиОповещение[, Поля[, Заголовок]]]):
   • третий аргумент разбирается по типу: строка или его отсутствие — совместимость, ОписаниеОповещения — callback, иное — ошибка;
   • Поля — только четвёртым аргументом и только при оповещении, заголовок окна — пятым. Так согласованный callback не заменяется (требование решения).
4. Поля диалога (ПоказатьВопрос: строки данных и поле ввода в диалоге (аргумент Поля → ДиалогПоля) #1877):
   • Схема полей: Имя, Заголовок, Значение, Выделить, Правка, Длина — с типами и пределами: 20 полей, из них 5 редактируемых; имя ≤ 64 символов, заголовок ≤ 200, Длина 1–1000, по умолчанию 256. Ввод в v1 — только однострочная строка.
   • Ошибки вызова: полный перечень DSL-ошибок, при которых диалог не выдаётся.
   • Результат: Структура("Ответ,Поля"), в Поля — только редактируемые поля; закрытие — Неопределено.
   • Серверный контекст: owner, сессия, форма и nonce — это binding interaction из среза A1 (пользователь, fingerprint сессии, formInstance, сущность или обработка, форма, элемент) плюс 256-bit correlation. Allowlist кнопок, редактируемых имён и длин хранится в server store, а не берётся из браузера.
   • Проверка ответа до DSL: кнопка; ровно множество редактируемых имён; UTF-8 без NUL; длина без усечения; CRLF → LF. Атомарный consumed. Отклонённый ответ ничего не вызывает и не гасит interaction; повтор после consumed и чужой binding дают одинаковый отказ.
   • Безопасный вывод: только textContent, маски диалог не накладывает и не снимает. Уточнение по факту кода: maskDSLValue маскирует чтение сохранённой записи через DSL-прокси, но не Объект формы — поэтому в документации обязательно предупреждение про ПДн.
   • Формы обработок: те же правила через общий финализатор.
5. Срезы: A разделён на A1 (общий callback и вопрос) и A2 (поля ПоказатьВопрос: строки данных и поле ввода в диалоге (аргумент Поля → ДиалогПоля) #1877, ~1.5–2 дня, после A1). Исполнитель A1/A2 — контрибутор отдельными Draft PR после merge плана; Нет открытия формы с предзаполнением и возвратом значения: план 158 есть, заявки под него нет #1531 остаётся ведущей общего механизма и срезов C–D. Если сопровождающий ведёт A1 сам, A2 ждёт его merge. Срез B отмечен слитым.
6. Тесты: unit-тесты разбора аргументов, схемы Поля с граничными значениями и проверки ответа (включая многобайтовые символы, NUL, невалидный UTF-8, однократное гашение); Node-тест строк и ввода.
7. Риски и критерии готовности: «два callback API» — переформулировано под замороженный Ответ; добавлена «подмена полей». Обновлены эстимейт и условия готовности ПоказатьВопрос: строки данных и поле ввода в диалоге (аргумент Поля → ДиалогПоля) #1877/Нет открытия формы с предзаполнением и возвратом значения: план 158 есть, заявки под него нет #1531.
8. Plans/README.md: строка 158 — ПоказатьВопрос: строки данных и поле ввода в диалоге (аргумент Поля → ДиалогПоля) #1877 и срез A2 в описании и оценке. Номер плана не меняется, go run ./tools/plannum: номера уникальны.

Решения по спорным местам — на ревью

• Заголовок при callback пятым аргументом. Альтернатива — заголовок в структуре параметров вместо отдельного аргумента. Выбран отдельный аргумент: проще и ближе к 1С, где Заголовок — отдельный параметр.
• Значение ссылки показывается представлением, вычисленным сервером, а не UUID.
• Отклонённый ответ не гасит interaction. Иначе опечатка в длине теряет весь ввод. Повтор принятого ответа по-прежнему ничего не вызывает.

Проверки

Только документные: git diff --check — чисто; go run ./tools/plannum — 180 планов, номера уникальны. Ссылки на код в новых разделах сверены с main 66a9a104:

• form_question.go, _question_answer / ВопросОтвет в handlers_managed_events.go (entity и processor);
• TestShowQuestion_*;
• maskDSLValue в field_access.go;
• newNavigationBuiltin.

🤖 Generated with Claude Code

[ivanarama]

Ревью. (круг 1)
Reviewed-SHA: b357908
Outcome-Label: changes-requested
Что меняется: Актуализация плана 158 и каталога Plans: сохранение слитого пути Ответ/ВопросОтвет, новый callback-путь ПоказатьВопрос и срез A2 с полями диалога; продуктовый код не меняется.
Проверено: Detached worktree точного HEAD b357908; прочитан полный план и diff двух изменённых Markdown-файлов; git diff --check 66a9a10...HEAD — без ошибок; go run ./tools/plannum — 180 планов, номера уникальны; локальные Markdown-ссылки в плане и Plans/README.md существуют; Сверены newQuestionBuiltin, доставка question_answer для entity/processor, клиентский textContent, newNavigationBuiltin и маскирование сохранённых DSL-объектов в отличие от Объект формы; go test -count=1 -v ./internal/ui с целевым -run для TestShowQuestion, TestOpenForm_ и трёх DSL mask-тестов — 12 Go-тестов прошли; первоначально два Node-wrapper теста были пропущены из-за PATH, затем оба отдельно прошли с Node v22.21.0 в PATH; Из internal/ui выполнен node --test static/question_modal_behavior_test.js — 3/3 прошли; первый запуск из корня имел ошибку cwd и исправлен; go vet ./internal/ui — без ошибок; общий build и полный go test ./... не запускались: diff касается только Plans/; Непосредственно перед complete подтверждены ivanarama, неизменный открытый Ready HEAD и все 8 обязательных CI: build, lint, postgres-integration, vuln, smoke, e2e, test-windows, launcher-webview-build — SUCCESS; Проверены два контрпримера спецификации A2: разные Имя при одинаковых подписях имеют одинаковый описанный клиентский payload; допустимая по перечисленным проверкам строка с CRLF остаётся многострочной после CRLF → LF.
Блокирующее: 1) [P2] Plans/158-open-form-programmatically.md:276–286 — клиенту не передаются ключи редактируемых полей. Перечень данных строки содержит подпись, значение-текст, выделение, признак ввода и maxlength, но не Имя, хотя ответ обязан содержать точное множество серверных имён. Для двух допустимых полей КомментарийА и КомментарийБ с одинаковым Заголовок браузер не может восстановить ключи карты имя → значение; даже Заголовок одного поля не обязан совпадать с Имя. Добавить каноническое Имя или явный идентификатор с серверным отображением в клиентскую схему, описать сериализацию ответа и тест с одинаковыми подписями и разными именами; 2) [P2] Plans/158-open-form-programmatically.md:261–269,287–290 — проверка ответа противоречит ограничению «только однострочная строка». Строка «первая\r\nвторая» является корректным UTF-8, не содержит NUL, укладывается в Длина=256 и после предписанного CRLF → LF остаётся многострочной; она проходит перечисленные проверки и доставляется callback. Ограничение browser input не защищает от прямого POST, а начальные значения с переносами также не запрещены. Для v1 явно отклонять CR и LF в начальном значении и ответе до consumed; добавить случаи CR, LF, CRLF с проверкой отсутствия вызова callback и сохранения interaction.
Хвост:
—
Вердикт: есть замечания.

[ivanarama]

PromptPilot service marker: REVIEW result publication claimed.

[ivanarama]

PromptPilot service marker: REVIEW result committed.

[AnnaSIceberg]

Оба замечания ревью (круг 1) учтены в плане: HEAD 19849bd8f88f13f326f7f78ebf4b51e8541c710a.

1. Клиент получает каноническое Имя редактируемой строки; ключ ответа — Имя, не Заголовок. Описан формат ответа: _interaction, _interaction_button, по одному _interaction_field.<Имя>; несколько значений одного ключа отклоняют ответ. Тест: две строки с одинаковым Заголовок и разными Имя.
2. Однострочность v1 — проверка сервера: CR и LF в ответе отклоняются без нормализации и без вызова процедуры, interaction остаётся открытой; CR/LF в начальном значении редактируемого поля — ошибка вызова. Тесты: CR, LF, CRLF.

CI зелёный: https://github.com/ivanarama/onebase/actions/runs/37416832459 . Прошу повторное ревью нового HEAD.