@theronap/agnoclast-mcp 0.9.170 → 0.9.172

package/lib/server.mjs

@@ -2165,7 +2165,24 @@ function renderNudge(payload) {
         // managed to list these rows for weeks without making one of them actionable.
         lines.push(`  ${a.stagedId}`)
         lines.push(`    ${a.title ?? '(no subject)'}  ·  ${a.sourceType}  ·  ${a.occurredAt?.slice(0, 10) ?? ''}`)
-        if (a.blockingIdentifiers?.length) {
+        // 🔴 A QUESTION IS ALREADY OUT — say so FIRST, before any "held because" reason.
+        //
+        // Caught by using the feature once on real data, 2026-09-24, minutes after shipping it:
+        // `staged_defer` wrote the question, `intake_cleanup_status` showed it to the owner, and
+        // this listing rendered the arrival IDENTICALLY to three nobody had ever looked at. So the
+        // next session would judge it from scratch and hit the same wall — which is the exact
+        // failure the defer verb was built to end.
+        //
+        // ⚠ AND IT WAS IN THE API RESPONSE THE WHOLE TIME. `listStagedArrivals` returns
+        // `deferredQuestion`, with an engine test asserting it. The test passed. What was missing
+        // was a reader — the eighth instance of that shape this week, written into the very change
+        // whose stated purpose was avoiding it. An engine-level test cannot catch it, because the
+        // engine is not the surface anyone reads.
+        if (a.deferredQuestion) {
+          const asked = String(a.deferredQuestion.askedAt ?? '').slice(0, 10)
+          lines.push(`    ⏸ ASKED THE OWNER${asked ? ` on ${asked}` : ''} — do not re-judge this one: "${a.deferredQuestion.prompt}"`)
+          lines.push('       Still pending on purpose: it needs placing once they answer. Their answer is in `intake_cleanup_status.openQuestions`.')
+        } else if (a.blockingIdentifiers?.length) {
           lines.push(`    blocked by: ${a.blockingIdentifiers.join(', ')}`)
         } else {
           lines.push('    held because no brain could be determined (no unknown identifiers)')
@@ -4089,6 +4106,81 @@ function renderNudge(payload) {
     },
   )
 
+  // ⭐ THE OTHER HALF OF set_routing_identifier (2026-09-24). A claim was ONE CALL to create and,
+  // through this server, impossible to remove — so a wrong brain decision was permanent. That
+  // contradicts the thing ADR-0066 is built on: filing is a judgment, and judgments get revised.
+  //
+  // ⚠ THE ENGINE AND THE ENDPOINT BOTH ALREADY EXISTED. `clearPageRoutingIdentifier` and the DELETE
+  // on /api/brain/routing-identifiers have been there the whole time; only the agent-facing verb was
+  // missing, so the capability was real and unreachable. Ninth instance of that shape this week.
+  server.registerTool(
+    'unclaim_routing_identifier',
+    {
+      title: 'Remove a routing claim from a page',
+      description:
+        'Remove an identifier claim from a page — the counterpart to `set_routing_identifier`. Use it when a claim sends mail to the wrong brain, when a page was claimed by mistake, or when TWO brains claim the same key and you want one of them to stop (that is the case where nothing routes at all, because a split stages rather than picking). ' +
+        '⭐ THE RESPONSE TELLS YOU WHAT ROUTING DOES NOW, which is the reason to call it: removing a claim moves the identifier between "routes", "stages because nothing claims it" and "stages because several do", and the delete count alone cannot tell you which. Computed with the router\'s own logic. ' +
+        '⚠ HISTORY IS NOT UNDONE BY DEFAULT. `set_routing_identifier` HEALS history — it attaches every record already carrying the identifier — but removing the claim leaves those attachments in place, and the response says how many. That asymmetry is deliberate: a claim is a ROUTING RULE, an attachment is a RECORD\'S PLACEMENT, and one such claim was measured accounting for 1,271 attachments on a single page. Pass `detach: true` only when you mean to unfile them too; it never touches a governing attachment, or one a person or an LLM made rather than this claim. ' +
+        '⚠ REVERSIBLE BY CONSTRUCTION: `set_routing_identifier` puts it back in one call and re-heals history. No content is destroyed here, which is why this needs no dry run.',
+      inputSchema: {
+        kind: z.enum(['project', 'person', 'org', 'user']).describe('the page kind'),
+        name: z.string().optional().describe('page title (or pass ref)'),
+        ref: z.string().optional().describe('node ref from read_page — prefer over name when available'),
+        brain: z.string().optional().describe('brain label when the title is ambiguous across brains — REQUIRED in practice when two brains hold a page of the same name, which is the usual reason you are here'),
+        identifier: z.string().describe('the claim to remove, e.g. email:someone@example.com or repo:owner/name. See `my_routing_claims` for what is claimed where'),
+        detach: z.boolean().optional().describe('also remove the attachments this claim made (default false). Leaves governing attachments and anything a person or LLM attached'),
+      },
+    },
+    async ({ kind, name, ref, brain, identifier, detach }) => {
+      if (!name && !ref) return toolError('Pass name or ref')
+      let res
+      try {
+        res = await fetchCortex(`${BASE}/api/brain/routing-identifiers`, {
+          method: 'DELETE',
+          headers: { Authorization: `Bearer ${TOKEN}`, 'Content-Type': 'application/json' },
+          body: JSON.stringify({ kind, name, ref, brain, identifier, detach: detach === true }),
+        })
+      } catch (e) {
+        return toolError(`Could not remove the routing claim: ${e.message}`)
+      }
+      const out = await res.json().catch(() => null)
+      if (!res.ok) {
+        if (out?.candidates?.length) {
+          return toolError(`That page title is ambiguous across brains — pass \`brain\`. Candidates: ${out.candidates.join(', ')}`)
+        }
+        return toolError(`Could not remove the routing claim: ${out?.error ?? res.status}`)
+      }
+      // A ZERO IS A VERDICT, NOT AN ERROR — the same convention my_routing_claims states. "No such
+      // claim" is worth saying plainly, because the usual cause is that the claim is on a DIFFERENT
+      // page (or in a different brain) than the caller assumed, and retrying the same call will not
+      // find it either.
+      if (!out?.removed) {
+        return {
+          content: [{
+            type: 'text',
+            text: `No claim on ${identifier} was found on that page, so nothing changed. That usually means the claim lives on a different page or in another brain — \`my_routing_claims ${identifier}\` shows every page that claims it.`,
+          }],
+        }
+      }
+      const left = typeof out?.attachmentsLeft === 'number' ? out.attachmentsLeft : null
+      const historyLine = out?.detached
+        ? `\n  ${out.detached} attachment(s) this claim had made were also removed; governing attachments and anything a person or an LLM attached were left alone.`
+        : left
+          ? `\n  ⚠ ${left} record(s) this claim previously attached to that page are STILL attached — removing the rule does not unfile history. Re-run with \`detach: true\` if they should come off too.`
+          : ''
+      return {
+        content: [{
+          type: 'text',
+          text:
+            `Removed the claim on ${out?.identifier ?? identifier}.\n` +
+            `  ➜ ${out?.routing?.verdict ?? '(routing outcome unavailable)'}` +
+            historyLine +
+            `\n  Reversible: \`set_routing_identifier\` puts it back and re-attaches history.`,
+        }],
+      }
+    },
+  )
+
   // ── Gate 4 record triage, over timeline_claims ────────────────────────────────────────────
   // A connector event materializes in seconds and has no idea what the work WAS. The session that
   // did the work knows exactly, and arrives later. These three tools are that handoff: look at what

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@theronap/agnoclast-mcp",
-  "version": "0.9.170",
+  "version": "0.9.172",
   "description": "Connect your AI assistant to Cortex — your org's projects, activity, gaps, and directives, scoped to you.",
   "type": "module",
   "bin": {