jui-tools-mcp-server 2.5.0 → 2.5.1

package/data/attribute_definitions.json

@@ -101,8 +101,7 @@
         "binding"
       ],
       "description": "Width weight for flexible layouts (binding supported)",
-      "platform": "swift",
-      "mode": "uikit"
+      "platform": "swift"
     },
     "heightWeight": {
       "type": [
@@ -110,8 +109,10 @@
         "binding"
       ],
       "description": "Height weight for flexible layouts (binding supported)",
-      "platform": "swift",
-      "mode": "uikit"
+      "platform": [
+        "swift",
+        "kotlin"
+      ]
     },
     "maxWidthWeight": {
       "type": [
@@ -231,7 +232,7 @@
         "string",
         "binding"
       ],
-      "description": "Border color - hex string or color name from colors.json (binding supported)"
+      "description": "Border color - hex string or color name from colors.json (binding supported). There is deliberately NO default: a border is drawn only when borderWidth AND borderColor are both declared, and neither half summons one on its own (2026-08-03 user ruling, recorded in attribute_semantics.json#semantics.border and gated by `jui conformance gate --cross-effect` against the five `observable` entries there). Declaring a default here would make borderWidth alone draw, which is the direction d2c8628 took once and the ruling superseded."
     },
     "borderStyle": {
       "type": "string",
@@ -243,15 +244,6 @@
       "default": "solid",
       "description": "Border line style - solid (default), dashed, or dotted"
     },
-    "alpha": {
-      "type": [
-        "number",
-        "binding"
-      ],
-      "min": 0,
-      "max": 1,
-      "description": "Opacity (0-1) - can be data binding"
-    },
     "opacity": {
       "type": [
         "number",
@@ -259,7 +251,7 @@
       ],
       "min": 0,
       "max": 1,
-      "description": "Opacity (0-1), alias for alpha - can be data binding",
+      "description": "Opacity (0-1) - can be data binding. `alpha` is an accepted alias spelling.",
       "aliases": [
         "alpha"
       ]
@@ -734,7 +726,7 @@
     },
     "variables": {
       "type": "object",
-      "description": "Variables for include",
+      "description": "Variables for include The SwiftUI codegen DOES read this (base_view_converter.rb), but only to echo it back as a `// variables: ...` comment — nothing reaches the rendered view, so `mode: uikit` stands. Recorded because the 2026-08-05 mode audit flags the read and the next auditor would otherwise re-derive it: the read is real, the effect is not.",
       "platform": "swift",
       "mode": "uikit"
     },
@@ -778,7 +770,7 @@
     },
     "binding_id": {
       "type": "string",
-      "description": "Binding ID",
+      "description": "Binding ID The SwiftUI codegen DOES read this (base_view_converter.rb), but only to echo it back as a `// binding_id: ...` comment — nothing reaches the rendered view, so `mode: uikit` stands. Recorded because the 2026-08-05 mode audit flags the read and the next auditor would otherwise re-derive it: the read is real, the effect is not.",
       "platform": "swift",
       "mode": "uikit"
     },
