@pega/sdk 0.0.4 → 0.0.6

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

@@ -1,223 +0,0 @@
----
-agent: agent
-description: Generate all (or a subset of) field components using any design system
----
-
-## Step 0 — Resolve inputs
-
-Read the user's message carefully. Extract:
-
-- **Design system** — the UI library to use (e.g. `Ant Design`, `Chakra UI`, `Carbon`, `Radix UI`)
-- **Output base path** — the folder where field components should be generated (e.g. `src/components/field/`, `app/ui/fields/`)
-- **Component list** — which components to generate (default: all 27 listed below)
-
-Both **design system** and **output base path** are required. If either is missing or ambiguous, you MUST stop and ask the user before proceeding. Do not infer any value from the project structure, `.instructions.md` files, existing folders, or any other source.
-
-⛔ **STOP** — If the user's message does not explicitly state BOTH the design system AND the output path, ask for the missing items now. Do not proceed to Step 1 until you have explicit answers from the user for all required inputs.
-
-Example questions (ask only the ones that are actually missing):
-
-1. Which design system should I use? (e.g. Ant Design, Chakra UI, Carbon, Radix UI)
-2. Where should the field components be generated? (e.g. `src/components/field/`)
-
-If the user specified a subset (e.g., "just TextInput and Dropdown"), restrict the list accordingly.
-
-Once both are known, continue to Step 1.
-
-### Full component list (default)
-
-| Component       | Pega Name       |
-| --------------- | --------------- |
-| AutoComplete    | AutoComplete    |
-| CancelAlert     | CancelAlert     |
-| Checkbox        | Checkbox        |
-| Currency        | Currency        |
-| Date            | Date            |
-| DateTime        | DateTime        |
-| Decimal         | Decimal         |
-| Dropdown        | Dropdown        |
-| Email           | Email           |
-| Group           | Group           |
-| Integer         | Integer         |
-| Location        | Location        |
-| Multiselect     | Multiselect     |
-| ObjectReference | ObjectReference |
-| Percentage      | Percentage      |
-| Phone           | Phone           |
-| RadioButtons    | RadioButtons    |
-| RichText        | RichText        |
-| ScalarList      | ScalarList      |
-| SelectableCard  | SelectableCard  |
-| SemanticLink    | SemanticLink    |
-| TextArea        | TextArea        |
-| TextContent     | TextContent     |
-| TextInput       | TextInput       |
-| Time            | Time            |
-| URL             | URL             |
-| UserReference   | UserReference   |
-
----
-
-## Step 1 — Read `field-components.md` (once, for the entire session)
-
-Read the full contents of `.github/skills/field-components.md`.
-
-This gives you:
-
-- The behavioral skeleton every field component must follow (state, effects, event handling, display modes)
-- The Design System Adaptation guide (prop mapping conventions, form layout wrappers)
-- The abstract template to use as a base for all components
-
-Keep this context active throughout the entire generation session. Do not re-read it per component.
-
----
-
-## Step 2 — Install and discover the design system (once)
-
-### 2a — Check and install the DS package
-
-Run this command in your terminal:
-
-```bash
-cat package.json | grep "<design-system-package>"
-```
-
-If the design system package is **not** listed in `dependencies` or `devDependencies`, install it:
-
-```bash
-npm install <design-system-package>
-```
-
-Also install any peer dependencies documented in the package's README. Report what was installed.
-
-### 2b — Discover the DS API from installed files
-
-Run these commands to discover the actual API (do NOT rely on training knowledge):
-
-1. Read the README for correct import paths and usage patterns:
-
-   ```bash
-   cat node_modules/<designSystem>/README.md
-   ```
-
-2. List every exported component:
-
-   ```bash
-   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"
-   ```
-
-3. For every input control you plan to use (Input, Select, Checkbox, DatePicker, Radio, etc.), read its prop interface:
-
-   ```bash
-   find node_modules/<designSystem> -name "ComponentName.d.ts" | head -3
-   grep -A 40 "interface.*Props" <path-from-above>
-   ```
-
-4. Check for a **form layout wrapper** (label + input + helper text) — e.g., `<Form.Item>` in Ant Design, `<FormControl>` in Chakra UI. Use it instead of manual margins.
-
-5. Check for **size/density/variant conventions** — use built-in props rather than custom padding.
-
-6. Check for a **companion icons package** — read its exports before using any icon name. Never guess icon names.
-
-7. Check for **CSS tokens** — use design system CSS custom properties for spacing; never hardcode `px` values.
-
-Only use component names and prop names confirmed in these files.
-
-Build a **DS API reference map** from this discovery. You will reuse it for every component — do not repeat these commands per component.
-
----
-
-## Step 3 — Overwrite check (all at once)
-
-For each component in the list, check whether `<outputPath>/<ComponentName>/<ComponentName>.tsx` already exists.
-
-If **any** exist, report them all at once and ask:
-
-> "The following N components already exist: [list]. How should I proceed?
->
-> - **Overwrite all** — replace all existing implementations
-> - **Skip existing** — only generate components that don't exist yet
-> - **Cancel** — stop without generating anything"
-
-Wait for the user's answer before proceeding. If none exist, continue immediately.
-
----
-
-## Step 4 — Generate each component (loop)
-
-For each component in the resolved list (in the order listed in Step 0):
-
-### 4a — Read the component-specific skill file (MANDATORY — do not skip)
-
-Read the file `.github/skills/field-skills/<ComponentName>.md` using your file reading tool. This step is **required** for every component that has a skill file — do not rely solely on the general `field-components.md`.
-
-After reading, extract and keep active:
-
-- **Behavioral Contract** — state management, option loading, edge cases specific to this component
-- **Design System Mapping** table — the recommended DS component for the chosen design system
-- **UI control type** — use this to select the closest DS primitive if the chosen DS is not in the mapping table
-
-If no skill file exists at that path, use the general behavioral skeleton from `field-components.md` loaded in Step 1.
-
-⚠️ The general skill file (`field-components.md`) provides the behavioral skeleton. The component-specific skill file provides the **exact event handling, option-loading logic, and edge cases**. Both are needed — generating from only the general skill will produce generic inputs that miss component-specific behavior (e.g., AutoComplete's async search, Currency's formatting).
-
-### 4b — Generate the component files
-
-Create the directory `<outputPath>/<ComponentName>/`.
-
-Create `<ComponentName>.tsx` using this structure from `field-components.md` (loaded in Step 1):
-
-1. Imports (React hooks + `handleEvent` from `../../helpers/event-utils` + `getComponentFromRegistry` from `@pega/sdk-react` + `PConnFieldProps` + DS input from Step 2)
-2. Interface extending `PConnFieldProps` with any extra props from the component skill file
-3. Destructure: `getPConnect`, `label`, `required`, `disabled`, `value`, `validatemessage`, `status`, `readOnly`, `testId`, `helperText`, `displayMode`, `hideLabel`, `placeholder`
-4. Display mode guards: if `DISPLAY_ONLY` or `STACKED_LARGE_VAL` → return `FieldValueList`
-5. Return → DS form input from Step 2, with `onBlur` calling `handleEvent(actions, 'changeNblur', propName, inputValue)`
-
-Pass `data-test-id={testId}` on the underlying interactive element.
-
-Create `index.tsx`:
-
-```typescript
-export { default } from './<ComponentName>';
-```
-
-### 4c — Register the component
-
-Edit `src/components/component-map.ts`:
-
-1. Add an import at the top of the file in the **Fields** section:
-   ```typescript
-   import <ComponentName> from './field/<ComponentName>';
-   ```
-2. Add an entry in the return object of `getSampleComponentMap()` under the fields comment:
-   ```typescript
-   <ComponentName>,
-   ```
-
-Do not reorder or restructure any existing entries.
-
-### 4d — Batch checkpoint
-
-After every **5 components**, run:
-
-```bash
-npm run build
-```
-
-Fix any TypeScript or build errors before continuing to the next component. This prevents error accumulation.
-
-### 4e — Report progress
-
-After each component: "`<ComponentName>` ✓ — using `<DS component name>`"
-
----
-
-## Step 5 — Verify the build
-
-Run:
-
-```bash
-npm run build
-```
-
-If build errors occur, fix them before reporting completion. Report a summary: list of all files created and all entries added to `component-map.ts`.

