Build a BOT integration with an AI coding assistant.

Prompt 1

Architecture and threat-boundary plan

You are designing an operator-owned backend for a Boring Order Tracker (BOT)
integration. Use the supplied BOT OpenAPI 3.1 contract, operator guide, field
catalogue, and consent/revocation guide as the only source of truth.

Target stack: [LANGUAGE, FRAMEWORK, DATABASE, QUEUE/CACHE]
Deployment environment: [HOSTING/CONTAINER PLATFORM]
Requested BOT scopes: [APPROVED OR REQUESTED SCOPES]
Product feature: [WHAT THE OPERATOR SITE WILL DO]

Produce an implementation-ready architecture covering: the browser/operator
boundary, BOT mTLS client boundary, secret/key storage, initial and delta pull
sync, local idempotent persistence, exact-order linking, history pagination,
revocation deletion and acknowledgement, optional webhook recovery, rate-limit
handling, audit/observability without sensitive payloads, and sandbox-to-
production separation. Include a data-flow diagram in Mermaid, a component
table, storage schema, failure/recovery paths, and a phased delivery checklist.

Privacy and authorization constraints: process only resources explicitly shared
with this integration. Never request, infer, scrape, log, store, return, or
derive a VIN, real order number, BOT account identifier, contact/address/
payment/financing data, Tesla identifiers or credentials, raw provider
responses, or undocumented fields. Never use internal BOT/mobile interfaces,
bypass mTLS or manual production review, broaden scopes, correlate IDs across
integrations, or treat sandbox approval as production approval. Pull sync is
the canonical recovery path. Call out any requested feature that the supplied
contract does not authorize instead of inventing an endpoint or field.

Required public-output rule: keep the implementation non-commercial unless BOT has separately agreed in writing. Render the required BOT credit and app link wherever BOT data appears. For mixed sources, persist provenance and label every BOT-derived record/value at its output location.

Prompt 2

Typed OpenAPI client and safe wrapper

Implement a typed client and a small domain-facing service wrapper for the BOT
Operator Integration API v1 in [LANGUAGE/FRAMEWORK]. Generate or validate types
from the supplied OpenAPI 3.1 file; do not invent operations or response fields.
The base URL is configured per environment and credentials are filesystem paths
or secret-store handles for the matching client certificate and private key.

Support GET /capabilities, POST /link-codes/redeem, GET /sync, order and vehicle
snapshot/history reads, GET /statistics/orders, and POST
/revocations/{id}/ack only when their scopes are present. Implement mTLS while
still validating BOT's public HTTPS hostname/CA, strict timeouts and response-
size limits, RFC 9457 application/problem+json decoding with request_id, ETag/
If-None-Match and 304, opaque cursors, pagination, Retry-After on 429, and bounded
exponential backoff for retryable 503/network failures. Never retry unsafe POSTs
without the endpoint's documented idempotency behavior. Add sandbox contract
tests and show configuration without embedding secrets.

Privacy and authorization constraints: accept and persist only schema fields
that the approved profile returns. Never request, infer, scrape, log, store,
return, or derive a VIN, real order number, BOT account identifier, contact/
address/payment/financing data, Tesla identifiers or credentials, raw provider
responses, or undocumented fields. Redact bodies, link codes, certificates,
keys, cursors, and resource IDs from routine logs. Do not disable TLS checks,
use internal BOT/mobile interfaces, bypass production review, or reuse sandbox
credentials in production. If the contract and my request conflict, stop and
explain the conflict.

Prompt 3

mTLS key, CSR, P12 and rotation runbook

Write a secure, platform-specific runbook for BOT mTLS enrollment and rotation
on [OPERATING SYSTEM/SECRET STORE/REVERSE PROXY]. Base it only on the supplied
BOT mTLS certificate guide and the environment, client ID, and exact CSR common
name supplied by BOT during the certificate issuance flow. If BOT has not
supplied those values, stop and request them; never guess an identity.

Cover local private-key generation, a CSR with BOT's supplied common name in the
form bot:<environment>:<client-id>, accepted RSA 3072-8192 or EC P-256/P-384 keys,
file ownership and permissions, secret backup policy, certificate/chain install,
a harmless /capabilities handshake test, monitoring the 90-day expiry, rotation
with at most two active certificates during the documented 14-day overlap, and
immediate revocation/incident steps. Also describe the one-time encrypted P12
comfort flow as an alternative whose package/password must be claimed within
15 minutes and stored immediately in the operator's secret store. Never output
or ask me to paste a private key, P12 password, certificate claim token, or live
credential into chat, source control, logs, CI artifacts, or command history.

Do not disable server-certificate/hostname validation, fabricate a CSR identity,
request a production certificate before BOT approval, reuse a sandbox certificate
in production, or suggest bypassing mTLS, portal reauthentication, certificate
status checks, or production gates. The API never authorizes VIN, real order
number, BOT account/contact/address/payment data, Tesla credentials, raw provider
responses, or undocumented fields; do not add them to diagnostics.

Prompt 4

Pull sync, ETag, cursor and history worker

