jui-tools-mcp-server 2.5.1 → 2.7.0

package/data/attribute_definitions.json

@@ -181,7 +181,7 @@
         "string",
         "binding"
       ],
-      "description": "Background color - hex string (#RRGGBB or #RRGGBBAA) or color name from colors.json (can be data binding)"
+      "description": "Background color - hex string (#RRGGBB or #RRGGBBAA) or color name from colors.json (can be data binding). `backgroundColor` folds here: the genuine layout reads of that spelling all chain with `background` (kjui blurview_component.rb:42 `background || backgroundColor`, kjui segment_component.rb:55 `backgroundColor || background`, rjui blur_converter.rb:58 and circle_view_converter.rb:55). Note the two kjui sites read the pair in OPPOSITE order, so a layout setting both drew two different colours until the normalizer began folding them — the same defect shape as CheckBox's accent chain (plan 51-E). When a `gradient` is also declared on the same view, the GRADIENT wins and this is the fallback fill — not a layer underneath it. Full ruling in attribute_semantics.json -> backgroundFill; do not restate it in toolchain comments."
     },
     "tapBackground": {
       "type": [
@@ -663,7 +663,8 @@
         "boolean",
         "binding"
       ],
-      "description": "Whether to clip content to bounds (binding supported)"
+      "description": "Whether to clip content to bounds (binding supported). Defaults to FALSE: content is not clipped unless the layout asks. A clipping default would silently destroy a child's `shadow` and would make `clipToBounds: true` inert on the platform that already clips. Full ruling in attribute_semantics.json -> clipToBounds; do not restate it in toolchain comments.",
+      "default": false
     },
     "onclick": {
       "type": [
@@ -856,7 +857,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."
+        "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."
       },
     "tag": {
       "type": [
@@ -950,7 +951,7 @@
         "centerHorizontal",
         "center"
       ],
-      "description": "Content gravity/alignment"
+      "description": "Content gravity/alignment. A single value names ONE axis; the axis it does not name falls to the container default (top vertically, start horizontally), so in LTR `left` and `top` both resolve to (start, top) and render identically. Use the array form to name both axes. Full ruling in attribute_semantics.json -> gravityDefaults; do not restate it in toolchain comments."
     },
     "onAppear": {
       "type": "string",
@@ -1110,6 +1111,20 @@
       "description": "Debug: original height string before parsing. Dynamic-only; not emitted to static code.",
       "platform": "swift",
       "mode": "dynamic-only"
+    },
+    "offsetX": {
+      "type": [
+        "number",
+        "binding"
+      ],
+      "description": "Horizontal offset applied after layout, in pt / dp / px. Measurement and sibling placement are unchanged — the layout is computed first and the offset moves only this view. Its INTERACTIVE region moves with it: an offset control is tappable where it is drawn, which is what rules out a draw-only translation. Absolute, not RTL-mirroring, like leftMargin/rightMargin rather than startMargin/endMargin. Pairs with offsetY; either one alone implies 0 for the other. Full ruling (including the android primitive) in attribute_semantics.json -> offset."
+    },
+    "offsetY": {
+      "type": [
+        "number",
+        "binding"
+      ],
+      "description": "Vertical offset applied after layout, in pt / dp / px. Measurement and sibling placement are unchanged — the layout is computed first and the offset moves only this view. Its INTERACTIVE region moves with it: an offset control is tappable where it is drawn, which is what rules out a draw-only translation. Absolute, not RTL-mirroring, like leftMargin/rightMargin rather than startMargin/endMargin. Pairs with offsetX; either one alone implies 0 for the other. Full ruling (including the android primitive) in attribute_semantics.json -> offset."
     }
   },
   "Label": {
@@ -1242,7 +1257,7 @@
         "object",
         "array"
       ],
-      "description": "Underline styling (boolean for simple, object for styled)",
+      "description": "Underline styling: boolean for a plain line, object to style it. The object face must never draw LESS than `true` does — a platform that cannot honour lineStyle or color still draws the plain Single line in the text colour. `lineStyle: \"None\"` is the one object value that draws nothing, exactly like `false`. Full ruling in attribute_semantics.json -> textDecoration; do not restate it in toolchain comments.",
       "properties": {
         "lineStyle": {
           "type": "string",
@@ -1269,7 +1284,7 @@
         "boolean",
         "object"
       ],
-      "description": "Strikethrough styling (boolean for simple, object for styled)",
+      "description": "Strikethrough styling: boolean for a plain line, object to style it. Same contract as Label.underline, minus lineOffset, which strikethrough does not declare and must not invent. `lineStyle: \"None\"` draws nothing, exactly like `false`. Full ruling in attribute_semantics.json -> textDecoration; do not restate it in toolchain comments.",
       "properties": {
         "lineStyle": {
           "type": "string",
@@ -1289,7 +1304,7 @@
     },
     "autoShrink": {
       "type": "boolean",
-      "description": "Enable auto-shrink"
+      "description": "Enable auto-shrink. Active only on a bounded axis (explicit size, matchParent, or a max bound) — a no-op under wrapContent, which grows to the content and leaves nothing to shrink into. Full ruling in attribute_semantics.json -> autoShrink."
     },
     "minimumScaleFactor": {
       "type": [
@@ -1479,6 +1494,13 @@
         "number"
       ],
       "description": "Font weight (e.g., 'bold', 'semibold', '500', 600)"
+    },
+    "disabledFontColor": {
+      "type": [
+        "string",
+        "binding"
+      ],
+      "description": "Font color when disabled - hex string or color name from colors.json (binding supported). Declared from the implementation, which already read it: sjui label_converter.rb:179-180 (plan 51-E)."
     }
   },
   "TextField": {
@@ -1487,8 +1509,11 @@
         "string",
         "binding"
       ],
-      "description": "Text content (binding for two-way)",
-      "binding_direction": "two-way"
+      "description": "Text content (binding for two-way). `value` folds here (sjui textfield_converter.rb:527 reads `text || value || bind`).",
+      "binding_direction": "two-way",
+      "aliases": [
+        "value"
+      ]
     },
     "hint": {
       "type": "string",
@@ -1519,6 +1544,24 @@
     "hintAttributes": {
       "type": "object",
       "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.",
+      "properties": {
+        "font": {
+          "type": "string",
+          "description": "Font name"
+        },
+        "fontSize": {
+          "type": "number",
+          "description": "Font size"
+        },
+        "fontColor": {
+          "type": "string",
+          "description": "Font color - hex string or color name from colors.json"
+        },
+        "lineHeightMultiple": {
+          "type": "number",
+          "description": "Line height multiplier"
+        }
+      },
       "platform": "swift"
     },
     "font": {
@@ -1902,6 +1945,10 @@
       "description": "Hide other elements while the field is focused.",
       "platform": "swift",
       "mode": "swiftui"
+    },
+    "hintLineHeightMultiple": {
+      "type": "number",
+      "description": "Placeholder line height multiplier. Declared from the implementation, which already read it: sjui textfield_converter.rb:153 and textview_converter.rb:93,117 (EditText/Input follow via _alias_of) (plan 51-E)."
     }
   },
   "TextView": {
@@ -1942,7 +1989,25 @@
     },
     "hintAttributes": {
       "type": "object",
-      "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."
+      "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.",
+      "properties": {
+        "font": {
+          "type": "string",
+          "description": "Font name"
+        },
+        "fontSize": {
+          "type": "number",
+          "description": "Font size"
+        },
+        "fontColor": {
+          "type": "string",
+          "description": "Font color - hex string or color name from colors.json"
+        },
+        "lineHeightMultiple": {
+          "type": "number",
+          "description": "Line height multiplier"
+        }
+      }
     },
     "hideOnFocused": {
       "type": "boolean",
@@ -2291,6 +2356,105 @@
         "binding"
       ],
       "description": "Font weight (e.g., 'bold', 'semibold', '500', 600, or binding)"
