@imfusion/web-ui 0.10.1-dev.45.ga6a3c86a → 0.10.1-dev.46.g5fe8962a

package/CHANGELOG.md

@@ -153,6 +153,7 @@ never changes the character width, so columns stay aligned. CoFo Sans Mono still
 - `Skeleton.Root` fades only its own content in when loading ends; the rest of the page stays still, and no `AbortError` reaches the console — Nikolaus Brunner <brunner@imfusion.com>
 - `AppShell`'s docked aside no longer leaves `AppShell.Main` up to 13px under it at 1024px: Main ends where the aside begins at every docked width — Nikolaus Brunner <brunner@imfusion.com>
 - The Stop hook's verify gate blocks only a turn that edited files. An edit from an earlier turn no longer blocks later turns that only answer questions while the tree stays dirty — Nikolaus Brunner <brunner@imfusion.com>
+- `imf-web-ui-ux` describes patterns and points to `imf-web-ui-components` for which components exist, instead of claiming which ones do not — Nikolaus Brunner <brunner@imfusion.com>
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@imfusion/web-ui",
-  "version": "0.10.1-dev.45.ga6a3c86a",
+  "version": "0.10.1-dev.46.g5fe8962a",
   "description": "The official Web UI component library for ImFusion web apps",
   "author": "ImFusion GmbH",
   "homepage": "https://imfusion.com",

package/src/llms/skills/imf-web-ui-ux/SKILL.md

@@ -7,8 +7,8 @@ description:
 
 # Shape the screen
 
-Use this skill for screen-level decisions. Verify component APIs with `imf-web-ui-components`; put code and styling rules in
-`imf-web-ui-conventions`.
+Use this skill for screen-level decisions. The patterns below name no components: check which component fits a pattern, and
+its API, in `imf-web-ui-components`. Put code and styling rules in `imf-web-ui-conventions`.
 
 Invoke `imf-web-ui-user-profile` first and explain at its levels throughout.
 
@@ -34,33 +34,31 @@ unanswered, make the conservative choice and state the assumption.
 ## Choose a surface
 
 - Use a full page by default.
-- Use `Drawer` for a focused task that keeps the current page in context.
-- Use `Popover` for small contextual content or a light form.
-- Use `Tooltip` for a hint only. It must not contain required or interactive information.
-- Use `Collapsible` for secondary content inside the page.
-- Use `Tabs` for parallel views of one subject. If users must complete every section, use a flow instead.
-
-The library has no modal `Dialog` or `Toast`. Raise those gaps rather than hand-rolling a replacement without a product
-reason.
+- Use a side panel for a focused task that keeps the current page in context.
+- Use a floating panel anchored to its trigger for small contextual content or a light form.
+- Use a hover or focus hint for a short label only. It must not contain required or interactive information.
+- Use a collapsible region for secondary content inside the page.
+- Use tabs for parallel views of one subject. If users must complete every section, use a flow instead.
+- Use a modal dialog for a decision that must be settled before the page continues, such as a destructive action. If no
+  component fits a pattern, raise the gap rather than hand-rolling a replacement without a product reason.
 
 ## Choose between similar controls
 
-- `Button` performs an action, `ChipLink` goes somewhere, and `Chip` labels something.
-- Use `ChipLink` for a link inside text or a row of chips, and `RichLink` for a link that fills its own row, such as a list
-  of resources.
-- Use plain `Table` parts for static small data. Pair them with a headless table library for sorting, pagination, or column
-  logic. TanStack Table is the recommended choice.
-- Use `Callout` for persistent in-place status. Put transient confirmation near the action until a toast pattern exists.
-- Use `Switch` for an immediate setting and `Checkbox` for a submitted choice.
-- Use `Select` for a known list, and consider a different control when the list is very short or very large.
-- Use `Slider` when relative position matters more than typing an exact value.
+- An action is a button, navigation is a link, and a label is a chip.
+- Use an inline link inside text or in a row of chips, and a full-row link for a list of resources.
+- Use a plain table for static small data. Pair it with a headless table library for sorting, pagination, or column logic.
+  TanStack Table is the recommended choice.
+- Use an in-place status message for persistent status. Keep transient confirmation near the action it confirms.
+- Use a switch for an immediate setting and a checkbox for a submitted choice.
+- Use a select for a known list, and consider a different control when the list is very short or very large.
+- Use a slider when relative position matters more than typing an exact value.
 
 ## Build the hierarchy
 
-- Frame an application with `AppShell`.
-- Compose `Stack` and `Row` for spacing and arrangement, and wrap long-form text in `Prose`. Use `Separator` for a real
+- Frame an application with the library's app shell.
+- Arrange content with stack and row layouts, wrap long-form text in a prose container, and use a separator for a real
   division.
-- Use `Typo` for text hierarchy instead of styling raw headings beside it.
+- Use the library's typography components for text hierarchy instead of styling raw headings beside them.
 - Give a view one primary action. Make other actions quieter.
 - Choose density from the user's frequency and data volume: frequent work and large data need compact layouts; occasional
   work benefits from more explanation and space.
