@pega/sdk 0.0.4 → 0.0.5

package/templates/react-sdk-reference/.cursor/rules/dse-component.mdrules

@@ -1,78 +0,0 @@
----
-globs: ["src/components/designSystemExtension/**/*.tsx"]
-alwaysApply: false
----
-
-# Design System Extension Component Rules
-
-When creating or modifying DSE components, follow these rules:
-
-## What Are DSE Components?
-
-Design System Extension components are display-focused presentational components. They sit between pure UI and data-fetching widgets. Some receive `getPConnect`, others receive only display props.
-
-## Patterns
-
-### Pattern A: With PConnect (data-aware display)
-
-Used for: FieldValueList, CaseSummaryFields, DetailsFields
-
-```typescript
-import type { PConnProps } from '@pega/sdk-react';
-
-interface FieldValueListProps extends PConnProps {
-  name?: string;
-  value?: string;
-  variant?: 'stacked' | 'inline';
-}
-
-export default function FieldValueList(props: FieldValueListProps) {
-  const { name, value, variant = 'inline' } = props;
-  // Render a label-value pair
-}
-```
-
-### Pattern B: Without PConnect (pure presentation)
-
-Used for: AlertBanner, Banner, Operator
-
-```typescript
-interface AlertBannerProps {
-  variant: 'urgent' | 'warning' | 'info' | 'success';
-  heading?: string;
-  messages: Array<string | { label?: string; description?: string }>;
-  onClose?: () => void;
-}
-
-export default function AlertBanner(props: AlertBannerProps) {
-  // Render an alert/notification banner
-}
-```
-
-### Pattern C: Rich editor (extends PConnFieldProps)
-
-Used for: RichTextEditor
-
-```typescript
-import type { PConnFieldProps } from '@pega/sdk-react';
-
-interface RichTextEditorProps extends PConnFieldProps {
-  content?: string;
-}
-```
-
-## Visual Preservation
-
-The replacement must look the same as the original component:
-
-1. **Read any `.css` file in the directory first.** Note every class's visual intent (spacing, sizing, colors, layout).
-2. Replicate those styles via inline `style` props, the new design system's props/variants, or by keeping the CSS import — whichever produces the closest match.
-3. Do NOT silently drop `makeStyles` classes — map each one to an equivalent style.
-
-## Key Rules
-
-- DSE components are the **most commonly referenced by other components** via `getComponentFromRegistry('FieldValueList')` — every field uses FieldValueList for display modes
-- Keep the same export name (default export) and prop interface shape
-- If you replace FieldValueList, ensure it accepts `name`, `value`, and optional `variant` props
-- AlertBanner must handle the `messages` array format (both strings and `{label, description}` objects)
-- Do NOT drop visual styles when removing `makeStyles` — always map them to an equivalent

package/templates/react-sdk-reference/.cursor/rules/field-component.mdrules

@@ -1,74 +0,0 @@
----
-globs: ["src/components/field/**/*.tsx"]
-alwaysApply: false
----
-
-# Field Component Rules
-
-When creating or modifying field components, follow these rules:
-
-## Required Structure
-
-1. **Import types from `@pega/sdk-react`**:
-   ```typescript
-   import type { PConnFieldProps } from '@pega/sdk-react';
-   ```
-
-2. **Define a props interface extending `PConnFieldProps`**:
-   ```typescript
-   interface MyFieldProps extends PConnFieldProps {
-     // additional props specific to this field
-   }
-   ```
-
-3. **Export as default function component**:
-   ```typescript
-   export default function MyField(props: MyFieldProps) { ... }
-   ```
-
-## Required Behaviors
-
-1. **Extract standard props**: `getPConnect`, `label`, `required`, `disabled`, `value`, `validatemessage`, `status`, `readOnly`, `testId`, `helperText`, `displayMode`, `hideLabel`, `placeholder`
-
-2. **Get PConnect APIs**:
-   ```typescript
-   const pConn = getPConnect();
-   const actions = pConn.getActionsApi();
-   const propName = (pConn.getStateProps() as any).value;
-   ```
-
-3. **Handle displayMode** (MUST be before the main return):
-   ```typescript
-   if (displayMode === 'DISPLAY_ONLY') {
-     return <FieldValueList name={hideLabel ? '' : label} value={value} />;
-   }
-   if (displayMode === 'STACKED_LARGE_VAL') {
-     return <FieldValueList name={hideLabel ? '' : label} value={value} variant='stacked' />;
-   }
-   ```
-
-4. **Use local state + blur pattern**:
-   - `onChange` → update local state only
-   - `onBlur` → call `handleEvent(actions, 'changeNblur', propName, localValue)`
-
-5. **Show validation**: Display `validatemessage` and apply error styling when `status === 'error'`
-
-6. **Pass test ID**: Set `data-test-id={testId}` on the interactive element
-
-7. **Use `getComponentFromRegistry('FieldValueList')`** — never hardcode FieldValueList import
-
-## Visual Preservation
-
-The replacement must look the same as the original component:
-
-1. **Read any `.css` file in the directory first.** Note every class's visual intent (spacing, sizing, colors, layout).
-2. Replicate those styles via inline `style` props, {{designSystem}} component props/variants, or by keeping the CSS import — whichever produces the closest match.
-3. Do NOT silently drop `makeStyles` classes — map each one to an equivalent style.
-
-## Do NOT
-
-- Skip `displayMode` handling — it breaks read-only views
-- Call `handleEvent` on every keystroke — only on blur
-- Hardcode component imports for components that exist in the registry
-- Remove the `handleEvent` import from `../../helpers/event-utils`
-- Drop visual styles when removing `makeStyles` — always map them to an equivalent

