jui-tools-mcp-server 2.14.0 → 2.14.1

package/data/attribute_definitions.json

@@ -732,7 +732,7 @@
         "string",
         "binding"
       ],
-      "description": "Tint color - hex string or color name from colors.json (binding supported)"
+      "description": "Tint color - hex string or color name from colors.json (binding supported). It is the accent of the node's operable parts, SwiftUI `.tint` / CSS `accent-color`: a control's accent, a link's colour, the text cursor - never the text colour (jsonui-cli 1.9.0 ruling). From 1.9.0 Compose no longer tints the text or icons inside a tinted node (the LocalContentColor wrap is gone), as iOS and web never did. The per-type declarations say what the accent is on that type (TextField: the cursor; Switch / Slider / Progress: the tint; Segment / TabView: the selected item). A container's tintColor reaches the controls inside it (included views, cells and embedded screens too), as SwiftUI's `.tint` does: on Compose, from the release after jsonui-cli 1.9.1, through the library's LocalJsonUITint; a control's own tintColor (or a more specific colour such as onTintColor) wins. Images and icons do not take it."
     },
     "binding": {
       "type": [
@@ -901,7 +901,7 @@
           "systemChromeMaterial": "Chrome"
         },
         "default": "Regular",
-        "description": "Visual effect (blur) style. Measured across the three converters 2026-08-05: the UIKit trio Light/Dark/ExtraLight is what all three map (sjui blur_converter.rb:71, kjui blurview_component.rb:38, rjui blur_converter.rb:98), and web additionally maps the SwiftUI material names. Every converter downcases before matching, so the casing here is presentational. `Regular` is the fallback all three already use for an unrecognised or absent value, hence the declared default. Enumerated because it was declared as a bare string while Blur.effectStyle — the same concept on the component that owns it — carried the enum: the split let the common spelling reach the render stage unvalidated, which is what the codegen-effect gate reported once the mode audit put these fixtures back in scope. Declared on `common`, so it applies on all three platforms and not only on Blur; the ios material/tint table is pinned in attribute_semantics.json -> effectStyle, which is also where the system* valueAliases and the tint layer order are ruled."
+        "description": "Visual effect (blur) style. A value is its declared spelling, case and all (jsonui-cli 1.9.0): no converter downcases before matching, so `thick` or `light` is an undeclared spelling, which the validator names and which draws the default. A node that declares its own effectStyle is judged on that declaration: a Blur takes only Blur.effectStyle's Light / Dark / ExtraLight, so Thick on a Blur draws the default too. The spellings here apply to every other node. The `system*Material` spellings are valueAliases of the material names (systemMaterial -> Regular, systemUltraThinMaterial -> UltraThin, and so on). `Regular` is the fallback every path uses for an unrecognised or absent value, hence the declared default. Enumerated because it was declared as a bare string while Blur.effectStyle — the same concept on the component that owns it — carried the enum: the split let the common spelling reach the render stage unvalidated, which is what the codegen-effect gate reported once the mode audit put these fixtures back in scope. Declared on `common`, so it applies on all three platforms and not only on Blur; the ios material/tint table is pinned in attribute_semantics.json -> effectStyle, which is also where the system* valueAliases and the tint layer order are ruled."
       },
     "tag": {
       "type": [
@@ -1307,7 +1307,7 @@
         "center",
         "right"
       ],
-      "description": "Where the label's text sits across the label's own width: Left the start, Center the middle, Right the end (binding supported). Without textAlign, the horizontal part of gravity places it (left / right / centerHorizontal, center); without either, the start. Vertically the text sits at the vertical gravity names, else the middle (gravityDefaults -> leafOwnFrameChannel). The lines of a multi-line or wrapped label follow the same rule across. (4f ruling 2026-09-27, and the user's ruling for iOS, round 6: align iOS to start.) The web draws it so from jsonui-cli 1.9.0, its lines too (rjui gives gravity's text-center / text-right when textAlign is not declared; measured in Chromium, a wrapped label's lines stayed at the start until then); Compose from jsonui-cli 1.9.0 (4f round 17); iOS from jsonui-cli 1.9.0 and SwiftJsonUI 10.29.0 (round 6) - until then, measured on sjui codegen and SwiftJsonUI Dynamic, a fixed-width label with neither drew its text in the middle (\"Mon\" in 50, a 200 x 44 label), one with gravity right or center at the start, and the lines of a multi-line one at the start whatever its gravity."
+      "description": "Where the label's text sits across the label's own width: Left the start, Center the middle, Right the end (binding supported). Without textAlign, the horizontal part of gravity places it (left / right / centerHorizontal, center); without either, the start. When gravity names both a center part (center / centerHorizontal) and right, center wins, on every platform. Vertically the text sits at the vertical gravity names, else the middle (gravityDefaults -> leafOwnFrameChannel). The lines of a multi-line or wrapped label follow the same rule across. (Ruled 2026-09-27; for iOS: align to start.) The web draws it so from jsonui-cli 1.9.0, its lines too (rjui gives gravity's text-center / text-right when textAlign is not declared; measured in Chromium, a wrapped label's lines stayed at the start until then); Compose from jsonui-cli 1.9.0, except the lines of a wrapContent-width label whose text wraps (by reading, they stayed at the start) and a gravity naming both center and right (by reading, it took right), both from the release after jsonui-cli 1.9.1; iOS from jsonui-cli 1.9.0 and SwiftJsonUI 10.29.0 (round 6) - until then, measured on sjui codegen and SwiftJsonUI Dynamic, a fixed-width label with neither drew its text in the middle (\"Mon\" in 50, a 200 x 44 label), one with gravity right or center at the start, and the lines of a multi-line one at the start whatever its gravity."
     },
     "lines": {
       "type": [
@@ -2880,7 +2880,7 @@
       "valueAliases": {
         "datetime": "dateAndTime"
       },
-      "description": "Date picker mode. datetime is a declared synonym of dateAndTime and the normalizer folds it: sjui and rjui accept both spellings (selectbox_converter.rb case arms; rjui downcases), but KotlinJsonUI's DateSelectBox matches \"dateAndTime\" literally and datetime would silently fall to the date-only branch — so the UIKit spelling is canonical, same reasoning as gradientDirection's capitalised canon."
+      "description": "Date picker mode. datetime is a declared synonym of dateAndTime and the normalizer folds it: sjui and rjui accept both spellings as declared, case and all (sjui matches them literally in selectbox_converter.rb's case arms; rjui's select_box_converter.rb takes a value only when it is a declared spelling, through EnumSpelling.lowered, and lowercases it just for its own case arms), but KotlinJsonUI's DateSelectBox matches \"dateAndTime\" literally and datetime would silently fall to the date-only branch — so the UIKit spelling is canonical, same reasoning as gradientDirection's capitalised canon."
     },
     "datePickerStyle": {
       "type": "string",
@@ -3564,7 +3564,7 @@
           "Diagonal": "Oblique"
         },
         "default": "Vertical",
-        "description": "Gradient direction. Canon copied from GradientView.gradientDirection, which declared the enum for the same concept while this spelling stayed a bare string. Vertical is the fallback on all three. CASE MATTERS on ios: sjui matches 'Horizontal'/'Oblique' literally (modifier_helper.rb:16) without downcasing, while Compose and web downcase — so the capitalised spellings are canonical and the aliases normalise to them before any converter sees the value. RightToLeft and BottomToTop are declared without an alias on purpose: they are reversed directions web implements (gradient_view_converter.rb:88,90) and the other two have no equivalent, so folding them into Horizontal/Vertical would silently reverse the gradient rather than preserve it.",
+        "description": "Gradient direction. Canon copied from GradientView.gradientDirection, which declared the enum for the same concept while this spelling stayed a bare string. Vertical is the fallback on all three. A value is its declared spelling, case and all (jsonui-cli 1.9.0): sjui matches the capitalised spellings literally (modifier_helper.rb gradient_expression), so 'horizontal' is an undeclared spelling that draws the Vertical fallback; the aliases normalise to the capitalised canon before any converter sees the value. Compose and web do not read this declaration (platform swift); their GradientView converters read GradientView.gradientDirection by the same rule (EnumSpelling.lowered: a declared spelling only, lowercased just for their own case arms). RightToLeft and BottomToTop are declared without an alias on purpose: they are reversed directions (sjui draws them trailing to leading and bottom to top), so folding them into Horizontal/Vertical would silently reverse the gradient rather than preserve it.",
         "platform": "swift"
       },
     "locations": {
@@ -3862,7 +3862,7 @@
         "binding"
       ],
       "min": 1,
