Loquent's design system is two layers — and we only ever wrote down one.

00TL;DR — six workstreams

The verdict on the original question (does the design skill follow Aurora?) is yes for the visual layer — but "exact knowledge" needs five more things, four of which don't exist yet.

01The design system is two layers

A coding agent that loads app-design today learns how to make a card coral and frosted. It learns nothing about what a Loquent screen is for. Both are "the design system."

02The agent-era interaction paradigm

The mental model, stated so an agent could build to it — plus the hard UI principles it implies. This becomes a new always-on rule.

The principles this forces on every UI

03The agent-surface catalog

The recurring surfaces the paradigm produces. Many already exist in code (reuse, don't reinvent); the two features add two new families. This catalog becomes the agent-ux skill.

Built today reuse these

Coming this week — two new families set the pattern

04Realtime everywhere

Mandate: all server data, in all areas, updates live — like messaging does today. The infrastructure already exists and is proven; the gap is coverage and a reusable pattern.

The infra (already shipped)

• Server hub: bases/realtime/event_hub.rs — publish_org() / publish_user() / publish_session(), RAII subscription guard, presence tracking.
• Wire: bases/realtime/ws_route.rs (/api/realtime) merges org + user streams; 10s ping / 15s dead-timeout.
• Client: shared/context/realtime_context.rs — RealtimeContext { events, status, reconnect_count, visibility_wake }, 500-event buffer, exponential-backoff reconnect, tab-visibility wake, Capacitor foreground reconnect.
• Canonical consumer: messaging — hooks/use_realtime_messages.rs (last-seen cursor, reset-on-reconnect, idempotent merge by id) + services/publish_message_service.rs.

Coverage map — who's live today

The reusable pattern to standardize

A generic use_realtime_entities<T>(event_types, filter_fn) hook in shared/hooks/ (encapsulates the last-seen cursor + reset-on-reconnect + idempotent merge that messaging hand-rolls), paired with a per-module publish_<entity>_event_service.rs called from every create/update/delete API.

05Inline feedback over toasts

Stop using toasts the way we do. Action confirmations should be inline; toasts only when genuinely necessary; the toast itself redesigned to Aurora glass.

Today: shared/context/toaster_context.rs + shared/components/toast_container_component.rs — 3 variants, bottom-right, 5s auto-dismiss for all. The ~28 success toasts are redundant: the UI change (form closes, row removed, modal dismissed) already confirms the action.

Existing inline primitives to build on: SaveStatus enum + SaveStatusButton + run_save() helper, ConfirmDialog, optimistic list removal. Gaps: row/field success indicators, modal-local operation state.

06Command palette (⌘K)

A single ⌘K entry that unifies navigation, cross-entity search, quick actions, and "ask the assistant" — high value for non-technical owners who can't hunt menus, and the natural front door to an agent-first app.

Mount point: global ⌘K/Ctrl K listener in shared/layouts/app_layout.rs (sibling to ToastContainer), guarded so it doesn't fire while typing in an input. Mobile: secondary entry via the avatar pill or assistant orb (no hardware ⌘). Built as a new command_ui.rs primitive (the cmdk pattern: filtered list + keyboard nav + groups) wrapped by a CommandPalette shared component that owns the app-specific items.

07Component audit vs shadcn

We have a strong 45-primitive foundation (Dioxus-native, mobile-first, Aurora-integrated). These are the real gaps and the thin spots — ordered by value to an agent-first CRM.

Missing — port these new primitives

Improve — thin spots in what we have

08Aurora completeness pass

The visual layer is current, but the app-design skill has drifted behind tailwind.css. Three fixes.

B · Missing recipe classes & tokens (in tailwind.css, absent from the skill)

C · Component index

The skill's quick-reference table covers ~8 of 45 primitives — and omits EmptyState, which its own prose references. Expand to a complete one-line index.

09The knowledge map — what to write where

This answers the original question directly: where each piece of design knowledge lives so a future coding agent has exact knowledge. NEW = create · UPD = update.

10Suggested build sequence

Docs-first where they unblock builders; primitives before the features that consume them.

1. STEP 1Write the paradigm rule + agent-ux skilldocs · fast

   Unblocks correct UI for both features immediately. Cheap, high-leverage, no code risk.

2. STEP 2Aurora completeness pass on app-designdocs · fast

   Naming callout + recipe section + full component index. Verify every class against tailwind.css/src/ui/.

3. STEP 3Realtime: shared hook + rule + scaffoldinginfra

   Build use_realtime_entities, write the rule, update scaffolding skills. Then roll module-by-module (task → contact → insights → sales → settings).

4. STEP 4Feedback: toast redesign + inline pattern + rule revisioninfra

   Redesign the toast (Aurora glass), ship the inline confirmation pattern, revise ui-permissions.md in the same change, migrate the ~28 confirmation sites.

5. STEP 5Core primitivesbuild

   Dialog → DropdownMenu → Popover → Command palette → Table → RadioGroup. Each via add-ui-element, indexed in app-design, rendered in design-system.html.

6. STEP 6The two features, on the now-documented foundationfeature

   Calls Enhancements (live-supervision family) and AutoEvolve (trust-and-learning family) — built against the paradigm rule, the agent-ux catalog, realtime, inline feedback, and the new primitives.

11Open questions

Decisions to lock before I write the docs/code. My recommendations are pre-selected.