Relentless installation instructions Version: 2026-10-14 Human guide: https://relentlessengine.com/install/guide Owner setup: https://relentlessengine.com/connect Fetch this document directly over HTTPS. Browser navigation is not required to read it. This is guidance, not an executable installer or authorization to deploy, change permissions, or collect visitor data. Follow the website repository's instructions and the owner's approved scope. When the website owner runs this prompt in an agent with authorised codebase access, prepare the requested integration and PR without asking again for that same permission. This is not visitor consent or authorization to activate capture. 1. CHECK SETUP AVAILABILITY AND INSPECT THE PROJECT Before asking the owner to sign in, create a verification file or download a package, GET https://relentlessengine.com/auth/options without credentials. Read the JSON capability flags, not the HTTP status alone. A failed request, non-JSON response or missing flag leaves that capability unconfirmed. - install_proof_enabled must be true before requesting a new verification file. - preparation_package_enabled must be true before requesting an inert preparation package. This flag does not promise capture or an authenticated download. - email_enabled or an advertised provider indicates a sign-in option only; it does not prove that this owner can sign in or that website setup is available. - activation_allowed:false does not prevent preparation, but grants no permission to collect. Other advertised flags also do not establish capture authorization. If verification or package preparation is unavailable, report the specific Relentless service capability, check time and setup URL. Do not ask the owner for files or downloads that the service cannot currently issue. Continue independent project inspection and record candidate public-page exclusions and the concrete next step. Use an already issued, applicable package only within its instructions; without one, do not invent an SDK, integration, verification file or endpoint. Keep account-dependent work pending until the relevant service is available. INSPECT THE PROJECT Identify the framework, existing analytics, consent manager, public and sensitive routes, and release process. Inspect any existing Relentless installation first. Preserve unrelated work and tracking. Propose the smallest reviewable change. Use existing approved project information for the regions served, including UK and EEA; keep unknown regions unknown. Resolve missing regional and consent requirements before collection review, not as a prerequisite to inert preparation. The site owner owns visitor privacy content and chooses the default per region. Relentless's default is to track every visitor with an opt-out, and to require a prior opt-in only for EU/EEA visitors; an unknown region counts as EU/EEA. Do not inject Relentless legal copy or add a banner. Collection must bind the site's capture-permission signal. Relentless retains its own processor/DPA and security obligations. 2. OWNER SIGN-IN When the required setup capabilities are available, ask the owner to open https://relentlessengine.com/connect in their browser, sign in with an available option, and select or add the exact website origin. Keep development and production separate. Never request session cookies, sign-in links, or private account credentials in the conversation. Sign-in and account approval are owner actions, not browser discovery tasks. If setup reports "Sign-in is temporarily unavailable", stop account-dependent work and report that message and the setup URL. A 200 response for the HTML page does not prove sign-in works. Do not substitute a demo, guessed package, invented API, or changed service settings. You may inspect the local project and explain the next step without installing. 3. VERIFY WEBSITE CONTROL WHEN AVAILABLE After confirming install_proof_enabled:true, the owner chooses "Create verification file" and shares the generated public verification instructions. Prepare only that file at the supplied address. Publish through the project's review and deployment process. The owner then chooses "Verify file". Follow the conditions displayed for that actual check. A displayed deadline requires completion before expiry in the same sign-in; a new sign-in clears legacy checks. Only an active check explicitly reported without a deadline survives a new sign-in. An absent check does not establish this behavior. A cancelled or replaced challenge requires a new file. Verification does not grant visitor consent or enable capture. 4. GET THE ISSUED PACKAGE AND IDENTIFY ITS TYPE When preparation_package_enabled:true, website setup can offer "Prepare your installation" even while capture is unavailable. Select candidate static public pages and the intended website release, then use "Download installation package". Keep an unknown release explicitly unknown. Use the issued RELENTLESS_INSTALL.md and manifest to determine what was downloaded; the button label alone is not proof. A preparation package has kind:account_installation_preparation_package and capture_ready:false. It contains a data-only bootstrap and inert relay, with no SDK, recorder, browser observers or forwarding handler. Follow its guide to prepare the smallest reviewable change and PR. Do not wire consent or interaction listeners, mount ingestion, or add a replacement SDK. Missing capture permission or a consent manager does not block this inert preparation. Do not require a capture grant to prepare files that cannot collect. This is preparation only, not a working installation or a verified event receipt. A capture package is a separate, grant-backed download. Follow its issued guide and the collection requirements below; neither download availability nor an unsigned manifest establishes activation approval. Do not invent a package name, install command, script URL, token or endpoint. Unsupported framework or package requirements stay pending; report the exact mismatch without enabling anything. 5. REVIEW ANY LATER CAPTURE INTEGRATION The inert preparation package above cannot be activated by changing a flag. It must be replaced with a separately reviewed, grant-backed capture package. Replay-capable code may ship, but replay must remain disabled for initial use. Require signed/current per-site configuration, account-owner enablement AND the site's capture-permission signal before collection. Reject missing, invalid, expired, revoked or mismatched configuration. Disabled replay must not capture, queue, persist or transmit replay-capable payloads; hiding playback is not enough. Initial rollout is event-only: no session replay, DOM snapshots, broad autocapture, form-entered data, tax facts or protected information. Use explicit reviewed non-form events on allowlisted static public pages. Exclude all forms, diagnostic and personalized-result flows, accounts, documents, credentials and payments. Do not collect raw URLs, query strings, fragments or referrers. Verify the issued SDK enforces this at collection and ingestion; masking or replay=false alone is not proof. If it cannot, prepare a disabled integration/PR and report the activation blocker. Do not enable the existing recorder to obtain a recording ID. Keep server files and private credentials out of browser assets. Bind the site's existing permission signal or consent manager. If none exists, report the prerequisite to the site owner and prepare with capture disabled; do not inject a banner or legal copy. Default-on applies only outside the EU/EEA and only through the owner's signal; never fake an EU/EEA opt-in in code. A refusal, and an unknown choice from an EU/EEA visitor, must block capture; withdrawal must stop it. Exclude sensitive pages and test masking, navigation, removal, and the project's required checks. Obtain approval before deployment or enabling visitor capture. 6. VERIFY EVENT-ONLY RECEIPT After separate authorized activation, use synthetic permitted non-form events to verify the actual website, release, package hash and consent state. Inspect SDK, wire, ingestion, storage, logs and report output. Retain the actual event receipt and the exclusion-test results, not a replay recording. If the issued verification flow requires session replay, it is not eligible for this initial rollout; keep capture disabled and report the package mismatch. A downloaded package or script tag is not installation success. Do not invent receipts or claim an unverified configuration is safe. MANUAL ALTERNATIVE An owner and developer can follow these same steps without a prompt or coding agent. Check service availability first. The issued package supplies its own instructions; preparation and verified collection are separate outcomes.