package/templates/react-sdk-reference/.github/prompts/generate-template-components.prompt.md

@@ -1,229 +0,0 @@
----
-agent: agent
-description: Generate all (or a subset of) template components using any design system
----
-
-## Step 0 — Resolve inputs
-
-Read the user's message carefully. Extract:
-
-- **Design system** — the UI library to use (e.g. `Ant Design`, `Chakra UI`, `Carbon`, `Radix UI`)
-- **Output base path** — the folder where template components should be generated (e.g. `src/components/template/`)
-- **Component list** — which templates to generate (default: all 32 listed below)
-
-Both **design system** and **output base path** are required. If either is missing or ambiguous, you MUST stop and ask the user before proceeding. Do not infer any value from the project structure, `.instructions.md` files, existing folders, or any other source.
-
-⛔ **STOP** — If the user's message does not explicitly state BOTH the design system AND the output path, ask for the missing items now. Do not proceed to Step 1 until you have explicit answers from the user for all required inputs.
-
-Example questions (ask only the ones that are actually missing):
-
-1. Which design system should I use? (e.g. Ant Design, Chakra UI, Carbon, Radix UI)
-2. Where should the template components be generated? (e.g. `src/components/template/`)
-
-> **Note:** The design system applies only to **layout templates** (TwoColumn, OneColumn, NarrowWide, WideNarrow, and their sub-variants). Form templates and page templates use the PConnect bridge pattern and are design-system agnostic — they will be generated without DS primitives regardless of your choice.
-
-If the user specified a subset (e.g., "just TwoColumn and OneColumn"), restrict the list accordingly.
-
-Once both are known, continue to Step 1.
-
-### Full component list (default — 32 templates)
-
-| Component               | Category   |
-| ----------------------- | ---------- |
-| AdvancedSearch          | Page       |
-| AppShell                | Page       |
-| BannerPage              | Page       |
-| CaseSummary             | Page       |
-| CaseView                | Page       |
-| CaseViewActionsMenu     | Widget     |
-| Confirmation            | Page       |
-| DataReference           | Form       |
-| DefaultForm             | Form       |
-| DefaultPage             | Page       |
-| Details                 | Layout     |
-| DetailsSubTabs          | Layout     |
-| DetailsThreeColumn      | Layout     |
-| DetailsTwoColumn        | Layout     |
-| DynamicTabs             | Navigation |
-| FieldGroupTemplate      | Form       |
-| HierarchicalForm        | Form       |
-| InlineDashboard         | Page       |
-| InlineDashboardPage     | Page       |
-| ListPage                | Page       |
-| ListView                | Page       |
-| MultiReferenceReadOnly  | Display    |
-| NarrowWide              | Layout     |
-| OneColumn               | Layout     |
-| PromotedFilters         | Widget     |
-| SelfServiceCaseView     | Page       |
-| SimpleTable             | Table      |
-| SingleReferenceReadOnly | Display    |
-| SubTabs                 | Navigation |
-| TwoColumn               | Layout     |
-| WideNarrow              | Layout     |
-| WssNavBar               | Navigation |
-
----
-
-## Step 1 — Read `template-components.md` (once, for the entire session)
-
-Read the full contents of `.github/skills/template-components.md`.
-
-This gives you:
-
-- **Layout template pattern** — DS-agnostic grid skeleton with `// [DS GRID]` placeholder; `templateCol` parsing logic; responsive behavior rules
-- **Design System Adaptation section** — how to map the chosen DS's grid/flex primitive to the computed column ratios
-- **Form template pattern** — PConnect bridge via `createElement(createPConnectComponent(), ...)` and `connectToState`; no DS involved
-- **Page template pattern** — region extraction via `getRawMetadata()` and PConnect bridge; no DS involved
-- Registration conventions and helper utilities
-
-Keep this context active throughout the entire generation session. Do not re-read it per component.
-
----
-
-## Step 2 — Install and discover the design system (once)
-
-### 2a — Check and install the DS package
-
-Run this command in your terminal:
-
-```bash
-cat package.json | grep "<design-system-package>"
-```
-
-If the design system package is **not** listed in `dependencies` or `devDependencies`, install it:
-
-```bash
-npm install <design-system-package>
-```
-
-Also install any peer dependencies documented in the package's README. Report what was installed.
-
-### 2b — Discover the DS layout API from installed files
-
-> You only need layout-related DS components. Form and page templates do not use the DS.
-
-Run these commands to discover the actual API (do NOT rely on training knowledge):
-
-1. Read the README for correct import paths and usage patterns:
-
-   ```bash
-   cat node_modules/<designSystem>/README.md
-   ```
-
-2. List every exported component — focus on layout primitives (Grid, Columns, Flex, SimpleGrid, Row, Col):
-
-   ```bash
-   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"
-   ```
-
-3. For every grid/layout component you plan to use, read its prop interface:
-
-   ```bash
-   find node_modules/<designSystem> -name "Grid.d.ts" -o -name "Col.d.ts" -o -name "Flex.d.ts" | head -5
-   grep -A 40 "interface.*Props" <path-from-above>
-   ```
-
-4. Note **responsive breakpoint APIs** and **column sizing conventions** (e.g., 12-column grid, fractional units, span props).
-
-Only use component names and prop names confirmed in these files.
-
-Build a **DS layout API reference** from this discovery. Reuse it for every layout template — do not repeat these commands per component.
-
----
-
-## Step 3 — Overwrite check (all at once)
-
-For each component in the list, check whether `<outputPath>/<ComponentName>/<ComponentName>.tsx` already exists.
-
-If **any** exist, report them all at once and ask:
-
-> "The following N components already exist: [list]. How should I proceed?
->
-> - **Overwrite all** — replace all existing implementations
-> - **Skip existing** — only generate components that don't exist yet
-> - **Cancel** — stop without generating anything"
-
-Wait for the user's answer before proceeding. If none exist, continue immediately.
-
----
-
-## Step 4 — Generate each component (loop)
-
-For each component in the resolved list (in the order listed in Step 0):
-
-### 4a — Read the component-specific skill file (MANDATORY — do not skip)
-
-Read the file `.github/skills/template-skills/<ComponentName>.md` using your file reading tool. This step is **required** for every component — do not rely solely on the general `template-components.md`.
-
-After reading, extract and keep active:
-
-- **Template category** — Layout (uses DS grid from Step 2) | Form (PConnect bridge + CSS) | Page (region extraction + PConnect bridge)
-- **Behavioral Contract** — sub-variants, region handling, slot rendering logic
-- **Design System Mapping** table — the recommended DS layout primitive (for Layout templates only)
-
-If no skill file exists at that path, use the general pattern from `template-components.md` loaded in Step 1.
-
-⚠️ The general skill file (`template-components.md`) provides the pattern skeletons. The component-specific skill file provides the **exact region structure, sub-variant keys, and rendering logic**. Both are needed — generating from only the general skill will produce templates with wrong region counts or missing sub-variant registrations.
-
-### 4b — Generate the component files
-
-Create the directory `<outputPath>/<ComponentName>/`.
-
-Create `<ComponentName>.tsx` using the structure matching the template category from `template-components.md` (loaded in Step 1):
-
-- **Layout**: `PropsWithChildren` + `templateCol` parsing (split on whitespace, strip units, compute ratios) + DS grid/flex from Step 2 rendering children in computed column ratios. On mobile: columns must stack to full width.
-- **Form**: `createElement(createPConnectComponent(), ...)` for each child from `getPConnect().getChildren()[0].getPConnect().getChildren()`. No DS primitives.
-- **Page**: `createElement(createPConnectComponent(), ...)` for each region from `getPConnect().getChildren()`. No DS primitives.
-
-Apply the Behavioral Contract from the component skill file (sub-variants, region handling, slot logic).
-
-Create `index.tsx` if required by the skill file:
-
-```typescript
-export { default } from './<ComponentName>';
-```
-
-Create any CSS file required by the skill file (e.g., `DefaultForm.css` with grid classes).
-
-### 4c — Register the component
-
-Edit `src/components/component-map.ts`:
-
-1. Add an import at the top of the file in the **Templates** section:
-   ```typescript
-   import <ComponentName> from './template/<ComponentName>';
-   ```
-2. Add an entry in the return object of `getSampleComponentMap()` under the templates comment:
-   ```typescript
-   <ComponentName>,
-   ```
-3. For sub-variants (e.g., TwoColumnPage, TwoColumnTab), register each key separately pointing to its own file or a shared implementation as specified in the skill file.
-
-Do not reorder or restructure any existing entries.
-
-### 4d — Batch checkpoint
-
-After every **5 components**, run:
-
-```bash
-npm run build
-```
-
-Fix any TypeScript or build errors before continuing to the next component. This prevents error accumulation.
-
-### 4e — Report progress
-
-After each component: "`<ComponentName>` ✓ — `<Layout | Form | Page>` template`<, using <DS component name> for grid>` if layout"
-
----
-
-## Step 5 — Verify the build
-
-Run:
-
-```bash
-npm run build
-```
-
-If build errors occur, fix them before reporting completion. Report a summary: list of all files created and all entries added to `component-map.ts`.

