chore(rules): drop the resource-menu sidebar-mirroring rule

Author: TheodoreSpeaks

.claude/rules/sim-list-ordering.md

@@ -1,5 +1,5 @@
 ---
-description: List and menu ordering that mirrors the sidebar or toolbar, with one separator before the destructive action
+description: List and menu ordering that mirrors the toolbar or settings nav, encoded once, with one separator before the destructive action
 paths:
   - "apps/sim/app/**/*.tsx"
   - "apps/sim/ee/**/*.tsx"
@@ -8,7 +8,7 @@ paths:
 
 # List & Menu Ordering
 
-**A list orders itself the way the user already reads the same things somewhere else.** Dropdowns, context menus, tab strips, command palettes, and settings navs are all *second* presentations of a set the user has already seen — in the sidebar, in a toolbar, in a column-header row. When the second presentation reorders that set, the user re-reads it from scratch every time.
+**A list orders itself the way the user already reads the same things somewhere else.** Dropdowns, context menus, tab strips, command palettes, and settings navs are all *second* presentations of a set the user has already seen — in a toolbar, in the settings nav, in a column-header row. When the second presentation reorders that set, the user re-reads it from scratch every time.
 
 This is not a style preference. Order is the cheapest affordance a list has, and the only one that costs nothing to get right.
 
@@ -18,13 +18,14 @@ Before writing a list of items, find where the user sees those same items *first
 
 | The list | Mirrors |
 | --- | --- |
-| Resource menus (`+` attach, `@` mention, resource-tab `+`) | the workspace **sidebar**, top-down |
 | A row / root **context menu** | that surface's **toolbar**, left-to-right → top-to-bottom |
 | Settings tab strip, recently-deleted tabs | the **settings nav**, top-down |
 | A "New …" menu | the order those things appear once created |
 
 Left-to-right becomes top-to-bottom. A toolbar reading `Filter · Sort · Export · Delete` becomes a menu reading Filter, Sort, Export, Delete — never alphabetized, never grouped by implementation, never "destructive last" unless the toolbar already puts it last.
 
+Resource menus (`+` attach, `@` mention, resource-tab `+`) do not mirror the sidebar. Their order is a product decision encoded in `RESOURCE_MENU_ORDER` (see below), and every resource menu shares it.
+
 Platform-only entries (desktop **Browser** and **Terminal**) trail the shared set rather than interleaving, so the common prefix is identical on every platform.
 
 ## Grouping: a rule marks a change in what the action acts on
@@ -107,10 +108,10 @@ grouping wants the standard grouping.
 An order duplicated across surfaces is an order that will drift. Export **one** constant and sort by it — do not hand-maintain a matching literal per menu.
 
 ```ts
-/** Top-down order for every menu listing resource families, mirroring the sidebar. */
+/** Top-down order for every menu listing resource families. */
 export const RESOURCE_MENU_ORDER: readonly MothershipResourceType[] = [
-  'integration', 'task', 'table', 'file', 'filefolder',
-  'knowledgebase', 'log', 'workflow', 'folder', 'browser', 'terminal', 'generic',
+  'integration', 'task', 'dashboard', 'table', 'file', 'filefolder',
+  'knowledgebase', 'workflow', 'log', 'folder', 'browser', 'terminal', 'generic',
 ]
 
 export function byResourceMenuOrder<T extends { type: MothershipResourceType }>(a: T, b: T) {

.cursor/rules/sim-list-ordering.mdc

@@ -1,13 +1,13 @@
 ---
-description: "List and menu ordering that mirrors the sidebar or toolbar, with one separator before the destructive action"
+description: "List and menu ordering that mirrors the toolbar or settings nav, encoded once, with one separator before the destructive action"
 globs: ["apps/sim/app/**/*.tsx","apps/sim/ee/**/*.tsx","apps/sim/components/**/*.tsx"]
 ---
 
 <!-- Generated from .claude/rules/sim-list-ordering.md by `bun run skills:sync`. Edit the source, not this file. -->
 
 # List & Menu Ordering
 
-**A list orders itself the way the user already reads the same things somewhere else.** Dropdowns, context menus, tab strips, command palettes, and settings navs are all *second* presentations of a set the user has already seen — in the sidebar, in a toolbar, in a column-header row. When the second presentation reorders that set, the user re-reads it from scratch every time.
+**A list orders itself the way the user already reads the same things somewhere else.** Dropdowns, context menus, tab strips, command palettes, and settings navs are all *second* presentations of a set the user has already seen — in a toolbar, in the settings nav, in a column-header row. When the second presentation reorders that set, the user re-reads it from scratch every time.
 
 This is not a style preference. Order is the cheapest affordance a list has, and the only one that costs nothing to get right.
 
@@ -17,13 +17,14 @@ Before writing a list of items, find where the user sees those same items *first
 
 | The list | Mirrors |
 | --- | --- |
-| Resource menus (`+` attach, `@` mention, resource-tab `+`) | the workspace **sidebar**, top-down |
 | A row / root **context menu** | that surface's **toolbar**, left-to-right → top-to-bottom |
 | Settings tab strip, recently-deleted tabs | the **settings nav**, top-down |
 | A "New …" menu | the order those things appear once created |
 
 Left-to-right becomes top-to-bottom. A toolbar reading `Filter · Sort · Export · Delete` becomes a menu reading Filter, Sort, Export, Delete — never alphabetized, never grouped by implementation, never "destructive last" unless the toolbar already puts it last.
 
+Resource menus (`+` attach, `@` mention, resource-tab `+`) do not mirror the sidebar. Their order is a product decision encoded in `RESOURCE_MENU_ORDER` (see below), and every resource menu shares it.
+
 Platform-only entries (desktop **Browser** and **Terminal**) trail the shared set rather than interleaving, so the common prefix is identical on every platform.
 
 ## Grouping: a rule marks a change in what the action acts on
@@ -106,10 +107,10 @@ grouping wants the standard grouping.
 An order duplicated across surfaces is an order that will drift. Export **one** constant and sort by it — do not hand-maintain a matching literal per menu.
 
 ```ts
