@thehammer/danx-dashboard-mcp 0.1.72 → 0.1.73

package/README.md

@@ -31,6 +31,7 @@ All exposed as `mcp__danx-dashboard__<name>` once wired through the workspace `m
 | `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_retire_branch` | `POST /api/issues/:id/card-branch-retire` | Mark this card's own `card/<id>` branch RETIRED (unsafe to merge) — `{reason}`, `by` server-stamped. NO status/terminal gate (DX-2845): settable the instant an audit/split judges the branch unsafe, whatever the card's status. The dispatched worker reads this at its next bootstrap and forces `origin/main` instead of re-attaching to the retired content |
 | `issue_retro` | `PUT /api/issues/:id/retro` | Requires terminal card; replace semantics |
 
 ## `plan_get` — cheap by default, opt-in for the rest (DX-2727)

package/dist/handlers.js

@@ -445,6 +445,24 @@ export async function issueDependency(client, args) {
         board,
     });
 }
+/**
+ * DX-2845 — mark a card's own `card/<id>` branch RETIRED (unsafe to merge)
+ * via POST /api/issues/:id/card-branch-retire {reason}. NO status/terminal
+ * gate on the server side — settable the moment a branch is judged unsafe,
+ * whether the card is ToDo, In Progress, or anything else (see
+ * `retireCardBranch`'s doc comment, `src/issues/write/card-branch-retire.ts`).
+ * `by` is server-stamped from the resolved writing identity, never
+ * client-supplied. Idempotent: retiring an already-retired branch just
+ * re-stamps reason/actor/timestamp.
+ */
+export async function issueRetireBranch(client, args) {
+    return client.request({
+        method: "POST",
+        path: `/${encodeURIComponent(args.id)}/card-branch-retire`,
+        body: { reason: args.reason },
+        board: args.board,
+    });
+}
 /**
  * DX-1362 — targeted checklist CUD. Action-dispatched onto the
  * `/api/issues/:id/checklists[/:cid[/items[/:iid]]]` route family so an agent
@@ -1129,75 +1147,3 @@ export async function planDeleteRecord(client, args) {
         body: { content_hash: args.content_hash },
     });
 }
-// ---------------- failure_category_list / _create / _update (DX-2792) ----------------
-/**
- * DX-2792 (Failure evaluation 3/4) — wraps `src/dashboard/failure-categories-routes.ts`,
- * the DX-2791 (Failure evaluation 2/4) category registry's REST API. INSTALL-
- * GLOBAL, not board-scoped: `failure_categories` carries no `board_id`
- * column (every category applies across the whole install), so — unlike
- * every `/api/issues/*`-backed tool above — these three never send a
- * `board` query param and the `board` override field is simply absent from
- * their schemas (mirrors the `plan_*` family's own board-less rationale in
- * `index.ts`'s `boardField` comment, for the same underlying reason: nothing
- * server-side would read it).
- */
-const FAILURE_CATEGORIES_BASE_PATH = "/api/failure-categories";
-/**
- * List every failure category with its live matched-occurrence count and
- * last-seen time, via `GET /api/failure-categories`. Returns
- * `{categories: [{id, name, description, matchers, ignore, ignoreReason,
- * expectedRate, matchedCount, lastSeenMs, ...}]}`. A fresh install returns
- * `{categories: []}`.
- */
-export async function failureCategoryList(client) {
-    return client.request({
-        method: "GET",
-        path: "",
-        basePath: FAILURE_CATEGORIES_BASE_PATH,
-    });
-}
-/**
- * Create a new failure category via `POST /api/failure-categories`. At
- * least one matcher, each with at least one of `sourceKind`/`tool`/
- * `regexPattern` set, is required (400 otherwise). `ignore: true` REQUIRES a
- * non-empty `ignoreReason` (400 otherwise). A matcher set that would overlap
- * an EXISTING category's matchers is refused 400 naming the conflicting
- * category — expand that category instead of creating a near-duplicate. On
- * success, the dashboard re-matches every existing uncategorized occurrence
- * against the new category before responding, so `matchedCount` in the
- * response already reflects any newly-covered signatures.
- */
-export async function failureCategoryCreate(client, args) {
-    return client.request({
-        method: "POST",
-        path: "",
-        basePath: FAILURE_CATEGORIES_BASE_PATH,
-        body: {
-            name: args.name,
-            description: args.description ?? "",
-            matchers: args.matchers,
-            ignore: args.ignore ?? false,
-            ignoreReason: args.ignoreReason ?? null,
-            expectedRate: args.expectedRate ?? null,
-        },
-    });
-}
-/**
- * Patch an existing failure category via `PATCH /api/failure-categories/:id`
- * — the tool for BOTH "expand an existing category's matchers" (send the
- * full replacement `matchers` array) and "mark a category ignored" (send
- * `ignore: true` + a non-empty `ignoreReason`). At least one field is
- * required (400 otherwise). Same overlap refusal as create (excluding this
- * category's own prior matchers). On success, re-matches every
- * uncategorized occurrence against the updated matcher set before
- * responding.
- */
-export async function failureCategoryUpdate(client, args) {
-    const { id, ...patch } = args;
-    return client.request({
-        method: "PATCH",
-        path: `/${id}`,
-        basePath: FAILURE_CATEGORIES_BASE_PATH,
-        body: patch,
-    });
-}

