@codeam/shared 2.61.30 → 2.61.32

package/dist/index.d.mts

@@ -351,7 +351,7 @@ declare function isHeadroomWrappable(agentId: string): boolean;
  * ubiquitous CLI for the tool → `cliEnv`; otherwise → `mcp`. A tool may
  * declare both.
  */
-type IntegrationId = 'jira' | 'sentry' | 'linear' | 'slack' | 'notion' | 'azure_devops' | 'figma' | 'microsoft_teams' | 'google_chat' | 'discord' | 'github_issues';
+type IntegrationId = 'jira' | 'sentry' | 'linear' | 'slack' | 'notion' | 'azure_devops' | 'figma' | 'microsoft_teams' | 'google_chat' | 'discord' | 'github_issues' | 'github' | 'gitlab';
 /**
  * `derived` = no link flow of its own: the credential is BORROWED live from a
  * connection the user already made elsewhere (see `derivedFrom`). The backend
@@ -359,18 +359,28 @@ type IntegrationId = 'jira' | 'sentry' | 'linear' | 'slack' | 'notion' | 'azure_
  * there is exactly one source of truth. Such an integration is "linked" iff its
  * source connection exists, and has no Connect/Disconnect action of its own.
  */
-type IntegrationAuthKind = 'oauth_redirect' | 'oauth_device' | 'api_key' | 'derived';
 /**
- * The external connection a `derived` integration borrows its credential from.
- * Deliberately NOT an `IntegrationId` — these connections are owned OUTSIDE the
- * toolkit registry (GitHub's OAuth belongs to the codespaces/VCS rail, which is
- * why `'github'` is not a linkable toolkit id).
+ * `connection` = the integration IS a standing connection whose credential lives
+ * in a `ProviderToken` row rather than the integrations vault, and whose
+ * connect/disconnect flow is owned by ANOTHER module (GitHub's OAuth belongs to
+ * the codespaces rail). It renders and acts like any other connector — the only
+ * difference is which code performs the link.
+ *
+ * Contrast `derived`, which BORROWS such a connection and owns no actions at
+ * all. Both resolve their credential from the same place; only `derived` has no
+ * link flow of its own.
+ */
+type IntegrationAuthKind = 'oauth_redirect' | 'oauth_device' | 'api_key' | 'derived' | 'connection';
+/**
+ * A standing connection whose credential lives in a `ProviderToken` row — either
+ * because the integration IS that connection (`kind: 'connection'`) or because
+ * it borrows it (`kind: 'derived'`). Its own id doubles as the source name.
  */
 type DerivedCredentialSource = 'github';
 /** Grouping used by category-driven surfaces (Start-from-Work-Item picker,
  *  catalog sections). A future tracker integration joins those features with
  *  ZERO feature code — they resolve sources from the registry by category. */
-type IntegrationCategory = 'tracker' | 'design' | 'comms' | 'docs' | 'observability';
+type IntegrationCategory = 'version_control' | 'tracker' | 'design' | 'comms' | 'docs' | 'observability';
 /**
  * One user-entered field for an `api_key` integration (no browser OAuth — the
  * user pastes credentials directly, e.g. a PAT + an org URL). The mobile form
@@ -420,6 +430,11 @@ interface IntegrationDefinition {
          *  Drives both the backend's credential resolution and the client's
          *  "no connect action, managed by <source>" rendering. */
         derivedFrom?: DerivedCredentialSource;
+        /** For `kind: 'connection'` — the connection this integration IS. Same
+         *  credential lookup as `derivedFrom`, but this one owns its link flow
+         *  (performed by the module that owns the connection, not by the generic
+         *  integrations OAuth path). */
+        connection?: DerivedCredentialSource;
     };
     delivery: IntegrationDelivery;
 }

package/dist/index.d.ts

@@ -351,7 +351,7 @@ declare function isHeadroomWrappable(agentId: string): boolean;
  * ubiquitous CLI for the tool → `cliEnv`; otherwise → `mcp`. A tool may
  * declare both.
  */
