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?

AreaIn the audited areamenu· 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?

Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. So far: in the audited area (menu) — decided by agents · verified; matches no known issue — decided by agents · verified; not a duplicate of another report — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.

Original report

Right now, custom entries added via `~/.config/omarchy/extensions/omarchy-menu.jsonc` always render *after* every stock entry in the same submenu — `mergeMenuSources()` in `MenuModel.js` processes the default file's items fully before appending any extensions-file items, and there's no `order`/`position`/`after` field in the schema to override that.

Concretely: adding a custom sibling to the stock `Capture` submenu (e.g. a delayed-screenshot variant next to `Screenshot`) can only ever land after `Color` (the last stock entry) — never between `Screenshot` and `Screenrecord`, even though that's the logical place for it.

Feature request: support an optional field on extension entries (e.g. `"after": "trigger.capture.screenshot"` or `"position": <n>`) so custom rows can be inserted at an arbitrary point relative to stock rows, not just appended at the end of the submenu. A settings GUI for reordering/injecting menu entries would be an even nicer long-term version of this, but the JSONC field alone would unblock the common case.

Happy to test a PR if useful — this came up while building a couple of delayed-screenshot menu entries for personal use.

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/13824· confirmed
• Fixed bypr/14812· 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.