Implement the canonical pull-sync worker for a BOT integration in
[LANGUAGE/FRAMEWORK/DATABASE]. Use only the supplied OpenAPI and operator guide.
Start with GET /capabilities, then GET /sync without updated_since for recovery
or initial sync. For each page, apply upserts and tombstones idempotently in one
durable transaction and store next_cursor only after the entire page commits.
Send the opaque cursor back unchanged as updated_since; never parse or synthesize
it. Persist ETag values and use If-None-Match, treating 304 as an unchanged poll.
Paginate order/vehicle history independently and do not claim completeness while
history_complete=false. Poll no more often than the approved quota; use 15
minutes by default. Respect the documented maximum 500 records/8 MiB response,
four concurrent requests, 20/minute burst and 600/hour baseline, plus all
effective values returned by /capabilities. Honor Retry-After on 429 and use
bounded jittered backoff for retryable failures.

Give me the schema, transaction pseudocode, runnable worker code, crash/restart
behavior, cursor-reset recovery, and tests for duplicate pages, concurrent runs,
304, partial history, out-of-order local jobs, tombstones, 410, 429, and 503.

Store only the current allowlisted projection for resources explicitly shared
with this integration. Never request, infer, scrape, log, store, return, or
derive a VIN, real order number, BOT account identifier, contact/address/
payment/financing data, Tesla identifiers or credentials, raw provider
responses, or undocumented fields. Do not use timestamps as a replacement for
BOT's cursor, skip tombstones, scrape internal BOT/mobile interfaces, broaden
scopes, or bypass sandbox/production separation and manual production approval.

Prompt 5

Exact-order linking and code redemption

Build the operator-side "My order" linking flow in [LANGUAGE/FRAMEWORK]. The
user has already selected exact resources and consented inside BOT. On my site,
accept one integration-bound ten-digit link code as a string so leading zeroes
are preserved. Do not place it in a URL. Do not log, persist beyond the exchange,
or send it to analytics. From the server that holds this integration's matching
mTLS credential, POST it to /link-codes/redeem. On success, store only the random
connection ID and integration-specific resource IDs returned by BOT. Never ask
for a BOT login, account detail, VIN, or real order number and never attempt to
match or infer an order from other data.

Design accessible UI states for input, success, expiry/invalid code, throttling,
temporary failure, and a privacy explanation. Codes expire after ten minutes,
are single-use, and allow at most five failed attempts per code; server-side BOT
limits also include ten attempts per source IP in 15 minutes and 60 per
integration/hour. Treat non-redeemable responses as opaque and do not reveal
whether a connection/resource exists. If the initial sync is not complete, do
not consume, brute-force, inspect, or work around the code; show a neutral retry-
later message. Include CSRF, abuse controls, telemetry redaction, and tests for
leading zeroes, concurrent redemption, reuse, expiry, and 429 Retry-After.

Use only documented BOT Operator API routes. Never scrape internal BOT/mobile
interfaces, bypass mTLS or production approval, broaden consent/scopes, correlate
IDs across integrations, or request/infer/store VIN, real order number, BOT
account/contact/address/payment data, Tesla credentials, raw provider responses,
or undocumented fields.

Prompt 6

Revocation, tombstone deletion and ACK

Implement a fail-closed revocation processor for a BOT integration in
[LANGUAGE/FRAMEWORK/DATABASE/OBJECT STORAGE]. Use tombstones from GET /sync as
the authoritative signal that access has already ended. In the same durable
workflow, make the resource unavailable, remove its current snapshot, full
history, search/index/cache/analytics derivatives, queued rich payloads, and any
other retained operator copy covered by policy. Track deletion work without
retaining the deleted personal payload. Only after every deletion step succeeds,
POST /revocations/{id}/ack with {"deletion_completed":true} and a stable unique
Idempotency-Key. Make retries safe. Complete and acknowledge within seven days;
surface an operational alert well before the day-five warning. Treat 410 on a
detail endpoint as the same mandatory-deletion condition. Remember that a fresh
initial sync can replay retained tombstones, so cursor loss must not lose the
obligation.

Provide a state machine, schema, worker code, retry/dead-letter policy, deletion
inventory, audit evidence that contains no deleted payload, and tests for partial
failure, duplicate tombstones, cursor reset, ACK timeout/retry, connection-wide
revocation, and suspension after a missed deadline.

Never delay access removal until ACK, acknowledge before deletion, restore data
from a stale cache/backup, or include rich data in a revocation notification.
Never request, infer, scrape, log, retain, return, or derive a VIN, real order
number, BOT account identifier, contact/address/payment/financing data, Tesla
identifiers or credentials, raw provider responses, or undocumented fields.
Never use internal BOT/mobile interfaces or bypass consent, mTLS, scopes, or
production gates.

Prompt 7 · optional

Signed webhook receiver

