@contentful/experience-design-system-generation 2.28.1-dev-build-090b2d1.0 → 2.28.1-dev-build-2497ca0.0

package/dist/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@contentful/experience-design-system-generation",
-  "version": "2.28.1-dev-build-090b2d1.0",
+  "version": "2.28.1-dev-build-2497ca0.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

@@ -86,8 +86,6 @@ export interface ParsedTokenToolCalls {
 export interface ParsedToolCalls {
     calls: ToolCall[];
     warnings: string[];
-    /** True when a line was lost outright (unparseable, or no `tool` field) — a retry signal, distinct from a parsed-but-rejected call. */
-    hadDroppedLine: boolean;
 }
 export declare function parseToolCallLines(stdout: string): ParsedToolCalls;
 export declare function parseTokenToolCallLines(stdout: string): ParsedTokenToolCalls;

package/dist/src/agent-runner.js

@@ -26,13 +26,12 @@ function findJsonObjectEnd(line) {
     return -1;
 }
 /**
- * Reads an agent's stdout into tool-call objects; non-`{` lines are prose.
- * `hadDroppedLine` is true only when a line is lost outright, not rejected later.
+ * Reads an agent's stdout into the tool-call objects it carries. Lines that do
+ * not start with `{` are the agent's prose and are skipped silently, as before.
  */
 function readToolCallObjects(stdout) {
     const objects = [];
     const warnings = [];
-    let hadDroppedLine = false;
     for (const raw of stdout.split('\n')) {
         const line = raw.trim();
         if (!line.startsWith('{'))
@@ -40,7 +39,6 @@ function readToolCallObjects(stdout) {
         const end = findJsonObjectEnd(line);
         if (end === -1) {
             warnings.push(`unparseable line: ${line.slice(0, 120)}`);
-            hadDroppedLine = true;
             continue;
         }
         let parsed;
@@ -49,7 +47,6 @@ function readToolCallObjects(stdout) {
         }
         catch {
             warnings.push(`unparseable line: ${line.slice(0, 120)}`);
-            hadDroppedLine = true;
             continue;
         }
         const trailing = line.slice(end + 1);
@@ -59,11 +56,8 @@ function readToolCallObjects(stdout) {
         if (typeof parsed === 'object' && parsed !== null && 'tool' in parsed) {
             objects.push(parsed);
         }
-        else {
-            hadDroppedLine = true;
-        }
     }
-    return { objects, warnings, hadDroppedLine };
+    return { objects, warnings };
 }
 export function parseSelectToolCallLines(stdout) {
     const calls = [];
@@ -99,7 +93,7 @@ const VALID_CDF_TYPES = new Set(['string', 'richtext', 'media', 'enum', 'token',
 const VALID_CATEGORIES = new Set(['content', 'design', 'state']);
 export function parseToolCallLines(stdout) {
     const calls = [];
-    const { objects, warnings, hadDroppedLine } = readToolCallObjects(stdout);
+    const { objects, warnings } = readToolCallObjects(stdout);
     for (const rec of objects) {
         if (!VALID_TOOL_NAMES.has(rec.tool)) {
             warnings.push(`unknown tool: ${String(rec.tool)}`);
@@ -187,7 +181,7 @@ export function parseToolCallLines(stdout) {
             calls.push(call);
         }
     }
-    return { calls, warnings, hadDroppedLine };
+    return { calls, warnings };
 }
 export function parseTokenToolCallLines(stdout) {
     const calls = [];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@contentful/experience-design-system-generation",
-  "version": "2.28.1-dev-build-090b2d1.0",
+  "version": "2.28.1-dev-build-2497ca0.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.28.1-dev-build-090b2d1.0"
+    "@contentful/experience-design-system-types": "2.28.1-dev-build-2497ca0.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. **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.
+- `values` is required for `cdf_type: "enum"` — must be a non-empty string array of the variant names the prop accepts.
 - **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,14 +208,12 @@ 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, 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
+**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
 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
@@ -299,7 +297,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` 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. |
+| `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. |
 | `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"` |
@@ -366,7 +364,7 @@ as enum so the author picks "primary" and the component receives "primary".
 
 ---
 
-## Category and required corrections
+## Category correction rules
 
 The pre-classified `category` is wrong in predictable ways. Correct silently (document in `description`):
 
@@ -377,11 +375,6 @@ The pre-classified `category` is wrong in predictable ways. Correct silently (do
 
 > **Key question for category**: "Who fills this in?" — A content editor fills in `content`. A designer configures `design`. Neither fills in `state` — it comes from routing, runtime behavior, or component infrastructure.
 
-**`required` is also a hint, and it is also wrong.** Verify it against the declaration:
-- A prop with a default value — a `$default`, a destructure default, or a `defaultVariants` entry — is **never** `required: true`. The two together are incoherent.
-- A prop declared `foo?:` is `required: false`, whatever the hint says.
-- Props reached through `VariantProps<typeof x>` or a Radix/`ComponentPropsWithoutRef` base are optional unless the component's own interface redeclares them as required.
-
 ---
 
 ## Slot classification
@@ -469,30 +462,14 @@ 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.) — do NOT infer the values
-
-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.
+### Named type (HeadingSize, ButtonVariant, etc.)
 
-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."}
-```
+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.
 
-Members NOT visible in the source shown — degrade to `string`:
 ```
-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."}
+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"}
 ```
 
 ### href prop
@@ -518,7 +495,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 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`.
+4. Every `cdf_type: "enum"` has a non-empty `values` array
 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
@@ -530,8 +507,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 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.
-17. No prop has `required: true` alongside a default value (`$default`, a destructure default, or a `defaultVariants` entry) — the two are incoherent. A prop declared `foo?:`, or reached through `VariantProps<typeof x>` or a Radix/`ComponentPropsWithoutRef` base without its own required redeclaration, is `required: false`.
+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`.
 
 After the run completes, the developer can validate the pipeline output with:
 
@@ -552,6 +528,4 @@ 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. 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.
+An imperfect classification is infinitely better than no classification.