pipebrain-mcp 0.44.0 → 0.45.0

package/dist/main.js

@@ -15402,7 +15402,28 @@ var projectMilestoneSchema = external_exports.object({
   token: external_exports.string().min(1),
   label: external_exports.string().min(1),
   position: external_exports.number().int().nonnegative(),
-  active: external_exports.boolean()
+  active: external_exports.boolean(),
+  /**
+   * Retired from the everyday pickers (PIPE-303) — NOT deleted. The row is still
+   * listed here, still holds its token, label and position, and a completion review
+   * still opens against it; only the pickers that offer a milestone to choose stop
+   * offering it. Carried on the wire because this embedded array IS the read surface
+   * for milestones (there is no GET for them), so a picker that could not see the flag
+   * could not honour it.
+   *
+   * OPTIONAL, while the `milestones.archived` COLUMN and the wire rows `libs/db`
+   * builds are both NOT NULL. This is the additive-field tolerance the block comment
+   * at the top of this file states outright, applied where it earns something: the
+   * server always sends the flag, so `undefined` can only mean a response that
+   * predates the column, and "no flag" and "not archived" are the same answer for
+   * every consumer. Requiring it here would instead make a milestone row literal
+   * illegal unless it restates the default — which is a cost paid by every fixture
+   * and caller that has no opinion about archiving, to buy a guarantee the producer
+   * already provides. What actually guards the flag reaching the wire is the projects
+   * integration suite, which reads `archived` off this array and would fail on
+   * `undefined` — a type could not catch a dropped SELECT column anyway.
+   */
+  archived: external_exports.boolean().optional()
 });
 var projectDeliverableTargetSchema = external_exports.object({
   id: uuidSchema,
@@ -15442,6 +15463,7 @@ var milestoneSchema = external_exports.object({
   label: external_exports.string().min(1),
   position: external_exports.number().int().nonnegative(),
   active: external_exports.boolean(),
+  archived: external_exports.boolean(),
   createdAt: external_exports.iso.datetime({ offset: true }),
   updatedAt: external_exports.iso.datetime({ offset: true }),
   deletedAt: external_exports.iso.datetime({ offset: true }).nullable()
@@ -17182,9 +17204,10 @@ var ApiClient = class _ApiClient {
    * Takes NO project and NO org PARAMETER: a queue you point at a project is the
    * per-project surface this replaces, and the organization is a property of the CLIENT,
    * which is where every caller already binds it — `X-Org-Id` for a session and for a
-   * bearer caller alike, falling back to the credential's own organization when nothing
-   * stamped one (PIPE-410 withdrew the rule that a bearer call's organization came off
-   * the token). The agent tool DOES take an `org`, and it is spent on `forOrg` before it
+   * bearer caller alike. A call that stamps none is refused rather than resolved against
+   * the credential, because PIPE-410 (an agent credential reaches every organization its
+   * owner belongs to) left no organization on a credential to resolve against. The agent
+   * tool DOES take an `org`, and it is spent on `forOrg` before it
    * gets here. `mine` narrows to the gates whose
    * work the viewer claimed — plus the requirement gates, which have no claimant at
    * all and would otherwise be waited on by nobody; omitting it is the wide view.
@@ -17676,7 +17699,7 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
     run(() => client2().unscoped().listOrgs(), GUIDANCE_POINTER)
   ));
   registerStrict("list_projects", {
-    description: "List all projects with their key, environments, milestones (token, label, active), deliverable targets (slug, label, active), and open-issue counts \u2014 the project switcher and workflow entry point (\xA77).",
+    description: "List all projects with their key, environments, milestones (token, label, active, archived \u2014 an archived milestone is a finished release retired from the pickers used to schedule work, still valid on every issue that already names it), deliverable targets (slug, label, active), and open-issue counts \u2014 the project switcher and workflow entry point (\xA77).",
     // Optional pagination (§9) — bounds mirror list_issues/list_requirements; the
     // server defaults limit to 200 (max 500) and passes limit/offset as query params.
     inputSchema: {
@@ -17696,7 +17719,7 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
     }
   }, (args) => run(() => client2().createProject(args)));
   registerStrict("list_waiting", {
-    description: "Every gate awaiting a PERSON across ALL projects in the organization this call acts in \u2014 name that organization with `org`, or omit it to read the one this session defaults to \u2014 longest wait first: a requirement revision awaiting approval, a question awaiting an answer, and work in `verify` holding at least one criterion not yet passed. Each entry names its project, the ref the action is taken on (`KEY-R{n}` for a revision, the ISSUE\u2019s `KEY-{n}` for a question or for work at verify), and `waitingSince` \u2014 the instant the wait began, not a duration. Nothing else is a gate: work in `triage` never appears, and neither does work in verify whose criteria have ALL passed. THIS TOOL is READ-ONLY and clears nothing; what clears each gate differs. Answering a question has no tool on this surface, by design. A requirement revision is approved with `approve_requirement`. A verify gate clears as its criteria pass \u2014 an `auto` one through `set_criterion_state`, a `manual` one only ever by a person in the web app. Use it to see what your work is blocked on before asking, rather than to act on it."
+    description: "Every gate awaiting a PERSON across ALL projects in the organization this call acts in \u2014 name that organization with `org`, which is refused if omitted unless this session has a default \u2014 longest wait first: a requirement revision awaiting approval, a question awaiting an answer, and work in `verify` holding at least one criterion not yet passed. Each entry names its project, the ref the action is taken on (`KEY-R{n}` for a revision, the ISSUE\u2019s `KEY-{n}` for a question or for work at verify), and `waitingSince` \u2014 the instant the wait began, not a duration. Nothing else is a gate: work in `triage` never appears, and neither does work in verify whose criteria have ALL passed. THIS TOOL is READ-ONLY and clears nothing; what clears each gate differs. Answering a question has no tool on this surface, by design. A requirement revision is approved with `approve_requirement`. A verify gate clears as its criteria pass \u2014 an `auto` one through `set_criterion_state`, a `manual` one only ever by a person in the web app. Use it to see what your work is blocked on before asking, rather than to act on it."
     // NO NARROWING ARGUMENTS. The one argument this tool does take — `org`, which every
     // tool takes — is not a narrowing: it says WHICH ORGANIZATION the call acts in, not
     // which of that organization's gates come back, and the caller's membership there is
@@ -17780,13 +17803,14 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
     }
   }, ({ project, ...input }) => run(() => client2().createMilestone(project, input)));
   registerStrict("update_milestone", {
-    description: "Rename or reorder a milestone, addressed by its token (e.g. `M1`) or uuid. Supply at least one of `token`, `label`, or `position` \u2014 an empty edit is rejected. Renaming the `token` does NOT rewrite issues pointing at the old one (`issues.milestone` is a loose ref), so prefer changing `label`. Use set_active_milestone to change `active` (\xA77).",
+    description: "Rename, reorder, archive or restore a milestone, addressed by its token (e.g. `M1`) or uuid. Supply at least one of `token`, `label`, `position`, or `archived` \u2014 an empty edit is rejected. Renaming the `token` does NOT rewrite issues pointing at the old one (`issues.milestone` is a loose ref), so prefer changing `label`. `archived: true` retires a finished release from the everyday pickers WITHOUT deleting it \u2014 the row keeps its token, label and position, issues carrying the token are untouched, and a completion review still opens against it; `archived: false` restores it. The project\u2019s ACTIVE milestone cannot be archived (refused `milestone_active` \u2014 make another milestone active first), and an archived one cannot be activated (refused `milestone_archived` \u2014 restore it first). Use set_active_milestone to change `active` (\xA77).",
     inputSchema: {
       project: projectKeySchema,
       milestone: external_exports.string().min(1),
       token: external_exports.string().min(1).optional(),
       label: external_exports.string().min(1).optional(),
-      position: external_exports.number().int().nonnegative().optional()
+      position: external_exports.number().int().nonnegative().optional(),
+      archived: external_exports.boolean().optional()
     }
   }, ({ project, milestone, ...fields }) => run(async () => client2().updateMilestone(project, await resolveMilestoneId(client2(), project, milestone), fields)));
   registerStrict("set_active_milestone", {
@@ -18293,7 +18317,7 @@ function loadMcpConfig() {
 }
 
 // src/version.ts
-var VERSION = "0.44.0";
+var VERSION = "0.45.0";
 
 // src/main.ts
 async function scopedClient(base, org) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pipebrain-mcp",
-  "version": "0.44.0",
+  "version": "0.45.0",
   "description": "Pipebrain MCP server for Claude Code and Claude Desktop — issues, requirements, decision records, conventions, prompts, content, assets, metadata-only secrets, and more of the platform's modules over the Pipebrain API.",
   "type": "module",
   "license": "MIT",