pipebrain-mcp 0.50.0 → 0.52.0

package/dist/main.js

@@ -383,9 +383,9 @@ var AGENT_CONFIG_ENTRIES = [
   { target: "skills/capture-correction/SKILL.md", sha256: "907ee8fc8e7ea15c8296acd23a816e1f9c6454edcf37a93f18af79b1c542fb75" },
   { target: "skills/pipebrain-header-pass/SKILL.md", sha256: "10545e3c1c5215b031e1c76281e65cd2ecf7420b3f07a4221824591a8263c5fc" },
   { target: "skills/pipebrain-secrets/SKILL.md", sha256: "52c2136a3cca5612981d50b926195eae3e804911e1e9723dd5eba76e66b52d6f" },
-  { target: "skills/pipebrain-work-session/SKILL.md", sha256: "09d5741761b43fc13a12a04117edd8b194aac18974bfedb42dfc76c14030ba87" },
+  { target: "skills/pipebrain-work-session/SKILL.md", sha256: "c1b701d167c62123f6fe38dae35a7dc6c9d0a8f2a9881efabc6b98d0caf14863" },
   { target: "skills/pipebrain-writing/SKILL.md", sha256: "8e5ed4636afcca0cacc220d8fa5310364d2d6854a9fc68ffa03e4c428989f8b8" },
-  { target: "skills/pipebrain/SKILL.md", sha256: "e53a1cb13d4e2e396c638d8f99055f4082edef030a40ffc8806b1f52f0824b57" },
+  { target: "skills/pipebrain/SKILL.md", sha256: "9fdad1b78bb506e9cd91ba55f4baee0adc5f4d2c5d9d418d0e8c922554e8df74" },
   { target: "skills/requirements-altitude/SKILL.md", sha256: "60d1916da22a52138c046fcf4e5cd4cc420b7a5679a6652eb76573b7a69a1cf4" }
 ];
 
@@ -505,7 +505,7 @@ function apiBindingLabel(apiBaseUrl) {
 }
 
 // ../../libs/agent-shared/dist/doctrine.js
