feat: add Orgo provider

[zozo123]

Summary

• Add the built-in Orgo delegated-run provider with config/env resolution, provider flags, lifecycle cleanup, list/status/stop/doctor, and secret-safe API-key handling.
• Add Orgo provider docs and generated provider-matrix metadata.
• Add Orgo coverage in the live smoke harness, including workspace create/delete, explicit workspace reuse, missing-key abort, auth-header checks, and no key leakage assertions.

Verification

• node --test scripts/live-smoke.test.js
• shellcheck -e SC2016 scripts/live-smoke.sh
• node scripts/check-provider-matrix.mjs
• bash scripts/check-docs.sh
• go vet ./...
• go test ./... (first aggregate hit existing flaky internal/cli test, focused rerun passed, second aggregate passed)
• go test -race ./... (first aggregate hit existing flaky internal/cli tests, focused rerun passed, second aggregate passed)
• go build -trimpath -o bin/crabbox ./cmd/crabbox
• Real bin/crabbox fake-Orgo-API e2e covering create workspace, create computer, bash command, delete computer, and delete workspace
• npm run format:check --prefix worker
• npm run lint --prefix worker
• npm run check --prefix worker
• npm test --prefix worker
• npm run build --prefix worker
• Autoreview clean: no accepted/actionable findings reported
• Committed secret-pattern guard: no sk_live_ pattern in HEAD

Secret/config notes

The Orgo API key is intentionally environment/config only and is not exposed as a CLI flag. I did not run the live Orgo smoke against a real pasted key; the live smoke is build/test ready, and local e2e used a fake API with a dummy key.

Refs #449

Authenticated account validation

Exact head 6709b303333df8d29ddd92c79fd4877bd8ba29d2 was rebuilt and retested after rebasing onto current main:

• doctor passed real Orgo authentication, control-plane, and inventory checks.
• list decoded the live /workspaces {"projects":[]} envelope and reported an empty account. This exposed and fixed the workspace-envelope compatibility bug with a regression test.
• Both API create and dashboard create reached the real service, then correctly stopped at the provider's paid-plan gate. The lowest displayed price is $29/month when billed yearly; no subscription or charge was created.
• Focused Go race tests, all 19 live-smoke harness tests, docs generation, and the exact PR binary build pass. GitHub CI is rerunning on the rebased head.

Full remote bash/delete lifecycle proof remains blocked on paid-plan authorization. This PR should not merge under the live-proof requirement until that temporary subscription is explicitly approved and the computer is deleted after validation.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed June 22, 2026, 5:05 AM ET / 09:05 UTC.

Summary
The PR adds a built-in Orgo delegated-run provider with config/env resolution, provider flags, lifecycle cleanup, list/status/stop/doctor behavior, provider docs, generated metadata, and smoke coverage.

Reproducibility: not applicable. this is a new-provider feature PR, not a broken existing behavior report. The relevant verification path is live Orgo provider proof, and complete hosted create/run/delete proof is still missing.

Review metrics: 2 noteworthy metrics.

• Diff surface: 20 files, +2656/-2. This is a full built-in provider addition, so provider registration, config, credentials, docs, and smoke coverage need to be reviewed together.
• Hosted lifecycle proof: partial auth/list proof, 0 complete hosted run/delete proofs. The PR body reports real account validation but says the core hosted bash/delete lifecycle remains blocked.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #449
Summary: This PR is the open implementation candidate for the linked Orgo provider feature request.

Members:

• canonical: Add support orgo as provider #449 - The issue is open, asks for Orgo provider support, and is referenced by this PR body.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🐚 platinum hermit
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Post redacted hosted Orgo proof for workspace creation, computer creation, bash execution, computer deletion, and workspace deletion.
• Remove the release-owned CHANGELOG.md entry.

Proof guidance:

• [P1] Needs stronger real behavior proof before merge: Partial authenticated-account checks are described, but the PR still needs redacted terminal/log/recording proof for the full hosted lifecycle; update the PR body after adding proof and request @clawsweeper re-review if needed.

Risk before merge

• [P1] The PR still lacks redacted hosted proof for the complete Orgo create workspace, create computer, bash execution, delete computer, and delete temporary workspace lifecycle; the body says that path is blocked by paid-plan authorization.
• [P1] Adding Orgo as a built-in credential-bearing provider is a product/security decision tied to Add support orgo as provider #449, not a purely mechanical code change.
• [P1] The release-owned CHANGELOG.md entry should be removed before merge so release notes remain owned by the release process.

Maintainer options:

1. Require hosted lifecycle proof (recommended)
   Ask for redacted terminal output, logs, or a recording showing real Orgo workspace creation, computer creation, bash execution, computer deletion, and temporary workspace deletion before merge.
