You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Platform-only entries (desktop **Browser** and **Terminal**) trail the shared set rather than interleaving, so the common prefix is identical on every platform.
28
28
29
+
## Grouping: one rule, against the consequential group
30
+
31
+
Order is governed above. **Separators are governed here** — and the answer is: use at most one.
32
+
33
+
Put a single `DropdownMenuSeparator` against the **consequential group** — the actions that
34
+
delete, detach, or change a run — and nowhere else. Everything on the other side of it runs
35
+
uninterrupted in toolbar-mirroring order.
36
+
37
+
That group trails in almost every menu, so in practice the rule reads "one rule immediately
38
+
before Delete / Leave / Close / Hide". It leads in exactly one place: the **logs row menu**,
39
+
where `Retry` and `Cancel Run` are the primary actions on a failed run and sit at the top, with
40
+
the rule beneath them. Ordering follows the surface (see "The rule" above); the separator simply
41
+
fences whichever end the consequential group occupies. A menu whose consequential actions are
42
+
merely *disabled* still gets no extra rule — `disabled` is not a group.
43
+
44
+
```tsx
45
+
// ✗ Bad — four semantic bands the user meets nowhere else
This is the failure that put a dangling rule at the bottom of the logs row menu, where two
86
+
unconditional separators sat above conditional items.
87
+
88
+
**Do not add a prop to move a rule.** The shared workflow context menu grew
89
+
`groupNonDestructiveActions` and `separateNavigationAction` for this; between them they moved one
90
+
separator for one caller, four of six branches were unreachable, and `separateNavigationAction`
91
+
had no observable effect anywhere in the repo. Both are gone. A menu that wants different
92
+
grouping wants the standard grouping.
93
+
29
94
## Encode the order once
30
95
31
96
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.
Copy file name to clipboardExpand all lines: CLAUDE.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -386,7 +386,9 @@ Co-locate a `search-params.ts` per feature exporting the parser map (single sour
386
386
387
387
A list orders itself the way the user already reads the same things somewhere else. Resource menus (`+` attach, `@` mention, resource-tab `+`) mirror the **sidebar** top-down; a row or root **context menu** mirrors that surface's **toolbar**, left-to-right becoming top-to-bottom; tab strips mirror their nav. Platform-only entries (desktop Browser, Terminal) trail the shared set.
388
388
389
-
Encode the order in ONE exported constant and sort by it — never a hand-maintained literal per menu (`RESOURCE_MENU_ORDER` / `byResourceMenuOrder` in `home/components/mothership-view/components/resource-registry`). Render mixed item kinds in a single ordered pass; emitting all submenu-backed families and then all flat ones silently pins every submenu to the top no matter what the constant says. Divergence is allowed only for search ranking, user-controlled ordering, and recency. Full rule in `.claude/rules/sim-list-ordering.md`.
389
+
Encode the order in ONE exported constant and sort by it — never a hand-maintained literal per menu (`RESOURCE_MENU_ORDER` / `byResourceMenuOrder` in `home/components/mothership-view/components/resource-registry`). Render mixed item kinds in a single ordered pass; emitting all submenu-backed families and then all flat ones silently pins every submenu to the top no matter what the constant says. Divergence is allowed only for search ranking, user-controlled ordering, and recency.
390
+
391
+
**Grouping**: at most ONE `DropdownMenuSeparator` per menu, fencing the consequential group — immediately before Delete/Leave/Close/Hide in almost every menu, and immediately after Retry/Cancel Run in the logs row menu, where those lead. No toolbar in the app renders a divider, so multi-band menus teach a taxonomy that exists on no other surface. Build each separator's guard from the EXACT render conditions of the items on both sides — a looser guard is what leaves a dangling rule when its group is conditional. Never add a prop to move a rule. Full rule in `.claude/rules/sim-list-ordering.md`.
Copy file name to clipboardExpand all lines: apps/docs/content/docs/en/platform/enterprise/custom-blocks.mdx
+11-3Lines changed: 11 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -74,7 +74,15 @@ Pick which of the workflow's outputs consumers can use, and give each one a name
74
74
75
75
<Imagesrc="/static/enterprise/custom-blocks-form.png"alt="Create block form filled in: Workspace and Workflow selectors, an uploaded icon, Name and Description fields, an expanded input with a placeholder, and two selected outputs each given a name"width={900}height={570} />
76
76
77
-
### 6. Save
77
+
### 6. Choose whether runs are traced
78
+
79
+
**Trace runs in consumer logs** is off by default. Leave it off and your block stays a single step in every workflow that uses it: nothing about the run is recorded anywhere a consumer can reach.
80
+
81
+
Turn it on and the block's steps appear inside the trace of every workflow that runs it, org-wide. That means anyone who can read those workflows' logs sees your workflow's block names, inputs, outputs, and prompts — including people with no access to this workspace. It is the same information curated outputs and redacted errors otherwise keep on your side of the block, so turn it on when you want consumers to be able to debug your block themselves, and leave it off otherwise.
82
+
83
+
You can change this at any time; it applies to runs from that point on. Failures always return a reference id either way, so you can find a run in your own logs even with tracing off.
84
+
85
+
### 7. Save
78
86
79
87
Click **Save changes**. The block is published immediately and becomes available to everyone in your organization in the workflow editor's block toolbar.
80
88
@@ -86,7 +94,7 @@ In the workflow editor, open the block toolbar. Published custom blocks appear u
86
94
87
95
<Imagesrc="/static/enterprise/custom-blocks-toolbar.png"alt="Workflow editor block toolbar with a Custom Blocks section listing two published blocks below Core Blocks"width={400}height={476} />
88
96
89
-
Consumers don't need any access to the source workflow. The block runs on its own, using only the inputs provided, and returns only the outputs you exposed. Internal steps, models, and intermediate values of the source workflow are never visible.
97
+
Consumers don't need any access to the source workflow. The block runs on its own, using only the inputs provided, and returns only the outputs you exposed. Its internal steps, models, and intermediate values stay hidden unless the block's publisher turned on **Trace runs in consumer logs**, in which case they appear under the block in the run's trace.
90
98
91
99
<Imagesrc="/static/enterprise/custom-blocks-canvas.png"alt="A custom block connected to a Start block on the workflow canvas, with its query input filled in and the run output showing the returned fields"width={900}height={570} />
92
100
@@ -96,7 +104,7 @@ Consumers don't need any access to the source workflow. The block runs on its ow
96
104
97
105
Open a block from **Settings → Enterprise → Custom blocks** to edit or delete it.
98
106
99
-
-**Editing** changes only the block's presentationand interface — name, description, icon, input placeholders, and exposed outputs. The source workflow can't be re-pointed.
107
+
-**Editing** changes only the block's presentation, interface, and trace policy — name, description, icon, input placeholders, exposed outputs, and whether runs are traced in consumer logs. The source workflow can't be re-pointed.
100
108
-**Changing what the block does** is done by editing and **redeploying the source workflow**. The block picks up the new deployment automatically; there's nothing to republish.
101
109
-**Deleting** a block is permanent. Workflows already using it will have that block removed, so replace it before deleting if it's in active use.
0 commit comments