@pega/sdk 0.0.12 → 0.0.14

package/templates/angular-sdk-reference/src/components/templates/narrow-wide/narrow-wide.component.ts

@@ -0,0 +1,37 @@
+/**
+ * NarrowWide — narrow-left/wide-right two-column layout (1:2 ratio).
+ *
+ * Pattern reference: angular-sdk-components NarrowWideFormComponent + sdk-react NarrowWide
+ */
+
+/* eslint-disable @typescript-eslint/no-explicit-any */
+import { Component, Input } from '@angular/core';
+import type { OnInit } from '@angular/core';
+import { CommonModule } from '@angular/common';
+import { PConnectBridgeComponent } from '@pega/sdk-angular';
+
+@Component({
+  selector: 'pega-narrow-wide',
+  standalone: true,
+  imports: [CommonModule, PConnectBridgeComponent],
+  template: `
+    <div style="display: grid; grid-template-columns: 1fr 2fr; gap: 1rem;">
+      <div *ngFor="let getter of childGetters">
+        <pconnect-bridge [getPConnect]="getter"></pconnect-bridge>
+      </div>
+    </div>
+  `,
+})
+export class NarrowWideComponent implements OnInit {
+  @Input() props: any;
+
+  childGetters: Array<() => typeof PConnect> = [];
+
+  ngOnInit(): void {
+    const pConn = this.props.getPConnect();
+    const children = pConn.getChildren?.() ?? [];
+    this.childGetters = children.map((child: any) => {
+      return child.getPConnect ?? (() => child);
+    });
+  }
+}

package/templates/angular-sdk-reference/src/components/templates/one-column/one-column.component.ts

@@ -0,0 +1,37 @@
+/**
+ * OneColumn — single-column layout template that renders children vertically.
+ *
+ * Pattern reference: angular-sdk-components OneColumnComponent + sdk-react OneColumn
+ */
+
+/* eslint-disable @typescript-eslint/no-explicit-any */
+import { Component, Input } from '@angular/core';
+import type { OnInit } from '@angular/core';
+import { CommonModule } from '@angular/common';
+import { PConnectBridgeComponent } from '@pega/sdk-angular';
+
+@Component({
+  selector: 'pega-one-column',
+  standalone: true,
+  imports: [CommonModule, PConnectBridgeComponent],
+  template: `
+    <div style="display: flex; flex-direction: column; gap: 0.25rem;">
+      <div *ngFor="let getter of childGetters">
+        <pconnect-bridge [getPConnect]="getter"></pconnect-bridge>
+      </div>
+    </div>
+  `,
+})
+export class OneColumnComponent implements OnInit {
+  @Input() props: any;
+
+  childGetters: Array<() => typeof PConnect> = [];
+
+  ngOnInit(): void {
+    const pConn = this.props.getPConnect();
+    const children = pConn.getChildren?.() ?? [];
+    this.childGetters = children.map((child: any) => {
+      return child.getPConnect ?? (() => child);
+    });
+  }
+}

package/templates/angular-sdk-reference/src/components/templates/two-column/two-column.component.ts

@@ -0,0 +1,37 @@
+/**
+ * TwoColumn — two-column grid layout template.
+ *
+ * Pattern reference: angular-sdk-components TwoColumnComponent + sdk-react TwoColumn
+ */
+
+/* eslint-disable @typescript-eslint/no-explicit-any */
+import { Component, Input } from '@angular/core';
+import type { OnInit } from '@angular/core';
+import { CommonModule } from '@angular/common';
+import { PConnectBridgeComponent } from '@pega/sdk-angular';
+
+@Component({
+  selector: 'pega-two-column',
+  standalone: true,
+  imports: [CommonModule, PConnectBridgeComponent],
+  template: `
+    <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 1rem;">
+      <div *ngFor="let getter of childGetters">
+        <pconnect-bridge [getPConnect]="getter"></pconnect-bridge>
+      </div>
+    </div>
+  `,
+})
+export class TwoColumnComponent implements OnInit {
+  @Input() props: any;
+
+  childGetters: Array<() => typeof PConnect> = [];
+
+  ngOnInit(): void {
+    const pConn = this.props.getPConnect();
+    const children = pConn.getChildren?.() ?? [];
+    this.childGetters = children.map((child: any) => {
+      return child.getPConnect ?? (() => child);
+    });
+  }
+}

package/templates/angular-sdk-reference/src/components/templates/wide-narrow/wide-narrow.component.ts

