igneum/app
2026-10-07 18:34:47 +00:00
..
igneum-app The miner's chain key from the shared legend export (key-22, 7 October 2026): IgneumDag.legend({mine}) and renderLegend(el, {mine}) in scene/live-dag.js (2.0.5) carry the one list of entries with each state's token and shape (Pending, Included, Excluded, Selected chain, Proven, Locked checkpoint; the app adds Your blocks, ringed, first); the app's chain card renders its key from it at mount with the source line kept (the Included swatch had been ember while the scene draws included blocks in --included, and "pending" was lower-case), its CSS colours a swatch only from the entry's token; the copies synced; tools/scene/legend.test.mjs on the gate's scene line: the export's entries, order, tokens and shapes, every colour the scene draws has an entry, the app key is the export, and the /live key equals the export minus the ruled exceptions (no Pending, no Your blocks) with the same wording, token and shape on every shared entry, binding on master where the site deploys from and a diagnostic on a release branch whose site tree is the frozen cut; the site is not edited (main's correction: the project lead's ask was the miner's key) 2026-10-07 18:02:56 +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 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