-var DOCTRINE = "# Pipebrain doctrine\n\nHow an agent works inside Pipebrain. These rules ship with the product and are the same in every organization. Each one protects something the product guarantees.\n\n## How to write here\n\nThe person reading what you write is the operator, deciding something. They have about two minutes. Put the point first. Use short sentences and ordinary words. Headings and bullets are fine. Explain why once, not under every bullet.\n\nA criterion is one sentence: a concrete situation, and what must be true afterward. If you need a general rule, write two or three criteria instead.\n\nEvidence on a criterion opens with the verdict, then how you drove it, then what it does not cover. Keep it to one screen; name the test or command, not every file you read.\n\nA closing comment says what landed, what did not and why, what you filed by key, and whether the tests are green.\n\nAnything else you notice goes to a question, when the operator has to choose; to a new issue at triage, when it is real work; or, most often, nowhere. Never add a notes, caveats, or next-steps section. An item filed and repeated in prose gets triaged twice.\n\nYour organization may add its own writing rules below this document. Most have none.\n\n## Search before you create\n\nLook for an existing record before you add one. A duplicate splits one record's history across two keys, and nothing merges them later. Update or link the record you find.\n\n## Link by key, never paste\n\nRefer to a requirement, decision, or issue by its key. Never paste its text into a body. When the source changes the copy stays stale, and the stale copy is what gets built.\n\n## Most choices are yours\n\nInside an approved requirement you choose the design, the libraries, and the order of work. Ask only when a choice changes what a user sees, costs money, or contradicts a requirement; file that one as a question. Asking about everything makes real questions wait behind choices that were yours. A technical choice worth keeping goes in a decision record.\n\n## File decisions as questions\n\nAn open decision goes in a question on the issue, filed with `ask_questions` and carrying the options you propose. It does not belong in a body, under a heading or in a field. Prose asks nobody and records no answer, so a later session cannot tell whether it was ever decided. Withdraw a question your own work has settled.\n\n## Cross-cutting requirements arrive on their own\n\nThey bind every epic and come back with a work-item read, at their latest approved revision. Never restate them in a body and never add them as explicit requirement links. A copy drifts, and an explicit link pins one revision where the read delivers the newest.\n\n## Conventions need a person's approval\n\nApproved conventions come back with the same work-item read and bind every project in the organization. Never restate one in a body and never add one as an explicit link; a copy goes stale.\n\nA convention you create or amend over the agent surface is a proposal. It is not in force until a person approves it in a browser. Until then, do not work from your own unapproved wording.\n\nA statement that stops being true when this project ends is a cross-cutting requirement. One still true on the next project is a convention. File one when an evaluator rejects work or a criterion fails, and rarely otherwise: each reaches every read, after a person reviews it.\n\n## Choosing auto or manual\n\nFirst find out what this project can drive end to end, and with which command. A criterion is `auto` when an evaluator can drive the input and read the result on the running system, including an interface where a browser harness exists. Only the evaluator's own run qualifies it; a test the implementer wrote does not. An auto criterion nobody can drive never gets evidence.\n\nMark a criterion `manual` only when the verdict needs a person's judgment. A manual row a machine could have checked holds the issue open until a person gets to it. If you cannot say how to drive a criterion, it is worded too vaguely; reword it against something observable. A manual criterion carries instructions for a stranger to the code.\n\nA manual criterion with no recorded artifact is the human gate working as designed, and not a finding.\n\n## The bar for filing a bug\n\nFile a bug only when the behavior breaks an approved requirement or a defined acceptance criterion, and name which one first. Everything else, including unclear code and edge cases nobody specified, is feedback or nothing. A queue that mixes defects with taste has to be read in full before any of it can be trusted.\n\n## A decision record is written once\n\nA decision record says what was decided and why, at the time. Do not edit it later; write a superseding record instead. The chain of records shows how the thinking changed, and an edit destroys it. Read existing records before reopening a settled question.\n\n## A secret value never travels in a tool call\n\nNo tool returns a secret value, by design, and none should receive one. A value in a tool call is in the transcript before the server can encrypt it; the only remedy is rotation. Set values with the command-line tool, from a file or standard input, and inject at run time.\n\n## Setting an instruction replaces the whole body\n\nThere is no partial update. An instruction write stores exactly the body you supply and discards everything that was there. Read the live value, compose the complete replacement, write it, then read it again to confirm what landed.\n\nThis guidance and the tool descriptions are a snapshot from the session's start; an edit reaches the next session, never this one. `list_org_instructions` returns the saved rows as they are now; that is the confirming read.\n";
+var DOCTRINE = "# Pipebrain doctrine\n\nHow an agent works inside Pipebrain. These rules ship with the product and are the same in every organization. Each one protects something the product guarantees.\n\n## How to write here\n\nThe person reading what you write is the operator, deciding something. They have about two minutes. Put the point first. Use short sentences and ordinary words. Headings and bullets are fine. Explain why once, not under every bullet.\n\nA criterion is one sentence: a concrete situation, and what must be true afterward. If you need a general rule, write two or three criteria instead.\n\nEvidence on a criterion opens with the verdict, then how you drove it, then what it does not cover. Keep it to one screen; name the test or command, not every file you read.\n\nA closing comment says what landed, what did not and why, what you filed by key, and whether the tests are green.\n\nAnything else you notice goes to a question, when the operator has to choose; to a new issue at triage, when it is real work; or, most often, nowhere. Never add a notes, caveats, or next-steps section. An item filed and repeated in prose gets triaged twice.\n\nYour organization may add its own writing rules below this document. Most have none.\n\n## Search before you create\n\nLook for an existing record before you add one. A duplicate splits one record's history across two keys, and nothing merges them later. Update or link the record you find.\n\n## Link by key, never paste\n\nRefer to a requirement, decision, or issue by its key. Never paste its text into a body. When the source changes the copy stays stale, and the stale copy is what gets built.\n\n## Most choices are yours\n\nInside an approved requirement you choose the design, the libraries, and the order of work. Ask only when a choice changes what a user sees, costs money, or contradicts a requirement; file that one as a question. Asking about everything makes real questions wait behind choices that were yours. A technical choice worth keeping goes in a decision record.\n\n## A branch and a worktree are derived from the issue\n\nReading an issue's work context returns its branch, its base and its worktree already resolved, each saying where it came from, and how the work leaves the branch. A value the issue, its ancestors and its project all leave unset is derived: the branch and the worktree label are the issue's display id in lower case, which is the project key, a hyphen and the number, and the base is main, which a project changes in its settings. Two sessions reading one issue compute the same names, so a session resuming abandoned work finds what the session before it used. Reading a project returns the work you could pick up and no placement, because no issue has been chosen yet.\n\nClaim the work naming the branch and the worktree you were given. Naming them is what reserves them: a claim is refused when another live claim in the project already holds either. A field you leave out keeps whatever the issue already records, so a claim that names nothing on an issue that records nothing reserves nothing, and a second session is free to take the same tree.\n\nA worktree is a label, not a path. Whoever runs the session maps that label to a directory, because a path recorded here would be true only on the machine that wrote it. Create a working tree when nothing on this machine answers to the label, and reuse the one already there when something does; a branch checked out in one tree cannot be checked out in another. Only the machine can answer that. What the placement tells you is a different thing worth knowing, and it says it for the branch and the worktree separately: whether another issue in this project is already placed on that same value, so you can see whether you are joining work or starting it.\n\nA claim you find under your own session identifier is work to resume rather than work to start. Read what the issue records, look at what the tree holds, and carry on from there. Claiming it again is refused, and starting it again abandons whatever the earlier session left.\n\nA working tree holding uncommitted changes is never removed. Report it and leave it alone. Nothing can tell deliberate work from residue, and removing it cannot be undone.\n\n## File decisions as questions\n\nAn open decision goes in a question on the issue, filed with `ask_questions` and carrying the options you propose. It does not belong in a body, under a heading or in a field. Prose asks nobody and records no answer, so a later session cannot tell whether it was ever decided. If your own work settles a question, answer it with `answer_question` \u2014 the answer is worth keeping, and withdrawing throws it away. Withdraw only a question that should never have been asked.\n\n## Cross-cutting requirements arrive on their own\n\nThey bind every epic and come back with a work-item read, at their latest approved revision. Never restate them in a body and never add them as explicit requirement links. A copy drifts, and an explicit link pins one revision where the read delivers the newest.\n\n## Conventions need a person's approval\n\nApproved conventions come back with the same work-item read and bind every project in the organization. Never restate one in a body and never add one as an explicit link; a copy goes stale.\n\nA convention you create or amend over the agent surface is a proposal. It is not in force until a person approves it in a browser. Until then, do not work from your own unapproved wording.\n\nA statement that stops being true when this project ends is a cross-cutting requirement. One still true on the next project is a convention. File one when an evaluator rejects work or a criterion fails, and rarely otherwise: each reaches every read, after a person reviews it.\n\n## Choosing auto or manual\n\nFirst find out what this project can drive end to end, and with which command. A criterion is `auto` when an evaluator can drive the input and read the result on the running system, including an interface where a browser harness exists. Only the evaluator's own run qualifies it; a test the implementer wrote does not. An auto criterion nobody can drive never gets evidence.\n\nMark a criterion `manual` only when the verdict needs a person's judgment. A manual row a machine could have checked holds the issue open until a person gets to it. If you cannot say how to drive a criterion, it is worded too vaguely; reword it against something observable. A manual criterion carries instructions for a stranger to the code.\n\nA manual criterion with no recorded artifact is the human gate working as designed, and not a finding.\n\nThis choice also decides who can finish the work. What gates finishing is the work rather than the caller \u2014 the status tool names what the gate reads, and the server never asks who is calling. A manual row is the one a credential cannot pass, so work carrying one waits for a person; work whose criteria are all machine-checked does not, and the session that has just passed them can set it done.\n\n## The bar for filing a bug\n\nFile a bug only when the behavior breaks an approved requirement or a defined acceptance criterion, and name which one first. Everything else, including unclear code and edge cases nobody specified, is feedback or nothing. A queue that mixes defects with taste has to be read in full before any of it can be trusted.\n\n## A decision record is written once\n\nA decision record says what was decided and why, at the time. A proposed record is still being written: correct it with `update_decision`, and accept it once it says what you decided. An accepted record is settled, so never edit one; write a superseding record instead. The chain of records shows how the thinking changed, and an edit destroys it. Read existing records before reopening a settled question.\n\n## A secret value never travels in a tool call\n\nNo tool returns a secret value, by design, and none should receive one. A value in a tool call is in the transcript before the server can encrypt it; the only remedy is rotation. Set values with the command-line tool, from a file or standard input, and inject at run time.\n\n## Setting an instruction replaces the whole body\n\nThere is no partial update. An instruction write stores exactly the body you supply and discards everything that was there. Read the live value, compose the complete replacement, write it, then read it again to confirm what landed.\n\nThis guidance and the tool descriptions are a snapshot from the session's start; an edit reaches the next session, never this one. `list_org_instructions` returns the saved rows as they are now; that is the confirming read.\n";
 
 // ../../libs/agent-shared/dist/org-reference.js
 var CANONICAL_UUID_RE = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;
