pipebrain-mcp 0.44.1 → 0.46.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()
@@ -17677,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: {
@@ -17781,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", {
@@ -17886,7 +17909,7 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
     })
   ), GUIDANCE_POINTER));
   registerStrict("create_issue", {
-    description: "Create an issue (epic/task/bug/feedback). Omitted status defaults to triage (still subject to \xA76 guards); omitted environment resolves explicit \u2192 parent\u2019s environment \u2192 project default (prod). Optional parent (a parent already `done` or `killed` is rejected `parent_terminal`, unless the child is itself terminal; a new issue is a leaf, so no cycle is possible here), priority, milestone, requirement_links (pins each at its approved revision; a target with no approved revision is rejected), deliverable_links (content deliverables like DWB-C3/bsky \u2014 pins each at its current revision; the promotion path), and ordered {text, verification, howTo} criteria (\xA77). A `status` other than `triage` or `killed` REQUIRES `milestone` (PIPE-R10 rule 9): work past triage belongs to a release, and the create is refused (`milestone_required`) without one. A `manual` criterion must carry `howTo` \u2014 one or two sentences saying where to look, what to do, and what counts as passing; writing or changing one without it is refused (`how_to_required`), and so is supplying it on an `auto` criterion, which a machine checks. Work of any kind carries criteria \u2014 an epic, a task, a bug alike \u2014 with feedback the one exception, refused with `criteria_not_supported` because it is a report rather than agreed work; `promote_feedback` retypes it into work before anything is built. When a bug is filed against a defined acceptance criterion, pass that criterion\u2019s uuid as `criterionId` and the bug records which criterion it was filed against \u2014 what has already been reported arrives as `filedBugs` on every criteria read. Filing a second bug against one criterion is supported: one row can fail for two different reasons at once. Bugs only: any other type naming a criterion is refused (`criterion_requires_bug`). Writing guidance for this tool lives in the product doctrine, which `get_work_context` returns \u2014 see \u201CSearch before you create\u201D and \u201CThe bar for filing a bug\u201D.",
+    description: "Create an issue (epic/task/bug/feedback). Omitted status defaults to triage (still subject to \xA76 guards); omitted environment resolves explicit \u2192 parent\u2019s environment \u2192 project default (prod). Optional parent (a parent already `done` or `killed` is rejected `parent_terminal`, unless the child is itself terminal; a new issue is a leaf, so no cycle is possible here), priority, milestone, requirement_links (pins each at its approved revision; a target with no approved revision is rejected), deliverable_links (content deliverables like DWB-C3/bsky \u2014 pins each at its current revision; the promotion path), and ordered {text, verification, howTo} criteria (\xA77). A `status` other than `triage` or `killed` REQUIRES `milestone` (PIPE-R10 rule 9): work past triage belongs to a release, and the create is refused (`milestone_required`) without one. An open child moves the parent to `in_progress` (rule 10). A `manual` criterion must carry `howTo` \u2014 one or two sentences saying where to look, what to do, and what counts as passing; writing or changing one without it is refused (`how_to_required`), and so is supplying it on an `auto` criterion, which a machine checks. Work of any kind carries criteria \u2014 an epic, a task, a bug alike \u2014 with feedback the one exception, refused with `criteria_not_supported` because it is a report rather than agreed work; `promote_feedback` retypes it into work before anything is built. When a bug is filed against a defined acceptance criterion, pass that criterion\u2019s uuid as `criterionId` and the bug records which criterion it was filed against \u2014 what has already been reported arrives as `filedBugs` on every criteria read. Filing a second bug against one criterion is supported: one row can fail for two different reasons at once. Bugs only: any other type naming a criterion is refused (`criterion_requires_bug`). Writing guidance for this tool lives in the product doctrine, which `get_work_context` returns \u2014 see \u201CSearch before you create\u201D and \u201CThe bar for filing a bug\u201D.",
     inputSchema: createIssueInputSchema.shape
   }, (args) => run(() => client2().createIssue(args)));
   registerStrict("promote_feedback", {
@@ -17897,7 +17920,7 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
     }
   }, ({ issue: issue2, ...fields }) => run(() => client2().promoteFeedback(issue2, fields)));
   registerStrict("open_review", {
-    description: "Open the COMPLETION REVIEW \u2014 the reading of an epic\u2019s WHOLE accumulated change as one body of work, by a third fresh session that neither built it nor evaluated it. It runs at one moment: once the epic\u2019s contract is green and before anyone sets it `done`. It creates one ORDINARY `task` at `ready` carrying the review checklist as its body. The epic form (`epic`) titles it `Completion review \u2014 <KEY-n> <epic title>`, files it as a CHILD of the epic and inherits the epic\u2019s milestone; the milestone form (`project` + `milestone`) titles it `Completion review \u2014 milestone <token>`, carries that token and has no parent. Pass EXACTLY ONE of `epic` or `project` + `milestone`: both, or neither, is refused. One review at a time per scope \u2014 a second is refused (`review_already_open`) NAMING the standing one, so read, finish or kill that task instead. The scopes overlap ONE way: the epic form\u2019s review also stands for that same project and milestone, so a later milestone-form open is refused; a milestone-form review blocks no epic-form open. A review opens only on a non-terminal epic \u2014 `review_target_not_epic` otherwise, `review_target_terminal` on a `done`/`killed` epic (a re-opened epic reviews again). NO NEW GATE was added to `done`: file each finding as ordinary work \u2014 a CHILD OF THE EPIC, a sibling of this review \u2014 and the children clause already on `done` holds the epic open until every finding is done or killed. A finding filed UNDER the review gates nothing, because that gate reads one level deep. Killing the review, or any finding, is the recorded waiver: deliberately ungated, and written to the status history with who did it and through which token. Writing guidance for the checklist and for each finding lives in the product doctrine, which `get_work_context` returns.",
+    description: "Open the COMPLETION REVIEW \u2014 the reading of an epic\u2019s WHOLE accumulated change as one body of work, by a third fresh session that neither built it nor evaluated it. It runs at one moment: once the epic\u2019s contract is green and before anyone sets it `done`. It creates one ORDINARY `task` at `ready` carrying the review checklist as its body. The epic form (`epic`) titles it `Completion review \u2014 <KEY-n> <epic title>`, files it as a CHILD of the epic and inherits the epic\u2019s milestone; the milestone form (`project` + `milestone`) titles it `Completion review \u2014 milestone <token>`, carries that token and has no parent. Pass EXACTLY ONE of `epic` or `project` + `milestone`: both, or neither, is refused. One review at a time per scope \u2014 a second is refused (`review_already_open`) NAMING the standing one, so read, finish or kill that task instead. The scopes overlap ONE way: the epic form\u2019s review also stands for that same project and milestone, so a later milestone-form open is refused; a milestone-form review blocks no epic-form open. A review opens only on a non-terminal epic \u2014 `review_target_not_epic` otherwise, `review_target_terminal` on a `done`/`killed` epic (a re-opened epic reviews again). NO NEW GATE was added to `done`: file each finding as ordinary work \u2014 a CHILD OF THE EPIC, a sibling of this review \u2014 and the children clause already on `done` holds the epic open until every finding is done or killed. A finding filed UNDER the review gates nothing, because that gate reads one level deep. Killing the review, or any finding, is the recorded waiver: deliberately ungated, and written to the status history with who did it and through which token. THIS CALL MOVES NOTHING. Attaching an open child otherwise starts its parent (PIPE-R10 rule 10); this one is exempt, because the review is the gate \u2014 starting the work again would drop it out of `list_waiting`. Writing guidance for the checklist and for each finding lives in the product doctrine, which `get_work_context` returns.",
     // The WHOLE domain schema rather than its `.shape`, for `get_work_context`'s
     // reason: the exactly-one-of rule is a refinement on the OBJECT, and a raw
     // shape drops it — the refusal naming the two forms would never reach the
@@ -17905,7 +17928,7 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
     inputSchema: openReviewInputSchema
   }, (args) => run(() => client2().openReview(args)));
   registerStrict("update_issue", {
-    description: "Update any subset of an issue\u2019s title, body, type, priority, milestone, environment, parent (self/cycle rejected, and moving an OPEN issue onto a parent already `done` or `killed` is rejected with `parent_terminal` \u2014 clearing the parent with null is always allowed), requirement_links (add/remove; adding a link to an unapproved requirement is rejected), deliverable_links (add/remove content-deliverable links, add pins at the current revision), or decision_links (add/remove decision records this work sits under \u2014 `KEY-D{n}`, from `list_decisions`). Changing type to `feedback` is rejected while the issue has criteria (\xA77), since feedback carries none; epic, task and bug interchange freely and the criteria ride along, keeping their AC-{n} numbers and their states. Clearing `milestone` (passing null) is rejected while the issue sits past `triage` \u2014 work already scheduled keeps a milestone (PIPE-R10 rule 9); swap it for a different one, or move the issue back to `triage` first. Writing guidance for this tool lives in the product doctrine, which `get_work_context` returns \u2014 see \u201CLink by key; never paste another record\u2019s text\u201D and \u201CA decision you need is filed as a question, never written into a body\u201D.",
+    description: "Update any subset of an issue\u2019s title, body, type, priority, milestone, environment, parent (self/cycle rejected, and moving an OPEN issue onto a parent already `done` or `killed` is rejected with `parent_terminal` \u2014 clearing the parent with null is always allowed), requirement_links (add/remove; adding a link to an unapproved requirement is rejected), deliverable_links (add/remove content-deliverable links, add pins at the current revision), or decision_links (add/remove decision records this work sits under \u2014 `KEY-D{n}`, from `list_decisions`). Changing type to `feedback` is rejected while the issue has criteria (\xA77), since feedback carries none; epic, task and bug interchange freely and the criteria ride along, keeping their AC-{n} numbers and their states. Clearing `milestone` (passing null) is rejected while the issue sits past `triage` \u2014 work already scheduled keeps a milestone (PIPE-R10 rule 9); swap it for a different one, or move the issue back to `triage` first. Setting `parent` ATTACHES the issue, and attaching an OPEN issue starts its new parent: a parent of any type moves to `in_progress`, recorded in that parent\u2019s status history against you and the credential you called with (PIPE-R10 rule 10). Nothing moves it back. Three attachments start nothing: an issue that is already `done` or `killed`; re-sending the parent an issue already has; and a parent that cannot legally hold `in_progress` \u2014 one that is blocked, or carries no milestone \u2014 which KEEPS the status it has and still takes the child, so a finding stays fileable against exactly that work. Writing guidance for this tool lives in the product doctrine, which `get_work_context` returns \u2014 see \u201CLink by key; never paste another record\u2019s text\u201D and \u201CA decision you need is filed as a question, never written into a body\u201D.",
     inputSchema: updateIssueInputSchema.shape
   }, ({ issue: issue2, ...fields }) => run(() => client2().updateIssue(issue2, fields)));
   registerStrict("set_issue_header", {
@@ -18294,7 +18317,7 @@ function loadMcpConfig() {
 }
 
 // src/version.ts
-var VERSION = "0.44.1";
+var VERSION = "0.46.0";
 
 // src/main.ts
 async function scopedClient(base, org) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pipebrain-mcp",
-  "version": "0.44.1",
+  "version": "0.46.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",