@salesforce/afv-skills 1.22.0 → 1.23.0

package/skills/uplifting-components-to-slds2/references/rule-no-hardcoded-values.md

@@ -1,160 +0,0 @@
-# Rule: No Hardcoded Values
-
-**Rule ID:** `slds/no-hardcoded-values-slds2`
-**Severity:** Warning
-**Scope:** All CSS properties with hardcoded values that have SLDS 2 hook equivalents — colors, spacing, sizing, typography, borders, radius, and shadows.
-
----
-
-## What the Linter Does
-
-The linter detects hardcoded values and reports them as warnings. Here's real output for an icon component:
-
-```
-  3:10  warning  Consider replacing the 32px static value with an SLDS 2 styling hook
-                 that has a similar value: --slds-g-sizing-9.                              slds/no-hardcoded-values-slds2
-
-  5:21  warning  Dynamic element with css-class "icon-container" using static value
-                 "#066afe" for "background-color" css property. Consider replacing
-                 the #066AFE static value with an SLDS 2 styling hook:
-                 1. --slds-g-color-surface-inverse-1
-                 2. --slds-g-color-surface-inverse-2
-                 3. --slds-g-color-surface-container-inverse-1                             slds/no-hardcoded-values-slds2
-
-  9:9   warning  Dynamic element with css-class "account-icon" using static value
-                 "#ffffff" for "fill" css property. Consider replacing:
-                 1. --slds-g-color-on-accent-1
-                 2. --slds-g-color-on-accent-2
-                 3. --slds-g-color-error-base-95
-                 4. --slds-g-color-warning-base-95                                         slds/no-hardcoded-values-slds2
-```
-
-**Non-color values** get single suggestions — auto-fixable with `--fix`:
-
-```css
-/* 32px → sizing-9 (single suggestion, auto-fixed) */
-width: var(--slds-g-sizing-9, 32px);
-```
-
-**Color values** get multiple suggestions — requires manual selection. The linter suggests hooks based on color-value similarity, **not semantic context**. You must inspect the HTML to choose correctly.
-
----
-
-## What to Fix vs What to Skip
-
-| Property Type | Example Values | Action |
-|---|---|---|
-| Color properties (`color`, `fill`, `background`, `background-color`, `stroke`, `border-*-color`, `outline-color`) | `#fff`, `rgb(0,0,0)` | **Fix** — replace with color hook + fallback |
-| Spacing properties (`margin`, `padding`, `gap`) | `16px`, `1rem`, `24px` | **Fix** — replace with spacing hook + fallback |
-| Sizing properties (`width`, `height`, `min-*`, `max-*`) | `32px`, `2rem` | **Fix** — replace with sizing hook + fallback |
-| Font properties (`font-size`, `font-weight`, `line-height`) | `14px`, `bold`, `1.5` | **Fix** — replace with typography hook + fallback |
-| Border properties (`border-radius`, `border-width`) | `8px`, `1px` | **Fix** — replace with radius/border hook + fallback |
-| Shadow properties (`box-shadow`) | `0 4px 8px rgba(…)` | **Fix** — replace with shadow hook + fallback |
-| Layout/structural values | `100%`, `auto`, `0`, `inherit`, `none` | **Skip** — leave unchanged, removing breaks rendering |
-
-When the linter says "Remove the static value" for a layout value like `width: 100%` or `height: auto`, **do not remove it**.
-
----
-
-## Replacement Pattern
-
-Always include the original value as fallback:
-
-```css
-property: var(--slds-g-[hook], originalValue);
-```
-
-The fallback must be the **exact original value** from the source CSS (e.g., `#066AFE`, not a converted equivalent).
-
----
-
-## Decision Tree
-
-When examining a hardcoded value or deprecated token, follow this decision tree:
-
-```
-1. SLDS utility class available?
-   └─ Yes → Remove CSS, add utility class to HTML
-   └─ No  ↓
-
-2. At least one 1:1 styling hook mapping?
-   ├─ Exactly one  → Use it with fallback
-   ├─ Multiple     → Inspect HTML context to choose (see decision guides)
-   └─ None         ↓
-
-3. No exact match
-   └─ No close match → Leave hardcoded
-```
-
-### Step 1: Check for Utility Classes
-
-If an SLDS utility class sets the exact property to the exact value, remove the CSS and replace with the class on the HTML element(s).
-
-**Best fit vs perfect fit:** Use existing utilities that get you close enough, even if it means combining two or three classes. This keeps markup readable, styles consistent, and avoids unnecessary custom CSS. Don't write new CSS rules for edge cases unless absolutely necessary.
-
-**When modifying CSS classes:**
-- Before removing a CSS declaration, ensure you understand how it's used in HTML and in JS (computed classes)
-- Update any tests after changing CSS classes — some tests use class query selectors that should be replaced with `data-tid` attributes
-
-#### Example: Replacing with Utility Classes
-
-Common CSS like `display: flex` with alignment can often be replaced entirely:
-
-```css
-/* Before — component.css */
-.container {
-    display: flex;
-    flex-direction: row;
-    justify-content: center;
-    align-items: center;
-}
-```
-
-```html
-<!-- Before — component.html -->
-<div class="container">
-```
-
-These styles map to SLDS grid utility classes:
-
-```html
-<!-- After — component.html (CSS removed entirely) -->
-<div class="slds-grid slds-grid_align-center slds-grid_vertical-align-center">
-```
-
-Note: `flex-direction: row` is the default for `display: flex` — it can be removed entirely.
-
-### Steps 2 & 3: Choose the Right Hook
-
-For choosing between multiple hooks or finding the closest match, see the decision guides:
-
-| Category | Decision Guide |
-|---|---|
-| Color (background, foreground, border color) | [color-hooks-decision-guide.md](color-hooks-decision-guide.md) — surface vs container, semantic vs palette, applied examples from real PRs |
-| Spacing, sizing, typography, borders, radius, shadows | [non-color-hooks-decision-guide.md](non-color-hooks-decision-guide.md) — numbered scales, closest-match rules, density-aware variants |
-
----
-
-## Common Mistakes
-
-1. **Inventing hook names** — Only use hooks documented in the SLDS design system.
-2. **Missing fallback** — Always include the original value: `var(--slds-g-hook, originalValue)`
-3. **Confusing spacing and sizing** — Spacing is for margins/padding/gaps. Sizing is for width/height/dimensions.
-4. **Using named hooks** — `--slds-g-spacing-medium`, `--slds-g-font-weight-bold`, `--slds-g-radius-large` do NOT exist. Only numbered hooks exist.
-5. **Replacing layout values** — Don't replace `100%`, `auto`, `flex: 1`, `none`, or `0` with hooks.
-6. **Blindly trusting linter suggestions for colors** — The linter matches by color value, not semantic context. Always inspect HTML before choosing.
-
-## What NOT to Replace
-
-Leave these unchanged (no SLDS hooks apply):
-
-```css
-width: 100%;                   /* layout values */
-height: auto;                  /* layout values */
-flex: 1;                       /* layout values */
-display: none;                 /* layout values */
-transition: color 0.3s ease;   /* animation values */
-opacity: 0.5;                  /* opacity */
-background: linear-gradient(…); /* gradients */
-left: 50%;                     /* positioning offsets */
-```

