# RebidWire agent guide

RebidWire is in development. Its intended audience is Dallas–Fort Worth janitorial contractors. The site is a landing page with an email waitlist, privacy notice and public-record example. It does not expose live contract search, customer accounts, prices, a dashboard, or an MCP service.

## Request launch updates

Prefer the labeled email form on the landing page. It collects only an email address for RebidWire launch and availability updates. Submit only when the user explicitly asks to join that list and supplies or approves the address. Reading the site does not imply consent. Do not harvest addresses, enumerate subscribers, batch-submit, or bypass abuse controls.

The production form sends a same-origin POST to `/api/waitlist` with `Content-Type: application/json` and JSON `{"email":"user-approved-address"}`. It requires the exact site Origin. Email is trimmed and normalized to lowercase, has a maximum length of 254 characters and a local part of at most 64 characters, and is validated on the server. Request bodies are bounded. Production valid submissions are limited to 10 per connection in 10 minutes; the loopback prototype uses a separate process-local limit. Honor 429/Retry-After; do not rotate identities to retry.

A successful response is deliberately generic for new and duplicate addresses. It confirms the request was handled, not message delivery, identity verification, a new subscription, or product access. Existing unsubscribed records are not reactivated by submitting again. Invalid input returns 400; disallowed origins return 403; unsupported content types return 415; oversized bodies return 413; unavailable storage returns 503. Show the response safely and preserve the user's input after an error. Do not treat an HTTP error as success.

## Email and opt-out

The reviewed production email version adds one confirmation for a new signup, with bounded provider retries and an unsubscribe link. Activation requires configured provider credentials and the reviewed database migration; a generic signup success never proves that version is active or that delivery occurred. Existing records are not backfilled. Launch campaigns are not implemented.

The unsubscribe link carries a private random token in the URL fragment. The preference page submits it to the same-origin `/api/unsubscribe` endpoint only after the user's action. Treat that token as a credential: never put it in query strings, logs, search indexes, or shared transcripts. Do not invent a token. Successful opt-out preserves suppression so repeated signup does not reactivate it; an already in-flight email may still arrive. An invalid link is an error, not confirmation of removal. Without a valid link, contact hello@cairn-labs.com for help or deletion.

## Privacy and local preview

Read the current `/privacy` page before action; it is authoritative for the deployed version's data flows. Email, consent timestamps/version and subscription state are stored for the waitlist. Production uses Vercel and Neon; the reviewed email version uses Resend for confirmation delivery. No analytics, cookies, open tracking or click tracking are enabled by default. There is no claimed fixed automatic deletion deadline. Private signup and preference responses are not public discovery data.

At a `127.0.0.1` preview, use synthetic addresses only. Its isolated SQLite database sends no email and has no live unsubscribe capability. This is separate from production storage. Do not assume the local confirmation text establishes a production subscription.

`/product.json` and `/llms.txt` are public informational discovery files. They do not grant permission or provide a security boundary. There is no advertised WebMCP tool or dedicated agent backend in this version.