Implement an optional BOT webhook receiver in [LANGUAGE/FRAMEWORK]. Pull sync
must remain the canonical recovery source. Follow the supplied AsyncAPI contract
and RFC 9421 HTTP Message Signatures. Accept only a public HTTPS endpoint that I
register and verify in the BOT portal. Before parsing or acting on the JSON body,
verify Content-Digest and the Ed25519 HTTP Message Signature, including the
covered method/target/components required by the contract. Fetch BOT's versioned
public key set from the documented same-portal JWKS URL, cache it only for its
advertised lifetime, and reject an unknown keyid. Enforce timestamp freshness,
store x-bot-event-id for replay protection, durably enqueue the exact verified
event once, and return 2xx only after durable acceptance. Handle duplicates,
delays, key rotation, temporary queue failure, and events arriving around a pull
sync without assuming webhook order.

Provide code, configuration, a verification test harness with valid and tampered
messages, and an operations runbook. Revocation events are minimal deletion
signals and must trigger the same deletion workflow as sync tombstones; never
expect or require a rich revocation payload.

Do not expose private/reserved callback targets, follow redirects during endpoint
verification, trust unsigned headers/body, skip digest verification, fetch keys
from an attacker-selected URL, or make webhooks the only recovery mechanism.
Never request, infer, scrape, log, store, return, or derive a VIN, real order
number, BOT account identifier, contact/address/payment/financing data, Tesla
identifiers or credentials, raw provider responses, or undocumented fields.
Do not bypass mTLS/scopes/consent or sandbox and manual production gates.

Prompt 8

Privacy, isolation, contract and quota tests

Create and implement a security/privacy-focused test plan for my BOT integration
backend in [LANGUAGE/TEST FRAMEWORK]. Derive behavior from the supplied OpenAPI,
AsyncAPI, field catalogue, and consent/revocation guide. Use synthetic sandbox
fixtures only.

Include schema/contract tests; mTLS environment mismatch and revoked/expired
certificate tests; at least ten synthetic integration tenants proving no cross-
tenant connection, resource ID, cursor, statistics, certificate, webhook, or
cache access; link-code expiry/single-use/leading-zero/concurrency/brute-force
tests; initial/delta sync, opaque cursor, ETag/304, history_complete, pagination,
idempotency, crash recovery, tombstone and 410 tests; immediate revocation plus
full deletion/ACK tests; aggregate-only statistics with no individual records;
webhook signature/digest/replay/duplicate tests if enabled; and error/log/
telemetry snapshots.

Add leak canaries and assert that VIN, real order number, BOT account ID/contact/
address/payment/financing data, Tesla IDs/tokens/credentials, raw provider
responses, GPS/presence-sensitive state, and undocumented fields never appear in
API-derived persistence, responses, history, statistics, webhook payloads, logs,
traces, metrics, exceptions, analytics, fixtures, or exports. Verify effective
quotas from /capabilities, the baseline 600/hour, 20/minute burst, four concurrent,
500 records/8 MiB, statistics 120/hour/2 MiB, and correct Retry-After behavior;
do not write a load test that intentionally attacks or evades BOT limits.

The plan must not scrape internal BOT/mobile interfaces, broaden scopes, disable
TLS/mTLS, use real production user data, infer prohibited fields, or bypass
manual production approval. List every untestable assumption as a production
blocker instead of marking it passed.

Prompt 9

Production-readiness review

Act as a strict production-readiness reviewer for an operator-owned BOT
integration. Review the supplied implementation, BOT OpenAPI/AsyncAPI contracts,
operator/field/consent guides, portal application profile, and sandbox evidence.
Return: (1) blockers, (2) high/medium/low risks, (3) evidence matrix, (4) exact
remediation tasks, and (5) a go/no-go recommendation. Do not treat missing
evidence as passed.

Require evidence for: immutable public name/slug and clear purpose; verified
support contact and HTTPS website/privacy/terms/linking URLs; only necessary
reviewed scopes; accepted current BOT Integration Terms; strictly non-commercial
operation unless a separate written commercial agreement is supplied; no Ads,
AdSense or other direct/indirect monetization under the standard license;
required BOT credit and app link plus review URL; item-level BOT provenance for
every BOT-derived record/value in mixed-source output; operator data
retention/deletion policy; environment-separated secrets, database and mTLS
clients; locally protected key/CSR and tested certificate rotation/revocation;
successful synthetic sandbox contract, isolation, privacy, rate-limit, cursor/
ETag, history and revocation tests; 15-minute default pull with durable recovery;
optional webhook signature/replay tests; monitoring that redacts payloads and
credentials; a seven-day deletion/ACK runbook; legal/privacy approval; rollback
and incident response; and explicit BOT manual production approval with a
separate production client/certificate.

Production must remain NO-GO while any required profile field/evidence is
missing, review is pending/rejected/suspended, a sandbox credential is being
used, mobile consent/data synchronization is unavailable, legal gates are open,
or tests reveal prohibited data. Never suggest a workaround for a gate, internal
BOT/mobile scraping, broader scopes, or access to VIN, real order number, BOT
account/contact/address/payment/financing data, Tesla identifiers/credentials,
raw provider responses, or undocumented fields. The review cannot grant access;
only BOT's manual approval and issued production credential can do so.