hermes-hub/agents/inbox/2026-09-02-A60-update-completes.md

Задание A60: обновление доводит себя до конца

Дата поступления

2026-09-02

База

origin/main (2f35377). A59 влит: ветка antigravity/a59-visible-update принята с исправлениями ревьюера (285ae7c). Показ и загрузку переписывать второй раз не надо.

git fetch origin --prune
git checkout -b antigravity/a60-update-completes origin/main

В main напрямую не пушить.

Порядок исполнения

Два прохода: Flash реализует, Pro проводит аудит. Пункт P0-6 написан для аудитора.

Зона: применение обновления и перезапуск. Показа и загрузки не касается — там всё принято и проверено.

---

Что уже сделано — переделывать не надо

A59 довёл обновление до экрана. Ревьюер проверил и принял:

окно при запуске, отказ по версии, молчание без обновлений   работает
полоса хода, честное Н/Д без размера                          работает
отмена с удалением недокачанного файла                        работает
отмена принимается только на проверке и загрузке              работает
SHA-256 обязательна, непроверенный файл не запускается        работает
запись о применённом обновлении только после успеха           работает

Ничего из этого не трогать.

---

Задача

Владелец нажимает «Обновить сейчас». Пакет скачивается на глазах, сумма сходится, начинается установка — и на этом всё кончается. Хаб не поднимается, окно гаснет, владелец идёт ставить сборку руками. Ровно то, из-за чего писалось A59.

---

Разрыв, и он один на обеих системах

Установщик снимает тот процесс, который его запустил и ждёт.

install_latest_update делает так:

stop_running_hub()                                  свои процессы, кроме текущего
subprocess.run(["bash", installer], timeout=600)    ЖДЁТ здесь
schedule_restart()                                  сюда управление не доходит

Linux — проверено исполнением, цепочка целиком.

1. хаб: subprocess.run(["bash", installer], capture_output=True)
        stdout установщика — труба, единственный читатель которой сам хаб
2. install-linux.sh, шаг [0/6]: stop_running_hub снимает хаб
        pgrep -u $(id -u) -f "antigravity_provider.router.web|hermes_hub_web_entry"
        никого не исключает, под шаблон попадает тот, кто запустил установщик
3. хаб мёртв  ->  у трубы не осталось читателя
4. следующий echo установщика  ->  SIGPIPE  ->  установщик умирает на шаге [1/6]
5. не установлено ничего; перезапускать нечего

Установщик не доживает до конца — он умирает раньше, чем что-либо поставит. Это не «поставилось, но не запустилось»: манифест и код остаются на прежней сборке. Проверено контрольным опытом — тот же скрипт, та же смерть родителя: с выводом в файл доходит до конца, с capture_output=True умирает.

Отсюда следует, что одной перестановкой schedule_restart делу не помочь: пока установщик пишет в трубу убитого им процесса, он не доживёт до установки при любом порядке вызовов.

Windows — прочитано по коду, живьём не проверялось. installer/HermesHubSetup.cs:280 (StopOwnedRuntime) выглядит аккуратнее: строит $protected — цепочку собственных предков, чтобы не снять того, кто его запустил. Но проверка -notin $protected стоит только на дочерних процессах внутри Stop-HubBranch. Сам процесс-цель снимается безусловно, а хаб под шаблон antigravity_provider\.router\.web подходит. Труба там та же: proc.wait(timeout=600) при Popen без перенаправления вывода. Подтвердить исполнением, а не поверить на слово.

Отката на путях установщика нет вообще: он есть только для .zip (apply_update_sync). Ни .sh, ни .exe при срыве на середине ничего не возвращают.

---

P0-1. Отсоединённый помощник

Порядок не выдумывать заново — он описан в docstring schedule_restart: сначала отсоединённый помощник, потом выход текущего процесса. Лаунчер считает хаб работающим, пока порт отвечает, поэтому поднимать новый, не освободив порт, бесполезно.

1. Хаб порождает помощника (setsid или отдельная группа процессов на Linux, DETACHED_PROCESS на Windows), передаёт ему путь к уже проверенному пакету и выходит сам, освободив порт.
2. Помощник: дожидается освобождения порта → запускает установщик → поднимает хаб → завершается.
3. Ни одна труба помощника не должна вести в хаб. Это то самое место, где всё ломается сейчас: capture_output=True делает читателем вывода тот процесс, который установщик собирается снять. Вывод установщика — сразу в файл, а не в PIPE, и не через процесс, которому предстоит умереть.
4. Помощник не наследует ни stdout хаба, ни его рабочий каталог: хаб исчезнет раньше, чем помощник закончит.
5. Помощник пишет свой ход в файл ~/.hermes/updates/apply-<время>.log, чтобы после неудачи было что показать. Пустой отказ без причины — уже было в A59, второй раз не проходит.

P0-2. Владелец видит, что происходит

