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.
Migration package prerequisites are not validated against the target channel before promotion
Reported by SorenHJohansen · filed Oct 1, 2026 · open at source · 4 revisions
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?
- AreaOutside the audited area· Decided by agents · verified
- 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?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
Summary
The quattro branch migration set cannot be promoted to the stable channel until the package prerequisites those migrations require are published in the target channel. Two migrations currently reference packages the stable Omarchy repository does not serve:
migrations/1788996284.sh("Repair remote Neovim clipboard yanks and paste") refuses to run unlessomarchy-nvim >= 2026.9.21-2is installed. The current stable repository publishesomarchy-nvim 2026.8.13-1—pacman -Sy omarchy-nvimreinstalls the same version because nothing newer exists there.migrations/1790539857.sh("Install Monologue, the webcam recorder") installs the packagemonologue, which is not currently published in the stable Omarchy package repository at all (error: target not found: monologue).
Why this is a release gate, not an emergency
Migrations are strictly ordered and the runner stops on failure. omarchy-migrate executes each pending migration in filename order under bash -euo pipefail, and the runner itself is set -euo pipefail, with no skip/continue path. Reproduced in a VM against a real stable install (published omarchy 4.0.4-1, all 106 of its migrations applied) upgraded by the current branch tree (135 migrations):
- the runner applies the runnable prefix of the 29-migration delta, then aborts at
1788996284; 1788996284and every migration after it (16 total, including1790539857) stay pending;- every subsequent
omarchy-migrate— next login, next update — retries the same failing migration and aborts again.
So promoting either migration before its prerequisite is available leaves that migration pending and prevents later migrations from running until the package becomes available.
Scope
The current v4.0.4 stable release is unaffected: neither migration is included in it (the v4.0.4 package ships 106 migrations, newest dated 2026-09-15; both of these are newer branch migrations). This should be treated as a release-blocking P2 for the next release, not a current stable outage.
Suggested resolutions
- Publish
omarchy-nvim >= 2026.9.21-2and themonologuepackage on the stable channel before promoting the current migration set, or hold those migrations back until their prerequisites exist there. - Optionally, consider whether the runner should skip-and-continue a failing migration rather than aborting the entire run; with the current design one unsatisfiable guard wedges everything after it. The guard in
1788996284.shitself is good (it preserves customized/symlink-managed files and refuses rather than corrupting) — the gap is the coordination between the migration set and the served packages.
Reproduced against HEAD 938662d9 (quattro), Tier-3 VM, bash .opencode/experiments/ex018-cross-version-migration-boundary.sh (EX-018).
View raw text
## Summary
The quattro branch migration set cannot be promoted to the stable channel until the package prerequisites those migrations require are published in the target channel. Two migrations currently reference packages the stable Omarchy repository does not serve:
- `migrations/1788996284.sh` ("Repair remote Neovim clipboard yanks and paste") refuses to run unless `omarchy-nvim >= 2026.9.21-2` is installed. The current stable repository publishes `omarchy-nvim 2026.8.13-1` — `pacman -Sy omarchy-nvim` reinstalls the same version because nothing newer exists there.
- `migrations/1790539857.sh` ("Install Monologue, the webcam recorder") installs the package `monologue`, which is not currently published in the stable Omarchy package repository at all (`error: target not found: monologue`).
## Why this is a release gate, not an emergency
Migrations are strictly ordered and the runner stops on failure. `omarchy-migrate` executes each pending migration in filename order under `bash -euo pipefail`, and the runner itself is `set -euo pipefail`, with no skip/continue path. Reproduced in a VM against a real stable install (published `omarchy 4.0.4-1`, all 106 of its migrations applied) upgraded by the current branch tree (135 migrations):
- the runner applies the runnable prefix of the 29-migration delta, then aborts at `1788996284`;
- `1788996284` and every migration after it (16 total, including `1790539857`) stay pending;
- every subsequent `omarchy-migrate` — next login, next update — retries the same failing migration and aborts again.
So promoting either migration before its prerequisite is available leaves that migration pending and prevents later migrations from running until the package becomes available.
## Scope
The current `v4.0.4` stable release is unaffected: neither migration is included in it (the v4.0.4 package ships 106 migrations, newest dated 2026-09-15; both of these are newer branch migrations). This should be treated as a **release-blocking P2 for the next release**, not a current stable outage.
## Suggested resolutions
- Publish `omarchy-nvim >= 2026.9.21-2` and the `monologue` package on the stable channel before promoting the current migration set, or hold those migrations back until their prerequisites exist there.
- Optionally, consider whether the runner should skip-and-continue a failing migration rather than aborting the entire run; with the current design one unsatisfiable guard wedges everything after it. The guard in `1788996284.sh` itself is good (it preserves customized/symlink-managed files and refuses rather than corrupting) — the gap is the coordination between the migration set and the served packages.
Reproduced against HEAD `938662d9` (quattro), Tier-3 VM, `bash .opencode/experiments/ex018-cross-version-migration-boundary.sh` (EX-018).
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
Not linked to any known issue, other report or change yet.
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.
- Out of scopeDecided by agents · verified · 2026-10-09 20:31 UTC