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.
Touch this finding and you re-check 1 requirements · 2 code files · 3 tests.
- Menu.qml
- MenuModel.js
- menumodel-replay.test.mjs
- report-reproducers.test.mjs
- menu-test.sh
Per-requirement evidence
For each requirement this finding touches: the implementing code, verifying tests, and proof obligations that discharge it.
Per-requirement evidence
For each requirement this finding touches: the implementing code, verifying tests, and proof obligations that discharge it.
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.