@thehammer/danx-dashboard-mcp 0.1.114 → 0.1.115

package/dist/handlers.js

@@ -591,6 +591,16 @@ export async function issueChecklist(client, args) {
  * context while `null` clears it — the same omit/null semantics
  * `plan_update_record` already gives a plan record's context.
  *
+ * DX-3309 — `add` also takes `type`: `question` (the operator decides) or
+ * `action` (only a person can carry it out). Sent only when given — the
+ * server itself defaults an omitted value to `question`, so a caller that
+ * predates this field keeps creating exactly what it always created. It is
+ * set once, at creation, and never editable afterward. The FULL teaching
+ * text (the could-I-do-this-myself test, and what `statement`/`context`/
+ * `solutions[]` mean under each type) lives on the tool's own `type` field
+ * `.describe()` in `index.ts` — that description, not this comment, is what
+ * a calling agent actually reads.
+ *
  * No answer action, for the reason `issueSolution` gives.
  */
 export async function issueProblem(client, args) {
@@ -604,6 +614,11 @@ export async function issueProblem(client, args) {
             const body = { statement: need.string(args.statement, "statement") };
             if (args.context !== undefined)
                 body.context = args.context;
+            // DX-3309 — sent only when given; the server itself defaults an omitted
+            // value to "question" (today's behavior, unchanged for any caller that
+            // doesn't yet know about this field).
+            if (args.type !== undefined)
+                body.type = args.type;
             if (args.solutions !== undefined)
                 body.solutions = args.solutions;
             const result = await client.request({ method: "POST", path: `/${idEnc}/problems`, body, board });

package/dist/index.js

@@ -610,7 +610,7 @@ 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, content_hash, open, solutions[], decisions[]}; add {statement, context?, 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).", {
+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.", {
     id: z.string().min(1),
     action: z.enum(["list", "add", "edit", "remove"]),
     problem_id: z.number().int().positive().optional().describe("edit/remove"),
@@ -621,6 +621,22 @@ strictTool("issue_problem", "A card's PROBLEMS via /api/issues/:id/problems[/:pi
         .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."),
+    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."),
     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.114",
+  "version": "0.1.115",
   "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",