package/dist/index.js

@@ -22,6 +22,7 @@
  *   - issue_problem          GET/POST/PATCH/DELETE /api/issues/:id/problems[/:pid] (DX-2735)
  *   - issue_solution         POST/PATCH/DELETE /api/issues/:id/problems/:pid/solutions[/:sid] (DX-2735)
  *   - issue_dependency       POST/DELETE /api/issues/:id/dependencies[/:did]
+ *   - issue_retire_branch    POST   /api/issues/:id/card-branch-retire (DX-2845)
  *   - issue_quality_gate     POST   /api/issues/:id/quality-gates/:gate
  *   - issue_quality_gate_verdict
  *                            PATCH  /api/issues/:id/quality-gates/:gate
@@ -48,9 +49,6 @@
  *   - plan_update_architecture_section  PATCH  /api/plans/mine/architecture/sections/:sid (DX-2726)
  *   - plan_delete_architecture_section  DELETE /api/plans/mine/architecture/sections/:sid (DX-2726)
  *   - plan_reorder_architecture_section PUT    /api/plans/mine/architecture/sections/reorder (DX-2726)
- *   - failure_category_list     GET    /api/failure-categories (DX-2791/DX-2792, board-less)
- *   - failure_category_create   POST   /api/failure-categories (DX-2791/DX-2792, board-less)
- *   - failure_category_update   PATCH  /api/failure-categories/:id (DX-2791/DX-2792, board-less)
  *
  * DX-2683 — THE PLAN TOOLS ARE SESSION-BOUND, and asymmetrically so. Reads
  * may name any plan; WRITES take no plan id at all and act on the plan this
@@ -89,7 +87,7 @@ import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
 import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
 import { z } from "zod";
 import { DashboardHttpClient } from "./http-client.js";