+    },
+    "fontFamily": {
+      "type": [
+        "string",
+        "binding"
+      ],
+      "description": "Font family name (e.g., 'Noto Sans JP'). Passed as the `family` field of `FontSpec` to `Configuration.Font.fontProvider`. Coexists with `font` (weight) and `fontSize` which are passed in the same FontSpec. Declared from the implementation, which already read it: sjui button_converter.rb:173-178 (plan 51-E)."
+    },
+    "partialAttributes": {
+      "type": "array",
+      "description": "Partial text styling: apply font/size/color/underline/shadow to a substring selected by 'range' (a [start, end] pair, a text pattern, or a binding), and optionally make it tappable with 'onclick'. This is the supported way to get emphasis or a link inside a Label, since 'text' is plain text and markdown is not interpreted, and it is the portable way to express a cross-reference: the handler navigates (and scrolls to the target) in host code, so the same layout works everywhere, where a URL-based link would only work on web. All three platforms resolve partials at RUNTIME against the resolved string, so a pattern range and a localized or bound 'text' both work. Semantics, identical across platforms and verified against each runtime: an array range is [start, end) with the end exclusive; a string range is the FIRST occurrence and the partial is skipped (not an error) when the pattern is absent; a range that is out of bounds or inverted is skipped; partials apply in declaration order and MERGE where they overlap, later declarations winning per property. Declared from the implementation, which already read it: sjui button_converter.rb:68-129 (plan 51-E).",
+      "items": {
+        "type": "object",
+        "properties": {
+          "font": {
+            "type": "string",
+            "description": "Font name"
+          },
+          "fontSize": {
+            "type": "number",
+            "description": "Font size"
+          },
+          "fontColor": {
+            "type": "string",
+            "description": "Font color - hex string or color name from colors.json"
+          },
+          "lineSpacing": {
+            "type": "number",
+            "description": "Line spacing"
+          },
+          "lineHeightMultiple": {
+            "type": "number",
+            "description": "Line height multiplier"
+          },
+          "lineBreakMode": {
+            "type": "string",
+            "enum": [
+              "Char",
+              "Clip",
+              "Word",
+              "Head",
+              "Middle",
+              "Tail"
+            ],
+            "description": "Line break mode"
+          },
+          "textAlign": {
+            "type": "string",
+            "enum": [
+              "Left",
+              "Right",
+              "Center"
+            ],
+            "description": "Text alignment"
+          },
+          "underline": {
+            "type": "object",
+            "properties": {
+              "lineStyle": {
+                "type": "string",
+                "enum": [
+                  "Single",
+                  "Double",
+                  "Thick",
+                  "None"
+                ],
+                "description": "Underline style"
+              },
+              "color": {
+                "type": "string",
+                "description": "Underline color - hex string or color name from colors.json"
+              },
+              "lineOffset": {
+                "type": "number",
+                "description": "Baseline offset"
+              }
+            }
+          },
+          "textShadow": {
+            "type": "string",
+            "description": "Text shadow"
+          },
+          "range": {
+            "type": [
+              "array",
+              "string"
+            ],
+            "description": "Range [start, end], text pattern string, or binding expression"
+          },
+          "onclick": {
+            "type": "string",
+            "description": "Click handler for this range (selector-based, lowercase)"
+          },
+          "onClick": {
+            "type": "binding",
+            "description": "Click handler for this range (camelCase) - binding only (@{functionName})"
+          }
+        }
+      }
     }
   },
   "Image": {
@@ -2418,6 +2582,10 @@
       "description": "Pinch-zoom lower bound.",
       "platform": "swift",
       "mode": "swiftui"
+    },
+    "defaultImage": {
+      "type": "string",
+      "description": "Default image name. Declared from the implementation, which already read it: sjui image_converter.rb:36,42 (defaultImage || errorImage || loadingImage) (plan 51-E)."
     }
   },
   "NetworkImage": {
@@ -2433,7 +2601,10 @@
         "string",
         "binding"
       ],
-      "description": "Image URL (alias, can be data binding)"
+      "description": "Image URL (alias, can be data binding). `source` folds here (sjui network_image_converter.rb:14 reads `url || source || src`).",
+      "aliases": [
+        "source"
+      ]
     },
     "hint": {
       "type": "string",
@@ -2513,6 +2684,18 @@
       "description": "HTTP headers for the image request (Coil 3: httpHeaders(NetworkHeaders) on ImageRequest.Builder).",
       "platform": "kotlin",
       "mode": "compose"
+    },
+    "renderingMode": {
+      "type": "string",
+      "enum": [
+        "original",
+        "template"
+      ],
+      "description": "Rendering mode. Declared from the implementation, which already read it: sjui network_image_converter.rb:67-68 (plan 51-E).",
+      "platform": [
+        "swift",
+        "kotlin"
+      ]
     }
   },
   "SelectBox": {
@@ -2575,7 +2758,7 @@
         "string",
         "binding"
       ],
-      "description": "Initial selected date (yyyy-MM-dd format, two-way binding)"
+      "description": "Initial selected date (yyyy-MM-dd format, two-way binding). No `default`: when it is absent no initial selection has been stated, and the closed face shows the prompt / hint / placeholder rather than today's date. Full ruling in attribute_semantics.json -> selectBoxDate."
     },
     "datePickerMode": {
       "type": "string",
@@ -2605,7 +2788,10 @@
     },
     "dateStringFormat": {
       "type": "string",
-      "description": "Date string format"
+      "description": "Date string format. `dateFormat` folds here (sjui selectbox_converter.rb:132 reads `dateFormat || dateStringFormat`).",
+      "aliases": [
+        "dateFormat"
+      ]
     },
     "minimumDate": {
       "type": [
@@ -2940,6 +3126,42 @@
     "trackTintColor": {
       "type": "string",
       "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."
+    },
+    "fontColor": {
+      "type": [
+        "string",
+        "binding"
+      ],
+      "description": "Text color - hex string or color name from colors.json (binding supported). Declared from the implementation, which already read it: sjui toggle_converter.rb:62-63,71-72 (plan 51-E)."
+    },
+    "toggleStyle": {
+      "type": "string",
+      "enum": [
+        "switch",
+        "button",
+        "checkbox",
+        "default"
+      ],
+      "description": "Which control shape the Switch is drawn as. A SwiftUI-only concept (the ToggleStyle protocol); an unrecognised value falls back to the platform default rather than erroring. Declared from the implementation, which already read it: sjui toggle_converter.rb:92-104 (plan 51-E).",
+      "platform": "swift",
+      "mode": "swiftui"
+    },
+    "label": {
+      "type": [
+        "string",
+        "binding"
+      ],
+      "description": "Switch label (can be data binding). Same shape CheckBox and Radio already declare: `label` is the canonical row and `text` folds into it. Declared from the implementation, which already read it: sjui toggle_converter.rb:21 (text || label) (plan 51-E).",
+      "aliases": [
+        "text"
+      ]
+    },
+    "fontSize": {
+      "type": [
+        "number",
+        "binding"
+      ],
+      "description": "Font size (binding supported). Declared from the implementation, which already read it: sjui toggle_converter.rb hands the whole component to the shared apply_font_modifiers helper, so the size was honoured with no declaration behind it (plan 51-E)."
     }
   },
   "Toggle": {
@@ -2957,12 +3179,18 @@
         "number",
         "binding"
       ],
-      "description": "Initially selected index (binding for two-way)",
-      "binding_direction": "two-way"
+      "description": "Initially selected index (binding for two-way). `selectedTabIndex` folds here (sjui segment_converter.rb:16), matching the alias TabView already declares.",
+      "binding_direction": "two-way",
+      "aliases": [
+        "selectedTabIndex"
+      ]
     },
     "tintColor": {
       "type": "string",
-      "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"
+      "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. `selectedSegmentTintColor` folds here (sjui segment_converter.rb:128 reads `selectedSegmentTintColor || tintColor`).",
+      "aliases": [
+        "selectedSegmentTintColor"
+      ]
     },
     "fontColor": {
       "type": "string",
@@ -3013,22 +3241,24 @@
         "number",
         "binding"
       ],
