server-monitor-manager/agents/claude/notes/2026-08-18-передача-состояния.md
Ochenstarik d52bb0e515 chore(agents): задания, отчёты и разбор PR #63
Задания и отчёты по актуализации проекта согласно agents/README.md:
синхронизация git-состояния, обновление зависимостей, разбор PR #63.

Правок workflow ветка не несёт: обновления GitHub Actions доставляются
слиянием PR Dependabot #44 и #46, чтобы не применить одно и то же дважды.
PR #45 (cosign-installer) не принят — релизный workflow на pull request
не выполняется, поэтому зелёные проверки его не покрывают.

Также добавлена записка передачи состояния, закоммитить её разрешил
владелец.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 16:29:20 +07:00

8.5 KiB
Raw Blame History

Передача состояния: как продолжить работу в новом чате

Этот файл заменяет переписку. Он написан для того, чтобы новый чат начинался с одного сообщения и не требовал пересказа истории.

Первое сообщение в новом чате

Репозиторий C:\Users\Ochenstarik\Agent_projects\server-monitor-manager, GitHub ochenstarik-ui/server-monitor-manager. Прочитай agents/README.md и agents/claude/notes/2026-08-18-передача-состояния.md, сверь состояние с GitHub и продолжай как главный агент: проверяешь работу Codex и Antigravity, пишешь им задания, мержишь и выпускаешь релизы.

Больше ничего пересказывать не нужно: доска, задания, отчёты и архив лежат в репозитории.

Где что лежит

Что Где
Правила работы агентов agents/README.md
Задания агенту agents/<agent>/inbox/
Отчёты агента agents/<agent>/done/
Принятые пары «задание — отчёт» agents/_accepted/ГГГГ-ММ-ДД-имя/
Доска состояния (прежний формат) agents/_salvage-2026-08-18/smm-deliverables/README.md
Архив закрытых заданий agents/_salvage-2026-08-18/smm-deliverables/Старые задачи/
Инструкция владельцу по серверам agents/_salvage-2026-08-18/smm-deliverables/smm-cleanup-and-install-2026-08-15.md

Доску стоит перенести из _salvage в постоянное место — она живая, а не архив.

Состояние на 2026-08-18

  • mainf8e751c, слит PR #62 codex/release-alpha20;
  • последний релиз — v0.1.0-alpha.20;
  • открыты: PR #63 antigravity/console-links (управление Links в консоли), PR #64 chore/agents-workspace (эта самая схема папок), плюс dependabot;
  • ветка claude/deps-update содержит незакоммиченные правки двух workflow и два новых задания в agents/claude/inbox/.

Сожжённые номера версий

alpha.10, alpha.11, alpha.19 — теги созданы, Release pipeline упал, релизы не опубликованы, номера не переиспользуются.

alpha.19 сожжён при мне и по процедурной дыре, а не по вине исполнителя: шаг Package bootstrap сверяет DEFAULT_RELEASE_TAG в deploy/smm-setup.sh с выпускаемым тегом, но весь блок закрыт условием refs/tags/*, поэтому репетиция через workflow_dispatch идёт по refs/heads/main и эту сверку пропускает. Репетиция была зелёной, тег упал.

Вывод, который дороже самого случая: репетиция, не покрывающая шаги, исполняемые только на теге, не является репетицией. Проверять это до следующего выпуска.

Рабочие соглашения

Выведены из происшествий, а не из общих соображений.

  1. Задание содержит только предстоящую работу. Файлы, начинавшиеся с описания уже сделанного, исполнитель принимал за отчёт о выполнении: Codex ответил «задание уже выполнено, PR #58» вместо работы над невыполненной частью. Сделанное живёт на доске, а не в задании.
  2. Отчёт — раздел в описании PR. Отдельный файл с отчётом результатом не является. Antigravity однажды сдал только такой файл, не создав ни ветки, ни PR.
  3. Проверять по репозиторию, а не по отчёту. Смотреть диф от базы слияния, а не от main: отставшая ветка в обычном дифе выглядит так, будто удаляет чужую работу.
  4. Критерий приёмки должен быть достижим. «Проверка запустилась автоматически» была недостижима: событие от GITHUB_TOKEN не запускает другие workflow. Это дефект задания, а не исполнителя.
  5. Границы областей прописывать явно. Codex — deploy/**, релизный пайплайн, проверка релиза. Antigravity — src/**, консоль, тесты Control и Desktop. Пересечение областей ломает параллельную работу.
  6. Зелёный CI не означает работающую машину. Так найдены: отсутствующий cosign, права на каталог mesh, отдача ассетов из ресурсов сборки. Каждый раз тест подставлял временный путь и проходил, а на сервере отказывало.
  7. Команды владельцу помечать, где выполнять: 🖥 на Windows, 🐧 на сервере. Путаница машин стоила нескольких заходов.
  8. Долгие загрузки — с индикатором. Молчащий curl -fsSL на 24 МБ дважды принят за зависание и прерван.

Живая установка

Проверено на настоящих машинах, а не в CI.

  • Hub 178.212.13.102 (host1885995-3.hostland.pro), Ubuntu 24.04 x86_64, поставлен из v0.1.0-alpha.14;
  • отпечаток CA: EB:05:E5:16:42:EE:97:28:C2:E9:EA:6F:3E:48:3C:0C:1C:1E:02:E0:ED:9B:AF:7B:BF:24:2C:19:D4:4B:11:C4;
  • публичный ключ WireGuard Hub: AjN8XwPB11bRQa0fO5ljPlAWc0FxU+fxbeUT8AZczHk=;
  • Node ai-agentvm1957808.vds.chsl.one, адрес 10.77.0.2, mesh собран, ping 7.6 мс. На этой машине работает 3x-ui и он не пострадал;
  • свободных серверов больше нет. tests/acceptance/three-server-mesh.sh требует Hub и три узла: источник и две цели, потому что смысл проверки в том, что к одной цели доступ по Link открыт, а ко второй закрыт. На двух машинах это не проверить;
  • WSL под узлы не годится: все дистрибутивы WSL2 делят один сетевой стек, два smm0 с разными адресами не поднять. Проверено экспериментом.

Физическая приёмка — единственный пункт Горизонта 0, не закрываемый кодом.

Что важно знать про продукт

  • подпись релиза проверяется настоящим материалом с обеих сторон: установкой на чистый runner (Linux) и UpdateService (Windows), автоматически на каждом релизе;
  • проверка подписи требует исходящего доступа к службам sigstore; в закрытом контуре установка зависнет;
  • таблица nftables inet ochenstarik_smm цепляется только к хуку forward и только к трафику smm0 → smm0. Хука input в ней нет, политика accept. Поэтому установка на сервер с 3x-ui безопасна — проверено на живой машине;
  • опубликованный тег неизменяем, ассеты не заменяются: исправление выпускается следующим номером.