@@ -70,15 +68,15 @@ reason.
 Plan these states with the loaded view:
 
 - **Empty**: say what belongs here and what the user can do next.
-- **Loading**: use `Spinner` or a stable skeleton; keep the frame from jumping. The `imf-web-ui-conventions` data topic says
-  which Skeleton part fits each way the data loads.
-- **Error**: explain what failed and the next action in a `Callout` near the problem.
+- **Loading**: use a spinner or a stable skeleton; keep the frame from jumping. The `imf-web-ui-conventions` data topic says
+  which skeleton part fits each way the data loads.
+- **Error**: explain what failed and the next action in an in-place status message near the problem.
 - **Loaded**: the normal view.
 
 ## Keep custom UI native
 
-When the library does not cover a piece, compose its primitives and use `--imf-ui-*` tokens. The implementation details are
-in `imf-web-ui-conventions`.
+When no component covers a piece, compose its primitives and use `--imf-ui-*` tokens. The implementation details are in
+`imf-web-ui-conventions`.
 
 For a screen review, read the relevant reference under `references/`: `usability-heuristics.md`, `visual-design.md`, or
 `forms.md`.

package/src/llms/skills/imf-web-ui-ux/references/forms.md

@@ -6,9 +6,9 @@ validation. These rules cover structure and feedback.
 ## Structure
 
 - Remove fields that can be derived or asked later.
-- Use one column by default. Put short, inseparable values such as city and postal code in a `Row`.
-- Group related fields in a `Stack` and separate groups with more space.
-- Use a labeled `Fieldset` or heading for each group.
+- Use one column by default. Put short, inseparable values such as city and postal code on one row.
+- Group related fields with tight spacing and separate groups with more space.
+- Use a labeled fieldset or heading for each group.
 - Match a field's size to the value it expects.
 
 ## Labels
@@ -21,10 +21,10 @@ hints near the field before the user starts typing.
 Validate when the user finishes a field, except where live feedback genuinely helps, such as password requirements. Keep the
 error next to the field and use more than color to show it.
 
-An error says what is wrong and how to fix it. Keep the user's input. A server or form-level failure belongs in a `Callout`
-near the actions; field-level failures stay with their fields.
+An error says what is wrong and how to fix it. Keep the user's input. A server or form-level failure belongs in an in-place
+status message near the actions; field-level failures stay with their fields.
 
 ## Submission
 
-Use one primary `Button` whose label names the result, such as `Create project`. While submitting, keep the form visible and
+Use one primary button whose label names the result, such as `Create project`. While submitting, keep the form visible and
 show progress. A failed submission must leave the user's input on screen.

package/src/llms/skills/imf-web-ui-ux/references/usability-heuristics.md

@@ -5,12 +5,12 @@ user research.
 
 1. **Show system status.** Give async actions visible progress and confirmation.
 2. **Use the user's language.** Labels and ordering should match the domain, not an API's private names.
-3. **Provide an exit.** Drawers and popovers need clear dismissal; destructive actions need confirmation or undo.
+3. **Provide an exit.** Side panels and floating panels need clear dismissal; destructive actions need confirmation or undo.
 4. **Be consistent.** Reuse the library's established components and semantics.
 5. **Prevent errors.** Constrain known choices and disable actions that cannot work.
 6. **Support recognition.** Keep relevant options and context visible instead of making users remember them.
 7. **Support frequent users.** Add keyboard shortcuts or dense layouts when the task is frequent and data-heavy.
 8. **Remove decoration without a job.** Every element should support the action or the data.
 9. **Make errors recoverable.** Say what failed and what to do next, near the problem.
-10. **Keep help contextual.** Prefer a short hint beside a control to essential information hidden in a tooltip or separate
-    page.
+10. **Keep help contextual.** Prefer a short hint beside a control to essential information hidden in a hover hint or
+    separate page.

package/src/llms/skills/imf-web-ui-ux/references/visual-design.md

@@ -7,12 +7,12 @@ Use this when a screen works but still looks wrong. Decide the hierarchy before
 Write the intended order of attention: title, primary action, content, and supporting details. Use contrast and scale to make
 that order visible. Keep variation limited; if everything is loud, nothing leads.
 
-Reserve saturated status colors for meaning. The primary `Button` should be the strongest action treatment on the screen.
+Reserve saturated status colors for meaning. The primary button should be the strongest action treatment on the screen.
 
 ## Grouping
 
-Use proximity first: tight gaps inside a group, larger gaps between groups. `Stack` gap values encode this relationship. Use
-a shared `Card` or bordered region only when spacing alone does not make the relationship clear.
+Use proximity first: tight gaps inside a group, larger gaps between groups. Spacing values encode this relationship. Use a
+shared card or bordered region only when spacing alone does not make the relationship clear.
 
 Similarity helps related elements stay recognisable across a layout. It supports proximity; it does not replace it.