Fenris/docs/spec/native-void-tickets.md

Native Void implementation tickets

Status: Approved and published as Gitea issues 83–87 with native blocking edges and ready-for-agent labels. Parent specification: #82.

Each issue references the published native Void specification, which includes ADR 0008. Existing Debian/RPM behavior, observation-history preservation, narrowly scoped privilege, and independent publication gates apply throughout.

Published tickets: 1, 2, 3, 4, 5.

1. Prove signed XBPS installation and immediate updates through Gitea

Blocked by: None.

Deliver a dedicated public Gitea distribution repository and a repeatable, isolated XBPS-client proof using clearly identified test artifacts, without representing them as a validated Fenris release.

• Verify permanent raw URL delivery of index, package and signature bytes without LFS indirection.
• Establish signing-key handling and trust verification without exposing private keys.
• Demonstrate install and update with a client that fetched the old index immediately before publication.
• Resolve actual cache behavior and verify binary size limits; escalate any hosting change outside the agreed Gitea scope.
• Publish index/artifacts together with serialized updates, preserve older downloadable artifacts, and demonstrate safe failure recovery.
• Record results and the usable publication mechanism for subsequent tickets.

2. Run and control Fenris monitoring natively under runit

Blocked by: None.

Deliver an end-to-end native monitoring path with existing CLI/TUI controls and truthful status in an isolated Void environment.

• Scheduled and on-demand collection use the same acquisition path with no overlap and bounded execution.
• Preserve cadence, initial boot delay, recovery after failures, and no catch-up semantics.
• Resume/pause preserve monitoring-period bookkeeping and boot/runtime distinctions; raw service stops do not record deliberate disable.
• Verify effective authentication and actionable native diagnostics, including missing-agent failures.
• Preserve systemd behavior and application feature parity through existing public behavior tests.

3. Install, upgrade and remove Fenris with native XBPS packages

Blocked by: 2.

Deliver buildable x86_64/glibc XBPS artifacts with dependency resolution and tested package lifecycle in an isolated Void environment.

• Fresh install remains dormant; native controls enable monitoring afterward.
• Package ownership, configuration preservation, permissions, and group access support real CLI/TUI reads and collector writes.
• Upgrade snapshots and migrates observation history safely without recording a deliberate pause.
• Removal performs sanctioned pause and retains history; reinstall and documented snapshot rollback behave correctly.
• Installation over incompatible unmanaged remnants fails with a useful migration path.
• Capture explicit lifecycle test results and verify Debian/RPM regressions relevant to changed packaging.

4. Publish validated package formats independently from the release workflow

Blocked by: 1, 3.

Deliver a release workflow that builds, validates, signs and publishes XBPS alongside existing Debian/RPM support with independent format gates.

• Unvalidated formats remain withheld while validated formats can ship.
• Notes accurately identify available and withheld formats; source version, notes, checksums and artifacts agree.
• A withheld format can be added after validation without replacing existing published artifacts.
• Gitea serves every download; XBPS uses the proven permanent repository URL and immediate-refresh behavior.
• Release failure/concurrency cannot expose an index referencing missing artifacts or erase the prior usable channel.
• Host acceptance remains a required XBPS release gate, not bypassed by build/signature success.

5. Validate and release on the user's Void machine

Blocked by: 4.

Deliver recorded host acceptance and the validated XBPS release, ending with Fenris installed and monitoring.

• Recheck host state, identify/configure the intended NVMe drive, and preserve pre-existing data before package lifecycle operations.
• Verify real acquisition, authenticated controls, scheduling, failure reporting, full dashboard behavior, and pause/resume semantics.
• Coordinate and verify reboot persistence; absence of the reboot test leaves that gate pending.
• Verify native upgrade/removal/reinstall with history preservation and immediate update discovery through Gitea.
• Publish only after the XBPS gate passes, then verify downloads and released-package installation.
• Preserve acceptance-test observation history and leave the released package monitoring; document installation, trust setup, diagnostics and rollback for Void users.