@contentful/experience-design-system-generation 2.32.1-dev-build-b7d2d34.0 → 2.32.1-dev-build-71db090.0

package/dist/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@contentful/experience-design-system-generation",
-  "version": "2.32.1-dev-build-b7d2d34.0",
+  "version": "2.32.1-dev-build-71db090.0",
   "description": "Agent-invocation and skill-prompt engine for the Contentful Experience Design System SDK",
   "license": "MIT",
   "type": "module",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@contentful/experience-design-system-generation",
-  "version": "2.32.1-dev-build-b7d2d34.0",
+  "version": "2.32.1-dev-build-71db090.0",
   "description": "Agent-invocation and skill-prompt engine for the Contentful Experience Design System SDK",
   "license": "MIT",
   "type": "module",
@@ -22,7 +22,7 @@
     "skills/"
   ],
   "dependencies": {
-    "@contentful/experience-design-system-types": "2.32.1-dev-build-b7d2d34.0"
+    "@contentful/experience-design-system-types": "2.32.1-dev-build-71db090.0"
   },
   "devDependencies": {
     "@tsconfig/node24": "^24.0.4",

package/skills/generate-components.md

@@ -556,19 +556,19 @@ invent a `values` list. The uncertain answer is `cdf_type: "string"`, every time
 
 The preamble may include an "Existing components in the target Contentful space" JSON block with a `likelyMatch` (a fuzzy-matched space component that likely corresponds to the codebase component you're classifying), an `otherComponents` list, and a rolled-up token summary. Use it to align your classifications with what the customer already has.
 
-### When `likelyMatch` is present — align prop names, categories, and slot names
+### When `likelyMatch` is present — align rename intent + categories + slot names
 
-Your goal is **consistency**: the customer will see the diff between what you propose and what already exists, and every unnecessary rename or category flip becomes review friction.
+Your goal is **consistency**: the customer will see the diff between what you propose and what already exists, and every unnecessary category flip or slot-shape mismatch becomes review friction.
 
-1. **Prop names**: if the codebase has a prop whose meaning matches a `likelyMatch` design/content property (e.g. codebase `kind` ↔ space `variant`, codebase `text` ↔ space `label`), emit `classify_prop` with the **space's prop name** rather than the codebase name. In the `reason` field, always explain the rename explicitly, e.g. `"renamed from codebase prop 'kind' to match existing space prop 'variant'"`. If you can't confidently identify the correspondence, keep the codebase name.
+1. **Prop names**: `classify_prop.prop` MUST always be the codebase prop name — that's the DB lookup key. When a codebase prop looks like it corresponds to an existing space prop (e.g. codebase `kind` ↔ space `variant`, codebase `text` ↔ space `label`), keep `prop` as the codebase name and put the alignment note in `reason`, e.g. `"looks like existing space prop 'variant' — customer may want to reconcile at review"`. Never rewrite `prop` itself; reconciliation happens downstream, not in this tool call.
 2. **Categories**: match the space's category (`design` / `content`) for equivalent props, even if you'd normally categorize differently. Note the alignment in `reason`.
 3. **Slot names**: match slot IDs / names when the shape is equivalent.
 4. **Enum values**: never invent new values to bridge a mismatch. If the codebase's enum diverges from the space's, classify against your best-effort mapping and cite the divergence in `reason` — this is a signal for human review, not a green light to rewrite the space's enum.
-5. **Never rename or realign silently.** Every classification influenced by the `likelyMatch` MUST cite it in `reason`.
+5. **Never realign silently.** Every classification influenced by the `likelyMatch` MUST cite it in `reason`.
 
 ### When only `otherComponents` is present (no direct match)
 
-Use the list to constrain slot `allowedComponents` — do not propose a slot that accepts component types the space doesn't have.
+Use the list to constrain slot `allowed_components` — do not propose a slot that accepts component types the space doesn't have.
 
 ### Token binding