feat(setup): publish standalone self-hosting package (#6849)

* feat(setup): publish standalone self-hosting package

* fix(setup): refresh discovered compose installs

* improvement(setup): unify repository command

* fix(setup): harden standalone package launch

* Update README.md

* fix(setup): isolate standalone compose installs

* fix(setup): restore default stopped installs

Author: TheodoreSpeaks

.agents/skills/add-block/SKILL.md

@@ -172,8 +172,8 @@ Optional companions: `credentialLabels` (override the picker's section/connect-r
 ### OAuth deployment availability (required for integration blocks)
 
 A visible tools-category block with OAuth is deployment-gated. Its `oauth-input.serviceId` is
-projected into `apps/sim/lib/integrations/integrations.json`, then resolved through
-`resolveOAuthClientCapabilityId()` in `apps/sim/lib/core/config/env-capabilities.ts`.
+projected into `packages/deployment-config/src/integrations.json`, then resolved through
+`resolveOAuthClientCapabilityId()` in `packages/deployment-config/src/env-capabilities.ts`.
 
 When adding or changing an OAuth integration block:
 
@@ -184,13 +184,14 @@ When adding or changing an OAuth integration block:
 3. For a new capability, add its required client fields to `OAUTH_CLIENT_CAPABILITIES` and ensure
    every referenced field exists in the env schema in `apps/sim/lib/core/config/env.ts`. Then add
    the matching `text` or `secret` input modes to `OAUTH_CLIENT_SETUP_FIELDS` in
-   `scripts/setup/capability-config.ts`. The CLI catalog is exhaustively typed and checked against
-   the runtime field list; do not infer secrecy from the field name.
-4. If the canonical OAuth service declares `serviceAccountProviderId`, keep
-   `SERVICE_ACCOUNT_METADATA_BY_OAUTH_SERVICE_ID` in
-   `apps/sim/lib/integrations/service-account-metadata.ts` aligned. Set
-   `deploymentRequirement` only when the service-account path is preview-gated or depends on the
-   OAuth client fields; otherwise omit it.
+   `packages/sim-setup/src/capability-config.ts`. The CLI catalog is exhaustively typed and checked
+   against the runtime field list; do not infer secrecy from the field name.
+4. If the canonical OAuth service declares `serviceAccountProviderId`, run
+   `bun run deployment-config:generate`; this regenerates the provider-ID facts in
+   `packages/deployment-config/src/service-account-providers.generated.ts`. Never hand-edit that
+   generated map. Add `deploymentRequirement` policy in
+   `packages/deployment-config/src/service-account-metadata.ts` only when the service-account path
+   is preview-gated or depends on the OAuth client fields; otherwise omit it.
 
 Missing capability metadata is a runtime configuration error, not a reason to make the integration
 silently available.
@@ -992,16 +993,21 @@ After adding or changing one, run:
 
 ```bash
 bun run scripts/generate-docs.ts
+bun run deployment-config:generate
 bun run integration-catalog:check
+bun run deployment-config:check
 bun run docs:check
 ```
 
 The catalog check independently derives deployment metadata from the executable block registry and
-compares it with the committed `apps/sim/lib/integrations/integrations.json`. `docs:check` re-renders
-every generated docs artifact in memory and fails on any committed file that differs — it runs in CI
-via `check:audits`, so commit the full generator output. If the generator also trues up pages an
-earlier PR left stale, commit that catch-up too; reverting it as "unrelated drift" makes `docs:check`
-fail.
+compares it with the committed `packages/deployment-config/src/integrations.json`. The deployment
+config check verifies the generated service-account facts against the canonical OAuth registry and
+catalog. `docs:check` re-renders every generated docs artifact in memory and fails on any committed
+file that differs — it runs in CI via `check:audits`, so commit the full generator output. If the
+generator also trues up pages an earlier PR left stale, commit that catch-up too; reverting it as
+"unrelated drift" makes `docs:check` fail. Review the generated diff and keep only intentional
+changes.
+
 ## Checklist Before Finishing
 
 - [ ] `integrationType` is set to the correct `IntegrationType` enum value

.agents/skills/add-integration/SKILL.md

@@ -538,16 +538,18 @@ the OAuth service configuration, deployment availability, and the setup CLI.
 1. Ensure the block has exactly one distinct OAuth `serviceId` and that it matches the canonical
    service entry in `apps/sim/lib/oauth/oauth.ts`.
 2. Confirm `resolveOAuthClientCapabilityId(serviceId)` resolves to the intended provider entry in
-   `OAUTH_CLIENT_CAPABILITIES` in `apps/sim/lib/core/config/env-capabilities.ts`. Google and
+   `OAUTH_CLIENT_CAPABILITIES` in `packages/deployment-config/src/env-capabilities.ts`. Google and
    Microsoft service IDs deliberately share provider-level capabilities.
 3. For a new OAuth provider, add the required client fields to `OAUTH_CLIENT_CAPABILITIES`, add
    every referenced field to the env schema in `apps/sim/lib/core/config/env.ts`, and add the
    matching `text` or `secret` entries to `OAUTH_CLIENT_SETUP_FIELDS` in
-   `scripts/setup/capability-config.ts`. Do not create integration-specific setup logic or infer
-   secret fields from naming; the CLI mapping is exhaustively checked against the runtime fields.
-4. If the canonical OAuth service has `serviceAccountProviderId`, add the matching projection to
-   `SERVICE_ACCOUNT_METADATA_BY_OAUTH_SERVICE_ID` in
-   `apps/sim/lib/integrations/service-account-metadata.ts`. Use:
+   `packages/sim-setup/src/capability-config.ts`. Do not create integration-specific setup logic or
+   infer secret fields from naming; the CLI mapping is exhaustively checked against the runtime
+   fields.
+4. If the canonical OAuth service has `serviceAccountProviderId`, run
+   `bun run deployment-config:generate` to refresh
+   `packages/deployment-config/src/service-account-providers.generated.ts`; never hand-edit the
+   generated provider-ID map. In `packages/deployment-config/src/service-account-metadata.ts`, use:
    - no `deploymentRequirement` when the service-account path works independently of OAuth client fields;
    - `'oauth-client'` when it requires the same deployment OAuth client fields;
    - `'preview-gated'` when availability is controlled by the service-account preview block.
@@ -560,15 +562,18 @@ a resolvable capability must fail validation.
 Run the documentation generator:
 ```bash
 bun run scripts/generate-docs.ts
+bun run deployment-config:generate
 bun run integration-catalog:check
+bun run deployment-config:check
 bun run docs:check
 ```
 
 This creates `apps/docs/content/docs/en/integrations/{service}.mdx` — one page per service carrying the block's Actions and, if it has one, its Triggers section. Never hand-edit generated pages; the only editable region is the `{/* MANUAL-CONTENT */}` block (see `scripts/README.md`).
 
-The same generator refreshes `apps/sim/lib/integrations/integrations.json`. The catalog check then
-derives the deployment-relevant fields from the executable block registry and compares them with the
-committed projection. Review the generated diff and keep only intentional changes.
+The docs generator refreshes `packages/deployment-config/src/integrations.json`, and the deployment
+config generator projects service-account provider IDs from that catalog plus the canonical OAuth
+registry. The checks compare both committed projections with their sources. Review the generated
+diff and keep only intentional changes.
 
 ## V2 Integration Pattern
 
@@ -647,14 +652,16 @@ If creating V2 versions (API-aligned outputs):
 - [ ] Created `index.ts` barrel export
 - [ ] Registered all triggers in `triggers/registry.ts`
 
-### Docs
+### Docs and deployment metadata
 - [ ] Ran `bun run scripts/generate-docs.ts`
+- [ ] Ran `bun run deployment-config:generate` for OAuth or service-account changes
 - [ ] Verified docs file created
-- [ ] Reviewed and committed the generated `apps/sim/lib/integrations/integrations.json` change
+- [ ] Reviewed and committed the generated `packages/deployment-config/src/integrations.json` change
 - [ ] `bun run integration-catalog:check` passes
 - [ ] `bun run docs:check` passes — CI fails on stale generated docs, so commit the full generator
       output, including catch-up regeneration for pages another PR left stale (never revert it as
       "unrelated drift")
+- [ ] `bun run deployment-config:check` passes
 
 ### Final Validation (Required)
 - [ ] Read every tool file and cross-referenced inputs/outputs against the API docs
@@ -1002,4 +1009,4 @@ requiredScopes: getScopesForService('{service}'),
 11. **Never hardcode scopes** - Use `getScopesForService()` in blocks and `getCanonicalScopesForProvider()` in auth.ts
 12. **Always add scope descriptions** - New scopes must have entries in `SCOPE_DESCRIPTIONS` within `lib/oauth/utils.ts`
 13. **OAuth service IDs need deployment capabilities** - Every visible OAuth integration must resolve through `OAUTH_CLIENT_CAPABILITIES`; shared Google/Microsoft aliases map to their provider capability
-14. **Keep runtime and presentation separate** - Runtime OAuth fields live in `env-capabilities.ts`; CLI input modes live in the exhaustively checked `scripts/setup/capability-config.ts` mapping
+14. **Keep runtime and presentation separate** - Runtime OAuth fields live in `packages/deployment-config/src/env-capabilities.ts`; CLI input modes live in the exhaustively checked `packages/sim-setup/src/capability-config.ts` mapping

.agents/skills/validate-integration/SKILL.md

@@ -29,12 +29,13 @@ apps/sim/blocks/registry-maps.ts    # Block + meta registry entry (BLOCK_REGISTR
 apps/sim/components/icons.tsx        # Icon definition
 apps/sim/lib/auth/auth.ts           # OAuth config — should use getCanonicalScopesForProvider()
 apps/sim/lib/oauth/oauth.ts         # OAuth provider config — single source of truth for scopes
-apps/sim/lib/oauth/utils.ts               # Scope utilities, SCOPE_DESCRIPTIONS for modal UI
-apps/sim/lib/core/config/env-capabilities.ts # OAuth client runtime capability source of truth
+apps/sim/lib/oauth/utils.ts         # Scope utilities, SCOPE_DESCRIPTIONS for modal UI
+packages/deployment-config/src/env-capabilities.ts # OAuth client runtime capability source of truth
 apps/sim/lib/core/config/env.ts     # Runtime env schema for capability fields
-scripts/setup/capability-config.ts  # Exhaustive CLI input-mode mapping for OAuth fields
-apps/sim/lib/integrations/integrations.json # Generated client-safe integration catalog
-apps/sim/lib/integrations/service-account-metadata.ts # Lightweight service-account projection
+packages/sim-setup/src/capability-config.ts # Exhaustive CLI input-mode mapping for OAuth fields
+packages/deployment-config/src/integrations.json # Generated client-safe integration catalog
+packages/deployment-config/src/service-account-providers.generated.ts # Generated provider-ID facts
+packages/deployment-config/src/service-account-metadata.ts # Handwritten deployment policy
 ```
 
 ## Step 2: Pull API Documentation
@@ -291,17 +292,17 @@ Scopes are centralized — the single source of truth is `OAUTH_PROVIDERS` in `l
 ## Step 6: Validate Deployment Availability (if OAuth service)
 
 The deployment UI and setup CLI do not infer OAuth client fields from scopes. They resolve the
-block's generated `oauthServiceId` through the application-owned capability catalog.
+block's generated `oauthServiceId` through the shared deployment capability catalog.
 
 - [ ] The visible integration block has exactly one distinct `oauth-input.serviceId`
 - [ ] `resolveOAuthClientCapabilityId(serviceId)` returns the intended provider capability
 - [ ] The resolved provider exists in `OAUTH_CLIENT_CAPABILITIES`
 - [ ] Every field listed by that capability exists in `apps/sim/lib/core/config/env.ts`
 - [ ] Every capability field has the correct `text` or `secret` entry in `OAUTH_CLIENT_SETUP_FIELDS`; no CLI naming heuristic is required
 - [ ] Shared Google/Microsoft service IDs resolve to their provider capability rather than duplicate entries
-- [ ] `bun run setup integration <capabilityId>` is the command emitted by availability; the CLI has only the exhaustive input-mode projection, not a second runtime provider definition
+- [ ] `npx @sim/setup add integration <capabilityId>` is the command emitted by availability; the CLI has only the exhaustive input-mode projection, not a second runtime provider definition
 - [ ] If the canonical OAuth service declares `serviceAccountProviderId`,
-      `SERVICE_ACCOUNT_METADATA_BY_OAUTH_SERVICE_ID[serviceId]` has the same provider ID
+      the generated `SERVICE_ACCOUNT_PROVIDER_BY_OAUTH_SERVICE_ID[serviceId]` has the same provider ID
 - [ ] The service-account `deploymentRequirement` matches how that credential actually works:
       omitted for an independent path, `'oauth-client'` when it needs the OAuth client fields, or
       `'preview-gated'` when controlled by a preview block
@@ -386,13 +387,16 @@ Several files are generated from tool and block definitions. Editing a tool or b
 
 ```bash
 bun run tool-metadata:generate       # repo root — apps/sim/tools/generated/*
-bun run scripts/generate-docs.ts     # docs .mdx + lib/integrations/integrations.json + docs icons
+bun run scripts/generate-docs.ts     # docs .mdx + deployment-config/integrations.json + docs icons
+bun run deployment-config:generate  # canonical OAuth registry + catalog → provider-ID facts
 bun run integration-catalog:check    # registry ↔ committed deployment metadata drift
 bun run docs:check                   # committed docs ↔ what the generator renders today
+bun run deployment-config:check     # OAuth registry/catalog ↔ provider-ID fact drift
 ```
 
 - **`tool-metadata:generate`** — required whenever a tool's `outputs`, `params`, or descriptions change. CI enforces this with `bun run tool-metadata:check`, which fails with *"Generated tool metadata is stale"*. This is the easiest gate to miss, because nothing in the tool file hints that a generated artifact mirrors it.
-- **`generate-docs`** — required whenever block metadata changes (`bgColor`, `name`, `description`, operations, outputs). Regenerates the integration `.mdx`, `integrations.json`, and the docs copy of `components/icons.tsx`.
+- **`generate-docs`** — required whenever block metadata changes (`bgColor`, `name`, `description`, operations, outputs). Regenerates the integration `.mdx`, `packages/deployment-config/src/integrations.json`, and the docs copy of `components/icons.tsx`.
+- **`deployment-config:generate`** — required for OAuth or service-account changes. Regenerates provider-ID facts from the canonical OAuth registry and integration catalog; special deployment requirements remain handwritten policy.
 - **`integration-catalog:check`** — loads the executable block registry, derives visible integration
   deployment fields, and compares them with the committed catalog. It catches missing/unexpected
   entries and stale auth/service IDs without loading the executable registry in client code.
@@ -419,9 +423,10 @@ After fixing, confirm:
 4. Derived artifacts regenerated and their diffs reviewed (see above)
 5. `bun run integration-catalog:check` passes
 6. `bun run docs:check` passes
-7. For OAuth or service-account changes, `bun test apps/sim/lib/integrations/availability.server.test.ts` passes
-8. Re-read all modified files to verify fixes are correct
-9. Any remaining unknown response schemas were explicitly reported to the user instead of guessed
+7. For OAuth or service-account changes, `bun run deployment-config:check` passes
+8. For OAuth or service-account changes, `bun run --cwd apps/sim test lib/integrations/availability.server.test.ts` passes
+9. Re-read all modified files to verify fixes are correct
+10. Any remaining unknown response schemas were explicitly reported to the user instead of guessed
 
 ## Checklist Summary
 
@@ -437,7 +442,7 @@ After fixing, confirm:
 - [ ] Validated scope descriptions exist in `SCOPE_DESCRIPTIONS` within `lib/oauth/utils.ts` for all scopes
 - [ ] Validated OAuth `serviceId` resolves to the intended `OAUTH_CLIENT_CAPABILITIES` entry and all capability fields exist in the env schema
 - [ ] Validated service-account projection and deployment requirement against the canonical OAuth service config
-- [ ] Regenerated `integrations.json` when block metadata changed and ran `bun run integration-catalog:check`
+- [ ] Regenerated deployment config when block/OAuth metadata changed and ran both catalog checks
 - [ ] Validated pagination consistency across tools and block
 - [ ] Validated memory load safety using `.agents/skills/memory-load-check/SKILL.md` when tools list/search/download/import/export/batch data
 - [ ] Validated error handling (error checks, meaningful messages)