@contentful/experience-design-system-cli 2.42.1-dev-build-f69db6bf.0 → 2.42.1-dev-build-fb965e69.0

package/skills/generate-tokens.md

@@ -185,10 +185,4 @@ Before emitting any tool calls, verify:
 6. No duplicate paths.
 7. `set_group` calls precede the `set_token` calls under them.
 
-After the run, the developer can validate with:
-
-```
-experience-design-system-cli print validate --tokens <out-path>
-```
-
-Re-run or iterate on any tokens flagged by warnings until validation passes.
+Before finishing, review the token output against this checklist and iterate on any warning the supplied input can resolve. Preserve unresolved warnings in the token `description`; do not guess values.

package/skills/map-tokens.md

@@ -26,7 +26,7 @@ If no token path index is provided, there is nothing to narrow against — do no
 
 For each design-category, token-typed prop shown in the "Generated CDF so far" section:
 
-1. **Prop type is a union of variant names** (e.g. `'primary' | 'secondary'`)? That prop should not be a `token` at all — the component receives a name and resolves it, which is the `enum` case in the classification step. Do not narrow it; narrowing cannot repair a wrong type. Emit nothing, and note in a prose line that it looks misclassified.
+1. **Prop type is a union of variant names** (e.g. `'primary' | 'secondary'`)? That prop should not be a `token` at all — the component receives a name and resolves it, which is a primitive with typed `values` in the classification step. Do not narrow it; narrowing cannot repair a wrong type. Emit nothing, and note in a prose line that it looks misclassified.
 2. **A default value or `tokenReference` is the prop's default, not a restriction.** `padding = tokens.spacingM` or a structured `tokenReference` tells you which token the prop *starts* on — it does not say the author may choose no other. Narrowing to that single path would leave the marketer one option, which is worse than no list. On its own, this evidence yields no tool call. If you narrow on other grounds (step 3), the default's path must be in the list.
 3. **Look for an explicit restriction** in the component source or its siblings: a comment naming the valid tokens, or code that validates/maps the prop against a fixed list of token paths (an allowlist array, a `satisfies` over specific token keys). If found, emit `$token.allowed` as the evidenced subset, scoped to tokens of the prop's `$token.kind`.
 4. **No explicit restriction?** Emit nothing. Omitting the list means "any token of this kind," which is correct and live — a guessed list is worse than none because it freezes the author's choices.

package/skills/select-components.md

@@ -2,7 +2,7 @@
 
 ## Purpose
 
-Review the extracted React/Next.js component(s) provided below and decide whether each belongs in **Contentful Experience Orchestration** as a Component Type. The input is a JSON array — you may receive 1–N components in a single message. Output one JSON tool call per input component to stdout, named after the component. Tool calls may appear in any order.
+Review the extracted component definition(s) provided below and decide whether each belongs in **Contentful Experience Orchestration** as a Component Type. Use the supplied framework and source evidence; supported inputs may come from more than one UI framework. The input is a JSON array — you may receive 1–N components in a single message. Output one JSON tool call per input component to stdout, named after the component. Tool calls may appear in any order.
 
 ---
 
@@ -20,59 +20,14 @@ The entity being defined — a **Component Type** — is the schema that tells C
 
 ---
 
-## The one rule: is this the author-facing UI component?
+## Source purpose and inclusion
 