-      "description": "Number of columns. Literal int -> static GridCells.Fixed(N) / Array(repeating: ..., count: N). Binding @{prop} -> runtime-resolved data.prop; the Collection always renders on the multi-column grid path (LazyVerticalGrid / LazyHorizontalGrid on Android, LazyVGrid / LazyHGrid on iOS) even when the binding resolves to 1, so the grid layout stays stable across runtime column changes."
+      "description": "Number of columns. Literal int -> static GridCells.Fixed(N) / Array(repeating: ..., count: N). Binding @{prop} -> runtime-resolved data.prop; the Collection always renders on the multi-column grid path (LazyVerticalGrid / LazyHorizontalGrid on Android, LazyVGrid / LazyHGrid on iOS) even when the binding resolves to 1, so the grid layout stays stable across runtime column changes. On a horizontal Collection `columns` is the number of lanes (jsonui-cli 1.9.0; until then every horizontal route drew one lane), and a section's own `columns` is that section block's lanes. A paging Collection draws no lanes: paging is not a lane route, whatever `columns` says."
     },
     "columnSpacing": {
       "type": "number",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jui-tools-mcp-server",
-  "version": "2.14.0",
+  "version": "2.14.1",
   "description": "MCP server for JsonUI project management - wraps jui and jsonui-doc CLIs plus component spec lookup",
   "main": "dist/index.js",
   "scripts": {

package/scripts/fetch-definitions.js

@@ -44,7 +44,7 @@ const DATA_DIR = join(PROJECT_ROOT, "data");
 //   3. `npm run fetch-definitions` and commit the data/ diff together with
 //      this pin in one commit
 // JSONUI_CLI_RAW_BASE still overrides the whole base URL for manual testing.
-const JSONUI_CLI_TAG = "v1.9.0";
+const JSONUI_CLI_TAG = "v1.9.2";
 const BASE_URL =
   process.env.JSONUI_CLI_RAW_BASE ||
   `https://raw.githubusercontent.com/Tai-Kimura/jsonui-cli/${JSONUI_CLI_TAG}`;