@nextop-os/ui-system 0.0.15 → 0.0.17

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (35) hide show
  1. package/AGENTS.md +84 -0
  2. package/README.md +86 -0
  3. package/UI_SYSTEM_GUIDELINES.md +148 -0
  4. package/agent/install-skill.mjs +181 -0
  5. package/agent/nextop-ui-system/SKILL.md +79 -0
  6. package/agent/nextop-ui-system/references/extract-base-component.md +43 -0
  7. package/agent/nextop-ui-system/references/maintain-inventory.md +40 -0
  8. package/agent/nextop-ui-system/references/promote-business-component.md +352 -0
  9. package/agent/nextop-ui-system/references/use-existing-component.md +37 -0
  10. package/agent/nextop-ui-system/scripts/create-business-preview.mjs +658 -0
  11. package/dist/{chunk-G6KJIFD2.js → chunk-FT633NLJ.js} +2 -2
  12. package/dist/{chunk-OBW6ALOJ.js → chunk-NFSMZKML.js} +78 -3
  13. package/dist/chunk-NFSMZKML.js.map +1 -0
  14. package/dist/chunk-XHA7R2WC.js +292 -0
  15. package/dist/chunk-XHA7R2WC.js.map +1 -0
  16. package/dist/components/index.js +2 -2
  17. package/dist/dev-vite.d.ts +9 -0
  18. package/dist/dev-vite.js +578 -0
  19. package/dist/dev-vite.js.map +1 -0
  20. package/dist/icons/index.d.ts +14 -1
  21. package/dist/icons/index.js +16 -2
  22. package/dist/index.d.ts +1 -1
  23. package/dist/index.js +17 -3
  24. package/dist/metadata/components.json +1464 -0
  25. package/dist/metadata/components.schema.json +106 -0
  26. package/dist/metadata/index.d.ts +25 -0
  27. package/dist/metadata/index.js +1472 -0
  28. package/dist/metadata/index.js.map +1 -0
  29. package/dist/styles/semantic.css +1 -0
  30. package/dist/styles/theme.css +12 -0
  31. package/package.json +25 -3
  32. package/dist/chunk-IK2XRJQG.js +0 -56
  33. package/dist/chunk-IK2XRJQG.js.map +0 -1
  34. package/dist/chunk-OBW6ALOJ.js.map +0 -1
  35. /package/dist/{chunk-G6KJIFD2.js.map → chunk-FT633NLJ.js.map} +0 -0
