@contentful/experience-design-system-generation 2.32.1-dev-build-111fac0.0 → 2.32.1-dev-build-0e6dd6e.0

package/dist/package.json

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

package/dist/src/agent-runner.d.ts

@@ -111,7 +111,7 @@ export declare function agentSupportsBedrock(agent: AgentName): boolean;
  * agents whose model id changes shape under Bedrock (codex, opencode) — an
  * explicit value or env override is never rewritten.
  */
-export declare function resolveAgentModel(agent: AgentName, explicit?: string, bedrock?: boolean): string;
+export declare function resolveAgentModel(agent: AgentName, explicit?: string, bedrock?: boolean): string | undefined;
 export type AgentDebugEvent = (name: string, payload?: Record<string, unknown>) => void;
 export declare function buildArgs(agent: AgentName, prompt: string, model?: string, promptViaStdin?: boolean, bedrock?: boolean): string[];
 export declare function runAgent(options: {

package/dist/src/agent-runner.js

@@ -295,18 +295,21 @@ export function agentSupportsBedrock(agent) {
     return BEDROCK_CAPABLE_AGENTS.has(agent);
 }
 const DEFAULT_CODEX_BEDROCK_REGION = 'us-east-1';
+const DEFAULT_OPENCODE_MODEL = 'claude-haiku-4-5';
 /**
  * Default models per agent — lightweight/fast picks to control cost when no
  * explicit model is configured. cursor uses `gpt-mini` (verified alias from
- * GetUsableModels; haiku is not available in cursor's model catalog). codex's
- * default differs on Bedrock: the model id there carries an `openai.` prefix,
- * required by the Bedrock provider and absent from the direct api.openai.com
- * id.
+ * GetUsableModels; haiku is not available in cursor's model catalog).
+ *
+ * codex is deliberately absent: with no entry here it gets no `--model` at
+ * all, so the installed Codex CLI picks whatever its account supports. On
+ * Bedrock it still needs an explicit id, since the model id there carries an
+ * `openai.` prefix required by the Bedrock provider and absent from the
+ * direct api.openai.com id — see DEFAULT_CODEX_BEDROCK_MODEL.
  */
 const DEFAULT_MODELS = {
     claude: 'haiku',
-    codex: 'gpt-5.6-luna', // requires OPENAI_API_KEY; ChatGPT account users must pass --model
-    opencode: 'claude-haiku-4-5',
+    opencode: DEFAULT_OPENCODE_MODEL,
     cursor: 'gpt-mini', // cursor alias for gpt-5.4-mini-medium; haiku not in cursor's catalog
     copilot: 'Auto', // the only model guaranteed on every Copilot plan (Free/Pro/Business/Enterprise); Pro+ users override via EDS_AGENT_MODEL_COPILOT
 };
@@ -328,7 +331,7 @@ export function resolveAgentModel(agent, explicit, bedrock = false) {
     if (bedrock && agent === 'codex')
         return DEFAULT_CODEX_BEDROCK_MODEL;
     if (bedrock && agent === 'opencode')
-        return withBedrockProviderPrefix(DEFAULT_MODELS.opencode);
+        return withBedrockProviderPrefix(DEFAULT_OPENCODE_MODEL);
     return DEFAULT_MODELS[agent];
 }
 /**
@@ -353,7 +356,10 @@ function codexBedrockConfigArgs() {
     return ['-c', 'model_provider=amazon-bedrock', '-c', `model_providers.amazon-bedrock.region=${region}`];
 }
 export function buildArgs(agent, prompt, model, promptViaStdin = false, bedrock = false) {
-    const modelArg = ['--model', resolveAgentModel(agent, model, bedrock)];
+    // codex with no configured model resolves to undefined — omit --model
+    // entirely so the CLI picks its own account-compatible default.
+    const resolvedModel = resolveAgentModel(agent, model, bedrock);
+    const modelArg = resolvedModel ? ['--model', resolvedModel] : [];
     // When the prompt is delivered on stdin, omit it from argv — a large prompt
     // as a command-line argument overflows ARG_MAX (spawn E2BIG). All four CLIs
     // read the prompt from stdin when it isn't passed positionally.
@@ -387,7 +393,7 @@ export function buildArgs(agent, prompt, model, promptViaStdin = false, bedrock
             // value, so promptViaStdin will fail here — callers must pass the
             // prompt inline for copilot.
             const copilotModel = resolveAgentModel('copilot', model);
-            const copilotModelArg = copilotModel === 'Auto' ? [] : ['--model', copilotModel];
+            const copilotModelArg = !copilotModel || copilotModel === 'Auto' ? [] : ['--model', copilotModel];
             return ['-p', ...promptArg, ...copilotModelArg, '--allow-all-tools'];
         }
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@contentful/experience-design-system-generation",
-  "version": "2.32.1-dev-build-111fac0.0",
+  "version": "2.32.1-dev-build-0e6dd6e.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-111fac0.0"
+    "@contentful/experience-design-system-types": "2.32.1-dev-build-0e6dd6e.0"
   },
   "devDependencies": {
     "@tsconfig/node24": "^24.0.4",

package/skills/generate-components.md

@@ -91,7 +91,7 @@ Emit one JSON object per line. The CLI parses lines starting with `{`. Lines not
 - Every prop in the input must produce exactly one call: `classify_prop` OR `exclude_prop`.
 - Every slot must produce exactly one `classify_slot` call.
 - Emit `classify_component` once at the start (required). The `description` field is **required** — always provide a brief description of the component's purpose.
-- `values` is required for `cdf_type: "enum"` — must be a non-empty string array of the variant names the prop accepts.
+- `values` is required for `cdf_type: "enum"` — must be a non-empty string array of the variant names the prop accepts. **There is no legal `enum` with a guessed list.** If the value set is shown to you anywhere in the material below — the type's own declaration, an `allowedValues` list on the raw prop, a variant/lookup map, a default, a sibling excerpt — copy it and emit `enum`. If it is shown nowhere, emit `cdf_type: "string"` and leave `values` off. `string` is an unrestricted enum: the author can still pass the real value. A guessed list silently rejects it.
 - **Do NOT include `values` for `cdf_type: "token"`.** The two property types carry different kinds of list. An `enum` prop's list holds *variant names* the component accepts (`"primary"`, `"secondary"`). A `token` prop's list holds *design token paths* (`"color.brand.primary"`), produced by the separate token-mapping step (`$token.allowed`) — never by you. Emitting `values` on a token prop makes the definition invalid.
 - `token_kind` is required for `cdf_type: "token"` — must be a DTCG `$type` string, e.g. `"color"`.
 - `required` must be a JSON boolean (`true`/`false`), not a string.
@@ -208,12 +208,14 @@ the default "could be overridden" (every default can), or because the tie-break
 below exists. Nothing downstream re-derives, corrects, or second-guesses this —
 what you emit is what ships.
 
-**Ambiguity resolves to `enum` — but only when Q1–Q3 cannot be answered.** The
-tie-break applies solely when the source shown does not let you answer the three
-questions: the property is interpolated in one place and looked up in another,
-the use sits in a file you cannot see, or the source is truncated at the point
-of use (the "uses not shown" line). In those cases emit `enum` (or `string` when
-it has no value set) and record the ambiguity in `reason`. When the three
+**Ambiguity resolves to `enum` — but only when Q1–Q3 cannot be answered, and only
+when you can still cite its values.** The tie-break applies solely when the source
+shown does not let you answer the three questions: the property is interpolated
+in one place and looked up in another, the use sits in a file you cannot see, or
+the source is truncated at the point of use (the "uses not shown" line). In those
+cases emit `enum` if a value set is citable from the source shown, else `cdf_type:
+"string"` per "no legal `enum` with a guessed list" — either way, record the
+ambiguity in `reason`. When the three
 questions *can* be answered from the source shown, they are answered and the
 tie-break does not apply: a clear Q1-yes is `enum`, a clear Q2-yes + Q3-yes is
 `token`, and a type annotation does not create ambiguity. An `enum` is delivered
@@ -297,7 +299,7 @@ A prop with a complex TypeScript type is **not automatically excluded**. Many pr
 | Raw type pattern | How to resolve |
 |---|---|
 | `'primary' \| 'secondary' \| 'ghost'` (union of literals) | → `enum`, extract `values` |
-| `HeadingSize` / `ButtonVariant` / any named type that is clearly a finite set of visual options | → `enum`. **Never invent a value list.** Use only values you can cite from the source shown (the type's own declaration, a lookup table, a default). If the source shown does not enumerate the values, this is the "cannot be answered" case — apply "Ambiguity resolves to `enum`": emit `enum` (or `string` if it has no discoverable value set) and record the missing evidence in `description` (not `reason` — `description` ships to the CDF, `reason` does not), e.g. `"WARNING: values not visible in source — enum values unconfirmed"`. Do not default to a generic guess like `['sm', 'md', 'lg']` or `['primary', 'secondary']` — those are one design system's vocabulary, not a fallback for missing evidence. |
+| `HeadingSize` / `ButtonVariant` / any named type that is clearly a finite set of visual options | → `enum` if you can cite its values from the source shown (the type's own declaration, a lookup table, a default) — copy them, never invent them. If the source shown does not enumerate the values, this is not the Q1–Q3 ambiguity tie-break — it is the "no legal `enum` with a guessed list" rule: emit `cdf_type: "string"` instead, with the missing evidence noted in `reason`. Do not default to a generic guess like `['sm', 'md', 'lg']` or `['primary', 'secondary']` — those are one design system's vocabulary, not a fallback for missing evidence. |
 | `Variant` / `variant` prop | Usually a visual design variant. → `enum`, `cdf_category: "design"`. Same evidence rule as above — cite values from the source shown; do not invent them. |
 | `Section[]` / array of custom items where the structure is unclear | → `exclude_prop` only if the array elements are complex objects with no obvious flat representation. If items are simple (title, label, id), consider representing as `string` (a comma-separated IDs or keys) or note in `description` why. |
 | `ExperienceConfiguration<Variant>` / deep generic | Personalization config — → `exclude_prop`, reason: `"personalization configuration — framework internal"` |
@@ -462,14 +464,30 @@ footer is supplementary and optional
 {"tool":"classify_slot","slot":"footer","required":false,"description":"Optional footer area for actions or metadata","rationale":"Footer is a supplementary region typically used for actions or metadata. Optional because most cards do not need one and the card renders correctly without it."}
 ```
 
-### Named type (HeadingSize, ButtonVariant, etc.)
+### Named type (HeadingSize, ButtonVariant, etc.) — do NOT infer the values
 
-When a prop has a named TypeScript type that is not inlined as a union literal, reason from the prop name and type name to infer the finite value set.
+When a prop has a named TypeScript type that is not inlined as a union literal,
+the value set is whatever that type's declaration says. A type *name* is not
+evidence of its members: `HeadingSize` could be `h1`–`h6`, `sm|md|lg`, or
+`s|m|l|xl`. Guessing picks one design system's vocabulary and is wrong more
+often than it is right, and a wrong name matches no style rule — the author's
+setting silently does nothing.
 
+So: look for the declaration in the source shown. If it is there, copy it. If it
+is not, **emit `string`** — `string` is an unrestricted enum, so the author stays
+unrestricted but correct.
+
+Members visible in the source shown — copy them, do not paraphrase:
+```
+titleSize has type HeadingSize; HeadingSize is declared in the excerpt as 'sm' | 'md' | 'lg'
+{"tool":"classify_prop","prop":"titleSize","cdf_type":"enum","cdf_category":"design","required":false,"values":["sm","md","lg"],"description":"Heading size","reason":"Copied from the HeadingSize declaration shown in the excerpt."}
+```
+
+Members NOT visible in the source shown — degrade to `string`:
 ```
-titleSize has type HeadingSize — this is a named enum controlling heading size
-inferring likely values: ["h1", "h2", "h3", "h4", "h5", "h6"] — documenting inference
-{"tool":"classify_prop","prop":"titleSize","cdf_type":"enum","cdf_category":"design","required":false,"values":["h1","h2","h3","h4","h5","h6"],"description":"Heading level — inferred from HeadingSize type name; actual values may be h1–h6 or sm/md/lg"}
+titleSize has type HeadingSize; HeadingSize is not declared anywhere in the source shown
+no evidence for its members, so no values list — string, not a guess
+{"tool":"classify_prop","prop":"titleSize","cdf_type":"string","cdf_category":"design","required":false,"description":"Heading size","reason":"HeadingSize is not declared in the source shown, so its members cannot be cited. Emitted as string rather than inventing a value list."}
 ```
 
 ### href prop
@@ -495,7 +513,7 @@ Before emitting any tool calls, verify:
 1. Every prop in the input has exactly one `classify_prop` or `exclude_prop` call
 2. Every slot has exactly one `classify_slot` call
 3. `classify_component` is emitted exactly once
-4. Every `cdf_type: "enum"` has a non-empty `values` array
+4. Every `cdf_type: "enum"` has a non-empty `values` array taken from the material shown. A prop whose value set was shown nowhere is `cdf_type: "string"` with no `values` — never an `enum` with a plausible-looking list, and never an `exclude_prop`.
 5. Every `cdf_type: "token"` has `token_kind` (or a warning in `description` if lookup failed) and does **not** have `values` set
 6. No `cdf_type: "link"` — all href/url props use `string`
 7. `required` values are JSON booleans, not strings
@@ -507,7 +525,7 @@ Before emitting any tool calls, verify:
 13. `rationale.description` follows the same "Description content rules" as `description` — no internal initiative names (`INTEG-*`, `EDSI`, `DSI`, `M1`, `M2`, wave/phase references, etc.).
 14. Every `cdf_type: "token"` prop cites a line that interpolates its value into a style **and** a token reference at that use (Q2 yes, Q3 yes), and carries no `values`. If you cannot cite both, it is `enum` or `string`; if you can, it is `token` — its type annotation is not a reason to emit `string`.
 15. Every prop whose values are friendly names is `enum` with a non-empty `values` array, even when each name resolves to a design token internally; every prop for which Q1–Q3 could not be answered was emitted as `enum` (or `string`) with the ambiguity stated in `reason`, and no answerable prop was called ambiguous.
-16. Every `enum`'s `values` array is copied from evidence in the source shown (a type declaration, lookup table, or default) — none of it was invented. Where no evidence exists for the values, the `description` states so (e.g. `"WARNING: values not visible in source"`), not just `reason`.
+16. Every `enum`'s `values` array is copied from evidence in the material shown — a type declaration, an `allowedValues` list on the raw prop, a variant or lookup map, a default, in the component's own file or in any sibling excerpt — and none of it was invented. Where the value set appears nowhere, the prop is `cdf_type: "string"`, with the reason recorded in `reason`. Do not drop a prop merely because you could not enumerate its values.
 
 After the run completes, the developer can validate the pipeline output with:
 
@@ -528,4 +546,6 @@ properties — this is never acceptable.
 If you are genuinely uncertain about every prop, classify each as:
 {"tool":"classify_prop","prop":"<name>","cdf_type":"string","cdf_category":"content","required":false,"description":"Uncertain classification — review recommended"}
 
-An imperfect classification is infinitely better than no classification.
+An imperfect classification is infinitely better than no classification. That is
+about **classifying a prop rather than dropping it** — it is not a licence to
+invent a `values` list. The uncertain answer is `cdf_type: "string"`, every time.