Relentless installation instructions
Version: 2026-09-16
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. 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.
Ask which regions the site serves, expressly including UK and EEA. The site owner
owns visitor privacy/consent content and determines applicable regimes. Explain
that clear prior consent may be required; do not inject Relentless legal copy or
a second banner. Integrate the client-approved consent signal. Relentless retains
its own processor/DPA and security obligations.

2. OWNER SIGN-IN
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
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". Expired challenges require a new file. Verification does
not grant visitor consent or enable capture.

4. GET THE ISSUED INSTALLATION PACKAGE
When capture setup is available, the owner selects approved public pages and the
website release, then chooses "Download installation package". Use that download's
README and framework instructions. Do not invent a package name, install command,
script URL, token, or endpoint. Missing capture permission or unsupported setup
is a blocker. Keep an unknown release explicitly unknown.

5. REVIEW THE INTEGRATION
Replay-capable code may ship, but replay must remain disabled for initial use.
Require signed/current per-site configuration, account-owner enablement AND the
client-approved visitor-consent 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 existing
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, and never
grant analytics consent in code. Unknown or denied consent
must block capture, and 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 complete these same steps without a prompt or coding
agent. The issued package supplies the integration instructions.