Follow up PR #429: account-link, budget guardrails, and durable Cloudflare provisioning workflows

[bussyjd]

Summary

PR #429 (feat: improve persistent Cloudflare tunnel setup and domain onboarding) is a strong v1 for persistent tunnel robustness and guided domain onboarding, but there are a few follow-up product improvements we should track separately rather than block the PR on them.

Reference draft basis:

• PR: feat: improve persistent Cloudflare tunnel setup and domain onboarding #429
• Cloudflare article inspiration: https://blog.cloudflare.com/agents-stripe-projects/

Why

PR #429 already moves obol in the right direction by adding:

• obol tunnel setup
• domain search/check/register flows
• account / zone auto-resolution
• explicit tunnel management modes
• persistent resource restore
• better tunnel status / connector visibility

The remaining gaps are mostly about turning this into a more agent-native, low-friction, budget-safe provisioning workflow.

Follow-up improvements

1. Replace raw API-token-first UX with an account-link flow

Today the persistent remote path still assumes operator-managed CLOUDFLARE_API_TOKEN input.

Follow-up direction:

• add a first-class obol cloudflare connect flow
• support browser/device/OAuth-style account linking
• store only a scoped credential locally
• make obol tunnel setup --hostname ... work after account-link instead of requiring raw token-first setup

Why:

• closer to the Cloudflare “signed-in orchestrator identity” model
• less credential juggling for operators
• safer than copying broad API tokens around

2. Add budget / policy guardrails for billable registrar actions

PR #429 adds confirmation around billable registration, but not durable spending policy.

Follow-up direction:

• add --max-registration-cost
• add config-level guardrails such as:
  • max monthly registrar spend
  • max single purchase cost
  • allowed TLDs
  • premium-domain opt-in
• emit explicit preflight pricing summaries before purchase

Why:

• closer to the Cloudflare “agent can spend within bounded budgets” model
• safer for future agent-driven or unattended workflows

3. Make domain-registration workflows first-class resumable objects

The draft already has async workflow polling internals, but the workflow lifecycle is not yet exposed as a first-class CLI surface.

Follow-up direction:

• add commands like:
  • obol domain workflow status <id>
  • obol domain workflow wait <id>
  • obol domain workflow resume <id>
• persist workflow IDs/URLs in local state when registration is async

Why:

• makes long-running registrar operations durable and inspectable
• better recovery after partial completion, terminal interruption, or host restarts

4. Add a machine-readable provisioning catalog for agent/tool use

The new CLI is much more discoverable for humans, but agents still have to infer capabilities from command docs.

Follow-up direction:

• expose a machine-readable catalog of provisionable resources and inputs, e.g. tunnel, DNS, registrar, account-link
• include whether an action is billable, async, or requires confirmation

Why:

• better fit for agentic setup flows
• easier future integration with Hermes / MCP / external orchestrators

5. Improve obol tunnel setup product messaging around zone/account/domain state

The new setup flow is much better, but still expects some Cloudflare literacy when zone resolution fails or domain setup is incomplete.

Follow-up direction:

• make setup output more productized and stateful, e.g.:
  • “Cloudflare does not manage example.com yet.”
  • “I can register example.com now and continue setup.”
  • “Estimated annual price: $X/year.”
• explain clearly whether the next step is account-link, zone attach, registration, or tunnel provisioning

Why:

• lowers operator friction
• better matches the “zero to production without manual steps” direction

Suggested scope note

These should be tracked as follow-up product improvements and should not block the core tunnel/domain robustness gains already in PR #429.