@pega/sdk 0.0.2 → 0.0.3

package/templates/react-sdk-reference/.github/skills/widget-components.md

@@ -51,12 +51,14 @@ interface AttachmentProps extends Omit<PConnFieldProps, 'value'> {
 
 ### Data-Fetching Widget
 
-Widgets typically fetch data from Pega data pages on mount:
+Widgets typically fetch data from Pega data pages on mount. This pattern is design-system agnostic. The `// [DS RENDER]` section must be replaced with your design system's presentation primitives (card, list, table, etc.) — see "Design System Adaptation" below.
 
 ```typescript
 import { useState, useEffect } from 'react';
-import { Card, CardHeader, CardContent, List, ListItem } from '@mui/material';
-import type { PConnProps } from '../../../types/PConnProps';
+// Import your design system components here:
+// e.g. import { Card, List } from 'antd';
+// e.g. import { Card, UnorderedList } from '@chakra-ui/react';
+import type { PConnProps } from '@pega/sdk-react';
 
 interface MyWidgetProps extends PConnProps {
   datasource?: any;
@@ -70,8 +72,9 @@ export default function MyWidget(props: MyWidgetProps) {
   const [data, setData] = useState<any[]>([]);
   const [loading, setLoading] = useState(true);
 
+  // 1. Fetch data from a Pega data page on mount
+  // This block is always the same regardless of design system
   useEffect(() => {
-    // Fetch data from a Pega data page
     const context = pConn.getContextName();
     PCore.getDataPageUtils()
       .getDataAsync(
@@ -89,23 +92,57 @@ export default function MyWidget(props: MyWidgetProps) {
       .catch(() => setLoading(false));
   }, []);
 
+  // 2. Loading state — replace with your DS loading indicator if available
   if (loading) return <div>Loading...</div>;
 
+  // 3. [DS RENDER] — replace with your design system's card/list/table primitives
+  // See "Design System Adaptation" section below for guidance
   return (
-    <Card>
-      <CardHeader title={headerText} />
-      <CardContent>
-        <List>
+    <YourDesignSystemCard>
+      <YourDesignSystemCardHeader title={headerText} />
+      <YourDesignSystemCardContent>
+        <YourDesignSystemList>
           {data.map((item, i) => (
-            <ListItem key={i}>{item.pyLabel}</ListItem>
+            <YourDesignSystemListItem key={i}>{item.pyLabel}</YourDesignSystemListItem>
           ))}
-        </List>
-      </CardContent>
-    </Card>
+        </YourDesignSystemList>
+      </YourDesignSystemCardContent>
+    </YourDesignSystemCard>
   );
 }
 ```
 
+---
+
+## Design System Adaptation
+
+The PCore data-fetching logic (all `PCore.*` calls) is always identical regardless of design system. Only the `// [DS RENDER]` section changes.
+
+**1. Check the component-specific skill file** — `.github/skills/widget-skills/<ComponentName>.md` contains a **Design System Mapping** table where available. Use it as a starting point.
+
+**2. If the chosen design system is not listed** — use the component purpose description to identify the appropriate DS primitives (card, list, table, button, badge, etc.).
+
+**3. Discover the API from installed packages** — confirm component names and props from `.d.ts` before writing JSX:
+```bash
+find node_modules/<ds-package> -name "*.d.ts" | xargs grep -l "Card\|List\|Table" | head -5
+grep -A 30 "interface.*Props" <path-to-file>
+```
+
+**4. Common widget UI primitive mapping:**
+
+| Widget pattern | Typical DS equivalent |
+|---|---|
+| Container with title | `Card` + header/title prop, or `Panel`, `Box` |
+| Item list | `List`, `UnorderedList`, or `Table` rows |
+| Loading indicator | `Spinner`, `Skeleton`, `Loading` |
+| Action button | `Button` with `onClick` |
+| Status badge | `Badge`, `Tag`, `Chip` |
+| Empty state | DS empty/placeholder component or plain `<div>` |
+
+**5. Icons** — if the DS has a companion icon package, read its exports before using any icon name. Never guess icon names.
+
+---
+
 ### Action Widget (opens assignments/cases)
 
 ```typescript

package/templates/react-sdk-reference/AGENTS.md

@@ -1,59 +1,247 @@
-# Agents
+# AGENTS — React SDK Reference
 
-AI assistant guide for React SDK Reference application.
+> Claude Code instructions for the Pega React SDK reference application.
+> Skill files and workflow prompts are in `.claude/skills/` and `.claude/prompts/`. Read them when asked to generate or replace components.
 
-For complete rules, see [`.github/copilot-instructions.md`](.github/copilot-instructions.md).
+
+You are assisting developers in a React reference application that demonstrates the Pega Infinity SDK. Customers clone this repo and **replace the sample UI components with their own design system** (MUI, Chakra, Radix, Shadcn, Ant Design, or any other).
+
+---
+
+## 1. Repository Purpose
+
+This is a **reference implementation** — not a framework. The UI components (fields, templates, widgets) are intentionally simple MUI-based implementations meant to be swapped out. The SDK wiring (bootstrap, PConnect bridge, component registry) is reusable infrastructure that should NOT be modified.
 
 ---
 
-## Purpose
+## 2. What Is Replaceable vs. Infrastructure
+
+### Replaceable (customer modifies these)
+
+| Directory                               | Purpose                                                     |
+| --------------------------------------- | ----------------------------------------------------------- |
+| `src/components/field/`                 | Form field components (TextInput, Dropdown, Date, etc.)     |
+| `src/components/template/`              | Layout templates (OneColumn, TwoColumn, Details, etc.)      |
+| `src/components/widget/`                | Data widgets (ToDo, Attachment, CaseHistory, etc.)          |
+| `src/components/designSystemExtension/` | Extended UI (AlertBanner, FieldGroup, RichTextEditor, etc.) |
+
+### Infrastructure (do NOT modify unless you know what you're doing)
 
-This is a **reference app** for Pega Infinity SDK. Customers clone it and replace the MUI-based sample components with their own design system. The SDK wiring (`@pega/sdk-react`, bootstrap, PConnect bridge) is infrastructure — only the UI layer is meant to be customized.
+| File/Directory                          | Purpose                                                   |
+| --------------------------------------- | --------------------------------------------------------- |
+| `src/MashupApp.tsx`                     | Auth + bootstrap + root rendering                         |
+| `src/components/component-map.ts`       | Registry wiring (only add/remove entries)                 |
+| `src/components/infra/`                 | Infrastructure components (ActionButtons, Stages, NavBar) |
+| `src/components/helpers/event-utils.ts` | PConnect event handler utility                            |
+| `@pega/sdk-react`                       | SDK bridge — never modify                                 |
 
 ---
 
-## Replaceable Component Directories
+## 3. Component Architecture
+
+### The PConnect Bridge
+
+Every component receives `getPConnect` as a prop. This is the bridge to the Pega platform:
+
+```typescript
+const pConn = getPConnect();
+const actions = pConn.getActionsApi(); // For field updates
+const propName = (pConn.getStateProps() as any).value; // Property path
+```
+
+### Event Handling Pattern
+
+All field components use this pattern for two-way binding:
+
+```typescript
+import handleEvent from '../../helpers/event-utils';
 
+// On change (local state only):
+function handleChange(event) {
+  setInputValue(event.target.value);
+}
+
+// On blur (push to platform):
+function handleBlur() {
+  handleEvent(actions, 'changeNblur', propName, inputValue);
+}
 ```
-src/components/
-├── field/                  ← Form inputs (TextInput, Dropdown, Date, etc.)
-├── template/               ← Layouts (OneColumn, TwoColumn, Details, etc.)
-├── widget/                 ← Data widgets (ToDo, Attachment, CaseHistory, etc.)
-└── designSystemExtension/  ← Extended UI (AlertBanner, FieldGroup, etc.)
+
+### Display Mode Handling
+
+Field components must handle `displayMode` prop:
+
+- `undefined` → render editable input
+- `'DISPLAY_ONLY'` → render read-only value via `FieldValueList`
+- `'STACKED_LARGE_VAL'` → render stacked read-only via `FieldValueList` with `variant='stacked'`
+
+### Component Registry
+
+Components are registered by name in `src/components/component-map.ts`:
+
+```typescript
+import { sdkComponents } from '@pega/sdk-react';
+
+function getSampleComponentMap() {
+  return {
+    ...sdkComponents, // Infrastructure (View, Region, FlowContainer, etc.)
+    TextInput, // Your field components
+    Dropdown,
+    // ...
+  };
+}
 ```
 
-## Do Not Modify
+To add a new component: add the import + add to the map object.
+To replace a component: change the import to point to your new implementation.
 
+---
+
+## 4. Props Interfaces
+
+### Field Components (`PConnFieldProps`)
+
+```typescript
+import type { PConnFieldProps } from '@pega/sdk-react';
+
+interface PConnFieldProps {
+  getPConnect: () => typeof PConnect;
+  label: string;
+  required: boolean;
+  disabled: boolean;
+  value?: string;
+  validatemessage: string;
+  status?: string; // 'error' | 'warning' | undefined
+  onChange: any;
+  onBlur?: any;
+  readOnly: boolean;
+  testId: string;
+  helperText: string;
+  displayMode?: string; // 'DISPLAY_ONLY' | 'STACKED_LARGE_VAL'
+  hideLabel: boolean;
+  placeholder?: string;
+}
 ```
-src/MashupApp.tsx            ← Bootstrap/auth flow
-src/components/component-map.ts  ← Only add/remove entries, don't restructure
-src/components/infra/        ← SDK infrastructure
-src/components/helpers/      ← Shared utilities (event-utils, formatters)
+
+### Template/Widget Components (`PConnProps`)
+
+```typescript
+import type { PConnProps } from '@pega/sdk-react';
+
+interface PConnProps {
+  getPConnect: () => typeof PConnect;
+}
 ```
 
 ---
 
-## Quick Commands
+## 5. Rules for Replacing Components
+
+1. **Keep the same default export name** — the component-map references it.
+2. **Keep `getPConnect` wiring intact** — extract props, call `handleEvent` on blur.
+3. **Handle `displayMode`** — return `FieldValueList` for read-only modes.
+4. **Handle validation** — show `validatemessage` when `status === 'error'`.
+5. **Preserve `data-test-id`** — pass `testId` to the root interactive element.
+6. **Use `getComponentFromRegistry`** to render sub-components (e.g., `FieldValueList`) — don't hardcode imports for components that might also be replaced.
+
+---
+
+## 6. Build & Dev Commands
 
 ```bash
-npm run dev       # Vite dev server (port 3500)
-npm run build     # Production build
+# From monorepo root (if developing locally with source packages):
+npm run build              # Build all packages + samples
+npm run dev:react          # Build + dev server
+
+# From this directory (standalone):
+npm run dev                # Vite dev server (port 3500)
+npm run build              # Production build
+```
+
+---
+
+## 7. Key Imports
+
+```typescript
+// From SDK (never modify these)
+import {
+  PConnectComponent,
+  PegaStoreContext,
+  registerComponentCreator,
+  getComponentFromRegistry,
+  sdkComponents,
+} from '@pega/sdk-react';
+import type { PConnProps, PConnFieldProps } from '@pega/sdk-react';
+
+// Event utility (preserve this)
+import handleEvent from '../../helpers/event-utils';
 ```
 
 ---
 
-## Key Pattern
+## 8. Do NOT
 
-Every replaceable component receives `getPConnect()` prop → extracts field state → renders UI → calls `handleEvent(actions, 'changeNblur', propName, value)` on blur to push changes back to Pega.
+- Modify `MashupApp.tsx` bootstrap flow when replacing design system components.
+- Import from `@pega/sdk-react/src/...` — use the package entry point only.
+- Hardcode component references — use `getComponentFromRegistry('Name')` for components that may be overridden.
+- Remove the `...sdkComponents` spread from `component-map.ts`.
+- Use `any` without justification — prefer `unknown` and narrow.
+- Add `@ts-ignore` — use `@ts-expect-error` with explanation if truly needed.
 
 ---
 
-## Reference
+## 9. Component Generation Workflow — Single Component
+
+When the user asks to generate, create, add, or replace **a single UI component** (e.g., "generate an AutoComplete component", "add a Dropdown using Chakra UI"),
+read the full contents of `.claude/prompts/add-component.md` and
+execute every step in order before writing any code.
+Do not skip steps or proceed without reading the required skill files first.
+
+> For generating **multiple field components** at once, see Section 10.
+
+---
+
+## 10. Batch Field Component Generation
+
+When the user asks to generate, create, or replace **multiple field components** or **all field components** with a design system (e.g., "generate field components with Ant Design", "replace all fields with Chakra UI", "generate all field components using Radix"),
+read the full contents of `.claude/prompts/generate-field-components.md` and
+execute every step in order before writing any code.
+Do not skip steps or proceed without reading the required skill files first.
+
+---
+
+## 11. Batch Template Component Generation
+
+When the user asks to generate, create, or replace **multiple template components** or **all template components** with a design system (e.g., "generate template components with Ant Design", "replace all templates with Chakra UI", "generate layout templates using Radix"),
+read the full contents of `.claude/prompts/generate-template-components.md` and
+execute every step in order before writing any code.
+Do not skip steps or proceed without reading the required skill files first.
+
+---
+
+## 12. Batch Widget Component Generation
+
+When the user asks to generate, create, or replace **multiple widget components** or **all widget components** with a design system (e.g., "generate widget components with Ant Design", "replace all widgets with Chakra UI", "generate widgets using Carbon"),
+read the full contents of `.claude/prompts/generate-widget-components.md` and
+execute every step in order before writing any code.
+Do not skip steps or proceed without reading the required skill files first.
+
+---
+
+## 13. Batch Design System Extension Component Generation
+
+When the user asks to generate, create, or replace **multiple design system extension components** or **all DSE components** with a design system (e.g., "generate DSE components with Ant Design", "replace design system extension components with Chakra UI", "generate designSystemExtension components using Carbon"),
+read the full contents of `.claude/prompts/generate-dse-components.md` and
+execute every step in order before writing any code.
+Do not skip steps or proceed without reading the required skill files first.
+
+---
+
+## 14. Generate All Components (Multi-Type)
+
+When the user asks to generate, create, or replace components across **multiple types** or **all component types** at once (e.g., "generate all components with Ant Design", "replace everything with Chakra UI", "generate field and widget components using Carbon", "regenerate all components"),
+read the full contents of `.claude/prompts/generate-all-components.md` and
+execute every step in order before writing any code.
+Do not skip steps or proceed without reading the required skill files first.
 
-| Topic | File |
-|-------|------|
-| Full instructions | `.github/copilot-instructions.md` |
-| Field component skill | `.github/skills/field-components.md` |
-| Template component skill | `.github/skills/template-components.md` |
-| Widget component skill | `.github/skills/widget-components.md` |
-| DSE component skill | `.github/skills/design-system-extension.md` |
+> Use this section when the request spans more than one component type. For a single type, use Sections 10–13.

package/templates/react-sdk-reference/package.json

@@ -17,7 +17,7 @@
     "@mui/styles": "^6.5.0",
     "@mui/x-date-pickers": "^9.2.0",
     "@pega/auth": "file:pega-auth-0.2.42.tgz",
-    "@pega/constellationjs": "file:pega-constellationjs-0.26.2.tgz",
+    "@pega/constellationjs": "file:pega-constellationjs-0.26.3-local.tgz",
     "@pega/sdk-react": "file:pega-sdk-react-0.1.0.tgz",
     "@pega/sdk-types": "file:pega-sdk-types-0.1.0.tgz",
     "@react-google-maps/api": "^2.20.8",

package/templates/react-sdk-reference/sdk-config.json

@@ -3,7 +3,7 @@
     "infinityRestServerUrl": "https://lab-16027-us-east-1.internal.pegalabs.io/prweb",
     "appAlias": "MediaCo",
     "sdkContentServerUrl": "",
-    "appPortal": "MediaCoSelfService",
+    "appPortal": "",
     "appMashupCaseType": "DIXL-MediaCo-Work-NewService",
     "excludePortals": [
       "pxExpress",

package/templates/react-sdk-reference/vite.config.ts

@@ -59,7 +59,7 @@ export default defineConfig({
     }),
   ],
   server: {
-    port: 3500,
+    port: 3502,
     open: true,
   },
 });

package/templates/react-sdk-reference/.github/prompts/replace-all-fields.prompt.md

@@ -1,48 +0,0 @@
----
-agent: agent
-description: Replace ALL field components with a new design system
----
-
-Replace ALL field components in `src/components/field/` with equivalents from **{{designSystem}}**.
-
-## Step 1: Replace all field components using subagents
-
-For each of the following field components, run a subagent using the `replace-field` prompt with `fieldName` set to the component directory name and `designSystem` set to **{{designSystem}}**:
-
-- TextInput
-- TextArea
-- Dropdown
-- Checkbox
-- RadioButtons
-- Date
-- DateTime
-- Time
-- Currency
-- Decimal
-- Integer
-- Percentage
-- Email
-- Phone
-- URL
-- AutoComplete
-- Multiselect
-- RichText
-- ScalarList
-- SelectableCard
-- Group
-- Location
-- ObjectReference
-- SemanticLink
-- UserReference
-- CancelAlert
-- TextContent
-
-Run subagents in parallel batches of 5 to maximize throughput.
-
-## Step 2: Replace FieldValueList
-
-Run a subagent to replace `FieldValueList` in `src/components/designSystemExtension/FieldValueList/` with a {{designSystem}} equivalent. Every field component depends on it for display modes.
-
-## Step 3: Verify
-
-After all subagents complete, run `npm run build` to verify everything compiles correctly.

package/templates/react-sdk-reference/.github/prompts/replace-component.prompt.md

@@ -1,81 +0,0 @@
----
-agent: agent
-description: Replace a single non-field component with your design system equivalent
----
-
-Replace the **{{componentName}}** component (located in `src/components/{{componentPath}}`) with an equivalent implementation using **{{designSystem}}**.
-
-Category: **{{componentCategory}}**
-
----
-
-## Instructions
-
-1. Read ALL files in `src/components/{{componentPath}}` to understand the current implementation
-2. **If a `.css` file exists in the directory, read it before writing anything.** For every CSS class, note its visual intent — spacing, sizing, colors, borders, layout, visibility tricks. The replacement must replicate the same visual appearance as the original.
-3. **Read the installed package before choosing components:**
-   - `cat node_modules/{{designSystem}}/README.md` — correct import paths and usage patterns for the installed version
-   - `grep "^export" node_modules/{{designSystem}}/dist/index.d.ts 2>/dev/null || grep -rl "^export" node_modules/{{designSystem}} --include="index.d.ts" | head -3 | xargs grep "^export"` — every component actually exported by the installed version
-   - **For every component you plan to use, read its TypeScript prop interface** from the installed `.d.ts` to discover all available styling props (e.g. `size`, `kind`, `hideLabel`, `helperText`, `orientation`). Find the file with: `find node_modules/{{designSystem}} -name "ComponentName.d.ts" | head -3`, then `grep -A 40 "interface.*Props"` on the result.
-   - Only use component names and prop names confirmed in those files. Do not rely on training knowledge of the API.
-4. Identify every `@mui/material`, `@mui/icons-material`, `@mui/styles`, and `@mui/x-date-pickers` import
-5. Replace each MUI component/utility with the {{designSystem}} equivalent, preserving the original visual output. **Styling priority — apply in this order, stop at the first that works:**
-   1. **{{designSystem}} component props/variants** — always prefer built-in props (`size`, `kind`, `orientation`, etc.) over any custom styling
-   2. **Retaining the existing `.css` file** and its class names where they don't conflict with {{designSystem}}
-   3. **{{designSystem}} design tokens via CSS custom properties** in `style` props — use design system token variables; never hardcode hex colors or pixel values
-   4. **Inline `style` props with raw values** — only as a last resort when no prop or token covers the need
-5. Convert any `makeStyles` usage to the approach above — map each class to an equivalent style, do NOT silently drop styles
-6. Replace MUI icons with {{designSystem}}'s icon system (or inline SVG if unavailable)
-7. **Before writing, discover the design system's own conventions — do not assume:**
-   - Check the README or exports for **layout primitive components** (grid, stack, flex wrappers) — prefer them over raw `<div style={{ display: 'flex' }}>` or `<div style={{ display: 'grid' }}>`
-   - Check the README or exports for a **form layout wrapper component** (one that groups label + input + helper text) — if one exists, use it instead of manual margins
-   - Check the README or `.d.ts` props for **size/density/variant and button kind/intent conventions** — use documented props rather than adding manual padding or color overrides
-   - For **built-in slots** (helper text, validation messages, label visibility): check the component's `.d.ts` — if a prop handles it natively, use that prop instead of rendering separate elements
-   - Check whether the design system has a **companion icons package** — read its exports/index before importing any icon name; do not guess icon names
-   - For **spacing in `style` props**, check `node_modules/{{designSystem}}` for a `tokens` or `css` directory — use design system CSS custom properties if available; otherwise use relative units (`rem`/`em`), never raw `px`
-
----
-
-## Category-specific rules
-
-### If `{{componentCategory}}` is `template`:
-
-- Replace MUI `Grid`/`Box`/`Stack` with {{designSystem}} layout primitives
-- Replace MUI `Tabs`/`Tab` with {{designSystem}} tab components
-- Replace MUI `Table`/`TableRow`/`TableCell` with {{designSystem}} table components
-- KEEP: children rendering logic (React children or PConnect child iteration)
-- KEEP: `templateCol` parsing for column width ratios
-- If the directory contains multiple variants (e.g., OneColumn, OneColumnPage, OneColumnTab), replace ALL of them
-
-### If `{{componentCategory}}` is `widget`:
-
-- Replace MUI visual components (Card, List, Button, Dialog, etc.) with {{designSystem}} equivalents
-- NEVER modify `PCore.*` API calls (getDataPageUtils, getMashupApi, getPubSubUtils, etc.)
-- KEEP: all data fetching logic, pub/sub subscriptions, platform interactions
-- KEEP: loading states and error handling
-
-### If `{{componentCategory}}` is `designSystemExtension`:
-
-- KEEP: same exported prop interfaces (other components depend on them)
-- If the component wraps a third-party editor (e.g., draft-js, Quill), replace only MUI wrappers — keep the editor
-- KEEP: same behavior and prop contract
-
-### If `{{componentCategory}}` is `infra`:
-
-- KEEP: `onButtonPress` callback pattern in ActionButtons
-- KEEP: `PCore.getLocaleUtils().getLocaleValue` calls for i18n
-- KEEP: all platform interaction logic
-- If the directory contains multiple variants (e.g., VerticalTabs, LeftAlignVerticalTabs), replace ALL of them
-
----
-
-## Universal rules (all categories)
-
-1. KEEP the same default export function name
-2. KEEP `data-test-id` attributes on interactive elements
-3. KEEP all `PCore.*` API calls unchanged
-4. KEEP `getPConnect()` prop extraction if present
-5. Do NOT modify `src/components/component-map.ts`
-6. Do NOT change the file path — only change file content
-7. Do NOT add new dependencies beyond {{designSystem}} and its documented peer deps
-8. Do NOT remove any TypeScript interfaces/types — update them if needed for new props

package/templates/react-sdk-reference/.github/prompts/replace-field.prompt.md

@@ -1,41 +0,0 @@
----
-agent: agent
-description: Replace a single field component with your design system equivalent
----
-
-Replace the `{{fieldName}}` field component (located in `src/components/field/{{fieldName}}/`) with an equivalent implementation using **{{designSystem}}**.
-
-**Before writing anything:** read ALL files in the component directory, including any `.css` file. For every CSS class, note its visual intent — spacing, sizing, colors, borders, layout. The replacement must produce the same visual appearance as the original.
-
-**Styling priority — apply in this order, stop at the first that works:**
-1. **{{designSystem}} component props/variants** — always prefer built-in props (`size`, `kind`, `hideLabel`, `orientation`, etc.) over any custom styling
-2. **Retaining the existing `.css` file** and its class names where they don't conflict with {{designSystem}}
-3. **{{designSystem}} design tokens via CSS custom properties** in `style` props — use design system token variables; never hardcode hex colors or pixel values
-4. **Inline `style` props with raw values** — only as a last resort when no prop or token covers the need
-
-**Before choosing {{designSystem}} components, read the installed package:**
-1. `cat node_modules/{{designSystem}}/README.md` — note the correct import path and usage patterns for the installed version.
-2. `grep "^export" node_modules/{{designSystem}}/dist/index.d.ts 2>/dev/null || grep -rl "^export" node_modules/{{designSystem}} --include="index.d.ts" | head -3 | xargs grep "^export"` — lists every component actually exported by the installed version.
-3. **For every component you plan to use, read its TypeScript prop interface** from the installed `.d.ts` to discover all available styling props (e.g. `size`, `kind`, `hideLabel`, `helperText`, `orientation`). Find the file with: `find node_modules/{{designSystem}} -name "ComponentName.d.ts" | head -3`, then `grep -A 40 "interface.*Props"` on the result.
-4. Only use component names and prop names confirmed in those files. Do not rely on training knowledge of the API.
-
-**Before writing, discover the design system's own conventions — do not assume:**
-- Check the README or exports for a **form layout wrapper component** (one that groups label + input + helper text) — if one exists, use it instead of manual margins
-- Check the README or `.d.ts` props for **size/density/variant conventions** — use whatever compact-form prop is documented rather than adding manual padding
-- For **built-in slots** (helper text, validation messages, label visibility): check the component's `.d.ts` — if a prop handles it natively, use that prop instead of rendering separate elements
-- Check whether the design system has a **companion icons package** — read its exports/index before importing any icon name; do not guess icon names
-- For **spacing in `style` props**, check `node_modules/{{designSystem}}` for a `tokens` or `css` directory — use design system CSS custom properties if available; otherwise use relative units (`rem`/`em`), never raw `px`
-- For **layout primitives**, check the exports list first — prefer design system stack/grid components over raw `<div style={{ display: 'flex' }}>`
-
-Requirements:
-
-1. Keep the same default export function name
-2. Import and use `PConnFieldProps` from `@pega/sdk-react`
-3. Keep the `handleEvent(actions, 'changeNblur', propName, value)` call on blur
-4. Handle `displayMode === 'DISPLAY_ONLY'` and `'STACKED_LARGE_VAL'` using `getComponentFromRegistry('FieldValueList')`
-5. Show `validatemessage` when `status === 'error'`
-6. Pass `data-test-id={testId}` to the interactive element
-7. Support `readOnly`, `disabled`, `required`, `placeholder`, `hideLabel`
-8. Use local state for the input value, sync from `value` prop via `useEffect`
-
-Do NOT modify `component-map.ts` unless the file path changes.

package/templates/react-sdk-reference/.github/prompts/swap-design-system.prompt.md

@@ -1,49 +0,0 @@
----
-agent: agent
-description: Remove MUI and replace all components with a new design system
----
-
-Replace the entire UI layer of this application from MUI (@mui/material) to **{{designSystem}}**.
-
-## Steps:
-
-### 1. Install the new design system
-
-Install {{designSystem}} and remove @mui/material, @mui/icons-material, @mui/styles, @mui/x-date-pickers (keep @mui/x-date-pickers if {{designSystem}} doesn't have a date picker).
-
-### 2. Replace field components (`src/components/field/`)
-
-Replace all MUI TextField, Select, Checkbox, Radio, etc. with {{designSystem}} equivalents. Keep the PConnect wiring (handleEvent, displayMode, validation).
-
-### 3. Replace template components (`src/components/template/`)
-
-Replace MUI Grid, Box, Tabs, Paper with {{designSystem}} layout primitives. Keep children rendering logic.
-
-### 4. Replace widget components (`src/components/widget/`)
-
-Replace MUI Card, List, Table, Button with {{designSystem}} equivalents. Keep data fetching and PCore API calls.
-
-### 5. Replace DSE components (`src/components/designSystemExtension/`)
-
-Replace MUI Alert, Typography, Chip with {{designSystem}} equivalents. FieldValueList is critical — every field uses it.
-
-### 6. Update MashupApp.tsx
-
-Replace MUI's ThemeProvider with {{designSystem}}'s provider (if any). Remove @mui/styles LegacyThemeProvider.
-
-### 7. Update infra components (`src/components/infra/`)
-
-Replace MUI usage in ActionButtons, NavBar, Stages, DeferLoad, DashboardFilter, VerticalTabs.
-
-### 8. Clean up
-
-- Remove all @mui/\* imports
-- Run `npm run build` to verify
-- Fix any TypeScript errors
-
-## Critical Rules
-
-- NEVER modify `@pega/sdk-react` imports or the component registry structure
-- NEVER remove `handleEvent` calls or `getPConnect` wiring
-- ALWAYS handle `displayMode` in field components
-- ALWAYS preserve `data-test-id` attributes