@thehammer/danx-dashboard-mcp 0.1.115 → 0.1.116

package/dist/handlers.js

@@ -619,6 +619,11 @@ export async function issueProblem(client, args) {
             // doesn't yet know about this field).
             if (args.type !== undefined)
                 body.type = args.type;
+            // DX-3309 (follow-up) — sent only when given; the server itself refuses
+            // an `action` add with no summary (400 naming the field), and defaults
+            // an omitted `question` summary to absent (`null`).
+            if (args.summary !== undefined)
+                body.summary = args.summary;
             if (args.solutions !== undefined)
                 body.solutions = args.solutions;
             const result = await client.request({ method: "POST", path: `/${idEnc}/problems`, body, board });
@@ -631,7 +636,12 @@ export async function issueProblem(client, args) {
             return client.request({
                 method: "PATCH",
                 path: `/${idEnc}/problems/${problemId}`,
-                body: { base_hash: baseHash, statement, ...(args.context === undefined ? {} : { context: args.context }) },
+                body: {
+                    base_hash: baseHash,
+                    statement,
+                    ...(args.context === undefined ? {} : { context: args.context }),
+                    ...(args.summary === undefined ? {} : { summary: args.summary }),
+                },
                 board,
             });
         }

package/dist/index.js

@@ -610,33 +610,54 @@ const SOLUTION_FIELDS = {
     con: z.string().optional(),
     recommended: z.boolean().optional(),
 };
-strictTool("issue_problem", "A card's PROBLEMS via /api/issues/:id/problems[/:pid]: one statement the operator must resolve (a question, or a flaw in the plan), each with its own solutions/answers — one problem per question. OPEN = not yet answered; the card needs a human exactly while open_problem_count > 0 — there is no separate flag to set, adding a problem IS putting the card in front of a human. list → live problems in order, each {id, statement, context, type, content_hash, open, solutions[], decisions[]}; add {statement, context?, type?, solutions?} → problem_id + solution_ids in one transaction (zero solutions is valid: the operator answers free-form) plus `problems_reminder: {open_problem_count, instruction}` naming each open problem's solution count; edit :pid {base_hash, statement, context?}; remove :pid {base_hash} — always allowed, even as the card's last open problem (DX-2830: removing it just means the card no longer needs a human). A stale base_hash → 409 `stale_problem` with currentHash + currentProblem: merge, then retry. No answer action — the operator answers in the dashboard. DX-2942 — `statement` is capped at 200 characters (a 400 names the actual length otherwise): write it as ONE plain question, and put any investigation detail in `context` (markdown, no cap) instead of running it on. Good: statement \"Which cache should we use?\", context \"Redis fits the read-heavy path; see benchmark in #123. Memcached is simpler ops but no persistence.\" Bad: statement \"We looked at Redis vs Memcached, ran benchmarks showing Redis 3x faster on reads, but Memcached has simpler ops and we're not sure persistence matters here since the cache is fully rebuildable from Postgres...\" (too long, refused — move it to context). DX-3309 — every problem is also a `type`: read the `type` field's own description below before your first `add`, it teaches which one this is and why the choice matters.", {
+strictTool("issue_problem", "A card's PROBLEMS via /api/issues/:id/problems[/:pid]: one statement the operator must resolve (a question, or a flaw in the plan) OR an action only a person can carry out, each with its own solutions/answers — one problem per question. OPEN = not yet answered; the card needs a human exactly while open_problem_count > 0 — there is no separate flag to set, adding a problem IS putting the card in front of a human. list → live problems in order, each {id, statement, context, type, summary, content_hash, open, solutions[], decisions[]}; add {statement, context?, type?, summary?, solutions?} → problem_id + solution_ids in one transaction (zero solutions is valid: the operator answers free-form) plus `problems_reminder: {open_problem_count, instruction}` naming each open problem's solution count; edit :pid {base_hash, statement, context?, summary?}; remove :pid {base_hash} — always allowed, even as the card's last open problem (DX-2830: removing it just means the card no longer needs a human). A stale base_hash → 409 `stale_problem` with currentHash + currentProblem: merge, then retry. No answer action — the operator answers in the dashboard. DX-2942 — `statement` is capped at 200 characters (a 400 names the actual length otherwise): write it as ONE plain sentence (a question for a question, the deed itself for an action), and put any investigation detail in `context` (markdown, no cap) instead of running it on. Good: statement \"Which cache should we use?\", context \"Redis fits the read-heavy path; see benchmark in #123. Memcached is simpler ops but no persistence.\" Bad: statement \"We looked at Redis vs Memcached, ran benchmarks showing Redis 3x faster on reads, but Memcached has simpler ops and we're not sure persistence matters here since the cache is fully rebuildable from Postgres...\" (too long, refused — move it to context). DX-3309 — every problem is also a `type`, and DX-3309's follow-up gave it a `summary` distinct from `context`: read BOTH fields' own descriptions below before your first `add` — together they teach which type this is, and the three-field split (`statement` / `summary` / `context`) an action actually needs.", {
     id: z.string().min(1),
     action: z.enum(["list", "add", "edit", "remove"]),
     problem_id: z.number().int().positive().optional().describe("edit/remove"),
     base_hash: z.string().min(1).optional().describe("content_hash last read; edit/remove"),
-    statement: z.string().min(1).optional().describe("add/edit; ONE plain question, at most 200 characters"),
+    statement: z
+        .string()
+        .min(1)
+        .optional()
+        .describe("add/edit; ONE plain sentence, at most 200 characters. For a question: the question itself. For an action: " +
+        "WHAT IS TO BE DONE — the deed itself, never phrased as a question (\"Rotate the staging DB credential\", " +
+        "not \"Should we rotate it?\")."),
     context: z
         .string()
         .nullable()
         .optional()
-        .describe("add/edit; markdown detail behind statement — file:line refs, code excerpts, root-cause writeups. add: sent only when given (null/omit means none). edit: omit to keep the stored context, null to clear it."),
+        .describe("add/edit; markdown detail behind statement — file:line refs, code excerpts, root-cause writeups, or (for " +
+        "an action) whatever detail the person carrying it out needs. NOT where an action's why-can't-the-agent " +
+        "sentence goes — that is `summary`. add: sent only when given (null/omit means none). edit: omit to keep " +
+        "the stored context, null to clear it."),
     type: z
         .enum(["question", "action"])
         .optional()
         .describe("add only. Before you raise this problem, apply the test: could I do this myself if I tried harder, and is the " +
         "only thing missing a decision? If yes, this is a \"question\": statement is the question itself (one plain " +
-        "sentence); context is the evidence behind it; solutions[] are candidate ANSWERS, each with its own pro/con, " +
-        "and the operator is done the moment they pick one. If the blocker is access, credentials, hardware, a " +
-        "human's authority, or a system you genuinely cannot reach, this is an \"action\": statement is WHAT IS TO " +
-        "BE DONE — the deed itself, never phrased as a question (\"Rotate the staging DB credential\", not \"Should " +
-        "we rotate it?\"); context is the action's summary and MUST say WHY YOU CANNOT DO THIS YOURSELF — that " +
-        "sentence is what tells the operator this is not you being lazy; solutions[] are the possible ROUTES a " +
-        "person could take to carry it out (e.g. \"rotate by hand in the console\" vs \"run the provisioning " +
-        "script\" vs \"ask the vendor\") — each will carry its own ordered steps to completion once the operator " +
-        "picks one (a later release; for now, describe the route in the solution's body). Omitted defaults to " +
-        "\"question\" (today's behavior) — but that default exists for the caller who has never heard of this " +
-        "field, not as permission to skip the choice: decide deliberately every time."),
+        "sentence); summary (optional) is why it matters; context is the evidence behind it; solutions[] are " +
+        "candidate ANSWERS, each with its own pro/con, and the operator is done the moment they pick one. If the " +
+        "blocker is access, credentials, hardware, a human's authority, or a system you genuinely cannot reach, " +
+        "this is an \"action\": statement is WHAT IS TO BE DONE — the deed itself, never phrased as a question " +
+        "(\"Rotate the staging DB credential\", not \"Should we rotate it?\"); summary is REQUIRED and MUST say " +
+        "WHY THE ACTION IS NEEDED AND WHY YOU CANNOT DO IT YOURSELF — that sentence is what tells the operator this " +
+        "is not you being lazy (an add with no summary is refused 400); context is whatever additional detail the " +
+        "person needs to carry it out; solutions[] are the possible ROUTES a person could take (e.g. \"rotate by " +
+        "hand in the console\" vs \"run the provisioning script\" vs \"ask the vendor\") — each will carry its own " +
+        "ordered steps to completion once the operator picks one (a later release; for now, describe the route in " +
+        "the solution's body). Omitted defaults to \"question\" (today's behavior) — but that default exists for " +
+        "the caller who has never heard of this field, not as permission to skip the choice: decide deliberately " +
+        "every time."),
+    summary: z
+        .string()
+        .nullable()
+        .optional()
+        .describe("add/edit. Plain text, 1-3 sentences — never markdown detail (that's `context`'s job). For a question: " +
+        "optional, why it matters. For an action: REQUIRED and non-empty — why the action is needed AND why you " +
+        "(the agent raising it) cannot do it yourself; omitting it on an action add is refused 400 naming this " +
+        "field, and an edit that would clear it on a live action problem is refused the same way. add: sent only " +
+        "when given (omit/null on a question means none). edit: omit to keep the stored summary, null to clear it " +
+        "(refused if the problem is a live action)."),
     solutions: z
         .array(z.object({ title: z.string().min(1), ...SOLUTION_FIELDS }).strict())
         .optional()

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@thehammer/danx-dashboard-mcp",
-  "version": "0.1.115",
+  "version": "0.1.116",
   "description": "Stdio MCP server wrapping danxbot's dashboard /api/issues/* normalized DB-backed HTTP routes for dispatched agents (DX-704 Phase 2).",
   "license": "MIT",
   "type": "module",