-import { issueAttach, issueChecklist, issueComment, issueCreate, issueDependency, issueEdit, issueGet, issueList, issueProblem, issueQualityGate, issueQualityGateVerdict, issueRetro, issueSolution, issueTransition, issueTriage, briefGetPage, briefList, briefSetPage, failureCategoryCreate, failureCategoryList, failureCategoryUpdate, planAddArchitectureSection, planAddCard, planAddRecord, planConnect, planCreate, planDeleteArchitectureSection, planDeleteRecord, planGet, PLAN_FIELD_GROUPS, PLAN_STATUSES, ISSUE_BATCH_GET_MAX, LIST_PAGE_MAX_LIMIT, PLAN_GET_CARDS_DEFAULT_LIMIT, planGetArchitectureSection, planGetRecord, planList, planRemoveCard, planRename, planReorderArchitectureSection, planUpdateArchitectureSection, planUpdateRecord, repoKnowledgeGet, repoKnowledgeSet, } from "./handlers.js";
+import { issueAttach, issueChecklist, issueComment, issueCreate, issueDependency, issueEdit, issueGet, issueList, issueProblem, issueQualityGate, issueQualityGateVerdict, issueRetireBranch, issueRetro, issueSolution, issueTransition, issueTriage, briefGetPage, briefList, briefSetPage, planAddArchitectureSection, planAddCard, planAddRecord, planConnect, planCreate, planDeleteArchitectureSection, planDeleteRecord, planGet, PLAN_FIELD_GROUPS, PLAN_STATUSES, ISSUE_BATCH_GET_MAX, LIST_PAGE_MAX_LIMIT, PLAN_GET_CARDS_DEFAULT_LIMIT, planGetArchitectureSection, planGetRecord, planList, planRemoveCard, planRename, planReorderArchitectureSection, planUpdateArchitectureSection, planUpdateRecord, repoKnowledgeGet, repoKnowledgeSet, } from "./handlers.js";
 import { PRIORITY_TIER_WORDS } from "./priority.js";
 function readEnvOrDie(name) {
     const v = process.env[name];
@@ -539,6 +537,12 @@ server.tool("issue_dependency", 'Dependency CRUD via /api/issues/:id/dependencie
     dependency_id: z.number().int().positive().optional(),
     ...boardField,
 }, async (args) => jsonResult(await issueDependency(client, args)));