-      "description": "Minimum value (binding supported). `minValue` / `minimumValue` are accepted alias spellings.",
+      "description": "Minimum value (binding supported). `minValue` / `minimumValue` are accepted alias spellings. Defaults to 0: with no bounds declared the range is 0 .. 1, this SSoT's convention for a unitless value on a track (compare Progress.progress and opacity, both declared min 0 / max 1). Full ruling in attribute_semantics.json -> sliderRange.",
       "aliases": [
         "minimumValue",
         "minValue"
-      ]
+      ],
+      "default": 0
     },
     "maximum": {
       "type": [
         "number",
         "binding"
       ],
-      "description": "Maximum value (binding supported). `maxValue` / `maximumValue` are accepted alias spellings.",
+      "description": "Maximum value (binding supported). `maxValue` / `maximumValue` are accepted alias spellings. Defaults to 1: with no bounds declared the range is 0 .. 1, this SSoT's convention for a unitless value on a track (compare Progress.progress and opacity, both declared min 0 / max 1). Full ruling in attribute_semantics.json -> sliderRange.",
       "aliases": [
         "maximumValue",
         "maxValue"
-      ]
+      ],
+      "default": 1
     },
     "tintColor": {
       "type": "string",
@@ -3065,6 +3295,10 @@
     "trackTintColor": {
       "type": "string",
       "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()."
+    },
+    "range": {
+      "type": "array",
+      "description": "Both bounds at once, as [minimum, maximum] — a shorthand for declaring `minimum` and `maximum` separately. It is NOT an alias: one spelling carries two values, so the normalizer cannot fold it. Read only when it is a two-element array; anything else leaves `minimum` / `maximum` to speak for themselves. Declared from the implementation, which already read it: sjui slider_converter.rb:16-19 (plan 51-E)."
     }
   },
   "Progress": {
@@ -3197,7 +3431,7 @@
     },
     "gradient": {
       "type": "array",
-      "description": "Gradient colors",
+      "description": "Gradient colors Wins over `background` when both are declared on the same view; see attribute_semantics.json -> backgroundFill.",
       "platform": "swift"
     },
     "gradientDirection": {
@@ -3459,6 +3693,19 @@
       ],
       "description": "Scroll behavior animation",
       "platform": "react"
+    },
+    "horizontalScroll": {
+      "type": "boolean",
+      "description": "Enable horizontal scroll. Declared from the implementation, which already read it: sjui scrollview_converter.rb:39 (plan 51-E)."
+    },
+    "defaultScrollAnchor": {
+      "type": "string",
+      "enum": [
+        "top",
+        "center",
+        "bottom"
+      ],
+      "description": "Initial scroll position anchor. Sets where the scroll view starts. Declared from the implementation, which already read it: sjui scrollview_converter.rb:207-215. Scope is deliberately all three platforms: the anchor is a portable concept and the declaration says an attribute EXISTS, not which face has caught up — the coverage ledger carries the android and web gaps. The \"(iOS 17+)\" note this description was copied with belonged to Collection's ios implementation, not to the contract, and has been dropped here (plan 51-E, raised by C)."
     }
   },
   "Collection": {
@@ -3505,7 +3752,10 @@
     },
     "lineSpacing": {
       "type": "number",
-      "description": "Spacing between rows"
+      "description": "Spacing between rows. `sectionSpacing` folds here (sjui collection_converter.rb:799,960 read `sectionSpacing || lineSpacing || 8`).",
+      "aliases": [
+        "sectionSpacing"
+      ]
     },
     "horizontalScroll": {
       "type": "boolean",
@@ -3728,6 +3978,29 @@
         "onValueChanged",
         "onPageChanged"
       ]
+    },
+    "cellWidth": {
+      "type": "number",
+      "description": "Fixed width for every cell, in pt / dp / px. Applied to the cell view AFTER it is built, so it overrides whatever width the cell layout asked for; leave it out to let each cell size itself. Declared from the implementation, which already read it: sjui collection_converter.rb:256,282,315,650 (plan 51-E)."
+    },
+    "cellHeight": {
+      "type": "number",
+      "description": "Fixed height for every cell, in pt / dp / px. Applied to the cell view AFTER it is built, so it overrides whatever height the cell layout asked for; leave it out to let each cell size itself. Declared from the implementation, which already read it: sjui collection_converter.rb:260,286,318,402 (plan 51-E)."
+    },
+    "hideSeparator": {
+      "type": "boolean",
+      "description": "Hide the row separators a list draws between cells. A NO-OP where the container draws no separators (a grid-shaped Collection has none) — that is the contract, not an unimplemented gap, and it does not license switching the container to a List. No CODEGEN face reads it, so the coverage row is runtime-only. Full ruling in attribute_semantics.json -> collectionSeparators."
+    },
+    "listStyle": {
+      "type": "string",
+      "enum": [
+        "plain",
+        "grouped",
+        "insetGrouped",
+        "sidebar"
+      ],
+      "default": "plain",
+      "description": "Which list chrome the collection is drawn with. Enumerated from the only implementation that reads it (SwiftJsonUI TableConverter.applyListStyle); an unrecognised value falls back to plain. ORTHOGONAL to hideSeparator — that one hides the separators, this one picks the chrome, and neither overrides the other. No CODEGEN face reads it, so the coverage row is runtime-only: sjui collection_converter.rb:213 hardcodes PlainListStyle instead. Full ruling in attribute_semantics.json -> collectionSeparators."
     }
   },
   "Radio": {
@@ -3774,7 +4047,10 @@
         "boolean",
         "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."
+      "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. `isOn` folds here (sjui radio_converter.rb:88,102 read both the literal and the bound form as `checked || isOn`).",
+      "aliases": [
+        "isOn"
+      ]
     },
     "value": {
       "type": "any",
@@ -3850,6 +4126,13 @@
     "onValueChange": {
       "type": "binding",
       "description": "Value change handler - binding only (@{functionName})"
+    },
+    "items": {
+      "type": [
+        "array",
+        "binding"
+      ],
+      "description": "List of items for normal picker (can be template variable). Declared from the implementation, which already read it: sjui radio_converter.rb:13 — the option list a radio GROUP renders; with it the converter emits a group, without it a single radio (plan 51-E)."
     }
   },
   "CheckBox": {
@@ -3949,14 +4232,22 @@
     },
     "onValueChange": {
       "type": "binding",
-      "description": "Value change handler - binding only (@{functionName})"
+      "description": "Value change handler - binding only (@{functionName}). Legacy handler spellings fold here (sjui checkbox_converter.rb:122 reads `onValueChange || onClick || action || onValueChanged`; `onClick` stays common).",
+      "aliases": [
+        "action",
+        "onValueChanged"
+      ]
     },
     "checkedColor": {
       "type": "color",
-      "description": "Color when checked.",
+      "description": "Color when checked. Legacy accent spellings fold here (sjui checkbox_converter.rb:98 and kjui checkbox_component.rb:211 both read the same four spellings for this one colour). `tintColor` is deliberately NOT in the alias list: it is already declared on `common`, and an alias that is also a declared row is a silent no-op (test_no_alias_is_cancelled_by_a_declaration_of_its_own_name). On a CheckBox the common tint IS the checked colour - that is what both converters implement - so it needs no alias row. Declaring the other two also settles a live divergence: ios reads `checkedColor` first, android reads `checkColor` first, so a layout setting both drew two different colours until the normalizer began folding them (plan 51-E).",
       "platform": [
         "swift",
         "kotlin"
+      ],
+      "aliases": [
+        "checkColor",
+        "onTintColor"
       ]
     },
     "uncheckedColor": {
@@ -3982,6 +4273,16 @@
         "swift",
         "kotlin"
       ]
+    },
+    "fontWeight": {
+      "type": [
+        "string",
+        "number"
+      ],
+      "description": "Font weight (e.g., 'bold', 'semibold', '500', 600). Canonical name matches Label and Button; the legacy `fontStyle` spelling folds here. Declared from the implementation, which already read it: sjui checkbox_converter.rb:74-76, which reads `fontStyle` and emits `fontWeight:` (plan 51-E).",
+      "aliases": [
+        "fontStyle"
+      ]
     }
   },
   "Check": {
@@ -4016,13 +4317,16 @@
         "string",
         "binding"
       ],
