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
Superposition Embeddable UI is used by developers, platform operators, product engineers, and workspace administrators who need to inspect and manage configuration, dimensions, overrides, and audit activity from within a host application.
10
+
11
+
## Product Purpose
12
+
13
+
The library provides embeddable admin surfaces for Superposition configuration management. Success means a host app can mount focused, trustworthy workflows that feel native to Juspay product tooling while remaining easy to scope, theme, and integrate.
14
+
15
+
## Brand Personality
16
+
17
+
Precise, composed, operational. The UI should feel like a dependable control surface for high-stakes configuration work, not a decorative dashboard.
18
+
19
+
## Anti-references
20
+
21
+
Avoid bespoke controls that diverge from Blend, marketing-style layouts, oversized empty states, heavy gradients, nested cards, and dense inline styling that makes the interface feel detached from the design system.
22
+
23
+
## Design Principles
24
+
25
+
- Blend first: use Blend components, tokens, states, and spacing as the primary interface vocabulary.
26
+
- Keep operators in flow: filters, tables, forms, and actions should be predictable, compact, and quick to scan.
27
+
- Make scope visible: workspace, boundary context, feature gates, and read-only limits should be clear without adding visual noise.
28
+
- Favor structured detail: use consistent key-value rows, tags, and tables for configuration data instead of ad hoc text blocks.
29
+
- Preserve host control: redesigns must keep the embeddable API, custom modal hooks, theming hooks, and scoped behavior intact.
30
+
31
+
## Accessibility & Inclusion
32
+
33
+
Target accessible defaults through Blend primitives, keyboard-friendly controls, visible focus states, readable contrast, and layouts that remain usable in constrained embedded containers.
Copy file name to clipboardExpand all lines: README.md
+14-2Lines changed: 14 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,11 +53,12 @@ The host app only needs to provide a `config` object.
53
53
-`scope.locked` (optional): keeps the UI inside that bounded slice.
54
54
-`strict` (optional): prevents extra boundary context and uses exact context matching for override lists.
55
55
-`features` (optional): which screens are allowed to render. `[]` renders no feature UI.
56
-
-`capabilities` (optional): per-feature action switches such as create, delete, ramp, and execute.
56
+
-`capabilities` (optional): per-feature action switches for create, update, and delete.
57
57
-`filters.defaultConfigPrefix` (optional): restricts default config keys and override values.
58
58
-`theme` (optional): color, typography, spacing, and radius overrides.
59
59
-`layout` (optional): host-controlled shell, modal, and alert sizing.
60
60
-`ui` (optional): host-owned notifications, confirmation, layering, and boundary-filter controls.
61
+
-`ui.featureControls` (optional): host-owned UI edit toggles for embeddable feature pages.
61
62
-`messages` (optional): host overrides for visible SDK copy.
62
63
63
64
The embeddable UI currently uses its own fetch-based REST client. It does not call a host-installed Superposition SDK directly. If your host app already talks to Superposition through its own backend or SDK, expose or proxy those REST endpoints from the host and point `apiBaseUrl` at that proxy.
@@ -179,6 +180,10 @@ The embeddable UI currently uses its own fetch-based REST client. It does not ca
179
180
},
180
181
"ui": {
181
182
"showBoundaryFilter": false,
183
+
"featureControls": {
184
+
"config": { "editable": true },
185
+
"dimensions": { "editable": true }
186
+
},
182
187
"modalZIndex": 1200,
183
188
"alertZIndex": 1200
184
189
},
@@ -211,7 +216,7 @@ strict: true,
211
216
```
212
217
213
218
If you leave `scope.context` out, the overrides UI is view-only unless
214
-
`capabilities.overrides.editContext` is enabled. The backend is responsible
219
+
`capabilities.overrides.update` is enabled. The backend is responsible
215
220
for authorizing create and edit actions — if the token lacks permission,
216
221
the backend will reject the request.
217
222
@@ -226,6 +231,9 @@ the List Contexts API as `dimension[...]` query params; strict mode sends
226
231
`readOnly` is still the fastest way to disable all mutating actions. Use
227
232
`capabilities` when the host needs more precise control.
228
233
234
+
When a feature appears in `capabilities`, omitted actions default to `false`.
235
+
That makes `capabilities` an explicit allowlist rather than a partial override.
236
+
229
237
For overrides, create and update actions are controlled by `capabilities`.
230
238
The backend enforces authorization — if the request lacks valid credentials,
0 commit comments