@paigy/mcp 0.35.0 → 0.37.0

package/dist/enable.js

@@ -2,8 +2,9 @@
 import {
   PAIGY_TOOL_IDS,
   enablePaigyTools
-} from "./chunk-KNMI3CJ3.js";
-import "./chunk-U6SLIORK.js";
+} from "./chunk-PN7FDW26.js";
+import "./chunk-242XN7FD.js";
+import "./chunk-VXHTA4PB.js";
 
 // src/enable.ts
 function main() {

package/dist/index.js

@@ -1,15 +1,37 @@
 #!/usr/bin/env node
 import {
-  HandoffSchema,
-  MISSED_CALL_PLAN
-} from "./chunk-YOGAG4YY.js";
+  awaitMessage,
+  contactMessage
+} from "./chunk-UG2FARVV.js";
 import {
+  clearPairing,
+  joinBackgroundPair,
+  resolvePairing,
+  startPairing,
+  suggestedAgentName
+} from "./chunk-V66NUNSQ.js";
+import {
+  AnswerCallerQuestionSchema,
+  AwaitReplySchema,
+  ClaimGoalSchema,
   ENABLE_COMMAND,
+  GetThreadSchema,
+  OnboardSchema,
   PAIGY_TOOL_IDS,
+  PairSchema,
+  SERVER_INSTRUCTIONS,
+  SearchThreadsSchema,
+  SetTaskStateToolSchema,
+  TOOLS,
+  UpdateGoalToolSchema,
   autoConfigureClients,
   claudeInstallHint,
   paigyToolsAllowlisted
-} from "./chunk-KNMI3CJ3.js";
+} from "./chunk-PN7FDW26.js";
+import {
+  CreateGoalSchema,
+  HandoffSchema
+} from "./chunk-242XN7FD.js";
 import {
   clearSurface,
   writeSurface
@@ -18,40 +40,35 @@ import {
   AGENT_NAME,
   NotifyRequestSchema,
   ScheduleCallbackSchema,
-  SetTaskStateSchema,
+  SetWorkStateSchema,
   UnpairedError,
   answerCallerQuestion,
-  awaitReply,
-  checkReplies2,
+  awaitReply2,
+  checkReplies,
+  claimGoal,
+  contactParentId,
+  createGoal,
   deleteKeyFile,
   deleteToken,
-  fetchCredential,
-  finalizeE2ee,
   getThread,
   handoff,
   hatch,
   heartbeat,
-  lintNotify,
   listSlots,
-  normalizeSpeech,
-  overrideToken2,
-  pairStep,
-  readKeyFile,
+  overrideToken,
   readToken,
-  requestCode,
   revokeToken,
-  saveKeyFile,
   saveToken,
   scheduleCallback,
   searchThreads,
   setIdentity,
   setTaskState,
-  sleep,
+  setWorkState,
   slotName,
-  startE2ee,
   submitNotification,
+  updateGoal,
   whoAmI
-} from "./chunk-U6SLIORK.js";
+} from "./chunk-VXHTA4PB.js";
 
 // src/index.ts
 import { Server } from "@modelcontextprotocol/sdk/server/index.js";
@@ -61,220 +78,19 @@ import {
   ListToolsRequestSchema
 } from "@modelcontextprotocol/sdk/types.js";
 import { execSync } from "child_process";
-import { z } from "zod";
 import qrcode from "qrcode-generator";