-      "description": "Indicator color - hex string or color name from colors.json (binding supported)",
+      "description": "Indicator color - hex string or color name from colors.json (binding supported). `tint` folds here (sjui indicator_converter.rb:77 reads `color || tintColor || tint`).",
       "platform": "swift",
-      "mode": "swiftui"
+      "mode": "swiftui",
+      "aliases": [
+        "tint"
+      ]
     },
     "hidesWhenStopped": {
       "type": "boolean",
-      "description": "Hide when stopped",
+      "description": "Hide when stopped. Decides SPACE: `true` collapses the stopped indicator out of the layout, `false` keeps it drawn AND laid out. Full ruling in attribute_semantics.json -> indicatorStopped.",
       "platform": "swift",
       "mode": "swiftui"
     }
@@ -4030,7 +4334,10 @@
   "GradientView": {
     "gradient": {
       "type": "array",
-      "description": "Gradient colors"
+      "description": "Gradient colors. `colors` folds here (sjui gradient_view_converter.rb:52,66 read `colors || gradient`). On GradientView the gradient is the component's own fill, so the backgroundFill precedence question does not arise.",
+      "aliases": [
+        "colors"
+      ]
     },
     "gradientDirection": {
       "type": "string",
@@ -4044,6 +4351,54 @@
     "locations": {
       "type": "array",
       "description": "Color stop locations (0.0-1.0)"
+    },
+    "child": {
+      "type": "array",
+      "description": "Child component(s). Declared from the implementation, which already read it: sjui gradient_view_converter.rb:16 (plan 51-E)."
+    },
+    "children": {
+      "type": "array",
+      "description": "Child components (alias for child). Declared from the implementation, which already read it: sjui gradient_view_converter.rb:16 (child || children) (plan 51-E)."
+    },
+    "startPoint": {
+      "type": [
+        "array",
+        "object"
+      ],
+      "description": "Unit coordinates in the view's own box for where the gradient starts: [x, y] or {\"x\": x, \"y\": y}, with 0 = leading/top, 0.5 = centre/middle, 1 = trailing/bottom. THREE faces read this key three incompatible ways today: sjui gradient_view_converter.rb:107-109 wants an OBJECT ({x, y}), rjui gradient_view_converter.rb:72-73 destructures an ARRAY ([x, y]), and kjui gradientview_component.rb:58-59 expects a STRING edge name ('top'). The two coordinate forms are declared because both are real coordinate spellings of the same thing; the android string form is NOT declared - it is `gradientDirection` semantics written under the wrong key, and is filed as a defect rather than blessed here. Declaring BOTH startPoint and endPoint replaces gradientDirection entirely; declaring only one is ignored and gradientDirection still decides (plan 51-E).",
+      "items": {
+        "type": "number"
+      },
+      "properties": {
+        "x": {
+          "type": "number",
+          "description": "0 = leading, 0.5 = centre, 1 = trailing"
+        },
+        "y": {
+          "type": "number",
+          "description": "0 = top, 0.5 = middle, 1 = bottom"
+        }
+      }
+    },
+    "endPoint": {
+      "type": [
+        "array",
+        "object"
+      ],
+      "description": "Unit coordinates in the view's own box for where the gradient ends: [x, y] or {\"x\": x, \"y\": y}, with 0 = leading/top, 0.5 = centre/middle, 1 = trailing/bottom. THREE faces read this key three incompatible ways today: sjui gradient_view_converter.rb:107-109 wants an OBJECT ({x, y}), rjui gradient_view_converter.rb:72-73 destructures an ARRAY ([x, y]), and kjui gradientview_component.rb:58-59 expects a STRING edge name ('top'). The two coordinate forms are declared because both are real coordinate spellings of the same thing; the android string form is NOT declared - it is `gradientDirection` semantics written under the wrong key, and is filed as a defect rather than blessed here. Declaring BOTH startPoint and endPoint replaces gradientDirection entirely; declaring only one is ignored and gradientDirection still decides (plan 51-E).",
+      "items": {
+        "type": "number"
+      },
+      "properties": {
+        "x": {
+          "type": "number",
+          "description": "0 = leading, 0.5 = centre, 1 = trailing"
+        },
+        "y": {
+          "type": "number",
+          "description": "0 = top, 0.5 = middle, 1 = bottom"
+        }
+      }
     }
   },
   "Blur": {
@@ -4063,6 +4418,14 @@
         "kotlin",
         "react"
       ]
+    },
+    "child": {
+      "type": "array",
+      "description": "Child component(s). Declared from the implementation, which already read it: sjui blur_converter.rb:16 (plan 51-E)."
+    },
+    "children": {
+      "type": "array",
+      "description": "Child components (alias for child). Declared from the implementation, which already read it: sjui blur_converter.rb:16 (child || children) (plan 51-E)."
     }
   },
   "IconLabel": {
@@ -4078,7 +4441,10 @@
         "boolean",
         "binding"
       ],
-      "description": "Selected state (binding supported). Chooses icon_on over icon_off and selectedFontColor over fontColor, so every platform declaring those needs this too."
+      "description": "Selected state (binding supported). Chooses icon_on over icon_off and selectedFontColor over fontColor, so every platform declaring those needs this too. `isOn` folds here — the legacy spelling for the same state. IconLabelConverter.swift:145-151 says so in as many words (\"Pre-SSoT layouts that spelled it `isOn` keep working\") and reads it out of rawData because no typed slot existed; sjui icon_label_converter.rb:130 reads the canonical `selected` (plan 51-E).",
+      "aliases": [
+        "isOn"
+      ]
     },
     "font": {
       "type": "string",
@@ -4124,6 +4490,13 @@
     "iconMargin": {
       "type": "number",
       "description": "Icon-text spacing"
+    },
+    "iconSize": {
+      "type": [
+        "number",
+        "array"
+      ],
+      "description": "Icon size. A number sizes both edges; a two-element [width, height] sizes them separately (rjui icon_label_converter.rb:130-138 reads both, and its spec covers both). NOT the same shape as CheckBox.iconSize, which is a square glyph and takes a number only. sjui icon_label_converter.rb:50-51 interpolates the value straight into `iconSize:`, so the array form is web-only today — declared here because the attribute's value space is a property of the attribute, not of whichever face lags (plan 51-E)."
     }
   },
   "Web": {
@@ -4193,6 +4566,34 @@
     "children": {
       "type": "array",
       "description": "Child components (alias for child)"
+    },
+    "direction": {
+      "type": "string",
+      "enum": [
+        "topToBottom",
+        "bottomToTop",
+        "leftToRight",
+        "rightToLeft",
+        "none"
+      ],
+      "description": "Layout direction. Declared from the implementation, which already read it: sjui view_converter.rb:140 (SafeAreaView routes through the View converter) (plan 51-E)."
+    },
+    "gradient": {
+      "type": "array",
+      "description": "Gradient colors. Declared from the implementation, which already read it: sjui view_converter.rb:456 (plan 51-E).",
+      "platform": "swift"
+    },
+    "spacing": {
+      "type": [
+        "number",
+        "binding"
+      ],
+      "description": "Space between children (binding supported). Declared from the implementation, which already read it: sjui view_converter.rb:181 (plan 51-E).",
+      "mode": [
+        "swiftui",
+        "compose",
+        "react"
+      ]
     }
   },
   "TabView": {

package/data/attribute_semantics.json

@@ -8,28 +8,26 @@
       "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). 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/borderWidth__static": "uniformly-active",
+        "common/borderColor__static": "uniformly-active",
         "common/borderStyle__solid": "uniformly-inert",
         "common/borderStyle__dashed": "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"
-      }
+      },
+      "observableNote": "MEASURED 2026-08-08 (run 31243724782 + local-env): uniformly active — the divergence this entry recorded was fixed in-wave (ios Blur bridge / ios highlighted swap / ios distribution fill / ios loadingImage via pending.invalid / border emit on all faces)."
     },
     "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"
