pipebrain-mcp 0.51.0 → 0.53.0

package/dist/main.js

@@ -383,7 +383,7 @@ 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: "1272d0a403b5826a52616cdbf2dc706f69746c21ac6c930e22df87750a2509b7" },
+  { target: "skills/pipebrain-work-session/SKILL.md", sha256: "d65dd271e1fef00bc583eac1cab5007d7c156a43b40ee1698aef1d88e9ae78f9" },
   { target: "skills/pipebrain-writing/SKILL.md", sha256: "8e5ed4636afcca0cacc220d8fa5310364d2d6854a9fc68ffa03e4c428989f8b8" },
   { 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. 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";
+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\nWork in the working tree you reserved, never in a checkout another session may be using; a tree of its own is what lets a session run beside others. The placement you are given, resolved through the issue, its ancestors and the project's settings, is the default for every session, and only the repository's own agent instructions override it: where they dictate one branch and no working trees, or where the branch you are given is the base itself, work in the checkout on that branch, and claim naming the branch and tree you will actually use, so the record says where the work really is.\n\nHow the work leaves the branch is the project's choice too, set in its settings and returned with the placement as one of three values, and it is acted on once the work is green and committed, not before. `pull_request`: push the branch and open a pull request against the base, and leave the merge to a person; where the branch is the base itself there is nothing to open it from, so the session acts as `none` and says so. `push`: merge the branch into the base and push the base, so the work lands with no review step; a merge that cannot complete cleanly is a blocker, never a partial push. `none`: the work stays committed on its branch, and the session pushes, merges and opens nothing; the operator takes it from there. When the session ends and the work has left the branch or is waiting on it, release the claim: the placement stays on the issue, and the tree stays where it is. A session that ends blocked keeps its claim, because the tree may hold uncommitted work and the claim is what tells the next session on that machine to resume it rather than start beside it.\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`);
@@ -17245,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
@@ -17742,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
@@ -17855,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
@@ -17926,9 +17999,9 @@ function createMcpServer(baseClient, apiBaseUrl, orgInstructions2 = /* @__PURE__
     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 }
@@ -18313,7 +18386,7 @@ function loadMcpConfig() {
 }
 
 // src/version.ts
-var VERSION = "0.51.0";
+var VERSION = "0.53.0";
 
 // src/main.ts
 async function scopedClient(base, org) {

package/package.json

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