@imfusion/web-ui 0.10.0 → 0.10.1-dev.2.gb6347f49

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@imfusion/web-ui",
-  "version": "0.10.0",
+  "version": "0.10.1-dev.2.gb6347f49",
   "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-update/SKILL.md

@@ -10,8 +10,8 @@ allowed-tools: Bash Read Grep Skill
 
 # Update Web UI
 
-This workflow has two possible commits: the package/tooling update, then an optional consumer migration. Keep them separate.
-Never overwrite user changes or commit without fresh approval.
+This workflow has two possible commits: the package/tooling update with the fixes its `Breaking` entries require, then an
+optional consumer migration. Keep them separate. Never overwrite user changes or commit without fresh approval.
 
 ## Before you start
 
@@ -20,7 +20,8 @@ Invoke `imf-web-ui-user-profile` first and explain at its levels throughout.
 Open with a short orientation, before any command runs, so the person knows the route and when they will be asked:
 
 1. **Preflight**: check the project and stop on uncommitted work.
-2. **Base update**: install the new package, refresh the skills and hooks, verify, then ask to commit.
+2. **Base update**: install the new package, refresh the skills and hooks, fix what the `Breaking` entries require, verify,
+   then ask to commit.
 3. **Migration check**: read what the new releases changed and report what this project needs; changes and their separate
    commit wait for approval.
 4. **Full audit**: offer `imf-web-ui-audit full`, a read-only check of the whole project against the conventions, wider than
@@ -88,16 +89,23 @@ installer-owned entries idempotently into the registration file for the chosen h
 do not stack an event the project already covers.
 
 After the installer command, inspect the installed skill diffs and briefly report any guidance changes; version-marker
-changes alone do not count. Re-read changed skills and references relevant to the remaining work, including this update skill
-if it changed. Continue from the current step using the updated guidance, keeping the original baseline, user choices, and
-completed changes in mind. Check for newly required steps without repeating completed mutations or expanding the approved
-scope.
+changes alone do not count.
+
+Then re-read, in full, every changed skill and reference the remaining work uses, starting with this update skill when it
+changed. A diff shows what moved, not the step order you continue under, so it does not replace the re-read. Continue from
+the current step using the updated guidance, keeping the original baseline, user choices, and completed changes in mind.
+Check for newly required steps without repeating completed mutations or expanding the approved scope.
 
 ## Verify the base update
 
 After every mutating command, compare the status with the preflight snapshot. Stop on an unexpected path or overlapping
 change.
 
+Read every `Breaking` entry and migration step in `node_modules/@imfusion/web-ui/CHANGELOG.md` between the pre-update and the
+new version, keeping for a prerelease baseline only the ones the dist diff in the migration check confirms, and map each to
+its call sites here. Fix the ones with matching code in the base update, so the update commit leaves the app consistent;
+tests do not catch a removed custom property or a moved scroll container.
+
 Run the consumer's documented full verification. Read its scripts first; prefer an aggregate check, otherwise run the
 non-watch format, lint, typecheck, test, and build commands that exist.
 
@@ -110,8 +118,10 @@ Report before the first commit:
 @imfusion/web-ui update report
 Package      : <old> -> <new>
 Skills       : <status>
+Re-read      : <changed skills read in full, or none changed>
 Hooks        : <status>
 Verification : <status>
+Breaking     : <entries fixed here, not applicable, or none>
 Update files : <paths>
 Held back    : <paths or none>
 Conflicts    : <paths or none>
@@ -137,9 +147,9 @@ diff was already in the baseline; report it as present.
 This phase reads and reports: every file stays as it is until the person approves the migration. Open the report with the
 releases read, then report separately:
 
-- migrations: every `Breaking` entry and migration step, mapped to the call sites it affects here and the fix the changelog
-  shows; a step with no matching code is reported as not applicable. A style-only change, such as a removed margin, raises no
-  type error: find its call sites by component usage;
+- migrations: every `Breaking` entry and migration step the base update left open, mapped to the call sites it affects here
+  and the fix the changelog shows; a step with no matching code is reported as not applicable. A style-only change, such as a
+  removed margin, raises no type error: find its call sites by component usage;
 - compatibility fixes required by changed imports or types that the changelog does not cover;
 - existing uses affected by a changed API or documented behavior;
 - suggestions: new features from the highlights and `Added` entries that fit what the project already builds, each with the