@thehammer/danx-dashboard-mcp 0.1.131 → 0.1.134

package/dist/handlers.js

@@ -23,7 +23,6 @@
  */
 import { readFile } from "node:fs/promises";
 import { basename, extname, isAbsolute } from "node:path";
-import { oneLine } from "./one-line.js";
 import { resolvePriority } from "./priority.js";
 /**
  * `filter`/`fields`/`sort` are JSON/CSV-encoded onto the query string (the
@@ -297,82 +296,6 @@ export async function issueTransition(client, args) {
         board,
     });
 }
-/** How much of a problem statement the reminder quotes — enough to recognise it. */
-const REMINDER_STATEMENT_MAX = 120;
-function isReminderProblem(value) {
-    const p = value;
-    return (typeof p === "object" &&
-        p !== null &&
-        typeof p.id === "number" &&
-        typeof p.statement === "string" &&
-        typeof p.open === "boolean" &&
-        Array.isArray(p.solutions));
-}
-/**
- * Attach the problems reminder to a SUCCESSFUL `issue_problem add`.
- *
- * DX-2830 — an added problem IS the moment a card is put in front of a human;
- * there is no separate gate to set or refuse. Whether each open problem lists
- * its viable solutions is feedback, never refusal: a problem with zero
- * solutions is valid (the operator answers free-form), and refusing it would
- * push the agent into inventing options. So the reminder rides the success
- * response and names the STILL-OPEN problems only — an answered sibling needs
- * nothing more.
- *
- * The write's own envelope is returned untouched beside it. A refused write
- * gets no reminder and no extra request. A failure READING the problems is
- * reported inside the reminder rather than thrown: the add already succeeded,
- * and throwing would tell the agent it failed when it did not.
- */
-export async function withProblemsReminder(client, id, board, result) {
-    if (!result.ok)
-        return result;
-    let listed;
-    try {
-        listed = await client.request({
-            method: "GET",
-            path: `/${encodeURIComponent(id)}/problems`,
-            board,
-        });
-    }
-    catch (err) {
-        return { ...result, problems_reminder: unreadableReminder(id, err instanceof Error ? err.message : String(err)) };
-    }
-    // `body` is the server's JSON verbatim — `null` is valid JSON, so read it null-safely;
-    // a throw here would land OUTSIDE the try above and misreport the successful write.
-    const problems = listed.ok ? listed.body?.problems : undefined;
-    if (!Array.isArray(problems) || !problems.every(isReminderProblem)) {
-        // A 2xx whose body is not the problem list is a contract break, not a refusal —
-        // say so, rather than leaving a bare "HTTP 200" that reads like success.
-        const detail = listed.ok ? `HTTP ${listed.status}, unexpected shape` : `HTTP ${listed.status}`;
-        return { ...result, problems_reminder: unreadableReminder(id, detail) };
-    }
-    const open = problems.filter((p) => p.open);
-    return { ...result, problems_reminder: { open_problem_count: open.length, instruction: openProblemsInstruction(id, open) } };
-}
-function openProblemsInstruction(id, open) {
-    if (open.length === 0) {
-        // Only reachable when every problem was answered between the add and this
-        // read — the card no longer needs a human.
-        return `No problem on ${id} is open any more — each was answered already. Re-read the card before you stop.`;
-    }
-    const listing = open
-        .map((p) => {
-        const statement = oneLine(p.statement, REMINDER_STATEMENT_MAX);
-        const count = p.solutions.length;
-        return `problem ${p.id} "${statement}" — ${count === 0 ? "NO SOLUTIONS LISTED" : `${count} solution${count === 1 ? "" : "s"}`}`;
-    })
-        .join("; ");
-    return (`${open.length} open problem${open.length === 1 ? "" : "s"} on ${id}: ${listing}. ` +
-        `Before you stop, list EVERY viable solution to each with issue_solution({id: "${id}", problem_id, action: "add", title, body, pro, con}) and mark the one you recommend with recommended: true, ` +
-        `and make every other question the operator must answer its own problem with issue_problem. The card needs a human until every open problem is answered.`);
-}
-function unreadableReminder(id, detail) {
-    return {
-        open_problem_count: null,
-        instruction: `Could not read the problems on ${id} (${detail}). Check with issue_problem({id: "${id}", action: "list"}) and make sure EVERY viable solution to each open problem is listed before you stop.`,
-    };
-}
 export async function issueTriage(client, args) {
     const { id, board, ...body } = args;
     return client.request({
@@ -637,8 +560,13 @@ export async function issueProblem(client, args) {
                 body.summary = args.summary;
             if (args.solutions !== undefined)
                 body.solutions = args.solutions;
-            const result = await client.request({ method: "POST", path: `/${idEnc}/problems`, body, board });
-            return withProblemsReminder(client, args.id, board, result);
+            // DX-3365 — the server's own response now carries the reminder (a
+            // `reminders: [{key, text}]` field appended by the registry
+            // middleware, `src/issues/reminders/middleware.ts`); this used to be an
+            // EXTRA client-side GET (`withProblemsReminder`, deleted) computing the
+            // identical text a request round-trip later. Passed through verbatim —
+            // no dual path.
+            return client.request({ method: "POST", path: `/${idEnc}/problems`, body, board });
         }
         case "edit": {
             const problemId = need.id(args.problem_id, "problem_id");

package/dist/index.js

@@ -653,7 +653,7 @@ const STEP_INPUT = z.lazy(() => z
     steps: z.array(STEP_INPUT).optional().describe("this step's own children, nested — refused past 3 levels total"),
 })
     .strict());
-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 (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. `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). Every problem is also a `type`, with 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.", {
+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 a `reminders: [{key, text}]` array (DX-3365 — every MCP-response reminder rides this ONE field now, DB-registry-driven and operator-overridable from the dashboard) naming each still-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 (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. `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). Every problem is also a `type`, with 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"),

package/package.json

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