package/skills/uplifting-components-to-slds2/references/rule-no-slds-class-overrides.md

@@ -1,126 +0,0 @@
-# Rule: No SLDS Class Overrides
-
-**Rule ID:** `slds/no-slds-class-overrides`
-**Severity:** Warning
-**Scope:** Detects CSS selectors that directly target `.slds-*` classes.
-
----
-
-## What the Linter Does
-
-The linter detects CSS classes that directly override SLDS classes and reports them as **warnings**. It does **not** auto-fix — all changes require manual work in both CSS and HTML.
-
-```
-  1:1  warning  Overriding slds-button isn't supported. To differentiate SLDS and
-               custom classes, create a CSS class in your namespace.
-               Examples: myapp-input, myapp-button.                  slds/no-slds-class-overrides
-```
-
-**Manual steps required:**
-1. Rename `.slds-*` selectors in CSS to `{componentName}-{sldsElementPart}`
-2. Add the new component class to markup (`.html` for LWC, `.cmp` for Aura) **alongside** the original SLDS class
-3. Never remove the original SLDS class from markup
-
----
-
-## Naming Convention
-
-**Format:** `{componentName}-{sldsElementPart}` (camelCase component name)
-
-| SLDS Class | Component: `userProfile` | Result |
-|---|---|---|
-| `.slds-button` | `userProfile` | `userProfile-button` |
-| `.slds-card` | `userProfile` | `userProfile-card` |
-| `.slds-modal__content` | `userProfile` | `userProfile-modal__content` |
-| `.slds-button_brand` | `userProfile` | `userProfile-button_brand` |
-
----
-
-## Common Patterns
-
-### Pattern 1: Simple Selector
-
-```css
-/* Before CSS */
-.slds-button { border-radius: 8px; }
-
-/* After CSS */
-.myComponent-button { border-radius: 8px; }
-```
-
-```html
-<!-- After HTML (manual) -->
-<button class="slds-button myComponent-button">Click</button>
-```
-
-### Pattern 2: Descendant Selector
-
-```css
-/* Before CSS */
-.slds-card .slds-button { margin-top: 1rem; }
-
-/* After CSS */
-.myComponent-card .myComponent-button { margin-top: 1rem; }
-```
-
-```html
-<!-- After HTML (manual) — each SLDS class gets a component class -->
-<div class="slds-card myComponent-card">
-  <button class="slds-button myComponent-button">Click</button>
-</div>
-```
-
-### Pattern 3: Multi-Class Selector
-
-```css
-/* Before CSS */
-.slds-card.slds-p-around_medium { border: 1px solid blue; }
-
-/* After CSS */
-.myComponent-card.myComponent-p-around_medium { border: 1px solid blue; }
-```
-
-```html
-<!-- After HTML (manual) -->
-<div class="slds-card slds-p-around_medium myComponent-card myComponent-p-around_medium">
-```
-
----
-
-## Core Rules
-
-1. **Never remove SLDS classes** from markup (`.html` or `.cmp`) — only ADD component classes alongside them
-2. **One-to-one mapping** — each SLDS class in a CSS selector gets exactly one component class
-3. **CamelCase component name** — `sampleComponent-button`, not `sample-component-button`
-4. **Preserve SLDS element names** — `.slds-button` becomes `componentName-button` (strip `slds-` prefix, keep the rest)
-
----
-
-## Interaction with Other Rules
-
-If the overridden CSS properties include hardcoded colors, you must also apply `rule-no-hardcoded-values.md` to those properties:
-
-```css
-/* Before */
-.slds-icon-action-check { background: #4bca81; }
-
-/* After — both rules applied */
-.myComponent-icon-action-check { background: var(--slds-g-color-success-base-70, #4bca81); }
-```
-
----
-
----
-
-## Validation Checklist
-
-**CSS:**
-- [ ] All `.slds-*` overrides reported by the linter are addressed
-- [ ] Component name is camelCase
-- [ ] SLDS element names preserved after prefix
-
-**Markup (`.html` for LWC, `.cmp` for Aura):**
-- [ ] Original SLDS classes preserved
-- [ ] Component classes added alongside SLDS classes
-- [ ] Every element in CSS selector chain updated in markup
-- [ ] One component class per SLDS class

