Compare commits

...

2 commits

Author SHA1 Message Date
Ochenstarik
21caaf5fc6 docs(agents): isolate Antigravity Forgejo identity
Some checks are pending
Linux control and agent / build-and-test (push) Waiting to run
Windows build / build (push) Waiting to run
2026-09-05 16:41:53 +07:00
Ochenstarik
aae4d2dcb3 chore(agents): plan project completion and review
Some checks are pending
Linux control and agent / build-and-test (push) Waiting to run
Windows build / build (push) Waiting to run
2026-09-05 16:18:06 +07:00
4 changed files with 292 additions and 0 deletions

View file

@ -0,0 +1,104 @@
# Автопродление Agent-сертификата и ротация Control CA
- **Кому:** antigravity
- **Дата:** 2026-09-05
- **От кого:** владелец проекта через проверяющего `codex`
- **Ветка:** `antigravity/agent-certificate-lifecycle`
- **Файл отчёта:** `../done/2026-09-05-agent-certificate-lifecycle.md`
## Что нужно сделать
Закрыть оставшийся программный критерий certificate lifecycle Горизонта 0:
1. Реализовать автоматическое продление сертификата Agent до истечения срока без
потери накопленных метрик и без повторного использования отозванной identity.
2. Сделать замену сертификата атомарной: сбой после получения нового материала не
должен уничтожать рабочий старый сертификат; после успешной замены старый не
должен продолжать использоваться.
3. Определить и зафиксировать порог продления, retry/backoff, поведение при
недоступном Control, при clock skew и при отзыве сертификата.
4. Документировать операционную ротацию Control CA с rollback/recovery: подготовка,
распространение trust, переключение, проверка Agent/Operator/Desktop,
завершение старой CA и действия при частично обновлённом флоте.
5. Обновить roadmap/horizon status только для критериев, доказанных тестами и
воспроизводимой процедурой. Не объявлять Горизонт 0 закрытым: физический mesh
acceptance проверяется отдельным заданием.
## Порядок выполнения
Это задание начинается после закрытия уже находящихся в твоём inbox задач:
1. `2026-08-19-console-behaviour-tests.md`;
2. `2026-08-19-console-events-throttle.md`;
3. `2026-08-20-console-node-metrics.md`;
4. `2026-08-20-reconciliation-poll-interval.md`.
По каждой из них нужен отдельный отчёт; объединять их изменения с certificate
lifecycle в один PR запрещено.
### Обязательное обновление локального репозитория перед началом
Не начинать certificate lifecycle из текущей рабочей ветки или поверх чужих
незакоммиченных изменений. Сначала завершить и сдать предыдущую задачу, убедиться,
что рабочее дерево чистое, затем выполнить:
```powershell
git -c core.sshCommand="ssh -i C:/Users/trush/.ssh/forgejo-agi2 -o IdentitiesOnly=yes -p 2222" fetch gitea --prune
git switch main
git -c core.sshCommand="ssh -i C:/Users/trush/.ssh/forgejo-agi2 -o IdentitiesOnly=yes -p 2222" pull --ff-only gitea main
git switch -c antigravity/agent-certificate-lifecycle
git status --short --branch
```
Использовать только отдельную Forgejo identity Antigravity (`forgejo-agi2`) и
`IdentitiesOnly=yes`; не использовать repo-local ключ `codex-1`, принадлежащий
проверяющему. Перед изменениями предъявить успешный `ls-remote gitea HEAD` с тем
же `core.sshCommand` и сравнить полученный SHA с `git rev-parse HEAD` после
создания ветки.
Если `git pull --ff-only` не проходит, локальный `main` содержит собственные
коммиты либо рабочее дерево не чистое — не использовать reset/rebase и не терять
изменения. Остановиться, записать фактический вывод в отчёт и передать ситуацию
проверяющему. В отчёте обязательно привести commit SHA актуального `gitea/main`,
от которого создана рабочая ветка.
## Границы
Допустимы Agent, Control, Core, относящиеся к lifecycle тесты и документация
ротации CA. Не менять web console, Links, provisioning actions, `deploy/**`,
release workflows, MSIX version и release-status переводы. Доверенная подпись
MSIX и физическая three-server приёмка — отдельные работы.
Не ослаблять mTLS, revocation, CSR ownership, срок одноразовых token или проверки
привязки Node identity. Не добавлять silent fallback на недоверенный сертификат.
## Как проверить результат
Обязательные доказательства в отчёте:
- `dotnet build ServerMonitorManager.slnx --configuration Release` — фактический
вывод, ошибок 0;
- полный `dotnet test` Control-набора — все тесты зелёные;
- тесты: продление при остатке менее порога; отсутствие продления выше порога;
Control недоступен — старый валидный сертификат продолжает работать и метрики
сохраняются; revoked certificate не продлевается; mismatch `node_id` отвергается;
прерванная атомарная замена сохраняет рабочий сертификат; повтор запроса
идемпотентен либо явно безопасен;
- каждый новый тест показать зелёным на исправном коде и красным на намеренно
сломанном соответствующем поведении;
- отдельная репетиция процедуры CA rotation на disposable Control + минимум одном
Agent: команды, фактические fingerprints/chain results до и после, reconnect и
rollback. Если полноценная dual-trust схема ещё не реализуема, не отмечать
критерий выполненным, а вернуть точный блокер и минимальное следующее задание;
- ссылки на зелёные CI-прогоны PR.
## Контекст и ограничения
Источник требований: `docs/product-horizons.md`, Горизонт 0, и
`docs/roadmap.md`, этап 14. В репозитории уже есть
`CertificateLifecycleTests`; существование тестов не доказывает наличие полного
runtime lifecycle — необходимо проследить фактический Agent path от определения
срока до атомарного переключения сохранённого PFX.
Приёмку выполняет `codex`. Не пушить в `main` и не смешивать с соседними
исправлениями.