package/templates/react-sdk-reference/.github/prompts/generate-widget-components.prompt.md

@@ -1,208 +0,0 @@
----
-agent: agent
-description: Generate all (or a subset of) widget components using any design system
----
-
-## Step 0 — Resolve inputs
-
-Read the user's message carefully. Extract:
-
-- **Design system** — the UI library to use (e.g. `Ant Design`, `Chakra UI`, `Carbon`, `Radix UI`)
-- **Output base path** — the folder where widget components should be generated (e.g. `src/components/widget/`)
-- **Component list** — which widgets to generate (default: all 9 listed below)
-
-Both **design system** and **output base path** are required. If either is missing or ambiguous, you MUST stop and ask the user before proceeding. Do not infer any value from the project structure, `.instructions.md` files, existing folders, or any other source.
-
-⛔ **STOP** — If the user's message does not explicitly state BOTH the design system AND the output path, ask for the missing items now. Do not proceed to Step 1 until you have explicit answers from the user for all required inputs.
-
-Example questions (ask only the ones that are actually missing):
-
-1. Which design system should I use? (e.g. Ant Design, Chakra UI, Carbon, Radix UI)
-2. Where should the widget components be generated? (e.g. `src/components/widget/`)
-
-If the user specified a subset (e.g., "just ToDo and Attachment"), restrict the list accordingly.
-
-Once both are known, continue to Step 1.
-
-### Full component list (default — 9 widgets)
-
-| Component       | Description                 |
-| --------------- | --------------------------- |
-| AppAnnouncement | System-wide announcements   |
-| Attachment      | File upload/download        |
-| CaseHistory     | Case audit trail            |
-| FileUtility     | File management utility     |
-| Followers       | Case followers list         |
-| QuickCreate     | Quick case creation buttons |
-| SummaryItem     | Single summary card         |
-| SummaryList     | List of summary cards       |
-| ToDo            | Assignment worklist         |
-
----
-
-## Step 1 — Read `widget-components.md` (once, for the entire session)
-
-Read the full contents of `.github/skills/widget-components.md`.
-
-This gives you:
-
-- The DS-agnostic data-fetching skeleton with `// [DS RENDER]` placeholder
-- The Design System Adaptation guide (primitive mapping table, icon discovery rules)
-- All common Pega APIs used in widgets: `PCore.getDataPageUtils()`, `PCore.getMashupApi()`, `PCore.getAttachmentUtils()`, `pConn.getCaseInfo()`, etc.
-- Registration conventions
-
-> The PCore data-fetching logic is always identical regardless of design system. Only the `// [DS RENDER]` section changes per DS.
-
-Keep this context active throughout the entire generation session. Do not re-read it per component.
-
----
-
-## Step 2 — Install and discover the design system (once)
-
-### 2a — Check and install the DS package
-
-Run this command in your terminal:
-
-```bash
-cat package.json | grep "<design-system-package>"
-```
-
-If the design system package is **not** listed in `dependencies` or `devDependencies`, install it:
-
-```bash
-npm install <design-system-package>
-```
-
-Also install any peer dependencies documented in the package's README. Report what was installed.
-
-### 2b — Discover the DS API from installed files
-
-Run these commands to discover the actual API (do NOT rely on training knowledge):
-
-1. Read the README for correct import paths and usage patterns:
-
-   ```bash
-   cat node_modules/<designSystem>/README.md
-   ```
-
-2. List every exported component:
-
-   ```bash
-   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"
-   ```
-
-3. For every component you plan to use (Card, List, Table, Button, Badge, Spinner), read its prop interface:
-
-   ```bash
-   find node_modules/<designSystem> -name "ComponentName.d.ts" | head -3
-   grep -A 40 "interface.*Props" <path-from-above>
-   ```
-
-4. Check for a **companion icon package** — if it exists, read its exports before using any icon name. Never guess icon names.
-
-5. Check for **size/variant conventions** — use built-in props rather than custom padding.
-
-6. Check for **CSS tokens** — use design system CSS custom properties for spacing; never hardcode `px` values.
-
-Only use component names and prop names confirmed in these files.
-
-Build a **DS UI primitive reference map** from this discovery. Reuse it for every widget — do not repeat these commands per component.
-
----
-
-## Step 3 — Overwrite check (all at once)
-
-For each component in the list, check whether `<outputPath>/<ComponentName>/<ComponentName>.tsx` already exists.
-
-If **any** exist, report them all at once and ask:
-
-> "The following N components already exist: [list]. How should I proceed?
->
-> - **Overwrite all** — replace all existing implementations
-> - **Skip existing** — only generate components that don't exist yet
-> - **Cancel** — stop without generating anything"
-
-Wait for the user's answer before proceeding. If none exist, continue immediately.
-
----
-
-## Step 4 — Generate each component (loop)
-
-For each component in the resolved list (in the order listed in Step 0):
-
-### 4a — Read the component-specific skill file (MANDATORY — do not skip)
-
-Read the file `.github/skills/widget-skills/<ComponentName>.md` using your file reading tool. This step is **required** for every component that has a skill file — do not rely solely on the general `widget-components.md`.
-
-After reading, extract and keep active:
-
-- **Behavioral Contract** — the exact PCore API calls, state variables, event handlers, and edge cases specific to this widget
-- **Design System Mapping** table — the recommended DS primitive for this component's presentation layer
-- **Props interface** — any required/optional props beyond the base `PConnProps`
-
-If no skill file exists at that path (e.g., `SummaryList`), use the general data-fetching pattern from `widget-components.md` loaded in Step 1.
-
-⚠️ The general skill file (`widget-components.md`) provides the skeleton. The component-specific skill file provides the **exact data flow and behavioral logic**. Both are needed — generating from only the general skill will produce components that render but don't fetch or display data correctly.
-
-### 4b — Generate the component files
-
-Create the directory `<outputPath>/<ComponentName>/`.
-
-Create `<ComponentName>.tsx` using this structure from `widget-components.md` (loaded in Step 1):
-
-1. Imports (React hooks + DS components from Step 2 + `PConnProps` from `@pega/sdk-react`)
-2. Interface extending PConnProps with props from the component skill file's Props table
-3. Component function: destructure `getPConnect`, call `getPConnect()` to get `pConn`
-4. `useEffect` → data fetch using the exact PCore API call from the skill file's Behavioral Contract
-5. Return → DS Card/List/Table primitive from Step 2 API map, rendering the fetched data
-
-Fill in the `// [DS RENDER]` section with DS primitives confirmed in Step 2. The data-fetching logic comes from the skill file's Behavioral Contract — do NOT invent API calls.
-
-Create `index.tsx`:
-
-```typescript
-export { default } from './<ComponentName>';
-```
-
-Create any CSS or utility files required by the skill file.
-
-### 4c — Register the component
-
-Edit `src/components/component-map.ts`:
-
-1. Add an import at the top of the file in the **Widgets** section:
-   ```typescript
-   import <ComponentName> from './widget/<ComponentName>';
-   ```
-2. Add an entry in the return object of `getSampleComponentMap()` under the widgets comment:
-   ```typescript
-   <ComponentName>,
-   ```
-
-Do not reorder or restructure any existing entries.
-
-### 4d — Batch checkpoint
-
-After every **5 components**, run:
-
-```bash
-npm run build
-```
-
-Fix any TypeScript or build errors before continuing to the next component. This prevents error accumulation.
-
-### 4e — Report progress
-
-After each component: "`<ComponentName>` ✓ — using `<DS card/list primitive>`"
-
----
-
-## Step 5 — Verify the build
-
-Run:
-
-```bash
-npm run build
-```
-
-If build errors occur, fix them before reporting completion. Report a summary: list of all files created and all entries added to `component-map.ts`.