@@ -0,0 +1,352 @@
1
+ # Promote Business Component
2
+
3
+ Use this reference when business-side UI should become a reusable
4
+ host-agnostic display component.
5
+
6
+ ## Business Criteria
7
+
8
+ Proceed only if the component can render from props with no host side effects.
9
+ Business components may expose domain display props such as workspace, file,
10
+ task, agent, run, project, account, status, permission, labels, and callbacks.
11
+
12
+ Do not promote UI that owns daemon, Electron, router, store, query, persistence,
13
+ polling, filesystem access, or workflow orchestration.
14
+
15
+ ## Agent-Owned Analysis
16
+
17
+ The agent must automatically analyze the candidate from code evidence. Do not
18
+ ask the user to provide the state matrix or props boundary unless the code has
19
+ conflicting evidence or an unclear business meaning.
20
+
21
+ Scan:
22
+
23
+ - source component and nearby helpers
24
+ - call sites and conditional rendering branches
25
+ - props, types, tests, mocks, fixtures, and sample data
26
+ - relevant i18n keys and resolved labels
27
+ - existing UI-system metadata and components
28
+
29
+ Build a state matrix from that evidence. For each candidate state, record:
30
+
31
+ - state name
32
+ - source file or branch proving the state
33
+ - props or data needed to render it
34
+ - host-owned behavior that must stay outside the shared component
35
+ - whether the state belongs in the shared component contract
36
+
37
+ ## Agent-Owned Boundary Decision
38
+
39
+ The agent decides the proposed component boundary before asking for preview
40
+ review:
41
+
42
+ - component `id` and `layer: "business"`
43
+ - source usage being replaced
44
+ - intended reuse surfaces
45
+ - public props and callbacks
46
+ - host-owned state and side effects that remain outside
47
+ - states that will appear in storyboard
48
+ - stable export path and metadata entry
49
+
50
+ If the candidate is not reusable or cannot stay host-agnostic, do not promote
51
+ it. Prefer using existing components or keeping the UI local.
52
+
53
+ ## Temporary Preview Gate
54
+
55
+ Before writing the component into `packages/ui/system`, generate a temporary
56
+ preview outside the repository.
57
+
58
+ The preview is an early confirmation of the component that will be promoted,
59
+ not a loose mockup. Build it from three inputs:
60
+
61
+ - the code-evidence state matrix
62
+ - the proposed public props and callback boundary
63
+ - the existing candidate UI source or visual surface being extracted
64
+
65
+ The draft component inside the preview should be a props-driven version of the
66
+ candidate source with host-owned behavior removed. Once the user confirms the
67
+ preview, the promoted component should be copied from the confirmed draft with
68
+ only package integration edits such as final file placement, exports, metadata,
69
+ storyboard wiring, and type tightening. Do not confirm a placeholder preview and
70
+ then reimplement a materially different component in `packages/ui/system`.
71
+
72
+ 1. Create the preview under
73
+ `$TMPDIR/nextop-ui-system-preview-<component-id>/`.
74
+ 2. Start the UI-system dev server:
75
+
76
+ ```bash
77
+ pnpm --filter @nextop-os/ui-system dev:server
78
+ ```
79
+
80
+ If a server may already be running, probe `/health` first.
81
+
82
+ 3. Configure the temporary Vite app with
83
+ `nextopUISystemDev({ serverUrl })` from
84
+ `@nextop-os/ui-system/dev-vite`.
85
+ 4. Import UI-system components, icons, styles, and utilities through stable
86
+ public entrypoints.
87
+ 5. Render every accepted state from the state matrix using the props-driven
88
+ draft component adapted from the candidate source.
89
+ 6. Start the preview app and give the user a local URL.
90
+ 7. Wait for the user to confirm the state set, visual behavior, and props
91
+ boundary before promoting the component into `packages/ui/system`.
92
+
93
+ The preview is a review gate, not package source. Do not put draft preview
94
+ files in the Nextop checkout.
95
+
96
+ ## Preview Scaffold Script
97
+
98
+ Prefer the bundled script when creating the temporary preview scaffold:
99
+
100
+ ```bash
101
+ node packages/ui/system/agent/nextop-ui-system/scripts/create-business-preview.mjs \
102
+ --component-id <component-id> \
103
+ --component-name <ComponentName> \
104
+ --state-matrix /path/to/state-matrix.json
105
+ ```
106
+
107
+ The state matrix JSON may be either an array or an object with a `states` array:
108
+
109
+ ```json
110
+ {
111
+ "states": [
112
+ {
113
+ "name": "normal",
114
+ "description": "Installed agents with status and actions.",
115
+ "evidence": ["apps/desktop/src/.../AgentSettings.tsx normal branch"],
116
+ "propsData": ["rows", "status labels", "action labels"],
117
+ "hostOwnedBehavior": ["install queue", "i18n lookup"],
118
+ "boundaryNotes": ["callbacks are host-provided"],
119
+ "includedInContract": true
120
+ }
121
+ ]
122
+ }
123
+ ```
124
+
125
+ The script writes a Vite React app scaffold to
126
+ `$TMPDIR/nextop-ui-system-preview-<component-id>/` by default. The generated
127
+ app includes:
128
+
129
+ - `vite.config.ts` with `nextopUISystemDev({ serverUrl })`
130
+ - `src/stateMatrix.ts` from the code-evidence state matrix
131
+ - `src/Preview.tsx` with a draft component and state cards
132
+ - `src/style.css` with Tailwind source hints for the dev cache and installed
133
+ package
134
+
135
+ Treat the generated `src/Preview.tsx` as a scaffold. Replace the generic draft
136
+ component with a props-driven adaptation of the candidate source before asking
137
+ for user confirmation. The confirmed preview component is the implementation
138
+ blueprint for `packages/ui/system`.
139
+
140
+ After generation, run the printed commands from the preview directory:
141
+
142
+ ```bash
143
+ pnpm install
144
+ pnpm dev -- --host 127.0.0.1
145
+ ```
146
+
147
+ Use `--out-dir`, `--server-url`, or `--force` only when the default temporary
148
+ directory or server URL is unsuitable.
149
+
150
+ ## Preview Code Generation Prompt
151
+
152
+ Use a prompt like this to turn the candidate source into the high-fidelity draft
153
+ inside the temporary preview. Fill the inputs from code evidence and the
154
+ proposed boundary; do not ask the user to write the preview code.
155
+
156
+ ```text
157
+ Generate a temporary Vite React preview for a proposed Nextop UI-system business
158
+ component promotion.
159
+
160
+ Inputs:
161
+ - Component id: <component-id>
162
+ - Proposed export name: <ComponentName>
163
+ - Proposed layer: business
164
+ - Source usage being replaced: <source file paths and call sites>
165
+ - Candidate source excerpt or file paths: <component/helper files to adapt>
166
+ - Proposed props and callbacks: <TypeScript interface or bullet list>
167
+ - Host-owned behavior to exclude: <daemon/router/store/i18n/data loading/etc.>
168
+ - State matrix:
169
+ <state name | source evidence | required props/data | host-owned behavior |
170
+ included in component contract>
171
+
172
+ Requirements:
173
+ 1. Create all preview files under
174
+ `$TMPDIR/nextop-ui-system-preview-<component-id>/`; do not write draft
175
+ preview files inside the Nextop checkout.
176
+ 2. Start from the generated files produced by
177
+ `scripts/create-business-preview.mjs` unless there is a specific reason to
178
+ hand-author the preview.
179
+ 3. Adapt the candidate UI source into a props-driven draft component. Preserve
180
+ the real visual structure, component composition, class names, spacing,
181
+ icons, and state-specific branches unless they depend on host-owned
182
+ behavior.
183
+ 4. Replace host-owned behavior with props, static sample data, no-op handlers,
184
+ or console logging. Do not keep daemon, Electron, router, store, query,
185
+ filesystem, polling, i18n key lookup, or workflow orchestration in the
186
+ preview component.
187
+ 5. Create or update a minimal Vite React app with `package.json`,
188
+ `index.html`, `src/main.tsx`, `src/Preview.tsx`, `src/stateMatrix.ts`, and
189
+ `src/style.css`.
190
+ 6. Configure `vite.config.ts` with
191
+ `nextopUISystemDev({ serverUrl: "http://127.0.0.1:4100" })` from
192
+ `@nextop-os/ui-system/dev-vite`.
193
+ 7. Import UI-system components, icons, utilities, and styles only through
194
+ stable public entrypoints:
195
+ `@nextop-os/ui-system`, `@nextop-os/ui-system/components`,
196
+ `@nextop-os/ui-system/icons`, `@nextop-os/ui-system/styles.css`, and
197
+ `@nextop-os/ui-system/utils`.
198
+ 8. Render every accepted state from the state matrix in one screen. Each state
199
+ card must show the state name, source evidence, included/excluded boundary
200
+ notes, and the rendered draft component.
201
+ 9. Keep copy, labels, permissions, statuses, and formatting as props in the
202
+ preview so the component boundary is reviewable.
203
+ 10. Do not import from `@nextop-os/ui-system/src/*`, app internals, daemon,
204
+ Electron, router, stores, query clients, or checkout-relative paths.
205
+ 11. Print the commands needed to run the preview and the expected local URL.
206
+
207
+ Output:
208
+ - File list with complete contents.
209
+ - Run commands.
210
+ - Short review checklist for the user: state coverage, visual behavior, props
211
+ boundary, and host-owned behavior.
212
+ - A note identifying which preview component file should be copied into
213
+ `packages/ui/system` after user confirmation.
214
+ ```
215
+
216
+ The generated preview should make boundary mistakes visible. If the draft needs
217
+ app state, navigation, fetching, or host adapters to render, stop and revise the
218
+ component boundary instead of promoting it.
219
+
220
+ ## Preview Chain Demo
221
+
222
+ Example request:
223
+
224
+ ```text
225
+ Promote the managed agent settings table into @nextop-os/ui-system.
226
+ ```
227
+
228
+ Expected chain:
229
+
230
+ 1. **Analyze source evidence**
231
+ - Read the source table, settings panel call sites, tests, mocks, and i18n
232
+ labels.
233
+ - Check existing metadata for reusable table, badge, button, dialog, and
234
+ icon primitives.
235
+ 2. **Build the state matrix**
236
+
237
+ ```text
238
+ normal
239
+ - Evidence: settings table renders installed agents with status and actions.
240
+ - Props/data: rows, status labels, action labels, icon slots, callbacks.
241
+ - Host-owned: install/uninstall orchestration, queue state derivation, i18n.
242
+ - Contract: yes.
243
+
244
+ empty
245
+ - Evidence: settings surface renders no configured agents.
246
+ - Props/data: empty title/body.
247
+ - Host-owned: deciding whether inventory is empty.
248
+ - Contract: yes.
249
+
250
+ disabled
251
+ - Evidence: actions disabled while an operation is pending.
252
+ - Props/data: disabled rows or disabled actions.
253
+ - Host-owned: permission and pending-operation calculation.
254
+ - Contract: yes.
255
+
256
+ error-like
257
+ - Evidence: row can show install failure or unavailable status.
258
+ - Props/data: tone, status label, supporting text.
259
+ - Host-owned: failure classification and retry behavior.
260
+ - Contract: yes.
261
+ ```
262
+
263
+ 3. **Decide the boundary before preview**
264
+ - `id`: a stable kebab-case business component id, for example
265
+ `example-business-component`
266
+ - `layer`: `business`
267
+ - Export: a matching PascalCase component name, for example
268
+ `ExampleBusinessComponent`
269
+ - Public props: rows, labels, icon render slots, action callbacks, disabled
270
+ flags, status/tone fields, empty-state copy.
271
+ - Host-owned behavior: i18n lookup, daemon calls, install queue,
272
+ confirmation dialogs, persistence, routing, and state derivation.
273
+ 4. **Generate a high-fidelity preview component**
274
+ - Write the state matrix to a temporary JSON file.
275
+ - Generate the preview scaffold:
276
+
277
+ ```bash
278
+ node packages/ui/system/agent/nextop-ui-system/scripts/create-business-preview.mjs \
279
+ --component-id example-business-component \
280
+ --component-name ExampleBusinessComponent \
281
+ --state-matrix /tmp/example-business-component-state-matrix.json \
282
+ --force
283
+ ```
284
+
285
+ - Adapt the current candidate source into `src/Preview.tsx` as a props-driven
286
+ business component draft.
287
+ - Keep the real table layout, status cells, action affordances, icon
288
+ placement, empty state, and disabled/error branches.
289
+ - Replace host behavior with props and local callback stubs: i18n-resolved
290
+ labels, queue state, confirmation dialog decisions, daemon calls, and
291
+ install orchestration stay outside the draft.
292
+ - Start or verify the UI-system dev server:
293
+
294
+ ```bash
295
+ pnpm --filter @nextop-os/ui-system dev:server
296
+ curl http://127.0.0.1:4100/health
297
+ ```
298
+
299
+ - Start the preview app and give the user the local URL.
300
+
301
+ 5. **User review gate**
302
+ - Ask the user to review state coverage, visual behavior, and props
303
+ boundary in the preview.
304
+ - If the user finds a missing state or boundary leak, update the state
305
+ matrix and regenerate the temporary preview.
306
+ - Only proceed after the user confirms the preview.
307
+ 6. **Promote after confirmation**
308
+ - Copy the confirmed preview draft into
309
+ `packages/ui/system/src/components/<component-file>.tsx`.
310
+ - Make only package integration edits: final exported prop types, imports,
311
+ class cleanup, and package-local helpers.
312
+ - Export it from stable barrels.
313
+ - Add metadata with `layer: "business"` and storyboard coverage for the
314
+ confirmed states.
315
+ - Replace the original app UI with `@nextop-os/ui-system` imports while
316
+ leaving host-owned behavior in the caller.
317
+ 7. **Validate and report**
318
+ - Run metadata, boundary, storyboard, and relevant package checks.
319
+ - Report the state matrix summary, reviewed preview URL, final boundary,
320
+ validation results, and uncovered risks.
321
+
322
+ ## Implementation
323
+
324
+ After preview confirmation:
325
+
326
+ 1. Implement the business component by composing `base` primitives.
327
+ 2. Keep all host-owned behavior in the caller.
328
+ 3. Add stable exports and metadata with `layer: "business"`.
329
+ 4. Add storyboard examples for normal, empty, disabled, loading, and error-like
330
+ states when those states exist in the public contract.
331
+ 5. Migrate callers by replacing only the visual surface.
332
+
333
+ ## Validation
334
+
335
+ Run the relevant checks:
336
+
337
+ ```bash
338
+ node tools/scripts/check-ui-metadata.mjs
339
+ pnpm check:ui-boundaries
340
+ pnpm --filter @nextop-os/ui-storyboard typecheck
341
+ pnpm --filter @nextop-os/ui-system typecheck
342
+ ```
343
+
344
+ If a consumer was migrated, also run that consumer's typecheck or build.
345
+
346
+ Report:
347
+
348
+ - state matrix summary
349
+ - preview URL reviewed by the user
350
+ - component boundary decision
351
+ - validation commands and results
352
+ - remaining risks or uncovered states
@@ -0,0 +1,37 @@
1
+ # Use Existing Component
2
+
3
+ Use this reference when replacing local UI with `@nextop-os/ui-system` or when
4
+ answering what shared components exist.
5
+
6
+ ## Workflow
7
+
8
+ 1. Read component metadata first by `id`, `name`, `export`, `layer`, and
9
+ `useCases`.
10
+ 2. Prefer an existing component before creating, extracting, or promoting a new
11
+ one.
12
+ 3. Read the selected component source and props type before using it.
13
+ 4. Import through stable public entrypoints only.
14
+ 5. Replace only the visual surface.
15
+
16
+ ## Caller-Owned Work
17
+
18
+ Keep these in the caller:
19
+
20
+ - host state and derived business state
21
+ - data loading, cache mutation, and persistence
22
+ - routing, daemon calls, Electron calls, and filesystem access
23
+ - i18n key lookup and user-visible product copy selection
24
+ - confirmation dialogs, queueing, install or uninstall flows, and navigation
25
+
26
+ The UI-system component should receive resolved props, labels, callbacks,
27
+ status values, icons, and children.
28
+
29
+ ## Validation
30
+
31
+ Run the smallest relevant checks:
32
+
33
+ ```bash
34
+ pnpm check:ui-boundaries
35
+ ```
36
+
37
+ If the consumer code changed, also run the relevant consumer typecheck or build.