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

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: https://github.com/ObolNetwork/obol-stack/pull/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.

Start by reading PR #429 and the existing obol tunnel setup, domain, and Cloudflare workflow entry points it introduced. This issue bundles five product directions, so select and scope one independently before coding. Done should mean that one follow-up has defined commands, state, confirmation, and acceptance criteria rather than attempting the entire proposal.