Bernardo Magri
7aae204014
Some checks failed
Check / eval (push) Failing after 2m45s
Bernardo promoted the PROPOSED item live: with fingerprint PAM on, sudo/login should accept whichever factor comes first instead of pam_fprintd's wait-for-the-reader-then-password. Stock PAM cannot express parallel factors (linux-pam#301), so this packages pam-fprint-grosshack v0.3.0 (pkgs/, pinned from GitLab — the field-standard fprintd fork), source-reviewed before packaging: every failure path (no reader, no prints, fprintd absent/hung, timeout, password typed) returns PAM_AUTHINFO_UNAVAIL and falls through; a typed password is only ferried via PAM_AUTHTOK to the stock `auth sufficient pam_unix.so … try_first_pass` rule — the module never validates passwords itself, so it cannot lock out password login. New option nomarchy.hardware.fingerprint.parallel, default TRUE (the better UX is what opting into fingerprint PAM buys; false = stock sequential). Wiring swaps the modulePath of stock fprintd's rule slot (mkForce) so the sufficient-before-pam_unix ordering is inherited, not recomputed. README + downstream template rows added. Verified: V2 — checks.hardware-toggles extended to three nodes, green: parallel node asserts the grosshack auth line precedes pam_unix in /etc/pam.d/sudo and that with NO reader a correct password still passes sudo while a wrong one fails (the lockout-safety invariant); seqpam node gets stock pam_fprintd and no grosshack; nopam gets neither. flake check + option-docs + template-sot green. V3 pending (HARDWARE-QUEUE, AMD dev box): the real type-or-touch race, fprintd-stopped fallback, hyprlock/greeter after a fingerprint win. Co-Authored-By: Claude Fable 5 <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 |
| 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 § ….