-**Accept** the component if it is the component that directly defines the author-facing UI surface — regardless of whether it is an atom, molecule, or organism, and regardless of whether it has many or few configurable props. A footer icon with two props (`icon`, `label`) is just as valid as a parallax hero with fifteen props.
-
-**Reject** the component if its primary purpose is framework or data-loading infrastructure rather than the author-facing UI surface:
-
-- It is a React hook (name starts `use` or `Use`)
-- It is a pure context provider with no visual output
-- It is a Ninetailed/personalization platform wrapper (its job is routing to variants, not rendering content)
-- It is a data-fetch wrapper that loads data for a sibling renderer and then forwards that data into the sibling renderer
-- It is an analytics/event-tracking component (fires events, renders nothing)
-- It is a security or infrastructure utility (no UI at all)
-
----
-
-## What NOT to use as a rejection reason
-
-These are **not** valid reasons to reject a component:
-
-| Invalid reason                                     | Why it is wrong                                                                                                           |
-| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
-| "Only atoms/low-level"                             | Atoms are first-class Component Types in Contentful Experience Orchestration                                              |
-| "Tightly coupled to a parent component"            | Contentful Experience Orchestration handles composition at the experience layer                                           |
-| "Has A/B testing or personalization-related props" | These props are classified as `state` or excluded in the generate step — their presence does not disqualify the component |
-| "Has no marketer-configurable props"               | Marketers are not the only users; designers and developers configure components too                                       |
-| "Domain-specific or feature-level"                 | Press releases, newsrooms, search — all valid content components                                                          |
-| "Server-side or SSR"                               | Server components that render visible UI are valid                                                                        |
-| "Few configurable props"                           | One or two props is fine                                                                                                  |
-
----
-
-## Reject only these categories
-
-| Category                                    | Why                                                                                                                                                                 |
-| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **React hooks**                             | `useXxx` / `UseXxx` — functions, not renderable components. Zero visual output.                                                                                     |
-| **Pure context providers**                  | Wrap children to pass context but render no UI themselves                                                                                                           |
-| **A/B testing or personalization wrappers** | Components whose _entire purpose_ is routing users to content variants or tracking experiment participation — they render no UI of their own                        |
-| **Data-fetch wrappers**                     | Components whose job is to load or resolve data for a sibling renderer. Even if they eventually return visible UI, the sibling renderer is the real Component Type. |
-| **Analytics and event tracking**            | Components that only fire analytics events and render nothing visible                                                                                               |
-| **Security utilities**                      | Non-visual security primitives with no rendered output                                                                                                              |
-
-> **Variant routing rule**: Reject a component if its entire purpose is deciding _which_ content variant to show — that is framework infrastructure, not a Component Type. Do **not** reject a component merely because it _contains_ some A/B testing or personalization-related props — those props are handled as `state` in the generate step.
-
-> **Data-fetch wrapper rule**: Reject a component if it imports or calls a generated query hook, loads data, and then forwards that data into a sibling renderer. The sibling renderer is the Component Type; the data-loader wrapper is not.
-
-> **Utility-wrapper rule**: Reject a component if **all three** of the following are true:
->
-> 1. It has no props that meaningfully shape user-facing content (no text strings, headings, image URLs, links, body content, rich text, or media references).
-> 2. The props it does have are purely structural or behavioral — e.g., `container`, `target`, `as`, `asChild`, render-prop callbacks, internal `ref` forwarding, focus/portal targets, debug toggles, or `children` only.
-> 3. It is a utility wrapper rather than a composable content surface. Concrete examples to reject under this rule: `Portal`, `SrOnly` (screen-reader-only wrappers), `FocusTrap`, `ErrorBoundary`, `Suspense` fallbacks, debug-only wrappers, and provider-shaped components whose only job is to forward children.
->
-> Use `reject_component` with a reason like `"Utility wrapper — no authorable content surface"` or `"Structural-only component — no user-shaping props"`. This rule is additive to the categories above; do **not** use it to reject a component that has even one author-shaping prop (e.g., a `label`, `title`, `text`, `href`, `src`, or `richText` prop) — those still belong as Component Types per the "one rule" above.
+Assess the component's declared purpose, visible/configurable surface and actual flow from the supplied source and renderer contract.
+Do not use component names, framework families, property counts, styles, callback shapes, structural-only inputs or a known component pattern as an authorability recipe.
+A renderable input, including a render callback, may be a source-supported configurable region even when its observed callers are missing or text-only.
+Reject only when the supplied source establishes why the entity is outside the target component contract; absence from bounded excerpts is uncertainty.
+A wrapper's behavior and delegated data are evidence to inspect, not a blanket rejection rule.
+Preserve uncertain inclusion for human review and explain what the source supports.
 
 ## Using `selectionContext`
 
@@ -84,6 +39,16 @@ If the input includes `selectionContext`, treat it as the only repo-level contex
 - resolver or registry references
 - one likely parent usage site
 
+## Source evidence and selection uncertainty
+
+- Make acceptance or rejection decisions from the supplied definition and captured evidence. Component names, framework labels, familiar patterns, prop counts, or a likely match in an existing model do not prove the component's purpose or rendering behavior by themselves.
+- Captured source references, observations, and parent usage are bounded context. A single caller shows an example of use, not the complete contract or all uses. Missing callers, imports, sibling files, or excerpts do not prove that a component is unused, non-rendering, or an infrastructure wrapper.
+- Treat existing model summaries as optional alignment context. They cannot force acceptance or rejection, and a mature model does not change the evidence required for a decision.
+- When evidence does not establish whether a component defines author-facing UI, preserve that uncertainty in the reason and lower confidence. Do not turn missing evidence into a rejection.
+- The inline context does not provide repository tools, filesystem or working-directory access, a complete compiler graph, final consensus, or an authorability guarantee.
+
+The example component names below are illustrative. Apply an example's decision only when the supplied evidence supports the described behavior; a name alone is not evidence.
+
 Use that bounded context to distinguish the author-facing renderer from infrastructure wrappers. In particular:
 
 - If the component imports a sibling renderer and mainly forwards fetched data into it, reject the wrapper and prefer the sibling renderer.
@@ -121,115 +86,11 @@ Emit one JSON object on a single line. Lines not starting with `{` are ignored b
 
 ---
 
