@codeam/shared 2.75.2 → 2.75.3

package/dist/index.mjs

@@ -322,12 +322,34 @@ var AGENT_REGISTRY = {
     displayName: "Gemini CLI",
     binaryName: "gemini",
     enabled: true,
-    // OAuth via `gemini auth login` (captured by `codeam link gemini`
-    // from ~/.gemini/oauth_creds.json) AND GEMINI_API_KEY are both
-    // accepted by the backend's GeminiProvisioningStrategy and propagated
-    // into codespace deploys.
-    supportedAuthKinds: ["oauth_token", "api_key"],
-    preferredAuthKind: "oauth_token",
+    // ⚠️ API KEY ONLY since 2026-06-18, when Google stopped Gemini CLI (and the
+    // Gemini Code Assist IDE extensions) serving requests for AI Pro, AI Ultra
+    // and free users, in the move to Antigravity CLI. Its announcement is
+    // explicit about what survives: "Gemini CLI will remain accessible via paid
+    // Gemini and Gemini Enterprise Agent Platform API keys."
+    //
+    // So the agent stays — `@google/gemini-cli` is NOT deprecated, it still
+    // ships weekly — but the OAuth door has to go: it captures a
+    // `~/.gemini/oauth_creds.json` from a CONSUMER Google account, which is
+    // exactly the tier that no longer serves requests. We used to PREFER that
+    // path, so it was the one we recommended first; on 2026-09-15 prod held 63
+    // Gemini links, 46 of them OAuth, 19 created after 2026-09-01 and the
+    // newest that same day. Three months of sending people through a bricked
+    // door — each one landing on `isGeminiIneligibleTier` at first use.
+    //
+    // ⚠️ Antigravity CLI is NOT a drop-in replacement for us: no official ACP
+    // mode (google-antigravity/antigravity-cli#31 open, 192 comments, zero
+    // `acp` hits in the repo as of 2026-09-15), and every third-party ACP
+    // adapter warns that driving `agy` that way matches what Google's FAQ calls
+    // a ToS violation — risking the USER's Google account. Our whole Gemini
+    // path is ACP, so adopting it would mean shipping that risk. Revisit only
+    // when #31 ships an official mode.
+    //
+    // Existing OAuth rows are NOT migrated: `supportedAuthMethods` gates the
+    // LINK call only, so the 46 stay readable and simply keep failing at the
+    // provider, where the ineligible-tier message already explains why.
+    supportedAuthKinds: ["api_key"],
+    preferredAuthKind: "api_key",
     // Not listed by `headroom wrap --help` — runs native.
     headroomWrappable: false,
     // Native ACP server: `gemini --skip-trust --acp`.
@@ -1585,6 +1607,16 @@ var INTEGRATION_REGISTRY = {
     // tools ourselves via a BUILT-IN MCP (delivery.builtin) against that admin
     // API — see apps/cli/src/integrations/convex-admin-mcp.ts. The user still
     // pastes a deploy key (Dashboard → Project Settings → Deploy Keys).
+    //
+    // ⚠️ That built-in ALSO owns `deploy`, and it is the only way an agent can
+    // push `convex/` changes. Deploying is bundle + push, not a REST call, so
+    // that one tool drives Convex's own CLI with the deploy key injected into
+    // THAT CHILD's env — the agent's shell never sees the credential. Before
+    // it existed the agent had the credential's power through the MCP but no
+    // way to deploy, so it looped on `npx convex dev` (interactive login) and
+    // asked the user to paste the token into the chat; the user ended up
+    // re-entering the SAME key by hand in Environment Variables, after burning
+    // real credits (2026-09-15).
     enabled: true,
     auth: {
       kind: "api_key",