-/** Top-down order for every menu listing resource families, mirroring the sidebar. */
+/** Top-down order for every menu listing resource families. */
 export const RESOURCE_MENU_ORDER: readonly MothershipResourceType[] = [
-  'integration', 'task', 'table', 'file', 'filefolder',
-  'knowledgebase', 'log', 'workflow', 'folder', 'browser', 'terminal', 'generic',
+  'integration', 'task', 'dashboard', 'table', 'file', 'filefolder',
+  'knowledgebase', 'workflow', 'log', 'folder', 'browser', 'terminal', 'generic',
 ]
 
 export function byResourceMenuOrder<T extends { type: MothershipResourceType }>(a: T, b: T) {

CLAUDE.md

@@ -91,7 +91,7 @@ The `'use client'` server boundary, the app/worker runtime env split, and featur
 - **Components**: `'use client'` only for hooks or browser APIs. Structure order, extraction thresholds, and list-render rules: `.claude/rules/sim-components.md`. Render-performance idioms (lazy-init refs, hoisting, `Map` pre-indexing, `[...arr].sort()` never `toSorted()` on client paths): `.claude/rules/sim-react-performance.md`. For effect/state/memo/callback anti-patterns use the `/you-might-not-need-*` skills and verify against the running UI.
 - **State ownership**: React Query owns server data — never `useState` + `fetch`; shareable client view-state (tabs, filters, search, pagination, selected id) lives in the URL via `nuqs`; Zustand owns global client state; `useState` owns UI-only state. Hooks: `.claude/rules/sim-hooks.md`. Stores (`devtools`, `persist` only with an explicit `partialize` whitelist, workflow value invariants): `.claude/rules/sim-stores.md`. URL state: `.claude/rules/sim-url-state.md`.
 - **Utils**: inline a helper with one consumer; create `utils.ts` when 2+ files share it — in `lib/` (app-wide) or `feature/utils/` (feature-scoped). Check `lib/` before writing a new one.
-- **Lists and menus** mirror the order the user already reads elsewhere (sidebar, toolbar), encoded in one exported order constant; a separator marks only a change in what the action acts on (typically one, before the destructive action): `.claude/rules/sim-list-ordering.md`.
+- **Lists and menus** mirror the order the user already reads elsewhere (toolbar, settings nav), encoded in one exported order constant (resource menus share `RESOURCE_MENU_ORDER`, a product order that does not mirror the sidebar); a separator marks only a change in what the action acts on (typically one, before the destructive action): `.claude/rules/sim-list-ordering.md`.
 - **Caching**: `lru-cache` with a `max` ceiling, never a hand-rolled TTL `Map`; a lifecycle map is not a cache; cache the gate, never the credential: `.claude/rules/sim-caching.md`.
 
 ## API Contracts and Routes

apps/sim/app/workspace/[workspaceId]/home/components/mothership-view/components/resource-registry/resource-registry.tsx

@@ -289,10 +289,9 @@ export const RESOURCE_REGISTRY: Record<MothershipResourceType, ResourceTypeConfi
 export const MENTION_PREVIEW_DEFAULT_LIMIT = 5
 
 /**
- * Top-down order for every menu that lists resource families, mirroring the
- * workspace sidebar so a user reads the same sequence in both places. The two
- * desktop-only panels trail the workspace resources, matching where they surface
- * in the app. `folder`/`filefolder` never render as their own entry — they feed
+ * Top-down order for every menu that lists resource families (`+` attach, `@`
+ * mention, resource-tab `+`). It is its own product order, not a copy of the
+ * sidebar. The two desktop-only panels trail the workspace resources. `folder`/`filefolder` never render as their own entry — they feed
  * their family's folder tree — but are ordered beside it so a menu that ever does
  * surface them lands in the right place.
  */