Open the app drawer of almost any system that's been alive for a couple of years and you'll find the same thing: a grid of icons, most of which are apps, and a handful of which are… something else. A settings page. A pairing wizard. A diagnostic panel someone needed once.

Nobody decided that. It's sediment. Each one was added by a person solving a real problem, and "put it in the drawer" was the fastest way to make it reachable.

The question that started this work was written down as a question, not a task:

Where should each of NAOMS's capabilities live so a person reaches for them in the place their intuition already points?

That framing matters, because it rules out the answer engineers reach for first — add a search box — and forces the harder one: decide what each thing is.

What was in there that shouldn't have been

The drawer had accumulated a connection ceremony ("connect"), a wallet, infrastructure knobs for bridges, stewardship, match-making and consent, and three operational surfaces — jobs, workloads, CI.

Look at that list and a pattern falls out. Almost none of them are things you open and spend time in. You don't "use" the connect flow; you perform it once, usually while looking at another device. You don't sit in the bridges panel; you configure it and leave. They were sharing a shelf with Chat and Photos, which are places you actually live.

So they moved, along three lines that match what they are:

• Things that are about you — your wallet, connecting to a person, connecting a new device — went to the owner menu, the round icon that represents you.
• Things an operator tunes — bridges, steward, match-making, consent, and the jobs/workloads/CI trio — went to the Configuration UI, grouped by what they govern.
• Things you open and use stayed in the drawer, which now reads: Chat, Contacts, Graph, Hives, Activity. Tasks and Calendar. Flow funding. The Studio.

That last list is the whole point. It is short, and everything on it is an app.

The detail I'd want a reviewer to check

Relocations go wrong in one specific way: the thing gets removed from where it was and its new home turns out to be a stub, so the capability is quietly gone rather than moved.

The code carries its own answer to that. Each removal is annotated where it happened, naming the destination and recording that the new home renders real data — verified by an end-to-end test that walks the Configuration sections — followed by the phrase "so they are never left unreachable."

That's a small sentence doing important work. It's the difference between tidying an interface and deleting features while making the screenshot look better.

The part I didn't expect to admire

There's a list in the drawer code called SYSTEM_APPS. Its job is to hide surfaces that are technically registered as apps but should only appear in Configuration.

It's a hack, and the comment above it says so — in those terms. It calls itself a transitional suppression list, explains that the real fix is structural (a feature that is configuration-only should declare itself as configuration-only, so the ordinary "is this an app?" test drops it automatically with no list needed), records which entries have already been migrated and removed, and states that when the last one goes, the list and the code that consults it are deleted outright.

Three ids are left on it. Separately, three packages have completed the migration. You can count both yourself.

I've read a lot of code comments that explain what a workaround does. It's much rarer to find one that names itself a workaround, defines the condition under which it gets deleted, and leaves a countable measure of how far along it is.

Because here's the failure mode that list is designed against: a suppression list is infinitely extensible. Every future surface that shows up in the wrong place can be fixed by adding one line to it, and each of those lines is individually reasonable, and after two years you have the sediment again — just hidden behind a list instead of sitting in the drawer.

Writing down "this shrinks to empty and then dies" is how you stop that.

What happens if you go to the old place

If something does try to open a configuration-only feature as though it were an app — a stale link, an old deep link, a menu that hasn't caught up — it doesn't silently do nothing, and it doesn't open an empty window. It refuses loudly and sends you to that feature's Configuration home instead.

Which is the right shape for a fallback: don't guess, don't fail silently, and land the person where the thing actually lives now.

The unglamorous truth

Nothing here is new capability. Every one of these surfaces existed the day before and works the same way. Measured in features shipped, this is a zero.

Measured in whether a person can find their wallet, it's most of the product.

Information architecture is the work nobody demos. It's also the difference between software that feels like it was designed and software that feels like it accumulated — and the accumulating kind is what you get by default, for free, just by continuing to add good things to a drawer.

---

Written by AI agents from real project logs; owned and edited by Mujo.