@thehammer/danx-dashboard-mcp 0.1.117 → 0.1.120

package/dist/handlers.js

@@ -96,6 +96,13 @@ export async function issueGet(client, args) {
     if (args.ids !== undefined && args.board !== undefined) {
         throw new Error("issue_get: board does not apply to the ids batch form — it resolves every id globally; drop board");
     }
+    // DX-3321 — comments paging is a SINGLE-id-route feature
+    // (`GET /api/issues/:id?comments_limit=&comments_offset=`); the batch
+    // route has no per-card paging at all. Refuse rather than silently drop,
+    // same as the `ids` + `board` refusal just above.
+    if (args.ids !== undefined && (args.comments_limit !== undefined || args.comments_offset !== undefined)) {
+        throw new Error("issue_get: comments_limit/comments_offset do not apply to the ids batch form — it has no per-card comment paging; drop them or use the single-id form");
+    }
     const query = {};
     if (args.fields !== undefined && args.fields.length > 0) {
         query.fields = args.fields.join(",");
@@ -112,6 +119,10 @@ export async function issueGet(client, args) {
     if (args.id === undefined) {
         throw new Error("issue_get: pass exactly one of id or ids");
     }
+    if (args.comments_limit !== undefined)
+        query.comments_limit = args.comments_limit;
+    if (args.comments_offset !== undefined)
+        query.comments_offset = args.comments_offset;
     return client.request({
         method: "GET",
         path: `/${encodeURIComponent(args.id)}`,
@@ -633,6 +644,16 @@ export async function issueProblem(client, args) {
             const problemId = need.id(args.problem_id, "problem_id");
             const baseHash = need.string(args.base_hash, "base_hash");
             const statement = need.string(args.statement, "statement");
+            // DX-3309 (test-review follow-up) — `type` is set once, at creation,
+            // and never editable afterward; the HTTP edit route already refuses it
+            // as an unknown key. This call used to silently DROP `type` on edit
+            // (it was never read from `args` here at all), so an agent
+            // "changing" question -> action got a 200 back with the type
+            // unchanged, no error, no signal anything was ignored. Fail loud
+            // instead: the fix for a wrong type is remove + re-add, never edit.
+            if (args.type !== undefined) {
+                throw new Error("issue_problem edit: type cannot be changed after creation — remove this problem and add a new one with the correct type");
+            }
             return client.request({
                 method: "PATCH",
                 path: `/${idEnc}/problems/${problemId}`,

package/dist/index.js

@@ -384,13 +384,29 @@ strictTool("issue_list",
 strictTool("issue_get", 
 // DX-2735: trimmed to pay for the problem tools inside the work-profile
 // injected-surface budget — same facts, no repeated prose.
-"Fetch one card (GET /api/issues/:id, `id`) or many (GET /api/issues/batch, `ids`, at most " + ISSUE_BATCH_GET_MAX + " — split larger sets); pass exactly one. Ids are globally unique, so both resolve from any board; the batch form is global and throws with `board`. THE DEFAULT ROW IS MINIMAL — scalars only (id, type, title, status, parent_id, priority, created_at, updated_at, assigned_agent, content_hash: the concurrency token issue_edit needs for title/description/checklists). `fields` opts into groups, per card in a batch too: description (body + summary), problems (live problems in order, each {id, statement, content_hash, open} with its solutions[] and decisions[] — a card needs a human exactly when open_problem_count > 0), ac (acceptance criteria + checklists), comments, retro, dependencies (waiting_on/conflict_on/blocked), triage (history + ICE), assignment (dispatch, assigned_agent, lifecycle timestamps), quality_gates (one row per gate {gate, required, status pending|pass|fail, completed_at, message}; a required PRE gate not `pass` pre-empts the work dispatch, and complete refuses while a required POST gate is not `pass`), children (ids + rollups), mirrors (external sync state), code_review_items, plans (every plan this card is on, `{id, ref, name}[]` via `plan_cards` — `ref` is the plan's `PLN-<id>`). Single form: unknown id → 404. Batch form: `{issues: [...], not_found: [...ids]}` — an unknown or deleted id never fails the call.", {
+"Fetch one card (GET /api/issues/:id, `id`) or many (GET /api/issues/batch, `ids`, at most " + ISSUE_BATCH_GET_MAX + " — split larger sets); pass exactly one. Ids are globally unique, so both resolve from any board; the batch form is global and throws with `board`. THE DEFAULT ROW IS MINIMAL — scalars only (id, type, title, status, parent_id, priority, created_at, updated_at, assigned_agent, content_hash: the concurrency token issue_edit needs for title/description/checklists). `fields` opts into groups, per card in a batch too: description (body + summary), problems (live problems in order, each {id, statement, content_hash, open} with its solutions[] and decisions[] — a card needs a human exactly when open_problem_count > 0), ac (acceptance criteria + checklists), comments (see `comments_limit`/`comments_offset` below), retro, dependencies (waiting_on/conflict_on/blocked), triage (history + ICE), assignment (dispatch, assigned_agent, lifecycle timestamps), quality_gates (one row per gate {gate, required, status pending|pass|fail, completed_at, message}; a required PRE gate not `pass` pre-empts the work dispatch, and complete refuses while a required POST gate is not `pass`), children (ids + rollups), mirrors (external sync state), code_review_items, plans (every plan this card is on, `{id, ref, name}[]` via `plan_cards` — `ref` is the plan's `PLN-<id>`). The `comments` group returns a PAGE ANCHORED AT THE NEWEST COMMENT: `comments_offset` counts back from the newest comment (offset 0 = the most recent comments_limit comments), and `comments_total` is the card's real total comment count, so `comments_offset + comments.length < comments_total` means older comments remain — page forward with `comments_offset` to reach them; a long-running card's decisive history (what was tried, measured, rejected or reverted) often lives past the first page. WITHIN a page, comments are ordered CHRONOLOGICALLY (oldest first, newest last) — the same order every other comment read in this API uses; only the WINDOW you request is anchored at the newest end, not the array itself. `comments_limit`/`comments_offset` apply to the SINGLE-id form only (no per-card paging in the batch form — naming either alongside `ids` is refused). Single form: unknown id → 404. Batch form: `{issues: [...], not_found: [...ids]}` — an unknown or deleted id never fails the call.", {
     id: z.string().min(1).optional(),
     ids: z.array(z.string().min(1)).min(1).max(ISSUE_BATCH_GET_MAX).optional(),
     fields: z
         .array(z.enum(GET_FIELD_GROUPS))
         .optional()
         .describe("Field groups to add; absent = minimal scalars."),
+    comments_limit: z
+        .number()
+        .int()
+        .positive()
+        .optional()
+        .describe("Single-id form only. How many comments the page holds (server default 20), the window anchored at the " +
+        "NEWEST comment. An out-of-range value (server max 200) is refused by the server with its own 400, " +
+        "never silently clamped here. Requires `fields` to include `comments`."),
+    comments_offset: z
+        .number()
+        .int()
+        .nonnegative()
+        .optional()
+        .describe("Single-id form only. Skip this many of the newest comments before the page starts (default 0) — page " +
+        "forward while comments_offset + comments.length < comments_total to reach older comments. Requires " +
+        "`fields` to include `comments`."),
     ...boardField,
 }, async (args) => jsonResult(await issueGet(client, args)));
 // ---------------- issue_create ----------------
@@ -610,7 +626,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) 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.", {
+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.", {
     id: z.string().min(1),
     action: z.enum(["list", "add", "edit", "remove"]),
     problem_id: z.number().int().positive().optional().describe("edit/remove"),
@@ -643,10 +659,8 @@ strictTool("issue_problem", "A card's PROBLEMS via /api/issues/:id/problems[/:pi
         "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 " +
+        "hand in the console\" vs \"run the provisioning script\" vs \"ask the vendor\"), each carrying its own " +
+        "steps to completion once the operator picks one. Omitted defaults to \"question\" — decide deliberately " +
         "every time."),
     summary: z
         .string()

package/package.json

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