Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Configurable automatic nightlight schedule
Reported by heymaikol · filed May 21, 2026Closed upstream on 2026-07-18. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Problem
Omarchy ships hyprsunset for the manual nightlight toggle (SUPER+CTRL+N, omarchy toggle nightlight), but the automatic time-based behaviour hyprsunset supports natively is opt-in only through manual config editing.
Today, turning the screen warm at sundown and back to identity in the morning requires the user to:
- Add
exec-once = uwsm-app -- hyprsunsetto~/.config/hypr/autostart.lua(or.confpre-migration) - Append a second
profile { time = ...; temperature = ... }block to~/.config/hypr/hyprsunset.conf
The current default config/hypr/hyprsunset.conf documents this in comments (added in #2446 and #3082), but there's no one-step or interactive way to enable, change, or disable it. Discoverability is poor and the schedule resets on a refresh.
Proposed UX
A managed, opt-in schedule with persistent settings:
- Off by default (no behaviour change for users who don't opt in)
- A single discoverable entry under Trigger → Toggle that opens a UI showing current status, intensity (K), start time, and end time
- The UI lets the user enable/disable the schedule and change each value
- Settings persist across reboots/refreshes and survive
omarchy refresh hyprsunsetcleanly (managed state stored outside the config file)
View raw text
## Problem
Omarchy ships hyprsunset for the manual nightlight toggle (`SUPER+CTRL+N`, `omarchy toggle nightlight`), but the *automatic* time-based behaviour hyprsunset supports natively is opt-in only through manual config editing.
Today, turning the screen warm at sundown and back to identity in the morning requires the user to:
1. Add `exec-once = uwsm-app -- hyprsunset` to `~/.config/hypr/autostart.lua` (or `.conf` pre-migration)
2. Append a second `profile { time = ...; temperature = ... }` block to `~/.config/hypr/hyprsunset.conf`
The current default `config/hypr/hyprsunset.conf` documents this in comments (added in #2446 and #3082), but there's no one-step or interactive way to enable, change, or disable it. Discoverability is poor and the schedule resets on a refresh.
## Proposed UX
A managed, opt-in schedule with persistent settings:
- Off by default (no behaviour change for users who don't opt in)
- A single discoverable entry under Trigger → Toggle that opens a UI showing current status, intensity (K), start time, and end time
- The UI lets the user enable/disable the schedule and change each value
- Settings persist across reboots/refreshes and survive `omarchy refresh hyprsunset` cleanly (managed state stored outside the config file)Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
- Related PRpr/9554· confirmed
- Related PRpr/12571· confirmed
- Related PRpr/14347· confirmed
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.