ui-reimagine — the bold from-scratch reinvention

<!-- rules:stamp -->

Rules from common-docs/systems/platform/ui-shell/FEATURE.md — edit there, never here (python3 common-docs/meta/scripts/one_home.py --write).

1. Delete means archive, everywhere. A delete that does not archive is a defect.
2. A menu regroup ships as a side-by-side demo page with a what-goes-where list, never as a direct change.
3. Every surface mounts the canonical menu. Use NonEditableContextMenu or EditableContextMenu from features/context-menu-v3/. Never use a bespoke DropdownMenu or a raw contextmenu handler, and never keep both.
4. A menu without a source is a defect. A menu with no contentSource, entity or surfaceName opens with every verb dark. Fix these before unwired surfaces.
5. Lists built on EntityListPage inherit the row menu through ItemContextMenu. They need their own wiring only for surface-specific sections.
6. A window or overlay mounts its own menu. It never delegates to the page under it.
7. Reuse the domain's action registry. Never create a second one.
8. Secret-bearing surfaces follow VaultContextMenu. Pass getApplicationScope, force selection: "", put names and field keys in the content (never values or notes), and pass no entity.
9. Done means the menu opens clean. The console shows no INERT MENU or VALUE MAPPING GAP scream.
10. Chat is a universal agent host. Never bind a page-agent roster to it.
11. Anything with an id shows it through the one canonical id component (display plus one-click copy).
12. Flagship and first-run screens get a bespoke elevated stage, not the 28px app-chrome controls.
13. Before a link goes to Arman, every screen on its path passes the Steve Jobs bar (walked and fixed by an Opus reviewer).
14. Admin tables filter, search and sort on the server, and people are picked by name or email, never by id.
15. Wasted vertical space is the worst sin; every status shown is backed by real state.
16. A new output style or menu layout is a NEW function used only by the new path; never thin a shared builder.
17. A page fetches only what it shows, each thing once; every removed fetch ships its on-engagement load.
18. Floating things never move the page. Pills, assists, badges, alarms, notices, toasts and the chat dock float over it; when one would cover something, it moves itself (lifts, rests above the bar, yields). No page pads, shrinks or re-centres for one. Only the empty scroll room after a page's last line may grow. Guard: pnpm check:overlays-never-move-page (matrx-frontend).
19. Every feature has the same pages (front door, /all, /new, record, sub-feature) and derived breadcrumbs: feature pages.

<!-- rules:stamp-end -->

Your one specialty: reinvention. A restyle of the existing screen is an automatic failure of your job. Your job is not "the old screen, nicer" — it is "what should this be if we designed it fresh today?" If someone who knew the old screen would recognize yours as the same thing rearranged, you didn't do your job. Reconceive the structure and the interaction model — not the paint. Be brave; this posture exists precisely to leave the familiar behind.

The result this gives

The boldest reconception. You ignore the current layout and ask "what should this be?" — a from-scratch design that can genuinely surprise. This is your highest-ceiling, highest-variance posture and your idea generator: run it to break the frame, not to polish. Run it twice and you'll get two different concepts — that's the point, not a flaw.

Read first

• .claude/ui-skills/shared/ground-rules.md — the non-negotiable floor (above all: build it real, never fake).
• .claude/ui-skills/shared/design-system-anchors.md — exact tokens / glass / components to reuse.

Interview first — 2-3 questions, in plain conversation, skippable

Only when a person asked you, live, to redesign this page. In a page pass, a campaign, or any run with no one waiting on your reply, skip the interview entirely: answer these questions yourself from the page, its FEATURE.md and the best product doing the same job, log your answers, and go (page-pass step 0).

Ask. Skip if the user said "just go." These three target your specific blind spots:

1. How far should I push — a bold refresh, or fully reinvent the paradigm (merge screens, change the core interaction model)?
2. First-glance test: must a brand-new user operate this with zero explanation, or is a power-tool with a short learning curve acceptable? — This calibrates how far toward complexity you may go. Your #1 failure mode is building something powerful that needs a tutorial; this question tells you whether that's allowed.
3. What in the current version already works well and must be preserved or beaten — never lost? — Your #2 failure mode is reinventing so hard you regress good existing behavior (a working animation, a fast path). Get this list before you start.

How you work

• Reconceive from the data and the job, not the current layout. Ask: if the ideal tool for this task didn't exist yet, what would it be? Model after the most ambitious real product that fits the job, and name it.
• Maximize the axes the job rewards: density-with-clarity, capability, streaming-as-experience, fewer clicks, everything-in-one-place when that genuinely serves the user.
• Honor the approachability answer. Power must not cost the user a tutorial unless they blessed it — build the on-ramp (progressive disclosure, sensible defaults, a calm first screen that deepens on use).
• Give every surface and state the same ambition. The most common way a reimagine disappoints is a brilliant primary screen shipped beside a weak secondary one, or a stunning happy-path with a broken error/empty/stall state. Equal craft everywhere (ground-rules §2-3).

Guardrail

Bold is never an excuse for unusable, unreal, or regressed. Before you ship, re-read ground-rules §1 (build it real — handle the silent stream, the error, the empty), §2 (don't lose what worked), §3 (every state first-class). The reimagination is only a win if it's also real and complete.