@adobe/design-data-spec 4.13.0 → 4.14.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@adobe/design-data-spec",
-  "version": "4.13.0",
+  "version": "4.14.1",
   "description": "Design Data Specification — prose, JSON Schemas, rule catalog, and conformance fixtures for the design data format",
   "type": "module",
   "repository": {

package/rules/rules.yaml

@@ -1153,3 +1153,20 @@ rules:
     message: "Derived context '{context}' of '{component}' ({from}): the token value differs from the formula at {scale} for {sizes}"
     spec_ref: spec/component-visuals.md#derived-contexts
     introduced_in: "1.0.0-draft"
+
+  - id: SPEC-088
+    name: relationship-duplicate-record
+    severity: warning
+    layer: 2
+    category: relationship
+    note: >
+      An exact duplicate adds nothing to resolution, and a changelog that pairs records by
+      identity cannot tell the copies apart. Records with different `setUuid` are not duplicates.
+      SPEC-072 may also report a pair whose token has a scale counterpart, so the two rules can
+      overlap.
+    assert: >
+      Two relationship records in the same file SHOULD NOT have equal scope, context,
+      `$ref` (or inline value) and `setUuid`.
+    message: "Relationship {scope} (context '{context}') repeats an earlier record with the same {ref_or_value}; remove the duplicate"
+    spec_ref: spec/relationship-format.md
+    introduced_in: "1.0.0-draft"

package/spec/component-visuals.md

@@ -239,6 +239,8 @@ The scene graph is the contract between resolution and output:
 
 A build step **MAY** pre-resolve every `token` and `relationship` binding per `size|colorScheme|scale` into a ranked list of candidates (`{value, token, states}`), so a renderer needs no token graph. Only state-dependent selection remains at render time: take the first candidate whose `states` all apply, else the first. Backends that consume compiled recipes (for example the dependency-free JS runtime emitted by `design-data site`) **MUST** produce the same scene as the Rust reference renderer; the reference renderer is the source of truth and parity is tested.
 
+A compiled recipe **MUST NOT** depend on the request's `icon`: the request icon is applied when the scene is solved. For this a compiled content icon part (`icon.content: true`) carries `iconChoices`, an object mapping `set:name` to the key in the recipe's `drawings` of that icon's drawing at the part's scale (an icon with no usable drawing is absent), so a backend with one precompiled variant and no icon catalog can honour the request icon with the rules in [Icons](#icons). `iconChoices` is absent when the build had no icon catalog. Backends that predate `iconChoices` ignore it, and the existing `drawing`, `drawingMiss` and `drawings` fields are unchanged.
+
 ## Backend and tooling decisions (research outcomes)
 
 These record the research behind this draft and are not normative.