package/skills/using-mobile-native-capabilities/SKILL.md

@@ -1,181 +0,0 @@
----
-name: using-mobile-native-capabilities
-description: "Build a Salesforce LWC that uses native mobile device capabilities — barcode scanner, biometrics, location, NFC, calendar, contacts, document scanner, geofencing, AR space capture, app review, and payments. Use this skill when the user asks for an LWC that scans a barcode, captures a photo of a document, reads location or geofences, prompts for biometrics, reads/writes the device calendar or contacts, taps NFC, takes a payment, prompts for an app review, or scans an AR space. Also triggers on \"lightning/mobileCapabilities\", \"mobile capability\", \"Nimbus\", \"device capability\". Do not use for mobile offline / Komaci priming reviews (use `reviewing-lwc-mobile-offline`) or for picking generic Lightning base components (use a generic Lightning base components skill)."
-metadata:
-  version: "1.0"
----
-
-# Using Mobile Native Capabilities
-
-The `lightning/mobileCapabilities` module exposes a set of factory functions
-that return service objects for native device features (barcode scanning,
-biometrics, location, etc.). Each service extends a common
-[BaseCapability](references/base-capability.md) with an `isAvailable()`
-method, so an LWC can degrade gracefully on surfaces where the capability is
-not present (desktop, mobile web).
-
-This skill routes an agent through (1) picking the right capability, (2)
-loading the authoritative type definitions, and (3) wiring the service into
-an LWC with the correct availability gating, error handling, and
-deprecation-aware API choice.
-
-## When to Use This Skill
-
-- User asks for an LWC that uses a device capability listed in the index
-  below.
-- User mentions `lightning/mobileCapabilities`, "mobile capability", or
-  "Nimbus" by name.
-- User wants to know which mobile native APIs are available, or which one
-  fits their feature.
-
-Do NOT use this skill for:
-
-- Mobile-offline review of an LWC (lwc:if, inline GraphQL, Komaci-priming
-  violations) — use `reviewing-lwc-mobile-offline`.
-- Picking generic Lightning Base Components — use
-  `using-lightning-base-components`.
-
-## Prerequisites
-
-- Knowledge that the LWC will run inside a supported mobile container
-  (Salesforce Mobile App, Field Service Mobile App). These capabilities are
-  unavailable on desktop and mobile web; gate every call behind
-  `isAvailable()`.
-- Familiarity with the `lightning/mobileCapabilities` module declaration
-  (see [mobile-capabilities](references/mobile-capabilities.md)).
-
-## Capability Index
-
-| Capability | Reference | One-line use |
-| --- | --- | --- |
-| App Review | [App Review](references/app-review.md) | Prompt the user for a native in-app review. |
-| AR Space Capture | [AR Space Capture](references/ar-space-capture.md) | Capture a 3D scan of a physical space using AR. |
-| Barcode Scanner | [Barcode Scanner](references/barcode-scanner.md) | Read QR / UPC / EAN / Code-128 / etc. from the camera. |
-| Biometrics | [Biometrics](references/biometrics.md) | Authenticate via Face ID / fingerprint. |
-| Calendar | [Calendar](references/calendar.md) | Read or create events on the device calendar. |
-| Contacts | [Contacts](references/contacts.md) | Read or create entries in the device address book. |
-| Document Scanner | [Document Scanner](references/document-scanner.md) | Scan paper documents using the camera with edge detection. |
-| Geofencing | [Geofencing](references/geofencing.md) | Trigger logic when the device crosses a geographic boundary. |
-| Location | [Location](references/location.md) | Read GPS coordinates and watch for updates. |
-| NFC | [NFC](references/nfc.md) | Read or write NFC tags. |
-| Payments | [Payments](references/payments.md) | Take an Apple Pay / Google Pay payment. |
-
-## Workflow
-
-### Step 1 — Identify the capability
-
-Map the user's feature ask to one row of the capability index. If the ask
-spans multiple capabilities (e.g. "scan a barcode and store it on a
-contact"), plan for **each** capability separately — there is one factory
-function per capability.
-
-### Step 2 — Load the shared and capability-specific references
-
-Read these two shared references **once** per session — they apply to every
-capability and are not duplicated in the per-capability files:
-
-- [BaseCapability](references/base-capability.md) — the common interface
-  with `isAvailable()` that every service extends.
-- [mobile-capabilities](references/mobile-capabilities.md) — the
-  `lightning/mobileCapabilities` module declaration showing every
-  re-exported service.
-
-Then open the capability's reference file from the table above. Each
-per-capability reference contains the service-specific TypeScript API
-(factory function, service interface, options types, result types, error
-types) and assumes the two shared references above are already in context.
-
-Do not infer the API from memory — read it. The services evolve and some
-methods are explicitly `@deprecated` in favor of newer alternatives.
-
-### Step 3 — Wire the service into the LWC
-
-For each capability:
-
-1. Import the factory from `lightning/mobileCapabilities`:
-   ```js
-   import { getBarcodeScanner } from 'lightning/mobileCapabilities';
-   ```
-2. Get an instance: `const scanner = getBarcodeScanner();`
-3. Gate the call behind `isAvailable()`:
-   ```js
-   if (!scanner.isAvailable()) {
-     // graceful fallback or user message
-     return;
-   }
-   ```
-4. Call the **non-deprecated** entry point. Several services keep older
-   methods marked `@deprecated` alongside the recommended one — always
-   prefer the recommended method in the reference.
-5. Wrap the promise in `try/catch` and handle the typed failure codes the
-   service exposes (e.g. `BarcodeScannerFailureCode`,
-   `LocationServiceFailureCode`). User-cancelled vs. permission-denied vs.
-   service-unavailable are distinct UX states.
-
-### Step 4 — Surface failure modes to the user
-
-Each service defines its own failure-code enum. Translate codes into
-user-actionable messages: a `USER_DENIED_PERMISSION` should ask the user to
-grant permission; a `USER_DISABLED_PERMISSION` must direct them to the OS
-settings; a `SERVICE_NOT_ENABLED` should be a developer-visible error, not
-shown to the user.
-
-### Step 5 — Stay inside the supported surface
-
-Mobile capabilities are available **only** when the LWC runs inside a
-supported Salesforce mobile app. If the same component is rendered on
-desktop or mobile web, the factory will still return an object but
-`isAvailable()` will return `false`. Never assume availability — gate every
-call.
-
-
-## Examples
-
-### Example — "Scan a barcode and write it into a field"
-
-1. Map to: Barcode Scanner.
-2. Read [Barcode Scanner](references/barcode-scanner.md).
-3. Use `scan(options)` (not the deprecated `beginCapture` / `resumeCapture`
-   / `endCapture` triple).
-4. In options, set the `barcodeTypes` to the symbologies needed (default is
-   all supported types) and `enableMultiScan: false` for a single read.
-5. On resolve, write `result[0].value` to the bound field. On reject,
-   inspect `error.code` against `BarcodeScannerFailureCode`.
-
-### Example — "Take an Apple Pay payment for an order total"
-
-1. Map to: Payments.
-2. Read [Payments](references/payments.md).
-3. Gate on `isAvailable()`.
-4. Build the payment request object per the reference.
-5. On resolve, surface the transaction id to the calling flow. On reject,
-   handle user-cancelled and payment-failed paths separately.
-
-
-## Verification Checklist
-
-- [ ] Every capability call is preceded by `isAvailable()`.
-- [ ] The non-deprecated entry point is used (no `beginCapture` /
-      `resumeCapture` / `endCapture` for barcode, etc.).
-- [ ] Each rejection path is mapped to the typed failure code enum.
-- [ ] Imports come from `lightning/mobileCapabilities`, not from a private
-      path.
-- [ ] No assumption that the capability runs on desktop or mobile web.
-
-
-## Troubleshooting
-
-- **`isAvailable()` returns `false` on a real device** — the device is
-  running an unsupported app surface (not Salesforce Mobile or Field
-  Service Mobile), or the service is gated by an org-level setting. The
-  fix is org configuration, not code.
-- **TypeScript can't find the import** — confirm the LWC has access to
-  `lightning/mobileCapabilities`. The module is declared globally inside
-  Salesforce mobile containers; outside that, the types must be installed
-  separately.
-- **Deprecated barcode methods still work** — yes, but new code must use
-  `scan()` and `dismiss()`. Refactor any sample code the agent received
-  before returning it.
-- **Multiple capabilities in one component** — get separate instances per
-  capability (they are independent service objects); do not try to share
-  state between them.

package/skills/using-mobile-native-capabilities/references/app-review.md

@@ -1,68 +0,0 @@
-# App Review Service Grounding Context
-
-The following content provides grounding information for generating a Salesforce LWC that leverages app review facilities on mobile devices. Specifically, this context will cover the API types and methods available to leverage the app review API of the mobile device, within the LWC.
-
-## App Review Service API
-
-```typescript
-/*
- * Copyright (c) 2024, Salesforce, Inc.
- * All rights reserved.
- * For full license text, see the LICENSE.txt file
- */
-
-import { BaseCapability } from '../BaseCapability.js';
-
-/**
- * Use this factory function to get an instance of {@linkcode AppReviewService}.
- * @returns An instance of {@linkcode AppReviewService}.
- */
-export function getAppReviewService(): AppReviewService;
-
-/**
- * Request an app review from a Lightning web component.
- * @see {@link https://developer.salesforce.com/docs/platform/lwc/guide/reference-lightning-appreviewservice.html|AppReviewService API}
- */
-export interface AppReviewService extends BaseCapability {
-  /**
-   * Requests an app review.
-   * @param options An {@linkcode AppReviewServiceOptions} object to configure the {@linkcode AppReviewService} request.
-   * @returns A resolved promise returns null.
-   */
-  requestAppReview(options?: AppReviewServiceOptions): Promise<null>;
-}
-
-/**
- * An object representing configuration details for an {@linkcode AppReviewService} session.
- */
-export interface AppReviewServiceOptions {
-  /**
-   * Ignore the app review request if already asked for the current version of the app.
-   */
-  ignoreIfAlreadyRequestedForCurrentAppVersion: boolean;
-}
-
-/**
- * An object representing an error that occurred when accessing {@linkcode AppReviewService} features.
- */
-export interface AppReviewServiceFailure {
-  /**
-   * A value representing the reason for an app review error.
-   */
-  code: AppReviewServiceFailureCode;
-
-  /**
-   * A string value describing the reason for the failure. This value is suitable for use in user interface messages. The message is provided in English and isn’t localized.
-   */
-  message: string;
-}
-
-/**
- * Possible failure codes.
- */
-type AppReviewServiceFailureCode =
-  | 'ALREADY_REQUESTED_FOR_CURRENT_APP_VERSION'
-  | 'IN_APP_REVIEW_ERROR'
-  | 'SERVICE_NOT_ENABLED'
-  | 'UNKNOWN_REASON';
-```

package/skills/using-mobile-native-capabilities/references/ar-space-capture.md

@@ -1,125 +0,0 @@
-# AR Space Capture Service Grounding Context
-
-The following content provides grounding information for generating a Salesforce LWC that leverages AR Space Capture facilities on mobile devices. Specifically, this context will cover the API types and methods available to leverage the AR Space Capture API of the mobile device, within the LWC.
-
-## AR Space Capture Service API
-
-```typescript
-/*
- * Copyright (c) 2024, Salesforce, Inc.
- * All rights reserved.
- * For full license text, see the LICENSE.txt file
- */
-
-import { BaseCapability } from '../BaseCapability.js';
-
-/**
- * Use this factory function to get an instance of {@linkcode ARSpaceCapture}.
- * @returns An instance of {@linkcode ARSpaceCapture}.
- */
-export function getARSpaceCapture(): ARSpaceCapture;
-
-/**
- * Scan a room using Apple's RoomPlan AR Capabilities.
- */
-export interface ARSpaceCapture extends BaseCapability {
-  /**
-   * Scan Room using Apple's AR Capabilities.
-   * @param options The customization options for the {@linkcode ARSpaceCapture} Plugin.
-   * @returns A resolved promise returns {@linkcode ARSpaceCaptureResult} object.
-   */
-  scanRoom(options?: ARSpaceCaptureOptions): Promise<ARSpaceCaptureResult>;
-}
-
-/**
- * ARSpaceCaptureResult interface.
- */
-export interface ARSpaceCaptureResult {
-  capturedRooms: CapturedRoom[] | null;
-}
-
-/**
- * CapturedRoom interface.
- */
-export interface CapturedRoom {
-  /**
-   * An array of walls that the framework identifies during a scan.
-   */
-  walls: unknown[];
-
-  /**
-   * An array of doors that the framework identifies during a scan.
-   */
-  doors: unknown[];
-
-  /**
-   * An array of windows that the framework identifies during a scan.
-   */
-  windows: unknown[];
-
-  /**
-   * An array of openings that the framework identifies during a scan.
-   */
-  openings: unknown[];
-
-  /**
-   * An array of floors that the framework identifies during a scan.
-   * Available iOS 17.0+.
-   */
-  floors: unknown[];
-
-  /**
-   * An array of objects that the framework identifies during a scan.
-   */
-  objects: unknown[];
-
-  /**
-   * A unique alphanumeric value that the framework assigns the room.
-   */
-  identifier: string;
-
-  /**
-   * One or more room types that the framework observes in the room.
-   * Available iOS 17.0+.
-   */
-  sections: unknown[];
-
-  /**
-   * The story, floor number, or level on which the captured room resides within a larger structure.
-   * Available iOS 17.0+.
-   */
-  story: number;
-
-  /**
-   * A version number for the captured room.
-   * Available iOS 17.0+.
-   */
-  version: number;
-}
-
-/**
- * ARSpaceCaptureOptions interface.
- */
-export interface ARSpaceCaptureOptions {
-  permissionRationaleText?: string;
-  presentWithAnimation: boolean;
-}
-
-/**
- * ARSpaceCaptureFailure interface.
- */
-export interface ARSpaceCaptureFailure {
-  code: ARSpaceCaptureFailureCode;
-  message: string;
-}
-
-/**
- * Possible failure codes.
- */
-type ARSpaceCaptureFailureCode =
-  | 'USER_DISMISSED' // User cancelled the operation.
-  | 'USER_DENIED_PERMISSION' // The user denied permissions to use the device camera.
-  | 'AR_NOT_SUPPORTED' // The AR capabilities are not enabled/available on the device.
-  | 'SERVICE_NOT_ENABLED' // The service is not enabled and therefore cannot be used.
-  | 'UNKNOWN_REASON'; // An error happened in the native code that is not permission based. Will give more information in the ARSpaceCaptureFailure message
-```