@codeam/shared 2.61.30 → 2.61.31

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';
 /**
  * `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';
 /**
  * `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,30 @@ 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: {}
+  },
   github_issues: {
     id: "github_issues",
     name: "GitHub Issues",
@@ -932,10 +956,10 @@ 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.
+  // 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",