`~/.config/omarchy/lock-components/` is created on install and nothing in `/usr/share/omarchy` ever reads it. I suspect that directory was the start of this idea, so this is a request to finish it, or to say it is not wanted so plugin authors stop looking for it.

## The gap

A plugin can replace the lock screen wholesale, and can compose with it by loading `plugins/lock/Service.qml` and adding behaviour around it. What it cannot do is contribute anything **visible** to the lock screen, because nothing may draw over a session-lock surface and there is no hook to draw inside one.

For anything that adds an authentication method, that is the difference between a usable feature and an invisible one. I maintain a face-unlock plugin (https://github.com/Kalinewb/omarchy-face) that runs a check when the display wakes. It works. But the lock screen shows a password field and nothing else, so:

- a check that is running,
- a check that ran and declined,
- and a check that never started,

are pixel-identical to the person standing in front of the machine. The only tells are the infrared emitter glowing and the screen eventually opening. Mine went unnoticed as "broken" for weeks on my own laptop for exactly this reason, and the failure turned out to be a timing race I could not see happening.

## The stock lock already has the shape

`shell/plugins/lock/LockView.qml` does this for fingerprint: `fingerprintConfigured` at :11, a reserved width `fingerprintReserve` at :29, and a glyph gated on it at :209. A plugin-provided equivalent is the same idea with a different source. I am not asking for a new concept, only for that slot to be reachable from outside.

## Smallest thing that would help

An enabled plugin declares a small status element, and the lock view renders it in the space fingerprint already reserves. A read-only slot would be enough for my case: an icon plus one short line of text, with no input and no ability to influence authentication. Anything richer can wait for someone with a case for it.

If a full QML component is too much surface, even a narrow data contract would do — a plugin publishes `{icon, text, state}` and the lock view draws it in Omarchy's own style. That keeps the drawing yours and avoids plugins styling themselves onto the lock screen.

## Why the workaround is not good enough

Hyprland has an `above_lock` layer rule, and it does work: the card appears over the lock screen. I would rather not ship it. The rule matches on layer-shell namespace, and any process running as the user can create a surface claiming that namespace, so granting it hands every process running as me the ability to paint over my own lock screen — including something shaped like a password prompt. That is a poor trade for a status indicator, and it defeats the session-lock protocol's one guarantee. It is also Hyprland-specific.

I would rather have a small supported slot than a compositor bypass, which is why I am asking rather than shipping the bypass.

Happy to prototype it against a shape you would accept.