@thehammer/danx-dashboard-mcp 0.1.112 → 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/dist/listen.js

@@ -276,6 +276,20 @@ function cardList(cards) {
  * point of the feature: a session that only sees "you're idle" learns
  * nothing a bare timer couldn't have told it. Always a single line; throws,
  * naming the fault, on a malformed nudge.
+ *
+ * DX-3274 — the line asserts only what `evaluateIdleNudge` actually measured
+ * (no real MCP call from THIS session in `idleMinutes`), never "work is
+ * waiting" or "work has stalled". `last_agent_call_at` cannot see a
+ * sub-agent/dispatch working the same card from underneath an orchestrating
+ * session — an orchestrator that delegates and then correctly waits without
+ * polling (the project's own mandated style, `base:monitor-polling`) looks
+ * identical, on this signal, to one that actually stalled. The card names
+ * are still worth reporting (a real signal: these are the cards this session
+ * itself has not touched), but the claim about THEM stops at "not checked
+ * in" — never a claim about whether the work itself is progressing, which
+ * this signal cannot support. See `evaluateIdleNudge`'s own doc comment
+ * (`src/issues/db/session-idle-nudge.ts`) for why a sub-agent-awareness
+ * special case was rejected instead of this wording fix.
  */
 export function formatNudgeLine(event) {
     const invalid = invalidNudgeReason(event);
@@ -286,7 +300,7 @@ export function formatNudgeLine(event) {
         parts.push(`startable: ${cardList(event.startable)}`);
     if (event.held.length > 0)
         parts.push(`held: ${cardList(event.held)}`);
-    return oneLine(`${LINE_PREFIX} this session has been idle ${event.idleMinutes}m with work waiting — ${parts.join("; ")}`);
+    return oneLine(`${LINE_PREFIX} this session has not made an MCP call in ${event.idleMinutes}m — ${parts.join("; ")}`);
 }
 /**
  * Incremental SSE parser. Comment lines (keep-alives, the connect marker) and

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@thehammer/danx-dashboard-mcp",
-  "version": "0.1.112",
+  "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",