Ember Sandbox Provision

For the sandbox operator only. Turns an approved sandbox request into a running sandbox, and removes it at expiry. Application developers never run this skill. They file requests with ember-app-onboard and wait for the operator.

When to Use

• A Sandbox request: <slug> issue is open in ATL-Trip-Planner/ember-platform-skills.
• A sandbox has reached its expiry date or is no longer needed.
• Your regular expiry review, every 30 to 60 days.

What to Say

• "Show open sandbox requests."
• "Validate and plan sandbox request #12."
• "Provision sandbox request #12."
• "Tear down the sandbox for my-app."
• "Which sandboxes are expiring?"

What Happens

1. The agent lists open requests and asks which one to work on.
2. It validates the request against the developer's ember-project.yaml at the requested commit. It also reruns context lint and the secret scan on a fresh checkout. Failures go back to the developer through the issue.
3. It shows the plan: ten steps, each READY or BLOCKED, with the exact commands and resource names. Commands not yet confirmed against the provider are marked UNVERIFIED.
4. You confirm the run. A confirmation covers one run only.
5. It runs the READY steps in order and stops at the first failure. Every resource is recorded as soon as it exists, so a partial run can always be reversed.
6. Two steps need you:
   • creating the Render Blueprint instance in the dashboard
   • sending the invites, confirming each person's email with them directly
7. When everything is done, it comments on the issue and closes it. The developer then moves their project to the sandbox tier.

Teardown shows every live resource in reverse order. After you confirm, it removes them and marks the register torn-down.

What Is Blocked Today

Steps 3 to 10 report BLOCKED until these exist:

• the sandbox Supabase organization
• the Render workspace and the Vercel team identifiers
• the atl.com Cloudflare zone agreement and the Zero Trust plan
• the *.sandbox.tde.atl.com domain
• the sandbox Entra registration

Record each identifier in your operator config as it becomes available.

Setup

1. Copy config/sandbox.example.yaml to ~/.ember/sandbox-operator.yaml and fill in identifiers as they exist. Every value starts as MISSING.
2. Put tokens in environment variables, never in the file. The config names them: RENDER_API_KEY and CLOUDFLARE_API_TOKEN by default.
3. Sign in to gh, and to the Supabase and Vercel CLIs, as yourself.
4. Keep a clone of the Ember repository at ~/gitroot/ember. The register is written there.

What It Never Does

• Touch a production account. Stop if an identifier looks like production.
• Run a step without your confirmation. apply and teardown refuse without --confirm.
• Create anything outside the register, so teardown always knows what exists.
• Print, store, or pass tokens, passwords, connection strings, or emails. Secrets go straight into GitHub secrets over standard input.
• Grant more than least privilege: sandbox accounts only, Developer roles, and no Vercel team membership.

What It Changes

Run It Without an Agent

node ~/gitroot/ember-platform-skills/skills/ember-sandbox-provision/scripts/provision.mjs requests
node ~/gitroot/ember-platform-skills/skills/ember-sandbox-provision/scripts/provision.mjs plan <issue>
node ~/gitroot/ember-platform-skills/skills/ember-sandbox-provision/scripts/provision.mjs apply <issue> --confirm
node ~/gitroot/ember-platform-skills/skills/ember-sandbox-provision/scripts/provision.mjs teardown <slug>
node ~/gitroot/ember-platform-skills/skills/ember-sandbox-provision/scripts/provision.mjs expiring --days 30

Common Problems