Files
Nomarchy/docs
Bernardo Magri a6f86cf575
All checks were successful
Check / eval (push) Successful in 4m9s
test(state): #133 — pin the #107 legacy-name shim (and its fail-closed gate)
mkFlake prefers state.json and still accepts the legacy theme-state.json,
because a machine only migrates on its next menu write. Nothing evaluated a
checkout carrying ONLY the legacy name, so the shim could rot with every
check green — breaking rebuilds for precisely the users who have not opened
the menu since #107, i.e. the ones least likely to see it coming.

checks.state-legacy-name evaluates two fixtures: legacy-only must resolve,
and no-state-at-all must still throw. The gate is half the shim's contract
(it turns "no state file" into one readable error instead of a readFile
stack from inside the module system) and was equally unpinned.

Cheap by construction: mkFlake wraps its return in `builtins.seq
_themeState`, so forcing the attrset forces the state read and nothing else
— no module system, no home.nix. Hence a one-file fixture and no measurable
cost (flake check still ~35s). That file is a SYMLINK to the shipped
template's state.json: a copy would drift and the check would quietly start
testing a fossil. The fixture also asserts it has no state.json, or it would
pass while testing nothing.

Both assertions proven by breaking lib.nix — deleting the fallback, then
defeating the gate — and watching each fail by name. Delete this check
together with the shim and the nomarchy-theme-sync alias.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 14:04:16 +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 § ….