igneum-labs b1d2cdbf5e 0.3.25 AMD knob: a tune line with no ranges is "not available (no tuning interface)", from PC 1's read-back of igneum-gpu-telemetry 1d8e055d (8 October 2026, 09:07Z): the integrated Radeon answers gmax - gmax_range - - plimit - plimit_range - - factory 0 ok, every field a dash (-1 after the parser), which amd_knob read as an offset knob with a one-MHz ladder and a 99 percent power range (known-failed first). The RX 9070 XT's line (gmax 0 gmax_range -500 1000 plimit 0 plimit_range -30 10 factory 1 ok) and its sample (gclk_mhz 3292 under load, plimit_pct 100, gmax_mhz 0) are the test's second half: the knob reads stock 3,292 MHz, the ladder 3192 down to 2792, the power range 70 to 110 percent, the apply sending offsets. Tests: ember::tests::the_amd_knob_reports_not_available_with_its_reason_and_sets_nothing (the integrated line added), engine::tests::pc1s_two_tune_lines_give_one_refusal_and_one_knob ... Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>		2026-10-08 09:13:22 +00:00
..
igneum-app	0.3.25 AMD knob: a tune line with no ranges is "not available (no tuning interface)", from PC 1's read-back of igneum-gpu-telemetry 1d8e055d (8 October 2026, 09:07Z): the integrated Radeon answers gmax - gmax_range - - plimit - plimit_range - - factory 0 ok, every field a dash (-1 after the parser), which amd_knob read as an offset knob with a one-MHz ladder and a 99 percent power range (known-failed first). The RX 9070 XT's line (gmax 0 gmax_range -500 1000 plimit 0 plimit_range -30 10 factory 1 ok) and its sample (gclk_mhz 3292 under load, plimit_pct 100, gmax_mhz 0) are the test's second half: the knob reads stock 3,292 MHz, the ladder 3192 down to 2792, the power range 70 to 110 percent, the apply sending offsets. Tests: ember::tests::the_amd_knob_reports_not_available_with_its_reason_and_sets_nothing (the integrated line added), engine::tests::pc1s_two_tune_lines_give_one_refusal_and_one_knob	2026-10-08 09:13:22 +00:00
mac	The opening window size, one rule for both hosts (window-22, 7 October 2026, the project lead on PC 2: "why did the app open super wide?"): scaling-21's 80 percent of the work area scaled above 1920 wide opened 2752 by 1152 on a 3440-wide area and 3072 by 864 on a two-monitor span, and a remembered WindowW/WindowH could carry that into later starts; now app/windows/opening_size.h: the PRIMARY monitor's work area (MonitorFromPoint primary, never the virtual desktop), width 80 percent capped at 1440 up to a 1920-wide display and 1920 beyond, height from the width at 16:10 bounded by the work area, never wider than 1.6 times the height, never under 900 by 600, never over the work area; a remembered frame kept only when it fits the work area, the minimum and the aspect cap, and never saved when it would not; the Mac window mirrors the rule on NSScreen.screens.first and discards an autosave frame that fails it; opening_size_test.c compiles on the gate with cc (known-failed first: it could not compile before the header, and 0.3.21's rule fails the 3440 by 1440 and the 3840 by 1080 cases); host.cpp touched (the shipper's named line)	2026-10-07 18:34:47 +00:00
windows	0.3.24: version strings first (rule 15; the six places), the tree after 0.3.23's cut: class v5 by height on Devnet 3, the chain id at the v5 floor, the dashboard width caps, the pool daemon's reconnect and counters	2026-10-07 21:37:44 +00:00