@@ -836,24 +828,46 @@
     },
     "events": {
       "type": "object",
-      "description": "Complex event handlers",
-      "platform": "swift",
-      "mode": "uikit"
+      "description": "Complex event handlers"
     },
     "effectStyle": {
-      "type": "string",
-      "description": "Visual effect style",
-      "platform": "swift",
-      "mode": "uikit"
-    },
+        "type": "string",
+        "enum": [
+          "Light",
+          "Dark",
+          "ExtraLight",
+          "Regular",
+          "Prominent",
+          "UltraThin",
+          "Thin",
+          "Thick",
+          "Chrome",
+          "systemMaterial",
+          "systemUltraThinMaterial",
+          "systemThinMaterial",
+          "systemThickMaterial",
+          "systemChromeMaterial"
+        ],
+        "valueAliases": {
+          "systemMaterial": "Regular",
+          "systemUltraThinMaterial": "UltraThin",
+          "systemThinMaterial": "Thin",
+          "systemThickMaterial": "Thick",
+          "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."
+      },
     "tag": {
       "type": [
         "number",
         "binding"
       ],
       "description": "View tag for identification (binding supported)",
-      "platform": "swift",
-      "mode": "uikit"
+      "platform": [
+        "swift",
+        "react"
+      ]
     },
     "userInteractionEnabled": {
       "type": [
@@ -904,8 +918,7 @@
     "touchDisabledState": {
       "type": "string",
       "description": "Touch disable mode",
-      "platform": "swift",
-      "mode": "uikit"
+      "platform": "swift"
     },
     "touchEnabledViewIds": {
       "type": "array",
@@ -919,7 +932,7 @@
     },
     "bindingScript": {
       "type": "string",
-      "description": "Custom Swift binding code",
+      "description": "Custom Swift binding code The SwiftUI codegen DOES read this (base_view_converter.rb), but only to echo it back as a `// bindingScript: ...` comment — nothing reaches the rendered view, so `mode: uikit` stands. Recorded because the 2026-08-05 mode audit flags the read and the next auditor would otherwise re-derive it: the read is real, the effect is not.",
       "platform": "swift",
       "mode": "uikit"
     },
@@ -1221,9 +1234,7 @@
         "array",
         "string"
       ],
-      "description": "Edge insets as array or pipe-separated string",
-      "deprecated": "kotlin",
-      "deprecation_note": "Compose Text has no edgeInset; use padding* instead."
+      "description": "Edge insets as array or pipe-separated string. Applied on every platform including Compose, where it maps to .padding() (kjui text_component.rb / DynamicTextComponent.kt) - the former \"Compose Text has no edgeInset\" deprecation was contradicted by that implementation and was retracted 2026-08-05."
     },
     "underline": {
       "type": [
@@ -1442,7 +1453,7 @@
     },
     "hintAttributes": {
       "type": "object",
-      "description": "Hint text styling attributes",
+      "description": "Hint text styling attributes. The nested keys win over the flat spellings (hintColor / hintFont / hintFontSize): a bag scoped to the hint is the more specific statement. That is the ordinary cascade rule and what all four readers do (rjui label_converter, kjui text_component, sjui Label and SelectBox) - it was unwritten until 2026-08-05, when the one converter that had it backwards was found by contradicting its own comment.",
       "properties": {
         "font": {
           "type": "string",
@@ -1492,27 +1503,23 @@
         "string",
         "binding"
       ],
-      "description": "Placeholder color - hex string or color name from colors.json (binding supported)",
-      "deprecated": "swiftui",
-      "deprecation_note": "SwiftUI TextField placeholder cannot be color-styled."
+      "description": "Placeholder color - hex string or color name from colors.json (binding supported). `placeholderColor` is an accepted alias spelling.",
+      "aliases": [
+        "placeholderColor"
+      ]
     },
     "hintFont": {
       "type": "string",
-      "description": "Placeholder font",
-      "deprecated": "swiftui",
-      "deprecation_note": "SwiftUI TextField placeholder cannot be custom-font-styled."
+      "description": "Placeholder font"
     },
     "hintFontSize": {
       "type": "number",
-      "description": "Placeholder font size",
-      "deprecated": "swiftui",
-      "deprecation_note": "SwiftUI TextField placeholder cannot be custom-size-styled."
+      "description": "Placeholder font size"
     },
     "hintAttributes": {
       "type": "object",
-      "description": "Hint text attributes (font, color, etc.)",
-      "platform": "swift",
-      "mode": "uikit"
+      "description": "Hint text attributes (font, fontSize, fontColor). The nested keys win over the flat spellings (hintColor / hintFont / hintFontSize): a bag scoped to the hint is the more specific statement. That is the ordinary cascade rule and what all four readers do (rjui label_converter, kjui text_component, sjui Label and SelectBox) - it was unwritten until 2026-08-05, when the one converter that had it backwards was found by contradicting its own comment.",
+      "platform": "swift"
     },
     "font": {
       "type": [
@@ -1577,7 +1584,22 @@
     },
     "inputType": {
       "type": "string",
-      "description": "Input type for Android (Android-only; `input` is the cross-platform attribute)",
+      "enum": [
+        "text",
+        "number",
+        "numberDecimal",
+        "phone",
+        "email",
+        "password",
+        "multiline",
+        "textEmailAddress",
+        "textPassword"
+      ],
+      "valueAliases": {
+        "textEmailAddress": "email",
+        "textPassword": "password"
+      },
+      "description": "Input type for Android (Android-only; `input` is the cross-platform attribute). Both the JsonUI spellings and the raw android:inputType names the frozen XML mapper passed through are accepted; the latter normalize to the former.",
       "platform": "kotlin"
     },
     "returnKeyType": {
@@ -1602,7 +1624,31 @@
         "string",
         "binding"
       ],
-      "description": "Content type for autofill (binding supported)"
+      "enum": [
+        "username",
+        "password",
+        "newPassword",
+        "oneTimeCode",
+        "email",
+        "emailAddress",
+        "name",
+        "givenName",
+        "familyName",
+        "telephoneNumber",
+        "tel",
+        "phone",
+        "streetAddress",
+        "postalCode",
+        "country",
+        "creditCardNumber",
+        "URL"
+      ],
+      "valueAliases": {
+        "emailAddress": "email",
+        "tel": "telephoneNumber",
+        "phone": "telephoneNumber"
+      },
+      "description": "Content type for autofill (binding supported). The enum is the set of tokens at least one platform actually maps: iOS to .textContentType, web to the autoComplete attribute, Android to the keyboard type. `email` (not emailAddress) and `telephoneNumber` (not tel) are the canonical spellings — the web converter only matches those two, so the alternates are normalized before conversion. Tokens no platform maps are deliberately absent: declaring UIKit's full UITextContentType list would enumerate values that cannot reach any output."
     },
     "secure": {
       "type": [
@@ -1663,21 +1709,21 @@
     },
     "accessoryBackground": {
       "type": "string",
-      "description": "Input accessory background - hex string or color name from colors.json",
+      "description": "Input accessory toolbar background - hex string or color name from colors.json. UIKit only: read by SJUITextField's accessory toolbar; SwiftUI has no input-accessory surface.",
       "platform": "swift",
-      "mode": "swiftui"
+      "mode": "uikit"
     },
     "accessoryTextColor": {
       "type": "string",
-      "description": "Input accessory text color - hex string or color name from colors.json",
+      "description": "Input accessory toolbar text color - hex string or color name from colors.json. UIKit only (see accessoryBackground).",
       "platform": "swift",
-      "mode": "swiftui"
+      "mode": "uikit"
     },
     "doneText": {
       "type": "string",
-      "description": "Done button text",
+      "description": "Text of the input accessory toolbar's Done button. UIKit only (see accessoryBackground).",
       "platform": "swift",
-      "mode": "swiftui"
+      "mode": "uikit"
     },
     "tintColor": {
       "type": "string",
@@ -1691,9 +1737,7 @@
           "type": "string",
           "description": "Caret color - hex string or color name from colors.json"
         }
-      },
-      "deprecated": "swiftui",
-      "deprecation_note": "SwiftUI cannot style the caret (iOS 17 has partial .tint API)."
+      }
     },
     "onTextChange": {
       "type": "string",
@@ -1701,24 +1745,36 @@
     },
     "autocapitalizationType": {
       "type": "string",
-      "description": "Auto-capitalization type"
+      "enum": [
+        "none",
+        "words",
+        "sentences",
+        "allCharacters",
+        "characters"
+      ],
+      "valueAliases": {
+        "characters": "allCharacters"
+      },
+      "description": "Auto-capitalization type. UIKit's vocabulary, honoured on every platform (.textInputAutocapitalization / KeyboardCapitalization / the HTML autocapitalize attribute). `characters` is an accepted alias spelling of allCharacters."
     },
     "autocorrectionType": {
       "type": "string",
-      "description": "Auto-correction type"
-    },
-    "spellCheckingType": {
-      "type": "string",
-      "description": "Spell checking type",
-      "platform": "swift",
-      "deprecated": "swift",
-      "deprecation_note": "Compose does not expose spell-checking control."
-    },
-    "keyboardAppearance": {
-      "type": "string",
-      "description": "Keyboard appearance: dark, light",
-      "deprecated": "kotlin",
-      "deprecation_note": "Compose keyboard appearance is system-controlled."
+      "enum": [
+        "default",
+        "yes",
+        "no",
+        "on",
+        "off",
+        "true",
+        "false"
+      ],
+      "valueAliases": {
+        "on": "yes",
+        "true": "yes",
+        "off": "no",
+        "false": "no"
+      },
+      "description": "Auto-correction type. UIKit's vocabulary; `on`/`true` and `off`/`false` are accepted alias spellings of yes/no. `default` means \"leave it to the platform\" — web deliberately emits nothing for it."
     },
     "clearButtonMode": {
       "type": "string",
@@ -1846,12 +1902,6 @@
       "description": "Hide other elements while the field is focused.",
       "platform": "swift",
       "mode": "swiftui"
-    },
-    "placeholderColor": {
-      "type": "string",
-      "description": "Deprecated on swift.",
-      "deprecated": "swift",
-      "deprecation_note": "SwiftUI TextField placeholder cannot be color-styled."
     }
   },
   "TextView": {
@@ -1892,7 +1942,7 @@
     },
     "hintAttributes": {
       "type": "object",
-      "description": "Hint styling attributes"
+      "description": "Hint styling attributes. The nested keys win over the flat spellings (hintColor / hintFont / hintFontSize): a bag scoped to the hint is the more specific statement. That is the ordinary cascade rule and what all four readers do (rjui label_converter, kjui text_component, sjui Label and SelectBox) - it was unwritten until 2026-08-05, when the one converter that had it backwards was found by contradicting its own comment."
     },
     "hideOnFocused": {
       "type": "boolean",
@@ -1985,7 +2035,15 @@
     },
     "lineBreakMode": {
       "type": "string",
-      "description": "Line break mode"
+      "enum": [
+        "Char",
+        "Clip",
+        "Word",
+        "Head",
+        "Middle",
+        "Tail"
+      ],
+      "description": "Truncation mode. Same vocabulary as Label.lineBreakMode — the two were the same concept declared twice, once enumerated and once as a bare string."
     },
     "dataDetectorTypes": {
       "type": "string",
@@ -2001,7 +2059,41 @@
     },
     "keyboardType": {
       "type": "string",
-      "description": "Keyboard type"
+      "enum": [
+        "default",
+        "asciiCapable",
+        "alphabet",
+        "number",
+        "numberPad",
+        "decimal",
+        "decimalPad",
+        "phone",
+        "phonePad",
+        "email",
+        "emailAddress",
+        "URL",
+        "webURL",
+        "webSearch",
+        "search",
+        "namePhonePad",
+        "twitter",
+        "text",
+        "numeric",
+        "numbersAndPunctuation"
+      ],
+      "valueAliases": {
+        "alphabet": "asciiCapable",
+        "numberPad": "number",
+        "decimalPad": "decimal",
+        "phonePad": "phone",
+        "numeric": "phone",
+        "numbersAndPunctuation": "number",
+        "emailAddress": "email",
+        "webURL": "URL",
+        "search": "webSearch",
+        "text": "default"
+      },
+      "description": "Soft-keyboard type. The canonical token of each pair is the one all three converters accept: `number` rather than UIKit's numberPad (Compose only matches `number` and would fall back to a plain text keyboard), likewise decimal/phone/email. `namePhonePad` and `twitter` reach iOS only; the other platforms fall back to their default keyboard."
     },
     "onTextChange": {
       "type": "string",
@@ -2097,10 +2189,11 @@
       "platform": "react"
     },
     "edgeInset": {
-      "type": "string",
-      "description": "Deprecated on kotlin.",
-      "deprecated": "kotlin",
-      "deprecation_note": "Compose Text has no edgeInset; use padding* instead."
+      "type": [
+        "number",
+        "array"
+      ],
+      "description": "The UIKit spelling of containerInset (content inset). Same accepted shapes: a single number, or an array of 1/2/4 numbers. Was declared deprecated on kotlin (\"Compose Text has no edgeInset\"); retracted 2026-08-05 because Label.edgeInset maps to .padding() on Compose in both the codegen and the dynamic renderer. Unimplemented on the Compose TextView path, not impossible."
     }
   },
   "EditText": {
@@ -2151,10 +2244,6 @@
         "hilightColor"
       ]
     },
-    "hilightColor": {
-      "type": "string",
-      "description": "Highlight color - hex string or color name from colors.json (typo alias)"
-    },
     "tapBackground": {
       "type": "string",
       "description": "Background when tapped - hex string or color name from colors.json"
@@ -2259,7 +2348,10 @@
         "Left",
         "Right"
       ],
-      "description": "Content mode (binding supported)"
+      "valueAliases": {
+        "ScaleToFill": "fill"
+      },
+      "description": "Content mode (binding supported). ScaleToFill is a declared synonym of fill (the stretch — see attribute_semantics.json#semantics.image); the normalizer folds it, fixtures are generated for the canonical spelling only."
     },
     "renderingMode": {
       "type": "string",
@@ -2443,14 +2535,6 @@
       ],
       "description": "Hint text color - hex string or color name from colors.json (binding supported)"
     },
