# Prepare YieldGate Sales in a Lovable or Bolt React app

This guide accompanies the reviewed React/Vite installer package. It prepares a customer-facing sales widget in the app you publish. It does not create a builder API/MCP connection, marketplace listing or merchant installation.

Current package state: local source and offline checks are prepared; actual Lovable/Bolt installation and live AI behavior are not verified by those checks. The common hosted widget also needs its reviewed lifecycle update and public verification before this adapter can support a real deployment. Keep display off while that release requirement is unresolved.

## 1. Start with the small result

Choose one public product page and one purchase question. Confirm the product facts and approved next purchase step. Do not include private customer transcripts, orders, credentials or payment data.

For example, a buyer who already chose Premium should be helped toward that approved option. A price objection should receive the documented premium difference. An unknown delivery date should remain unconfirmed.

## 2. Use the package for your app

For an authorized existing React project, supply the reviewed `YieldGateSales.jsx` and `install-yieldgate.js` together. Use the matching Lovable or Bolt paste-ready prompt. Ask the builder to preserve current routes, login, checkout, backend and other integrations. No builder REST connector or MCP permission is required by this widget package.

Keep the component in the persistent application shell, outside individual route screens:

```jsx
<YieldGateSales enabled={false} siteId="" />
```

The supplied component uses the accompanying installer; copying the line alone does not supply those files. Do not inject a second raw script as well.

For the supplied React/Vite example, its public configuration starts as:

```dotenv
VITE_YIELDGATE_ENABLED=false
VITE_YIELDGATE_SITE_ID=
```

Only the actual public installation site ID may later go in that field. It is not a provider key or owner login. Never put secrets, account cookies or customer conversations in client code or builder prompts.

## 3. Check the app before enabling it

Run the app’s existing checks and build through the owner’s normal environment. Inspect navigation, repeated mounts and full removal. A local or shared builder preview can show wiring and status, but cannot stand in for the required verified custom HTTPS domain.

Confirm separately that the merchant is authorized to change the site, the actual domain is verified, the product information is approved, the agent is published and service access is active. Check the relevant visitor notice and the current supported hosted asset. The installer does not create those permissions or change billing.

## 4. Understand the visible result

- `disabled`: display is off.
- `requires_verified_custom_https_origin`: this is a local/shared preview or another unsupported origin.
- `awaiting_hosted_lifecycle`: a script was requested; chat availability is not confirmed.
- `hosted_lifecycle_unavailable`: the hosted asset does not support the required installation lifecycle; stop this setup and obtain the reviewed compatible release.
- `unavailable`: script/configuration access failed; no AI fallback should be invented.
- `available`: the supported asset passed configuration checks and mounted. This does not prove an AI answer, purchase or revenue result.

Once the actual domain and current asset are verified, the owner may enable the public setting with the real installation site ID through the app’s normal release process. That is a separate publication decision, not an instruction for the builder to deploy automatically.

## 5. Test one deliberate conversation

Opening the widget should not create an automatic AI answer. A visitor’s explicit Send enters the existing chat path and its limits. Check one approved task, then inspect the actual response against the product facts. Do not add automatic sends, retries, recording opt-in, purchase actions or fake AI replies to make the preview appear successful.

Removing the component should dispose of its supported widget. The package refuses to silently adopt a conflicting manual installation. Local removal is not a promise to delete historical hosted records.

Any optional recording, personas or operator-improvement features require their own release, access and customer-notice checks. Current service handling is described in [YieldGate Sales privacy](https://agent-revenue.oraxlabs.io/sales-privacy.html).