# Allow agents to register domains

## Purpose

Define how GETQUICK agents may register or provision domains through Cloudflare when the user asks for a production deployment, a new domain, or a domain purchase.

This specification is based on Cloudflare's April 30, 2026 announcement that agents can provision Cloudflare accounts, obtain API tokens, purchase domains, and deploy through a Stripe Projects-style flow with user authorization and payment controls.

## Context

Cloudflare describes an agent provisioning model with three core parts:

- Discovery: the agent queries a catalog of available services before choosing what to provision.
- Authorization: the signed-in platform attests to the user's identity, then Cloudflare either links an existing account through OAuth or provisions a new Cloudflare account.
- Payment: the platform supplies a payment token so Cloudflare can bill the user without exposing raw card details to the agent.

In the Stripe Projects flow, the agent can discover Cloudflare Registrar, call a command such as `stripe projects add cloudflare/registrar:domain`, prompt for approval when needed, and end with a deployed app on a newly registered domain.

GETQUICK agents should treat domain registration as a high-impact purchase and identity operation. It must be explicit, user-approved, budget-aware, and auditable.

## Outcome

After this specification is implemented:

- Agents can register a domain only after the user explicitly asks for domain registration or approves a proposed domain purchase.
- The agent checks whether a domain is needed before attempting to buy one.
- The user sees the domain name, expected cost, account, registrar, and payment path before purchase.
- The agent never handles raw payment card data.
- The agent stores only the minimum deployment credentials needed for the active task.
- The resulting domain is configured, validated, and documented.

## Steps

### Decide whether domain registration is allowed

Allow domain registration only when one of these is true:

- The user directly asks to buy, register, or provision a domain.
- The user asks to deploy to production and approves the agent's proposal to register a specific domain.
- The workflow already requires a custom domain and the user confirms the domain name and purchase.

Do not register a domain when:

- A temporary preview URL is enough.
- The user only asked for local development.
- The user has not approved a specific domain name.
- The domain could conflict with an existing brand, customer, or production property.
- The agent cannot determine the billing account or expected cost.

### Discover the provisioning path

Before registration, the agent should discover available services from the active orchestrator or platform catalog.

For a Stripe Projects-style flow, the expected discovery path is:

```bash
stripe projects catalog
```

The agent should look for a Cloudflare Registrar domain service, then choose that service only if it matches the user's requested outcome.

### Ask for explicit approval

Before any purchase, show the user:

- The exact domain to register.
- The Cloudflare account or identity that will own the domain.
- The orchestrator or payment provider that will pay for it.
- The expected recurring cost and renewal behavior, when available.
- The deployment or DNS purpose for the domain.
- Any fallback if the requested domain is unavailable.

Use a direct approval prompt. Do not rely on vague approval such as "ship it" when a paid domain purchase is involved.

### Provision or link the Cloudflare account

If the orchestrator supports Cloudflare account provisioning:

1. Use the signed-in user's identity from the orchestrator.
2. If the user already has a Cloudflare account, send them through the provider's OAuth flow.
3. If the user has no Cloudflare account, let Cloudflare provision one through the supported account creation flow.
4. Store returned credentials only in the orchestrator's secure credential store.
5. Do not print, log, or commit API tokens.

The agent must not ask the user to paste raw Cloudflare API tokens into chat unless there is no supported orchestrator flow and the user explicitly chooses a manual fallback.

### Register the domain

For a Stripe Projects-style flow, the registration command described by Cloudflare is:

```bash
stripe projects add cloudflare/registrar:domain
```

The agent should pass or select the approved domain only through the orchestrator's supported interface.

If the orchestrator prompts for a payment method, account authorization, or terms acceptance, pause and let the human complete that step. Cloudflare notes that humans must accept Cloudflare terms of service even when the rest of the flow is agent-driven.

### Configure DNS and deployment

After registration:

1. Confirm the domain is owned by the expected Cloudflare account.
2. Configure DNS records for the intended app, Worker, Pages project, or service.
3. Use proxied records for HTTP and HTTPS traffic when Cloudflare should protect the site.
4. Keep mail and verification records DNS-only unless the provider requires otherwise.
5. Configure SSL/TLS before sending users to the domain.
6. Deploy or attach the app to the domain.

### Record the result

At completion, report:

- Registered domain.
- Owning Cloudflare account or project identity.
- Deployment target.
- DNS records changed.
- Validation results.
- Any renewal, budget, or billing notes the user should review.

Do not include secret tokens or payment details in the final report.

## Validation

Validate the agent flow before considering the task complete:

```bash
dig NS example.com
dig A example.com
dig CNAME www.example.com
curl -I https://example.com
```

Expected results:

- The domain is registered in the intended Cloudflare account.
- DNS returns Cloudflare nameservers for Cloudflare Registrar domains.
- The app domain resolves to the intended target.
- HTTPS returns a valid response.
- The user has approved the purchase in the conversation or orchestrator UI.
- No secrets, payment card details, or raw API tokens were written to source control or chat.

## Operational notes for agents

Use this spec when a user asks an agent to register a domain, buy a domain, deploy to a new custom domain, or set up production hosting that requires a domain.

Prefer an orchestrator-mediated flow such as Stripe Projects when available because it provides discovery, authorization, and payment handling without exposing raw payment details to the agent.

If no safe orchestrator flow is available, fall back to the human Cloudflare domain SOP at `/cloudflare/register-a-domain-with-cloudflare/`.

Important search terms: agent domain registration, Cloudflare Registrar, Stripe Projects, service discovery, OAuth authorization, payment token, domain purchase approval.

## Troubleshooting

- If the requested domain is unavailable, stop and ask the user to choose or approve an alternative.
- If the user has no payment method, pause for the orchestrator's payment setup flow.
- If OAuth authorization fails, ask the user to retry authorization or use the manual Cloudflare workflow.
- If the agent cannot determine the owning account, do not register the domain.
- If the agent exceeds or may exceed a budget limit, stop and ask for explicit user approval before continuing.
- If deployment succeeds but the domain does not resolve, check DNS records, nameservers, and SSL/TLS configuration.