-type IntegrationId = 'jira' | 'sentry' | 'linear' | 'slack' | 'notion' | 'azure_devops' | 'figma' | 'microsoft_teams' | 'google_chat' | 'discord' | 'github_issues';
+type IntegrationId = 'jira' | 'sentry' | 'linear' | 'slack' | 'notion' | 'azure_devops' | 'figma' | 'microsoft_teams' | 'google_chat' | 'discord' | 'github_issues' | 'github' | 'gitlab';
 /**
  * `derived` = no link flow of its own: the credential is BORROWED live from a
  * connection the user already made elsewhere (see `derivedFrom`). The backend
@@ -359,18 +359,28 @@ type IntegrationId = 'jira' | 'sentry' | 'linear' | 'slack' | 'notion' | 'azure_
  * there is exactly one source of truth. Such an integration is "linked" iff its
  * source connection exists, and has no Connect/Disconnect action of its own.
  */
-type IntegrationAuthKind = 'oauth_redirect' | 'oauth_device' | 'api_key' | 'derived';
 /**
- * The external connection a `derived` integration borrows its credential from.
- * Deliberately NOT an `IntegrationId` — these connections are owned OUTSIDE the
- * toolkit registry (GitHub's OAuth belongs to the codespaces/VCS rail, which is
- * why `'github'` is not a linkable toolkit id).
+ * `connection` = the integration IS a standing connection whose credential lives
+ * in a `ProviderToken` row rather than the integrations vault, and whose
+ * connect/disconnect flow is owned by ANOTHER module (GitHub's OAuth belongs to
+ * the codespaces rail). It renders and acts like any other connector — the only
+ * difference is which code performs the link.
+ *
+ * Contrast `derived`, which BORROWS such a connection and owns no actions at
+ * all. Both resolve their credential from the same place; only `derived` has no
+ * link flow of its own.
+ */
+type IntegrationAuthKind = 'oauth_redirect' | 'oauth_device' | 'api_key' | 'derived' | 'connection';
+/**
+ * A standing connection whose credential lives in a `ProviderToken` row — either
+ * because the integration IS that connection (`kind: 'connection'`) or because
+ * it borrows it (`kind: 'derived'`). Its own id doubles as the source name.
  */
 type DerivedCredentialSource = 'github';
 /** Grouping used by category-driven surfaces (Start-from-Work-Item picker,
  *  catalog sections). A future tracker integration joins those features with
  *  ZERO feature code — they resolve sources from the registry by category. */
-type IntegrationCategory = 'tracker' | 'design' | 'comms' | 'docs' | 'observability';
+type IntegrationCategory = 'version_control' | 'tracker' | 'design' | 'comms' | 'docs' | 'observability';
 /**
  * One user-entered field for an `api_key` integration (no browser OAuth — the
  * user pastes credentials directly, e.g. a PAT + an org URL). The mobile form
@@ -420,6 +430,11 @@ interface IntegrationDefinition {
          *  Drives both the backend's credential resolution and the client's
          *  "no connect action, managed by <source>" rendering. */
         derivedFrom?: DerivedCredentialSource;
+        /** For `kind: 'connection'` — the connection this integration IS. Same
+         *  credential lookup as `derivedFrom`, but this one owns its link flow
+         *  (performed by the module that owns the connection, not by the generic
+         *  integrations OAuth path). */
+        connection?: DerivedCredentialSource;
     };
     delivery: IntegrationDelivery;
 }

package/dist/index.js

@@ -672,6 +672,60 @@ var INTEGRATION_REGISTRY = {
       }
     }
   },