-        },
+        "View/highlighted__true": "uniformly-active",
         "common/highlightBackground__static": "uniformly-inert"
-      }
+      },
+      "observableNote": "MEASURED 2026-08-08 (run 31243724782 + local-env): uniformly active — the divergence this entry recorded was fixed in-wave (ios Blur bridge / ios highlighted swap / ios distribution fill / ios loadingImage via pending.invalid / border emit on all faces)."
     },
     "image": {
       "defaultContentMode": "fit",
@@ -50,12 +48,14 @@
     },
     "size": {
       "maxBoundsClampFill": "matchParent is clamped by maxWidth/maxHeight",
-      "ruling": "2026-08-03 user ruling (31 handoff): matchParent + maxWidth/maxHeight resolves to min(parent extent, bound) — the bound clamps the fill. Generated code is canonical (kjui emits the constraint before the fill since 847fb56); KJUI dynamic ordered fillMaxWidth before widthIn, ignoring the bound entirely — reordered in the 33 wave (bounds precede a fill, stay after an explicit size). The composite clamp fixtures below are the observable: a clamping platform renders visibly narrower/shorter than its filled control (active); ignoring the bound renders identically (inert). Companion precedence (2026-08-03 campaign adjudication): an EXPLICIT numeric dimension pins the constraints and its bound stays inert (kjui codegen 847fb56, ios 35efc2b, rjui skips max-* under an explicit size); bounds in turn clamp a FILL. Order: explicit > bounds > fill.",
+      "ruling": "2026-08-03 user ruling (31 handoff): matchParent + maxWidth/maxHeight resolves to min(parent extent, bound) — the bound clamps the fill. Generated code is canonical (kjui emits the constraint before the fill since 847fb56); KJUI dynamic ordered fillMaxWidth before widthIn, ignoring the bound entirely — reordered in the 33 wave (bounds precede a fill, stay after an explicit size). The composite clamp fixtures below are the observable: a clamping platform renders visibly narrower/shorter than its filled control (active); ignoring the bound renders identically (inert). Companion precedence (2026-08-03 campaign adjudication): an EXPLICIT numeric dimension pins the constraints and its bound stays inert (kjui codegen 847fb56, ios 35efc2b, rjui skips max-* under an explicit size); bounds in turn clamp a FILL. Order: explicit > bounds > fill. 2026-08-07 (plan 51-E), the wrap-bound family D asked for as the companion to maxBoundsClampFill. `width: wrapContent` says size to the content and `maxWidth` declares a MAXIMUM, not a target, so the two compose in only one way: the content sizes itself, the bound caps it, and content that would exceed the cap REFLOWS inside it rather than overflowing or stretching the box out to the bound. A short string under `maxWidth: 150` therefore stays narrow — the bound is not an ideal size, which is the half that only existed as a comment in sjui frame_helper.rb until now. ios already emits the canonical shape (`.frame(maxWidth: 150).fixedSize(horizontal: false, vertical: true)`), android `wrapContentWidth().widthIn(max=150)` and web `w-fit max-w-[150px]` agree. Note for fixture authors, from D's measurement: the generic maxWidth sweep cannot see this axis at all — a 40pt child in a 200pt box does not move by one pixel — so the observable needs REFLOWABLE text, which is why common/maxWidth__wrap is bespoke in bounds_fixtures.py.",
       "observable": {
         "common/maxWidth__fill_clamp": "uniformly-active",
-        "common/maxHeight__fill_clamp": "uniformly-active"
+        "common/maxHeight__fill_clamp": "uniformly-active",
+        "common/maxWidth__wrap": "uniformly-active"
       },
-      "explicitOverBounds": "an explicit numeric dimension wins over its min/max bound"
+      "explicitOverBounds": "an explicit numeric dimension wins over its min/max bound",
+      "wrapBoundReflow": "a wrapContent axis with a max bound reflows the content INSIDE the bound; the bound never becomes the ideal size"
     },
     "networkImage": {
       "noSrc": "defaultImage",
@@ -68,11 +68,9 @@
         },
         "NetworkImage/hint__static": "uniformly-inert",
         "NetworkImage/errorImage__static": "uniformly-active",
-        "NetworkImage/loadingImage__static": {
-          "ios": "inert",
-          "android": "active"
-        }
-      }
+        "NetworkImage/loadingImage__static": "uniformly-active"
+      },
+      "observableNote": "MEASURED 2026-08-08 (run 31243724782 + local-env): uniformly active — the divergence this entry recorded was fixed in-wave (ios Blur bridge / ios highlighted swap / ios distribution fill / ios loadingImage via pending.invalid / border emit on all faces)."
     },
     "margins": {
       "offsetModel": "ZStack/overlay child margins are full-margin offsets; an explicit center declaration disables that axis margin; margins arrays and start/endMargin apply as padding",
@@ -81,8 +79,14 @@
     },
     "gravityDefaults": {
       "defaultGravity": "top|start",
-      "ruling": "2026-08-03 campaign adjudication: the default content gravity is top|start on every container (CollectionStack pins Top; SafeAreaView spacer layouts anchor start). A platform centering by default is the deviant. No activeness observable — default-vs-default renders identically; the geometry probe closes it mechanically.",
-      "observable": {}
+      "ruling": "2026-08-03 campaign adjudication: the default content gravity is top|start on every container (CollectionStack pins Top; SafeAreaView spacer layouts anchor start). A platform centering by default is the deviant. No activeness observable — default-vs-default renders identically; the geometry probe closes it mechanically. 2026-08-07 (plan 51-E), Wave 2 carry-over: what happens to the axis a single-value gravity does NOT name. Ruled from the declaration alone, as the semantics rule requires, not from any platform's behaviour. common.gravity declares an enum of SINGLE-AXIS values (top, bottom, left, right, centerVertical, centerHorizontal) alongside an array type whose whole purpose is naming both axes at once. If a single-axis value left the other axis undefined, then `gravity: \"left\"` would have no defined rendering at all, and a declaration cannot leave its own enum values meaningless — so each axis resolves independently, and the axis that is not named takes the default already ruled above (top | start). It does NOT inherit the parent's gravity and it is not \"unset\". CONSEQUENCE, stated because it looks like a bug when measured: in LTR, `gravity: \"left\"` and `gravity: \"top\"` both resolve to (start, top) and are therefore observationally IDENTICAL. The Wave 2 note that ios draws `left` and `top` the same picture is the contract being honoured, not a defect; a fixture that expects those two to differ is testing something the SSoT never promised. Whether a given fixture can see the horizontal axis at all is a separate, real question — a child that fills the container's width makes it unobservable (D's lane). 2026-08-07 (plan 51-E), B's follow-up measurement: sjui emits `alignment: .topLeading` for every NAMED form (`left|top`, `left`, `top`) but drops the `alignment:` argument entirely when gravity is omitted, so SwiftUI falls to `.center` (51-B-progress). That is the deviation this ruling already named — \"a platform centering by default is the deviant\" — and the argument is the same one that settled the unspecified axis: if a partially specified gravity fills the unnamed axis with the default, then an omitted gravity fills BOTH axes with it. Any other reading makes omitting gravity mean something different from naming the default explicitly, which no declaration says. So the omitted form must also emit topLeading. NOTE FOR ROLLOUT, not for the canon: every View in every project that does not declare gravity goes through this line, so the fix wants a 3PF measurement and a fixture that can actually see it (a fixed-size container whose child does not stretch — with a stretching child the Spacer construction is identical in all four forms and the difference is unobservable). Sequencing is the orchestrator's; the canon is not in doubt.",
+      "observable": {},
+      "unspecifiedAxis": "falls to the container default for that axis (top vertically, start horizontally) — never \"unset\", never inherited from the parent",
+      "omittedEntirely": "same as the default: top | start. Omitting gravity must render identically to naming the default explicitly",
+      "leafOwnFrameChannel": {
+        "default": "center",
+        "ruling": "2026-08-08 adjudication (gravity leaf-scope hotfix, v1.5.2/10.15.1): the container default above scopes to CONTAINERS — nodes whose content the framework itself lays out. A childless node's own-frame content (a fit image's bitmap inside its declared box, a custom component's internals, a text block smaller than its fixed box) is a SEPARATE channel whose default is Center: Compose's Image/extension alignment default, which kjui never overrides, and the position the android face measurably draws a shrunken autoShrink line in its fixed box. ios converged in SwiftJsonUI 245d059+4d41bf9 (codegen gravity_to_frame_alignment leaf scope; dynamic fixed-frame text drop). A DECLARED gravity or textAlign still applies to any node — this entry names only the omitted-spelling default. Implementations were aligned BEFORE this text landed; the entry records the ruling the code already obeys."
+      }
     },
     "shadow": {
       "stringPipe": "five-field strict",
@@ -100,16 +104,8 @@
       "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 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",
-          "android": "active",
-          "web": "inert"
-        },
-        "Blur/effectStyle__light": {
-          "ios": "inert",
-          "android": "active",
-          "web": "inert"
-        },
+        "Blur/effectStyle__extralight": "uniformly-active",
+        "Blur/effectStyle__light": "uniformly-active",
         "TextField/borderStyle__bezel": {
           "ios": "inert",
           "android": "active",
@@ -141,7 +137,8 @@
           "web": "inert"
         },
         "TabView/showLabels__false": "uniformly-active"
