pipebrain-mcp 0.26.0 → 0.28.0

package/dist/main.js

@@ -15666,6 +15666,17 @@ var getWorkContextInputSchema = external_exports.strictObject({
 }).refine((v) => v.issue === void 0 !== (v.project === void 0), {
   message: "pass exactly one of `issue` or `project` \u2014 an issue names its own project, and passing neither names nothing to read"
 });
+var openReviewInputSchema = external_exports.strictObject({
+  epic: issueRefSchema.optional(),
+  project: projectRefSchema.optional(),
+  milestone: external_exports.string().min(1, { message: "milestone must not be empty \u2014 name the token the review reads" }).optional()
+}).refine((v) => {
+  const epicForm = v.epic !== void 0 && v.project === void 0 && v.milestone === void 0;
+  const milestoneForm = v.epic === void 0 && v.project !== void 0 && v.milestone !== void 0;
+  return epicForm !== milestoneForm;
+}, {
+  message: "pass exactly one of `epic` or `project` + `milestone` \u2014 an epic names its own project and milestone, and passing neither names nothing to review"
+});
 var claimInputSchema = external_exports.strictObject({
   issue: issueRefSchema
 });
@@ -16019,7 +16030,12 @@ var deleteOrgInstructionInputSchema = external_exports.strictObject({
 });
 
 // ../../libs/domain/dist/instructions.js
-var ISSUE_WRITE_TOOLS = ["create_issue", "update_issue", "promote_feedback"];
+var ISSUE_WRITE_TOOLS = [
+  "create_issue",
+  "update_issue",
+  "promote_feedback",
+  "open_review"
+];
 var INSTRUCTION_SCOPE_TARGETS = {
   general: { kind: "server" },
   requirements: { kind: "tools", tools: ["create_requirement", "update_requirement"] },
@@ -16220,6 +16236,14 @@ var ApiClient = class _ApiClient {
   createIssue(input) {
     return this.request("POST", "/api/v1/issues", { body: input });
   }
+  /**
+   * Opens a completion review (PIPE-217) — `{epic}` or `{project, milestone}`,
+   * exactly one. Returns the created task: a review is an ordinary issue, so this
+   * is the same detail payload the create path returns.
+   */
+  openReview(input) {
+    return this.request("POST", "/api/v1/reviews", { body: input });
+  }
   /** Promotes a feedback issue into a new epic or task (PIPE-143). */
   promoteFeedback(ref, input) {
     return this.request("POST", `/api/v1/issues/${enc(ref)}/promote`, { body: input });
@@ -16576,7 +16600,7 @@ var ApiClient = class _ApiClient {
   // --- the waiting queue -----------------------------------------------------
   /**
    * Every gate awaiting a person across ALL projects of the caller's organisation
-   * (PIPE-87): revisions awaiting approval, questions awaiting an answer, and epics
+   * (PIPE-87): revisions awaiting approval, questions awaiting an answer, and work
    * in `verify` with a criterion not yet passed, longest wait first.
    *
    * Takes NO project and NO org: a queue you point at a project is the per-project
@@ -16990,7 +17014,7 @@ Every loose end has one destination, and none of them is prose. Anything you not
     }
   }, (args) => run(() => client2.createProject(args)));
   registerTool("list_waiting", {
-    description: "Every gate awaiting a PERSON across ALL projects in the token\u2019s org, longest wait first: a requirement revision awaiting approval, a question awaiting an answer, and an epic 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 an epic), and `waitingSince` \u2014 the instant the wait began, not a duration. Nothing else is a gate: work in `triage` never appears, and neither does an epic in verify whose criteria have ALL passed. READ-ONLY, and there is no tool on this surface that clears any of the three \u2014 approving a revision, answering a question and marking a manual criterion are all decisions a person takes 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 token\u2019s org, 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. READ-ONLY, and there is no tool on this surface that clears any of the three \u2014 approving a revision, answering a question and marking a manual criterion are all decisions a person takes in the web app. Use it to see what your work is blocked on before asking, rather than to act on it."
     // NO arguments — not even an org. Org scope arrives from the token, exactly as
     // it does for `list_projects`, and an org parameter would open a cross-org read
     // path that has no precedent anywhere on this surface. The viewer narrowing the
@@ -17111,6 +17135,14 @@ Every loose end has one destination, and none of them is prose. Anything you not
       ...promoteFeedbackInputSchema.shape
     }
   }, ({ issue: issue2, ...fields }) => run(() => client2.promoteFeedback(issue2, fields)));
+  registerTool("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 nothing is left to check, and before anyone sets it `done`. It creates one ORDINARY `task` at `ready` carrying the review checklist as its body \u2014 no new record type. 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 \u2014 nothing here models a milestone as complete. 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 \u2014 and a review opens only on an epic (`review_target_not_epic`). NO NEW GATE was added to `done`, and the whole mechanism depends on that: 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. An epic that never opened a review still closes exactly as it did before.",
+    // 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
+    // caller, and both arguments (or neither) would be accepted here.
+    inputSchema: openReviewInputSchema
+  }, (args) => run(() => client2.openReview(args)));
   registerTool("update_issue", {
     description: 'Update any subset of an issue\u2019s title, body, type, priority, milestone, environment, parent (self/cycle rejected), 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. Cite the decision record a piece of work implements rather than restating what was decided in its body: the record is where the reasoning stays correct, and a body repeating it goes stale the moment the decision is superseded. Link another record by key plus title on first mention; never paste its text into a body \u2014 the source changes, the copy does not, and a stale copy gets built. A decision you need from the operator is filed as a question via `ask_questions`, never written as an "Open questions" heading inside a body \u2014 a heading prompts nobody and records no answer, so a later session cannot tell whether the decision was made. Cross-cutting requirements bind every epic automatically and arrive with `get_issue` \u2014 never restate them in a body and never add them to `requirement_links`; an explicit link pins the linked document\u2019s approved revision.',
     inputSchema: updateIssueInputSchema.shape
@@ -17427,7 +17459,7 @@ function loadMcpConfig() {
 }
 
 // src/version.ts
-var VERSION = "0.26.0";
+var VERSION = "0.28.0";
 
 // src/main.ts
 var config2 = loadMcpConfig();

package/package.json

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