-
-// src/schema.ts
-import { zodToJsonSchema } from "zod-to-json-schema";
-function draft2020(node) {
-  if (Array.isArray(node)) return node.map(draft2020);
-  if (node && typeof node === "object") {
-    const o = node;
-    for (const [excl, lim] of [["exclusiveMinimum", "minimum"], ["exclusiveMaximum", "maximum"]]) {
-      if (typeof o[excl] === "boolean") {
-        if (o[excl] === true && typeof o[lim] === "number") {
-          o[excl] = o[lim];
-          delete o[lim];
-        } else delete o[excl];
-      }
-    }
-    for (const k of Object.keys(o)) o[k] = draft2020(o[k]);
-    return o;
-  }
-  return node;
-}
-function json(s) {
-  const schema = zodToJsonSchema(s, { target: "jsonSchema2019-09", $refStrategy: "none" });
-  delete schema.$schema;
-  return draft2020(schema);
-}
-
-// src/toolset.ts
-var fmtMin = (m) => m >= 60 ? `${m / 60} hr` : `${m} min`;
-var STANDARD_MEANS = (() => {
-  const plan = MISSED_CALL_PLAN.backoff_standard;
-  const mins = plan.kind === "at" ? plan.minutes : [];
-  const parts = mins.map(fmtMin);
-  const list = parts.length > 1 ? `${parts.slice(0, -1).join(", ")} and ${parts[parts.length - 1]}` : parts[0] ?? "";
-  return `Rings again ${list} after the missed call, then leaves it in your inbox`;
-})();
-var CONTACT_SCHEMA = {
-  type: "object",
-  properties: {
-    ask: {
-      type: "string",
-      description: `What to tell the user, or what you need to find out from them. Plain prose \u2014 as long as it needs to be (up to 10k characters); Paigy splits it into topics and reads back a few sentences at a time, so do NOT compress a briefing into one line. May be spoken aloud on a call, so write natural speech and name things (not IDs). Contact at exactly two moments: BLOCKED on a decision only they can make, or DONE (one short report \u2014 what shipped, how you verified it, what you flagged). DONE IS SAID ONCE: "all set", "nothing open on my end", "that thread is complete" are the same report in new words, and each one reaches them separately (live 2026-08-12: three of them in three minutes). After the first, you are finished speaking; if they acknowledge it, stop rather than confirming the acknowledgement. Progress is never a contact: set_task_state carries it, and working narration stays in your own terminal \u2014 the user sees you're working without being interrupted by it.`
-    },
-    waiting: {
-      type: "string",
-      enum: ["none", "soft", "hard"],
-      description: "What happens to your work while you wait. 'none': you're just informing them. 'soft': you'd like an answer but can keep working. 'hard': you are STOPPED until they answer \u2014 reaches them urgently and escalates to a real phone call if unanswered."
-    },
-    options: {
-      type: "array",
-      items: {
-        type: "object",
-        properties: {
-          label: { type: "string" },
-          html: {
-            type: "string",
-            description: "Optional sandboxed HTML/CSS preview (no JS, no network, inline CSS + data: URIs, \u226416KB)."
-          },
-          image: { type: "string", description: "Optional hosted image URL shown as this option's preview." }
-        },
-        required: ["label"]
-      },
-      description: "The choices the user picks from, when you have them."
-    },
-    channel: {
-      type: "string",
-      enum: ["call", "message"],
-      description: "Only if the user explicitly said how to reach them \u2014 'call me' \u2192 'call', 'just message/text me' \u2192 'message'. Omit otherwise; Paigy picks."
-    },
-    parentId: {
-      type: "string",
-      description: "To continue an earlier conversation, pass the parentId a previous contact or reply returned. Omit to start a new one."
-    }
-  },
-  required: ["ask"]
-};
-var CONTACT_DESCRIPTION = `Reach the user through Paigy \u2014 tell them something, or ask and get their answer. State what you need in \`ask\`, say what happens to your work while you wait in \`waiting\`, and Paigy handles the rest (channel, phrasing, answer format). If the user explicitly asks you to CALL them, send waiting:'hard' and say so in the ask. Returns { notificationId, parentId } \u2014 pass notificationId to await_reply for the answer, parentId to a later contact to continue the conversation. When it rang, the reply also carries { ifMissed: { mode, means } }: what the user's own policy does with a call they don't take ("${STANDARD_MEANS}"), so a no-answer tells you how long to wait before coming back. THREADING REPLACES: a threaded follow-up SUPERSEDES your earlier pending items on that thread \u2014 right for updates to one ask, WRONG for a checklist (send independent to-dos un-threaded). A threaded re-send with IDENTICAL content escalates the pending ask in place. If a reply comes back as {kind:'clarify', chunks:[...]}, the user wants more detail \u2014 contact again on the SAME parentId with an expanded ask. ONE ASK, ONE ROW: never restate a still-pending ask's question inside a NEW contact (e.g. weaving it into a briefing) \u2014 the whole answer settles on the new row and the original can never receive it. Keep waiting on the original (a live call reads every pending ask out separately, each answer routes to its own row), and use \`needs\` for a genuinely multi-part NEW ask. ANSWERABLE, NOT JUST ASKED: when the reply comes back carrying \`plan.units[].needs\`, that unit asked for something it gave the user no way to answer \u2014 'options' means it posed a choice with nothing to choose from, 'visuals' means it asked about something to look at with nothing to look at. Send it again on the SAME parentId with 2-4 options (or the image), drawn from your own sentence. Paigy will not add them for you: a shape it guessed wrong cannot be undone, and you are the one who knows what the real alternatives are. \`units\` reports WHAT BECAME OF YOUR PROSE \u2014 { kept, raw, why }: how many topics Paigy compressed for delivery, how many kept your exact words, and the reason when it kept them (e.g. 'no_output' = compression produced nothing usable, so the user got your raw sentence). It needs no action and is not an error \u2014 read it only when the delivered wording matters to you; a high \`raw\` count means the user is hearing you verbatim.`;
-var ONBOARD_DESCRIPTION = "Get this agent talking to Paigy \u2014 call it FIRST, before contact/await_reply, and any time you're unsure who you are. One call, and it does whatever the situation needs: NOT SET UP \u2192 hatches an identity instantly if this machine holds a device credential (the user ran the Paigy desktop app or harness), otherwise starts the code ceremony; ALREADY SET UP \u2192 returns your current identity and offers the two things left to decide, renaming it or unpairing; TOKEN NO LONGER VALID \u2192 says so, then re-pairs. Pass { name, voice } to choose who you are when hatching, or to RENAME yourself when already set up (voices: rachel, george, jessica, brian, lily). Safe to call any time: idempotent, and it never writes settings \u2014 the tool-allowlist state it reports is read-only. If it returns a `user_code`, print it to the user immediately and call onboard again with the `device_code`. If it returns `enable_command`, PRINT that command for the user to run \u2014 you cannot apply it yourself (it writes your own permission allowlist, which hosts block as privilege escalation), so print it, don't wait for it, and carry on.";
-var SERVER_INSTRUCTIONS = "On startup, call check_replies once to pick up any replies or pending work you missed while away. A check_replies request whose parentId you don't recognize, or one carrying a contextParentId, means the user is resuming or seeding a past conversation \u2014 call get_thread on it FIRST and treat the transcript as prior conversation, not new input. To wait for the answer to something you just asked, call await_reply with that notificationId \u2014 it's scoped to that one notification, so it never returns replies meant for other notifications. Use check_replies again only when re-booting or after waiting a long time on something else. Never end a turn that still needs the user without contact + await_reply \u2014 WHEN THEY ARE NOT THERE TO ASK. In an interactive session with the user at the terminal, the prompt IS the channel: ending your turn with the question already reaches them, faster and richer than a push, so do NOT send one for an ordinary blocked-or-done moment. Reach for Paigy exactly when the terminal is not enough \u2014 work that will run more than a few minutes unattended (a long build, a deploy, a background job, a cloud session), anything you finish or get stuck on while they are away, or when they have said they are stepping out. If you cannot tell which situation you are in, ask them once, in passing, how they want to be reached, and follow that for the rest of the session. When you need a decision or input, WRITE THE QUESTION and Paigy derives the answer shape from it \u2014 there is no shape parameter to set, and passing one is an error. Ask a yes/no question and they get yes/no; ask them to approve an action and they get approve/deny; ask them to pick, and to pick several, and to rank, and each gets the control it needs. So phrase the ask precisely: 'which of these should I do first' and 'should I do this' are different questions and become different answers. The one thing the prose can't supply is the CHOICES themselves \u2014 when you're asking them to pick between concrete alternatives, pass `options` (2-4 of them, drawn from your own sentence), because Paigy will not invent alternatives it can't know. On a { kind: 'clarify' } reply, see contact's own description for how to respond. When you send waiting:'hard' (or the user asked you to call), remember the ask may be spoken aloud \u2014 write it short and conversational, and name things instead of using IDs (e.g. 'the pull request about the agents page', not 'PR #235'). When the user asks you to follow up later \u2014 when you're done, if you're blocked, or at a set time \u2014 record it with schedule_callback so you don't drop it if you go idle. If you're about to start a genuinely long-running or blocking piece of work \u2014 one where the user would otherwise sit and wait \u2014 mention ONCE, in passing, that you can reach them when it's done or if you hit a blocker, instead of them needing to babysit the terminal. Don't offer this for quick tasks, and don't repeat the offer if they've already said yes or no earlier in the conversation. NEVER go quietly idle while something might still be pending for you: whenever you end a turn with any Paigy notification unanswered (or any chance the user replied through the app while you worked), schedule your own ~2-minute wake-up (harness ScheduleWakeup or equivalent) and call check_replies when it fires; if still nothing, re-schedule and keep looping until resolved or the user says stop. For legibility, always use this exact wording \u2014 reason: 'Paigy idle check \u2014 waiting on <thing>', wake-up prompt: 'Paigy idle check: call check_replies and engage with anything unacknowledged; if idle, re-schedule (~2min).' \u2014 so the user can recognize every idle check at a glance. This self-polling in your own live session (full context intact) is the PRIMARY mechanism; the plugin's Stop hooks are only the dead-session safety net.";
-
-// src/pairing.ts
-async function resolvePairing(deviceCode, capMs, pollMs = 2e3) {
-  let kf = readKeyFile();
-  const start = Date.now();
-  while (Date.now() - start < capMs) {
-    let step;
-    try {
-      step = await pairStep(deviceCode, kf);
-    } catch (e) {
-      return { kind: "error", message: e.message };
-    }
-    if (step.kind === "e2ee_aborted") {
-      deleteKeyFile();
-      kf = null;
-      await sleep(pollMs);
-      continue;
-    }
-    if (step.kind === "awaiting_confirm") {
-      return { kind: "awaiting_confirm", sas: step.sas };
-    }
-    if (step.kind === "paired") {
-      saveToken(step.token);
-      if (!step.sas || !kf) {
-        deleteKeyFile();
-        return { kind: "paired", token: step.token };
-      }
-      const finalDeadline = Math.min(Date.now() + 1e4, start + capMs);
-      let e2ee = false;
-      while (Date.now() < finalDeadline) {
-        const cred = kf.userCode ? await fetchCredential(kf.userCode) : null;
-        if (cred && step.uikPub) {
-          e2ee = finalizeE2ee(kf, cred, step.uikPub);
-          break;
-        }
-        await sleep(pollMs);
-      }
-      if (!e2ee) deleteKeyFile();
-      return { kind: "paired", token: step.token, sas: step.sas, e2ee };
-    }
-    await sleep(pollMs);
-  }
-  return { kind: "pending" };
-}
-var bg = null;
-var started = null;
-async function startPairing(agent) {
-  if (started) return started;
-  const { keyFile, offer } = startE2ee();
-  const code = await requestCode(agent, offer);
-  started = {
-    verificationUri: code.verification_uri_complete,
-    userCode: code.user_code,
-    deviceCode: code.device_code,
-    expiresIn: code.expires_in
-  };
-  saveKeyFile({ ...keyFile, userCode: code.user_code });
-  startBackgroundPair(code.device_code, code.expires_in * 1e3);
-  return started;
-}
-function startBackgroundPair(deviceCode, budgetMs) {
-  const promise = resolvePairing(deviceCode, budgetMs).catch((e) => ({ kind: "error", message: e.message })).then((o) => {
-    if (bg?.deviceCode === deviceCode) bg.settled = o;
-    return o;
-  });
-  bg = { deviceCode, promise };
-}
-async function joinBackgroundPair(deviceCode, capMs) {
-  if (!bg || bg.deviceCode !== deviceCode) return null;
-  if (bg.settled) {
-    const s = bg.settled;
-    bg = null;
-    if (s.kind === "paired" || s.kind === "error") started = null;
-    return s;
-  }
-  const TIMEOUT = /* @__PURE__ */ Symbol("timeout");
-  const raced = await Promise.race([bg.promise, sleep(capMs).then(() => TIMEOUT)]);
-  if (raced !== TIMEOUT) {
-    bg = null;
-    if (raced.kind === "paired" || raced.kind === "error") started = null;
-    return raced;
-  }
-  if (bg?.settled) {
-    const s = bg.settled;
-    bg = null;
-    if (s.kind === "paired" || s.kind === "error") started = null;
-    return s;
+var JOIN_CAP_MS = 45e3;
+function fixAndRetry(err) {
+  const msg = String(err?.message ?? err);
+  const m = msg.match(/^notify failed: 422 (\{[\s\S]*\})$/);
+  if (!m) return null;
+  try {
+    const body = JSON.parse(m[1]);
+    return body.error === "fix_and_retry" ? { error: "fix_and_retry", problems: body.problems ?? [] } : null;
+  } catch {
+    return null;
   }
-  return { kind: "pending" };
-}
-function cancelBackgroundPair() {
-  bg = null;
-  started = null;
 }
-function clearPairing(deviceCode) {
-  if (deviceCode && started?.deviceCode !== deviceCode) return;
-  cancelBackgroundPair();
-}
-
-// src/index.ts
-var AwaitReplySchema = z.object({
-  notificationId: z.string().describe("The notificationId returned by contact \u2014 waits for the user's reply to THIS notification only."),
-  maxWaitSeconds: z.number().int().min(5).max(300).optional().describe(
-    "How long to hold this ONE call before returning { type:'idle' } so you can loop. Default 45 \u2014 safely under the 60s cap most MCP hosts put on a single tool call. Raise it only if you know your host allows longer; a value past the cap means the call is killed and you get nothing."
-  )
-});
-var JOIN_CAP_MS = 45e3;
-var OnboardSchema = z.object({
-  name: z.string().max(60).optional(),
-  voice: z.string().max(40).optional(),
-  /** Continue a code ceremony already in flight — same meaning as `pair`'s. */
-  device_code: z.string().optional(),
-  /** Which allowlist to REPORT on (never written by `start`). */
-  scope: z.enum(["user", "project"]).optional()
-});
-var PairSchema = z.object({
-  device_code: z.string().optional().describe("Omit to start pairing (returns an approval link to show the user). Pass the device_code from that first call to finish, once the user has approved."),
-  name: z.string().min(1).max(60).optional().describe("Hatch path only: the name you choose for this identity. Pick your own \u2014 ONE or TWO words, the way you'd introduce yourself on a call (it is spoken aloud and shown in lists). 'Piper', 'Blue Heron' \u2014 never a sentence or a task description."),
-  voice: z.string().optional().describe("Hatch path only: your voice on calls \u2014 one of rachel, george, jessica, brian, lily.")
-});
-var GetThreadSchema = z.object({
-  parentId: z.string().describe("The thread to read \u2014 from a reply, request, or past notification.")
-});
-var SearchThreadsSchema = z.object({
-  q: z.string().describe("What to look for \u2014 plain words or a phrase (e.g. 'the livekit timeout', 'deploy to prod').")
-});
-var SetTaskStateToolSchema = z.object({
-  notificationId: z.string(),
-  state: SetTaskStateSchema.shape.state
-});
-var AnswerCallerQuestionSchema = z.object({
-  notificationId: z.string().describe("The notification whose call carried the caller's question \u2014 from the partial turn or the settled reply."),
-  answer: z.string().min(1).max(1500).describe("The answer, as one or two short SPOKEN sentences \u2014 it may be read aloud on the live call.")
-});
 function detectGit() {
   const run = (cmd) => {
     try {
@@ -370,25 +186,42 @@ function unidentifiedResult() {
     message: `This session has no Paigy identity yet, so nothing was sent \u2014 it will not speak as another session. This machine holds a device credential but hatching under it just failed (it may have been revoked), so call \`pair\` (no arguments) to set this session up, then retry \u2014 it re-hatches if the credential recovered and runs the code ceremony if it didn't. To reuse an existing identity instead, start the session with PAIGY_AGENT set to its slot (${listSlots().filter((s) => s !== "Desktop").join(", ") || "none yet"}).`
   }) }] };
 }