-## Examples
-
-```
-Analytics — fires analytics events, no visual output
-{"tool":"reject_component","name":"Analytics","reason":"analytics tracker — no visual output"}
-```
-
-```
-CanaryToken — security utility, no visual output
-{"tool":"reject_component","name":"CanaryToken","reason":"security utility — no visual output"}
-```
-
-```
-ClientExperience — personalization wrapper whose entire purpose is routing users to content variants
-{"tool":"reject_component","name":"ClientExperience","reason":"variant routing wrapper — entire purpose is A/B routing, not rendering UI"}
-```
-
-```
-ComponentMarker — experimentation marker component, no visual output
-{"tool":"reject_component","name":"ComponentMarker","reason":"experimentation marker — no visual output"}
-```
-
-```
-ComponentTracker — variant attribution tracker, no visual output
-{"tool":"reject_component","name":"ComponentTracker","reason":"variant attribution tracker — no visual output"}
-```
-
-```
-Refresh — client-side route refresh utility for personalization platform, no visual output
-{"tool":"reject_component","name":"Refresh","reason":"personalization route refresh utility — no visual output"}
-```
-
-```
-ServerExperience — server-side variant routing wrapper, no visual output
-{"tool":"reject_component","name":"ServerExperience","reason":"server-side variant routing wrapper — no visual output"}
-```
-
-```
-UseHelpNavigation — React hook, not a renderable component
-{"tool":"reject_component","name":"UseHelpNavigation","reason":"React hook — not a renderable component"}
-```
-
-```
-Providers — React context provider with no visual output
-{"tool":"reject_component","name":"Providers","reason":"pure context provider — no visual output"}
-```
-
-```
-HeroBannerGql — fetch wrapper that loads data and forwards it into HeroBanner
-It may eventually return visible UI, but the author-facing component is HeroBanner, not HeroBannerGql.
-{"tool":"reject_component","name":"HeroBannerGql","reason":"data-fetch wrapper — loads data for a sibling renderer rather than defining the author-facing UI surface"}
-```
-
-```
-FooterIcon — atom: renders an icon with optional label in the footer
-{"tool":"select_component","name":"FooterIcon","reason":"UI atom — renders icon with configurable icon and label"}
-```
-
-```
-FeedbackModal — modal dialog with visibility state
-{"tool":"select_component","name":"FeedbackModal","reason":"modal UI component with configurable visibility and content"}
-```
-
-```
-ActiveFilters — renders active filter chips with remove controls
-{"tool":"select_component","name":"ActiveFilters","reason":"filter UI component — renders visible filter chips"}
-```
-
-```
-FullSizeBarNoContent — full-width text bar with link; has some personalization state props
-The personalization props (hideContentForPersonalization, componentId) are state props handled in the generate step.
-The component renders real visual UI — a bar with text, chevron, and link.
-{"tool":"select_component","name":"FullSizeBarNoContent","reason":"content bar UI — renders visible bar with configurable text, link, and design"}
-```
-
-```
-ParallaxComponent — parallax marketing section; has some A/B testing props alongside real content props
-The A/B testing props (abmFallback, abmLinkedFromAccount) are state props, not the component's primary purpose.
-The component renders a parallax section with title, subtitle, and visual effects.
-{"tool":"select_component","name":"ParallaxComponent","reason":"marketing section UI — renders parallax content with configurable title, subtitle, and design"}
-```
-
-```
-NewsroomLandingPressReleases — press release list with pagination and locale
-{"tool":"select_component","name":"NewsroomLandingPressReleases","reason":"content list UI — renders press releases with configurable locale and pagination"}
-```
-
-```
-ServerHelpNavigation — server-side navigation with configurable search visibility and locale
-{"tool":"select_component","name":"ServerHelpNavigation","reason":"navigation UI — renders help navigation with configurable locale and search toggle"}
-```
-
-```
-TextImageCard — card with rich text and background image
-{"tool":"select_component","name":"TextImageCard","reason":"content card UI — configurable rich text, image, and layout"}
-```
-
-```
-SearchInput — search field with dropdown
-{"tool":"select_component","name":"SearchInput","reason":"search UI — configurable placeholder and state"}
-```
-
----
-
 ## Existing entities in the target space
 
 The preamble may include an "Existing components in the target Contentful space" JSON block and a rolled-up token summary. Use them as **signal, not as a filter**. Rules:
 
-1. Never let a name overlap force a decision. Acceptance is still driven purely by "does the codebase component render visible, authorable UI?" — a name match does not auto-accept, and a name conflict does not auto-reject.
+1. Never let a name overlap force a decision. Decide from supplied evidence about whether the component renders visible, author-facing UI; a name match does not auto-accept, and a name conflict does not auto-reject.
 2. When a codebase component appears to correspond to an existing space component (name overlap, semantic overlap in the description), note it in your `reason` — e.g. `"accepted; likely maps to existing space component 'Button'"`. This surfaces the mapping for downstream review.
-3. When the space is mature (many existing components, dozens of tokens) and the codebase has thin wrappers with no visible UI difference, lean harder toward rejecting the wrappers. Extra noise in a mature space is more costly than in an empty one.
+3. A mature space does not change the evidence threshold for deciding whether a component is an author-facing UI surface. Record possible duplication for review without using model size to reject a component.
 4. When no overlap exists, the acceptance decision is unchanged from the rules above.

package/dist/src/tui/import/steps/10-flow/support/use-timed-spinner.d.ts

@@ -1,4 +0,0 @@
-export declare function useTimedSpinner(): {
-    spinner: React.ReactElement;
-    elapsed: string;
-};