feat(edition): Tier 1 ungating

[marcorivm]

Removes the upsell/lock gating from features the open edition ships unlocked. 23 files, +73/−442 — almost entirely deletions.

Smallest PR in the stack and the place to start: it establishes the edition model everything above depends on.

• Drops team-badge.tsx, adds unavailable-badge.tsx
• Un-gates the condition builder, identity picker, resource scope, app select/target fields
• De-upsells the connect flow, get-started dialog, connections tab, credentials dialog

Stack

Split out of the original 381-file #8. Upstream catch-up (v1.42.0 → v1.44.0) already landed as #10, so main is now v1.44.0 and everything below is our own code.

main (v1.44.0, after #10)
 └─ #14  01-tier1-ungating              23 files    +73/-442
     └─ #11  02-org-members-rbac        47 files  +5298/-36
         └─ #12  03-user-groups         16 files  +2963/-1
             └─ #13  04-project-access  33 files  +7701/-234
                 └─ #15  05-gateway-org-scope       6 files  +1080/-176
                     └─ #16  06-gateway-conditions  23 files  +2292/-211
                         └─ #17  07-gateway-resource-scope  13 files  +1551/-20
                             └─ #18  08-web-org-policy      23 files  +2421/-384
                                 └─ #8   spend budgets      20 files  +2523/-35
                                     └─ #9   upstream-sync tooling  8 files  +823/-0

Review and merge in order, top to bottom. Roughly half of each diff is tests.

[marcorivm]

What it actually does

Removes paywalls from the OSS build's UI and API:

• The "Team" pill and the "Try OneCLI Cloud" upsell dialog (pro-app-dialog.tsx) no longer point at the hosted product — locked apps show a neutral "Unavailable" badge instead of a branded "Team" badge with a sales CTA.
• Inline marketing links to app.onecli.sh are deleted or replaced with plain "not available in this build" copy.
• getCurrentPlan() returns "enterprise" unconditionally instead of null, so plan-gated UI sees the org as fully entitled.
• Most importantly: the server-side ossPolicyValidator (packages/api/src/services/policy-oss-locks.ts) is deleted outright, along with its wiring in apps/web/src/lib/init/api.ts.

Why it exists / what "ungating" means here

Upstream's OSS edition locks two things that have nothing to do with actual capability:

1. UI gates — badges/dialogs/links that exist only to upsell Cloud.
2. A server-side validator that actively rejected requests. ossPolicyValidator.validate() threw a 422 ("Granular resource scoping … is available on OneCLI Cloud") for any policy rule with {repositories}/{folders} scoping, and validateTargets() threw a 422 for any rule targeting a cloud-only provider (the available: false EE stubs in ee-app-registry.ts, e.g. aws-role, datadog).

The locking mechanism was that validator, wired only through the OSS init seam (eeOverrides.policyValidator); every EE edition aliases the file away and never sees it. Removing the wiring means the provider-hook default (permissive) now applies to OSS, so those requests are silently accepted rather than rejected.

Reading order

1. packages/api/src/services/policy-oss-locks.ts — deleted; read it from the diff first so you know what's now missing.
2. apps/web/src/lib/init/api.ts — the seam. Note the new comment: "No policyValidator is wired: the provider-hook default is permissive… The gateway does not yet ENFORCE resource scoping — see Tier 3." The PR admits the gap in its own comment.
3. packages/api/src/services/policy-service.ts (assertIdentitiesValid, assertTargetsValid docstring) — same acknowledgment at the two call sites the validator guarded.
4. packages/api/src/apps/connect-credentials.ts (resolveConnectCredentials, ~line 70) — unchanged except a string, and it's what bounds the blast radius: actually connecting a cloud-only provider is still blocked.
5. apps/web/src/lib/user-plan.tsx — trivial; getCurrentPlan → "enterprise".
6. Everything else (apps-tab.tsx, pro-app-dialog.tsx, unavailable-badge.tsx, team-badge.tsx deletion, condition-builder.tsx, resource-scope.tsx, identity-picker.tsx) is mechanical copy/badge swapping — skim.

What to scrutinise

The deleted validator, not the UI. The old code's own comment said it plainly: "Without this lock OSS would accept-and-store {repositories}/{folders} that its gateway never enforces — false security, worse than absence." That is exactly the new state. A user can build a rule scoping a GitHub connection to specific repos, the API accepts and stores it, the UI renders it as if enforced, and the gateway ignores the scope. Confirm this window is deliberately accepted until Tier 3 (PR #17, granular resource scoping, further up this stack) lands, and that resource-scope.tsx still visibly says the field isn't enforced in this build.

validateTargets removal looks safe: a rule can now target e.g. aws-role, but no OSS flow can mint such a connection (connect-credentials.ts still blocks it), so the rule is dead rather than dangerous. Worth independently confirming no other path mints an EE-provider connection (import/seed scripts, admin tooling).

Design decisions worth questioning

• Silently downgrading a hard 422 into accept-with-no-enforcement, gated only by a code comment pointing at future work, is a debatable sequencing choice. A softer lock (accept but mark "not enforced" in the UI) was available.
• teamOnly gating logic was deleted from apps-tab.tsx even though nothing currently sets teamOnly: true — fine as dead-code cleanup, but it removes a hook future EE work might want.

Test coverage reality

The two deleted test files (policy-oss-locks.test.ts, policy-flags.test.ts) covered exactly the removed behaviour, and there is no replacement test asserting "OSS now accepts resource-scoped rules and cloud-only app targets." Arguably correct — permissive is permissive — but it means no regression tripwire if enforcement is ever re-added and this seam is forgotten. Nothing anywhere exercises the actual gap (stored-but-unenforced scope) end to end; that's a Tier 3 concern and doesn't exist yet.

---

_{Reviewer orientation guide — produced by analysing this PR's diff and surrounding code, not the commit messages. Claims about line numbers and behaviour are worth spot-checking as you read; where it says something is untested or risky, that was verified against the tree rather than inferred.}