pipebrain-mcp 0.34.1 → 0.35.0

package/dist/main.js

@@ -15081,9 +15081,8 @@ var widgetOriginSchema = external_exports.string().trim().transform((raw) => raw
 var emailSchema = external_exports.email({ message: "enter a valid email address" });
 var passwordSchema = external_exports.string().min(8, { message: "password must be at least 8 characters" }).max(128, { message: "password must be at most 128 characters" });
 var ACCEPTED_TOKEN_PREFIXES = ["pbt_"];
-var MINTED_TOKEN_PREFIXES = ["pbt_", "plt_"];
-var tokenPrefixSchema = external_exports.string().regex(new RegExp(`^(?:${MINTED_TOKEN_PREFIXES.join("|")})[0-9A-Za-z]{4}$`), {
-  message: "token prefix must be a minted prefix followed by 4 base62 characters"
+var tokenPrefixSchema = external_exports.string().regex(new RegExp(`^(?:${ACCEPTED_TOKEN_PREFIXES.join("|")})[0-9A-Za-z]{4}$`), {
+  message: "token prefix must be an accepted prefix followed by 4 base62 characters"
 });
 var SECRET_NAME_RE = /^[A-Z_][A-Z0-9_]*$/;
 var secretNameSchema = external_exports.string().regex(SECRET_NAME_RE, {
@@ -17119,7 +17118,7 @@ function createMcpServer(client2, apiBaseUrl, orgInstructions2 = /* @__PURE__ */
       // one description loaded into EVERY session by `anthropic/alwaysLoad`. The clauses
       // that went were the ones arguing for the rule rather than stating it; what a caller
       // needs to predict a refusal all stayed.
-      description: "Everything a session needs before it starts work, in ONE read \u2014 assembled by the API and returned verbatim, with the BINDING GUIDANCE appended after it: the product doctrine and this organization\u2019s own writing rules, in full. This is the one call that returns them; every other read only names it. CALL IT FIRST, before you write anything. Addressed by `issue` OR by `project`, never both and never neither: an issue names its own project, so the pair is refused rather than resolved for you (\xA77). Given an ISSUE: that issue\u2019s full detail \u2014 the same payload `get_issue` returns \u2014 PLUS the BODY TEXT of every requirement it links, at the revision the link is pinned at. That text is the round trip this removes: `get_issue` names which documents bind the work and at which revision, never what they SAY. Comments come CAPPED at the newest `commentLimit`, with `commentCount` \u2014 the issue\u2019s TRUE total \u2014 beside them; read the issue directly for the rest. Given a PROJECT: `available`, the work a session could START right now. It EXCLUDES finished and abandoned work (`done`, `killed`), work another person has claimed, and anything blocked \u2014 the status guard would refuse to start that. Your OWN claims stay, and so does unscheduled work carrying no milestone. The item form carries no `available`; the project form carries no item. BOTH forms also carry the project half: the release currently being worked (the active milestone) and the project\u2019s cross-cutting requirements WITH their text \u2014 they bind every epic automatically. READ-ONLY \u2014 this claims nothing, moves nothing and writes nothing.",
+      description: "Everything a session needs before it starts work, in ONE read \u2014 assembled by the API and returned verbatim, with the BINDING GUIDANCE appended after it: the product doctrine and this organization\u2019s own writing rules, in full. This is the one call that returns them; every other read only names it. CALL IT FIRST, before you write anything. Addressed by `issue` OR by `project`, never both and never neither: an issue names its own project, so the pair is refused rather than resolved for you (\xA77). Given an ISSUE: that issue\u2019s full detail \u2014 the same payload `get_issue` returns \u2014 PLUS the BODY TEXT of every requirement it links, at the revision the link is pinned at. That text is the round trip this removes: `get_issue` names which documents bind the work and at which revision, never what they SAY. Comments come CAPPED at the newest `commentLimit`, with `commentCount` \u2014 the issue\u2019s TRUE total \u2014 beside them; read the issue directly for the rest. Given a PROJECT: `available`, the work a session could START right now. It EXCLUDES finished and abandoned work (`done`, `killed`), work another person has claimed, and anything blocked \u2014 the status guard would refuse to start that. Your OWN claims stay, and so does unscheduled work carrying no milestone. `available` comes CAPPED at `availableLimit` rows, with `availableCount` \u2014 the project\u2019s TRUE total of startable work \u2014 beside it. The item form carries no `available`; the project form carries no item. BOTH forms also carry the project half: the release currently being worked (the active milestone) and the project\u2019s cross-cutting requirements WITH their text \u2014 they bind every epic automatically. READ-ONLY \u2014 this claims nothing, moves nothing and writes nothing.",
       // The WHOLE domain schema rather than its `.shape`: the exactly-one-of rule is a
       // refinement on the OBJECT, and a raw shape drops it — the SDK validates against
       // what it is handed, so the shape alone would quietly accept both arguments and
@@ -17578,7 +17577,7 @@ function loadMcpConfig() {
 }
 
 // src/version.ts
-var VERSION = "0.34.1";
+var VERSION = "0.35.0";
 
 // src/main.ts
 var config2 = loadMcpConfig();

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "pipebrain-mcp",
-  "version": "0.34.1",
-  "description": "Pipebrain MCP server for Claude Code and Claude Desktop \u2014 issues, requirements, content, assets, and metadata-only secrets over the Pipebrain API.",
+  "version": "0.35.0",
+  "description": "Pipebrain MCP server for Claude Code and Claude Desktop — issues, requirements, content, assets, and metadata-only secrets over the Pipebrain API.",
   "type": "module",
   "license": "MIT",
   "main": "./dist/main.js",