Clarify headed validation for glibc certification cells #24

New Issue

2026-09-28T04:20:02Z

xavierk commented

2026-09-28 04:20:02 +00:00

Part of Find the way to Odin’s build-ready specification.

Question

Which certified glibc cells require headed desktop and browser validation for Odin v1? Set distro, VM, and physical-hardware validation gates defines six glibc cells: Void, Debian 13, and Fedora 44 on both x86_64 and aarch64. The same resolution says to exercise headed desktop and browser behavior in "the four glibc cells", without naming them. Decide whether all six are required, or identify the exact four and the support claim for the remaining two. State how this affects physical/VM evidence, mouse and accessibility claims, headed browser score qualification, and the release gate. Keep musl desktop claims separately scoped as already specified.

This is a validation and support decision. Do not run certification in this ticket.

Part of [Find the way to Odin’s build-ready specification](https://git.bongbetic.com/xavierk/odin/issues/1).  ## Question Which certified glibc cells require headed desktop and browser validation for Odin v1? [Set distro, VM, and physical-hardware validation gates](https://git.bongbetic.com/xavierk/odin/issues/14#issuecomment-6939) defines six glibc cells: Void, Debian 13, and Fedora 44 on both x86_64 and aarch64. The same resolution says to exercise headed desktop and browser behavior in "the four glibc cells", without naming them. Decide whether all six are required, or identify the exact four and the support claim for the remaining two. State how this affects physical/VM evidence, mouse and accessibility claims, headed browser score qualification, and the release gate. Keep musl desktop claims separately scoped as already specified. This is a validation and support decision. Do not run certification in this ticket.

xavierk added the wayfinder:grilling label 2026-09-28 04:20:08 +00:00

xavierk added a new dependency 2026-09-28 04:20:13 +00:00

#15 Approve Odin’s build-ready specification

xavierk referenced this issue

2026-09-28 04:20:27 +00:00

Approve Odin’s build-ready specification #15

xavierk self-assigned this 2026-09-28 04:31:37 +00:00

xavierk commented

2026-09-28 04:38:04 +00:00

Resolution — headed validation for glibc cells

The product owner chose all six glibc certification cells and confirmed that a failure of required headed UI behavior in any cell blocks the eight-cell Odin v1 release. This clarifies the mistaken “four glibc cells” phrase in Set distro, VM, and physical-hardware validation gates; the six cells are Void glibc, Debian 13 glibc, and Fedora 44 glibc on each of x86_64 and aarch64.

Exercise headed desktop behavior in a reproducible VM and on physical hardware for each of the six cells. Record the exact cell, device, display, terminal, browser/driver, and capability probes. VM results establish guest compatibility only; physical evidence is required for bare-metal support. These tests extend the existing eight-cell physical/VM suite rather than replacing its minimal, headless, and SSH checks.
In every glibc cell, validate keyboard access, mouse parity where the terminal reports mouse input, focus and scroll behavior, resize, weak/no-color/ASCII behavior, screen-reader-friendly output, and headed browser operation with a compatible installed browser/driver. Keyboard and plain output must remain usable when mouse reporting is absent. Record absent mouse reporting as a terminal capability gap; do not claim universal mouse support.
Required headed UI behavior is part of the eight-cell release gate. If it fails in any glibc cell, fix and revalidate before the full Odin v1 release. Do not claim headed support for a cell based on VM evidence alone.
Headed browser operation does not by itself qualify a numerical score. Each physical OS/browser/mode score identity still needs its own correctness, repeatability, calibration, and approved-mode evidence under the existing gates. A browser workload or driver failure withholds that score and dependent headline, preserves raw evidence and a reasoned capability outcome, and follows the existing core-package rule: a score failure alone does not block the package when the required platform and UI functions pass. Do not infer score qualification for all six cells from the headed functional tests.
Void musl desktop support remains separately scoped. This decision does not add a musl headed claim.

This is a specification decision; no certification was run in this ticket.

## Resolution — headed validation for glibc cells The product owner chose all six glibc certification cells and confirmed that a failure of required headed UI behavior in any cell blocks the eight-cell Odin v1 release. This clarifies the mistaken “four glibc cells” phrase in [Set distro, VM, and physical-hardware validation gates](https://git.bongbetic.com/xavierk/odin/issues/14#issuecomment-6939); the six cells are Void glibc, Debian 13 glibc, and Fedora 44 glibc on each of x86_64 and aarch64. - Exercise headed desktop behavior in a reproducible VM and on physical hardware for each of the six cells. Record the exact cell, device, display, terminal, browser/driver, and capability probes. VM results establish guest compatibility only; physical evidence is required for bare-metal support. These tests extend the existing eight-cell physical/VM suite rather than replacing its minimal, headless, and SSH checks. - In every glibc cell, validate keyboard access, mouse parity where the terminal reports mouse input, focus and scroll behavior, resize, weak/no-color/ASCII behavior, screen-reader-friendly output, and headed browser operation with a compatible installed browser/driver. Keyboard and plain output must remain usable when mouse reporting is absent. Record absent mouse reporting as a terminal capability gap; do not claim universal mouse support. - Required headed UI behavior is part of the eight-cell release gate. If it fails in any glibc cell, fix and revalidate before the full Odin v1 release. Do not claim headed support for a cell based on VM evidence alone. - Headed browser operation does not by itself qualify a numerical score. Each physical OS/browser/mode score identity still needs its own correctness, repeatability, calibration, and approved-mode evidence under the existing gates. A browser workload or driver failure withholds that score and dependent headline, preserves raw evidence and a reasoned capability outcome, and follows the existing core-package rule: a score failure alone does not block the package when the required platform and UI functions pass. Do not infer score qualification for all six cells from the headed functional tests. - Void musl desktop support remains separately scoped. This decision does not add a musl headed claim. This is a specification decision; no certification was run in this ticket.

xavierk closed this issue

2026-09-28 04:38:07 +00:00

xavierk referenced this issue

2026-09-28 04:38:21 +00:00

Find the way to Odin’s build-ready specification #1

xavierk referenced this issue

2026-09-28 05:16:24 +00:00

Approve Odin’s build-ready specification #15

xavierk referenced this issue

2026-09-28 05:34:15 +00:00

Odin v1: terminal benchmark and health suite specification #26

xavierk referenced this issue