Files
Nomarchy/docs
Bernardo Magri c32b51897e
All checks were successful
Check / eval (push) Successful in 3m44s
fix(theme): #130 the chip moves, not the label; #129 pins the pair so it is checkable
Light-theme accent buttons sat at 2.72:1 — under AA and under even the 3:1
large-text floor. Bernardo: fix it. The plan on file ("darken the label")
turned out to be IMPOSSIBLE, and measuring all 24 palettes is what showed
it: on a saturated mid-tone accent nothing clears 4.5 — cream base 2.72,
dark text 1.65. That is why adw-gtk3 ships white-on-accent at ~2.7. The
chip has to move.

The chip is now the accent pulled AWAY from the label: toward white when
the label is dark, toward black when it is cream. One factor (0.70), only
the anchor flips, so "solid accent button + base label" stays the design
and just shifts tone. Worst dark 4.86 (nord/bad), worst light 5.59
(summer-day). The old 0.90 chip failed SEVEN themes (miasma/bad 3.43,
rose-pine 2.70) — never only a light-theme bug, contrary to the item.

#129 rides along, and the two are one idea. #98 shipped an invisible button
with every check green because the background was not a palette role —
adw-gtk3 computed it from currentColor. So the guard is not a CSS lint
(which would flag the harmless generic-button rule and get muted) but
arithmetic: pin both ends and the pair becomes checkable.
check-theme-contrast.py now models GTK's own mix(a,b,f) = a + (b-a)*f —
READ from gtkcsscolorvalue.c:234, not assumed — and asserts base-on-chip
>= 4.5 for all 24 themes. Its negative test reproduces the item's reported
2.72/2.74 exactly from an independent model, which is the best evidence
available that the arithmetic matches the pixels.

Invariant to keep: pin the pair, or pin neither. Both chips are pinned now
(suggested + .default + destructive), where #98 pinned only destructive.

tools/dialog-shot.nix deliberately not built: the checker covers the
numbers, and a VM that only ever confirms arithmetic is maintenance for
nothing. Render if a new widget class appears.

Also sweeps #127 with the latch finding (ff5017e): symptom 2 solved, not
DPMS — which raises the odds the mitigation treats the wrong cause.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 14:55:17 +01:00
..

Docs map

Where human and agent documentation lives. Do not invent a third tree for the same facts.

Path Audience Role
../README.md Everyone What Nomarchy is, install, options tables
REQUIREMENTS.md Users + agents Minimum system requirements (GPU/OpenGL, RAM, disk, UEFI)
VISION.md Maintainers + agents Product north star toward v1.0 and beyond — themes, not a task queue
ROADMAP.md Maintainers + agents Design/decision records + shipped log (historical ✓)
HARDWARE.md Users + agents Firmware, profiles, drivers, unsupported machines
TESTING.md Maintainers + agents Verification ladder, honesty rule, ISO/VM recipes
RECOVERY.md Users Broken theme/desktop/boot → undo
OVERRIDES.md Users Downstream Nix overrides
MIGRATION.md Users Existing NixOS → Nomarchy without reinstall
OMARCHY.md Users Coming from Omarchy — bindings/theme/install/config map
Path Role
../AGENTS.md Agent entry point, any vendor/harness (CLAUDE.md symlinks to it)
../agent/README.md Agent instructions + executable loop state: BACKLOG, LOOP, VERIFICATION, …
../.claude/ Claude Code adapter only: permissions + subagent defs

How work flows

VISION  (what we want the product to feel like)
   │
   ▼  human triages slices into…
BACKLOG (what's next, ordered — agents execute only this)
   │
   ▼  lasting design notes after ship →
ROADMAP ✓ entries

Agents do not implement directly from VISION or ROADMAP. They take the top actionable item in agent/BACKLOG.md (see agent/LOOP.md). They may append PROPOSED pitches that reference VISION § … or ROADMAP § ….