Set the evidence-based VoidKontrol v1 release and handoff criteria #9
Notifications
Due Date
No due date set.
Depends on
#6 Choose the VoidKontrol service, UI, and desktop integration architecture
xavierk/voidkontrol
#7 Define verified capabilities, configuration ownership, and recovery guarantees
xavierk/voidkontrol
#8 Validate the Carbon keyboard-customization and recovery workflows
xavierk/voidkontrol
Reference: xavierk/voidkontrol#9
Reference in New Issue
Block a user
Question
With architecture, device contract and interaction decisions available, what precise acceptance matrix makes VoidKontrol v1 ready to build and eventually ship? Cover the user-confirmed USB-only starting presentation, each supported control and boundary value, readback and persistence after reconnect/power-cycle, interrupted writes and restore, preservation of normal typing/media, privilege isolation, accessibility, niri/Noctalia behavior, clean Void installation and removal, upgrade/migration, offline operation, and explicitly unsupported targets. Distinguish decisions complete from tests actually passed. Confirm the implementation-ready destination with the user and identify any remaining fog before handoff.
Parent map: Find the way to VoidKontrol v1: complete verified Swarm75 control on Void Linux