1. Перед выходом статус restarting с текстом, что хаб сейчас закроется и поднимется сам. Не «установлено» — установка ещё идёт.
2. Интерфейс переживает разрыв. Опрос get_update_progress получит отказ соединения: это ожидаемое состояние, а не ошибка. Показывать «Hermes Hub перезапускается», продолжать пробовать, при возврате — перечитать страницу.
3. Не молчать бесконечно. Не поднялся за отведённое время — сказать это прямо и назвать путь к журналу помощника.

P0-3. Откат на путях установщика

1. Помощник снимает копию установленного до запуска установщика.
2. Установщик вернул не ноль или хаб не поднялся за отведённое время — вернуть прежнее и поднять его.
3. Причина отказа — с кодом возврата и хвостом вывода — в журнал и на экран при следующем старте.
4. Программа обязана остаться работоспособной. Это главное требование пункта: неудачное обновление не имеет права оставить владельца без хаба.

P0-4. Проверка исполнением

Тестами это не ловится: дело в живом переходе между версиями и в том, кто кого снимает.

1. Поставить v0.1.2-b7, обновиться на v0.1.3-b1 через интерфейс. Оба релиза опубликованы, установщики и checksums.txt на месте. Скриншоты: окно, полоса, экран после возврата.
2. Замерить время от нажатия до готовности.
3. Проверить, что работает новый код — по running_commit, снятому при старте процесса, а не по номеру версии.
4. Повторить на Windows.
5. Сорвать установку намеренно (испорченный установщик) — проверить откат и что хаб жив.
6. Проверить, что старый процесс не остался и порт занят новым.

P0-5. Обновление вообще предлагается

Найдено тем же прогоном, до того как дело дошло до установки.

Хаб на v0.1.2-b7 при живом релизе v0.1.3-b1 ответил: «Установлена сборка новее опубликованного релиза (4fa9939 от 2026-09-02)», update_available: false. Обновиться было нельзя вообще.

Причина: deployed_at в deployment_manifest.json пишется установщиком в момент установки, а не сборки, и сравнивается с published_at релиза. Поставил старую сборку сегодня — она «новее» любого релиза, и обновление не предложат больше никогда. Владелец, переставивший сборку руками, выпадает из обновлений молча.

1. Сравнивать сборки, а не дату установки. Дата установки не говорит о том, какой код внутри.
2. Если сравнить нечем — предложить обновление, а не промолчать. Молчание здесь дороже лишнего окна: владелец не узнает, что отстал.
3. Причину решения показывать. «Установлена сборка новее релиза» — вывод, а не факт; рядом должно стоять, из чего он сделан.

P0-6. Аудит вторым проходом

1. Пройти обновление целиком на обеих системах.
2. Проверить, что помощник не снимает чужого — только процессы хаба своего пользователя.
3. Проверить откат при сорвавшейся установке и что после него хаб отвечает.
4. Проверить, что интерфейс не объявляет успех раньше времени — ни на выходе хаба, ни на разрыве связи.
5. Побочные изменения объяснить.
6. Пропущенный пункт назвать пропущенным. В A59 живая проверка была пропущена молча, при том что релиз для неё был опубликован за девять часов до сдачи.

---

Ограничения

• Показ и загрузку из A59 не переделывать.
• Проверку SHA-256 и список разрешённых адресов не ослаблять.
• Показ работающего коммита и времени запуска не ломать.
• Фронтенд без npm, без сборки, без фреймворков — по docs/web-api/CONTRACT.md §1.
• Правки ревьюера из main не откатывать — включая комментарии. В A59 сняли шесть блоков с объяснением прошлых регрессий, ревьюер возвращал их руками.
• Версию 0.1.3 не понижать.
• Правило честности без исключений: неизвестное — Н/Д с причиной, а не правдоподобное число и не полоса во всю ширину.

Критерии приёмки

1. Ветка в origin, git status чист.
2. Обновление, запущенное из интерфейса, доходит до работающего нового хаба без участия владельца — на Linux и на Windows, подтверждено скриншотами.
3. После перезапуска running_commit соответствует новой сборке.
4. Сорвавшаяся установка откатывается, хаб остаётся работоспособным.
5. Старый процесс не остался, порт занят новым.
6. Журнал помощника пишется, и при отказе на него указывают.
7. Обновление предлагается по сравнению сборок, а не по дате установки; переустановка старой сборки не выключает обновления навсегда.
8. ruff check . чисто; релизный гейт пройден; тестов не меньше 740.
9. Отчёт: START_HEAD, FINAL_HEAD, origin/main, git status, X passed / Y skipped / Z failed, тайминги, скриншоты.

Главное

A59 сделал обновление видимым: владелец видит окно и видит загрузку. Дальше механизм обрывается на самом простом — установщик снимает того, кто его запустил и ждёт результата.

Задание про один шаг: чтобы после нажатия «Обновить сейчас» владелец больше ничего не делал.

Порядок сдачи

Передать точный FINAL_COMMIT_SHA.