Proof Portal
Omarchy
ProbeLabsviewing a historical runA 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.
searchScore ranking anomalies: apps promoted in-tier, root exact-labels swamped, multi-term matches collapse
Low-severity issue, currently open.
Description
The issue as recorded.
Executed probes: an app and a menu row with equal scores rank app-FIRST (the -5 within-tier nudge). That violates the contract in the code comment 'App rows sort after all menu items' (F15d). An exact label at root scores base 2 while the identical exact label nested deeper scores base 0 (F15f). The root row therefore ranks below its nested twin, and the depth tie-break loses effect. A multi-term query that matchesQuery accepts across fields (one term on the label, one on the description) scores in the unmatched baseline band. That ranks it below a single-field pure match (F15e2 - measured 78000 for the accepted query).
Affected requirements
The requirement(s) this issue violates — click through to the spec.
Severity, explained
Why this is rated the way it is — and the scoring signals behind the rating (each ⓘ explains the term).
- why this rating
- Risk-rated
- risk area
- Correctness
- CVE surface
- None
How it's proven
The reproducer — an actual test that drives the real code and shows the issue happening. Run it yourself, or peek the test and the source it covers.
node pocs/menu-probes.js ../shell/plugins/menu/MenuModel.js
Reproduction steps
Technical steps for your engineers to confirm the issue by hand.
node pocs/menu-probes.js ../shell/plugins/menu/MenuModel.js
What protects you, and the fix
What limits your exposure today, and the planned remediation.
What protects you now
Ranking anomalies reorder results but never hide them; the wanted entry stays on the results list
The fix
give multi-term queries an aggregation across per-term scores; make the root/nested exact-label bands consistent; reconcile the app nudge with the documented ordering
Blast radius
If you touch this issue, what else may need re-checking — the requirements it affects and the code and tests that hang off them. Historical view: authored trace links only — automatically derived links aren't reconstructible for past runs.
No authoredcode links reach these requirements in this historical reconstruction. Automatically derived code links aren't reconstructible for past runs, so implementing code may have existed without an authored trace.
Evidence trail
The raw evidence manifests behind this finding — superseded by the resolved reproducer above, kept here for traceability.
Evidence trail
The raw evidence manifests behind this finding — superseded by the resolved reproducer above, kept here for traceability.
- pocs/menu-probes.js
- pocs/menu-probes2.js
- pocs/menu-probes3.js
- proof/evidence/ki-menu-search-score-ranking.yaml
Change history
Every recorded revision of this finding's source file — when it was added, edited, or re-classified, with the diff for each change.
Discussions
Discuss this with the proof team. Nothing changes in your audit automatically — you open a request and a staff member records any outcome inside the thread.