Cloud accounts: an operator panel that holds every provider key sealed, read-only first, and shows what each read was for #378

Settings → Cloud accounts is in. It's admin-only and holds Cloudflare, DigitalOcean, AWS, Azure, Fly and Backblaze keys, sealed through the forge-level secrets table. tsc is clean and the new and neighbouring test files pass. I did not run the full forge.json check; I added test/cloud.test.ts and test/run-secrets.test.ts to it.

What it does

• Adding a key: pasting a credential makes the forge verify it with read-only calls (src/cloud/providers.ts, with the full call list in its header). The page shows one sentence on what the key can see. A key the provider rejects is not stored. Backblaze reports the key's own capabilities. Cloudflare, DigitalOcean, AWS, Azure and Fly don't expose scope, and the sentence says so.
• What the page shows: provider, name, last check, which run last opened the key, and a read-only/writes-allowed state, never a value. An "Every read" list shows each open as provider, name, run and time. The run page already lists the secrets a run held.
• Write switch: it is off by default. A run that adds writes: yes to its front-matter and declares a cloud key whose switch is off fails. The refusal appears in the run log and summary, and the key is never opened. This gates the forge's hand-out only. A provider key that can write still can, so paste read-only keys.
• Audit: it opens one [audit] issue per finding in a repository you name as owner/repo, with a monthly saving estimate. It skips findings that already have an open issue and changes nothing in the cloud account.
• Tests: they cover rejected keys, non-admin refusal, only GET requests, the audit issues, the write gate, the page, a cross-origin POST, AWS request signing, and the Backblaze host check.

Departures from the issue and what I left out

• Secret names: the table only takes capital names, so cloudflare/main is stored as CLOUD_CLOUDFLARE_MAIN.
• Multi-part keys: AWS, Azure and Backblaze keys are pasted as parts joined by : (for example KEY_ID:APPLICATION_KEY).
• Audit is not a crew run: it runs inside the forge, not as a crew run, so its reads show as audit:<provider>:<id> and verifies as verify:<provider>.
• Audit coverage: it finds unattached volumes, powered-off droplets, unassociated IPs and never-active Cloudflare zones. Over-provisioned droplets and forgotten DNS records need metrics or resolution, which I didn't attempt. AWS audits cover us-east-1 only, and Backblaze audits find nothing yet.
• Untested against real APIs: the Azure and Fly audits and the Fly GraphQL queries follow the providers' documented shapes but weren't run against the real services.
• No dependencies added.

To try it, sign in as an admin, open Settings → Cloud accounts, add a key, then press Verify or Audit.

🤖 Generated with Claude Code

Closes #340

I merged main into the branch and pushed it. The only conflict was the check.run test list in forge.json. I kept both sides' additions: test/cloud.test.ts and test/run-secrets.test.ts from this branch, and test/forge-cloudflare.test.ts from main.

tsc is clean, and test/cloud.test.ts, test/forge-cloudflare.test.ts and test/run-secrets.test.ts pass (21 tests). I did not run the full forge.json check locally; that runs on the push.

The pull itself is unchanged. It adds Settings → Cloud accounts, where an admin pastes a provider key. The forge verifies it read-only and seals it. It lists each read with the run that made it. A write switch, off by default, gates runs that declare writes: yes. A read-only audit files one issue per finding.

🤖 Generated with Claude Code