-    "text": {
-      "type": [
-        "string",
-        "binding"
-      ],
-      "description": "Display text (binding supported)",
-      "platform": "swift"
-    },
     "items": {
       "type": [
         "array",
@@ -2481,8 +2565,10 @@
         "binding"
       ],
       "description": "Selected item value (two-way binding)",
-      "platform": "swift",
-      "mode": "uikit"
+      "platform": [
+        "swift",
+        "kotlin"
+      ]
     },
     "selectedDate": {
       "type": [
@@ -2500,7 +2586,10 @@
         "dateAndTime",
         "countDown"
       ],
-      "description": "Date picker mode"
+      "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."
     },
     "datePickerStyle": {
       "type": "string",
@@ -2807,10 +2896,6 @@
       "platform": "swift",
       "mode": "uikit"
     },
-    "onToggle": {
-      "type": "binding",
-      "description": "Toggle handler function - binding only (@{functionName}). Alias of onValueChange."
-    },
     "onValueChange": {
       "type": "binding",
       "description": "Value change handler - binding only (@{functionName})",
@@ -2854,9 +2939,7 @@
     },
     "trackTintColor": {
       "type": "string",
-      "description": "Deprecated on swift.",
-      "deprecated": "swift",
-      "deprecation_note": "SwiftUI Toggle uses unified tint only."
+      "description": "Colour of the switch track - hex string or color name from colors.json. Deprecation retracted with the Slider pair; a SwiftUI Toggle is not limited to a unified tint any more than Progress is."
     }
   },
   "Toggle": {
@@ -2879,25 +2962,21 @@
     },
     "tintColor": {
       "type": "string",
-      "description": "Tint color - hex string or color name from colors.json"
+      "description": "Accent color of the SELECTED segment - a background fill on ios/web, the indicator on Compose. Hex string or color name from colors.json"
     },
