wolfpack-mcp 1.0.112 → 1.0.113

package/README.md

@@ -1,10 +1,14 @@
-# Wolfpack MCP Server
+# Clachan MCP Server (formerly Wolfpack)
 
 [![npm](https://img.shields.io/npm/v/wolfpack-mcp)](https://www.npmjs.com/package/wolfpack-mcp)
 
-Connect your AI assistant to Wolfpack to manage work items, track issues, update documentation, and log progress—all
+Connect your AI assistant to Clachan to manage work items, track issues, update documentation, and log progress—all
 through natural conversation.
 
+> **Wolfpack is now Clachan.** Same product, same server, same account. The package is still published as
+> `wolfpack-mcp`, its settings are still `WOLFPACK_*`, and API keys still begin `wfp_`; nothing you have
+> configured needs to change. See [Clachan and Wolfpack](#clachan-and-wolfpack) below.
+
 ## Quick Start
 
 There are two ways to connect:
@@ -24,19 +28,20 @@ Add to your Claude Desktop config file:
   "mcpServers": {
     "wolfpack": {
       "type": "url",
-      "url": "https://wolfpacks.work/mcp"
+      "url": "https://app.clachan.ai/mcp"
     }
   }
 }
 ```
 
-Restart Claude Desktop. You'll be prompted to sign in with your Wolfpack account via OAuth.
+Restart Claude Desktop. You'll be prompted to sign in with your Clachan account via OAuth. The server is also
+still served at `https://wolfpacks.work/mcp`, so an existing configuration keeps working.
 
 ### Coding Agents (stdio)
 
 #### 1. Generate an API Key
 
-1. Log in to [wolfpacks.work](https://wolfpacks.work)
+1. Log in to [app.clachan.ai](https://app.clachan.ai) (or [wolfpacks.work](https://wolfpacks.work), which still works)
 2. Go to **Account Settings** → **API Keys**
 3. Click **Create New Key**
 4. Select the permissions you need (work items, issues, wiki, etc.)
@@ -62,6 +67,24 @@ Restart Claude Desktop. You'll be prompted to sign in with your Wolfpack account
 
 **Cursor / Windsurf** — use the same `command`, `args`, and `env` in your editor's MCP configuration.
 
+The stdio server talks to `https://wolfpacks.work/api/mcp` unless `WOLFPACK_API_URL` says otherwise; both
+domains serve the same deployment, so there is nothing to change during the rename.
+
+## Clachan and Wolfpack
+
+The product was renamed from Wolfpack to Clachan in September 2026. Both names are understood while the
+rename settles: the server introduces the product to your assistant as "Clachan (formerly Wolfpack)", so
+asking for "the Wolfpack issue" or "my Clachan work items" means the same thing.
+
+What you configure is deliberately **unchanged**, because it is the contract every installed client already
+depends on:
+
+- the package name, `wolfpack-mcp`, and the server name `wolfpack` in your MCP configuration
+- the environment variables: `WOLFPACK_API_KEY`, `WOLFPACK_API_URL`, `WOLFPACK_ORG_SLUG`, `WOLFPACK_TEAM_SLUG`
+- the API key prefixes `wfp_sk_` (user) and `wfp_ak_` (agent)
+
+If those are ever renamed it will be announced here, with the old spellings kept working alongside the new.
+
 ## Installation
 
 ```bash

package/dist/brand.js

@@ -8,6 +8,13 @@
  *
  * `WOLFPACK_*` variables are this package's public configuration contract with the MCP
  * clients that already set them, so they are deliberately not renamed here.
+ *
+ * `productFormerName` is what the product was called before a rename, for as long as the
+ * transition lasts (#2592); the server instructions say it once so a user who still uses
+ * the old name is understood. Unlike the other two, a blank `PRODUCT_FORMER_NAME` is a
+ * value — "no former name" — so a deployment rebranded by its environment can turn the
+ * suffix off. Empty in `brand.json` once the transition is over.
  */
 export const productName = process.env.PRODUCT_NAME || 'Clachan';
+export const productFormerName = process.env.PRODUCT_FORMER_NAME ?? 'Wolfpack';
 export const productDomain = process.env.PRODUCT_DOMAIN || 'wolfpacks.work';

package/dist/serverInstructions.js

@@ -1,4 +1,4 @@
-import { productName } from './brand.js';
+import { productFormerName, productName } from './brand.js';
 /**
  * Server instructions, returned in the MCP `initialize` result.
  *
@@ -12,8 +12,13 @@ import { productName } from './brand.js';
  * Mirrored in `packages/backend/src/mcp/serverInstructions.ts` for the remote
  * server — the two servers have no shared package, and already keep their tool
  * descriptions in step by hand.
+ *
+ * While a rename is in transition the product is introduced as "X (formerly Y)", once
+ * (#2592): nothing else tells the model that "the Wolfpack issue" and a Clachan issue are
+ * the same thing. The suffix disappears with the former name.
  */
-export const SERVER_INSTRUCTIONS = `${productName} is this project's tracker. Its references override the usual GitHub reading of "#N".
+const formerly = productFormerName ? ` (formerly ${productFormerName})` : '';
+export const SERVER_INSTRUCTIONS = `${productName}${formerly} is this project's tracker. Its references override the usual GitHub reading of "#N".
 
 - A bare "#123" — "work on #123", "look at #42" — is ALWAYS a ${productName} work item. Call get_work_item. Do not run \`gh issue view\`, and do not search GitHub for it.
 - Read a number as a GitHub issue or pull request only when the user says GitHub, PR, or gh — "the GitHub issue #123", "PR #123".

package/dist/serverInstructions.test.js

@@ -1,5 +1,6 @@
-import { describe, it, expect } from 'vitest';
+import { describe, it, expect, vi } from 'vitest';
 import { SERVER_INSTRUCTIONS } from './serverInstructions.js';
+import { productFormerName, productName } from './brand.js';
 describe('SERVER_INSTRUCTIONS', () => {
     it('claims a bare #N for work items before any tool is chosen (#1373)', () => {
         // The whole point of the instructions field: a client puts it in the system
@@ -28,4 +29,29 @@ describe('SERVER_INSTRUCTIONS', () => {
     it('stays short enough to sit in a system prompt', () => {
         expect(SERVER_INSTRUCTIONS.length).toBeLessThan(1200);
     });
+    it('introduces the product by its former name too, while it has one (#2592)', () => {
+        // A user mid-rename still says the old name; nothing else tells the model the
+        // two are one product. Read from the brand so the test survives the transition
+        // ending — at which point the suffix must be gone, and this asserts that too.
+        const expected = productFormerName
+            ? `${productName} (formerly ${productFormerName}) is this project's tracker`
+            : `${productName} is this project's tracker`;
+        expect(SERVER_INSTRUCTIONS).toContain(expected);
+        expect(SERVER_INSTRUCTIONS.match(/formerly/g) ?? []).toHaveLength(productFormerName ? 1 : 0);
+    });
+    it('says nothing about a former name when the deployment sets a blank one', async () => {
+        // A blank value is a value here: a deployment rebranded through PRODUCT_NAME must be
+        // able to turn the suffix off, otherwise it introduces itself as formerly Wolfpack.
+        vi.stubEnv('PRODUCT_FORMER_NAME', '');
+        vi.resetModules();
+        try {
+            const fresh = await import('./serverInstructions.js');
+            expect(fresh.SERVER_INSTRUCTIONS).not.toContain('formerly');
+            expect(fresh.SERVER_INSTRUCTIONS).toContain(`${productName} is this project's tracker`);
+        }
+        finally {
+            vi.unstubAllEnvs();
+            vi.resetModules();
+        }
+    });
 });

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "wolfpack-mcp",
-  "version": "1.0.112",
-  "description": "MCP server for Wolfpack AI-enhanced software delivery tools",
+  "version": "1.0.113",
+  "description": "MCP server for Clachan (formerly Wolfpack), AI-enhanced software delivery tools",
   "main": "dist/index.js",
   "type": "module",
   "bin": {
@@ -23,6 +23,7 @@
   "keywords": [
     "mcp",
     "model-context-protocol",
+    "clachan",
     "wolfpack",
     "ai",
     "claude",