2. Pause for provider direction
   Keep the PR paused behind Add support orgo as provider #449 until maintainers confirm Orgo should be accepted as a built-in credential-bearing provider.
3. Accept partial proof deliberately
   Maintainers could intentionally accept the paid-plan limitation, but that would own unproven hosted bash execution and cleanup behavior for a new credentialed provider.

Next step before merge

• [P1] Maintainer product/security review and contributor live proof are required; automation cannot approve a paid Orgo subscription or produce the contributor's hosted service proof.

Security
Cleared: No concrete diff-level credential leak was found; the remaining security concern is maintainer approval and complete proof for a new credential-bearing provider.

Review findings

• [P3] Remove the release-owned changelog entry — CHANGELOG.md:8

Review details

Best possible solution:

Land Orgo only after maintainers confirm the built-in provider direction, the release-owned changelog edit is removed, and the PR includes redacted live hosted create/run/delete proof.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a new-provider feature PR, not a broken existing behavior report. The relevant verification path is live Orgo provider proof, and complete hosted create/run/delete proof is still missing.

Is this the best way to solve the issue?

Unclear: the adapter follows Crabbox's delegated-run and credential-provenance patterns, but the built-in provider direction and final hosted service contract still need maintainer confirmation.

Full review comments:

• [P3] Remove the release-owned changelog entry — CHANGELOG.md:8
  Please remove this CHANGELOG.md addition from the feature PR. Repository release-note policy keeps changelog edits owned by release preparation; the PR body and commits already provide the needed release context.
  Confidence: 0.88

Overall correctness: patch is correct
Overall confidence: 0.78

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against f57d12b03d1f.

Label changes

Label justifications:

• P2: This is a normal-priority provider feature PR with meaningful proof and maintainer-review gates, not a shipped regression or emergency.
• merge-risk: 🚨 security-boundary: The diff adds a new Bearer-token HTTP provider and credential-destination handling whose hosted behavior needs maintainer/security confidence before merge.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: Partial authenticated-account checks are described, but the PR still needs redacted terminal/log/recording proof for the full hosted lifecycle; update the PR body after adding proof and request @clawsweeper re-review if needed.

Evidence reviewed

What I checked:

• AGENTS.md policy read: Repository policy was read fully and applied to the provider-boundary, generic positioning, testing, and secret-handling review checks. (AGENTS.md:1, f57d12b03d1f)
• Current main lacks Orgo support: A current-main search for Orgo provider names and environment variables returned no matches, so the PR is not obsolete or already implemented on main. (f57d12b03d1f)
• Provider implementation on PR head: The PR registers provider name orgo, alias orgo-ai, delegated-run kind, Linux target, cleanup feature, and coordinator-never routing behind a provider adapter. (internal/providers/orgo/provider.go:19, 6709b303333d)
• Credential boundary present: The PR tracks Orgo API-base and API-key provenance and rejects repository-selected orgo.apiBase when paired with inherited Orgo credentials. (internal/cli/credential_provenance.go:250, 6709b303333d)
• Partial live proof only: The PR body reports authenticated doctor/list checks and a paid-plan gate, but explicitly says full remote bash/delete lifecycle proof remains blocked by paid-plan authorization. (6709b303333d)
• Canonical related issue: The linked Orgo provider request is still open and marked as needing product/maintainer review, so the PR should remain paired with it until maintainers decide the built-in provider direction.

Likely related people:

• steipete: Current-main history ties this handle to credential provenance and provider hardening, and this PR's later commits repair Orgo credential boundaries, cleanup, smoke-token handling, bash exit handling, proof redaction, and live envelope decoding. (role: recent credential-boundary and provider-security area contributor; confidence: high; commits: 966e99599db4, 8ae979ffd42b, aaaa544606d8; files: internal/cli/credential_provenance.go, scripts/live-smoke.sh, internal/providers/orgo/backend.go)
• zozo123: This handle has merged current-main provider work in adjacent config, docs, and delegated-provider surfaces, and authored the original Orgo provider commits in this PR. (role: prior provider implementation contributor; confidence: high; commits: e079b3dde742, 3b92643ab361, 7575c39aa3ff; files: internal/providers/fastapicloud, internal/providers/opencomputer, internal/cli/config.go)
• Vincent Koc: Recent current-main commits touched provider selection documentation and provider capability exposure adjacent to the generated provider table and delegated-run evidence surfaces. (role: recent provider-docs and capability contributor; confidence: medium; commits: 0d947a568557, 12c3d359b57f, 056f1f57abc0; files: docs/providers/README.md, internal/cli)
• Coy Geek: Current-main history includes several recent provider additions by this author, making them relevant for built-in provider review patterns. (role: adjacent provider implementation contributor; confidence: medium; commits: aff04c9f19a3, 527b93b0b0bb, 159da078de76; files: internal/providers, docs/providers)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.