+  github: {
+    id: "github",
+    name: "GitHub",
+    icon: "github",
+    category: "version_control",
+    // LIVE. GitHub is the product's code substrate (codespaces + the PR
+    // Command Center), and it was historically the ONE connection outside this
+    // registry: its credential lives in a `ProviderToken` row rather than the
+    // integrations vault, so it was rendered by a hand-written special-case row
+    // and could not legally appear in a deploy's `integrationIds` (the manifest
+    // resolver rejects unknown ids — a recurring bug class).
+    //
+    // `kind: 'connection'` closes that gap without re-plumbing OAuth: the entry
+    // makes GitHub a first-class, categorised catalog row whose credential the
+    // backend resolves from the SAME `ProviderToken` it always used, while the
+    // connect/disconnect flow stays owned by the codespaces rail (the clients
+    // route those two actions there). ⚠️ It is a REAL connection with a REAL
+    // disconnect — do NOT treat it like `github_issues`, which merely derives
+    // from it and has no actions of its own.
+    enabled: true,
+    auth: { kind: "connection", connection: "github" },
+    // No MCP: a deployed box already has an authenticated `gh` on PATH.
+    delivery: {}
+  },
+  gitlab: {
+    id: "gitlab",
+    name: "GitLab",
+    icon: "gitlab",
+    category: "version_control",
+    // LIVE — a user-owned gitlab.com application (Confidential) with BOTH env
+    // callbacks registered, so dev/prod share the client and differ only in
+    // GITLAB_OAUTH_REDIRECT_URI. The backend GitLabOAuthProvider is
+    // config-gated (503 if env unset), so this is safe mid-rollout.
+    //
+    // ⚠️ Unlike `github`, this is a NORMAL `oauth_redirect` integration: its
+    // credential is vaulted here rather than living in a ProviderToken, because
+    // nothing else in the product owns a GitLab connection (GitHub's lives on
+    // the codespaces rail, which is why it's `kind: 'connection'`).
+    enabled: true,
+    auth: {
+      kind: "oauth_redirect",
+      // GitLab has NO per-resource scopes — `api` is the only one that grants
+      // merge-request WRITE (comment / approve / merge / close), so a
+      // read-only alternative would make the whole MR surface useless.
+      // `write_repository` is the git-over-HTTPS rail for the agent's push;
+      // `api` already covers it for user tokens, but it costs nothing on a
+      // consent screen that already says "complete read/write access" and
+      // changing scopes later forces EVERY user to re-authorize.
+      scopes: ["api", "write_repository"]
+    },
+    // No MCP: the box's `git` is authenticated for push, and the MR surface is
+    // served backend-side by the VCS provider — same shape as `github`.
+    delivery: {}
+  },
   github_issues: {
     id: "github_issues",
     name: "GitHub Issues",
@@ -932,10 +986,22 @@ function getIntegrationsByCategory(category) {
 
 // src/integrations/branding.ts
 var INTEGRATION_BRANDING = {
-  // GitHub — a brand-only entry (NOT an `IntegrationId`; v1 reuses the
-  // codespaces OAuth token rather than exposing GitHub as a linkable toolkit).
-  // Present so the PR/MR Command Center surfaces (the review-launch toast, etc.)
-  // render the official GitHub mark from the ONE shared catalog.
+  // GitLab — the official multicolour Tanuki (from GitLab's own header markup),
+  // like jira/slack. Kept verbatim: the four paths are the shape + the two
+  // cheeks + the chin, and flattening them to one colour loses the mark.
+  // `aria-hidden`/`role`/`class` were stripped — the renderers own a11y.
+  gitlab: {
+    id: "gitlab",
+    name: "GitLab",
+    vendor: "GitLab",
+    tagline: "Merge requests, reviews & CI",
+    brandColor: "#FC6D26",
+    logoSvg: '<svg width="25" height="24" viewBox="0 0 25 24" fill="none" xmlns="http://www.w3.org/2000/svg"><path d="m24.507 9.5-.034-.09L21.082.562a.896.896 0 0 0-1.694.091l-2.29 7.01H7.825L5.535.653a.898.898 0 0 0-1.694-.09L.451 9.411.416 9.5a6.297 6.297 0 0 0 2.09 7.278l.012.01.03.022 5.16 3.867 2.56 1.935 1.554 1.176a1.051 1.051 0 0 0 1.268 0l1.555-1.176 2.56-1.935 5.197-3.89.014-.01A6.297 6.297 0 0 0 24.507 9.5Z" fill="#E24329"/><path d="m24.507 9.5-.034-.09a11.44 11.44 0 0 0-4.56 2.051l-7.447 5.632 4.742 3.584 5.197-3.89.014-.01A6.297 6.297 0 0 0 24.507 9.5Z" fill="#FC6D26"/><path d="m7.707 20.677 2.56 1.935 1.555 1.176a1.051 1.051 0 0 0 1.268 0l1.555-1.176 2.56-1.935-4.743-3.584-4.755 3.584Z" fill="#FCA326"/><path d="M5.01 11.461a11.43 11.43 0 0 0-4.56-2.05L.416 9.5a6.297 6.297 0 0 0 2.09 7.278l.012.01.03.022 5.16 3.867 4.745-3.584-7.444-5.632Z" fill="#FC6D26"/></svg>'
+  },
+  // GitHub — now a REAL `IntegrationId` (`version_control`, `kind: 'connection'`).
+  // It started life here as a brand-only entry, back when GitHub was rendered by
+  // a hand-written special-case row; the mark is unchanged, it's just also the
+  // catalog row's logo now. Still used by the PR/MR Command Center surfaces.
   github: {
     id: "github",
     name: "GitHub",