chore: актуализация проекта — приёмка, задания и история релизов в документации #65
6 changed files with 399 additions and 1 deletions
206
CHANGELOG.md
206
CHANGELOG.md
|
|
@ -7,8 +7,198 @@ Versions follow the tags in this repository.
|
|||
|
||||
## [Unreleased]
|
||||
|
||||
### Added
|
||||
- Link management and a real-time Event Journal in the Control web console (#63)
|
||||
|
||||
### Changed
|
||||
- Task, report, and acceptance workflow for agents moved into `agents/` (#64)
|
||||
- `actions/download-artifact` pinned to v8.0.1 across all workflows (#46)
|
||||
- `docker/setup-qemu-action` pinned to v4.2.0 (#44)
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.20] — 2026-08-18
|
||||
|
||||
Published. Carries the work that `v0.1.0-alpha.19` failed to publish.
|
||||
|
||||
### Added
|
||||
- Release pipeline now tests the latest published release before cutting a new
|
||||
one (#62)
|
||||
- Operator web console for nodes, links, and enrollment code generation (#59)
|
||||
- Guided unified installer (#58)
|
||||
- Complete server uninstall mode (#60)
|
||||
- Testing-only password login for the web console (#61)
|
||||
- Node enrollment endpoint (#53)
|
||||
- Desktop update proof (#55)
|
||||
|
||||
### Fixed
|
||||
- Mesh state directory permissions created before Control starts (#57)
|
||||
- `DEFAULT_RELEASE_TAG` in the packaged convenience installer matches the tag
|
||||
being produced — the defect that burned `v0.1.0-alpha.19`
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.19] — 2026-08-18 — burned, not published
|
||||
|
||||
The tag exists, but the Release pipeline failed before a GitHub Release was
|
||||
published: the packaged convenience installer's `DEFAULT_RELEASE_TAG` did not
|
||||
match the immutable tag. The version number is burned and must not be moved,
|
||||
deleted, recreated, or reused. Its content was published under
|
||||
`v0.1.0-alpha.20`.
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.18] — 2026-08-18
|
||||
|
||||
### Fixed
|
||||
- Wrong-identity negative test selects cosign v3 explicit detached-output mode,
|
||||
matching the production consumer's detached signature and certificate
|
||||
contract (#56)
|
||||
|
||||
First release required to complete both automatic `workflow_run` verification
|
||||
and manual `workflow_dispatch` re-verification.
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.17] — 2026-08-18
|
||||
|
||||
### Fixed
|
||||
- Checksum verification stays fail-closed while its success line is suppressed,
|
||||
so pass-through commands such as `node-code` return only machine-readable
|
||||
bootstrap output (#54)
|
||||
|
||||
Automatic verification completed clean-host Hub and Node installation, then the
|
||||
negative-test harness stopped while creating a wrong-identity signature:
|
||||
cosign v3 requires an explicit bundle or legacy detached-output mode.
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.16] — 2026-08-17
|
||||
|
||||
### Fixed
|
||||
- Acceptance shell clears its command hash after removing test-provisioned
|
||||
cosign (#52)
|
||||
|
||||
Automatic verification proved clean-host Hub installation, then failed on the
|
||||
Node: the convenience installer wrote the checksum success line to stdout ahead
|
||||
of the machine-readable `SMMNODE2` enrollment code, so the value was rejected.
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.15] — 2026-08-17
|
||||
|
||||
### Added
|
||||
- Pinned, checksum-verified cosign binary provisioned by the installer (#43)
|
||||
|
||||
First release that provisions cosign. Its verification proved clean-host Hub
|
||||
installation and manifest verification, then stopped before the clean-host Node
|
||||
installation: the acceptance script retained the deliberately removed cosign
|
||||
path in Bash's command hash.
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.14] — 2026-08-15
|
||||
|
||||
### Fixed
|
||||
- Release signing consistency between producer and consumer (#41, #42)
|
||||
|
||||
First release with the complete manifest, keyless signature, and Fulcio
|
||||
certificate set, so its published assets can be verified. A clean host cannot
|
||||
install it because the release does not provision cosign — preserve it for
|
||||
verification and historical evidence, do not use it for installation.
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.13] — 2026-08-13
|
||||
|
||||
### Fixed
|
||||
- Windows checksum asset normalized to LF so GNU `sha256sum -c` can consume it
|
||||
(#39)
|
||||
|
||||
Published with a keyless manifest signature but without the Fulcio signing
|
||||
certificate required by production consumers. The immutable release remains
|
||||
published as historical evidence.
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.12] — 2026-08-13
|
||||
|
||||
### Fixed
|
||||
- Network-dependent alpha.8 compatibility test replaced in release
|
||||
verification (#38)
|
||||
|
||||
Published with a keyless manifest signature but without the Fulcio signing
|
||||
certificate, so consumers cannot verify that signature. Its Windows
|
||||
`SHA256SUMS` asset also used CRLF and was not consumable by GNU
|
||||
`sha256sum -c`. Neither defect is repaired in place.
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.11] — 2026-08-12 — burned, not published
|
||||
|
||||
The tag exists, but the Release pipeline failed before a GitHub Release was
|
||||
published. The version number is burned and must not be moved, deleted,
|
||||
recreated, or reused.
|
||||
|
||||
Content carried by the tag: release contract updated to alpha.10, backward
|
||||
compatibility test removed from the bootstrap job, Debian VM reboot constraint
|
||||
documented, translations and roadmap synchronized.
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.10] — 2026-08-11 — burned, not published
|
||||
|
||||
The tag exists, but the Release pipeline failed before a GitHub Release was
|
||||
published. The version number is burned and must not be moved, deleted,
|
||||
recreated, or reused.
|
||||
|
||||
Content carried by the tag: signed delivery queue B (#35), version comparison
|
||||
fix (#36).
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.9] — 2026-08-10
|
||||
|
||||
### Added
|
||||
- Monitor snapshot contract (#32)
|
||||
|
||||
### Changed
|
||||
- Single-writer release pipeline: `linux-release.yml` is the sole GitHub
|
||||
Release publisher (#33)
|
||||
|
||||
`smm-setup.sh`, its checksum, the bootstrap script, platform archives, SBOMs,
|
||||
and the signed manifest are reproducible from the tagged tree. The installer
|
||||
fetches only same-tag assets and verifies the bootstrap checksum before
|
||||
execution.
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.8] — 2026-08-10
|
||||
|
||||
### Added
|
||||
- Source-scoped monitor role (#29)
|
||||
- Certificate lifecycle management
|
||||
- Signed delivery, queue A
|
||||
- Reproducible builds (#15)
|
||||
- Product horizons and KAgent integration specifications (#13)
|
||||
|
||||
### Fixed
|
||||
- CycloneDX SBOM generation in release jobs (#28)
|
||||
- Repository hygiene (#14)
|
||||
|
||||
Contains the v1 `server-monitor-manager-bootstrap-manifest.json` layout and an
|
||||
orphaned `server-monitor-manager-manifest.sig` without the corresponding
|
||||
manifest v2. Published assets remain immutable; the anomaly is documented
|
||||
rather than repaired in place.
|
||||
|
||||
---
|
||||
|
||||
## [v0.1.0-alpha.7] — 2026-08-09
|
||||
|
||||
### Added
|
||||
- Background link reconciliation service for the Control plane (#12)
|
||||
- Link reconciliation driven by factual state (#16)
|
||||
- Provisioning helper coverage for a missing node row (#17)
|
||||
|
||||
### Changed
|
||||
- Link policy reconciliation now runs continuously (#11)
|
||||
|
|
@ -90,7 +280,21 @@ Versions follow the tags in this repository.
|
|||
- Secure node enrollment documentation
|
||||
- Windows build verification in CI
|
||||
|
||||
[Unreleased]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.6...HEAD
|
||||
[Unreleased]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.20...HEAD
|
||||
[v0.1.0-alpha.20]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.19...v0.1.0-alpha.20
|
||||
[v0.1.0-alpha.19]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.18...v0.1.0-alpha.19
|
||||
[v0.1.0-alpha.18]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.17...v0.1.0-alpha.18
|
||||
[v0.1.0-alpha.17]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.16...v0.1.0-alpha.17
|
||||
[v0.1.0-alpha.16]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.15...v0.1.0-alpha.16
|
||||
[v0.1.0-alpha.15]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.14...v0.1.0-alpha.15
|
||||
[v0.1.0-alpha.14]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.13...v0.1.0-alpha.14
|
||||
[v0.1.0-alpha.13]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.12...v0.1.0-alpha.13
|
||||
[v0.1.0-alpha.12]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.11...v0.1.0-alpha.12
|
||||
[v0.1.0-alpha.11]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.10...v0.1.0-alpha.11
|
||||
[v0.1.0-alpha.10]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.9...v0.1.0-alpha.10
|
||||
[v0.1.0-alpha.9]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.8...v0.1.0-alpha.9
|
||||
[v0.1.0-alpha.8]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.7...v0.1.0-alpha.8
|
||||
[v0.1.0-alpha.7]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.6...v0.1.0-alpha.7
|
||||
[v0.1.0-alpha.6]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.5...v0.1.0-alpha.6
|
||||
[v0.1.0-alpha.5]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.4...v0.1.0-alpha.5
|
||||
[v0.1.0-alpha.4]: https://github.com/ochenstarik-ui/server-monitor-manager/compare/v0.1.0-alpha.3...v0.1.0-alpha.4
|
||||
|
|
|
|||
87
agents/claude/done/2026-08-20-docs-sync.md
Normal file
87
agents/claude/done/2026-08-20-docs-sync.md
Normal file
|
|
@ -0,0 +1,87 @@
|
|||
# Отчёт: документация приведена в соответствие с историей релизов
|
||||
|
||||
- **Задание:** `../inbox/2026-08-20-docs-sync.md`
|
||||
- **Агент:** `claude`
|
||||
- **Дата:** 2026-08-20
|
||||
- **Ветка:** `claude/deps-update`
|
||||
|
||||
## Что сделано
|
||||
|
||||
**`CHANGELOG.md`.** Дописаны 14 отсутствовавших версий, alpha.7 … alpha.20.
|
||||
Записи выведены из тегов и коммитов между ними, а не из памяти. Прежняя
|
||||
секция `Unreleased` со ссылками на #10–#12 оказалась содержимым alpha.7 —
|
||||
перенесена туда. Новый `Unreleased` описывает слитое после alpha.20: #63,
|
||||
#64, #44, #46. Ссылки сравнения версий перестроены для всех 20 тегов.
|
||||
|
||||
Сожжённые номера помечены прямо в заголовке — `burned, not published` — с
|
||||
указанием, чем упал пайплайн и под какой версией вышло их содержимое:
|
||||
|
||||
- alpha.10 и alpha.11 — пайплайн упал до публикации;
|
||||
- alpha.19 — `DEFAULT_RELEASE_TAG` в упакованном установщике не совпал
|
||||
с тегом; содержимое вышло под alpha.20.
|
||||
|
||||
Для опубликованных, но дефектных версий записи содержат сам дефект:
|
||||
alpha.8 (осиротевшая подпись без manifest v2), alpha.12 и alpha.13
|
||||
(подпись без сертификата Fulcio), alpha.14 (проверяемая, но не
|
||||
устанавливаемая на чистый хост), alpha.15 … alpha.17 (на чём остановилась
|
||||
проверка). Иначе CHANGELOG подсказывал бы ставить версию, которая не
|
||||
ставится.
|
||||
|
||||
**`docs/release-policy.md`.** Добавлена запись про alpha.20 — что он
|
||||
исправляет, что переносит из сожжённого alpha.19.
|
||||
|
||||
**`docs/roadmap.md`.** Веб-консоли в плане не было вовсе, поэтому это не
|
||||
переключение галочек, а дописывание фактически поставленного. В этап 2:
|
||||
консоль оператора, отдача ассетов из встроенных ресурсов, вход по паролю
|
||||
для тестовых стендов. В этап 3: управление Links из консоли, аварийное
|
||||
отключение, раздельные желаемое/фактическое состояния, журнал событий.
|
||||
В этап 7: режим полного удаления сервера, пошаговый объединённый установщик.
|
||||
|
||||
## Как проверено
|
||||
|
||||
Все 20 версий на месте:
|
||||
|
||||
```
|
||||
$ grep -c "^## \[v0.1.0-alpha" CHANGELOG.md
|
||||
20
|
||||
```
|
||||
|
||||
Даты записей сверены с датами тегов — расхождений нет:
|
||||
|
||||
```
|
||||
$ for n in $(seq 1 20); do t="v0.1.0-alpha.$n"; ... done
|
||||
v0.1.0-alpha.1 2026-07-16 2026-07-16 совпадает
|
||||
...
|
||||
v0.1.0-alpha.20 2026-08-18 2026-08-18 совпадает
|
||||
```
|
||||
|
||||
Двадцать строк, все «совпадает».
|
||||
|
||||
## Что не сделано
|
||||
|
||||
**README и одиннадцать переводов не тронуты намеренно.** `README.md:101`
|
||||
по-прежнему называет `v0.1.0-alpha.14`. `docs/release-policy.md` отдаёт
|
||||
строку статуса релиза в корневом README и в переводах в единоличное
|
||||
владение владельцу релиза и прямо требует запрашивать изменение, а не
|
||||
править самому. Запрошено заданием
|
||||
`agents/codex/inbox/2026-08-20-readme-release-status.md`.
|
||||
|
||||
Порядок регламента нарушен: задание в `inbox/` записано после выполнения
|
||||
работы, а не до. Указываю прямо, чтобы это не выглядело соблюдённым.
|
||||
|
||||
## Замечено рядом
|
||||
|
||||
1. **`README.md:101` и переводы** — предмет выданного задания Codex.
|
||||
2. **В roadmap этап 6 содержит пункт «синхронизировать все переводы README
|
||||
с текущим release status»** — он остаётся невыполненным и закрывается
|
||||
тем же заданием.
|
||||
3. **Содержание записей CHANGELOG выведено из заголовков коммитов и
|
||||
merge-коммитов.** Там, где заголовок был неинформативен, запись вышла
|
||||
короче фактического объёма работы. Это не выдумка, но и не полный
|
||||
пересказ: восстановление постфактум точнее заголовков быть не может.
|
||||
|
||||
## Вопросы к приёмке
|
||||
|
||||
Записи alpha.10, alpha.11 и alpha.19 оставлены в CHANGELOG как сожжённые.
|
||||
Альтернатива — не упоминать их вовсе. Считаю упоминание правильным:
|
||||
читатель, увидев разрыв в нумерации, иначе решит, что запись потеряна.
|
||||
41
agents/claude/inbox/2026-08-20-docs-sync.md
Normal file
41
agents/claude/inbox/2026-08-20-docs-sync.md
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
# Привести документацию в соответствие с фактическим состоянием релизов
|
||||
|
||||
- **Кому:** `claude`
|
||||
- **Дата:** 2026-08-20
|
||||
- **От кого:** владелец проекта (в чате: «делай что можно. и продолжай»)
|
||||
- **Ветка:** `claude/deps-update`
|
||||
- **Файл отчёта:** `../done/2026-08-20-docs-sync.md`
|
||||
|
||||
## Что нужно сделать
|
||||
|
||||
`CHANGELOG.md` заканчивался на `v0.1.0-alpha.6` от 2026-07-31, тогда как
|
||||
теги идут до `v0.1.0-alpha.20`. Секция `Unreleased` ссылалась на давно
|
||||
слитые #10–#12. `docs/release-policy.md` вёл построчную историю версий, но
|
||||
обрывался на alpha.19. `docs/roadmap.md` не отражал подсистемы, слитые в
|
||||
`main`.
|
||||
|
||||
Восстановить историю по фактам репозитория — тегам и коммитам между ними,
|
||||
а не по памяти:
|
||||
|
||||
- CHANGELOG: записи для alpha.7 … alpha.20, сожжённые номера помечены как
|
||||
сожжённые, ссылки сравнения версий выправлены;
|
||||
- release-policy: запись про alpha.20;
|
||||
- roadmap: отметить фактически поставленное.
|
||||
|
||||
## Границы
|
||||
|
||||
Не менять код, workflow и версии сборки. **Не трогать строку статуса релиза
|
||||
в README и переводах**: по `docs/release-policy.md` эти пути принадлежат
|
||||
владельцу релиза, изменение запрашивается заданием, а не правится напрямую.
|
||||
|
||||
## Как проверить результат
|
||||
|
||||
- в CHANGELOG присутствуют все 20 версий: `grep -c "^## \[v0.1.0-alpha"`;
|
||||
- даты записей совпадают с датами тегов: `git log -1 --format=%ad --date=short <тег>`;
|
||||
- содержание записей выводится из `git log` между соседними тегами.
|
||||
|
||||
## Контекст и ограничения
|
||||
|
||||
Сожжённые номера `alpha.10`, `alpha.11`, `alpha.19` не переиспользуются:
|
||||
теги существуют, релизы не опубликованы. Запись о них в CHANGELOG обязана
|
||||
показывать это прямо, иначе читатель решит, что релиз был.
|
||||
52
agents/codex/inbox/2026-08-20-readme-release-status.md
Normal file
52
agents/codex/inbox/2026-08-20-readme-release-status.md
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
# Синхронизировать release status в README и переводах
|
||||
|
||||
- **Кому:** `codex`
|
||||
- **Дата:** 2026-08-20
|
||||
- **От кого:** главный агент (`claude`)
|
||||
- **Ветка:** `codex/readme-release-status`
|
||||
- **Файл отчёта:** `../done/2026-08-20-readme-release-status.md`
|
||||
|
||||
## Что нужно сделать
|
||||
|
||||
`README.md:101` утверждает, что текущий тестовый выпуск — `v0.1.0-alpha.14`.
|
||||
Фактически опубликован `v0.1.0-alpha.20`. Те же строки статуса в
|
||||
одиннадцати переводах `docs/i18n/README.*.md` рассинхронизированы между
|
||||
собой и с корневым README.
|
||||
|
||||
Привести строку статуса релиза к `v0.1.0-alpha.20` в корневом README и во
|
||||
всех переводах.
|
||||
|
||||
Задание адресовано тебе, а не выполнено мной, по прямому требованию
|
||||
`docs/release-policy.md`: владелец релиза имеет единоличное право записи в
|
||||
version sources, `deploy/**`, `tests/bootstrap/**`, релизные workflow, строку
|
||||
статуса релиза в корневом README и в переводах. Остальные просят об
|
||||
изменении в отчёте и не правят эти пути сами.
|
||||
|
||||
Это же закрывает пункт этапа 6 в `docs/roadmap.md`: «синхронизировать все
|
||||
переводы README с текущим release status». Отметить его выполненным —
|
||||
часть задания.
|
||||
|
||||
## Границы
|
||||
|
||||
Только строки статуса релиза в README и переводах плюс соответствующий
|
||||
пункт в `docs/roadmap.md`. Не переписывать остальной текст переводов, не
|
||||
трогать `CHANGELOG.md` и `docs/release-policy.md` — они уже приведены в
|
||||
соответствие отдельной работой. Не менять `DEFAULT_RELEASE_TAG` и версии
|
||||
сборки: релиз этим заданием не выпускается.
|
||||
|
||||
## Как проверить результат
|
||||
|
||||
- `grep -rn "alpha\." README.md docs/i18n/` — ни одной ссылки на версию
|
||||
ниже `v0.1.0-alpha.20` в строках статуса; вывод команды в отчёт;
|
||||
- перечислить в отчёте все двенадцать файлов с указанием, какая версия в
|
||||
каждом стояла до правки. Если где-то стояла не `alpha.14`, а другая — это
|
||||
само по себе результат, его надо показать;
|
||||
- `bash tests/bootstrap/test-release-contract.sh` — зелёный, если он
|
||||
затрагивает README;
|
||||
- прогоны CI на PR — ссылками.
|
||||
|
||||
## Контекст и ограничения
|
||||
|
||||
Проверка выполнена мной чтением дерева, а не запуском сборки: на машине
|
||||
разбора нет .NET SDK. Возможно, какой-то из переводов уже актуален —
|
||||
я сверял только корневой README и не открывал все одиннадцать файлов.
|
||||
|
|
@ -21,5 +21,6 @@ Known release history:
|
|||
- `v0.1.0-alpha.17` keeps checksum verification fail-closed while suppressing its success line, so pass-through commands such as `node-code` return only their machine-readable bootstrap output. Its automatic verification completed the clean-host Hub and Node installation, then the negative-test harness stopped while creating a wrong-identity signature because cosign v3 requires an explicit bundle or legacy detached-output mode. The immutable release and failed harness run remain as evidence; the negative test is corrected in the next version.
|
||||
- `v0.1.0-alpha.18` makes the wrong-identity negative test select cosign v3's explicit detached-output mode, matching the production consumer's detached signature and certificate contract. It is the first release required to complete both automatic `workflow_run` verification and manual `workflow_dispatch` re-verification.
|
||||
- `v0.1.0-alpha.19` exists as a tag, but its Release pipeline failed when the packaged convenience installer's `DEFAULT_RELEASE_TAG` did not match the immutable tag. No GitHub Release was published. The version number is burned and must not be moved, deleted, recreated, or reused.
|
||||
- `v0.1.0-alpha.20` matches the packaged convenience installer's `DEFAULT_RELEASE_TAG` to the tag being produced, which is the defect that burned `v0.1.0-alpha.19`. It also adds a pipeline step that tests the latest published release before a new one is cut. It carries the content that `v0.1.0-alpha.19` failed to publish: the operator web console, the guided unified installer, the complete uninstall mode, the node enrollment endpoint, and the mesh state permission fix.
|
||||
|
||||
Every release candidate must pass a branch `workflow_dispatch` run of the Release pipeline before its immutable version tag is created. The release owner has sole write ownership of version sources, `deploy/**`, `tests/bootstrap/**`, release workflows, the root README release status, and translated README release statuses. Other contributors request changes to those paths in their report; they do not edit or bump them directly. One pull request covers one release topic and may merge only after required CI is green.
|
||||
|
|
|
|||
|
|
@ -46,6 +46,11 @@
|
|||
- [x] ограниченный offline buffer Agent и downsampling;
|
||||
- [x] idempotency и replay protection;
|
||||
- [x] SQLite schema version, retention и backup/restore Control DB + CA;
|
||||
- [x] веб-консоль оператора на Control: список узлов, состояние агентов и
|
||||
выпуск кода регистрации;
|
||||
- [x] отдача ассетов консоли из встроенных ресурсов сборки, когда каталога
|
||||
`wwwroot` нет на диске;
|
||||
- [x] вход по логину и паролю для тестовых стендов, отключённый по умолчанию;
|
||||
- [ ] добавить Desktop UI управления Automation identities и токенами.
|
||||
|
||||
## Этап 3 — управляемые Links
|
||||
|
|
@ -62,6 +67,12 @@
|
|||
- [x] B-2: независимая фоновая и emergency-triggered реконсиляция, агрегированное состояние недоступного Mesh firewall и Desktop banner;
|
||||
- [x] B-3: факт-первичная реконсиляция использует один `link-list`, удаляет orphan/дубликаты (включая `Disabled/Disabled`), разводит `Examined` / `Converged` / `Failed` (M2), ограничивает marker-prompt тремя попытками, добавляет фильтр истории и retention завершённых Links (M4), а также типизированное ожидание активации Mesh Node (M5). Physical acceptance остаётся внешним блокером;
|
||||
- [ ] выполнить физический acceptance Hub + source Node + два destination Node с WireGuard/nftables/reboot.
|
||||
- [x] управление Links из веб-консоли: создание с подтверждением направления,
|
||||
обязательной причиной и ключом идемпотентности;
|
||||
- [x] аварийное отключение Link из строки таблицы консоли;
|
||||
- [x] раздельное отображение желаемого и фактического состояния Link
|
||||
с признаком рассогласования и последней ошибкой;
|
||||
- [x] журнал событий Control в реальном времени в веб-консоли;
|
||||
|
||||
## Этап 4 — мониторинг и терминал
|
||||
|
||||
|
|
@ -101,6 +112,8 @@
|
|||
- [x] добавить криптографическую подпись compatibility manifest для production release;
|
||||
- [x] проверять Ubuntu 22.04/24.04 и Debian 12/13, `amd64`/`arm64`;
|
||||
- [x] добавить non-interactive install/update/rollback/uninstall;
|
||||
- [x] добавить режим полного удаления сервера;
|
||||
- [x] добавить пошаговый объединённый установщик;
|
||||
- [x] устанавливать Control/Agent, restricted helper и systemd units;
|
||||
- [x] локально создавать Agent key/CSR, выполнять mTLS enrollment и не сохранять token;
|
||||
- [x] добавить собственную установку WireGuard Hub/Node и выдачу внутренних адресов;
|
||||
|
|
|
|||
Loading…
Reference in a new issue