@codeam/shared 2.61.75 → 2.61.77

package/dist/index.mjs

@@ -1423,6 +1423,41 @@ var INTEGRATION_REGISTRY = {
       }
     }
   },
+  convex: {
+    id: "convex",
+    name: "Convex",
+    icon: "convex",
+    category: "database",
+    // LIVE — OAuth 2.0 (authorization code, Confidential). authorize
+    // dashboard.convex.dev/oauth/authorize/team (the scope is the URL PATH —
+    // `team` for team-wide access — NOT a query param); token
+    // api.convex.dev/oauth/token (form-urlencoded, client creds in the BODY).
+    // ⚠️ Convex issues NO refresh token and the team-scoped application token
+    // does not expire, so there is nothing to rotate (refresh() is a re-link
+    // surface). The OAuth app (Team Settings → OAuth Applications) is registered
+    // and CONVEX_OAUTH_CLIENT_ID/SECRET/REDIRECT_URI are in Secret Manager
+    // (prod+dev); the config-gated 503 keeps this safe mid-rollout.
+    enabled: true,
+    auth: {
+      kind: "oauth_redirect",
+      // ⚠️ Convex's scope is the authorize URL path (`/team`), NOT sent in the
+      // authorize URL as a query param — this list is informational.
+      scopes: []
+    },
+    delivery: {
+      mcp: {
+        // Convex's OFFICIAL MCP server ships inside the `convex` npm package
+        // (`convex mcp start`). The team-scoped OAuth application token doubles
+        // as the CLI/MCP deploy key → fed via CONVEX_DEPLOY_KEY (env only, never
+        // argv). Version PINNED; bump only after re-verifying headless.
+        command: "npx",
+        args: ["-y", "convex@1.42.3", "mcp", "start"],
+        envMapping: {
+          CONVEX_DEPLOY_KEY: "accessToken"
+        }
+      }
+    }
+  },
   confluence: {
     id: "confluence",
     name: "Confluence",
@@ -1760,6 +1795,14 @@ var INTEGRATION_BRANDING = {
     brandColor: "#3FCF8E",
     logoSvg: '<svg role="img" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><title>Supabase</title><path fill="#FFFFFF" d="M11.9 1.036c-.015-.986-1.26-1.41-1.874-.637L.764 12.05C-.33 13.427.65 15.455 2.409 15.455h9.579l.113 7.51c.014.985 1.259 1.408 1.873.636l9.262-11.653c1.093-1.375.113-3.403-1.645-3.403h-9.642z"/></svg>'
   },
+  convex: {
+    id: "convex",
+    name: "Convex",
+    vendor: "Convex",
+    tagline: "Reactive database & backend",
+    brandColor: "#EE342F",
+    logoSvg: '<svg role="img" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><title>Convex</title><path fill="#FFFFFF" d="M15.09 18.916c3.488-.387 6.776-2.246 8.586-5.348-.857 7.673-9.247 12.522-16.095 9.545a3.47 3.47 0 0 1-1.547-1.314c-1.539-2.417-2.044-5.492-1.318-8.282 2.077 3.584 6.3 5.78 10.374 5.399m-10.501-7.65c-1.414 3.266-1.475 7.092.258 10.24-6.1-4.59-6.033-14.41-.074-18.953a3.44 3.44 0 0 1 1.893-.707c2.825-.15 5.695.942 7.708 2.977-4.09.04-8.073 2.66-9.785 6.442m11.757-5.437C14.283 2.951 11.053.992 7.515.933c6.84-3.105 15.253 1.929 16.17 9.37a3.6 3.6 0 0 1-.334 2.02c-1.278 2.594-3.647 4.607-6.416 5.352 2.029-3.763 1.778-8.36-.589-11.847"/></svg>'
+  },
   cloudflare: {
     id: "cloudflare",
     name: "Cloudflare",
@@ -2043,11 +2086,110 @@ var specDrivenDevelopmentSkill = {
   }
 };
 
+// src/skills/code-naming.ts
+var CODE_NAMING_BODY = `Use this skill when NAMING or RENAMING code \u2014 variables, functions, classes,
+interfaces, types, files, modules, components, hooks, constants \u2014 while writing
+new code, refactoring, or reviewing a diff. A name should reveal intent and
+domain meaning so a reader understands the code without translating it in their
+head, and so it needs fewer comments.
+
+## The five core rules (name the concept, not the implementation)
+
+1. **Don't abbreviate, and don't use single letters for meaningful values.**
+   \`usr\`/\`cfg\`/\`authReq\` \u2192 \`user\`/\`config\`/\`authRequest\`; \`u\`/\`p\` \u2192 \`user\`/\`project\`.
+   Abbreviations rely on context the next reader may not have. Allowed: standard
+   acronyms the domain already uses (API, URL, HTTP, ID, UUID, CLI, SDK, PR, OAuth),
+   loop indices \`i\`/\`j\`, coordinates \`x\`/\`y\`, and generic type params \`T\`/\`K\`/\`V\`.
+
+2. **Don't put the data TYPE in a variable name.** \`userList\` \u2192 \`users\`,
+   \`nameString\` \u2192 \`displayName\`, \`isActiveBool\` \u2192 \`isActive\`, \`invoiceMap\` \u2192
+   \`invoicesById\`. The type system and editor already show the type; the name
+   should carry the meaning.
+
+3. **Include the UNIT when a number has one** (unless the type makes it
+   unmistakable). \`timeout\` \u2192 \`timeoutMs\`, \`delay\` \u2192 \`retryDelaySeconds\`,
+   \`size\` \u2192 \`fileSizeBytes\`, \`price\` \u2192 \`priceUsd\`. Especially time, distance,
+   money, bytes, rates, percentages, token/rate limits.
+
+4. **Don't put the type CONSTRUCT in a type's name.** \`UserClass\` \u2192 \`User\`,
+   \`PaymentInterface\`/\`IPayment\` \u2192 \`Payment\` (or a role like \`PaymentGateway\`),
+   \`ConfigType\` \u2192 \`Config\`, \`StatusEnum\` \u2192 \`Status\`. Name the concept, not
+   "what kind of programming thing it is."
+
+5. **Refactor when you're reaching for \`Utils\`/\`Helpers\`/\`Common\`.** A generic
+   bucket usually hides a missing concept. Group by domain instead:
+   \`utils/parseCookie\` \u2192 a \`cookies/\` module or a \`CookieStore\`/\`CookieJar\` class;
+   \`utils/formatDate\` \u2192 \`dates/\` or a \`DateRangeFormatter\`. Same for vague
+   \`Base\`/\`Abstract\`/\`Manager\`/\`Helper\` class names \u2014 prefer the role
+   (\`Repository\`, \`BillingService\`, \`UserProvisioner\`) unless the project
+   convention explicitly requires \`Base\`/\`Abstract\`.
+
+## Shape rules
+
+- **Functions are verbs / verb phrases:** \`createInvoice()\`, \`sendPasswordResetEmail()\`,
+  \`findRepositoryById()\`. Booleans read like a question in an \`if\`:
+  \`isActive\`, \`hasAccess\`, \`canDeploy\`, \`shouldRetry\` (prefix \`is/has/can/should/needs\`).
+- **Classes / interfaces / types are nouns or roles:** \`Invoice\`, \`PaymentGateway\`,
+  \`AgentSession\` \u2014 not \`InvoiceData\`, \`SubscriptionThing\`, \`AgentSessionType\`.
+- **Collections are plural, or \`\u2026ById\`/\`\u2026ByX\` when indexed:** \`users\`,
+  \`activeSessions\`, \`invoicesByCustomerId\`.
+- **Don't encode a temporary implementation in a name that may change:**
+  \`postgresUserRepository\` \u2192 \`userRepository\`, \`redisCache\` \u2192 \`cache\` \u2014 unless the
+  implementation IS the meaningful distinction. Name the role, not today's backend.
+- **Follow the project's existing conventions** (casing, file naming, \`useX\`
+  hooks, \`handleX\` handlers). Match the surrounding code; don't introduce a new
+  style without a strong reason.
+
+## Words to distrust (infer the real role, then name it)
+
+\`data\`, \`info\`, \`item\`, \`obj\`, \`temp\`, \`result\`, \`value\`, \`thing\`, \`stuff\`,
+\`manager\`, \`helper\`, \`utils\`, \`common\`, \`base\`, \`abstract\`, \`processor\`,
+\`handler\`, \`payload\`. They're acceptable only when the surrounding context makes
+them precise (e.g. \`config\` inside one \`DatabaseConnection\`); vague when passed
+across many layers.
+
+## Guardrails \u2014 this is a review/refactor guide, NOT a mass-rename mandate
+
+- Names that are already clear and idiomatic are DONE \u2014 leave them.
+- Before renaming: read how the identifier is used and infer the real domain
+  concept. Prefer the **smallest** clear rename.
+- Do NOT do large unrelated renames, and do NOT rename purely for personal
+  preference. Stay inside the change you were asked to make.
+- Preserve public API / exported names unless the task explicitly allows a break;
+  when you do rename, update every reference, tests, and docs in the same change.
+- No clever names, jokes, or metaphors in production code; don't make names
+  needlessly long either.
+
+When reviewing, raise a naming issue only when a clearer name would materially
+help a reader \u2014 one suggestion per finding: \`current \u2192 suggested \u2014 why\`.`;
+var CODE_NAMING_INSTRUCTION = `When naming or renaming code, name the domain concept, not the implementation:
+no abbreviations or single-letter names for meaningful values (standard acronyms
+like API/URL/ID/OAuth are fine); don't put the data type in a variable name
+(userList \u2192 users); include the unit when a number has one (timeout \u2192 timeoutMs);
+don't put the type construct in a type's name (IPayment \u2192 Payment); and refactor
+generic Utils/Helper/Manager/Base buckets into a domain module or a role-named
+class. Functions are verbs (createInvoice), booleans read like questions
+(isActive/hasAccess), classes/types are nouns/roles, collections are plural or
+\u2026ById. This is a review/refactor guide, not a mandate to mass-rename: leave
+already-clear names alone, prefer the smallest clear rename, don't rename
+unrelated code, and preserve public/exported names unless the task allows a break.`;
+var codeNamingSkill = {
+  id: "code-naming",
+  name: "Code Naming",
+  description: `Naming review & refactor: name the domain concept, not the implementation \u2014 no abbreviations, no type-in-name, units when they matter, no Utils/Manager/Base buckets; rename minimally, never mass-rename.`,
+  source: "curated",
+  delivery: {
+    skillFile: { body: CODE_NAMING_BODY },
+    instruction: { body: CODE_NAMING_INSTRUCTION }
+  }
+};
+
 // src/skills/registry.ts
 var SKILL_REGISTRY = {
   "code-review": codeReviewSkill,
   "resolve-conflicts": resolveConflictsSkill,
-  "spec-driven-development": specDrivenDevelopmentSkill
+  "spec-driven-development": specDrivenDevelopmentSkill,
+  "code-naming": codeNamingSkill
 };
 function isSkillId(id) {
   return Object.prototype.hasOwnProperty.call(SKILL_REGISTRY, id);