Set up Heedeo in this app using the current plain-text guide at https://app.heedeo.com/docs/integration.md (human-readable version: https://app.heedeo.com/docs). Read the guide before editing; if you cannot access either version, ask me for its contents rather than guessing the API.

Inspect the app, framework version, package manager and lockfile, hosting configuration, existing signup flow and any existing Heedeo integration. Preserve the current stack, authentication, routes and middleware. Extend an existing integration instead of installing it twice. Start in observation-only mode: collect signals without blocking signups or adding verification steps.

For a new Node.js or Cloudflare Workers integration, read https://app.heedeo.com/docs/sdk.md and install the official npm package with `npm install @heedeo/sdk` (or the equivalent for the app’s package manager). Use the version resolved by the lockfile. The package handles script loading, forwarding, types, retries and errors; do not reimplement those pieces or add a duplicate script tag. Use the manual guide for unsupported frameworks and existing server-action integrations. Configure the trusted client-IP source for the actual host, never an arbitrary header or a production localhost fallback. No change of hosting or authentication is needed.

Use my Heedeo publishable key for the browser. Keep HEEDEO_SECRET_KEY only in the server environment. If it is missing, tell me where to enter it locally and in my deployment settings; do not ask me to paste the secret into chat, print it, commit it or put it in browser code. Keys are available after signup at https://app.heedeo.com/review/sign-up.

If this prompt names an endpoint from my Domains page, Heedeo is already served from my domain there, so skip the forwarding route in step 1. Pass the endpoint as `endpoint` to createHeedeo if the installed @heedeo/sdk takes it (0.1.0-pilot.11 and later); otherwise load the script from it, `<endpoint>/i.js?key=<publishable key>`. Without an endpoint, forward the two paths as step 1 says.

Implement the full flow from the guide. When using the package, let its documented methods own the following behavior; do not duplicate the internals:
1. Forward the script and identification paths through this app's own domain, preserving the required cookies, response Set-Cookie headers and request headers. Use the hosting provider's documented, trusted client-IP source, consistently for identification and events. Never blindly trust an arbitrary incoming IP header or enable unrestricted proxy trust. Merge with existing routing and authentication rules. Use a supported path prefix if the default paths conflict.
2. Load the script once and call identify() just before the signup action, not on every page load. Pass the returned token to the server for that attempt. If the script is unavailable or identification fails, signup must still work.
3. Send POST /v1/events from the server with the required fields in the guide and the signup email. Include a user ID when available without sending a second event using the same receipt. Use one request_id per logical attempt and reuse it for retries. Forward the actual request method, path and required headers; exclude cookie and authorization headers case-insensitively and do not send unrelated secrets. Use bounded timeouts and retries. Missing signals or a Heedeo outage must not stop signup.
4. Keep signals on the server, record the event_id for debugging, and do not expose internal reasons to end users. Do not copy the guide's example refusal rule into the pilot. Show me the suggested privacy-policy wording for review before publishing it.

Run the app's relevant checks and exercise a test signup in the browser. Confirm that identification returns a usable receipt and that the server event succeeds with an event_id and a non-null visitor. Check that a retry returns the same event instead of creating another, and that signup still works when Heedeo is unavailable. Never claim success just because the script loads, a key-validation request returns invalid_token, or the flags page is empty. If credentials or deployment access prevent a check, report exactly what remains unverified.

Return to https://app.heedeo.com/review/welcome to verify installation. Its live check distinguishes waiting for an event, an event without a matched browser, and an event linked to a visitor. Do not treat a historical matched event as proof of a new code change: compare the displayed event ID and timestamp with the test you just ran.

Finish with the files changed, checks actually run, the test event_id if available, and the remaining deployment steps. Do not deploy unless I have authorized deployment. Distinguish local verification from verification on the deployed site; check secure-cookie behavior over HTTPS before calling production setup complete.