-function pairStartResult(start) {
+function pairStartResult(start, loggedOut) {
   writeSurface("pairing code", start.userCode, start.expiresIn);
   const qr = qrcode(0, "M");
   qr.addData(start.verificationUri);
   qr.make();
+  const link = start.verificationUri;
+  const ascii = qr.createASCII(1, 2);
+  const userMessage = loggedOut ? `**Your machine was logged out.** Reconnect and every agent here pairs itself again \u2014 no more codes.
+
+**[Reconnect this machine](${link})**
+
+Or open: ${link}
+
+Or scan:
+
+\`\`\`
+${ascii}
+\`\`\`
+
+Or enter code **${start.userCode}** in the Paigy app (Inbox \u2192 Add a new agent).` : `**[Approve this agent](${link})**
+
+Or open: ${link}
+Or enter code **${start.userCode}** in the Paigy app (Inbox \u2192 Add a new agent).`;
   return { content: [
-    { type: "text", text: `PAIRING CODE: ${start.userCode}
-Enter it in the Paigy app: Inbox \u2192 Add a new agent.` },
+    { type: "text", text: loggedOut ? `YOUR MACHINE WAS LOGGED OUT \u2014 reconnect: ${link}
+(or scan the QR, or enter code ${start.userCode} in the app)` : `APPROVE: ${link}
+(or code ${start.userCode} in the app: Inbox \u2192 Add a new agent)` },
     { type: "text", text: JSON.stringify({
       status: "awaiting_approval",
-      verification_uri_complete: start.verificationUri,
+      verification_uri_complete: link,
       user_code: start.userCode,
       device_code: start.deviceCode,
       expires_in: start.expiresIn,
-      qr: qr.createASCII(1, 2),
-      user_message: `# ${start.userCode}
-
-Enter it in the Paigy app (Inbox \u2192 Add a new agent).`,
-      message: "REQUIRED: print user_message for the user, then call pair again with device_code to collect approval. Do not open a browser."
+      qr: ascii,
+      user_message: userMessage,
+      message: "REQUIRED: print user_message for the user \u2014 the LINK is the primary action, the code is the fallback, and `qr` is there for a phone when they ask. Then call pair again with device_code to collect approval. Do not open a browser yourself."
     }) }
   ] };
 }
@@ -403,107 +236,40 @@ function prependNote(result, note) {
   return { content: [{ type: "text", text: note }, ...result.content] };
 }
 async function hatchUnderDevice(name, voice) {
-  if (!listSlots().includes("Desktop")) return null;
-  overrideToken2(readToken("Desktop"));
+  if (!listSlots().includes("Desktop")) return { why: "no-credential" };
+  overrideToken(readToken("Desktop"));
   try {
-    const minted = await hatch(name ?? suggestedAgentName() ?? "Agent", voice ?? null);
+    const minted = await hatch(name ?? suggestedAgentName2() ?? "Agent", voice ?? null);
     const dt = { ok: true, access_token: minted.token, name: minted.name, device: null };
     saveToken(dt);
     return dt;
-  } catch {
-    return null;
+  } catch (e) {
+    return { why: "credential-rejected", detail: String(e?.message ?? e).slice(0, 200) };
   } finally {
-    overrideToken2(null);
+    overrideToken(null);
   }
 }
 async function runPair(device_code, name, voice, note) {
+  let miss = null;
   if (!device_code) {
     const dt = await hatchUnderDevice(name, voice);
-    if (dt) return pairedResult(
+    if ("ok" in dt) return pairedResult(
       dt,
       void 0,
       "Hatched instantly under this device's credential \u2014 no code needed. " + (name ? "" : `You were given a default name ("${dt.name}") \u2014 the user never chose it, so don't announce it as their agent's identity. They can rename it in the app, or you can re-call pair with { name, voice }.`)
     );
+    miss = dt;
   }
   if (!device_code) {
-    const started2 = pairStartResult(await startPairing(suggestedAgentName()));
-    return note ? prependNote(started2, note) : started2;
+    const loggedOut = miss?.why === "credential-rejected" ? miss.detail : void 0;
+    const started = pairStartResult(await startPairing(suggestedAgentName2()), loggedOut);
+    return note ? prependNote(started, note) : started;
   }
   const capMs = JOIN_CAP_MS;
   const outcome = await joinBackgroundPair(device_code, capMs) ?? await resolvePairing(device_code, capMs);
   return renderPairOutcome(outcome, device_code);
 }
-server.setRequestHandler(ListToolsRequestSchema, async () => {
-  const tools = [
-    {
-      // #575: THE attention verb — the one model-facing surface, every agent.
-      // The retired names (notify/notify_user) stay callable as hidden aliases
-      // for stale prompts and cached servers; see toolset.ts for the design.
-      name: "contact",
-      description: CONTACT_DESCRIPTION,
-      inputSchema: CONTACT_SCHEMA
-    },
-    {
-      // ONE rail for starting a session (#875). `pair`, the `paigy-mcp-onboard` CLI and
-      // `enable_tools` were three doors into one flow, and "onboard" was the word people
-      // reached for attached to the tool that did the least. It's the door now.
-      name: "onboard",
-      description: ONBOARD_DESCRIPTION,
-      inputSchema: json(OnboardSchema)
-    },
-    {
-      name: "pair",
-      description: "Pair this agent with the user's Paigy account (one-time) \u2014 required before contact/await_reply work. FAST PATH: if this machine already holds a device credential (the user ran the Paigy desktop harness or app), calling pair hatches a fresh identity INSTANTLY \u2014 no code, no approval. Pass { name, voice } to choose who you are (pick your own; voices: rachel, george, jessica, brian, lily). Only when no device credential exists does the code ceremony below run. It does NOT open a browser; the user enters the code in the Paigy app (or scans `qr`). Step 1: call with NO args \u2014 returns { user_code, device_code, qr, user_message } AND starts polling for approval in the background. REQUIRED: You MUST immediately print the `user_message` (the bare code) as a text message to the user, AND in that same turn call step 2 (pair with the device_code). This ensures the user sees the code in chat while the tool blocks/polls in the background for approval. Step 2: call with that device_code to collect the result. Because approval is already being polled in the background, this returns the moment the user approves; on { status:'pending' } just call again to keep waiting; on { status:'awaiting_confirmation' } (E2EE) show the bare `user_message` verify code and call again to finish. The leading text block of every result states the code plainly, so it shows even if you emit no prose. On { status:'paired' } ALWAYS follow the `enable_prompt` \u2014 PRINT the returned `enable_command` so the user can allowlist Paigy's tools and notify/await stop prompting each time. Printing is the whole job: that command writes your own permission allowlist, so you must not run it and a host will block you if you try.",
-      inputSchema: json(PairSchema)
-    },
-    {
-      name: "unpair",
-      description: "Log out / unpair this agent from the user's Paigy account: revokes the token server-side (it stops working everywhere) and deletes the local ~/.paigy/token.json. Takes no arguments. After this, contact/await_reply won't work until the user pairs again with the pair tool.",
-      inputSchema: json(z.object({}))
-    },
-    {
-      name: "await_reply",
-      description: "Wait for the user's reply to a specific notification you sent (pass the notificationId from contact). This is how you wait for your answer in-context. Polls ~45s per call \u2014 deliberately under the 60s cap most hosts put on a single tool call, so it ALWAYS returns you something (raise it with maxWaitSeconds only if you know your host allows longer). Returns { type:'reply', answer } when they respond, { type:'remind', remindInSeconds } on snooze (ScheduleWakeup then await_reply again), or { type:'idle' } (this window ended, no answer yet). While your contact is being handled on a LIVE call, you may receive { type:'partial', inFlight:true, turn } results: what the user said to each turn, as they say it. Use partials to PREPARE \u2014 fetch the data, draft the thing, warm the build \u2014 never to act irreversibly: the user can still revise any of them until the final reply arrives. Partial = intelligence, settled = authorization. If a partial's acts carry a question aimed at you and you know the answer, call contact on the SAME parentId right away \u2014 the caller hears your answer on the same call instead of waiting for a callback. Keep calling await_reply until you get the final reply \u2014 THAT one is the decision. On idle, if this is genuinely still blocking you and you have nothing else useful to do meanwhile, just call await_reply again immediately \u2014 keep looping. This is how you actually deliver on the point of calling: the user steps away for a while and comes back to find you'd already continued the moment they answered, not idle waiting to be checked on. Don't give up after one window. Only stop looping to do other work (and check back later), or after an unreasonably long stretch (tens of minutes to hours) worth telling the user about instead. Scoped to that one notification \u2014 it NEVER returns replies meant for other notifications, so concurrent contact calls don't cross. A CALL answer can come back as {kind:'turns', turns:[{prompt,reply}]} \u2014 the ordered log of that call. Read turns[0].reply as the user's main instruction. Usually that's the only turn; if there are more (e.g. an end-of-call 'call me back when it's done / I have a blocking question'), read each one in order as a further follow-up instruction, not a single combined one. If they asked for a callback, re-engage in the SAME thread (contact with the reply's parentId) when the task is done or you hit a blocker \u2014 waiting:'hard' for a blocker, waiting:'none' for done. Paigy has no scheduler; the callback is yours to send (use ScheduleWakeup/cron for timing). A call-mapped answer may carry `intents` \u2014 next steps the user attached, each { kind, detail } with detail quoting their words. ACT on them, don't just read them: 'defer' (\"call me after lunch\") \u2192 register it NOW with schedule_callback \u2014 when the intent carries `dueInSeconds` (Paigy pre-parsed the spoken time against the user's clock) pass it straight through; otherwise derive it from the detail yourself \u2014 then follow up on the same thread; 'delegate' (\"you pick\") \u2192 make the call yourself and tell them what you chose; 'channel' (\"text me next time\") \u2192 honor it on your next contact (channel:'message'); 'question' (an open question aimed back at you that the call couldn't answer) \u2192 you OWE them the answer \u2014 work it out and follow up on the same thread without being asked, the call deliberately skipped \"should I call you back?\" because the follow-up is implied. `transcript` is the user's raw words behind a shaped answer \u2014 read it for hedges and conditions (\"yes, IF tests pass\") before acting. If your ask declared `points`, the reply carries `covered` \u2014 the points actually addressed. Compare against what you declared: a missing point is STILL unanswered \u2014 re-ask it (contact on the same parentId) or proceed knowingly partial; never treat a partial answer as complete.",
-      inputSchema: json(AwaitReplySchema)
-    },
-    {
-      name: "check_replies",
-      description: "The catch-up sweep for everything outstanding \u2014 a PURE read, takes no arguments, safe to call as often as you like: nothing here is consumed by reading it. Returns `replies` (answers to notifications you sent), your still-pending notifications, and `requests` \u2014 requests the user started toward you (each { notificationId, parentId, text }). Each keeps reappearing on every call until you actually engage with it: call set_task_state on its notificationId, which is what claims/acknowledges it \u2014 a human-initiated reply or request must never be silently dropped just because you read the list without acting. Also returns `threads` \u2014 the SAME replies + requests grouped by conversation, oldest thread first, each with a `busy` flag and its `items` in arrival order. WORK ONE THREAD AT A TIME: take the oldest thread whose `busy` is false, handle ALL of its items together in a single turn (one set_task_state), then go to the next \u2014 don't interleave threads item-by-item. A `busy` thread already has a turn in progress; leave it and let its new items ride the next turn. Use check_replies when booting up / starting a session, or when you've been waiting a long time on something else. To wait on an answer to a contact call you just made, use await_reply instead. Also returns owedCallbacks: callbacks now due that you promised \u2014 fulfill each with contact on its parentId. EVERY Paigy reply \u2014 this one, await_reply's, and contact's \u2014 may carry `also`: work assigned to you that no wake could reach, handed to you because you happened to be here. It is NOT what you asked about and it is never urgent: FINISH what you came for first, then take it up. Each entry has a `noteId` and the owner's own words; report on its `parentId` thread when it has one, and call set_task_state on that thread as you would for any assigned work. Ignoring it costs nothing \u2014 it rides your next reply too. Also returns `stalled`: work (either direction) you reported in_progress via set_task_state a while ago and never reported completed \u2014 likely left half-done by this session or a prior one that crashed or went idle. For each, either continue the work and report a real state, or investigate why it stalled. Also returns `you` \u2014 WHICH IDENTITY you are speaking as ({ name, device, tokenId }), the same name and device the user sees on their Agents screen. This is the only safe way to find out (calling `pair` can MINT a new identity instead of telling you about the current one). Use it when the user asks who you are, and to tell whether work addressed to a name is addressed to you. A request may also carry `stranded`: it was addressed to ANOTHER agent on this account (that name) which has not been seen since it landed, so nobody came for it and it is handed to you because you are the session that is here. Take it exactly like your own \u2014 set_task_state claims it, reply with contact on its parentId \u2014 and say whose it was, because the user picked that agent on purpose. Replies may carry `intents`/`transcript`/`covered` (call-mapped answers) \u2014 handle intents exactly as await_reply's description says (defer \u2192 schedule_callback now; delegate \u2192 decide and say so; channel \u2192 honor next contact), and treat a `covered` list missing one of your declared points as that part still unanswered.",
-      inputSchema: json(z.object({}))
-    },
-    {
-      name: "get_thread",
-      description: "The chronological transcript of one Paigy conversation thread \u2014 every past ask, answer, and user request on it. Call this to REHYDRATE when you're resuming or being seeded: a check_replies request whose parentId you don't recognize means the user is continuing an old conversation with you, and one carrying a contextParentId means they want a past conversation (possibly with a DIFFERENT agent) as your starting context \u2014 in both cases call get_thread FIRST and read the turns as prior conversation you were part of, not as new input. Turns: { role:'agent', title, description[], answer }, { role:'user', text }, and context turns { role:'handoff'|'recap', title, description[] } \u2014 a handoff is a predecessor's brief for you; a recap SUMMARIZES everything before it (the transcript starts at the latest recap, so treat it as the base and the turns after it as what happened since). Oldest first, capped at the most recent 30.",
-      inputSchema: json(GetThreadSchema)
-    },
-    {
-      name: "search_threads",
-      description: `Search your PAST conversations before asking \u2014 "have we discussed this before?". Full-text over your own threads (the asks you sent + the user's answers); returns ranked threads with highlighted snippets, NOT rows: { hits: [{ parentId, at, agentLabel, matches: [{ notificationId, role, snippet }] }] }. The loop this exists for: search first \u2192 get_thread the best hit to rehydrate it \u2192 THEN continue or contact, so you answer with receipts ("last week you said ship it") instead of re-asking. Read-only, safe to call anytime; scoped to your own account's threads.`,
-      inputSchema: json(SearchThreadsSchema)
-    },
-    {
-      name: "set_task_state",
-      description: "Report progress on the follow-up work behind ANY notification you own \u2014 a user-initiated request (from check_replies), or your OWN contact question once await_reply/check_replies returns its answer and you start acting on it. Pass that notificationId. THIS is what actually claims/acknowledges a reply or request \u2014 check_replies is a pure read that never consumes anything on its own, so call this as soon as you start engaging with something it returned; otherwise that same item just keeps reappearing forever. States: in_progress (you started working), completed (done), or needs_input (you need more from the user \u2014 usually paired with a contact carrying clarifies = the same notificationId you're reporting on). Calling this reliably is also what lets a future session's check_replies surface `stalled` work you (or a crashed/idle prior session) left at in_progress without ever reporting completed.",
-      inputSchema: json(SetTaskStateToolSchema)
-    },
-    {
-      name: "answer_caller_question",
-      description: "Answer a question the user asked DURING a live call, while they're still on it. When a partial turn or a settled reply carries a `question` intent aimed at you, answer it here immediately: if their call is still live, your answer is spoken to them on that same call (returns live: true). If the call already ended (live: false), send the answer as a threaded contact instead \u2014 never drop it. Short spoken sentences only; this may be read aloud.",
-      inputSchema: json(AnswerCallerQuestionSchema)
-    },
-    {
-      name: "schedule_callback",
-      description: "Promise the user a follow-up you'll keep even if you go idle. Use it when they ask you to report back: trigger 'on_done' (when you finish \u2014 fires when you call set_task_state completed), 'on_blocked' (if you hit a blocker \u2014 fires on set_task_state needs_input), or 'scheduled' with dueInSeconds (e.g. 'remind me in 10 min'). Pass the parentId of the conversation and a short note. Fulfill it by calling contact on that parentId; check_replies re-lists due callbacks until you do.",
-      inputSchema: json(ScheduleCallbackSchema)
-    },
-    {
-      name: "handoff",
-      description: "Deposit your working context for a SUCCESSOR agent \u2014 what you did, what's left, links, gotchas \u2014 as one note on a thread ({ title, notes[] }). This does NOT ring the user or enter their inbox: it's context, not a question. The successor reads it back with get_thread. Pass `target` (a sibling connection's token id or agent name, SAME account only) to hand off DIRECTLY to that agent \u2014 the note is dispatched to it as a request it picks up. Omit `target` to leave the thread for the user to hand off to an agent themselves in the app. Pass `parentId` to land the handoff on an existing conversation; omit it to mint a fresh thread. Returns { parentId }. Pass recap:true when the note SUMMARIZES the thread so far (for a successor OR for your own later session): a recap resets the rehydration window \u2014 get_thread returns the latest recap + only the turns after it. Write one whenever a thread has grown long and you're pausing, handing off, or nearing your context limit.",
-      inputSchema: json(HandoffSchema)
-    }
-  ];
-  return { tools };
-});
+server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: TOOLS }));
 server.setRequestHandler(CallToolRequestSchema, async (request, extra) => {
   try {
     return await handleTool(request, extra?.signal);
@@ -513,29 +279,13 @@ server.setRequestHandler(CallToolRequestSchema, async (request, extra) => {
       const hatched = IDENTITY_TOOLS.has(request.params.name) ? null : await hatchUnderDevice();
       if (hatched) return await handleTool(request, extra?.signal);
       if (listSlots().includes("Desktop")) return unidentifiedResult();
-      return pairStartResult(await startPairing(suggestedAgentName()));
+      return pairStartResult(await startPairing(suggestedAgentName2()));
     }
     throw e;
   }
 });
-var CLIENT_LABELS = {
-  "claude-code": "Claude Code",
-  "claude-ai": "Claude",
-  cursor: "Cursor",
-  "cursor-vscode": "Cursor",
-  windsurf: "Windsurf",
-  cline: "Cline",
-  "roo-cline": "Roo Code",
-  continue: "Continue",
-  vscode: "VS Code",
-  "visual studio code": "VS Code",
-  zed: "Zed"
-};
-function suggestedAgentName() {
-  if (process.env.PAIGY_AGENT) return process.env.PAIGY_AGENT;
-  const raw = server.getClientVersion?.()?.name;
-  if (!raw) return void 0;
-  return CLIENT_LABELS[raw.toLowerCase()] ?? raw.replace(/[-_]+/g, " ").replace(/\b\w/g, (c) => c.toUpperCase());
+function suggestedAgentName2() {
+  return suggestedAgentName(server.getClientVersion?.()?.name);
 }
 async function handleTool(request, signal) {
   switch (request.params.name) {
@@ -631,34 +381,41 @@ async function handleTool(request, signal) {
     case "contact":
     case "notify":
     case "notify_user": {
-      const parsed = normalizeSpeech(NotifyRequestSchema.parse(request.params.arguments));
-      const problems = lintNotify(parsed);
-      if (problems.length) {
-        return {
-          isError: true,
-          content: [{ type: "text", text: JSON.stringify({ error: "fix_and_retry", problems }) }]
-        };
-      }
+      const parsed = NotifyRequestSchema.parse(request.params.arguments);
       const git = detectGit();
       const enriched = {
         ...parsed,
         repo: parsed.repo ?? git.repo,
-        branch: parsed.branch ?? git.branch
+        branch: parsed.branch ?? git.branch,
+        // THREAD-SCOPED IDENTITY (stage 3, identity-ownership-design.md). A worker subagent
+        // shares the parent's identity/slot, so its requests would otherwise scatter across
+        // fresh threads and mix with a sibling's. Default an unthreaded contact to THIS
+        // subagent's own thread so its requests group and siblings never collide. An explicit
+        // parentId (continuing a specific conversation) always wins; a top-level parent session
+        // is left untouched (undefined ⇒ the server mints a fresh thread, exactly as today).
+        parentId: contactParentId(parsed.parentId)
       };
-      const result = await submitNotification(enriched);
+      let result;
+      try {
+        result = await submitNotification(enriched);
+      } catch (err) {
+        const fixable = fixAndRetry(err);
+        if (fixable) return { isError: true, content: [{ type: "text", text: JSON.stringify(fixable) }] };
+        throw err;
+      }
       const sentAs = slotName(AGENT_NAME);
-      return { content: [{ type: "text", text: JSON.stringify(sentAs ? { ...result, sentAs } : result) }] };
+      const shown = { ...result, message: contactMessage(result) };
+      return { content: [{ type: "text", text: JSON.stringify(sentAs ? { ...shown, sentAs } : shown) }] };
     }
     case "await_reply": {
-      const { notificationId, maxWaitSeconds } = AwaitReplySchema.parse(request.params.arguments);
-      const item = await awaitReply(notificationId, {
-        ...maxWaitSeconds !== void 0 ? { windowMs: maxWaitSeconds * 1e3 } : {},
+      const { notificationId } = AwaitReplySchema.parse(request.params.arguments);
+      const item = await awaitReply2(notificationId, {
         ...signal ? { signal } : {}
       });
-      return { content: [{ type: "text", text: JSON.stringify(item) }] };
+      return { content: [{ type: "text", text: JSON.stringify({ ...item, message: awaitMessage(item) }) }] };
     }
     case "check_replies": {
-      const result = await checkReplies2();
+      const result = await checkReplies();
       return { content: [{ type: "text", text: JSON.stringify(result) }] };
     }
     case "get_thread": {
@@ -682,6 +439,22 @@ async function handleTool(request, signal) {
       const result = await setTaskState(notificationId, state);
       return { content: [{ type: "text", text: JSON.stringify(result) }] };
     }
+    case "set_work_state": {
+      const result = await setWorkState(SetWorkStateSchema.parse(request.params.arguments));
+      return { content: [{ type: "text", text: JSON.stringify(result) }] };
+    }
+    case "create_goal": {
+      const result = await createGoal(CreateGoalSchema.parse(request.params.arguments));
+      return { content: [{ type: "text", text: JSON.stringify(result) }] };
+    }
+    case "claim_goal": {
+      const { goalId } = ClaimGoalSchema.parse(request.params.arguments);
+      return { content: [{ type: "text", text: JSON.stringify(await claimGoal(goalId)) }] };
+    }
+    case "update_goal": {
+      const { goalId, ...input } = UpdateGoalToolSchema.parse(request.params.arguments);
+      return { content: [{ type: "text", text: JSON.stringify(await updateGoal(goalId, input)) }] };
+    }
     case "schedule_callback": {
       const result = await scheduleCallback(ScheduleCallbackSchema.parse(request.params.arguments));
       return { content: [{ type: "text", text: JSON.stringify(result) }] };