-    "normalColor": {
-      "type": [
-        "string",
-        "binding"
-      ],
-      "description": "Normal state color - hex string or color name from colors.json (binding supported)",
-      "platform": "swift",
-      "mode": "swiftui"
+    "fontColor": {
+      "type": "string",
+      "description": "Label color of the UNSELECTED segments - hex string or color name from colors.json",
+      "aliases": [
+        "normalColor"
+      ]
     },
-    "selectedColor": {
-      "type": [
-        "string",
-        "binding"
-      ],
-      "description": "Selected state color - hex string or color name from colors.json (binding supported)",
-      "platform": "swift",
-      "mode": "swiftui"
+    "selectedFontColor": {
+      "type": "string",
+      "description": "Label color of the selected segment, falling back to fontColor - hex string or color name from colors.json",
+      "aliases": [
+        "selectedColor"
+      ]
     },
     "valueChange": {
       "type": "string",
@@ -2929,37 +3008,23 @@
       "description": "Current value (binding for two-way)",
       "binding_direction": "two-way"
     },
-    "minValue": {
-      "type": [
-        "number",
-        "binding"
-      ],
-      "description": "Minimum value (binding supported)"
-    },
     "minimum": {
       "type": [
         "number",
         "binding"
       ],
-      "description": "Minimum value (alias for minValue) (binding supported)",
+      "description": "Minimum value (binding supported). `minValue` / `minimumValue` are accepted alias spellings.",
       "aliases": [
         "minimumValue",
         "minValue"
       ]
     },
-    "maxValue": {
-      "type": [
-        "number",
-        "binding"
-      ],
-      "description": "Maximum value (binding supported)"
-    },
     "maximum": {
       "type": [
         "number",
         "binding"
       ],
-      "description": "Maximum value (alias for maxValue) (binding supported)",
+      "description": "Maximum value (binding supported). `maxValue` / `maximumValue` are accepted alias spellings.",
       "aliases": [
         "maximumValue",
         "maxValue"
@@ -2995,15 +3060,11 @@
     },
     "progressTintColor": {
       "type": "string",
-      "description": "Deprecated on swift.",
-      "deprecated": "swift",
-      "deprecation_note": "SwiftUI Slider uses unified tint only."
+      "description": "Colour of the filled portion of the track - hex string or color name from colors.json. Was declared deprecated on swift (\"SwiftUI Slider uses unified tint only\"); retracted 2026-08-05 because Progress, also SwiftUI, maps the same attribute to .tint(). Unimplemented on the Slider path, not impossible."
     },
     "trackTintColor": {
       "type": "string",
-      "description": "Deprecated on swift.",
-      "deprecated": "swift",
-      "deprecation_note": "SwiftUI Slider uses unified tint only."
+      "description": "Colour of the unfilled track - hex string or color name from colors.json. Deprecation retracted with progressTintColor: SwiftUI Progress reaches the same result through .background()."
     }
   },
   "Progress": {
@@ -3137,15 +3198,29 @@
     "gradient": {
       "type": "array",
       "description": "Gradient colors",
-      "platform": "swift",
-      "mode": "uikit"
+      "platform": "swift"
     },
     "gradientDirection": {
-      "type": "string",
-      "description": "Gradient direction",
-      "platform": "swift",
-      "mode": "uikit"
-    },
+        "type": "string",
+        "enum": [
+          "Vertical",
+          "Horizontal",
+          "Oblique",
+          "LeftToRight",
+          "TopToBottom",
+          "Diagonal",
+          "RightToLeft",
+          "BottomToTop"
+        ],
+        "valueAliases": {
+          "LeftToRight": "Horizontal",
+          "TopToBottom": "Vertical",
+          "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.",
+        "platform": "swift"
+      },
     "locations": {
       "type": "array",
       "description": "Gradient color stop locations",
@@ -3154,7 +3229,7 @@
     },
     "safeAreaInsetPositions": {
       "type": "array",
-      "description": "Safe area inset positions (SafeAreaView only)",
+      "description": "Which edges reserve the safe area. Declared here as well as on SafeAreaView on purpose: SafeAreaView is its own definition section and does not inherit View's, and every platform honours the attribute on a PLAIN view too (sjui base_view_converter.rb#apply_safe_area_insets_to_bag runs for every component; rjui view_converter.rb#safe_area_edges emits env(safe-area-inset-*) padding). The two declarations are the same concept reaching two routing paths, not a duplicate.",
       "items": {
         "type": "string",
         "enum": [
@@ -3216,15 +3291,11 @@
     "_comment": "Sparse by design, not an alias: only the Kotlin dynamic runtime dispatches CircleView (DynamicCircleViewComponent, CircleShape clip) - P18 audit 2026-08-01. Everything it renders beyond child/children comes from common. component_metadata.json carries the per-platform truth.",
     "child": {
       "type": "array",
-      "description": "Child component(s)",
-      "platform": "swift",
-      "mode": "uikit"
+      "description": "Child component(s)"
     },
     "children": {
       "type": "array",
-      "description": "Child components (alias for child)",
-      "platform": "swift",
-      "mode": "uikit"
+      "description": "Child components (alias for child)"
     }
   },
   "ScrollView": {
@@ -3579,7 +3650,7 @@
     },
     "scrollTo": {
       "type": "binding",
-      "description": "PassthroughSubject<Int, Never> for programmatic scrolling to cell index"
+      "description": "Binding that requests a programmatic scroll. The declared DATA CLASS is a plain value — `String` when cellIdProperty is set (scroll to that cell id), `Int` otherwise (scroll to that index). It is deliberately NOT `PassthroughSubject<Int, Never>`, which this description used to prescribe: PassthroughSubject is a Combine type, and naming a Swift transport in the cross-platform SSoT is what made consumers write it into their data section, where kjui's map_to_kotlin_type passes unknown classes through verbatim and the Kotlin build dies on it. How the request is delivered is each platform's own business — iOS wraps the value in a publisher so a repeated send re-scrolls, Compose reads the String directly, web keys a useEffect on it. STATUS 2026-08-05, after B landed the derivation (jsonui-cli 8c41e3e): the CODEGEN side of all three platforms now takes the plain value — sjui emits `.onChange(of: data.<prop>)` with no publisher and no throttle, Compose keys a LaunchedEffect on it, web a useEffect. The remaining gap is the SwiftUI DYNAMIC renderer: CollectionConverter.swift:127 still resolves the binding as `data[propName] as? PassthroughSubject<Int, Never>` and gets nil for a plain value, so the scroll silently never fires there (it does not crash, it does nothing). Consequence for fixtures: a Collection.scrollTo fixture is now declarable and no longer kills the Kotlin build, and Collection.scrollAnchor is measurable on the codegen path — but ios codegen and ios dynamic will disagree until the dynamic resolver accepts the value, so expect a parity finding there rather than a render failure. Owner of the remainder: the SwiftJsonUI dynamic lane. Note also that the vendored CollectionAttributes.swift still carries the old publisher wording in its doc comment; it is generated from this description and will pick the correction up at the next re-vendor."
     },
     "scrollAnchor": {
       "type": "string",
@@ -3588,7 +3659,8 @@
         "center",
         "bottom"
       ],
-      "description": "Anchor point for scroll target (default: bottom)"
+      "default": "bottom",
+      "description": "Anchor point for the scrollTo target. Measured 2026-08-05: ios (sjui collection_converter.rb:1138), web (rjui build_command.rb:768) and the Compose GRID path (kjui collection_component.rb:313) all fall back to bottom, so bottom is the declared default. The Compose LIST path emits no anchor offset unless the attribute is explicitly declared, which lands the target at top - that is a divergence in that one path, not a second default."
     },
     "defaultScrollAnchor": {
       "type": "string",
@@ -3624,17 +3696,16 @@
       "description": "Enable/disable scrolling (binding supported)"
     },
     "onItemAppear": {
-      "type": "callback",
-      "description": "Called with the cell index (Int) when a cell appears on screen. Use for pagination by checking index against total count in ViewModel."
+      "type": [
+        "string",
+        "binding"
+      ],
+      "description": "Called with the cell index (Int) when a cell appears on screen. Use for pagination by checking index against total count in ViewModel. Declared `binding` because that is what a layout actually carries: the author writes `@{handlerName}`, a STRING, and every reader matches it as one (kjui collection_component.rb:364 `json_data['onItemAppear'].match(/@\\{([^}]+)\\}/)`, and the binding validators infer `((Int) -> Unit)?` from that spelling). It was `type: \"callback\"` — the only callback-typed attribute in the whole SSoT — and attr-codegen skips that type as \"function-valued, not extractable from JSON\". True of a function; not true of the `@{...}` string a JSON layout can hold, so the attribute had no row in any generated table and no platform could read it typed (2026-08-05, plan 49-E, raised by A)."
     },
     "currentPage": {
       "type": "binding",
       "description": "Current page index for paging collections (binding supported)"
     },
-    "onPageChanged": {
-      "type": "callback",
-      "description": "Called with the new page index (Int) when the user swipes to a different page"
-    },
     "containerInset": {
       "type": "array",
       "description": "Container-level insets applied outside of individual cells.",
@@ -3698,16 +3769,12 @@
         "selected_icon"
       ]
     },
-    "selected_icon": {
-      "type": "string",
-      "description": "Selected icon name (underscore alias)"
-    },
     "checked": {
       "type": [
         "boolean",
         "binding"
       ],
-      "description": "Initial checked state (can be binding)"
+      "description": "Seeds the group's INITIAL selection — it is not the live state, and it is not two-way. The state a radio group carries is `selectedValue`; `checked` only says which option starts selected when nothing else has said. Precedence, and all three platforms implement it in this order: a BOUND `selectedValue` wins outright (the group's own two-way state), then a LITERAL `selectedValue` (a group-level statement naming the starting option), then this option's `checked`. So a radio group that binds selectedValue ignores `checked` entirely, which is what stops a seed from freezing a group that the user can no longer change. The bound form of `checked` seeds the glyph rather than the state, since a property initialiser cannot read the data map: it selects only while the group has made no choice yet (sjui radio_converter.rb:88-103, and the same rule in RadioConverter.swift). CONTRAST with CheckBox.checked and Switch.checked, which look identical and are not: those ARE the control's state and carry binding_direction two-way. A radio has no state of its own — the group does. Declared 2026-08-05 (plan 49-E) from the implementations; the previous description said only \"Initial checked state\", which was true and told nobody what happens when both are declared."
     },
     "value": {
       "type": "any",
@@ -3922,6 +3989,18 @@
     "_comment": "Component alias of CheckBox. Resolved by the L1 normalizer type rewrite and by every validator/codegen consumer - do not add attribute copies here."
   },
   "Indicator": {
+    "animating": {
+      "type": [
+        "boolean",
+        "binding"
+      ],
+      "default": true,
+      "description": "Whether the indicator is spinning. Defaults to true: an Indicator with nothing declared animates. `false` stops it, and hidesWhenStopped then decides whether the stopped indicator keeps its space or collapses out of the layout \u2014 which is why hidesWhenStopped is only ever read on this branch (sjui indicator_converter.rb:23, kjui indicator_component.rb:13).",
+      "platform": [
+        "swift",
+        "kotlin"
+      ]
+    },
     "indicatorStyle": {
       "type": "string",
       "enum": [
@@ -4070,8 +4149,8 @@
       "platform": "swift"
     },
     "sandbox": {
-      "type": "string",
-      "description": "Iframe sandbox attribute",
+      "type": "boolean",
+      "description": "Iframe sandboxing kill-switch. `false` emits no sandbox attribute at all; otherwise the permission list is built from the other Web attributes (javaScriptEnabled, javaScriptCanOpenWindowsAutomatically, allowPopupsToEscapeSandbox, allowModals, ...) rather than from a value written here.",
       "platform": "react"
     },
     "allow": {
@@ -4091,7 +4170,10 @@
     },
     "safeAreaInsetPositions": {
       "type": "array",
-      "description": "Safe area edges",
+      "description": "Safe area edges. `edges` is an accepted alias spelling: the Compose SafeAreaView builder reads it (kjui compose_builder.rb:722 `json_data['edges'] || json_data['safeAreaInsetPositions']`) while no declaration named it, so iOS and web silently ignored a layout that used it. Declaring the alias normalizes it to the canonical spelling and makes it reach all three platforms.",
+      "aliases": [
+        "edges"
+      ],
       "items": {
         "type": "string",
         "enum": [
@@ -4195,10 +4277,6 @@
       "default": true,
       "description": "Whether to show tab labels (default: true)"
     },
-    "onTabChange": {
-      "type": "binding",
-      "description": "Tab change handler - binding only (@{functionName})"
-    },
     "onValueChange": {
       "type": [
         "string",

package/data/attribute_semantics.json

@@ -6,25 +6,41 @@
     "border": {
       "widthAlone": "no-draw",
       "styleAlone": "no-draw",
-      "ruling": "A border is drawn only when BOTH borderWidth and borderColor are declared; borderWidth alone renders nothing on every platform — there is no default border color (2026-08-03 user ruling; supersedes the transient gray-default direction of d2c8628, unified across toolchains in 3e87b96). borderStyle alone likewise renders nothing: it styles a border the width+color pair requests, it never summons one (2026-08-03 user ruling #2). NOTE: TextField.borderStyle is a DIFFERENT attribute (UIKit text-field chrome: roundedRect/line/bezel/none) and is outside this entry.",
+      "ruling": "A border is drawn only when BOTH borderWidth and borderColor are declared; borderWidth alone renders nothing on every platform — there is no default border color (2026-08-03 user ruling; supersedes the transient gray-default direction of d2c8628, unified across toolchains in 3e87b96). borderColor alone renders nothing for the same reason — the pair is what requests a border, and neither half requests one on its own (measured 2026-08-04, plan 34 re-measure: 0 px against the control on all three platforms; the android codegen does emit on the attribute's PRESENCE, which is a codegen-stage fact plan 41 tracks, not a rendered difference). borderStyle alone likewise renders nothing: it styles a border the width+color pair requests, it never summons one (2026-08-03 user ruling #2). NOTE: TextField.borderStyle is a DIFFERENT attribute (UIKit text-field chrome: roundedRect/line/bezel/none) and is outside this entry. The `__*_with_border` fixtures are the paired variants (borderStyle declared ALONGSIDE borderWidth + borderColor) that plan 49 added once three lanes had implemented the attribute with nothing measuring it — the lone-style fixtures above stay inert and keep testing the AND rule. `solid_with_border` is inert for a different reason from the lone ones: solid is the declared default of borderStyle, so stating it explicitly draws the same picture as omitting it (codegen_effect calls this class `value-is-default`). dashed/dotted are the two that must differ from the control. If the 3PF measurement comes back split rather than uniform, the honest record is a per-platform map like skinIdioms uses, not a forced uniform verdict: plan 34 caught ios emitting identical text for solid and dashed (C2/presence-only), and B/C/A implemented the three platforms separately in this wave. MEASURED 2026-08-05 (conformance-mobile run 30950551601 @ 5aada98), and the split the paragraph above anticipated is what happened: dashed and dotted are active on android and web and INERT on ios — the three borderStyle values render pixel-identical to each other and to the control on ios, which is the same symptom plan 34 recorded at the codegen stage (sjui emitting the same text for solid and dashed, C2/presence-only). They are therefore recorded as per-platform maps, not forced to a uniform verdict. This records today's reality; it does not bless it. If ios is supposed to draw a dashed border, the entry moves to uniformly-active once it does. solid_with_border stays uniformly-inert on all three because solid is borderStyle's declared default. RESOLVED 2026-08-05 on run 30990560599: ios draws both dashed and dotted, so the per-platform split is folded back to uniformly-active. The gap was never in sjui's codegen — that emitted StrokeStyle from dc35e82 — but in the SwiftUI dynamic renderer's applyBorder, which stroked with lineWidth only and so drew every style as solid. Recorded because the shape recurs: a codegen and a dynamic path disagreeing looks exactly like a platform not implementing an attribute.",
       "observable": {
         "common/borderWidth__static": "uniformly-inert",
+        "common/borderColor__static": "uniformly-inert",
         "common/borderStyle__solid": "uniformly-inert",
         "common/borderStyle__dashed": "uniformly-inert",
-        "common/borderStyle__dotted": "uniformly-inert"
+        "common/borderStyle__dotted": "uniformly-inert",
+        "common/borderStyle__solid_with_border": "uniformly-inert",
+        "common/borderStyle__dashed_with_border": "uniformly-active",
+        "common/borderStyle__dotted_with_border": "uniformly-active"
+      }
+    },
+    "highlight": {
+      "highlightedAlone": "no-draw",
+      "highlightBackgroundAlone": "no-draw",
+      "ruling": "The highlighted appearance is drawn only when BOTH `highlighted` and a highlight colour are declared — the same pair-required shape as `border`, and ruled the same way. `highlighted: true` alone swaps the background to a colour that was never given, so nothing changes; `highlightBackground` alone names a colour for a state the view is never in. Every codegen already treats them as a pair (kjui modifier_builder.rb:490 combines highlight_cond with highlight_bg; sjui apply_highlighted_to_bag does the same), so a single-attribute fixture measures the absence of the companion rather than the converter. Established by measurement, not assumption: plan 41's paired probe carried View.highlighted as its one PROVISIONAL entry, and giving it `highlightBackground` made the ios/C0 and android/C0 findings disappear — the converters were correct and the fixture was missing the other half. This entry retires that PROVISIONAL: the pairing is now derived from the ledger like every other family (2026-08-05, plan 49-E, on plan 41's evidence). MEASURED 2026-08-05 (same run): web is active — A routed the highlight background through an inline style instead of a losing Tailwind class — while ios and android are still inert, so the verdict is recorded per platform. NOTE for anyone tidying this block: `common/highlightBackground__static` carries no control in the generated fixture set, so it is never compared and its verdict here is not checked against anything. It must NOT be deleted regardless — companions.py derives the pairing from this topic's `observable` KEYS, and a topic with fewer than two members stops producing companions at all. Same permanent-unverifiable note as networkImage's loadingImage applies to `common/highlightBackground__static`: rules.py scopes it to the paired form, so the bare fixture has no control and the entry can never be checked at the render stage. It stays because companions.py derives the View.highlighted pairing from these keys — deleting it would stop the pairing, not just the check. MEASURED 2026-08-06 on run 31068716186: android is now active (152,960 px) — the highlighted+highlightBackground pair landed on android; ios remains inert.",
+      "observable": {
+        "View/highlighted__true": {
+          "ios": "inert",
+          "android": "active",
+          "web": "active"
+        },
+        "common/highlightBackground__static": "uniformly-inert"
       }
     },
     "image": {
       "defaultContentMode": "fit",
       "fill": "stretch",
-      "ruling": "2026-08-03 user rulings: (a) the default contentMode is fit on every platform — web's implicit cover default was drift (fixed in rjui, 22d96b4); (b) fill is the stretch (scaleToFill synonym) — AspectFill is the crop. All three platforms now implement the full mapping including the positional modes (unscaled + aligned + cropped; sjui/kjui/SwiftJsonUI/KotlinJsonUI, 33 wave). Observables: fit-valued fixtures equal the default rendering (uniformly inert); fill/scaleToFill differ from it everywhere (uniformly active). Verified on the 33 round-3 measurement.",
+      "ruling": "2026-08-03 user rulings: (a) the default contentMode is fit on every platform — web's implicit cover default was drift (fixed in rjui, 22d96b4); (b) fill is the stretch (scaleToFill synonym) — AspectFill is the crop. All three platforms now implement the full mapping including the positional modes (unscaled + aligned + cropped; sjui/kjui/SwiftJsonUI/KotlinJsonUI, 33 wave). Observables: fit-valued fixtures equal the default rendering (uniformly inert); fill/scaleToFill differ from it everywhere (uniformly active). Verified on the 33 round-3 measurement. REGRESSION on run 30990560599, recorded as measured and NOT as a semantics change: fill and scaleToFill went inert on ios between round 3 (44,640 px against the control) and round 4 (0 px), while the fixture declaration and the control image are byte-identical across the two runs — so the picture moved, not the probe. SwiftJsonUI fe74662 rewrote ImageViewConverter's declaredSize guard from `component.width/height` to `component.declaredWidth/declaredHeight`, and the stretch is applied through that size; it landed after round 3 and is in round 4. This entry is expected to fall back to uniformly-active once that is fixed — it is a progress meter, not a ruling that ios stretches differently. RESOLVED 2026-08-06 on run 31068716186 (SwiftJsonUI checkout 8b4c1b3): ios draws the stretch again — 44,640 px against the control, the exact round-3 magnitude — so both fill and scaleToFill fold back to uniformly-active, as the round-5 prediction registered. The per-platform split lived for exactly one round, which is what a progress meter is for.",
       "observable": {
         "Image/contentMode__fit": "uniformly-inert",
         "Image/contentMode__aspectfit": "uniformly-inert",
         "NetworkImage/contentMode__fit": "uniformly-inert",
         "NetworkImage/contentMode__aspectfit": "uniformly-inert",
-        "Image/contentMode__fill": "uniformly-active",
-        "Image/contentMode__scaletofill": "uniformly-active"
+        "Image/contentMode__fill": "uniformly-active"
       }
     },
     "textView": {
@@ -43,12 +59,19 @@
     },
     "networkImage": {
       "noSrc": "defaultImage",
-      "ruling": "2026-08-03 user ruling: with no src, NetworkImage displays defaultImage; while loading it displays the first of hint/placeholder/loadingImage; on error it displays errorImage, falling back to defaultImage. Implemented on all platforms in the 33 wave (KotlinJsonUI defaultImage read + Coil fallback chain; ios placeholder no longer collapses over defaultImage; rjui defaultImage prop + template state machine). State-image fixtures use the DISTINCT conformance_sample_alt asset, so a hijacked no-src state renders visibly — the uniformly-inert observables verify the chain end-to-end.",
+      "ruling": "2026-08-03 user ruling: with no src, NetworkImage displays defaultImage; while loading it displays the first of hint/placeholder/loadingImage; on error it displays errorImage, falling back to defaultImage. Implemented on all platforms in the 33 wave (KotlinJsonUI defaultImage read + Coil fallback chain; ios placeholder no longer collapses over defaultImage; rjui defaultImage prop + template state machine). State-image fixtures use the DISTINCT conformance_sample_alt asset, so a hijacked no-src state renders visibly — the uniformly-inert observables verify the chain end-to-end. MEASURED 2026-08-05 (same run): placeholder is now active on all three — the conformance host never completes a network load, so the loading state persists and the placeholder is what the fixture shows; inert was the wrong expectation for it and the contract is updated. errorImage and loadingImage are active on android and inert on ios (they are out of scope on web), recorded per platform. OPEN QUESTION, deliberately not resolved by this entry: under the ruling above a state image should only appear in its own state, so android rendering a difference for errorImage — when the fixture never errors — reads like android showing a state image it should not, i.e. a defect rather than a contract. Recorded as measured because the gate cannot be satisfied by a ledger reason, but the android/ios split here needs adjudicating by the lanes that own those runtimes before it is treated as intended. NOTE on loadingImage's entry: rules.py deliberately gives that fixture no control (an in-flight image has no duration, so the loading face cannot be photographed however the fixture is shaped), which means the contract here is PERMANENTLY unverifiable at the render stage and will show up every run under \"could not be verified\". It is kept because the codegen probe still measures the spelling on both mobile converters — the entry states what the platforms should do, and the render stage simply is not the instrument that can check it. MEASURED 2026-08-06 on run 31068716186: the android/ios pair REVERSED — errorImage is now active on ios (631 px: ios draws the error face) and inert on android (0 px), and placeholder went inert on android in the same run. ios moving to active is the OPEN QUESTION's suspected defect being adjudicated by implementation; android going dark on BOTH state images at once reads as an android-side regression of the state-image chain, assigned to G+C (2026-08-06). placeholder's contract records the split as a progress meter and returns to uniformly-active when the android chain is fixed; errorImage's contract is deliberately left at its pre-run-5 value so the gate keeps a standing violation pointing at the open investigation — a contract edit would file the regression as intended. RESOLVED 2026-08-06 on run 31080217407: G's decisive-network interceptor made the error state deterministic, and errorImage measures ACTIVE on both mobile platforms (web stays out of scope) — the deliberately-stale contract folds to uniformly-active and the standing violation retires. placeholder's android:inert row REMAINS measured reality on run 6 and is consistent with the same interceptor: a load that now completes deterministically ends the loading state, so the loading face never shows on android — whether ios/web should match that is G+C's open half of #19, and the placeholder row stays a meter until they rule.",
       "observable": {
-        "NetworkImage/placeholder__static": "uniformly-inert",
+        "NetworkImage/placeholder__static": {
+          "ios": "active",
+          "android": "inert",
+          "web": "active"
+        },
         "NetworkImage/hint__static": "uniformly-inert",
-        "NetworkImage/errorImage__static": "uniformly-inert",
-        "NetworkImage/loadingImage__static": "uniformly-inert"
+        "NetworkImage/errorImage__static": "uniformly-active",
+        "NetworkImage/loadingImage__static": {
+          "ios": "inert",
+          "android": "active"
+        }
       }
     },
     "margins": {
@@ -75,7 +98,7 @@
     },
     "skinIdioms": {
       "demarcation": "control chrome may differ per platform; the DIFFERENCE ITSELF is contract-pinned",
-      "ruling": "2026-08-03 campaign adjudication: platform-owned control chrome is a legitimate difference, but only in its adjudicated SHAPE — the observable pins each accepted divergence as an expected-difference pattern, so both disappearing and mutating fail the gate. Members: Blur effectStyle (android material variants differ visibly, ios materials render alike on flat surfaces per the 31 saturation analysis, web CSS blur is single-variant), TextField.borderStyle (UIKit field chrome — each platform draws its own; web renders none for the UIKit-only bezel variants), TabView.showLabels (ios hides tab labels, android/web keep the labeled bar). The tabview glyph-source family is the codegen-side counterpart, pinned permanently in codegen_parity.json (2026-08-03 user ruling).",
+      "ruling": "2026-08-03 campaign adjudication: platform-owned control chrome is a legitimate difference, but only in its adjudicated SHAPE — the observable pins each accepted divergence as an expected-difference pattern, so both disappearing and mutating fail the gate. Members: Blur effectStyle (android material variants differ visibly, ios materials render alike on flat surfaces per the 31 saturation analysis, web CSS blur is single-variant), TextField.borderStyle (UIKit field chrome — each platform draws its own; web renders none for the UIKit-only bezel variants), TabView.showLabels WAS a member on the strength of a `__true` measurement — the DEFAULT value — and left the topic on 2026-08-05 when run 30990560599 measured both values on all three: `true` is inert everywhere (it is the default, so declaring it draws what omitting it draws) and `false` is active everywhere (ios 1491 px, android 8427, web 3019), with the two values distinguishable on every platform. There is no ios-only divergence to pin, so the entry moves to `__false` as a plain uniformly-active fact and the attribute is no longer a skin idiom. The original reading came from comparing the default value against its control, which cannot show what a non-default value does. The tabview glyph-source family is the codegen-side counterpart, pinned permanently in codegen_parity.json (2026-08-03 user ruling).",
       "observable": {
         "Blur/effectStyle__extralight": {
           "ios": "inert",
@@ -117,11 +140,7 @@
           "android": "active",
           "web": "inert"
         },
-        "TabView/showLabels__true": {
-          "ios": "active",
-          "android": "inert",
-          "web": "inert"
-        }
+        "TabView/showLabels__false": "uniformly-active"
       }
     },
     "progressValue": {
@@ -132,6 +151,91 @@
       "observable": {
         "Progress/progress__static": "uniformly-active"
       }
+    },
+    "segmentLabelColors": {
+      "roleModel": "fontColor is the unselected label, selectedFontColor the selected one (falling back to fontColor), tintColor the SELECTED segment's accent — drawn as a background fill on ios/web and as the TabRow indicator on Compose",
+      "ruling": "2026-08-04 orchestrator adjudication (38, consumer field report): a Segment whose selected background is a brand colour had no way to declare a readable label — web hardcoded the unselected label and treated fontColor as the SELECTED label's fallback, so the name and the role were twisted, and neither spelling was declared for Segment at all. fontColor and selectedFontColor are now declared for Segment on every platform (the IconLabel.selectedFontColor precedent) and carry the roles above: rjui emits the unselected class from fontColor, sjui writes both UISegmentedControl title attributes (.normal and .selected), kjui fills contentColor / selectedContentColor. The swift-only normalColor and selectedColor keep resolving behind the new spellings — they are in live consumer use — and selectedBackground was dropped instead of declared: tintColor already means the selected background and a second spelling for it earns nothing. No activeness observable: the fixtures would need a selected-vs-unselected pair to separate the two roles, which the current single-value shape cannot express.",
+      "tintColorAlignment": "2026-08-04 orchestrator adjudication (42): android used to feed tintColor into the selected LABEL colour, so one declaration painted different things per platform — it now feeds the indicator, which is Compose's selected-state accent (its default is Configuration.Segment.defaultSelectedBackgroundColor). The rendering SHAPE stays platform-native: a filled segment on ios/web, a TabRow indicator on Compose; TabRow has no per-segment background and containerColor is the whole row. Measured before the change: of the two consumer screens declaring Segment colours, the only android one resolved its label colour from selectedColor (which precedes tintColor in the old chain), so no shipped screen changes colour — the missing accent simply appears. indicatorColor was an undeclared second spelling for the same slot and its read was dropped; normalColor / selectedColor became declared aliases of fontColor / selectedFontColor, so every converter reads canonical names only.",
+      "observable": {}
+    },
+    "boundSize": {
+      "unitModel": "a bound size attribute carries a runtime number in layout units: dp on android, points on ios, px on web",
+      "ruling": "2026-08-04 orchestrator adjudication (36, consumer field report): all six size attributes (width, height, minWidth, maxWidth, minHeight, maxHeight) declare \"binding\" in attribute_definitions, so a bound value MUST be honoured on every platform. kjui resolves it to `.height(data.v.dp)` (process_dimension) and sjui to `.frame(height: data.v)` (frame_helper is_binding?); rjui dropped it silently because the value reached the Tailwind arbitrary-value mapper, which returns '' for any string that is not a CSS unit — the declaration produced no class and no inline style, and jui build stayed warning-free. rjui now routes a bound dimension to the inline style as a px template literal, and treats it as an EXPLICIT size for the shrink and explicit-over-bounds rules above. No activeness observable: a bound fixture renders whatever the host viewmodel supplies, so fixture-vs-control cannot separate honouring from ignoring.",
+      "observable": {}
+    },
+    "distribution": {
+      "sizeValues": [
+        "fill",
+        "fillEqually"
+      ],
+      "gapValues": [
+        "equalSpacing",
+        "equalCentering"
+      ],
+      "spacingWins": "an explicit spacing pins the gap; distribution still governs size",
+      "ruling": "2026-08-05 (plan 49-E), raised by F/G and measured across all three toolchains. The vocabulary is UIStackView's, and its four values split into TWO KINDS that the current implementations conflate: `fill` and `fillEqually` distribute SIZE among the children, while `equalSpacing` and `equalCentering` distribute the FREE SPACE between them. fill = children grow to consume the axis, leaving no free space (proportional to their content size); fillEqually = every child gets the SAME size regardless of content; equalSpacing = equal gaps between adjacent children, with no leading or trailing gap; equalCentering = equal centre-to-centre distances. CONSEQUENCE, and this is the part every platform gets wrong today: the two size values are NOT an arrangement. They are `Modifier.weight(1f)` on each child in Compose, `.frame(maxWidth: .infinity)` (or equal weights) in SwiftUI, and `flex-1` in CSS — not Arrangement.* and not justify-content. Mapping `fill` to SpaceBetween/justify-between is precisely backwards: fill means there is no free space left to distribute. MEASURED STATE 2026-08-05 — all three disagree with the canon AND with each other, and each collapses a DIFFERENT pair of values into one output, so no fixture comparing two declared values can tell them apart: android (kjui container_component.rb:129-140) sends fillEqually and equalCentering both to Arrangement.SpaceEvenly; web (rjui view_converter.rb:184-195) sends the same pair both to justify-evenly; ios (sjui view_converter.rb:217,367,383) synthesises identical Spacer sets for equalSpacing and equalCentering, and gives fillEqually between-only spacers, which is space-between rather than equal sizes. `fill` emits nothing on ios (correct by accident) and a space-between arrangement on the other two (wrong). WHY NO GATE CAUGHT IT: --inert-complete asks whether a fixture differs from its CONTROL. Two declared values that both differ from the control but are identical to EACH OTHER pass that check, and android parity passes too because codegen and dynamic collapse them the same way. A value-vs-value comparison is the missing instrument — this is the 'both wrong in the same direction reads as green' shape. SPACING PRECEDENCE: `spacing` and `distribution` are not mutually exclusive and the current Compose behaviour (spacing != null wins outright, distribution never read) is wrong for the size values. An explicit `spacing` pins the GAP, so it overrides the gap that equalSpacing/equalCentering would compute; it says nothing about size, so fill/fillEqually still apply underneath it. Same shape as the size topic's explicit > bounds > fill ordering: the more specific declaration wins the axis it speaks about, and only that axis. No observable entries yet: the fixtures that would prove this need to compare two declared VALUES against each other rather than each against the control, which the current generator does not emit. That instrument is the follow-up this ruling asks for. PER-VALUE MAPPING added 2026-08-05 after A implemented the ruling on web (jsonui-cli 651403e) — recorded so B and C match that choice instead of re-deriving it, which is how the three drifted apart in the first place. The `perValueMapping` block above is the table; the two decisions worth calling out are that the SIZE values are carried to the CHILDREN (a per-child flex/weight instruction, not a container arrangement) and that equalCentering maps to SpaceAround / justify-around rather than SpaceEvenly — SpaceEvenly equalises the GAPS, which is equalSpacing's job, and collapsing the two is precisely the conflation this ruling exists to undo. web landed first and is the reference implementation; ios (sjui view_converter.rb, still synthesising Spacers for both gap values) and android (kjui container_component.rb:129, still mapping four values onto two Arrangements) are outstanding. CHILD SIZE PRECEDENCE, ruled 2026-08-05 after G measured android and found `fill` leaving 60dp unconsumed: an EXPLICIT width/height on the child wins over the size half of distribution, so `fill` and `fillEqually` do not override a declared child size. This is not a new principle — the `size` topic's 2026-08-03 campaign adjudication already ordered explicit > bounds > fill, and distribution's size half IS a fill instruction on the child's axis, so it sits at the bottom of that order like any other. It is also what `spacingWins` says one line up: the more specific declaration wins the axis it speaks about. CONSEQUENCE for the measurement, and the reason this had to be ruled rather than implemented: a fixture whose children declare `width: 40` cannot demonstrate `fill` at all — the 60dp G measured is the correct outcome, not a defect. The fixture has to omit the child dimension on the distribution axis for the attribute to have anything to do. That makes it the fourth case of a fixture shape hiding the attribute it is supposed to measure (after SafeAreaView's matchParent, alignTop/LeftOfView off-screen, and SelectBox with nothing to decorate). android's current implementation is correct as it stands; no three-platform change follows from this. FIRST VALUE-VS-VALUE MEASUREMENT 2026-08-05, on run 30972192150's artifacts once D's fixtures (0035321) and H's --value-discrimination gate (f54d3d5) existed, with control_diff.ignore_bands applied. It confirms the collapse this ruling was written from, platform by platform and by measurement rather than by reading converters: ios draws equalSpacing and equalCentering pixel-identically, android and web draw fillEqually and equalCentering pixel-identically. Three platforms, two different collapsed pairs, nobody agreeing — recorded in `collapsedPairs` so the fix can be checked off per platform. `fill` is ALSO inert against its control on ios while active on android and web, which is not a contradiction of explicitChildSizeWins: the fixture's children carry an explicit width, so no platform should be moving them, and the two that do are moving the TRACK rather than the child. The entry is per-platform for that reason and must not be flattened to uniformly-inert until the fixture drops the child width — at which point fill becomes measurable and this entry gets re-measured, not edited. RE-MEASURED on run 30990560599 after D removed the child width from the size-half fixtures (661bfba). web now distinguishes all four values — A's implementation is the first to satisfy the ruling end to end, and `collapsedPairs` loses its web row. ios still collapses equalSpacing with equalCentering and android now collapses fill with fillEqually (it had been fillEqually with equalCentering): the pair moved because the fixture changed, so android's remaining defect is in the SIZE half, where fill and fillEqually must differ — fill grows children from their content, fillEqually makes them equal regardless of it. `fill` stays inert on ios: with the child width gone the fixture can finally demonstrate it, and ios does not. Run 31068716186 (2026-08-06) measured android fill != fillEqually with both active against the control — C's 27b9b13 (codegen) and G's c7d2dfb (DistributionFillRow) closed the SIZE-half collapse, so the android collapsedPairs row is deleted BY MEASUREMENT, not by edit. The ios pair (equalSpacing == equalCentering) persists: run-5 geometry shows identical child positions and a 32 px gap for both values. Run 31080217407 (2026-08-06) measured ios distinguishing equalSpacing from equalCentering — B (b57e327/3dc3795) and F (e8f99c7) implemented the pinned iosGapConstruction, and the geometry is exactly the canon's: equalCentering shifts the first child right by the half-gap edge spacer (box_a 154 -> 168 px) while every child keeps its declared size (118 px). collapsedPairs is now EMPTY — all three platforms distinguish all four values, which is the state this ruling was written to reach. The empty map stays as the healthy-state marker, same convention as companions.py's emptied PROVISIONAL.",
+      "observable": {
+        "View/distribution__fill": {
+          "ios": "inert",
+          "android": "active",
+          "web": "active"
+        },
+        "View/distribution__fillequally": "uniformly-active",
+        "View/distribution__equalspacing": "uniformly-active",
+        "View/distribution__equalcentering": "uniformly-active"
+      },
+      "perValueMapping": {
+        "fill": {
+          "swiftui": ".frame(maxWidth/maxHeight: .infinity) on each child",
+          "compose": "grow from content — NOT expressible with Modifier.weight (weight(1f) IS fillEqually, the run-4 0px collapse; weight(1f, fill=false) packs by content and is inert). Dedicated measurement pass DistributionFillRow/Column in the base KotlinJsonUI library (c7d2dfb): content size plus an equal split of the leftover, one policy shared by the kjui codegen emit and the dynamic renderer. Device-verified: all 6 value pairs pairwise distinct, explicit child size never grown, spacing gaps pinned",
+          "web": "grow on each child"
+        },
+        "fillEqually": {
+          "swiftui": "equal frames on each child",
+          "compose": "Modifier.weight(1f) with a zero base on each child",
+          "web": "flex-1 min-w-0 min-h-0 on each child"
+        },
+        "equalSpacing": {
+          "swiftui": "Spacer between children only, flush ends (see iosGapConstruction)",
+          "compose": "Arrangement.SpaceBetween",
+          "web": "justify-between"
+        },
+        "equalCentering": {
+          "swiftui": "one Spacer at each end, two between each pair — the count ratio makes the ends half (see iosGapConstruction)",
+          "compose": "Arrangement.SpaceAround",
+          "web": "justify-around"
+        }
+      },
+      "iosGapConstruction": {
+        "equalSpacing": "[child] Spacer [child] Spacer [child] — between-children only, ends flush (justify-between)",
+        "equalCentering": "Spacer [child] Spacer Spacer [child] Spacer Spacer [child] Spacer — ONE spacer at each end, TWO between each pair; free space splits into 2(n-1)+2 equal units, so each end gap is exactly half a between gap (justify-around)",
+        "spacerMinLength": "every synthesised Spacer MUST be Spacer(minLength: 0) — SwiftUI's default minLength pollutes the computed gaps",
+        "spacingWins": "an explicit `spacing` pins the gap and suppresses this synthesis, same as the topic-level spacingWins",
+        "gravityStandsDown": "a declared gap distribution OWNS the free space on its axis: the gravity packing spacers (e.g. the leading spacer right-gravity emits) are NOT emitted alongside it — one extra packing spacer breaks the count ratio and drags equalSpacing toward equalCentering (F, e8f99c7, decision 1)",
+        "edgeSpacerGate": "equalCentering's edge spacers are suppressed ONLY on a wrapContent axis (declared size nil): with no free space a Spacer would expand the container and swallow the trailing padding (the measured round-3 bug). A FIXED numeric size has free space for the ratio and KEEPS its edge spacers — the older widthExpands gate (matchParent/-1/.infinity) was too narrow for it (F, e8f99c7, decision 2)",
+        "note": "Pinned 2026-08-06 (E's proposal, orchestrator-approved: implement this release, B codegen + F dynamic) so the two ios paths emit ONE counting instead of deriving Spacer arithmetic twice — two paths growing children separately is exactly what collapsed distribution's SIZE half before c7d2dfb. Spacer counting suffices because HStack/VStack split free space equally among unconstrained Spacers: the 1:2 end:between count ratio IS space-around's half-gap. No custom Layout, no measurement pass. Acceptance is already wired: when this lands, run 6 must delete collapsedPairs' ios row and turn the two value_discrimination receiving rows stale. Regression-test discipline from F's landing: a partial reversion (between 2->1 only) builds an equal-three-spacer structure the first sample points slipped past — pin BOTH sides of the computed boundary (55 in the 300pt fixture) so partial and full reversion both fail."
+      },
+      "explicitChildSizeWins": "an explicit child width/height beats distribution's size half — size topic's explicit > bounds > fill",
+      "collapsedPairs": {}
+    },
+    "trackColors": {
+      "sliderTrack": "trackTintColor is the UNFILLED track; progressTintColor is the filled one",
+      "switchTrack": "trackTintColor is the OFF track; onTintColor overrides it while on",
+      "notTheView": "neither paints the view's background",
+      "ruling": "2026-08-06 (plan 49-E), asked for by A after ios parity showed three implementations doing three different things. Ruled from the ones that already agree rather than from the name: Compose and web BOTH read trackTintColor as the unfilled Slider track (kjui slider_component.rb:102, rjui slider_converter.rb:85 -> ::-webkit-slider-runnable-track) and BOTH read it as the OFF Switch track with onTintColor winning while on (kjui switch_component.rb:99, rjui switch_converter.rb:30). sjui's SwiftUI Slider says the same thing in its comment. So: Slider = the unfilled side only, the filled side is progressTintColor, and tintColor stays the accent that colours the thumb and the active track when nothing more specific is declared. Switch = the OFF track, and onTintColor is not an alias of it but the state that overrides it. The view's BACKGROUND is wrong on both, and that is what the codegen emits — `.background(color)` paints the whole control, so a declared track colour swallows the component. It is also why the two ios parity findings exist: dynamic reaches the track, codegen reaches the view. RECORDED HERE BECAUSE IT WAS ALREADY CITED: kjui and rjui both carry comments pointing at `slider.trackColors` / `switch.trackColors` in this file, and neither entry existed — the ruling was referenced by three converters and written down nowhere, which is why three implementations could drift while each believed it was following the canon. IOS CONSTRAINT, measured on run 30990560599 and recorded 2026-08-06 after A implemented the ruling: SwiftUI's Toggle exposes no surface for the OFF track, so both ios paths degrade to .tint(), which is visible only while the switch is ON. The fixture declares no isOn and photographs the OFF state, so ios renders identically to its control (0 px) while android and web paint the OFF track (6788 / 909 px) — a platform constraint of the skinIdioms family (platform-owned control chrome), NOT implementation drift and NOT a progress meter: unlike the per-platform entries that fall when a fix lands, this split is expected to persist until Apple exposes the surface. Recorded here rather than in skinIdioms so the ruling and its one platform exception stay on the same page; recorded here rather than in inert_audit because the verdict is attributed, not unexplained. Slider's entry is uniformly-active by the same run's measurement (3067 / 14442 / 16236 px): the unfilled slider track IS paintable on ios.",
+      "observable": {
+        "Slider/trackTintColor__static": "uniformly-active",
+        "Switch/trackTintColor__static": {
+          "ios": "inert",
+          "android": "active",
+          "web": "active"
+        }
+      },
+      "iosSwitchConstraint": "SwiftUI's Toggle has no paintable OFF-track surface; both ios paths degrade to .tint(), visible only while ON"
+    },
+    "fontProvider": {
+      "ruling": "Configuration.Font.fontProvider is the app's typeface-policy injection point, and the presence of `fontFamily` must NOT change whether it is consulted: every font resolution routes through the provider as FontSpec(family:, weight:, size:), family nil included. A path that bypasses the provider when family is absent makes the same attribute on the same screen pass or skip the app's policy depending on mode — the checked/unchecked shape this wave kept finding. The codegen path is the conforming side; SwiftJsonUI's dynamic path (DynamicDecodingHelper.fontFromComponent) is being aligned to it with a regression test (F, plan 49). A provider that ignores family nil sees no change; one that returns a custom face was silently falling back to the system font on dynamic — either way the contract converges on: the typeface does not depend on mode. Preserving a consumer's current look is not a reason to keep the bypass (canonical semantics win). 2026-08-06 ruling.",
+      "contract": "family presence must not gate provider consultation — every implementer, current or future, routes every FontSpec through fontProvider"
     }
   }
 }

package/data/component_metadata.json

@@ -117,7 +117,12 @@
   },
   "Image": {
     "description": "Local image component",
-    "aliases": [],
+    "aliases": [
+      "CircleImage",
+      "CircleImageView",
+      "ImageView",
+      "Img"
+    ],
     "platforms": {
       "swift_generated": true,
       "swift_dynamic": true,
@@ -233,7 +238,11 @@
   },
   "Collection": {
     "description": "List/grid collection with data binding",
-    "aliases": [],
+    "aliases": [
+      "Table",
+      "TableView",
+      "RecyclerView"
+    ],
     "platforms": {
       "swift_generated": true,
       "swift_dynamic": true,

package/data/coverage.json

@@ -2,33 +2,6 @@
   "schemaVersion": 1,
   "_comment": "Declared attributes no platform converter reads. Hand-maintained: close a gap by implementing it (then delete the entry) or by narrowing platform/mode in attribute_definitions.json. reason is one of: dynamic-key, legacy, platform-na, runtime-only, unimplemented.",
   "entries": [
-    {
-      "component": "Button",
-      "attribute": "hilightColor",
-      "platforms": [
-        "web"
-      ],
-      "reason": "legacy",
-      "note": "alias — normalized to its canonical spelling before conversion"
-    },
-    {
-      "component": "Collection",
-      "attribute": "onPageChanged",
-      "platforms": [
-        "web"
-      ],
-      "reason": "legacy",
-      "note": "alias — normalized to its canonical spelling before conversion"
-    },
-    {
-      "component": "Radio",
-      "attribute": "selected_icon",
-      "platforms": [
-        "android"
-      ],
-      "reason": "legacy",
-      "note": "alias — normalized to its canonical spelling before conversion"
-    },
     {
       "component": "ScrollView",
       "attribute": "minZoom",
@@ -38,77 +11,14 @@
       "reason": "unimplemented",
       "note": "codegen 未対応。ランタイム側に実装あり (ios: UIKit) — この検査は Ruby codegen しか走査しないので、実装の有無ではなく codegen 対応の有無を表す"
     },
-    {
-      "component": "Slider",
-      "attribute": "maxValue",
-      "platforms": [
-        "web"
-      ],
-      "reason": "legacy",
-      "note": "alias — normalized to its canonical spelling before conversion"
-    },
-    {
-      "component": "Slider",
-      "attribute": "minValue",
-      "platforms": [
-        "web"
-      ],
-      "reason": "legacy",
-      "note": "alias — normalized to its canonical spelling before conversion"
-    },
-    {
-      "component": "Switch",
-      "attribute": "onToggle",
-      "platforms": [
-        "web"
-      ],
-      "reason": "legacy",
-      "note": "alias — normalized to its canonical spelling before conversion"
-    },
-    {
-      "component": "TextField",
-      "attribute": "accessoryBackground",
-      "platforms": [
-        "ios"
-      ],
-      "reason": "unimplemented",
-      "note": "codegen 未対応。ランタイム側に実装あり (ios: UIKit) — この検査は Ruby codegen しか走査しないので、実装の有無ではなく codegen 対応の有無を表す"
-    },
-    {
-      "component": "TextField",
-      "attribute": "accessoryTextColor",
-      "platforms": [
-        "ios"
-      ],
-      "reason": "unimplemented",
-      "note": "codegen 未対応。ランタイム側に実装あり (ios: UIKit) — この検査は Ruby codegen しか走査しないので、実装の有無ではなく codegen 対応の有無を表す"
-    },
-    {
-      "component": "TextField",
-      "attribute": "doneText",
-      "platforms": [
-        "ios"
-      ],
-      "reason": "unimplemented",
-      "note": "codegen 未対応。ランタイム側に実装あり (ios: UIKit) — この検査は Ruby codegen しか走査しないので、実装の有無ではなく codegen 対応の有無を表す"
-    },
-    {
-      "component": "View",
-      "attribute": "direction",
-      "platforms": [
-        "ios"
-      ],
-      "reason": "unimplemented",
-      "note": "codegen 未対応。ランタイム側に実装あり (ios: UIKit) — この検査は Ruby codegen しか走査しないので、実装の有無ではなく codegen 対応の有無を表す"
-    },
     {
       "component": "common",
-      "attribute": "alpha",
+      "attribute": "binding",
       "platforms": [
-        "web"
+        "ios"
       ],
       "reason": "legacy",
-      "note": "alias — normalized to its canonical spelling before conversion"
+      "note": "UIKit-only KVC binding (SJUIViewCreator sets view.binding / bindingSet). The last Ruby reader was sjui's table_converter.rb, folded into the Collection route when 49-E ruled Table is a Collection — so this became unread by that ruling, not by anything failing. The declaration says it is superseded by `@{...}` in the attribute value itself; the UIKit runtime still honours it for layouts that predate that, which is why it is not deleted. Reason `legacy` rather than `unimplemented`: nothing is missing."
     }
   ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jui-tools-mcp-server",
-  "version": "2.5.0",
+  "version": "2.5.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.4.0";
+const JSONUI_CLI_TAG = "v1.4.1";
 const BASE_URL =
   process.env.JSONUI_CLI_RAW_BASE ||
   `https://raw.githubusercontent.com/Tai-Kimura/jsonui-cli/${JSONUI_CLI_TAG}`;