You are editing my existing website repository. Integrate the KyroFeedback feedback widget with the smallest change that fits this project's current framework and conventions.

Project details:
- Website: [https://www.example.com]
- KyroFeedback origin: https://feedback.kyrocms.com
- Project slug: [my-product]
- Publishable key: [pk_live_...]
- Desired widget position: [bottom-right or bottom-left]
- Desired placement: [all pages, help page only, account area, etc.]

Requirements:
1. Inspect the repository, identify its framework, app entry point/layout, existing script-loading pattern, CSP/security policy, and relevant tests before editing.
2. Add this script only in the requested area, adapting its placement to the framework:
   <script src="https://feedback.kyrocms.com/widget.js" data-project-key="pk_live_..." data-position="bottom-right"></script>
3. Load the script after the document body exists, and avoid adding React/Next.js code to a plain website unless the site already uses it.
4. Use only this pk_live_ publishable key. Do not create, request, embed, log, or expose an sk_live_ secret key. Do not send credentials to any destination except the configured KyroFeedback origin.
5. Do not redesign the site or change unrelated components, routes, styles, or dependencies.
6. Preserve the existing Content Security Policy and explain any required script-src/connect-src additions rather than weakening the policy broadly.
7. Test the affected route in the project's available browser/test setup. Confirm the launcher appears, the widget opens, feedback can be submitted, and the browser console/network show no relevant errors. If you cannot run a browser, state that clearly and provide exact manual test steps.
8. Report files changed, where the key is configured, tests performed, and any deployment steps.

If a required value is missing, inspect the repository first, then ask only for that missing value. Do not guess a production key or domain.

You are editing my existing website repository. Build a small customer-facing feedback experience using KyroFeedback's public API, while leaving KyroFeedback as the system of record. First inspect the project's framework, routing, design system, authentication model, environment-variable conventions, CSP, and test setup. Follow existing UI patterns; do not redesign unrelated pages.

Configuration:
- KyroFeedback origin: https://feedback.kyrocms.com
- Project slug: [my-product]
- Publishable browser key: [pk_live_...]
- Entry point/location: [header link, account page, support page, etc.]
- Desired customer flow: [submit only / browse, submit, vote, comment]
- Brand/design requirements: [describe them]

Use the versioned API at https://feedback.kyrocms.com/api/v1. Send `Authorization: Bearer pk_live_...` and JSON content type. A publishable key is intended for browser use; do not use or expose a secret key. Keep `credentials: "include"` on browser API calls so anonymous identity cookies work.

Supported endpoints:
- GET /config
- GET /feedback?limit=20&q=...&status=...&type=...
- POST /feedback with { title, description, type, authorName? }
- GET /feedback/:id
- GET /feedback/:id/comments
- POST /feedback/:id/comments with { content, authorName?, parentId? }
- GET, POST, DELETE /feedback/:id/votes

Types are FEATURE, BUG, QUESTION, INTEGRATION. Comment parentId is optional and must belong to the same feedback item. Anonymous feedback, comments, and voting can be disabled by the project owner; show the API's permission error clearly and link to the hosted portal at https://feedback.kyrocms.com/p/my-product for sign-in flows. Handle loading, empty, validation, success, rate-limit, network, and API error states. Never silently discard a submission.

Security and implementation requirements:
1. Verify every request uses the configured KyroFeedback origin and this project's publishable key only.
2. Do not add secret keys, server credentials, or user passwords to client bundles, logs, prompts, or source control.
3. Respect the host site's existing consent, CSP, accessibility, responsive layout, and design-system patterns.
4. Keep changes scoped to the requested feedback experience. Do not invent unsupported endpoints or assume a dashboard API is available to browser users.
5. Test listing, submission, detail, comments/replies, voting/unvoting, keyboard use, mobile layout, and error states using the project's available tools. If browser testing is unavailable, state what could not be verified and give manual steps.
6. Report all changed files, the configuration location, exact tests run, and deployment steps.

Inspect this website and add a clear link or button labeled [Give feedback] that opens https://feedback.kyrocms.com/p/[project-slug]. Place it at [desired location] using existing components and styles. Open in the same tab unless the site's established pattern says otherwise. Do not add dependencies, API keys, a new feedback form, or unrelated redesigns. Test the link destination and report the files changed.