@salesforce/afv-skills 1.56.0 → 1.58.0

package/skills/experience-lwc-legacy-migrate/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: experience-lwc-legacy-migrate
+description: "Migrate legacy Salesforce UI stacks onto modern LWC — Aura → LWC conversion completeness verification and Lightning Out Beta → Lightning Out 2.0 host-page migration. TRIGGER on \"verify Aura to LWC migration completeness\", \"migrate Lightning Out Beta to LO 2.0\", \"upgrade $Lightning.use() to <lightning-out-application>\", \"replace hardcoded LO tokens with OAuth PKCE\", \"write an LO 2.0 host page\", or an external Lightning Out page that stopped rendering; also `.cmp`/`.js-meta.xml` files alongside LWC. DO NOT TRIGGER for the initial Aura-to-LWC conversion (use experience-aura-lwc-migrate), a React-to-LWC migration, or building a new LWC (use experience-lwc-design-generate)."
+metadata:
+  version: "1.0"
+  domains: ["Experience"]
+  relatedSkills:
+    - "experience-aura-lwc-migrate"
+    - "experience-lwc-design-generate"
+  cliTools:
+    - tool: ["python3"]
+      semver: ">=3.8"
+---
+<!-- adk-managed-skill -->
+
+# Migrating Legacy LWC Stacks
+
+Two distinct migration workflows live here because users in the middle of
+migrating Aura components are often also migrating Lightning Out host pages
+— they benefit from one skill that knows both.
+
+| Migration                          | Use when                                               | Reference                                                                                              |
+|------------------------------------|--------------------------------------------------------|--------------------------------------------------------------------------------------------------------|
+| Aura → LWC completeness check      | An Aura component was converted, verify nothing is lost | [aura-to-lwc-completeness-checklist.md](references/aura-to-lwc-completeness-checklist.md)              |
+| Lightning Out Beta → LO 2.0        | Migrating an external host page off `lightning.out.js`  | [lightning-out-beta-to-2-migration.md](references/lightning-out-beta-to-2-migration.md)                |
+
+## When to Use This Skill
+
+- User has already converted an Aura component to LWC and wants a structured
+  completeness check.
+- User has a non-Salesforce host page that embeds Salesforce LWC via
+  Lightning Out Beta and needs to move to LO 2.0.
+- User is upgrading `$Lightning.use()` / `$Lightning.createComponent()` calls
+  to the `<lightning-out-application>` web component pattern.
+- User needs to replace a hardcoded LO auth token with OAuth PKCE + front-door
+  flow.
+
+If the user wants to build a brand-new LO 2.0 host page from scratch (no Beta
+code to migrate), the LO 2.0 system reference inside this skill is still the
+right source of truth — point them at it directly.
+
+## Prerequisites
+
+- Access to the source (Aura component files or Beta host page).
+- For LO 2.0 migration: ability to create an External Client App (ECA) in
+  Salesforce Setup (Consumer Key required) and optionally a Lightning Out 2.0
+  App (18-char App ID).
+- For Aura migration: access to the LWC conversion, including any `__tests__`
+  (Jest) and `__utam__` (UTAM) folders if they exist.
+
+
+## Workflow A — Aura → LWC Completeness Check
+
+Goal: rate an already-done Aura-to-LWC conversion across 12 dimensions and
+produce actionable recommendations.
+
+### Step A1 — Identify the component
+
+Ask the user for the component name (e.g. `accountTile`). Locate the Aura
+source (`{componentName}.cmp`, controller, helper, CSS) and the LWC output
+(`{componentName}.html`, `.js`, `.css`, `.js-meta.xml`).
+
+### Step A2 — Run the checklist
+
+Follow [aura-to-lwc-completeness-checklist.md](references/aura-to-lwc-completeness-checklist.md)
+verbatim:
+
+- Score the conversion on all 12 metrics (Functional Parity, Event Handling,
+  Data Binding & State, UI/UX Parity, Extensibility & Modularity, Error
+  Handling, Localization, Security & Access Control, Performance, Salesforce
+  Best Practices, Jest Test Coverage, UTAM Page Objects).
+- Use the six-rating scale: Excellent / Good / Satisfactory / Limited / Poor
+  / Missing.
+- Present the output as a list (not a table), per the reference.
+
+### Step A3 — Summarize + recommend
+
+End with an overall confidence statement and a prioritized list of specific,
+actionable recommendations (what to fix, in what order).
+
+
+## Workflow B — Lightning Out Beta → LO 2.0
+
+Goal: transform a Lightning Out Beta host page into a Lightning Out 2.0 host
+page while leaving the customer's HTML structure, styling, and business logic
+intact.
+
+### Step B1 — Read the LO 2.0 mental model
+
+Internalize the architecture *before* editing code:
+[lightning-out-2-system-reference.md](references/lightning-out-2-system-reference.md).
+
+Key takeaway: LO 2.0 is not a library upgrade. It runs the LWC inside an
+iframe with a closed shadow DOM — host-page JS cannot touch the LWC and
+vice versa, and host-page CSS does not cascade in.
+
+### Step B2 — Identify Beta patterns
+
+Use Phase 1 of the migration guide to locate:
+
+- **Pattern A** — Script tag loading `lightning.out.js` (extract the domain).
+- **Pattern B** — Config variables (endpoint, Aura app, component, token).
+- **Pattern C** — `$Lightning.use(...)` call.
+- **Pattern D** — `$Lightning.createComponent(...)` call.
+- **Pattern E** — DOM target element referenced by the 3rd arg of Pattern D.
+
+See [lightning-out-beta-to-2-migration.md § Phase 1](references/lightning-out-beta-to-2-migration.md).
+
+### Step B3 — Apply transformations
+
+The script-tag URL, the component tag name, and the attribute names are
+**deterministic** conversions — derive them with the helper script so they are
+exact every time (namespace preserved, camelCase → kebab-case, Beta host →
+versioned LO 2.0 library URL):
+
+```bash
+python3 scripts/convert-lo-names.py \
+  --component c:myComponent \
+  --attributes recordId,ownerId \
+  --my-domain https://<DOMAIN>.lightning.force.com
+```
+
+It prints the `<c-...>` tag, the kebab-case attributes, and the versioned LO
+2.0 library URL. Then work through Phase 2 of the guide:
+
+1. **Script tag** — use the `library-url` the script prints; add `async`.
+2. **Component name / attributes** — use the `component-tag` and kebab-case
+   attributes the script prints.
+3. **Component tag** — add the `<c-...>` tag directly in HTML at the target
+   location (a judgement call — place it where the Beta render target was).
+4. **Replace the `$Lightning` block** — delete it entirely and start from
+   [assets/lo20-host-page-template.html](assets/lo20-host-page-template.html),
+   filling in the config constants; it already includes the helper functions,
+   `mountLo20(frontdoorUrl, orgUrl)`, `boot()`, and the OAuth listeners.
+
+### Step B4 — Six non-negotiable rules
+
+These rules cause silent runtime failures if violated, and every one is a
+deterministic code-structure check. Enforce them with the validator script
+rather than by eye — run it against the migrated page and fix every FAIL:
+
+```bash
+python3 scripts/validate-lo20-page.py <migrated-page.html>
+```
+
+It prints a PASS/FAIL line per rule (plus the LO 2.0 library and Beta-removal
+checks) and exits non-zero if any rule fails. The six rules it enforces:
+
+1. `customElements.whenDefined(...)` must receive a **literal string**, not
+   the `components` variable.
+2. `mountLo20(frontdoorUrl, orgUrl)` must accept two parameters.
+3. Call `clearCachedResult()` before every `mountLo20(...)`.
+4. Always pass both parameters when calling `mountLo20(...)`, even if
+   `orgUrl` is undefined.
+5. Wrap all initialization in `boot()` and call `boot()` at the end.
+6. The component tag has **no inline `display:none`** — control visibility
+   via the loading indicator.
+
+### Step B5 — Salesforce setup
+
+- **External Client App (ECA)** — Setup → App Manager → New Connected App →
+  External Client App. Enable OAuth with PKCE. Copy the Consumer Key.
+- **Lightning Out 2.0 App** — apply this decision before continuing:
+
+  | Condition | Action |
+  |---|---|
+  | Host page sets `app-id="..."` | Setup → Lightning Out → New LO App; copy the 18-character App ID into the host page's `app-id` attribute |
+  | Host page embeds LWC directly (no `app-id`) | Skip the LO App entirely |
+- Helper files the migration assumes exist alongside the host page:
+  `frontdoor-url.html` (OAuth callback) and `utils/LightningOutAuth.js`
+  (PKCE implementation).
+
+### Step B6 — Run the LO 2.0 verification checklist
+
+First run `python3 scripts/validate-lo20-page.py <migrated-page.html>` to clear
+the mechanical checks, then walk the remaining manual items in the full
+post-migration checklist — cover every item before declaring the migration
+done. See the "Verification Checklist" section at the end of
+[lightning-out-beta-to-2-migration.md](references/lightning-out-beta-to-2-migration.md).
+
+
+## Verification Checklist (high level)
+
+For Aura → LWC:
+- [ ] All 12 completeness metrics rated with a justification.
+- [ ] Output in list form (not table), per the reference.
+- [ ] Overall confidence statement present.
+- [ ] Concrete, prioritized recommendations listed.
+
+For LO Beta → LO 2.0:
+- [ ] Script tag uses `.my.salesforce.com/lightning/lightning.out.latest/index.iife.prod.js` with `async`.
+- [ ] No references to `$Lightning.use` / `$Lightning.createComponent` remain.
+- [ ] Component name is kebab-case; attributes are kebab-case.
+- [ ] `mountLo20(frontdoorUrl, orgUrl)` takes two parameters.
+- [ ] `customElements.whenDefined(...)` uses a literal string.
+- [ ] All initialization wrapped in `boot()` and `boot()` is called once.
+- [ ] OAuth PKCE flow replaces hardcoded token; postMessage, BroadcastChannel,
+      and storage listeners all present and defensively coded.
+- [ ] Component tag has no inline `display:none`.
+
+
+## Troubleshooting
+
+- **LO 2.0 mount hangs** — custom element not registered. Verify the library
+  script tag URL and that the `app-id` / `frontdoor-url` values are correct.
+- **Component renders empty** — attributes probably still in camelCase. LO 2.0
+  reads HTML attributes which must be kebab-case.
+- **OAuth callback never fires** — one of postMessage / BroadcastChannel /
+  storage listeners was dropped. LO 2.0 needs all three.
+- **Aura checklist scored "Missing" on UTAM or Jest** — may be acceptable if
+  the team has an alternative test strategy; flag in recommendations rather
+  than block.

