Connection scope

Every integration connection is placed at one scope, which decides who can use it. A connection shared into a project or an organization is one credential the whole group's agents can act on; a user connection is private to the person who made it.

Which scopes a deployment offers

The ladder comes from two feature flags, read server-side, so a level a buyer turned off never appears in any picker.

project needs only the projects feature, because it partitions rather than shares: in an SEO product each project is a different client site with its own connection, which is as useful to a solo user as to a team. user is the floor - every deployment can keep a credential to the person who connected it.

Visibility

What a caller sees is the union for the workspace they are in: the active project's connections, the active organization's shared ones, and their own. That same union is what the agents get, so a shared connection is a shared tool.

• Losing context narrows, never widens. A request outside a project simply sees no project connections, never every project's.
• Scope is fixed at creation. To move a connection, disconnect and reconnect it.
• maxInstances counts per scope context, so a cap of 1 allows one in each project, one shared with the organization, and one of the user's own. The count runs inside the write, so a double-click cannot slip a second past the cap.
• A sign-in scopes like any other entry. An oauth connection carries its scope through the authorization flow, so it can be shared with a project or an organization exactly as a pasted key can.

Restricting an entry with allowedScopes

A catalog entry can keep itself off the levels it does not belong on. ["user"] makes an entry private however the request is shaped; ["project"] files each connection under one project. The list is intersected with the deployment's ladder, so it narrows and never widens.