Remote COM Server 0.1.4 — подписи и отдельный public-комплект, 2026-10-25

По команде пользователя переименованы поля:
  bind_ip: «IP адрес VPN-адаптера на этом компьютере»;
  peer_ip: «IP адрес VPN-адаптера на удалённом компьютере»;
  пароль: «Пароль».
У длинных подписей wrap180, весь текст виден, настройки/пароль не менялись.
Транспортные runtime/config/httpapi/winserial не менялись; отдельная версия
EXE23549440B SHA CA4739139C536D8DC6F21350A14EEE69BBD1FABCD1B46AD4E3A57E0F88532BDB.
Standalone физически: новый профиль -> ошибка без COM -> выбор COM30/57600,
idle0 -> Save -> Start -> 17880B в обе стороны/21кадр -> Stop/EOF -> штатный
Close/reopen, те же настройки без auto-start. Новые подписи проверены на
точных PNG после Save и reopen; AST отдельно проверяет соответствие ключей.
Второй тот же runner на изолированном UI с намеренно прежними подписями:
транспортный маршрут проходит, но тот же caption-oracle отвергает все три
старые подписи. Raw transport PASS не подменяет визуальную приёмку.
Первый negative на новых координатах не дошёл до Save: старые подписи
вернули старые высоты строк. Сбой harness/forced cleanup сохранён и НЕ принят;
после корректировки локаторов обе стороны повторены на одном стеке.
Локальные strict UI-gates не заменяют реальный двухкомпьютерный VPN-тест.
Установщик отдельный, per-user/без администратора, без драйверов/VPN/firewall.
Приёмка установки и итоговые хеши — в public-build/final-public артефактах.

--------------------------------------------------------------------------
ИСТОРИЯ: Remote COM Server 0.1.3 — результат предыдущего этапа, 2026-10-25

Статус: LOCAL_NATIVE_ROUTES_PASS_VPN_PENDING. Это пробная portable-сборка,
не окончательная публичная приёмка. Старые результаты ниже сохранены как история.

По прямому согласию пользователя использован документ
Y:\HOST\SESSIONS\2026-10-14_ДИАГНОСТИКА_ЗАХВАТА_ЭКРАНА.txt и альтернативный
pywinauto/Pillow, а не Sky WGC. В отдельном .ui-test-venv проверены реальные
импорты, затем новый пустой Notepad: снимок, физическое открытие/закрытие меню,
штатный выход. Это восстановление рабочего метода, не исправление Sky WGC.
Сеть ПК, VPN, firewall, старый клиент/драйвер не менялись.

Найденный UI-дефект новой программы: после Close/reopen 0.1.2 Windows
размещала окно [130,130,1076,899] при рабочей области [0,0,1600,860].
Нижняя подпись скрывалась за taskbar. В 0.1.3 окно ограничивается текущей
рабочей областью монитора, с учётом рамки и отрицательных координат монитора.
На стенде после запуска и reopen [327,45,1273,814], вся подпись видна.
EXE 0.1.3: 23549440 байт, SHA256
33D353C23638D1AA2C0C34E1705AA5C5324CD8AA129004F83BB1909640995599.

Полные реальные физические маршруты standalone 0.1.3:
  1. Чистый профиль -> Start без COM/диалог -> физический выбор COM30,
     57600/8N1, idle0 -> Save -> Start -> обмен -> Stop -> Close -> reopen.
  2. Тот же новый профиль/настройка -> занятый HTTP80 -> видимый диалог
     WinError10048 -> OK -> освобождение конфликта -> Start/обмен/Stop/reopen.
  3. Занятый COM30 -> реальный access-denied диалог -> освобождение COM ->
     успешный Start/обмен/Stop/reopen, без частично работающего сервера.
  4. Активный обмен -> физический AltF4 -> «Нет» сохраняет соединение ->
     повторный AltF4/«Да» закрывает TCP/процесс -> reopen без автозапуска.
В каждом положительном маршруте 21 посылка, по 17880 байт в обе стороны,
сравнение всех байт через существующую com0com COM30/31; TCP localhost.
Остановка/выход завершают активный TCP-сеанс. Штатные выходы, новый boot_id,
тот же device_id, сохранённые значения после reopen. Скриншоты показывают
периодически обновляемые счётчики; снимок не обязан быть атомарным с runtime.