package/templates/react-sdk-reference/.cursor/rules/pega-sdk.mdrules

@@ -1,247 +0,0 @@
----
-alwaysApply: true
----
-
-# Pega SDK — Cursor Rules
-
-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.
-
----
-
-## 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)
-
-| 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                                 |
-
----
-
-## 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);
-}
-```
-
-### 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,
-    // ...
-  };
-}
-```
-
-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;
-}
-```
-
-### Template/Widget Components (`PConnProps`)
-
-```typescript
-import type { PConnProps } from '@pega/sdk-react';
-
-interface PConnProps {
-  getPConnect: () => typeof PConnect;
-}
-```
-
----
-
-## 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
-# 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';
-```
-
----
-
-## 8. Do NOT
-
-- 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.
-
----
-
-## 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 `.cursor/rules/prompts/add-component.mdrules` 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 `.cursor/rules/prompts/generate-field-components.mdrules` 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 `.cursor/rules/prompts/generate-template-components.mdrules` 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 `.cursor/rules/prompts/generate-widget-components.mdrules` 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 `.cursor/rules/prompts/generate-dse-components.mdrules` 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 `.cursor/rules/prompts/generate-all-components.mdrules` and
-execute every step in order before writing any code.
-Do not skip steps or proceed without reading the required skill files first.
-
-> 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/.cursor/rules/prompts/add-component.mdrules

