Bernardo Magri
30e632ff65
All checks were successful
Check / eval (push) Successful in 3m48s
Every rebuild while docked re-lit the panel and threw a workspace onto it. Not forgetfulness: a rebuild PERFORMS an undock. Dock mode lived only in the compositor (`keyword monitor <internal>, disable`, nothing written down), the config's only monitor line is the catch-all `monitor=,preferred,auto,1`, and rewriting the config makes Hyprland reload it — re-enabling every output. Our own undock path already uses `hyprctl reload` as exactly that hammer (hardware-proven 2026-07-14). The watcher could not rescue it: reconcile diffs `monitors all`, which lists disabled outputs, so the connected set is identical across the flip — structurally blind, the blind spot of rounds 4-5's "the output set is the truth". So the intent is recorded where every other setting lives — settings.display.dockMode, in-flake, menu-writable — written at the one choke point both menu and watcher pass through (transition: dock → true, undock → false, `enable` of an internal → false, because "Screen on" IS leaving dock mode and must not be undone a second later). The watcher re-asserts it as a tick invariant rather than an event reaction, which is what makes the reload case work; auto_dock was already idempotent, so it costs one `hyprctl monitors` per tick. The trap avoided: baking the disable into the config would survive a reload and hand a user with no external a zero-output session at login — the #100/#127 brick. The config cannot know what is plugged in, so it keeps defaulting to "everything on" and the re-assert is gated on an external being present. Verified: 9/9 gates unit-tested by driving the REAL generated function against stubs (incl. no-external → never re-dock, profile active → yield, already-docked → no churn), plus the state write/read round-trip on a throwaway checkout so the live flake was untouched. V3 queued — needs a relogin, the watcher is exec-once. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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 |
Related (not under docs/)
| 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 § ….