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

New Issue

2026-09-25T17:48:45Z

xavierk commented

2026-09-25 17:48:45 +00:00

Destination

Reach a research-backed, build-ready specification for Odin by Bongbetic: the exact benchmark and diagnostic suite, architecture, Linux support contract, median scoring method, optimization rubric, local results model, TUI behavior, and acceptance criteria. Resolve design choices before implementation begins.

Notes

This is a planning effort. Research may recommend options; final product and architecture choices remain in decision tickets. Do not begin the production build from this map.
Consult wayfinder, grilling, and domain-modeling; use research for research tickets and prototype for the interaction ticket. Read AGENTS.md, CONTEXT.md, and docs/agents/*.md. Technical documentation lookups use Context7 followed by exact primary sources when needed.
Fixed requirements: terminal operation; Bongbetic branding; decorative, themeable InkUI components from https://github.com/kamlesh723/inkui; colorful graphs and data points; keyboard and mouse navigation; Bash usability.
Requested coverage: memory pressure and memory errors; CPU performance and bottlenecks; GPU performance and usable/correct drivers; NVMe/HDD read/write speed and health; overall system health; browser responsiveness in the spirit of BrowserBench and Speedometer 3; shell performance; representative popular languages including Python, Rust, C++, and Java.
User-confirmed initial platform targets: modern x86_64 and aarch64, glibc and musl, Void/xbps plus deb and rpm distribution families. Detect capabilities and explain unavailable tests. Exact distro versions, kernel/runtime floors, and certification cells await research; support is not a promise that every test can run on every system.
User-confirmed execution profiles: standard target 10–20 minutes, with quick and explicitly selected extended profiles. Both headed and headless browser modes are allowed, with terminal controls/results and clearly distinguished measurements.
The user clarified that the requested headline is a median score. Research must address normalization, the population whose median is taken, missing coverage, repeated trials, calibration, and comparability; do not silently replace this requirement with a different aggregate.
Development occurs on Void Linux; validation must cover different Linux VMs and identify where physical hardware evidence is required. Kernel configuration and optimizations are part of the measurement environment. Favor a current maintained stack with reproducible versions; determine minimum requirements from evidence.
Store results locally. Optimization and drive replacement advice must be tied to observed evidence and communicate uncertainty. The relation between health findings, workload performance, and the headline score is a decision to settle.
Browse the planning tickets for the live work queue; filter open issues by map membership and native blockers to find the frontier.
Use native Gitea dependencies. Children contain the map membership marker; open tickets are queried, not copied into this index. Claim a research ticket as xavierk before work. Evidence goes on a separate research/<topic> branch and is linked from its resolution.

Decisions so far

Establish storage measurements and trustworthy health advice: Bounded file workloads and protocol-specific health evidence are viable candidates; write budgets, unsafe transports, parser versions, and uncertainty need explicit policies.
Establish InkUI architecture and Linux delivery options: InkUI can supply the visual components, but mouse/fallback behavior and runtime/libc delivery require explicit qualification; Node and Bun remain conditional options.
Establish safe CPU, memory, and kernel measurements: Throughput, loaded responsiveness, pressure, and memory-error evidence are distinct; established tools are candidates, but containment, coverage, and repeatability require qualification.
Establish GPU driver evidence and performance workloads: GPU discovery, execution, correctness, and presentation prove different things; headless compute and rendering candidates have distinct API, driver, and portability limits.
Establish browser, shell, and language workload validity: Browser, shell, startup, compilation, and warmed-language workloads need distinct identities; native browser automation can complement supported Playwright cohorts without hiding capability gaps.
Establish defensible median scoring and comparison rules: A median requires fixed normalization and domain membership; reference changes and missing tests can change rankings, so calibration, coverage, and comparison identities must be versioned.
Choose Odin’s workload suite and run profiles: Standard workload coverage and run profiles set; its Speedometer browser choice is superseded by the new browser workload decision.
Define Odin’s median score and comparability contract: Seven fixed domain medians and full-coverage rule stand; the new browser workload replaces the Speedometer-specific statistic and reference.
Define health findings and the optimization advice rubric: Severity and confidence are separate; advice requires scoped evidence, qualified alarms govern safety stops, and unknown telemetry never certifies health.
Define local results, history, and export behavior: Full local evidence, provenance, and partial outcomes remain auditable; history persists until deletion, with atomic recovery, compatible comparisons, and private-by-default portable export/import.
Define Odin’s calibration procedure and release gates: Physical reference, mode-specific corpora, stability, sensitivity, and release gates stand; the new browser workload needs fresh calibration.
Audit Speedometer offline pack redistribution rights: The pinned full archive lacks third-party redistribution clearance; packaging choice now depends on rights remediation or workload replacement.
Verify the offline Speedometer pack and its redistribution terms: The unchanged full pack lacks redistribution clearance and proven offline closure; grants or cleared replacements, a final manifest, and unscored offline validation precede packaging.
Choose Odin’s runtime and Linux compatibility contract: Node 24, React 19, and Ink 6 with pinned InkUI; native packages use distro or bundled Node 24, explicit offline preparation, separate supervised runner, and certified support cells.
Evaluate the Bongbetic TUI workflow with InkUI: Human chose to keep all three layouts, with Mission Control as default.
Choose a legally distributable v1 browser workload: Odin-owned offline interaction workload replaces the uncleared Speedometer pack; exact protocol and new calibration remain to specify.
Specify Odin’s v1 browser interaction workload: Grid, board, and editor actions define a 240-sample p95 browser metric; the five-minute stage, offline pack, calibration, and validity gates are fixed.
Set distro, VM, and physical-hardware validation gates: Eight physical/VM cells, scoped score claims, six-run repeatability, and 5% TUI-overhead gates; two validation rigs remain access prerequisites.
Reconcile browser editor fixture and scripted action: One-based editor lines retain the fixture; corrected eight actions have pinned expected states and digests, with a new pack identity and calibration gate.
Clarify headed validation for glibc certification cells: All six glibc cells require physical and VM headed UI checks; UI failure blocks v1 release, while headed browser scores require separate qualification.
Resolve Odin v1 Extended browser workload scope: v1 Extended repeats the Odin-owned browser suite three times; JetStream and MotionMark are deferred.
Approve Odin’s build-ready specification: Product owner approved the coherent decision set and implementation handoff; release evidence remains gated.

Not yet specified

None.

Out of scope

Implementing or releasing the production benchmark during this planning effort.
Running stress tests, installing drivers, changing kernel settings, or modifying the development host as part of charting.
A hosted leaderboard, mandatory uploads, or cloud accounts: the requested result history is local.
Destructive raw-device write tests and automatic system tuning as default behavior; the requested product provides benchmarking, diagnostics, and advice.
JetStream 3.0 and MotionMark 1.3.2 as v1 Extended modules: Resolve Odin v1 Extended browser workload scope defers them to a later effort.

## Destination Reach a research-backed, build-ready specification for **Odin by Bongbetic**: the exact benchmark and diagnostic suite, architecture, Linux support contract, median scoring method, optimization rubric, local results model, TUI behavior, and acceptance criteria. Resolve design choices before implementation begins. ## Notes - This is a planning effort. Research may recommend options; final product and architecture choices remain in decision tickets. Do not begin the production build from this map. - Consult `wayfinder`, `grilling`, and `domain-modeling`; use `research` for research tickets and `prototype` for the interaction ticket. Read `AGENTS.md`, `CONTEXT.md`, and `docs/agents/*.md`. Technical documentation lookups use Context7 followed by exact primary sources when needed. - Fixed requirements: terminal operation; Bongbetic branding; decorative, themeable InkUI components from https://github.com/kamlesh723/inkui; colorful graphs and data points; keyboard and mouse navigation; Bash usability. - Requested coverage: memory pressure and memory errors; CPU performance and bottlenecks; GPU performance and usable/correct drivers; NVMe/HDD read/write speed and health; overall system health; browser responsiveness in the spirit of BrowserBench and Speedometer 3; shell performance; representative popular languages including Python, Rust, C++, and Java. - User-confirmed initial platform targets: modern x86_64 and aarch64, glibc and musl, Void/xbps plus deb and rpm distribution families. Detect capabilities and explain unavailable tests. Exact distro versions, kernel/runtime floors, and certification cells await research; support is not a promise that every test can run on every system. - User-confirmed execution profiles: standard target 10–20 minutes, with quick and explicitly selected extended profiles. Both headed and headless browser modes are allowed, with terminal controls/results and clearly distinguished measurements. - The user clarified that the requested headline is a **median score**. Research must address normalization, the population whose median is taken, missing coverage, repeated trials, calibration, and comparability; do not silently replace this requirement with a different aggregate. - Development occurs on Void Linux; validation must cover different Linux VMs and identify where physical hardware evidence is required. Kernel configuration and optimizations are part of the measurement environment. Favor a current maintained stack with reproducible versions; determine minimum requirements from evidence. - Store results locally. Optimization and drive replacement advice must be tied to observed evidence and communicate uncertainty. The relation between health findings, workload performance, and the headline score is a decision to settle. - Browse [the planning tickets](https://git.bongbetic.com/xavierk/odin/issues) for the live work queue; filter open issues by map membership and native blockers to find the frontier. - Use native Gitea dependencies. Children contain the map membership marker; open tickets are queried, not copied into this index. Claim a research ticket as `xavierk` before work. Evidence goes on a separate `research/<topic>` branch and is linked from its resolution. ## Decisions so far  - [Establish storage measurements and trustworthy health advice](https://git.bongbetic.com/xavierk/odin/issues/4): Bounded file workloads and protocol-specific health evidence are viable candidates; write budgets, unsafe transports, parser versions, and uncertainty need explicit policies. - [Establish InkUI architecture and Linux delivery options](https://git.bongbetic.com/xavierk/odin/issues/6): InkUI can supply the visual components, but mouse/fallback behavior and runtime/libc delivery require explicit qualification; Node and Bun remain conditional options. - [Establish safe CPU, memory, and kernel measurements](https://git.bongbetic.com/xavierk/odin/issues/2): Throughput, loaded responsiveness, pressure, and memory-error evidence are distinct; established tools are candidates, but containment, coverage, and repeatability require qualification. - [Establish GPU driver evidence and performance workloads](https://git.bongbetic.com/xavierk/odin/issues/3): GPU discovery, execution, correctness, and presentation prove different things; headless compute and rendering candidates have distinct API, driver, and portability limits. - [Establish browser, shell, and language workload validity](https://git.bongbetic.com/xavierk/odin/issues/5): Browser, shell, startup, compilation, and warmed-language workloads need distinct identities; native browser automation can complement supported Playwright cohorts without hiding capability gaps. - [Establish defensible median scoring and comparison rules](https://git.bongbetic.com/xavierk/odin/issues/7): A median requires fixed normalization and domain membership; reference changes and missing tests can change rankings, so calibration, coverage, and comparison identities must be versioned. - [Choose Odin’s workload suite and run profiles](https://git.bongbetic.com/xavierk/odin/issues/8): Standard workload coverage and run profiles set; its Speedometer browser choice is superseded by the new browser workload decision. - [Define Odin’s median score and comparability contract](https://git.bongbetic.com/xavierk/odin/issues/10): Seven fixed domain medians and full-coverage rule stand; the new browser workload replaces the Speedometer-specific statistic and reference. - [Define health findings and the optimization advice rubric](https://git.bongbetic.com/xavierk/odin/issues/11#issuecomment-6740): Severity and confidence are separate; advice requires scoped evidence, qualified alarms govern safety stops, and unknown telemetry never certifies health. - [Define local results, history, and export behavior](https://git.bongbetic.com/xavierk/odin/issues/12#issuecomment-6750): Full local evidence, provenance, and partial outcomes remain auditable; history persists until deletion, with atomic recovery, compatible comparisons, and private-by-default portable export/import. - [Define Odin’s calibration procedure and release gates](https://git.bongbetic.com/xavierk/odin/issues/17#issuecomment-6776): Physical reference, mode-specific corpora, stability, sensitivity, and release gates stand; the new browser workload needs fresh calibration. - [Audit Speedometer offline pack redistribution rights](https://git.bongbetic.com/xavierk/odin/issues/18#issuecomment-6782): The pinned full archive lacks third-party redistribution clearance; packaging choice now depends on rights remediation or workload replacement. - [Verify the offline Speedometer pack and its redistribution terms](https://git.bongbetic.com/xavierk/odin/issues/16#issuecomment-6796): The unchanged full pack lacks redistribution clearance and proven offline closure; grants or cleared replacements, a final manifest, and unscored offline validation precede packaging. - [Choose Odin’s runtime and Linux compatibility contract](https://git.bongbetic.com/xavierk/odin/issues/9#issuecomment-6845): Node 24, React 19, and Ink 6 with pinned InkUI; native packages use distro or bundled Node 24, explicit offline preparation, separate supervised runner, and certified support cells. - [Evaluate the Bongbetic TUI workflow with InkUI](https://git.bongbetic.com/xavierk/odin/issues/13#issuecomment-6895): Human chose to keep all three layouts, with Mission Control as default. - [Choose a legally distributable v1 browser workload](https://git.bongbetic.com/xavierk/odin/issues/19#issuecomment-6899): Odin-owned offline interaction workload replaces the uncleared Speedometer pack; exact protocol and new calibration remain to specify. - [Specify Odin’s v1 browser interaction workload](https://git.bongbetic.com/xavierk/odin/issues/20#issuecomment-6927): Grid, board, and editor actions define a 240-sample p95 browser metric; the five-minute stage, offline pack, calibration, and validity gates are fixed. - [Set distro, VM, and physical-hardware validation gates](https://git.bongbetic.com/xavierk/odin/issues/14#issuecomment-6939): Eight physical/VM cells, scoped score claims, six-run repeatability, and 5% TUI-overhead gates; two validation rigs remain access prerequisites. - [Reconcile browser editor fixture and scripted action](https://git.bongbetic.com/xavierk/odin/issues/23#issuecomment-6960): One-based editor lines retain the fixture; corrected eight actions have pinned expected states and digests, with a new pack identity and calibration gate. - [Clarify headed validation for glibc certification cells](https://git.bongbetic.com/xavierk/odin/issues/24#issuecomment-6965): All six glibc cells require physical and VM headed UI checks; UI failure blocks v1 release, while headed browser scores require separate qualification. - [Resolve Odin v1 Extended browser workload scope](https://git.bongbetic.com/xavierk/odin/issues/25#issuecomment-6981): v1 Extended repeats the Odin-owned browser suite three times; JetStream and MotionMark are deferred. - [Approve Odin’s build-ready specification](https://git.bongbetic.com/xavierk/odin/issues/15#issuecomment-6999): Product owner approved the coherent decision set and implementation handoff; release evidence remains gated. ## Not yet specified None. ## Out of scope - Implementing or releasing the production benchmark during this planning effort. - Running stress tests, installing drivers, changing kernel settings, or modifying the development host as part of charting. - A hosted leaderboard, mandatory uploads, or cloud accounts: the requested result history is local. - Destructive raw-device write tests and automatic system tuning as default behavior; the requested product provides benchmarking, diagnostics, and advice. - JetStream 3.0 and MotionMark 1.3.2 as v1 Extended modules: [Resolve Odin v1 Extended browser workload scope](https://git.bongbetic.com/xavierk/odin/issues/25#issuecomment-6981) defers them to a later effort.

xavierk added the wayfinder:map label 2026-09-25 17:48:45 +00:00