Proof Portal

Project overview

Omarchy

ProbeLabsviewing a historical run

A 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.

Viewing historical run 20d4e6aOct 2, 2026, 05:32 PMquattro-proofBack to current
Back to findings
Known issueKI-MENU-MERGE-STALE-ORDER-ALIASED-ROWS

mergeAppRows/swapProviderRows keep stale .order values and mutate caller-owned rows in place

OpenOpenLow

Low-severity issue, currently open.

Description

The issue as recorded.

Both merges copy kept rows by reference without restamping .order. After any row leaves the set, the survivors' order values no longer match their itemOrder indexes (F11a/F12b) - searchScore's declaration-order tiebreak then compares stale numbers. Both merges also write row.order/providerMenu into the CALLER's row objects (F11b). That is exactly the in-place write the module header forbids ('an in-place write into such an object is occasionally dropped by the engine').

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).

LowRated severity — the impact if this issue is exploited or hit.
why this rating
Risk-rated
risk area
Correctness
Security classification
Not a security surface
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.

Known issue reproducedprofileknown_issue_reproducerprovesSW-REQ-260922-Z680
Reproducer test
Run it yourself
node pocs/menu-probes2.js ../shell/plugins/menu/MenuModel.js
Covers (2)
Last run Sep 30, 2026, 11:02 PM

Reproduction steps

Technical steps for your engineers to confirm the issue by hand.

node pocs/menu-probes2.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

The tiebreak only mis-sorts rows whose primary scores are equal; visible order otherwise follows declaration order

The fix

shallow-copy kept rows and restamp order for every survivor; never write into the row objects handed in

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.

Tracing blast radius…

Touch this finding and you re-check 1 requirements · 2 code files · 2 tests.

Requirements (1)
Code files (2)
  • Menu.qml
  • MenuModel.js
Tests (2)
  • menumodel-replay.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.

Implementing code (4)
  • shell/plugins/menu/Menu.qml
    mergeProviderRows
  • shell/plugins/menu/Menu.qml
    slugify
  • shell/plugins/menu/MenuModel.js
    mergeAppRows
  • shell/plugins/menu/MenuModel.js
    swapProviderRows
Tests & evidence (2)
  • test/node/menumodel-replay.test.mjs
  • test/shell.d/menu-test.sh
Proof obligations (1)
atomicity

Operation either fully completes or has no effect.

  • ✓negative (required) — test/shell.d/menu-test.sh:921
  • ✓nominal (required) — test/shell.d/menu-test.sh:911

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-merge-stale-order-aliased-rows.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.

Sign in to discuss this with the proof team.Sign in