@@ -15058,6 +15058,7 @@ var issueStatusSchema = external_exports.enum([
   "done",
   "killed"
 ]);
+var integrationModeSchema = external_exports.enum(["pull_request", "push", "none"]);
 var OPEN_STATUSES = [
   "triage",
   "backlog",
@@ -15184,6 +15185,7 @@ var deliverableTargetLabelSchema = external_exports.string().min(1, { message: "
 var projectNameSchema = external_exports.string().min(1, { message: "project name must not be empty" });
 var tokenLabelSchema = external_exports.string().min(1, { message: "token label must not be empty" });
 var contentMetadataSchema = external_exports.record(external_exports.string(), external_exports.unknown());
+var sessionIdSchema = external_exports.string().min(1, { message: "session must not be empty \u2014 omit it to read without a session" });
 
 // ../../libs/domain/dist/display-id.js
 var DisplayIdError = class extends Error {
@@ -15442,7 +15444,28 @@ var projectSchema = external_exports.object({
   environments: external_exports.array(projectEnvironmentSchema),
   milestones: external_exports.array(projectMilestoneSchema),
   deliverableTargets: external_exports.array(projectDeliverableTargetSchema),
-  openIssueCount: external_exports.number().int().nonnegative()
+  openIssueCount: external_exports.number().int().nonnegative(),
+  /**
+   * What an issue's placement falls back to when neither it nor any ancestor carries a
+   * value (PIPE-444). A person edits these in project settings; agents never write them,
+   * which is what keeps one writer per field (PIPE-D46).
+   *
+   * `.nullable()` and REQUIRED, like `defaultEnvironmentId` above rather than optional
+   * like the issue header fields: the columns exist on every project and the wire mapper
+   * sends all three on every row, so an absent key would mean a server predating them
+   * while `null` means this project sets no default. Optional would make those two
+   * indistinguishable.
+   */
+  defaultBranch: external_exports.string().nullable(),
+  defaultWorktree: external_exports.string().nullable(),
+  defaultBase: external_exports.string().nullable(),
+  /**
+   * How work leaves its branch (PIPE-445). NOT nullable, unlike the three above: those
+   * are nullable because null there means "ask the next level up" and the walk is the
+   * feature. There is no walk here — the value is read from the project and nowhere
+   * else — so a null could only mean "no answer", and work context has to return one.
+   */
+  defaultIntegrationMode: integrationModeSchema
 });
 var environmentSchema = external_exports.object({
   id: uuidSchema,
@@ -16041,7 +16064,20 @@ var updateIssueInputSchema = external_exports.strictObject({
   parent: issueRefSchema.nullable().optional(),
   requirementLinks: requirementLinkChangesSchema.optional(),
   deliverableLinks: deliverableLinkChangesSchema.optional(),
-  decisionLinks: decisionLinkChangesSchema.optional()
+  decisionLinks: decisionLinkChangesSchema.optional(),
+  /**
+   * Where the work happens (PIPE-444) — this is the placement write. An agent records
+   * here what a claim did not name, or corrects what it did.
+   *
+   * `.nullable().optional()`, like `milestone` and `parent` above: omitting a field
+   * leaves it, and passing `null` CLEARS the issue's own value so it falls back to the
+   * nearest ancestor carrying one and then to the project default. The two are different
+   * asks and a schema that could not tell them apart would make an issue's own value
+   * impossible to remove.
+   */
+  branch: external_exports.string().min(1, { message: "branch must not be empty \u2014 pass null to clear it" }).nullable().optional().describe("The branch this issue\u2019s work happens on. Pass null to clear it, so the issue inherits from the nearest ancestor carrying one and then from the project default."),
+  worktree: external_exports.string().min(1, { message: "worktree must not be empty \u2014 pass null to clear it" }).nullable().optional().describe("A label for the working tree this issue\u2019s work happens in \u2014 never a path, which is true only on the machine that wrote it. Pass null to clear it."),
+  base: external_exports.string().min(1, { message: "base must not be empty \u2014 pass null to clear it" }).nullable().optional().describe("What this issue\u2019s work integrates into. Pass null to clear it, so the issue inherits from its chain and then from the project default.")
 });
 var ISSUE_SUMMARY_MAX = 350;
 function inPlainWords(schema, field) {
@@ -16079,7 +16115,18 @@ var getIssueInputSchema = external_exports.strictObject({
 });
 var getWorkContextInputSchema = external_exports.strictObject({
   issue: issueRefSchema.optional(),
-  project: projectRefSchema.optional()
+  project: projectRefSchema.optional(),
+  /**
+   * The reader's own agent session (PIPE-443). It narrows the project form's
+   * `available` list to work no OTHER session of the same person is holding.
+   *
+   * Accepted on BOTH forms rather than refused alongside `issue`, even though the item
+   * form returns no list for it to narrow. A session that knows its own identifier
+   * passes it on every call it makes; refusing it here would make that one call the
+   * exception and buy nothing, since naming a session cannot change what an item read
+   * returns.
+   */
+  session: sessionIdSchema.optional()
 }).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"
 });
@@ -16095,7 +16142,12 @@ var openReviewInputSchema = external_exports.strictObject({
   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
+  issue: issueRefSchema,
+  session: sessionIdSchema.optional(),
+  branch: external_exports.string().min(1, { message: "branch must not be empty \u2014 omit it to keep the branch already recorded" }).optional(),
+  worktree: external_exports.string().min(1, {
+    message: "worktree must not be empty \u2014 omit it to keep the worktree already recorded"
+  }).optional()
 });
 var setBlockedInputSchema = external_exports.strictObject({
   issue: issueRefSchema,
@@ -16273,6 +16325,17 @@ var listIssuesFilterSchema = external_exports.strictObject({
   // the same reason `blocked` is one — a filter the server quietly dropped returns
   // everything and reads exactly like one that matched everything.
   needsHeader: external_exports.boolean().optional(),
+  /**
+   * The reader's own agent session (PIPE-443). Naming one drops every issue held under a
+   * DIFFERENT session identifier, so an operator running several agents against one
+   * repository stops having each of them offered the work the others hold. Omitting it
+   * is today's behaviour exactly: a person in a browser has no session, and their own
+   * claims stay in the list.
+   *
+   * An issue whose claim named no session is never dropped by this, whichever session
+   * asks — the filter narrows to sessions that said who they were.
+   */
+  session: sessionIdSchema.optional(),
   // Pagination — server default 200, max 500 (§9); default applied server-side.
   limit: external_exports.number().int().min(1, { message: "limit must be at least 1" }).max(500, { message: "limit must be at most 500" }).optional(),
   offset: external_exports.number().int().nonnegative().optional()
@@ -16777,8 +16840,16 @@ var ApiClient = class _ApiClient {
   updateIssue(ref, fields) {
     return this.request("PATCH", `/api/v1/issues/${enc(ref)}`, { body: fields });
   }
-  claimIssue(ref) {
-    return this.request("POST", `/api/v1/issues/${enc(ref)}/claim`);
+  /**
+   * Claims an issue, optionally reserving where the work happens (PIPE-442). A field
+   * `placement` omits keeps whatever the issue already recorded; the call never clears
+   * one. Refused 409 `placement_conflict` when another live claim in the project holds
+   * the branch or the worktree.
+   */
+  claimIssue(ref, placement) {
+    return this.request("POST", `/api/v1/issues/${enc(ref)}/claim`, {
+      body: placement ?? {}
+    });
   }
   releaseIssue(ref) {
     return this.request("POST", `/api/v1/issues/${enc(ref)}/release`);
@@ -16877,8 +16948,9 @@ var ApiClient = class _ApiClient {
   /**
    * Answers a question by its stable `Q-{n}` number with EXACTLY one of `option`
    * (1-based, into the question's options) or `text` (PIPE-93); answering again
-   * revises. Session only — a bearer caller is refused, so this is the web app's
-   * call, never the MCP's. Returns the updated detail.
+   * revises. Token OR session (PIPE-450): the bearer refusal PIPE-R22 r2 withdrew is
+   * gone, and the answer records the credential behind it instead. Returns the updated
+   * detail.
    */
   answerQuestion(ref, number4, answer) {
     return this.request("POST", `/api/v1/issues/${enc(ref)}/questions/${number4}/answer`, { body: answer });
@@ -17208,9 +17280,12 @@ var ApiClient = class _ApiClient {
   }
   // --- the waiting queue -----------------------------------------------------
   /**
-   * Every gate awaiting a person across ALL projects of the caller's organisation
+   * Everything not moving on its own across ALL projects of the caller's organisation
    * (PIPE-87): revisions awaiting approval, questions awaiting an answer, and work
-   * in `verify` with a criterion not yet passed, longest wait first.
+   * in `verify` with a criterion not yet passed, longest wait first. Not all of it
+   * waits on a person — a question clears with `answer_question` and an `auto`
+   * criterion with `set_criterion_state`; the one a credential cannot pass is a
+   * criterion marked for human judgment.
    *
    * 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,
@@ -17241,7 +17316,9 @@ var ApiClient = class _ApiClient {
    * answer.
    */
   getWorkContext(input) {
-    return input.issue !== void 0 ? this.request("GET", `/api/v1/issues/${enc(input.issue)}/work-context`) : this.request("GET", `/api/v1/projects/${enc(input.project)}/work-context`);
+    return input.issue !== void 0 ? this.request("GET", `/api/v1/issues/${enc(input.issue)}/work-context`) : this.request("GET", `/api/v1/projects/${enc(input.project)}/work-context`, {
+      query: input.session === void 0 ? {} : { session: input.session }
+    });
   }
   // --- secrets ---------------------------------------------------------------
   // Metadata only: no method here returns a secret VALUE (the reveal plane is a
@@ -17675,7 +17752,7 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
     );
   }
   registerStrict("list_orgs", {
-    description: "List the organizations this credential may act in, with each name, slug, id, kind and your role. This is the one tool that needs no `org`: every other call names the organization it acts in and is refused without one, and this is how you find the names you may use. The answer is your memberships right now, which is what that check reads, so a joined organization appears and a left one does not."
+    description: "List the organizations this credential may act in, with each name, slug, id, kind and your role. Use it to find the names you may pass. This is the one tool that needs no `org`: every other call names the organization it acts in, and omitting it is refused unless this session has a default. The answer is your memberships right now, so a joined organization appears and a left one does not."
   }, () => (
     // A BARE ARRAY, unlike `list_waiting`'s `{ items }`, and for the reason that tool
     // gives rather than against it: the envelope has already been unwrapped by
@@ -17715,7 +17792,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 named by `org`, longest wait first: a requirement revision awaiting approval, a question awaiting an answer, and work at verify still holding a criterion that has not passed. Each entry names its project, the ref to act on, and when the wait began. Read-only, and it clears nothing. A revision clears with `approve_requirement`. Use it to see what is waiting before you ask."
+    description: "Everything not moving on its own across all projects in the organization named by `org`, longest wait first: a requirement revision awaiting approval, an unanswered question, and work at verify holding a criterion that has not passed. Each entry names its project, the ref to act on, and when the wait began. Read-only. A revision clears with `approve_requirement`, a question with `answer_question`, an `auto` criterion with `set_criterion_state`. A criterion marked for human judgment waits for a person."
   }, () => (
     // `{ items }`, mirroring the HTTP envelope rather than unwrapping to a bare array
     // like the sibling list tools. The reason is the envelope itself: this tool is a
@@ -17738,7 +17815,7 @@ function createMcpServer(baseClient, 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 starting work. Call it first: it alone returns the doctrine and the organization\u2019s writing rules in full. Address it by `issue` or `project`, never both. An issue returns its detail plus the text of each requirement it links, comments capped at `commentLimit` (default " + WORK_CONTEXT_COMMENT_LIMIT + "), with `commentCount` the true total. A project returns `available` \u2014 startable work, excluding done, killed, blocked, person-reserved and others\u2019 claims \u2014 capped at `availableLimit` with `availableCount` as the true total. Read-only.",
+      description: "Everything a session needs before starting work. Call it first: it alone returns the doctrine and your organization\u2019s writing rules in full. Pass `issue` or `project`, never both. An issue returns its detail plus each linked requirement\u2019s text, comments capped at `commentLimit` (default " + WORK_CONTEXT_COMMENT_LIMIT + "), with `commentCount` the true total. A project returns `available` \u2014 startable work, excluding done, killed, blocked, person-reserved, others\u2019 claims and, with `session`, your other sessions\u2019 \u2014 capped at `availableLimit` beside the true `availableCount`. Read-only.",
       inputSchema: getWorkContextInputSchema,
       // THE TWO ANNOTATIONS PIPE-D30 REQUIRES, and the reason each key is spelled out
       // rather than built: an unknown `_meta` key is IGNORED — no error, no warning — so a
@@ -17851,7 +17928,7 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
   registerStrict(
     "list_issues",
     {
-      description: "List issue summaries \u2014 status, priority, milestone, claimer, criteria progress and the header \u2014 filtered by project, status, type, claimer, priority, milestone, text, parent, blocked and needsHeader. With no status filter the default is buildable work only: " + OPEN_STATUSES.join(", ") + '. Terminal work is excluded until you name it, so pass status ["done","killed"] for finished and abandoned work. An explicit filter is used verbatim, never merged. needsHeader true returns the issues whose header is missing or stale.',
+      description: "List issue summaries \u2014 status, priority, milestone, claimer, criteria progress and the header \u2014 filtered by project, status, type, claimer, priority, milestone, text, parent, blocked, needsHeader and session. With no status filter the default is buildable work: " + OPEN_STATUSES.join(", ") + '. Terminal work is excluded until you name it: pass status ["done","killed"]. An explicit filter is used verbatim, never merged. needsHeader true returns issues whose header is missing or stale; session drops work another session holds.',
       inputSchema: listIssuesFilterSchema.shape
     },
     // The default lives in the API now, not here (PIPE-D35, Listing issues
@@ -17895,22 +17972,22 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
     })
   ), GUIDANCE_POINTER));
   registerStrict("create_issue", {
-    description: "Create an epic, task, bug or feedback. Status defaults to triage; anything but triage or killed needs a milestone, else refused `milestone_required`. Optional parent, priority, milestone, links and ordered criteria. An open issue under a done or killed parent is refused `parent_terminal`. Epics, tasks and bugs carry criteria; feedback is refused `criteria_not_supported`. A `manual` criterion needs `howTo`, else refused `how_to_required`. A bug may name the criterion it was filed against. See the doctrine `get_work_context` returns, under \u201CSearch before you create\u201D.",
+    description: "Create an epic, task, bug or feedback. Status defaults to triage; anything but triage or killed needs a milestone, else refused `milestone_required`. An archived milestone is refused `milestone_archived_write`. An open issue under a done or killed parent is refused `parent_terminal`. Epics, tasks and bugs carry criteria; feedback is refused `criteria_not_supported`. A `manual` criterion needs `howTo`, else refused `how_to_required`. A bug may name the criterion it was filed against. See the doctrine `get_work_context` returns, under \u201CSearch before you create\u201D.",
     inputSchema: createIssueInputSchema.shape
   }, (args) => run(() => client2().createIssue(args)));
   registerStrict("promote_feedback", {
-    description: "Retype a feedback report as real work \u2014 an epic or a task \u2014 so it can carry criteria and be built. Feedback itself is refused `criteria_not_supported`, which is what this call resolves. Closing the source feedback is refused `status_guard` when anything beneath it, at any depth, is not done or killed, and the refusal names it. A `manual` criterion needs `howTo`, or it is refused `how_to_required`. See the doctrine `get_work_context` returns, under \u201CThe bar for filing a bug\u201D.",
+    description: "Retype a feedback report as real work \u2014 an epic or a task \u2014 so it can carry criteria and be built. Feedback itself is refused `criteria_not_supported`. Scheduling the new work into an archived milestone is refused `milestone_archived_write`. Closing the source feedback is refused `status_guard` when anything beneath it, at any depth, is not done or killed. A `manual` criterion needs `howTo`, else refused `how_to_required`. See the doctrine `get_work_context` returns, under \u201CThe bar for filing a bug\u201D.",
     inputSchema: {
       issue: external_exports.string().min(1),
       ...promoteFeedbackInputSchema.shape
     }
   }, ({ issue: issue2, ...fields }) => run(() => client2().promoteFeedback(issue2, fields)));
   registerStrict("open_review", {
-    description: "Open the completion review of an epic\u2019s whole change, by a session that neither built nor evaluated it. It creates one task at ready carrying the checklist. Pass exactly one of `epic`, or `project` plus `milestone`. One review stands per scope; a second is refused `review_already_open`. An epic-form review also holds that milestone scope; a milestone-form review blocks no epic. File findings as children of the epic, not the review. See the doctrine `get_work_context` returns, under \u201CHow to write here\u201D.",
+    description: "Open an epic\u2019s completion review, read by whoever neither built nor evaluated it: one ready task carrying the checklist. Pass exactly one of `epic`, or `project` plus `milestone`. A first call is refused `review_target_not_epic`, `review_target_terminal` (finished epic), `milestone_required` (no milestone), `milestone_not_found` (unknown token). One review per scope; a second is refused `review_already_open`. Epic-form also holds that milestone scope; milestone-form blocks no epic. File findings under the epic, not the review. See the doctrine `get_work_context` returns, under \u201CHow to write here\u201D.",
     inputSchema: openReviewInputSchema
   }, (args) => run(() => client2().openReview(args)));
   registerStrict("update_issue", {
-    description: "Change an issue\u2019s fields, parent and links. Header fields are refused here; criteria are set with `set_criteria`, which epics, tasks and bugs all carry. Moving an open issue onto a done or killed parent is refused `parent_terminal`; one with open work beneath it is refused `parent_terminal_subtree`. A cycle-closing re-parent is refused `parent_cycle`. Attaching open work starts its new parent unless that parent is blocked, unscheduled or under a finished parent. See the doctrine `get_work_context` returns, under \u201CMost choices are yours\u201D.",
+    description: "Change an issue\u2019s fields, parent and links. Header fields are refused; `set_criteria` sets criteria, which epics, tasks and bugs carry. An archived milestone is refused `milestone_archived_write`, unless the issue or its parent carries it. A cycle-closing re-parent is refused `parent_cycle`. A finished parent refuses an open issue, `parent_terminal`; a finished one holding open work, `parent_terminal_subtree`. Attaching open work starts a parent that is not blocked, unscheduled or under finished work. See the doctrine `get_work_context` returns, under \u201CMost choices are yours\u201D.",
     inputSchema: updateIssueInputSchema.shape
   }, ({ issue: issue2, ...fields }) => run(() => client2().updateIssue(issue2, fields)));
   registerStrict("set_issue_header", {
@@ -17918,13 +17995,13 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
     inputSchema: setIssueHeaderInputSchema.shape
   }, ({ issue: issue2, ...fields }) => run(() => client2().setIssueHeader(issue2, fields)));
   registerStrict("set_status", {
-    description: "Move an issue to a new status. verify needs every auto criterion passed; done needs every criterion passed, and every issue beneath it, at any depth, done or killed \u2014 epic, task or bug alike \u2014 read from status. An epic with no criteria is refused at both gates; a task or bug with none moves through. A blocked issue cannot reach ready or in_progress until its blockers clear. An issue with no milestone can only be triage or killed.",
+    description: "Move an issue to another status. An open status under a done or killed parent is refused `parent_terminal_reopen`. verify needs every auto criterion passed; done needs every criterion passed and everything beneath it, at any depth, done or killed. An epic with no criteria is refused at both gates; a task or bug with none moves through. Blocked work cannot reach ready or in_progress until blockers clear. Work with no milestone can only be triage or killed.",
     inputSchema: setStatusInputSchema.shape
   }, (args) => run(() => client2().setStatus(args.issue, args.status)));
   registerStrict("claim_issue", {
-    description: "Claim an issue for this session. It succeeds only if unclaimed; under a race one caller wins and the loser is told who holds it. Claiming is separate from status. It is refused `reserved_for_person` when an operator has reserved the work for a person \u2014 that mark refuses the claim and nothing else, so reading, commenting and moving status all still work. Only a person in the browser can lift it; say in a comment why the work looks agent-ready.",
-    inputSchema: { issue: issueRefSchema }
-  }, (args) => run(() => client2().claimIssue(args.issue)));
+    description: "Claim an issue for this session and reserve where the work happens. It succeeds only if unclaimed; under a race one caller wins and the loser is told who holds it. `branch` and `worktree` are refused `placement_conflict` when another live claim in the project holds either, naming that issue. A field you omit keeps what the issue already recorded. Claiming is separate from status, and is refused `reserved_for_person` when an operator has kept the work for a person.",
+    inputSchema: claimInputSchema.shape
+  }, ({ issue: issue2, ...placement }) => run(() => client2().claimIssue(issue2, placement)));
   registerStrict("release_issue", {
     description: "Release your claim on an issue, leaving it unclaimed and its status unchanged.",
     inputSchema: { issue: issueRefSchema }
@@ -17977,13 +18054,17 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
     });
   }));
   registerStrict("ask_questions", {
-    description: "Ask the operator one or more questions on an issue. Send the batch in one call \u2014 a half-asked set costs a second pass. Each question gets a stable `Q-{n}` number that is never reused, and `options` are the choices you propose. Answers come back on every later read of the issue, so read them before asking again rather than re-asking a settled decision. Withdraw one with `withdraw_question`. See the doctrine `get_work_context` returns, under \u201CFile decisions as questions\u201D.",
+    description: "Ask the operator questions on an issue. Send them in one call \u2014 a half-asked set costs a second pass. Each question gets a stable `Q-{n}` number, never reused; `options` are the choices you propose. Answers come back on every later read; read them before asking again. Answer one yourself with `answer_question` when your work settles it; withdraw one with `withdraw_question` if it should never have been asked. See the doctrine `get_work_context` returns, under \u201CFile decisions as questions\u201D.",
     inputSchema: askQuestionsInputSchema.shape
   }, (args) => run(() => client2().askQuestions(args.issue, args.questions)));
   registerStrict("withdraw_question", {
-    description: "Withdraw a question by its `Q-{n}` number, in the organization named by `org`. Only the asker may withdraw, and the asker is the person your credential belongs to, so another agent\u2019s question is not yours to clear. Use it when your own work settled the question or it was wrong to ask, rather than leaving the operator to answer something nobody awaits. The question is kept for the audit trail, its number retires, and later reads no longer carry it.",
+    description: "Withdraw a question by its `Q-{n}` number, in the organization named by `org`. Only the asker may withdraw, and the asker is the person your credential belongs to, so another agent\u2019s question is not yours to clear. Use it for a question that should never have been asked; one your own work settled deserves `answer_question` instead, which keeps the answer. The question is kept for the audit trail, its number retires, and later reads no longer carry it.",
     inputSchema: withdrawQuestionInputSchema.shape
   }, (args) => run(() => client2().withdrawQuestion(args.issue, args.number)));
+  registerStrict("answer_question", {
+    description: "Answer a question by its `Q-{n}` number, in the organization named by `org`. Pass exactly one of `option` (a 1-based index into the choices offered) or `text` \u2014 both, or neither, is refused here before anything is sent. Answering again revises; every answer records who answered and which credential. An out-of-range index is refused `option_out_of_range`, naming how many choices there are; a withdrawn or unknown number, `question_not_found`. Answer what your own work settled; leave the rest to the operator.",
+    inputSchema: answerQuestionInputSchema
+  }, (args) => run(() => client2().answerQuestion(args.issue, args.number, { option: args.option, text: args.text })));
   registerStrict("list_requirements", {
     description: "List requirements filtered by project and text: lifecycle (draft/approved/amended), the latest and approved revision numbers, the cross-cutting flag and the linked-epic count.",
     inputSchema: listRequirementsFilterSchema.shape
@@ -18078,6 +18159,18 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
     description: "List decision records filtered by `project` and `text`: each one\u2019s state, its replacement when superseded, and how many requirements and work items cite it. `text` matches title and body.",
     inputSchema: listDecisionsFilterSchema.shape
   }, (args) => run(() => client2().listDecisions(args), GUIDANCE_POINTER));
+  registerStrict("update_decision", {
+    description: "Correct a decision record while it is still `proposed`: `title`, `body`, or both. An edit naming nothing to change is refused here, before anything is sent. Once a record is `accepted` or `superseded` its text is frozen, and the correction is refused `decision_frozen`, which says to write the change as a new record and supersede this one. Use `accept_decision` to accept; asking for `superseded` here is refused, because superseding must name the replacement.",
+    inputSchema: updateDecisionInputSchema
+  }, (args) => run(() => client2().updateDecision(args.decision, {
+    title: args.title,
+    body: args.body,
+    status: args.status
+  })));
+  registerStrict("accept_decision", {
+    description: "Accept a decision record that is still `proposed`: it becomes `accepted`, stamped with who accepted it and when, and its text is frozen from then on \u2014 changing it later means a new record plus `supersede_decision`. The tool names the move, so the record is the only argument. A record that is already `accepted` or `superseded` is refused `decision_transition_not_allowed`, naming what it can still do.",
+    inputSchema: { decision: decisionRefSchema }
+  }, (args) => run(() => client2().updateDecision(args.decision, { status: "accepted" })));
   registerStrict("supersede_decision", {
     description: "Replace an accepted decision record with another: `decision` becomes `superseded` and points at `replacedBy`, where the current decision lives. Refused while the record is still `proposed` (correct it instead), when a record replaces itself, when the replacement is in another project, or when its chain already leads back to this record.",
     inputSchema: supersedeDecisionInputSchema.shape
@@ -18113,7 +18206,7 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
   registerStrict("promote_deliverable", {
     // The paste exception is stated because without it an agent holding the doctrine
     // would refuse this tool's whole purpose.
-    description: "Create a NEW issue from a deliverable (`DRAFT-KEY/platform`) with a protected link pinning its current revision, which cannot be removed. Needs `title` and `type`; `status` defaults to triage, `body` seeds the issue. A `status` past triage or killed needs `milestone`, or it is refused `milestone_required`. Seeding `body` with the post text is the exception to linking rather than pasting. See the doctrine `get_work_context` returns, under \u201CLink by key, never paste\u201D.",
+    description: "Create a NEW issue from a deliverable (`DRAFT-KEY/platform`) with a protected link pinning its current revision, which cannot be removed. Needs `title` and `type`; `status` defaults to triage, `body` seeds the issue. A `status` past triage or killed needs a `milestone`, else refused `milestone_required`. An archived milestone is refused `milestone_archived_write`. Seeding `body` with the post text is the exception to linking rather than pasting. See the doctrine `get_work_context` returns, under \u201CLink by key, never paste\u201D.",
     inputSchema: {
       deliverable: external_exports.string().min(1),
       title: external_exports.string().min(1),
@@ -18293,7 +18386,7 @@ function loadMcpConfig() {
 }
 
 // src/version.ts
-var VERSION = "0.50.0";
+var VERSION = "0.52.0";
 
 // src/main.ts
 async function scopedClient(base, org) {

package/package.json

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