-      }
+      },
+      "observableNote": "MEASURED 2026-08-08 (run 31243724782 + local-env): uniformly active — the divergence this entry recorded was fixed in-wave (ios Blur bridge / ios highlighted swap / ios distribution fill / ios loadingImage via pending.invalid / border emit on all faces)."
     },
     "progressValue": {
       "canonical": "progress",
@@ -175,11 +172,7 @@
       "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__fill": "uniformly-active",
         "View/distribution__fillequally": "uniformly-active",
         "View/distribution__equalspacing": "uniformly-active",
         "View/distribution__equalcentering": "uniformly-active"
@@ -216,7 +209,8 @@
         "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": {}
+      "collapsedPairs": {},
+      "observableNote": "MEASURED 2026-08-08 (run 31243724782 + local-env): uniformly active — the divergence this entry recorded was fixed in-wave (ios Blur bridge / ios highlighted swap / ios distribution fill / ios loadingImage via pending.invalid / border emit on all faces)."
     },
     "trackColors": {
       "sliderTrack": "trackTintColor is the UNFILLED track; progressTintColor is the filled one",
@@ -234,8 +228,154 @@
       "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"
+      "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. 2026-08-07 (plan 51-E), raised by G: android's codegen default provider (Configuration.defaultResolved) declares that it deliberately DISCARDS generic family names such as serif, while ios and web resolve them. The default provider must resolve them. `fontFamily` is declared as a family NAME with no enumeration and no carve-out, so a generic name is an ordinary value of the attribute, and every platform has real typefaces behind those names. The ruling above already fixed that a provider must always be CONSULTED; this fixes the other half — the DEFAULT provider must not silently narrow the attribute's value space. An app that wants to ignore generic families can still do it by injecting its own provider, which is what the injection point is for; the default is not the place to encode that policy, because it makes the same layout render a different typeface on android with nothing in the layout saying so. Owner: C (android codegen) and G (dynamic, in step).",
+      "contract": "family presence must not gate provider consultation — every implementer, current or future, routes every FontSpec through fontProvider",
+      "genericFamilies": "the default provider MUST resolve generic family names (serif, sans-serif, monospace, ...) — dropping them is not a policy decision the default gets to make"
+    },
+    "textDecoration": {
+      "attributes": [
+        "Label.underline",
+        "Label.strikethrough",
+        "partialAttributes[].underline"
+      ],
+      "faces": {
+        "boolean": "true draws the line; false draws nothing",
+        "object": "draws the line DESCRIBED by the object — never less than the boolean face draws",
+        "lineStyleNone": "lineStyle: \"None\" is the one object value that draws NOTHING; it is exactly equivalent to false"
+      },
+      "unstyledDefaults": {
+        "color": "the text's own colour — `color` declares no `default`, so it MODIFIES the line rather than bringing it into existence, and an absent colour means 'do not modify'",
+        "lineStyle": "Single",
+        "lineOffset": "no baseline adjustment; declared on underline only — strikethrough has no lineOffset and must not invent one"
+      },
+      "ruling": "2026-08-07 (plan 51-E §3), written so the implementation lanes have an expected value to match; presence was repaired in 10.14.1 and the STYLE content is what remains. The contract is derived from the declaration: underline/strikethrough declare boolean|object, and the object face's properties (lineStyle, color, lineOffset) carry no `default`, which by the SSoT's own convention makes them MODIFIERS of a line that the attribute's presence already brought into existence. Two consequences are load-bearing. FIRST, the object face must never render LESS than the boolean face: `underline: {...}` is a more specific request than `underline: true`, so a platform that cannot yet honour lineStyle or color must still draw the plain Single line in the text colour. Rendering nothing is always wrong. SECOND, `lineStyle: \"None\"` is the sole exception and means no line at all — identical output to `false`. MEASURED STATE, 2026-08-07, so nobody re-derives it: sjui text_style_helper.rb:130-135 (line_decoration?) and kjui text_component.rb:455 (decoration_on?) both implement exactly this None rule and then draw a plain line, ignoring colour and lineOffset. rjui label_converter.rb:371 is a bare truthiness test (`classes << 'underline' if attributes['underline']`), so on web a Hash is always truthy and `{lineStyle: \"None\"}` DRAWS A LINE — probed directly through the converter, not read: true / {Single} / {None} / {color:#FF0000} all emit the same `underline` class. That is a defect owned by A. kjui's DYNAMIC renderer drops the object face entirely (cross_effect Label/underline__styled, Label/strikethrough__styled: android inert, ios and web active), which violates the never-less-than-boolean rule and is owned by G. Double and Thick are declared but no face distinguishes them from Single today; they stay declared because the enum is the contract, and the gap belongs in the coverage ledger rather than being papered over by deleting the values. 2026-08-07 addendum (plan 51-E), F reporting after the SwiftUI halves were aligned: SJUILabel.swift:448 (the UIKit face) still falls `lineStyle: \"None\"` through to .single, so one library now answers the same spelling two ways. THE CONTRACT BINDS UIKIT. `Label.underline` and `Label.strikethrough` declare no `mode` key, so they apply to every mode, and UIKit is not frozen — nothing in SwiftJsonUI declares it so, and the SSoT carries 93 uikit-mode attribute declarations against swiftui's 30. Narrowing the ruling to swiftui would state something the declaration does not. So it is a defect owned by F, correctly filed as not urgent: conformance never renders it.",
+      "observable": {},
+      "modeIndependent": "the contract binds every mode, uikit included — Label.underline/strikethrough declare no `mode` key"
+    },
+    "backgroundFill": {
+      "attributes": [
+        "common.background",
+        "View.gradient",
+        "GradientView.gradient"
+      ],
+      "precedence": "gradient wins; background is the fallback fill, not a layer underneath it",
+      "ruling": "2026-08-07 (plan 51-E), raised by B with both ios paths measured. `background` and `gradient` fill the SAME surface, and the SSoT declares no precedence between them. Ruled: a declared gradient WINS, and background is what fills the surface when no gradient is declared or the face cannot produce one. Two grounds, both internal. FIRST, `gradient` is the more specific statement about the fill — an array of stops against a single colour — and this SSoT has already ruled that a more specific request must never render less than the general one (see textDecoration, where the object face may not draw less than the boolean). SECOND, the alternative readings do not survive their own consequences: if background won, then declaring a gradient on a view that also has a background — the ordinary case — would make the gradient silently inert, which is precisely the ios defect B is holding open; and a LAYERED reading (background painted, gradient composited over it) would require an alpha/compositing model that neither declaration mentions, and would make `background` visible-but-covered, i.e. unobservable and untestable. One surface, one fill, most specific wins. MEASURED STATE 2026-08-07: ios currently renders a THIRD answer — the declared gradient is always invisible, on both the codegen and dynamic paths (B: MODIFIER_ORDER puts :background adjacent to :gradient for views with children, and a childless View becomes `Rectangle().fill(background)` and never reaches the order table at all). Both paths are B's and F's to close, together. The other two faces do not contradict this ruling because they do not implement this attribute pair: `View.gradient` is declared `platform: swift`, kjui reads `gradient` only in GradientView and in the FROZEN xml drawable path, and rjui expresses a gradient through the `background` string itself (CSS gradient syntax, base_converter.rb:180). GradientView is unaffected — there the gradient is the component's whole purpose.",
+      "observable": {}
+    },
+    "selectBoxDate": {
+      "attributes": [
+        "SelectBox.selectedDate",
+        "SelectBox.selectItemType",
+        "SelectBox.prompt"
+      ],
+      "closedFaceWithNoSelection": "the prompt / hint / placeholder — never a fabricated date",
+      "ruling": "2026-08-07 (plan 51-E), raised by F with B's measurement agreeing: with `selectItemType: Date` and no `selectedDate`, ios shows an empty closed face while android and web show the current date/time. IOS IS CANON. `selectedDate` declares NO `default`, and by this SSoT's convention that makes it a modifier rather than an attribute that brings a value into existence — its absence means no initial selection has been stated, not 'today'. SelectBox already declares prompt / hint / placeholder, which is the mechanism for \"nothing chosen yet\", so the closed face has something correct to show and does not need to invent one. Two consequences make the android/web behaviour actively wrong rather than merely different: it is unobservable (a caller cannot distinguish 'no selection' from 'the user picked today'), and `selectedDate` is declared two-way, so seeding it writes today's date back into the viewmodel on first render without the user ever opening the picker — a default that silently manufactures data. Owners: C (android) and A (web).",
+      "observable": {}
+    },
+    "clipToBounds": {
+      "default": false,
+      "ruling": "2026-08-07 (plan 51-E), from E2's measurement: web does not clip by default, android does. Declared `default: false`. Two internal grounds, neither a head count. FIRST, `shadow` is a common attribute and a clipping parent destroys a child's shadow; a default that silently disables another common attribute contradicts the declaration that offers it. SECOND, the SSoT gives this concept exactly one spelling, the opt-in `clipToBounds`, and on a platform that already clips, declaring `clipToBounds: true` is INERT — an attribute you cannot observe declaring. Making false the default is what gives the attribute something to say on every platform: absent means no clip, `true` means clip. android is the deviant and the change is C's and G's; as with gravity, the canon is not in doubt but the rollout wants a measurement, since every container in every android project goes through this default.",
+      "observable": {},
+      "governsHitTesting": "yes — clipping removes the overflow from hit testing as well as from drawing; see attribute_semantics.json -> offset.overflowHitTesting"
+    },
+    "indicatorStopped": {
+      "attributes": [
+        "Indicator.animating",
+        "Indicator.hidesWhenStopped"
+      ],
+      "falseFace": "the stopped indicator is BOTH drawn and laid out",
+      "trueFace": "the stopped indicator collapses out of the layout entirely",
+      "ruling": "2026-08-07 (plan 51-E), raised by F before implementing: on the false face ios codegen keeps an `opacity(0)` spinner while dynamic emits EmptyView. BOTH ARE WRONG, in different directions, and the declaration already says so — Indicator.animating states that hidesWhenStopped 'decides whether the stopped indicator keeps its space or collapses out of the layout'. So `true` collapses it and `false` keeps it, which makes dynamic's EmptyView an implementation of the TRUE face on the false branch. codegen gets the space right and the visibility wrong: an attribute named hidesWhenStopped set to false cannot hide anything, and opacity(0) is hiding. The false face is a stopped indicator that is drawn AND occupies its space. CONSISTENT WITH the Wave 2 effect ledger, which removed hidesWhenStopped as spinner phase noise: that note is about MEASURABILITY, not about the contract. Where a platform cannot render a genuinely stopped spinner the fixture stays phase-noisy and effect-excluded; the ledger entry stands and does not license drawing nothing.",
+      "observable": {}
+    },
+    "effectStyle": {
+      "attributes": [
+        "common.effectStyle"
+      ],
+      "scope": "all three platforms, and not only on Blur — the declaration is on `common`",
+      "spellingCanon": "the nine bare names are canonical; the five system* spellings are declared valueAliases and the normalizer folds them",
+      "iosMaterialTable": {
+        "ultraThin": {
+          "material": ".ultraThinMaterial"
+        },
+        "thin": {
+          "material": ".thinMaterial"
+        },
+        "regular": {
+          "material": ".regularMaterial"
+        },
+        "thick": {
+          "material": ".thickMaterial"
+        },
+        "chrome": {
+          "material": ".bar"
+        },
+        "light": {
+          "material": ".thinMaterial",
+          "tint": "white 0.25",
+          "colorScheme": ".light"
+        },
+        "extraLight": {
+          "material": ".ultraThinMaterial",
+          "tint": "white 0.45",
+          "colorScheme": ".light"
+        },
+        "dark": {
+          "material": ".regularMaterial",
+          "tint": "black 0.40",
+          "colorScheme": ".dark"
+        },
+        "prominent": {
+          "material": ".thickMaterial",
+          "tint": "white 0.20"
+        }
+      },
+      "tintLayer": "above the material, BELOW the content — a Blur's children must not be washed by the tint",
+      "ruling": "2026-08-07 (plan 51-E). Three questions at once, from B (scope), F (the ios table) and E2 (spelling). SCOPE: three platforms, and not only on Blur. The attribute is declared on `common`, android and web apply it there, and only ios restricts it — so ios is the deviant, not the declaration. This intersects the inert_audit single-platform-scope family: those rows are ios gaps, not evidence for narrowing the scope. SPELLING: the nine bare names are canonical and the five system* spellings are already declared as `valueAliases`, so the normalizer folds them and no implementation needs to know both sets. E2's seven connected rows follow that fold. IOS TABLE: pinned above, from F's implementation in VisualEffectStyle.swift, which is adopted as canon. SwiftUI offers only five Material steps against nine spellings, so a naive mapping would collapse prominent/thick, light/thin, extraLight/ultraThin and dark/regular into four identical pictures and MANUFACTURE value_discrimination collapsedPairs — the table separates the colliding spellings with a tint instead. The tint sits above the material and below the content, which is the layer order `.background(.ultraThinMaterial)` already meant. The table lives in the LIBRARY once and both ios paths call it (F's VisualEffectStyle, B replacing the hardcoded `.ultraThinMaterial` at blur_converter.rb:65 with an emit that calls it) — the same single-table shape kjui took for DistributionFillRow, because two paths growing their own copy always desync. NOT ASSERTED HERE: that the nine render as nine distinct pixel sets. F declined to claim distinctness unmeasured and that is right; `chrome` (.bar) and `thick` are the closest pair. If the next ios run reports a collapsedPair, the fix is a tint on chrome, not a retreat from the table.",
+      "observable": {}
+    },
+    "autoShrink": {
+      "attributes": [
+        "Label.autoShrink",
+        "Label.minimumScaleFactor"
+      ],
+      "requiresBoundedAxis": "autoShrink is a no-op on an unbounded axis — there is nothing to shrink into",
+      "ruling": "2026-08-07 (plan 51-E), raised by A: web shrinks only until the text fits its box, while ios applies the shrink even under wrapContent (an adjustsFontSizeToFitWidth-shaped reading). WEB IS CANON. Shrinking is defined relative to a constraint, and `width: wrapContent` is declared to mean size-to-content — an axis that grows to whatever the text needs and therefore presents nothing to shrink into. Under ios's reading `autoShrink` changes the picture on a box that was never too small, which makes minimumScaleFactor a font-size multiplier rather than a floor, and that is not what either attribute declares (`minimumScaleFactor` declares min 0 / max 1 as a FLOOR for the shrink). So: autoShrink is active only on a bounded axis (an explicit size, matchParent, or a max bound), and is a no-op under wrapContent. Owner: B and F (both ios halves). Not urgent — no lane is blocked on it — but it is a canon question with an answer, not a next-Wave ledger row.",
+      "observable": {}
+    },
+    "collectionSeparators": {
+      "attributes": [
+        "Collection.hideSeparator",
+        "Collection.listStyle"
+      ],
+      "noOpWhereNoSeparators": "a container that draws no separators satisfies hideSeparator vacuously — that is a no-op by contract, not an unimplemented gap",
+      "orthogonality": "listStyle picks the chrome, hideSeparator hides the separators; neither overrides the other",
+      "ruling": "2026-08-07 (plan 51-E), raised by B: the ios probe path is CollectionStackView, not SwiftUI's List, and a container that is not a list has no separators to hide — so what should `hideSeparator` draw there? NOTHING, and that is the contract, not a gap. 'Hide the separators' is vacuously satisfied where there are none. The scope is deliberately NOT narrowed: the axis here is the container's rendered SHAPE (Collection's own `layout`, `columns` and `orientation` decide whether it is list-shaped), and `platform` / `mode` cannot express that — narrowing by platform would say something false. More importantly, 'implement it' must NOT mean 'switch the container to a List': an attribute that reshapes the thing it modifies is the defect family this wave exists to remove. hideSeparator modifies a list; it does not create one. MEASUREMENT CONSEQUENCE, so the ledgers do not mis-file it: the fixture must use a list-shaped Collection to observe this at all. Inert on a non-list container is the CONTRACT being honoured, and the coverage rows for both attributes are `runtime-only` (ios dynamic implements them; no codegen face does) rather than `unimplemented`. listStyle: enumerated here from the only implementation that reads it (SwiftJsonUI TableConverter.applyListStyle) as plain / grouped / insetGrouped / sidebar with plain the default — B was right that a bare string could not be validated or discriminated, and B should not replace the hardcoded PlainListStyle() until the vocabulary exists, which it now does. THE TWO ARE ORTHOGONAL. TableConverter.swift:45-49 currently lets `hideSeparator: true` win and forces .plain, which makes a declared `listStyle: \"grouped\"` silently inert whenever separators are hidden — the same silently-inert-declaration shape again. `.listRowSeparator(.hidden)` applies to any list style, so there is no need to force plain. Owner: F.",
+      "observable": {}
+    },
+    "offset": {
+      "attributes": [
+        "common.offsetX",
+        "common.offsetY"
+      ],
+      "layoutInvariance": "measurement and sibling placement are unchanged — the layout is computed first",
+      "interactiveRegion": "moves WITH the view: an offset control is tappable where it is drawn",
+      "androidPrimitive": "Modifier.absoluteOffset — NOT graphicsLayer { translationX/Y }, and not the RTL-mirroring Modifier.offset",
+      "ruling": "2026-08-07 (plan 51-E), asked by C and G as a one-line confirmation. It is not one line, because the declaration as I wrote it does not decide the question and I should say so rather than rubber-stamp it. C and G read 'paint-time translation' in the offsetX description as naming the Compose DRAW phase. That phrase was my shorthand for layout invariance, not a phase specification, and BOTH candidate primitives satisfy what the description actually says: Modifier.offset changes placement without changing measurement, so siblings do not move and the occupied space is unchanged, exactly as graphicsLayer does. The description has been reworded so the next reader does not have to re-derive that. THE DISCRIMINATOR the declaration was silent on is the INTERACTIVE REGION. A draw-phase translation leaves the touch target at the un-offset position, so the view is drawn in one place and tappable in another. Ruled: the interactive region moves with the view. The ground is internal — `onClick`, `onLongPress` and `canTap` are COMMON attributes that apply to every view, so an offset that decouples them from the drawn position silently breaks another common declaration, which is the same reason clipToBounds does not default to clipping (it would silently break `shadow`). A secondary reason: graphicsLayer forces a render layer and pulls in shadow/alpha/clip compositing side effects that a purely positional attribute has no business requesting. So the android primitive is Modifier.absoluteOffset, not graphicsLayer. ABSOLUTE and not plain Modifier.offset because this SSoT already separates the absolute axis vocabulary from the RTL-aware one — leftMargin/rightMargin against startMargin/endMargin — and `offsetX` is spelled on the X axis, so it must not mirror under RTL. NOT YET MEASURED, and stated as a request rather than a claim: that SwiftUI's .offset carries hit testing with it. The ruling is a design decision either way, but if ios turns out to strand the touch target then ios is the deviant and B/F own it — I am not asserting compliance I have not seen. B / F: please measure. 2026-08-07 addendum, F asking about the part of an offset view that escapes its parent, and rightly separating it from the primitive question above — SwiftUI hit-tests only inside the parent frame, which is a different mechanism from which modifier does the offsetting. Ruled, and it needs no new principle because two declarations already decide it: `clipToBounds` defaults to FALSE, so the overflow is DRAWN, and the ruling above says an offset control is tappable where it is drawn. Therefore the overflow is tappable. Hit testing follows CLIPPING, not the parent's frame, which leaves `clipToBounds` as the single control over both: declared true, the overflow is clipped and is then neither drawn nor tappable; left at its default, it is both. The alternative — drawn but not tappable — is precisely the draw/tap mismatch the offset ruling exists to forbid, so accepting it for the overflow would contradict the same contract one level out. SwiftUI's frame-bounded hit testing is therefore the deviation. It is real work rather than a flag (contentShape / an enlarged hit region), so if ios turns out not to be able to honour it, the honest outcome is a ledger row saying ios cannot — NOT a quiet divergence, and not a weakening of the contract for the other two. NOT MEASURED: android and web overflow hit testing. F supplied the ios half only. C / G / A: please measure yours before anyone implements, so the fix is aimed at the faces that actually deviate.",
+      "observable": {},
+      "overflowHitTesting": "hit testing follows CLIPPING, not the parent frame: an unclipped overflow is drawn and therefore tappable; a clipped one is neither"
+    },
+    "sliderRange": {
+      "attributes": [
+        "Slider.minimum",
+        "Slider.maximum",
+        "Slider.range",
+        "Slider.value",
+        "Slider.step"
+      ],
+      "defaultRange": "0 .. 1",
+      "ruling": "2026-08-07 (plan 51-E), raised by E2 with all three converters measured: none of them had a declared default to read, so each invented one — sjui `max || 1`, kjui and rjui `max || 100`. A layout writing `value: 0.5` therefore sits mid-track on ios and at half a percent on android and web. IOS IS CANON: the default range is 0 .. 1. The ground is this SSoT's own convention for a unitless value on a track, not a head count. `Progress.progress` declares `min: 0, max: 1` and `common.opacity` declares `min: 0, max: 1`; Progress is the Slider's closest sibling — a number along a track — and 100 would make Slider the only such attribute in the SSoT that is not normalised. It also keeps the round-trip coherent: `Slider.value` is declared two-way, so under a 0..100 default the control writes 0..100 back into a viewmodel whose author was writing 0..1. Declared as `default` on minimum and maximum so no converter has to invent it again; `range` is the [min, max] shorthand, so its absence means [0, 1] too. CONSEQUENCE FOR WEB, so that fixing the range does not break the control: `Slider.step` is declared platform:react with no default, and E2 measured web rounding 0.5 up to 1 under the old 0..100 range. With a 0..1 range an implicit step of 1 collapses the slider to two positions, so the web default step must be continuous (HTML `step=\"any\"`) unless the layout declares one. Owner: A for the step, A and C for the range.",
+      "observable": {}
     }
   }
 }

package/data/coverage.json

@@ -11,6 +11,14 @@
       "reason": "unimplemented",
       "note": "codegen 未対応。ランタイム側に実装あり (ios: UIKit) — この検査は Ruby codegen しか走査しないので、実装の有無ではなく codegen 対応の有無を表す"
     },
+    {
+      "component": "Slider",
+      "attribute": "range",
+      "platforms": [
+        "android"
+      ],
+      "reason": "unimplemented"
+    },
     {
       "component": "common",
       "attribute": "binding",

package/package.json

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