@thehammer/danx-dashboard-mcp 0.1.33 → 0.1.34

package/README.md

@@ -26,7 +26,7 @@ All exposed as `mcp__danx_dashboard__<name>` once wired through the workspace `m
 | `issue_create` | `POST /api/issues` | Epic REQUIRES non-empty `phase_children[]` (atomic insert) |
 | `issue_edit` | `PATCH /api/issues/:id/edit` | Prose + structured keys (`title`, `description`, `ac`, `checklists`, `effort_level`, `parent_id`, `priority`, `list_id`); semantic keys refused with 400 + pointer to dedicated handler. `priority` (DX-1532) takes a tier word (`low`/`high`/…) or a number in `[0,6)` — the ONLY way to set the numeric column the Trello label + dashboard badge read; never set priority via description prose |
 | `issue_transition` | `POST /api/issues/:id/transition` | Actions: ready, pickup, rollback_pickup, complete, cancel, block, unblock, archive, reopen |
-| `issue_triage` | `POST /api/issues/:id/triage` | Verdicts: approve, cancel, keep, defer (with optional ICE + ttl_seconds). None of these are a cross-card ordering gate — a card held at Review via `keep` can still be readied independent of a sibling; use `issue_dependency` to sequence cards |
+| `issue_triage` | `POST /api/issues/:id/triage` | Send `{confidence, reason}` — an integer 0-5 score; the server computes the verdict (approve/cancel/keep/defer) against the board's configured thresholds (DX-2086). `keep`/`defer` now block the card. None of these are a cross-card ordering gate; use `issue_dependency` to sequence cards |
 | `issue_comment` | `POST/PATCH/DELETE /api/issues/:id/comments[/:cid]` | Author server-stamped, soft-delete preserved |
 | `issue_dependency` | `POST/DELETE /api/issues/:id/dependencies[/:did]` | `depends_on` cycle-checked; remove hardcodes `reason: "recorded_in_error"`. The only mechanism the dispatch picker enforces to sequence one card after another — status alone is not a substitute |
 | `issue_requires_human` | `POST/DELETE /api/issues/:id/requires-human` | Set replaces step rows atomically; clear soft-deletes them |

package/dist/index.js

@@ -175,7 +175,6 @@ const TRANSITION_ACTIONS = [
     "archive",
     "reopen",
 ];
-const TRIAGE_VERDICTS = ["approve", "cancel", "keep", "defer"];
 // Optional per-call board override shared by every tool. Omitted → the
 // dispatch's env-derived board (`<repo>:<slug>`) is used; provided → that
 // board is targeted instead (the dashboard owns board→repo and 404s an
@@ -308,18 +307,10 @@ server.tool("issue_transition", "Stamp a lifecycle transition via POST /api/issu
     ...boardField,
 }, async (args) => jsonResult(await issueTransition(client, args)));
 // ---------------- issue_triage ----------------
-server.tool("issue_triage", "Record a triage verdict via POST /api/issues/:id/triage. Verdicts: approve (stamps ready_at — moves to ToDo, clears triage TTL), cancel (stamps cancelled_at — terminal), keep (refreshes triage_expires_at by ttl_seconds — defaults 7 days, card stays at Review), defer (stamps archived_at, clears ready_at — parks to Backlog). ICE components optional but recorded when present (total = i*c*e). Reason is REQUIRED non-empty. REFUSES 409 on terminal cards. None of these verdicts create a cross-card ordering gate — a card left at Review (via keep) is invisible to the plan-dependency gate's live-partner comparison and can be readied independent of any sibling's status. To sequence one card after another, use issue_dependency (kind: depends_on) — that is the only mechanism the dispatch picker actually enforces regardless of status.", {
+server.tool("issue_triage", "Record a triage confidence score via POST /api/issues/:id/triage (DX-2086). Caller sends a single `confidence` integer 0-5 plus a required non-empty `reason` — the server computes the verdict by comparing `confidence` against the board's configured thresholds (all band edges inclusive on the low side): confidence <= cancelThreshold -> cancel (stamps cancelled_at, terminal); cancelThreshold < confidence <= archiveThreshold -> defer (stamps archived_at AND blocked_at/blocked_reason); archiveThreshold < confidence <= reviewThreshold -> keep (stamps blocked_at/blocked_reason, stays derived-Review); confidence > reviewThreshold -> approve (stamps ready_at). REFUSES 409 on terminal cards. A keep/defer verdict now BLOCKS the card (blocked_at set) — it is not a cross-card ordering gate; use issue_dependency (kind: depends_on) to sequence one card after another.", {
     id: z.string().min(1),
-    verdict: z.enum(TRIAGE_VERDICTS),
+    confidence: z.number().int().min(0).max(5),
     reason: z.string().min(1),
-    ice: z
-        .object({
-        i: z.number().finite(),
-        c: z.number().finite(),
-        e: z.number().finite(),
-    })
-        .optional(),
-    ttl_seconds: z.number().positive().optional(),
     ...boardField,
 }, async (args) => jsonResult(await issueTriage(client, args)));
 // ---------------- issue_comment ----------------

package/package.json

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