View file

@ -0,0 +1,130 @@
# Отчёт: полный анализ состояния проекта
- **Задание:** `../inbox/2026-09-05-full-project-analysis.md`
- **Дата:** 2026-09-05
- **Изменения продукта:** отсутствуют
## Итог
Проект представляет собой функционально насыщенную alpha-версию: Control,
Agent, Core и restricted Provisioning Helper собираются; основной набор из 158
тестов проходит. Базовые monitoring, mTLS identities, Links, SQLite, web console,
release/bootstrap chain и каркас provisioning реализованы. Проект пока нельзя
считать production-ready: не закрыт Горизонт 0, mutating provisioning ограничен
сменой timezone, нет физической mesh/reboot-приёмки и доверенной подписи MSIX.
В roadmap отмечено 100 выполненных и 79 невыполненных пунктов. Значительная
часть 79 пунктов относится к будущим горизонтам и не должна начинаться сейчас.
## Что реализовано
- WinUI Desktop, Control Hub ASP.NET Core, Linux Agent, общий Core и отдельный
restricted provisioning helper.
- Мониторинг ресурсов, SSH/WireGuard/latency, локальная история и diagnostics.
- mTLS enrollment и разделённые Agent/Operator/Automation identities.
- Directional Links, TTL, kill switch, audit, event stream и reconciliation.
- SQLite schema/retention/backup, Agent offline buffer и нагрузочный тест 100 Nodes.
- Bootstrap/install/update/rollback/uninstall, WireGuard/nftables, signed release
manifest и compatibility checks.
- Provisioning job state machine, immutable plan, execution grant, audit и один
фактически исполняемый mutating increment: timezone-only с verification/rollback.
## Что осталось: фактический порядок
### P0 — закрыть Горизонт 0
1. Провести физический acceptance на реальной топологии Hub + source Node + два
destination Node с `SMM_ACCEPT_RESTORE=1 SMM_ACCEPT_REBOOT=1`. CI это не
заменяет.
2. Завершить lifecycle сертификатов: автопродление Agent и документированная,
проверенная ротация Control CA.
3. Настроить постоянную доверенную Windows code-signing identity. Сейчас MSIX
test-signed.
4. Разобрать дефект версии MSIX: `Package.appxmanifest` всё ещё содержит
`1.0.0.6`; открыто отдельное непринятое задание.
5. Синхронизировать release status: корневой README и все 11 переводов говорят
`alpha.14`, тогда как история релизов дошла до `alpha.20`.
### P1 — уже заведённые дефекты текущей alpha
- Web console: нет поведенческих JS-тестов; существующие проверки в основном
доказывают наличие разметки.
- Web console: каждое `link.*`/`agent.*` событие напрямую вызывает
`loadDashboardData`, то есть пачка событий усиливает запросы; throttle/debounce
отсутствует.
- Web console: нет Operator API и UI для последних метрик/короткой истории узлов.
- Link reconciliation: маркер читается до проверки `_backoffUntil`, а timer
жёстко использует `min(configured, 30s)`; непринятое задание подтверждено кодом.
- Desktop UI для управления Automation identities/tokens отсутствует.
- Группы/теги/избранное, настраиваемые alert rules и управляемая отдельная
terminal-key identity отсутствуют.
### P2 — довести provisioning до полезного продукта
- Полная execution/retry/verification/rollback state machine для остальных
действий, versioned schemas и desired/factual/drift для всех action types.
- Полный preflight OS/arch/SSH/firewall/APT/capabilities.
- Desktop wizard locale/packages/swap/unattended upgrades.
- Root-only backups и symlink protection.
- User/SSH key/sudo/block/session/service lifecycle с factual verification и
rollback.
- Managed firewall editor и безопасная двухфазная миграция SSH-порта.
### P3 — качество и эксплуатация
- Настоящие Debian reboot tests, полная VM matrix и physical alpha acceptance.
- Долговременный soak test и измеримые performance budgets.
- Устранить предупреждения анализаторов: solution build выдаёт 41 warning;
наиболее содержательные — незакрываемые `SemaphoreSlim` в `MetricBuffer`,
непереданный cancellation token в helper и дорогой/неструктурированный logging.
- Добавить Desktop и Desktop security test project в общий solution либо явно
документировать раздельную проверку. Сейчас обычный `dotnet build/test` solution
их не охватывает.
- Разобрать зависание Desktop security tests: отдельный прогон собрал проект, но
не завершился более чем за минуту и был остановлен. Причина не определена.
### P4 — только после соответствующих гейтов
- Горизонт 1: approval policies, alerts/incidents, read-only Telegram,
Docker/systemd observation/actions, Backup Manager.
- Горизонт 2: полноценная web authentication model, Secret Vault, centralized
logs, security posture, multi-Hub phase 1 и один Xray module.
- Горизонт 3: KAgent integration.
- Дополнительные Desktop/mobile clients и push notifications.
## Несогласованности и организационный долг
- `ServerMonitorManager.slnx` не содержит Desktop и Desktop security tests,
хотя README предлагает `dotnet build ServerMonitorManager.slnx` как сборку
Windows client.
- README заявляет текущий релиз `alpha.14`; release policy и tag history — до
`alpha.20`.
- В `agents/*/inbox` без одноимённых отчётов остаются 7 ранее выданных задач:
4 Antigravity и 3 Codex. Наличие задания не доказывает, что работа не велась,
но по принятой схеме результат не сдан и не принят.
- Поиск TODO/FIXME/NotImplemented не обнаружил явных продуктовых заглушек;
совпадения `placeholder` в Desktop относятся к UI placeholder text.
## Проверки и фактический результат
1. `dotnet restore ServerMonitorManager.slnx --verbosity minimal`
— exit 0, восстановлены пять проектов solution.
2. `dotnet build ServerMonitorManager.slnx --configuration Release --no-restore`
— exit 0, 0 ошибок, 41 предупреждение.
3. `dotnet test tests/ServerMonitorManager.Control.Tests/... --configuration Release --no-build`
— вне sandbox: 158 passed, 0 failed, 0 skipped, 17 s.
4. Тот же test в sandbox — 132 passed, 26 failed из-за denied access к Windows
certificate storage/Event Log. Повтор вне sandbox доказал, что это ограничение
среды, а не продуктовый regression.
5. `dotnet test tests/ServerMonitorManager.Desktop.Security.Tests/...`
— restore/build успешны с предупреждениями; test run не завершился более чем
за минуту, остановлен. Зелёный результат не получен.
6. Статический подсчёт: 67 source `.cs`, 33 test `.cs`, 164 `[Fact]/[Theory]`,
roadmap 100 checked / 79 unchecked.
## Не сделано
Физические Linux/mesh/reboot проверки, GitHub Actions/release rehearsal и
установка MSIX поверх старой версии не запускались: для них нужны внешняя
топология, GitHub execution и/или установленный пакет. Найденные дефекты не
исправлялись согласно границам аналитической задачи.