@@ -0,0 +1,37 @@
+/**
+ * WideNarrow — wide-left/narrow-right two-column layout (2:1 ratio).
+ *
+ * Pattern reference: angular-sdk-components WideNarrowFormComponent + sdk-react WideNarrow
+ */
+
+/* eslint-disable @typescript-eslint/no-explicit-any */
+import { Component, Input } from '@angular/core';
+import type { OnInit } from '@angular/core';
+import { CommonModule } from '@angular/common';
+import { PConnectBridgeComponent } from '@pega/sdk-angular';
+
+@Component({
+  selector: 'pega-wide-narrow',
+  standalone: true,
+  imports: [CommonModule, PConnectBridgeComponent],
+  template: `
+    <div style="display: grid; grid-template-columns: 2fr 1fr; gap: 1rem;">
+      <div *ngFor="let getter of childGetters">
+        <pconnect-bridge [getPConnect]="getter"></pconnect-bridge>
+      </div>
+    </div>
+  `,
+})
+export class WideNarrowComponent implements OnInit {
+  @Input() props: any;
+
+  childGetters: Array<() => typeof PConnect> = [];
+
+  ngOnInit(): void {
+    const pConn = this.props.getPConnect();
+    const children = pConn.getChildren?.() ?? [];
+    this.childGetters = children.map((child: any) => {
+      return child.getPConnect ?? (() => child);
+    });
+  }
+}

package/templates/angular-sdk-reference/src/helpers/event-utils.ts

@@ -0,0 +1,18 @@
+// From DX Components src/utils/event-utils.js
+
+export function handleEvent(actions: any, eventType: string, propName: string, value: string | boolean | number) {
+  switch (eventType) {
+    case 'change':
+      actions.updateFieldValue(propName, value);
+      break;
+    case 'blur':
+      actions.triggerFieldChange(propName, value);
+      break;
+    case 'changeNblur':
+      actions.updateFieldValue(propName, value);
+      actions.triggerFieldChange(propName, value);
+      break;
+    default:
+      break;
+  }
+}

package/templates/angular-sdk-reference/src/helpers/utils.ts

@@ -0,0 +1,38 @@
+export function getOptionList(configProps: any, dataObject: any): any[] {
+  const listType = configProps.listType;
+  let arReturn: any[] = [];
+
+  if (listType) {
+    switch (listType.toLowerCase()) {
+      case 'associated':
+        // data source should be an array
+        if (typeof configProps.datasource === 'object') {
+          arReturn = configProps.datasource;
+        }
+        break;
+
+      case 'datapage':
+        // get data page
+        // eslint-disable-next-line no-case-declarations
+        const dataPage = configProps.datasource;
+        if (typeof dataPage === 'string' && dataObject[dataPage]) {
+          alert('need to handle data page');
+        } else {
+          let listSourceItems = configProps.listOutput;
+          if (typeof dataPage === 'object' && !Array.isArray(listSourceItems)) {
+            listSourceItems = dataPage.source ? dataPage.source : [];
+          }
+          (listSourceItems || []).forEach((item: any) => {
+            item.value = item.text ? item.text : item.value;
+          });
+          arReturn = listSourceItems || [];
+        }
+        break;
+
+      default:
+        break;
+    }
+  }
+
+  return arReturn;
+}

package/templates/angular-sdk-reference/src/helpers/versionHelpers.ts

@@ -0,0 +1,14 @@
+/**
+ * versionHelpers.ts
+ *
+ * Container helper functions that can identify which version of
+ * PCore/PConnect is being run
+ */
+
+export const sdkVersion = '8.7';
+
+export function compareSdkPCoreVersions() {
+  // const theConstellationVersion = PCore.getPCoreVersion();
+
+  console.warn(`Using Constellation version ${PCore.getPCoreVersion()}. Ensure this is the same version as your Infinity server.`);
+}

package/templates/angular-sdk-reference/tsconfig.json