+// ---------------- issue_retire_branch ----------------
+server.tool("issue_retire_branch", "Mark a card's own `card/<id>` branch RETIRED (unsafe to merge) via POST /api/issues/:id/card-branch-retire {reason} (DX-2845). NO status/terminal gate — settable the moment a branch is judged unsafe (an audit rejected it, the card was split into fresh slices, ...), whether the card is ToDo, In Progress, or anything else; this is deliberately NOT the same as captureAndDeleteCardBranch, which only fires once the card itself reaches Done/Cancelled. `by` is server-stamped from the resolved writing identity, never client-supplied. The dispatched worker reads this at its next bootstrap and forces `origin/main` as the checkout start point instead of re-attaching to the retired content — the origin `card/<id>` ref itself is separately backed up then deleted by the worker as a lazy hygiene step. Idempotent: retiring an already-retired branch just re-stamps reason/actor/timestamp.", {
+    id: z.string().min(1),
+    reason: z.string().min(1),
+    ...boardField,
+}, async (args) => jsonResult(await issueRetireBranch(client, args)));
 // ---------------- issue_quality_gate ----------------
 server.tool("issue_quality_gate", "Set one card's per-gate `required` flag via POST /api/issues/:id/quality-gates/:gate {required} — the only post-create way (issue_create takes gate_decisions; issue_edit refuses gate keys). PRE `plan-*` gates run before the work dispatch; POST `code-*` gates block complete. Unknown gate → 400. The board state per gate is tri-state: `required` always runs, `optional` runs WHEN this flag is true (optional is NOT off), `disabled` never runs. Optional `effort_level` overrides a `plan-*` gate's reviewer rung (null clears it). The write always succeeds and returns `{issue, applied: true, effective, reason}` — read `effective` (does the gate now run) and `reason` (why the board overrode your value), not just the 200. Board-scoped; see `board`.", {
     id: z.string().min(1),
@@ -758,47 +762,6 @@ server.tool("plan_reorder_architecture_section", "Reassign your connected plan's
         .min(1)
         .describe("Every live section id of the connected plan, in the desired order — exactly once each."),
 }, async (args) => jsonResult(await planReorderArchitectureSection(client, args)));
-// ---------------- failure_category_list / _create / _update (DX-2792) ----------------
-const matcherField = z
-    .object({
-    sourceKind: z
-        .enum(["tool-error", "hook-refusal", "api-error", "usage-limit", "session-result"])
-        .optional()
-        .describe("Absent matches any source kind."),
-    tool: z.string().min(1).optional().describe("Exact tool name (e.g. \"Bash\"); absent matches any tool, including null."),
-    regexPattern: z
-        .string()
-        .min(1)
-        .optional()
-        .describe("Regex source tested against the normalized excerpt (paths/UUIDs/timestamps/ports already stripped)."),
-})
-    .describe("At least one of sourceKind/tool/regexPattern must be set — an empty matcher is refused.");
-const expectedRateField = z
-    .object({
-    count: z.number().int().min(0).describe("N — how many failures are expected."),
-    overDispatches: z.number().int().positive().describe("X — over how many dispatches."),
-})
-    .nullable()
-    .optional()
-    .describe("Both fields together, or omit/null entirely — never a half-specified rate.");
-server.tool("failure_category_list", "List every failure category via GET /api/failure-categories (DX-2791/DX-2792). Board-less — a category applies across the whole install, not one board. Returns `{categories: [{id, name, description, matchers, ignore, ignoreReason, expectedRate, matchedCount, lastSeenMs, createdAtMs, createdBy, updatedAtMs, updatedBy}]}`, id ascending. A fresh install returns `{categories: []}`. Read this immediately before `failure_category_create`/`failure_category_update` so your overlap/expand decision is against the CURRENT set, not a stale snapshot from earlier in the dispatch.", {}, async () => jsonResult(await failureCategoryList(client)));
-server.tool("failure_category_create", 'Create a new failure category via POST /api/failure-categories (DX-2791/DX-2792). Board-less. `matchers` (at least one) is an OR-across-matchers set — a category matches an occurrence when ANY ONE matcher\'s fields all hold. `ignore: true` REQUIRES a non-empty `ignoreReason` (400 otherwise) — use this for an expected, non-actionable failure rather than leaving it uncategorized. A matcher set overlapping an EXISTING category is refused 400 naming the conflict — call `failure_category_list` first and EXPAND that category (`failure_category_update`) instead of creating a near-duplicate. On success, the dashboard re-matches every existing uncategorized occurrence against the new category before responding.', {
-    name: z.string().min(1).describe("The category's name."),
-    description: z.string().optional().describe("Optional free-text description. Defaults to empty."),
-    matchers: z.array(matcherField).min(1).describe("At least one matcher; a category matches an occurrence when ANY ONE matches (OR across matchers)."),
-    ignore: z.boolean().optional().describe("Mark this category as expected/non-actionable noise. Requires ignoreReason. Defaults to false."),
-    ignoreReason: z.string().nullable().optional().describe("Required (non-empty) when ignore is true."),
-    expectedRate: expectedRateField,
-}, async (args) => jsonResult(await failureCategoryCreate(client, args)));
-server.tool("failure_category_update", "Patch an existing failure category via PATCH /api/failure-categories/:id (DX-2791/DX-2792). Board-less. This is the tool for BOTH actions: expanding an existing category's matchers (send the FULL replacement `matchers` array — it REPLACES, not appends, so include every matcher you want to keep alongside the new one) and marking a category ignored (`ignore: true` + a non-empty `ignoreReason`). At least one field besides `id` is required (400 otherwise). Same overlap refusal as create, excluding this category's own prior matchers. On success, re-matches every uncategorized occurrence against the updated matcher set before responding.", {
-    id: z.number().int().positive().describe("The category id to patch — from failure_category_list."),
-    name: z.string().min(1).optional(),
-    description: z.string().optional(),
-    matchers: z.array(matcherField).min(1).optional().describe("REPLACES the full matcher set when sent — never a partial append."),
-    ignore: z.boolean().optional(),
-    ignoreReason: z.string().nullable().optional(),
-    expectedRate: expectedRateField,
-}, async (args) => jsonResult(await failureCategoryUpdate(client, args)));
 // ---------------- main ----------------
 async function main() {
     boot();

package/package.json

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