Тот же физический runner/executor/data-oracle без изменений выполнен на
изолированных неисправных реализациях: потеря COM в Save, подавление диалога
при занятом HTTP/COM, остановка сеанса после «Нет». Все четыре FAIL ровно
в соответствующих точках, без принудительного завершения собственных GUI.
20 точных PNG открыты и визуально проверены. user_route_contract-0.1.3.json
запечатывает 323 файла с SHA; валидатор независимо сверяет исходное состояние,
порядок/мишени физического ввода, снимки, модель, передачу, persistence,
normal-exit и отрицательный контроль. 22 теста PASS: 15 основных + 7 gate.
Gate-тесты отвергают пропуск фазы/скриншота, preseed, обход, подмену negative
положительным результатом и повреждённое доказательство. Две прежние backend-
мутации также отвергнуты. tools/run_tests.py --strict-ui: exit0, UI gate PASS
ТОЛЬКО в указанной области четырёх маршрутов, не всей VPN/аппаратной приёмки.

Исторический ручной маршрут 0.1.2 с тем же физическим драйвером и реальным
reopen отвергнут тем же независимым containment-oracle для геометрии.
Это не выдаётся за идентичный SHA runner нового автоматического маршрута.
Первый mutant-core был ошибкой тестовой проверки (чтение сохранённого COM
вместо активного). Этот FAIL/forced-cleanup сохранён, в приёмку не включён;
probe исправлен, candidate-core2/mutant-core2 повторены одним новым стеком.

Cleanup текущей UI-кампании: все собственные процессы штатно закрыты,
включая оставшееся окно 0.1.2; COM30/31 доступны эксклюзивно, localhost80/4001
не слушают. Аппаратных перепрошивок в этой UI-кампании не было.
Оригинальные исходник/EXE клиента 0.2.9 повторно сверены по SHA.

Остаётся: реальный тест между двумя ПК по SoftEther; localhost его не заменяет.
Другие UART-форматы/скорости, все варианты GUI-полей, Show/Copy password,
другие Windows/DPI не покрыты этими четырьмя маршрутами. Предыдущие успешные
аппаратные проверки ниже относятся к исходникам сервера 0.1.0–0.1.2,
не к сквозному пути standalone 0.1.3 через VPN. Редкие прежние искажения RS485
не объявлены устранёнными. Публикации/установщика/Forgejo commit/push нет.

--------------------------------------------------------------------------
ИСТОРИЯ: Remote COM Server 0.1.2 — предварительный результат, 2026-10-25
Прежний блокирующий UI-статус ниже относится только к этапу ДО pywinauto.

Новая отдельная Windows-программа. WT32 Remote COM 0.2.9, её исходник,
опубликованный EXE и драйвер не изменялись. Никаких правил firewall,
настроек VPN или сетевых адаптеров Windows не добавлено.

Реализовано:
  - реальный COM -> TCP, один клиент, точные bind/peer IPv4;
  - совместимый служебный HTTP80: login/status/bridge/disconnect;
  - ограниченные очереди, обработка partial/zero write и TCP timeout;
  - отсутствие повторной передачи старых команд при reconnect;
  - Stop всего сервера при ошибке COM, видимая причина/ротация журнала;
  - сохранение конфигурации, случайный пароль API под Windows DPAPI;
  - GUI Start/Stop/Save, COM/IP/baud/формат, счётчики, журнал;
  - отдельная standalone-сборка, без Python и драйвера в поставке.

Проверки:
  14 backend-тестов PASS (evidence/unit-tests.log).
  В том числе старый HTTP-объект после Stop не может открыть COM или
  отключить новый сеанс. Этот дефект обнаружен при разработке и исправлен.
  Две изолированные мутации отвергнуты теми же тестами: возврат гонки Stop
  и однобитное повреждение частичной COM-записи. Это НЕ UI negative control.
  Оригинальный транспорт 0.2.9 + реальная com0com COM20/21: 4096 байт
  в каждую сторону без расхождений (серверный serial в этой группе fake).

