pipebrain-mcp 0.18.0 → 0.19.0

package/dist/main.js

@@ -15261,6 +15261,11 @@ var criterionSchema = external_exports.object({
   position: external_exports.number().int().nonnegative(),
   text: markdownSchema,
   verification: verificationSchema,
+  // How to check this criterion by hand (PIPE-166) — written by whoever specified
+  // it, carried only on `manual` rows, and null on a row written before the field
+  // existed. Distinct from `stateEvidence` below: written at a different moment,
+  // by a different author, in the opposite direction (what to do, not what was seen).
+  howTo: markdownSchema.nullable(),
   state: criterionStateSchema,
   stateEvidence: markdownSchema.nullable(),
   // Attribution for the last state change — null while pending & untouched (§4).
@@ -15569,7 +15574,13 @@ var orgInstructionSchema = external_exports.object({
 // ../../libs/domain/dist/inputs.js
 var criterionInputSchema = external_exports.strictObject({
   text: markdownSchema.min(1, { message: "criterion text must not be empty" }),
-  verification: verificationSchema.optional()
+  verification: verificationSchema.optional(),
+  howTo: markdownSchema.refine((s) => s.trim().length > 0, {
+    message: "criterion howTo must not be empty \u2014 say how to check this criterion by hand"
+  }).optional()
+}).refine((v) => !(v.verification === "auto" && v.howTo !== void 0), {
+  message: "`howTo` applies to manual criteria only \u2014 an auto criterion is checked by a machine, so instructions on one have no reader",
+  path: ["howTo"]
 });
 var createIssueInputSchema = external_exports.strictObject({
   project: projectRefSchema,
@@ -17035,11 +17046,11 @@ function createMcpServer(client2, apiBaseUrl, orgInstructions2 = /* @__PURE__ */
     inputSchema: { issue: issueRefSchema }
   }, (args) => run(() => client2.getIssue(args.issue)));
   registerTool("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 (self/cycle rejected), 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} 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. Search before you create: `list_issues` takes a `text` filter \u2014 run it on the distinctive nouns first. Sessions do not see each other, so a duplicate is invisible until someone finds both; on a near match, comment or amend the existing record rather than filing again. 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. A criterion may be `auto` (machine-checkable) only when an evaluator can drive the input and read the result against the running system unaided \u2014 an existing test covering it does not make it auto; default to `manual` when unsure. Criteria live on epics only: a task cannot carry a criteria list and instead states in its own body what would count as done. 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.',
+    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 (self/cycle rejected), 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. Search before you create: `list_issues` takes a `text` filter \u2014 run it on the distinctive nouns first. Sessions do not see each other, so a duplicate is invisible until someone finds both; on a near match, comment or amend the existing record rather than filing again. 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. A criterion may be `auto` (machine-checkable) only when an evaluator can drive the input and read the result against the running system unaided \u2014 an existing test covering it does not make it auto; default to `manual` when unsure. A `manual` criterion must also carry `howTo` \u2014 one or two sentences, not an essay, saying where to look, what to do, and what counts as passing for whoever checks it by hand. Writing or changing one without it is refused (`how_to_required`); so is supplying it on an `auto` criterion, which a machine checks. Criteria live on epics only: a task cannot carry a criteria list and instead states in its own body what would count as done. 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: createIssueInputSchema.shape
   }, (args) => run(() => client2.createIssue(args)));
   registerTool("promote_feedback", {
-    description: 'Promote a FEEDBACK issue into a NEW epic or task (PIPE-143): creates the issue in the feedback\u2019s project (`title` + `type` required; omitted environment inherits the FEEDBACK\u2019s environment, not the project default; optional status/body/priority/milestone/requirement_links/criteria as in create_issue), records the feedback as its permanent source (`promotedFrom`/`promotedTo` on both details), closes the feedback as done, and comments the new key on it. The feedback\u2019s own title/body are never touched \u2014 write the new issue\u2019s body as real work, do not paste the feedback in. Rejected (409) for non-feedback, terminal, or already-promoted sources. Returns the created issue. A `status` other than `triage` or `killed` REQUIRES `milestone` (PIPE-R10 rule 9), exactly as in create_issue; the SOURCE feedback needs none to be closed by the promotion. Search before you promote: `list_issues` takes a `text` filter \u2014 run it on the feedback\u2019s distinctive nouns first; an issue covering it may already exist, and sessions do not see each other. On a near match, comment on or amend the existing issue rather than promoting a duplicate. 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. A criterion may be `auto` (machine-checkable) only when an evaluator can drive the input and read the result against the running system unaided \u2014 an existing test covering it does not make it auto; default to `manual` when unsure. Criteria live on epics only: a task cannot carry a criteria list and instead states in its own body what would count as done. 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.',
+    description: 'Promote a FEEDBACK issue into a NEW epic or task (PIPE-143): creates the issue in the feedback\u2019s project (`title` + `type` required; omitted environment inherits the FEEDBACK\u2019s environment, not the project default; optional status/body/priority/milestone/requirement_links/criteria as in create_issue), records the feedback as its permanent source (`promotedFrom`/`promotedTo` on both details), closes the feedback as done, and comments the new key on it. The feedback\u2019s own title/body are never touched \u2014 write the new issue\u2019s body as real work, do not paste the feedback in. Rejected (409) for non-feedback, terminal, or already-promoted sources. Returns the created issue. A `status` other than `triage` or `killed` REQUIRES `milestone` (PIPE-R10 rule 9), exactly as in create_issue; the SOURCE feedback needs none to be closed by the promotion. Search before you promote: `list_issues` takes a `text` filter \u2014 run it on the feedback\u2019s distinctive nouns first; an issue covering it may already exist, and sessions do not see each other. On a near match, comment on or amend the existing issue rather than promoting a duplicate. 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. A criterion may be `auto` (machine-checkable) only when an evaluator can drive the input and read the result against the running system unaided \u2014 an existing test covering it does not make it auto; default to `manual` when unsure. A `manual` criterion must also carry `howTo` \u2014 one or two sentences, not an essay, saying where to look, what to do, and what counts as passing for whoever checks it by hand. Writing or changing one without it is refused (`how_to_required`); so is supplying it on an `auto` criterion, which a machine checks. Criteria live on epics only: a task cannot carry a criteria list and instead states in its own body what would count as done. 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: {
       issue: external_exports.string().min(1),
       ...promoteFeedbackInputSchema.shape
@@ -17082,7 +17093,7 @@ function createMcpServer(client2, apiBaseUrl, orgInstructions2 = /* @__PURE__ */
     inputSchema: linkBlockerInputSchema.shape
   }, (args) => run(() => client2.removeBlocker(args.issue, args.blocker)));
   registerTool("set_criteria", {
-    description: "Epic only: define or replace the ordered acceptance criteria list ({text, verification}). Matched rows keep their stable AC-{n} number; new items get fresh never-reused numbers; removed items are soft-deleted. A matched row keeps its state only when BOTH its text and verification mode are unchanged \u2014 a mode flip resets it to pending (\xA77). A criterion may be `auto` (machine-checkable) only when an evaluator can drive the input and read the result against the running system unaided \u2014 an existing test covering it does not make it auto; default to `manual` when unsure. Criteria live on epics only: a task cannot carry a criteria list and instead states in its own body what would count as done.",
+    description: "Epic only: define or replace the ordered acceptance criteria list ({text, verification, howTo}). Matched rows keep their stable AC-{n} number; new items get fresh never-reused numbers; removed items are soft-deleted. A matched row keeps its state only when BOTH its text and verification mode are unchanged \u2014 a mode flip resets it to pending (\xA77). A criterion may be `auto` (machine-checkable) only when an evaluator can drive the input and read the result against the running system unaided \u2014 an existing test covering it does not make it auto; default to `manual` when unsure. A `manual` criterion must also carry `howTo` \u2014 one or two sentences, not an essay, saying where to look, what to do, and what counts as passing for whoever checks it by hand. Writing or changing one without it is refused (`how_to_required`); so is supplying it on an `auto` criterion, which a machine checks. Criteria live on epics only: a task cannot carry a criteria list and instead states in its own body what would count as done.",
     inputSchema: setCriteriaInputSchema.shape
   }, (args) => run(() => client2.setCriteria(args.issue, args.criteria)));
   registerTool("set_criterion_state", {
@@ -17361,7 +17372,7 @@ function loadMcpConfig() {
 }
 
 // src/version.ts
-var VERSION = "0.18.0";
+var VERSION = "0.19.0";
 
 // src/main.ts
 var config2 = loadMcpConfig();

package/package.json

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