@@ -1,11 +1,12 @@
 {
   "compileOnSave": false,
   "compilerOptions": {
+    "rootDir": "../..",
     "outDir": "./dist/out-tsc",
     "forceConsistentCasingInFileNames": true,
     "strict": true,
     "noImplicitOverride": true,
-    "noPropertyAccessFromIndexSignature": true,
+    "noPropertyAccessFromIndexSignature": false,
     "noImplicitReturns": true,
     "noFallthroughCasesInSwitch": true,
     "sourceMap": true,
@@ -21,7 +22,9 @@
       "@pega/sdk-angular": ["../../packages/sdk-angular/src/index.ts"],
       "@pega/sdk-types": ["../../packages/sdk-types/src/index.ts"]
     },
-    "ignoreDeprecations": "5.0"
+    "ignoreDeprecations": "5.0",
+    "typeRoots": ["../../node_modules/@types", "../../node_modules/@pega"],
+    "types": ["pcore-pconnect-typedefs"]
   },
   "angularCompilerOptions": {
     "enableI18nLegacyMessageIdFormat": false,

package/templates/react-sdk-reference/.ai-common/agents/embedded-flow-expert.md

@@ -55,7 +55,7 @@ Determine which workflow governs the request, then execute it by reading the ref
 
 ### Step 0.0 — Ensure the Pega server connection is configured
 
-Before executing any data source below, read and execute `{{SKILL_DIR}}/connect-pega-server.md`. It is a no-op when the connection is already configured, and otherwise gathers the missing values from the user and writes them into the MCP config and `sdk-config.json` before this step continues.
+Before executing any data source below, read and execute `{{SKILL_DIR}}/connect-pega-server.md`. It is a no-op when the connection is already configured. Otherwise, it resolves existing values from the active MCP config, browser-served `sdk-config.json`, and environment files, then asks once for every missing non-secret value. The user may provide those values in chat or write them into any allowed configuration file named by the gate; the assistant re-reads the files and synchronizes every applicable destination. The gate may pause for an environment-sourced Pega MCP client secret (Cursor only) or an MCP reconnect. After the user retries, rerun the gate before executing any data source.
 
 ### Step 0.1 — Check for a case type in the prompt
 
@@ -90,7 +90,7 @@ Reduce that response to a generatable list by applying the following in order. P
 2. **Keep components that appear in at least one lifecycle view.** A view is out-of-the-box, and therefore not part of the case lifecycle, when its name begins with `py` or `pz`, or when it is `CaseHistory`. Keep a component if it appears in **at least one** view that is not out-of-the-box. A component may legitimately appear in both kinds of view — one lifecycle view is enough to keep it. Drop a component only when every view it appears in is out-of-the-box.
 
 3. **Strip what is never generated, wherever it appears.** This rule is independent of point 2 and applies even to components that passed it:
-   - Structural wrappers the SDK's registry already provides and that render nothing of their own: View, Region, FlowContainer, Assignment, CaseView, RootContainer. Templates traverse through these to reach their children rather than rendering them, so there is no visual contract to implement.
+   - Structural wrappers the SDK's registry already provides and that render nothing of their own: View, Region, FlowContainer, Assignment, CaseView, RootContainer, and reference nodes. Templates traverse through these to reach their children rather than rendering them, so there is no visual contract to implement. A reference node resolves a view by name — including the one an embedded record uses for its inline form — and the runtime already handles it.
    - Any component whose name starts with `px` (internal Pega infrastructure)
    - Chrome the SDK adapter provides and that is never generated: NavBar, DeferLoad, VerticalTabs, DashboardFilter
    - Chrome whose fate point 4 decides rather than the data page: ActionButtons, Stages, MultiStep
@@ -103,9 +103,15 @@ Reduce that response to a generatable list by applying the following in order. P
 
    `Stages` is the counter-example: it is case chrome, never appears in an embedded assignment, and must not be generated for an embedded flow. It stays stripped.
 
-5. **Present the resolved list, and the exclusions with their reasons.** Name what will be generated, then separately name what was dropped because it appears only in out-of-the-box views, and what was stripped because it is never generated. An exclusion the user disagrees with is far easier to catch when it is visible, and a silently missing component surfaces much later as a rendering gap. **Report the starting fields here too** — either the property names the case type accepts at creation, or that none were confirmed and pre-fill will therefore be off. This is the last point before analysis and generation begin, so it is the last cheap moment for the user to correct either one. Then ask whether to proceed.
+5. **Present the resolved list, and the exclusions with their reasons.** Name what will be generated, then separately name what was dropped because it appears only in out-of-the-box views, what was stripped because it is never generated, and what was added because a selected component declares it as a registry dependency. An exclusion the user disagrees with is far easier to catch when it is visible, and a silently missing component surfaces much later as a rendering gap. **Report the starting fields here too** — either the property names the case type accepts at creation, or that none were confirmed and pre-fill will therefore be off. This is the last point before analysis and generation begin, so it is the last cheap moment for the user to correct either one. Then ask whether to proceed.
 
-6. **Beyond the additions in point 4, generate only what this resolved list contains.** Do NOT add components based on assumptions about what a case type might need.
+6. **Beyond the additions in point 4, generate only what this resolved list contains, plus the registry dependencies the selected components declare.** Do NOT add components based on assumptions about what a case type might need.
+
+   Some components are orchestrators: they render no control of their own, and instead resolve other components from the registry at runtime. Reference fields and embedded data fields are the clearest examples — one of them may resolve a table, a repeating-group template, a picker, or a value display depending on how it was configured. Those dependencies are building blocks rather than fields, so they never appear in view metadata and this data page never returns them. A registry lookup that finds nothing degrades to a fallback or a blank render rather than raising an error, so an orchestrator generated on its own looks like a styling fault rather than a missing component.
+
+   A dependency named in a generated component's own skill file is therefore **not** an assumption — it is part of that component's contract. Read each selected component's skill file, collect the registry keys it declares it will resolve, and add any that are neither already registered in the project nor already in the list. The dependency is **transitive**: a dependency's own skill may declare further ones, so repeat until the set stops growing. Record which component required each addition, and report them under point 5 separately from the chrome added by point 4.
+
+   The distinction to hold: a dependency a skill file declares is required, and omitting it produces a component that cannot render. A component you believe a case type might need is not. Never widen the list on your own judgement.
 
 ### Step 0.4 — Proceed to workflows
 
@@ -127,13 +133,13 @@ Step 0 of the wire-integration skill resolves both, checks whether the named con
 
 If the user named a launch point but no render target, the skill infers it from what the control already does. If they named neither, the skill asks using surfaces drawn from the customer's own application. Never assume either one.
 
-| Workflow           | Required inputs                                                                                   |
-| ------------------ | ------------------------------------------------------------------------------------------------- |
-| Analyze            | Case type class + access to the customer's codebase                                               |
-| Generate           | Case type class + component list + Design Profile (or permission to create one)                   |
-| Full embedded flow | Case type class + server-resolved component list + codebase access + launch point + render target |
-| Wire integration   | Case type class + generated `pega-components/` folder must exist + launch point + render target   |
-| Verify integration | A wired integration + a human available to authenticate when the flow reaches the Pega login form |
+| Workflow           | Required inputs                                                                                                             |
+| ------------------ | --------------------------------------------------------------------------------------------------------------------------- |
+| Analyze            | Case type class + access to the customer's codebase                                                                         |
+| Generate           | Case type class + component list + Design Profile (or permission to create one)                                             |
+| Full embedded flow | Case type class + server-resolved component list + codebase access + launch point + render target                           |
+| Wire integration   | Case type class + generated components folder (location resolved during analysis) must exist + launch point + render target |
+| Verify integration | A wired integration + a human available to authenticate when the flow reaches the Pega login form                           |
 
 ---
 
@@ -143,12 +149,12 @@ If the user named a launch point but no render target, the skill infers it from
 2. **Always read before executing** — read the skill or prompt file fully before acting on it. Never paraphrase from memory.
 3. **Follow steps in order** — each skill/prompt defines numbered steps. Execute them sequentially without skipping.
 4. **Design Profile is the bridge** — the analysis skill produces it, the generation prompt consumes it. If generation is requested and no profile exists, analysis must run first. Step 0 of the wiring skill consumes it too, when it has to ask where the flow should render — which is why analysis precedes that gate rather than following it.
-5. **Never modify the customer's existing code** except at the seams that the wiring and verification skills enumerate. The `pega-components/` folder is purely additive, and a failing verification check is never permission to edit customer code outside those seams to make it pass.
+5. **Never modify the customer's existing code** except at the seams that the wiring and verification skills enumerate. The generated components folder (location resolved during analysis and recorded in the Design Profile) is purely additive, and a failing verification check is never permission to edit customer code outside those seams to make it pass.
 6. **Component skills are authoritative** — the behavioral contracts in `{{SKILL_DIR}}/field-skills/`, `template-skills/`, `widget-skills/`, `design-system-extension-skills/`, and `infra-skills/` define what each component must do. These are non-negotiable.
 7. **Adapt to the customer's framework** — the skills and prompts are framework-agnostic. Determine the customer's framework from their project configuration and apply conventions accordingly.
 8. **Verification is mandatory, and it is not only static** — the generation prompt's checks confirm the generated files are well-formed. They do not confirm the flow runs. Whenever the integration has been wired, finish with `{{SKILL_DIR}}/embedded-flow/run-and-verify-integration.md` and report how far it got. Never declare success on static checks alone.
 9. **Case type class must be used** — the confirmed case type class must be written into `sdk-config.json` (in the `appMashupCaseType` field) and used in the bootstrap/wiring module when calling the mashup API to create a case.
-10. **Only generate server-resolved components** — generate exactly what Step 0.3 produced: the components the case type's data page returned and that survived its filters, plus the additions point 4 names (`FieldValueList`, `ActionButtons`, and `MultiStep` for a multi-step case). Do NOT add anything else based on assumptions about what a case type might need.
+10. **Only generate server-resolved components, their declared dependencies, and the named chrome** — generate exactly what Step 0.3 produced: the components the case type's data page returned and that survived its filters, the additions point 4 names (`FieldValueList`, `ActionButtons`, and `MultiStep` for a multi-step case), and the registry dependencies that the selected components' own skill files declare, resolved transitively per point 6. Do NOT add anything else based on assumptions about what a case type might need.
 11. **Never silently replace existing behaviour, and never assume where the flow renders** — before anything is written, resolve the launch point and the render target. If the named control already does something, ask whether to override; if they decline, stop the whole flow, do not embed on a different control, and do not leave partial edits behind. If the render target was never stated and cannot be inherited from the control's existing behaviour, ask. See Step 0 of the wire-integration skill.
 12. **Never handle credentials** — when verification reaches the Pega login form in the browser, a human signs in at a visible window. Do not request, capture, log, echo, or store those credentials, at any stage and under any failure condition.
 
@@ -164,6 +170,7 @@ If the user named a launch point but no render target, the skill infers it from
 | Every component is removed by the lifecycle filter               | The case type may have no lifecycle views. Show the views that were returned, explain that all of them are out-of-the-box, and ask the user to confirm before proceeding                                                                                                                                                                       |
 | Customer's project uses an unfamiliar framework                  | Read the framework's documentation (if accessible) + rely heavily on the representative components from the Design Profile                                                                                                                                                                                                                     |
 | A requested component has no skill file                          | The name is not a Pega component name. Resolve it to a canonical one using the staged process in Step 1 of the generation prompt (normalized name, then alias table, then behaviour class, then ask the user), implement that component's skill, and tell the user which substitution you made                                                 |
+| A generated component renders blank or shows the fallback        | Most likely a registry dependency it resolves at runtime was never generated. Orchestrator components fail this way silently. Re-read that component's skill file, collect the registry keys it declares, and confirm each one is registered — see point 6 of Step 0.3. Do not treat it as a styling fault                                     |
 | Design Profile extraction finds no clear patterns                | Ask the user to point to specific example components in their codebase                                                                                                                                                                                                                                                                         |
 | Generated component fails type check after 2 retries             | Report the specific error, show the problematic code, and ask the user for guidance                                                                                                                                                                                                                                                            |
 | Customer uses multiple design systems in one project             | Ask which one should be used for the Pega components, or default to the one used for form elements                                                                                                                                                                                                                                             |

package/templates/react-sdk-reference/.ai-common/global/ai-agent-instructions-embedded.md

@@ -47,7 +47,7 @@ Pega SDK packages (`.tgz` files) have been added to the project root and referen
 
 ### SDK Configuration
 
-`sdk-config.json` contains connection details for the Pega server. The AI assistant gathers the server URL, app alias, OAuth client ID, and (when the MCP configuration requires one) a client secret from the user in chat the first time a workflow needs them, and fills them in automatically — see `{{SKILL_DIR}}/connect-pega-server.md`. The case type is resolved from the server during the embedded flow itself.
+The browser-served `sdk-config.json` contains non-secret Pega server connection details. The first workflow that needs a live server runs `{{SKILL_DIR}}/connect-pega-server.md`, which resolves values from the active SDK config, MCP config, and environment files, then asks once for all missing non-secret values. The user may provide those values in chat or update an allowed file; the assistant synchronizes every applicable destination. Only a Cursor-style MCP entry requires a Pega MCP client secret, which must come from a private environment variable and is never requested in chat or written to `sdk-config.json`. The browser SDK's OAuth grant configuration remains the user's choice. The case type is resolved from the server during the embedded flow itself.
 
 ---
 
@@ -100,7 +100,7 @@ Most infrastructure components ship from the SDK and are never generated. Three
 
 ## 5. Rules
 
-1. **Never modify the customer's existing components during analysis or generation** — the `pega-components/` folder is additive. Wiring is the exception: it edits the integration seams listed in the wire-integration skill, plus the verification tooling seams listed in the run-and-verify-integration skill. A failing verification check never widens that set
+1. **Never modify the customer's existing components during analysis or generation** — the generated components folder (location resolved during analysis and recorded in the Design Profile) is additive. Wiring is the exception: it edits the integration seams listed in the wire-integration skill, plus the verification tooling seams listed in the run-and-verify-integration skill. A failing verification check never widens that set
 2. **Match the customer's conventions** — generated code should look like the customer wrote it
 3. **Satisfy the Pega behavioral contract** — every component must implement what its skill file requires
 4. **Use the customer's design system** — never introduce a new UI library

package/templates/react-sdk-reference/.ai-common/global/ai-agent-instructions.md

@@ -10,7 +10,7 @@ This is a **reference implementation** — not a framework. The UI components (f
 
 ### SDK Configuration
 
-`sdk-config.json` and the generated MCP config file are scaffolded blank/placeholder — connection details are never collected at scaffold time. The AI assistant gathers the server URL, app alias, OAuth client ID, and MCP rule details from the user in chat the first time a workflow needs a live Pega server (e.g. resolving portals/components in Section 15), and fills them into both files automatically — see `{{SKILL_DIR}}/connect-pega-server.md`.
+`sdk-config.json` and the generated MCP config file are scaffolded blank/placeholder — connection details are never collected at scaffold time. The first workflow that needs a live Pega server runs `{{SKILL_DIR}}/connect-pega-server.md`, which resolves values from the active SDK config, MCP config, and environment files, then asks once for all missing non-secret values. The user may provide those values in chat or update an allowed file; the assistant synchronizes every applicable destination. A Pega MCP client secret is required only when the active MCP entry has `auth.clientSecret` (currently Cursor), must come from a private environment variable, and is never requested in chat or written to browser-served SDK configuration.
 
 ---
 

package/templates/react-sdk-reference/.ai-common/instructions/dse-component.md

@@ -1,5 +1,5 @@
 ---
-ai-globs: **/designSystemExtension/**/*
+ai-globs: **/{AlertBanner,Banner,CaseSummaryFields,DetailsFields,FieldGroup,FieldGroupList,FieldValueList,Operator,Pulse,RichTextEditor,WssQuickCreate}/**/*
 ---
 
 # Design System Extension Component Rules

package/templates/react-sdk-reference/.ai-common/instructions/embedded-component.md

@@ -10,7 +10,7 @@ When generating or modifying Pega components in the `pega-components/` folder (c
 
 ## Context
 
-These components are different from the reference app's sample components. They are generated to live **inside a customer's existing project**, using the customer's design system so that they are visually indistinguishable from the rest of their UI. The Design Profile (`.design-profile.md`) in the same folder describes the customer's visual conventions.
+These components are different from the reference app's sample components. They are generated to live **inside a customer's existing project**, using the customer's design system so that they are visually indistinguishable from the rest of their UI. The Design Profile (`docs/design-profile.md` at the project root) describes the customer's visual conventions.
 
 ---
 

package/templates/react-sdk-reference/.ai-common/instructions/field-component.md

@@ -1,5 +1,5 @@
 ---
-ai-globs: **/field/**/*
+ai-globs: **/{AutoComplete,CancelAlert,Checkbox,Currency,Date,DateTime,Decimal,Dropdown,Email,Group,Integer,Location,Multiselect,ObjectReference,Percentage,Phone,RadioButtons,RichText,ScalarList,SelectableCard,SemanticLink,TextArea,TextContent,TextInput,Time,URL,UserReference}/**/*
 ---
 
 # Field Component Rules

package/templates/react-sdk-reference/.ai-common/instructions/infra-component.md

@@ -1,5 +1,5 @@
 ---
-ai-globs: **/infra/**/*
+ai-globs: **/{ActionButtons,DashboardFilter,DeferLoad,MultiStep,NavBar,Stages,VerticalTabs}/**/*
 ---
 
 # Infrastructure (Chrome) Component Rules

package/templates/react-sdk-reference/.ai-common/instructions/template-component.md

@@ -1,5 +1,5 @@
 ---
-ai-globs: **/template/**/*
+ai-globs: **/{AdvancedSearch,AppShell,BannerPage,CaseSummary,CaseView,CaseViewActionsMenu,Confirmation,DataReference,DefaultForm,DefaultPage,Details,FieldGroupTemplate,HierarchicalForm,InlineDashboard,InlineDashboardPage,ListPage,ListView,MultiReferenceReadOnly,NarrowWide,ObjectPage,OneColumn,PromotedFilters,SelfServiceCaseView,SimpleTable,SingleReferenceReadOnly,SubTabs,TwoColumn,WideNarrow,WssNavBar,SearchForm,SearchGroups}/**/*
 ---
 
 # Template Component Rules

package/templates/react-sdk-reference/.ai-common/instructions/widget-component.md

@@ -1,5 +1,5 @@
 ---
-ai-globs: **/widget/**/*
+ai-globs: **/{AppAnnouncement,Attachment,CaseHistory,FileUtility,Followers,QuickCreate,SummaryItem,SummaryList,ToDo,ActionButtonsForFileUtil}/**/*
 ---
 
 # Widget Component Rules

package/templates/react-sdk-reference/.ai-common/prompts/component-manifest.json

@@ -29,6 +29,11 @@
       { "name": "Decimal", "path": "src/components/field/Decimal" },
       { "name": "Dropdown", "path": "src/components/field/Dropdown" },
       { "name": "Email", "path": "src/components/field/Email" },
+      { "name": "EmbeddedData", "path": "src/components/field/EmbeddedData" },
+      {
+        "name": "EmbeddedDataMulti",
+        "path": "src/components/field/EmbeddedDataMulti"
+      },
       { "name": "Group", "path": "src/components/field/Group" },
       { "name": "Integer", "path": "src/components/field/Integer" },
       { "name": "Location", "path": "src/components/field/Location" },
@@ -274,6 +279,8 @@
     "web address": ["URL"],
     "formatted rich text entry": ["RichText", "RichTextEditor"],
     "list of simple values": ["ScalarList"],
+    "a record stored on the case itself": ["EmbeddedData"],
+    "a list of records stored on the case itself": ["EmbeddedDataMulti"],
     "reference to another record": ["ObjectReference"],
     "reference to a person": ["UserReference", "Operator"],
     "geographic location": ["Location"],

package/templates/react-sdk-reference/.ai-common/prompts/embedded-component-manifest.md

@@ -105,7 +105,7 @@ Record the visual treatment only. Generated components read validation messages
 
 ### 4. File Conventions
 
-**Context only.** Generated components use Pega-owned paths and names (`pega-components/{type}/{ComponentName}/`), so Structure and Naming below do not apply to them. Re-exports, test location, and style location still inform co-located files.
+**Context only.** Generated components use Pega-owned paths and names (`{output_path}/{ComponentName}/`), so Structure and Naming below do not apply to them. Re-exports, test location, and style location still inform co-located files.
 
 | Field          | Description                                             |
 | -------------- | ------------------------------------------------------- |
@@ -126,7 +126,7 @@ Record the visual treatment only. Generated components read validation messages
 | Default/named preference | Which import style dominates                                     |
 | Style imports            | How stylesheets or style modules are imported                    |
 
-Generated components import the customer's UI primitives through their path aliases. Relative paths are used only _within_ `pega-components/` — for shared helpers, barrel files, and the registry file's component imports. One Pega component is never imported into another to render it; that always goes through the component registry.
+Generated components import the customer's UI primitives through their path aliases. Relative paths are used only _within_ the generated output folder (`{output_path}`) — for shared helpers, barrel files, and the registry file's component imports. One Pega component is never imported into another to render it; that always goes through the component registry.
 
 ---
 

package/templates/react-sdk-reference/.ai-common/prompts/generate-all-components.md

@@ -57,7 +57,7 @@ Once design system, base folder, and type scope are resolved, continue to Step 0
 
 ### 0.5.0 — Ensure the Pega server connection is configured
 
-Before executing any data source below, read and execute `{{SKILL_DIR}}/connect-pega-server.md`. It is a no-op when the connection is already configured, and otherwise gathers the missing values from the user and writes them into the MCP config and `sdk-config.json` before this step continues.
+Before executing any data source below, read and execute `{{SKILL_DIR}}/connect-pega-server.md`. It is a no-op when the connection is already configured. Otherwise, it resolves existing values from the active MCP config, application `sdk-config.json`, and environment files; asks once for every missing non-secret value; and writes chat-provided values to every applicable file. It may pause for an environment-sourced Pega MCP client secret (Cursor only) or an MCP reconnect. After the user retries, rerun the gate before executing any data source.
 
 ### 0.5.1 — Resolve the portal
 
@@ -193,7 +193,9 @@ Intersect the confirmed selection with the type scope from Step 0, group the res
 - Step 3 checks for existing files only within the generation set.
 - Steps 4–8 each generate only the components of their type that are in the generation set, and are skipped entirely when it holds none of their type.
 
-Generate nothing outside the generation set. Do not add components based on assumptions about what a portal might need.
+Generate nothing outside the generation set, with one exception: the registry dependencies that the selected components' own skill files declare. Some components are orchestrators — they render no control of their own and instead resolve other components from the registry at runtime, as reference and embedded data fields do. Those dependencies are building blocks rather than fields, so they never appear in view metadata and no data source above returns them, and a registry lookup that finds nothing degrades to a blank render rather than raising an error. Read each selected component's skill file, collect the registry keys it declares it will resolve, and add any that are neither already registered nor already in the set; repeat until the set stops growing, since a dependency's own skill may declare further ones. Report these additions in the Step 9 summary, naming which component required each.
+
+A dependency a skill file declares is required. A component you believe a portal might need is not — do not add components based on assumptions about what a portal might need.
 
 ---
 

package/templates/react-sdk-reference/.ai-common/prompts/generate-embedded-components.md

@@ -1,5 +1,5 @@
 ---
-ai-description: "Generate Pega components styled to match a customer's existing application — given a component list and a Design Profile, produces a pega-components/ folder with implementations that satisfy the Pega behavioral contract while rendering with the customer's design system, tokens, and styling approach, and reading like their own code"
+ai-description: "Generate Pega components styled to match a customer's existing application — given a component list and a Design Profile, produces a generated components folder (location chosen by the user during analysis) with implementations that satisfy the Pega behavioral contract while rendering with the customer's design system, tokens, and styling approach, and reading like their own code"
 ---
 
 ## Step 0 — Resolve missing information
@@ -7,8 +7,8 @@ ai-description: "Generate Pega components styled to match a customer's existing
 Read the user's message carefully. Extract:
 
 - **Component list** — the Pega component names to generate (e.g., `TextInput`, `Dropdown`, `DefaultForm`, `TwoColumn`, `ToDo`)
-- **Design Profile location** — the path to the `.design-profile.md` file (default: `pega-components/.design-profile.md`)
-- **Output path** — where to write the generated components (default: `pega-components/`)
+- **Design Profile location** — always `docs/design-profile.md` at the project root. This location is fixed and never moves with the output path
+- **Output path** — read the **Output Path** field from Section 1 of the Design Profile and use it verbatim as `{output_path}`. Never re-ask for it and never fall back to a hardcoded default — it was already resolved once, with the user, during analysis
 
 The **component list** is required. If it is not provided and cannot be inferred from prior conversation context, stop and ask the user.
 
@@ -77,7 +77,7 @@ After every name is resolved, group the canonical names by type so you can read
 
 Read the following **once** before the generation loop:
 
-1. **The Design Profile** — read the full `.design-profile.md`. Its design tokens, styling convention, and validation display convention are authoritative and must be replicated. Its component patterns (input interface, state management, event handling) and file conventions describe the customer's own code — read them for context, but generated components follow the Pega contract and Pega-owned paths instead.
+1. **The Design Profile** — read the full `docs/design-profile.md`. Its design tokens, styling convention, and validation display convention are authoritative and must be replicated. Its component patterns (input interface, state management, event handling) and file conventions describe the customer's own code — read them for context, but generated components follow the Pega contract and Pega-owned paths instead.
 
 2. **General type-level skills** — for each component type present in the grouped list, read the corresponding general skill:
 
@@ -161,17 +161,16 @@ Create the component implementation that satisfies **both**:
 
 State, events, validation wiring, and prop contracts are deliberately absent from that list — they come from the Pega behavioral contract above, no matter how the customer writes their own forms. A customer whose own screens use a form library does not change how a generated component holds a value or commits it.
 
-**Exception — the output path is not the customer's to choose.** `pega-components/` is a generated, Pega-owned tree that the customer never authors in, so its layout is fixed rather than inferred from the Design Profile. Write the component to:
+**Exception — the layout beneath `{output_path}` is not the customer's to choose.** The folder the user resolved during analysis is a generated, Pega-owned tree that the customer never authors in, so what goes underneath it is fixed rather than inferred from the Design Profile. Write the component to:
 
 ```
-{output_path}/{type}/{ComponentName}/{ComponentName}.{ext}
+{output_path}/{ComponentName}/{ComponentName}.{ext}
 ```
 
-- `{type}` is literal — `field`, `template`, `widget`, `designSystemExtension`, or `infra` — and is never renamed or flattened. The instruction globs match on it.
-- `{ComponentName}` is the canonical Pega component name resolved in Step 1, verbatim, for both the folder and the implementation file, whatever the customer's naming style is. `Checkbox` produces `Checkbox/Checkbox.*`, never `checkbox/CheckboxField.*`; `Date` produces `Date/Date.*`, never `date/DateField.*`.
+- `{ComponentName}` is the canonical Pega component name resolved in Step 1, verbatim, for both the folder and the implementation file, whatever the customer's naming style is. `Checkbox` produces `Checkbox/Checkbox.*`, never `checkbox/CheckboxField.*`; `Date` produces `Date/Date.*`, never `date/DateField.*`. Components are never grouped into a further `field`/`template`/`widget`/`designSystemExtension`/`infra` subfolder — every component's own folder sits directly under `{output_path}`.
 - `{ext}` follows the customer's framework, not their file-naming style.
 
-Deterministic paths are what let tooling, globs, and regeneration find components again. Customer conventions govern the _contents_ of these files, not their location or name. If the customer's repo lints file names, exclude `pega-components/` from that rule rather than bending the paths.
+Deterministic paths are what let tooling and regeneration find components again. Customer conventions govern the _contents_ of these files, not their location or name. If the customer's repo lints file names, exclude `{output_path}` from that rule rather than bending the paths.
 
 ### 4d. Register the component
 
@@ -277,7 +276,7 @@ Read the generated registry file and confirm:
 Verify that every import in the generated files resolves to either:
 
 - A package present in the customer's dependency manifest
-- A file within the generated `pega-components/` folder
+- A file within the generated components folder (`{output_path}`)
 - The Pega SDK packages (added in integration wiring)
 
 If any import references a package not in the project, either:
@@ -304,7 +303,7 @@ Whenever `Requested Name` and `Resolved As` differ, say so in your reply as well
 
 1. **Never invent UI primitives** — only use components available in the customer's UI library or their custom component set
 2. **Never skip behavioral requirements** — every item in the skill file's contract must be implemented, even if the customer's equivalent doesn't natively support it (add the behavior manually)
-3. **Never break existing code** — the generated `pega-components/` folder is additive; never modify the customer's existing components. This prompt does not wire the integration or verify it — those are separate steps, and they are the only ones permitted to edit the customer's files, confined to the seams their skills enumerate
+3. **Never break existing code** — the generated components folder (`{output_path}`) is additive; never modify the customer's existing components. This prompt does not wire the integration or verify it — those are separate steps, and they are the only ones permitted to edit the customer's files, confined to the seams their skills enumerate
 4. **Never hardcode design tokens** — always reference the customer's token system (variables, constants, theme values)
 5. **Respect the customer's code conventions** — the contents of generated files should look like the customer wrote them
 6. **One folder per component** — each component gets its own folder named after its canonical Pega name; paths are Pega's, contents are the customer's