package/skills/experience-lwc-legacy-migrate/assets/lo20-host-page-template.html

@@ -0,0 +1,192 @@
+<!doctype html>
+<!--
+  Lightning Out 2.0 host-page template.
+
+  Copy this file as the starting point for a migrated host page, then fill in
+  the CONFIGURATION constants and replace `c-your-component` with the migrated
+  component tag + its kebab-case attributes. This template already satisfies the
+  six non-negotiable LO 2.0 rules; run scripts/validate-lo20-page.py against your
+  filled-in copy to confirm nothing regressed.
+
+  Placeholders to replace:
+    YOUR_ORG            -> your org My Domain host (…my.salesforce.com)
+    YOUR_ECA_CONSUMER_KEY, YOUR_18_CHAR_APP_ID (optional)
+    c-your-component    -> the migrated component tag (see scripts/convert-lo-names.py)
+    /lo20.html          -> this page's own filename (lo2_returnTo)
+-->
+<html lang="en">
+  <head>
+    <meta charset="utf-8" />
+    <title>Your Page Title</title>
+    <style>
+      .card { border: 1px solid #d8dde6; padding: 16px; border-radius: 4px; }
+      .muted { color: #706e6b; font-size: 0.8rem; }
+    </style>
+    <!-- LO 2.0 library: My Domain host, versioned path, loaded async -->
+    <script async src="https://YOUR_ORG.my.salesforce.com/lightning/lightning.out.latest/index.iife.prod.js"></script>
+  </head>
+  <body>
+    <h1>Your Page Title</h1>
+
+    <div class="card">
+      <div id="loading" role="status" aria-live="polite">
+        <div><strong>Loading…</strong></div>
+        <div class="muted">
+          If this hangs, confirm your <code>app-id</code> and <code>frontdoor-url</code> values.
+        </div>
+        <div style="margin-top: 10px">
+          <button id="connectBtn" type="button">Connect to Salesforce</button>
+          <span class="muted" style="margin-left: 8px">(opens auth in this tab)</span>
+        </div>
+      </div>
+
+      <!-- LO 2.0 mount point -->
+      <div id="loAppMount"></div>
+
+      <!-- Component tag (NO inline display style on the tag itself) -->
+      <c-your-component></c-your-component>
+    </div>
+
+    <script>
+      // ======= 1. CONFIGURATION =======
+      const ECA_CONSUMER_KEY = "YOUR_ECA_CONSUMER_KEY";
+      const LO_APP_ID = "YOUR_18_CHAR_APP_ID"; // Optional — empty string if not required
+      const ORG_MYDOMAIN_URL = "https://YOUR_ORG.my.salesforce.com";
+      const components = "c-your-component";
+
+      // ======= 2. DOM REFERENCES =======
+      const loadingEl = document.getElementById('loading');
+      const connectBtn = document.getElementById('connectBtn');
+      const loAppMount = document.getElementById('loAppMount');
+
+      // ======= 3. HELPER FUNCTIONS =======
+      function setLoading(text) {
+        const strong = loadingEl?.querySelector?.('div strong');
+        if (strong) strong.textContent = text;
+      }
+
+      function showError(msg) {
+        console.error('LO 2.0 Error:', msg);
+        if (loadingEl) {
+          loadingEl.innerHTML = "<strong>Failed to start LO 2.0.</strong><div class='muted'>" + msg + '</div>';
+        }
+      }
+
+      function readCachedResult() {
+        try {
+          const raw = localStorage.getItem('lo2_frontdoor_result');
+          if (!raw) return null;
+          return JSON.parse(raw);
+        } catch {
+          return null;
+        }
+      }
+
+      function clearCachedResult() {
+        try {
+          localStorage.removeItem('lo2_frontdoor_result');
+        } catch {
+          // ignore
+        }
+      }
+
+      // ======= 4. MOUNT FUNCTION (two parameters) =======
+      function mountLo20(frontdoorUrl, orgUrl) {
+        setLoading('Initializing Lightning Out 2.0…');
+
+        // Prevent duplicate mounts
+        if (loAppMount && loAppMount.querySelector('lightning-out-application')) return;
+
+        function tryMount() {
+          if (!customElements?.get?.('lightning-out-application')) return false;
+
+          const el = document.createElement('lightning-out-application');
+          el.setAttribute('components', components);
+          if (LO_APP_ID) el.setAttribute('app-id', LO_APP_ID);
+          el.setAttribute('frontdoor-url', frontdoorUrl);
+
+          (loAppMount || document.body).appendChild(el);
+          return true;
+        }
+
+        const start = Date.now();
+        (function tick() {
+          if (tryMount()) return;
+          if (Date.now() - start > 15000) {
+            showError('Failed to initialize Lightning Out 2.0 (custom element not registered).');
+            return;
+          }
+          setTimeout(tick, 50);
+        })();
+
+        // Rule 1: literal string, NOT the `components` variable
+        customElements.whenDefined('c-your-component').then(() => {
+          if (loadingEl) loadingEl.style.display = 'none';
+        });
+      }
+
+      // ======= 5. BOOT FUNCTION (ALL INIT LOGIC) =======
+      function boot() {
+        try {
+          setLoading('Ready to authenticate.');
+
+          // Store config for the callback page
+          localStorage.setItem('orgMyDomainURL', ORG_MYDOMAIN_URL);
+          localStorage.setItem('loAppID', LO_APP_ID);
+          localStorage.setItem('loECAKey', ECA_CONSUMER_KEY);
+          localStorage.setItem('lo2_returnTo', '/lo20.html'); // this page's filename
+
+          // Listen for callback results by multiple mechanisms
+          window.addEventListener('message', (evt) => {
+            const data = evt?.data;
+            if (!data) return;
+            if (data.error) return showError(`Auth error: ${data.error}`);
+            if (!data.frontdoorUrl) return;
+            clearCachedResult();
+            mountLo20(data.frontdoorUrl, data.orgUrl);
+          });
+
+          try {
+            const bc = new BroadcastChannel('lo2auth');
+            bc.onmessage = (evt) => {
+              const data = evt?.data;
+              if (!data) return;
+              if (data.error) return showError(`Auth error: ${data.error}`);
+              if (!data.frontdoorUrl) return;
+              clearCachedResult();
+              mountLo20(data.frontdoorUrl, data.orgUrl);
+            };
+          } catch (e) {
+            // BroadcastChannel not supported, ignore
+          }
+
+          window.addEventListener('storage', (evt) => {
+            if (evt.key !== 'lo2_frontdoor_result') return;
+            const data = readCachedResult();
+            if (!data) return;
+            if (data.error) return showError(`Auth error: ${data.error}`);
+            if (!data.frontdoorUrl) return;
+            mountLo20(data.frontdoorUrl, data.orgUrl);
+          });
+
+          // If the user already completed auth in another tab, pick up the cached result
+          const cached = readCachedResult();
+          if (cached?.frontdoorUrl) {
+            mountLo20(cached.frontdoorUrl, cached.orgUrl);
+          }
+
+          connectBtn?.addEventListener('click', () => {
+            clearCachedResult();
+            setLoading('Redirecting to OAuth…');
+            window.location.assign('/frontdoor-url.html');
+          });
+        } catch (e) {
+          showError((e && (e.stack || e.message)) || String(e));
+        }
+      }
+
+      // ======= 6. CALL BOOT =======
+      boot();
+    </script>
+  </body>
+</html>

package/skills/experience-lwc-legacy-migrate/references/aura-to-lwc-completeness-checklist.md

@@ -0,0 +1,188 @@
+# Aura to LWC Conversion Completeness Checklist
+
+You are a Salesforce principal architect. Your task is to help a developer verify whether their conversion of a Salesforce Aura component to a Lightning Web Component (LWC) is truly complete. This is a developer-focused self-checklist, not a platform evaluation or LLM-as-judge scenario. The goal is to provide confidence and clarity for the developer, not to benchmark platform performance.
+
+## Instructions
+
+1. **Review the Completeness Metrics:**
+   For each of the following metrics, use the provided rating to assess the LWC conversion. For each metric, select one of the following qualitative ratings:
+
+   - **Excellent**: Perfect or near-perfect match in understanding and detail
+   - **Good**: Strong understanding with minor differences
+   - **Satisfactory**: Adequate understanding with some notable differences
+   - **Limited**: Basic understanding with significant gaps
+   - **Poor**: Major misunderstandings or omissions
+   - **Missing**: Issue completely overlooked or fatally misunderstood
+
+2. **For Each Metric:**
+
+   - State the metric and its description
+   - Assign a rating (from the list above)
+   - Provide a brief justification for the rating
+   - Optionally, add one or two sentences explaining any gaps, strengths, or issues
+
+3. **Checklist Output:**
+
+   - Present your results as a list, not a table
+   - For each metric, include:
+     - Metric name
+     - Description
+     - Rating
+     - Justification/comments
+
+4. **Summary and Recommendations:**
+
+   - At the end, summarize your overall confidence in the conversion's completeness
+   - List specific, actionable recommendations to address any gaps or issues
+
+5. **Context:**
+
+   - The component name is: `{{componentName}}`
+   - The Aura component file is: `{{componentName}}.cmp`
+   - The LWC template file is: `{{componentName}}.html`
+   - You have access to supporting files such as controllers, helpers, CSS, blueprints, Jest tests (in `__tests__`), and UTAM page objects (in `__utam__`).
+
+6. **Important Notes:**
+   - This checklist is a comprehensive aid for developers to verify their work, not a judge of platform performance.
+   - The resulting ratings are confidence measures for the developer, not benchmarks.
+   - Each metric could, in the future, have a more detailed, dedicated tool for finer-grained verification, but avoid duplicating existing tools unless a true gap is identified.
+   - If you find that guidance is unclear or tools are not being applied consistently, note this as a potential process/tooling gap.
+
+## Completeness Metrics and Scoring
+
+- **Functional Parity**: Are all user-facing features, states, and flows from the Aura component present in the LWC?
+
+  - _Excellent_: All features and flows are present and work as intended.
+  - _Good_: Minor features or flows are missing or slightly altered.
+  - _Satisfactory_: Most features are present, but some notable differences exist.
+  - _Limited_: Several important features are missing or incomplete.
+  - _Poor_: Major features are missing or broken.
+  - _Missing_: No attempt at parity.
+
+- **Event Handling**: Are all events (custom, platform, UI) handled equivalently in the LWC?
+
+  - _Excellent_: All events are handled as in Aura.
+  - _Good_: Minor event handling differences.
+  - _Satisfactory_: Most events handled, some notable gaps.
+  - _Limited_: Several events missing or mishandled.
+  - _Poor_: Major event handling missing.
+  - _Missing_: No event handling present.
+
+- **Data Binding & State**: Are all data flows, attributes, and state transitions preserved and correctly mapped?
+
+  - _Excellent_: All data/state flows are preserved and correct.
+  - _Good_: Minor data/state differences.
+  - _Satisfactory_: Most data/state flows present, some gaps.
+  - _Limited_: Several data/state flows missing.
+  - _Poor_: Major data/state issues.
+  - _Missing_: No data/state mapping.
+
+- **UI/UX Parity**: Is the user interface (including accessibility, responsiveness, and SLDS usage) equivalent?
+
+  - _Excellent_: UI/UX matches or improves on Aura.
+  - _Good_: Minor UI/UX differences.
+  - _Satisfactory_: Most UI/UX present, some gaps.
+  - _Limited_: Several UI/UX issues.
+  - _Poor_: Major UI/UX issues.
+  - _Missing_: No UI/UX parity.
+
+- **Extensibility & Modularity**: Is the LWC designed for maintainability and future extension?
+
+  - _Excellent_: Highly modular and extensible.
+  - _Good_: Minor modularity/extensibility issues.
+  - _Satisfactory_: Adequate, but some concerns.
+  - _Limited_: Several modularity/extensibility issues.
+  - _Poor_: Major issues.
+  - _Missing_: Not modular/extensible.
+
+- **Error Handling**: Are all error states and recovery actions present and clear in the LWC?
+
+  - _Excellent_: All error handling present and clear.
+  - _Good_: Minor error handling gaps.
+  - _Satisfactory_: Most error handling present, some gaps.
+  - _Limited_: Several error handling issues.
+  - _Poor_: Major error handling missing.
+  - _Missing_: No error handling.
+
+- **Localization**: Are all labels/messages localized as in Aura?
+
+  - _Excellent_: All localization present.
+  - _Good_: Minor localization gaps.
+  - _Satisfactory_: Most localization present, some gaps.
+  - _Limited_: Several localization issues.
+  - _Poor_: Major localization missing.
+  - _Missing_: No localization.
+
+- **Security & Access Control**: Are there any regressions in data access or exposure?
+
+  - _Excellent_: No regressions, all controls present.
+  - _Good_: Minor security/access gaps.
+  - _Satisfactory_: Most controls present, some gaps.
+  - _Limited_: Several security/access issues.
+  - _Poor_: Major security/access issues.
+  - _Missing_: No security/access controls.
+
+- **Performance**: Is the LWC at least as performant, or improved, compared to Aura?
+
+  - _Excellent_: Performance matches or improves on Aura.
+  - _Good_: Minor performance differences.
+  - _Satisfactory_: Most performance present, some gaps.
+  - _Limited_: Several performance issues.
+  - _Poor_: Major performance issues.
+  - _Missing_: No performance consideration.
+
+- **Salesforce Best Practices**: Does the LWC follow modern Salesforce LWC and SLDS guidelines?
+
+  - _Excellent_: All best practices followed.
+  - _Good_: Minor best practice gaps.
+  - _Satisfactory_: Most best practices followed, some gaps.
+  - _Limited_: Several best practice issues.
+  - _Poor_: Major best practice issues.
+  - _Missing_: No best practices followed.
+
+- **Jest Test Coverage**: Are Jest unit tests present (usually in a `__tests__` folder) and do they cover key logic?
+
+  - _Excellent_: Comprehensive test coverage.
+  - _Good_: Minor test coverage gaps.
+  - _Satisfactory_: Most key logic covered, some gaps.
+  - _Limited_: Several test coverage issues.
+  - _Poor_: Major test coverage missing.
+  - _Missing_: No tests present.
+
+- **UTAM Page Objects**: Are UTAM page objects generated (usually in a `__utam__` folder) for UI automation?
+  - _Excellent_: Comprehensive UTAM coverage.
+  - _Good_: Minor UTAM coverage gaps.
+  - _Satisfactory_: Most key UI flows covered, some gaps.
+  - _Limited_: Several UTAM coverage issues.
+  - _Poor_: Major UTAM coverage missing.
+  - _Missing_: No UTAM page objects present.
+
+---
+
+## Example Output Structure
+
+```markdown
+# Aura to LWC Conversion Completeness Checklist
+
+- **Functional Parity**
+  - Description: Are all user-facing features, states, and flows from the Aura component present in the LWC?
+  - Rating: Good
+  - Justification: All major features are present, but one minor flow is missing.
+  - Comments: The save flow is slightly different, but overall parity is strong.
+
+- **Event Handling**
+  - Description: Are all events (custom, platform, UI) handled equivalently in the LWC?
+  - Rating: Excellent
+  - Justification: All events are handled as in Aura.
+
+... (repeat for each metric)
+
+# Summary
+
+Overall, the conversion is strong, with only minor gaps in functional parity and localization. Confidence in completeness is high.
+
+# Recommendations
+
+- Address the missing flow in functional parity.
+- Improve localization for error messages.
+```