View file

@ -0,0 +1,26 @@
# Полный анализ состояния проекта
- **Кому:** codex
- **Дата:** 2026-09-05
- **От кого:** владелец проекта
- **Ветка:** текущая рабочая ветка (анализ без изменения продукта)
- **Файл отчёта:** `../done/2026-09-05-full-project-analysis.md`
## Что нужно сделать
Провести полный анализ проекта и определить, что осталось доделать.
## Границы
Не исправлять найденные дефекты и не менять продуктовый код. Результат —
доказательный отчёт о текущем состоянии, незавершённых работах и приоритетах.
## Как проверить результат
Проверить структуру и документацию, состояние Git, маркеры незавершённости,
конфигурацию сборки и тестов; запустить доступные проверки и привести команды
с фактическим результатом.
## Контекст и ограничения
Соблюдать `AGENTS.md` и `agents/README.md`. Не смешивать анализ с исправлениями.

View file

@ -0,0 +1,32 @@
# Проверка полного завершения программы
- **Кому:** codex
- **Дата:** 2026-09-05
- **От кого:** владелец проекта
- **Ветка:** текущая ветка, без реализации продуктовых изменений
- **Файл отчёта:** `../done/2026-09-05-review-program-completion.md`
## Что нужно сделать
Выступать проверяющим работ Antigravity по завершению Server Monitor Manager:
выдавать атомарные задания в порядке продуктовых горизонтов, проверять код,
фактические команды, отрицательные тесты и внешнюю приёмку, принимать следующий
этап только после закрытия критериев предыдущего.
## Границы
Не выполнять продуктовую реализацию вместо Antigravity. Не принимать работу по
описанию без воспроизводимых доказательств. Не разрешать переход через гейты из
`docs/product-horizons.md`.
## Как проверить результат
Для каждого задания: сверка diff с границами, полный релевантный набор тестов,
проверка заявленного красного/зелёного сценария и отдельный акт приёмки. Общий
результат — закрытые критерии всех горизонтов и отсутствие открытых пунктов
актуального roadmap.
## Контекст и ограничения
Исполнитель реализации — `antigravity`. Проверяющий — `codex`. Первым закрывается
текущий backlog Antigravity, затем Горизонт 0; новые горизонты до этого запрещены.