@@ -1,149 +0,0 @@
----
-description: add-component.prompt
-alwaysApply: false
----
-
-## Step 0 — Resolve missing information
-
-Read the user's message carefully. Extract:
-
-- **Component name** — the exact name (e.g. `AutoComplete`, `DatePicker`)
-- **Component type** — one of: `field` | `template` | `widget` | `designSystemExtension`
-- **Design system** — the UI library to use (e.g. `Ant Design`, `Chakra UI`, `Carbon`, `Radix UI`)
-- **Output path** — the exact or relative path where the component should be generated (e.g. `src/components/field/AutoComplete`)
-
-If any of the four are missing or ambiguous, ask the user all unresolved items in **one numbered list** and wait for their answers before continuing. Do not guess or proceed with assumptions.
-
-Example questions to ask (only ask the ones that are actually missing):
-1. Which design system should I use? (e.g. Ant Design, Chakra UI, Carbon, Radix UI)
-2. What is the exact component name?
-3. What type of component is this? (field / template / widget / designSystemExtension)
-4. What is the exact or relative path where the component should be generated? (e.g. `src/components/field/AutoComplete`)
-
-### Case-insensitive component name matching
-
-The user may enter the component name in any casing (e.g. `autocomplete`, `Autocomplete`, `autoComplete`). It is your responsibility to match it to the correct canonical name by checking the skill files in `.cursor/rules/skills/field-skills/`, `.cursor/rules/skills/template-skills/`, `.cursor/rules/skills/widget-skills/`, and `.cursor/rules/skills/design-system-extension-skills/`. For example, if the user types `autocomplete`, match it to `AutoComplete`.
-
-Once all four are known, continue to Step 1.
-
----
-
-## Step 1 — Check for existing component (overwrite check)
-
-Before generating, check if a component already exists at the resolved output path:
-
-1. Check if `<outputPath>/<ComponentName>.tsx` (or the directory) already exists.
-2. If it **does exist**, ask the user: _"A component named `<ComponentName>` already exists at `<outputPath>`. Do you want to overwrite it with the new implementation?"_
-   - If the user says **yes**, proceed to overwrite.
-   - If the user says **no**, stop and skip generation.
-3. If it **does not exist**, continue to Step 2.
-
----
-
-## Step 2 — Check for skill files
-
-Always read the **general type skill** for the component type:
-
-| Component Type | General Skill File |
-|---|---|
-| `field` | `.cursor/rules/skills/field-components.mdrules` |
-| `template` | `.cursor/rules/skills/template-components.mdrules` |
-| `widget` | `.cursor/rules/skills/widget-components.mdrules` |
-| `designSystemExtension` | `.cursor/rules/skills/design-system-extension.mdrules` |
-
-Then look for a **component-specific skill** based on the component type:
-
-| Component Type | Specific Skill Location |
-|---|---|
-| `field` | `.cursor/rules/skills/field-skills/<ComponentName>.mdrules` |
-| `template` | `.cursor/rules/skills/template-skills/<ComponentName>.mdrules` |
-| `widget` | `.cursor/rules/skills/widget-skills/<ComponentName>.mdrules` |
-| `designSystemExtension` | `.cursor/rules/skills/design-system-extension-skills/<ComponentName>.mdrules` |
-
-If the component-specific skill file exists, read it fully. Pay special attention to:
-- **Behavioral Contract** — state management, event handling, option loading, edge cases
-- **Design System Mapping** table — the recommended component for the chosen design system
-
-You must read **both** the general type skill and the component-specific skill (if it exists) before proceeding.
-
-Examples:
-- `AutoComplete` (field) → read `field-components.md` + `field-skills/AutoComplete.md`
-- `AdvancedSearch` (template) → read `template-components.md` + `template-skills/AdvancedSearch.md`
-- `AppAnnouncement` (widget) → read `widget-components.md` + `widget-skills/AppAnnouncement.md`
-- `AlertBanner` (designSystemExtension) → read `design-system-extension.md` + `design-system-extension-skills/AlertBanner.md`
-
-If no component-specific skill file exists, continue using the general pattern from the type skill.
-
----
-
-## Step 3 — Check and install dependencies
-
-Run:
-```
-cat package.json | grep "<design-system-package>"
-```
-
-If the design system package is **not** listed in `dependencies` or `devDependencies`, install it:
-```
-npm install <design-system-package>
-```
-
-Also install any peer dependencies documented in the package's README. Report what was installed.
-
----
-
-## Step 4 — Discover the design system's API
-
-Before writing any code, inspect 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`:
-   `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.
-
-Also check:
-- Whether the design system has a **form layout wrapper** (label + input + helper text) — use it instead of manual margins
-- Whether it has **size/density/variant conventions** — use built-in props rather than custom padding
-- Whether it has a **companion icons package** — read its exports before using any icon name; never guess icon names
-- Whether it has a **tokens or CSS directory** — use design system CSS custom properties for spacing; never hardcode `px` values
-
----
-
-## Step 5 — Generate the component
-
-Create the component directory at the resolved output path (from Step 0).
-
-Create `<ComponentName>.tsx` using the pattern for the component type:
-
-- **field**: Extend `PConnFieldProps` from `@pega/sdk-react`. Extract `getPConnect`, `label`, `required`, `disabled`, `value`, `validatemessage`, `status`, `readOnly`, `testId`, `helperText`, `displayMode`, `hideLabel`, `placeholder`. Call `handleEvent(actions, 'changeNblur', propName, value)` on blur. Handle `displayMode === 'DISPLAY_ONLY'` and `'STACKED_LARGE_VAL'` using `getComponentFromRegistry('FieldValueList')`. Show `validatemessage` when `status === 'error'`. Pass `data-test-id={testId}` on the interactive element.
-- **template**: Extend `PConnProps`, render children via the design system's grid/layout primitives
-- **widget**: Extend `PConnProps`, fetch data via `PCore.getDataPageUtils()`
-- **designSystemExtension**: Pure display props or extend `PConnProps`
-
-Create `index.tsx`:
-```typescript
-export { default } from './<ComponentName>';
-```
-
----
-
-## Step 6 — Register in component-map.ts
-
-Edit `src/components/component-map.ts`:
-
-1. Add the import at the top of the file, in the correct section (Fields / Templates / Widgets / Design System Extension)
-2. Add an entry in `getSampleComponentMap()` under the matching category comment
-
-Do not restructure or reorder any existing entries.
-
----
-
-## Step 7 — Verify the build
-
-Run:
-```
-npm run build
-```
-
-If build errors occur, fix them before reporting completion. Report what files were created and what was added to `component-map.ts`.