Аппаратная цепочка:
  COM20 -> оригинальный транспорт 0.2.9 -> localhost TCP -> новый сервер ->
  физический COM6/RS485 -> WT32 E08CFEE54D58 -> TCP независимого проверяющего.
  57600/8N1, 1/7/64/256/512/1024 байта, уникальные детерминированные данные.
  Первый прогон: 300.44 с, 1290 посылок, по 400760 байт, 5 reconnect.
  Повтор 0.1.1: 300.42 с, 1301 посылка, по 403464 байта, 5 reconnect.
  В обоих первая минута — простой; ошибок/расхождений не обнаружено.
  Это исходники сервера, не сквозной GUI-маршрут standalone EXE.

Опубликованный EXE старого клиента 0.2.9 (не только импорт его исходника):
  91.94 с, 306 посылок, по 122203 байта без расхождений/лишнего reconnect.
  Сервер — исходники 0.1.2; тот же COM6/WT32. Первые 30 с — простой.
  Изолированный APPDATA, штатный автозапуск по тестовому config;
  это диагностическая совместимость, НЕ приёмочный физический UI-маршрут.
  Закрыт только тестовый процесс; GUI normal-exit здесь не проверяли.
  EXE до/после SHA256:
  8DF404E2EE6F6030E1C88F55BF8DEFB0C13C15841B7DA0351AAC1AD82944C995.
  Исходник до/после:
  25452FE709009AFB2025AD2AA64636633C31D9A5180DF273CD15D252589C91DD.

Сборки:
  0.1.0 — первоначальная, не использовать: гонка Stop исправлена далее.
  0.1.1 — не использовать: неполный комплект ресурсов ttkbootstrap.
  0.1.2 — включены пакет/его assets/localization и Tcl по проверенному
  рецепту старого клиента. Standalone EXE 23511552 байта, SHA256:
  BB31379B3AC661D075768959A46E62C2F4AB0535EA7589921942198739E9455F.
  Запуск настоящего EXE подтверждён окном Remote COM Server 0.1.2,
  журналом и обновляемым runtime.json. Сервер оставлен остановленным.

НЕЗАКРЫТО / НЕ ВЫДАВАТЬ ЗА PASS:
  Полный физический GUI-маршрут и такой же маршрут на неисправной мутации
  не завершены. Sky Windows.GraphicsCapture возвращает FrameArrived /
  window capture timeout. AX-only даёт панели без подписей контролов;
  клик системной кнопки тоже отвергнут: geometry unavailable, не исполнен.
  Координаты из исходников, handler calls и preseeded config не подставляли.
  tools/run_tests.py --strict-ui: exit1, backend14 PASS, строгий UI-gate FAIL.
  Новый EXE не прошёл сквозную приёмку Start/Stop/Save/reopen.
  Реального двухкомпьютерного SoftEther VPN-прогона пока не было.
  Выше только localhost + настоящая физическая линия, не VPN throughput.
  Другие скорости/чётность физически не приняты.
  Узкие успешные обмены не отменяют прежние редкие повреждения RS485,
  зарегистрированные в отдельной матрице Worker SoftEther 0.1.87.

Восстановление:
  Через настоящий Web upload временно ставили неизменный SoftEther87,
  затем вернули исходный Beremiz1.1.211 с проверенным SHA бинарника.
  Foundation1.1.122 и лицензия сохранены; PLC STOP как до проверки.
  api/config сети побайтно по JSON-данным совпал, список файлов совпал.
  Serial перед возвратом установлен OFF/9600/8N1/idle300 как до опыта.
  После возврата Beremiz не предоставляет bridge API; status disabled.
  COM6 проверен эксклюзивным открытием/закрытием. Ethernet .220.20 доступен.
  WiFi после возврата пока не подключён, reason201; WiFi-настройки совпали
  с исходными. Доступность внешней точки доступа в этой задаче не установлена.
  evidence/hardware/cleanup.json PASS относится к настройкам/доступу/лицензии,
  не означает проверенную работу WiFi после возврата.

Это первый экспериментальный вариант, НЕ принятый публичный выпуск.
Ни Forgejo Release/commit/push, ни установщик не создавались.
