@paigy/mcp 0.32.0 → 0.34.0

package/dist/{chunk-XSHUDPJ3.js → chunk-45CIZLCJ.js}

@@ -51,6 +51,12 @@ var ReceiptEventSchema = z.enum([
   // the recipient opened it
   "answered",
   // the recipient replied
+  // The recipient TURNED THE RING DOWN — CallKit ended it and no answer was ever tapped.
+  // Written by the phone, on the same door that reports the ring itself, so it exists only
+  // when a ring reached a running app and a person did not take it. That is what separates
+  // it from "a ring with no answer", which our own crashes wrote just as readily and which
+  // is why the responsiveness back-off had to be removed (#1144).
+  "declined",
   "escalated",
   // re-reached at a higher level (re-ring / promote)
   "coalesced",
@@ -59,8 +65,14 @@ var ReceiptEventSchema = z.enum([
   // deadline passed unanswered
   "woke",
   // the agent was woken for an owed obligation (callback)
-  "gave_up"
+  "gave_up",
   // the budget was spent — stopped re-engaging
+  // The ladder starts over — a silent pickup (the owner's fresh-miss rule, 2026-07-28), a
+  // promote to call, a re-delivery. APPENDED, never a rewind: `ring_step` was a cache of
+  // the escalated-count and a writer rewound it to 0 on every unanswered call (2026-08-24,
+  // nine rings in an hour, `gaveUp` unreachable). A count since the last `restarted` cannot
+  // be rewound by a writer that forgot to advance it.
+  "restarted"
 ]);
 var AttentionSchema = z.object({
   urgency: NotifyLevelSchema,
@@ -250,6 +262,14 @@ var IntentSchema = z.object({
    *  about what cannot answer "is the bot looping less this week?". */
   fault: z.enum(["loop", "unanswered", "overridden", "misheard", "slow", "other"]).optional()
 });
+var RideAlongSchema = z.object({
+  /** The note this came from — assign/clarify/close it through /api/notes/:id. */
+  noteId: z.string(),
+  /** What to do, in the owner's own words (the note's headline). Never model-rewritten. */
+  text: z.string(),
+  /** The thread to report back on, when the note was dispatched over the request rail. */
+  parentId: z.string().nullable()
+});
 var AwaitItemSchema = z.discriminatedUnion("type", [
   z.object({
     type: z.literal("reply"),
@@ -270,7 +290,13 @@ var AwaitItemSchema = z.discriminatedUnion("type", [
     transcript: z.string().optional(),
     /** Coverage report (#396), when the ask declared `points`: which of them this
      *  answer addressed. Missing points = re-ask or proceed knowingly partial. */
-    covered: z.array(z.string()).optional()
+    covered: z.array(z.string()).optional(),
+    /** Ride-alongs (RideAlongSchema) — pending work for you, attached to the moment you
+     *  became free. Only `reply` and `idle` carry it: those are the two outcomes that
+     *  END a wait. `remind`, `superseded` and `turn` are mid-flight, and handing an
+     *  agent a side-quest while it is still holding the line is how the main thing gets
+     *  dropped. Absent/empty = nothing owed. */
+    also: z.array(RideAlongSchema).optional()
   }),
   z.object({
     type: z.literal("remind"),
@@ -305,7 +331,7 @@ var AwaitItemSchema = z.discriminatedUnion("type", [
       acts: z.array(IntentSchema).nullable().optional()
     })
   }),
-  z.object({ type: z.literal("idle") })
+  z.object({ type: z.literal("idle"), also: z.array(RideAlongSchema).optional() })
 ]);
 var CallbackTriggerSchema = z.enum(["on_done", "on_blocked", "scheduled"]);
 var ScheduleCallbackSchema = z.object({
@@ -336,6 +362,12 @@ var PendingRepliesSchema = z.object({
   pending: z.array(
     z.object({ parentId: z.string(), notificationId: z.string(), createdAt: z.string() })
   ),
+  /** WHO YOU ARE on this account (field report 2026-08-28): the name and device the user
+   *  sees for this session's identity. From inside a session there was no way to find out —
+   *  `pair` with no arguments can HATCH a fresh identity, so it is not a safe probe — and an
+   *  agent that cannot tell which agent it is cannot tell whether work addressed to
+   *  "Reta" was addressed to it. Absent only for a token with no pairing behind it. */
+  you: z.object({ name: z.string(), device: z.string().nullable(), tokenId: z.string() }).optional(),
   /** User-initiated requests addressed to this agent; act on them and reply via
    *  contact on the same parentId. Keeps reappearing until you call
    *  set_task_state on its notificationId. */
@@ -347,12 +379,21 @@ var PendingRepliesSchema = z.object({
       createdAt: z.string(),
       /** The user seeded this request with a past conversation — call get_thread on it
        *  FIRST and treat the transcript as prior context (#57/#251). */
-      contextParentId: z.string().optional()
+      contextParentId: z.string().optional(),
+      /** STRANDED (field report 2026-08-28): this request was addressed to ANOTHER agent on
+       *  the account — the name here — which has not been seen since it landed, so nobody
+       *  came for it. Handed to you because you are the session that is here. Take it like
+       *  any request (set_task_state claims it, reply with contact on its parentId), and say
+       *  whose it was, because the user chose that agent on purpose. */
+      stranded: z.string().optional()
     })
   ),
   /** Callbacks you owe the user that are now DUE (you said you'd follow up when done,
    *  if blocked, or at a time that has passed). Re-surfaced every sweep until you
    *  fulfill one by calling contact on its parentId. */
+  /** Ride-alongs (RideAlongSchema): notes assigned to this agent that no wake could
+   *  reach. Same array the contact/await replies carry — one queue, every carrier. */
+  also: z.array(RideAlongSchema).optional(),
   owedCallbacks: z.array(
     z.object({ parentId: z.string(), trigger: CallbackTriggerSchema, note: z.string() })
   ),
@@ -388,7 +429,11 @@ var NotifyResponseSchema = z.object({
   status: NotifyStatusSchema,
   createdAt: z.string().datetime(),
   answer: UserAnswerSchema.optional(),
-  answeredAt: z.string().datetime().optional()
+  answeredAt: z.string().datetime().optional(),
+  /** Ride-alongs for THIS agent — pending work it should pick up when it's done with
+   *  what it came for. Present on any reply, because an unwakeable agent's only
+   *  reliable moment is one it initiated. Absent/empty = nothing owed. */
+  also: z.array(RideAlongSchema).optional()
 });
 var NotifyPlanUnitSchema = z.object({
   notificationId: z.string(),
@@ -440,6 +485,9 @@ var UserResponseSchema = z.object({
 });
 var VoiceKeySchema = z.enum(["rachel", "george", "jessica", "brian", "lily"]);
 var AgendaTurnSchema = z.object({
+  /** Twin coverage (#1089): sibling claim ids this asking turn's answer ALSO settles —
+   *  the planner declares duplicates instead of asking them twice. */
+  coveredIds: z.array(z.string()).optional(),
   /** At most three short spoken sentences. Capped because a turn is a breath: a 1031-char
    *  line went out on 2026-07-28 and the caller could not answer it at all. */
   info: z.array(z.string().min(1)).max(3).default([]),
@@ -473,6 +521,7 @@ var AgendaTurnSchema = z.object({
    *  on, the claim stays pending; blocking:true on context = hold for a reply. */
   blocking: z.boolean().optional()
 });
+var CLAIM_STALE_MS = 30 * 6e4;
 var InboxItemSchema = z.object({
   id: z.string(),
   /** The conversation thread + connection this item lives on. Present on the replied
@@ -492,6 +541,15 @@ var InboxItemSchema = z.object({
    *  (live 2026-08-10, D35). The API already orders by it; this lets a reader that
    *  re-sorts (grouping, filtering) put an arrival back in the order it was written. */
   seq: z.number().int().optional(),
+  /** HOW MANY units the arrival was cut into. A device reads a LENS, never the arrival —
+   *  `/api/inbox` serves `open`, so the units already settled are gone from it — and a client
+   *  counting what it can see is counting what is LEFT. Walking a three-unit ask on the answer
+   *  screen read "1 of 3", then "1 of 2", then no chip at all, each answer having removed the
+   *  only evidence of itself. How big an arrival is, is a fact about the arrival, so the
+   *  server that can still see every row states it. Absent on any row with no `askId`: a
+   *  unit knows WHICH ask it came from and WHERE it sat in it, and how many there were is
+   *  the one part of its own arrival a single row cannot answer. */
+  units: z.number().int().positive().optional(),
   tokenId: z.string().optional(),
   status: NotifyStatusSchema,
   context: ContextSchema,
@@ -512,6 +570,16 @@ var InboxItemSchema = z.object({
    *  while the party called the same dead claim stalled. Absent = no token/no data,
    *  which must never CLAIM stalled. */
   lastSeenAt: z.string().optional(),
+  /** WHEN THE AGENT LAST SAID ANYTHING ABOUT THIS CLAIM — the newest `agent_state` row in
+   *  the `notification_events` ledger (trigger-written since 20260621010000, so every row a
+   *  user can see has one). The age input for `CLAIM_STALE_MS`, and it has to be this rather
+   *  than `createdAt`: a claim is very often picked up long after the row was born — the
+   *  inbox keeps an ANSWERED row visible while the agent works the follow-up, so a question
+   *  asked this morning and claimed a minute ago is eight hours old and one minute into its
+   *  work. Reading the row's birth as the claim's age brands that "No update in 8h" the
+   *  instant the agent picks it up (#997). Absent = pre-trigger row; fall back to
+   *  `createdAt`. */
+  agentStateAt: z.string().datetime().optional(),
   agenda: z.array(AgendaTurnSchema).optional(),
   /** On a replied detail (#397): the next steps the user attached to the answer
    *  ("call back after lunch") — shown so they can see the commitment was captured. */
@@ -583,11 +651,23 @@ var SnoozeRequestSchema = z.object({
   requestId: z.string(),
   until: z.string().datetime()
 });
+var APNS_TOKEN_RE = /^[0-9a-fA-F]{64}$/;
 var PushTokenSchema = z.object({
   voipToken: z.string().min(1).optional(),
   alertToken: z.string().min(1).optional(),
   fcmToken: z.string().min(1).optional(),
   platform: z.enum(["ios", "android"])
+}).superRefine((v, ctx) => {
+  if (v.platform !== "ios") return;
+  for (const field of ["voipToken", "alertToken"]) {
+    const token = v[field];
+    if (token === void 0 || APNS_TOKEN_RE.test(token)) continue;
+    ctx.addIssue({
+      code: z.ZodIssueCode.custom,
+      path: [field],
+      message: `not an APNs device token (want 64 hex chars, got ${token.length})`
+    });
+  }
 });
 var MissedCallSchema = z.enum([
   "retry_10m",
@@ -648,6 +728,15 @@ var UserSettingsSchema = z.object({
   /** Opt-in to real-phone (PSTN) calls when the app can't ring. Optional, not
    *  defaulted — an older client PATCHing the full object must not clobber it. */
   pstnCalls: z.boolean().optional(),
+  /** The user's IANA timezone (e.g. "America/Bogota"), recorded by the app — it is the
+   *  only party that knows it. REMINDERS are why it exists: "remind me at ten" becomes
+   *  an absolute `due_at` only if we know whose ten. Optional and never defaulted, for
+   *  the same reason `voiceMode` is (a stale client PATCHing the whole object must not
+   *  clobber it) and one more: a GUESSED timezone schedules reminders hours off, and
+   *  that failure reads as the reminder rail being unreliable rather than as a missing
+   *  setting. Absent = a spoken time can't be landed, so the reminder rides the next
+   *  call — honest about what we know. */
+  timezone: z.string().min(1).max(64).optional(),
   /** Account E2EE state (text lane): 'off' (default) = today's plaintext; 'on' =
    *  content is sealed end-to-end between the local agent and the phone. Like
    *  voiceMode, OPTIONAL and NOT defaulted so a stale client PATCHing the full
@@ -788,7 +877,8 @@ var HandoffSchema = z.object({
   recap: z.boolean().optional()
 });
 var NoteSourceSchema = z.enum(["app", "call"]);
-var NoteStatusSchema = z.enum(["open", "assigned", "done"]);
+var NoteStatusSchema = z.enum(["open", "assigned", "in_progress", "done"]);
+var NoteRepeatSchema = z.enum(["once", "until_done"]);
 var DecisionSchema = z.object({
   id: z.string(),
   /** The note this decision refines; null = recorded on a bare thread (the
@@ -813,11 +903,29 @@ var NoteSchema = z.object({
   assignee: z.string().nullable(),
   /** The request thread minted at assignment; null until assigned. */
   parentId: z.string().nullable(),
+  /** REMINDERS (reminders-design.md): the NOT-BEFORE this becomes eligible to ride a
+   *  call — never a deadline, and nothing rings when it passes. Null = "the very next
+   *  call", the right reading of "remind me to…" with no time attached. */
+  //  Defaulted, not required: a Note from an API deploy older than the reminders
+  //  migration has none of these, and the defaults ARE what it means — no not-before,
+  //  one ride, never ridden. Parsing must not fail across a rolling deploy.
+  dueAt: z.string().nullable().default(null),
+  repeat: NoteRepeatSchema.default("once"),
+  /** How many calls have already carried it — the fatigue cap counts rides, not days. */
+  rides: z.number().int().default(0),
+  lastRideAt: z.string().nullable().default(null),
   createdAt: z.string()
 });
 var CreateNoteSchema = z.object({
   /** The intent, in the user's own words. Stored verbatim; the broker only titles it. */
-  text: z.string().min(1).max(4e3)
+  text: z.string().min(1).max(4e3),
+  /** Capture it as a REMINDER — a note assigned to the user themselves, which rides
+   *  their next call instead of being handed to an agent. Everything else about the
+   *  note is identical; this is the one parameter that separates the two. */
+  forMe: z.boolean().optional(),
+  /** The not-before, when the user already said one. Absent = the very next call. */
+  dueAt: z.string().datetime().optional(),
+  repeat: NoteRepeatSchema.optional()
 });
 var RecordDecisionSchema = z.object({
   /** An open decision (from /clarify) to answer. */

package/dist/{chunk-LKA7UMRZ.js → chunk-G2WR7FCJ.js}

@@ -1,6 +1,6 @@
 import {
   AGENT_NAME
-} from "./chunk-7SFOTYXZ.js";
+} from "./chunk-X42EUXML.js";
 
 // src/clients.ts
 import { execFile } from "child_process";

package/dist/{chunk-7SFOTYXZ.js → chunk-X42EUXML.js}

@@ -2390,6 +2390,12 @@ var ReceiptEventSchema = z.enum([
   // the recipient opened it
   "answered",
   // the recipient replied
+  // The recipient TURNED THE RING DOWN — CallKit ended it and no answer was ever tapped.
+  // Written by the phone, on the same door that reports the ring itself, so it exists only
+  // when a ring reached a running app and a person did not take it. That is what separates
+  // it from "a ring with no answer", which our own crashes wrote just as readily and which
+  // is why the responsiveness back-off had to be removed (#1144).
+  "declined",
   "escalated",
   // re-reached at a higher level (re-ring / promote)
   "coalesced",
@@ -2398,8 +2404,14 @@ var ReceiptEventSchema = z.enum([
   // deadline passed unanswered
   "woke",
   // the agent was woken for an owed obligation (callback)
-  "gave_up"
+  "gave_up",
   // the budget was spent — stopped re-engaging
+  // The ladder starts over — a silent pickup (the owner's fresh-miss rule, 2026-07-28), a
+  // promote to call, a re-delivery. APPENDED, never a rewind: `ring_step` was a cache of
+  // the escalated-count and a writer rewound it to 0 on every unanswered call (2026-08-24,
+  // nine rings in an hour, `gaveUp` unreachable). A count since the last `restarted` cannot
+  // be rewound by a writer that forgot to advance it.
+  "restarted"
 ]);
 var AttentionSchema = z.object({
   urgency: NotifyLevelSchema,
@@ -2644,6 +2656,14 @@ var IntentSchema = z.object({
    *  about what cannot answer "is the bot looping less this week?". */
   fault: z.enum(["loop", "unanswered", "overridden", "misheard", "slow", "other"]).optional()
 });
+var RideAlongSchema = z.object({
+  /** The note this came from — assign/clarify/close it through /api/notes/:id. */
+  noteId: z.string(),
+  /** What to do, in the owner's own words (the note's headline). Never model-rewritten. */
+  text: z.string(),
+  /** The thread to report back on, when the note was dispatched over the request rail. */
+  parentId: z.string().nullable()
+});
 var AwaitItemSchema = z.discriminatedUnion("type", [
   z.object({
     type: z.literal("reply"),
@@ -2664,7 +2684,13 @@ var AwaitItemSchema = z.discriminatedUnion("type", [
     transcript: z.string().optional(),
     /** Coverage report (#396), when the ask declared `points`: which of them this
      *  answer addressed. Missing points = re-ask or proceed knowingly partial. */
-    covered: z.array(z.string()).optional()
+    covered: z.array(z.string()).optional(),
+    /** Ride-alongs (RideAlongSchema) — pending work for you, attached to the moment you
+     *  became free. Only `reply` and `idle` carry it: those are the two outcomes that
+     *  END a wait. `remind`, `superseded` and `turn` are mid-flight, and handing an
+     *  agent a side-quest while it is still holding the line is how the main thing gets
+     *  dropped. Absent/empty = nothing owed. */
+    also: z.array(RideAlongSchema).optional()
   }),
   z.object({
     type: z.literal("remind"),
@@ -2699,7 +2725,7 @@ var AwaitItemSchema = z.discriminatedUnion("type", [
       acts: z.array(IntentSchema).nullable().optional()
     })
   }),
-  z.object({ type: z.literal("idle") })
+  z.object({ type: z.literal("idle"), also: z.array(RideAlongSchema).optional() })
 ]);
 var CallbackTriggerSchema = z.enum(["on_done", "on_blocked", "scheduled"]);
 var ScheduleCallbackSchema = z.object({
@@ -2730,6 +2756,12 @@ var PendingRepliesSchema = z.object({
   pending: z.array(
     z.object({ parentId: z.string(), notificationId: z.string(), createdAt: z.string() })
   ),
+  /** WHO YOU ARE on this account (field report 2026-08-28): the name and device the user
+   *  sees for this session's identity. From inside a session there was no way to find out —
+   *  `pair` with no arguments can HATCH a fresh identity, so it is not a safe probe — and an
+   *  agent that cannot tell which agent it is cannot tell whether work addressed to
+   *  "Reta" was addressed to it. Absent only for a token with no pairing behind it. */
+  you: z.object({ name: z.string(), device: z.string().nullable(), tokenId: z.string() }).optional(),
   /** User-initiated requests addressed to this agent; act on them and reply via
    *  contact on the same parentId. Keeps reappearing until you call
    *  set_task_state on its notificationId. */
@@ -2741,12 +2773,21 @@ var PendingRepliesSchema = z.object({
       createdAt: z.string(),
       /** The user seeded this request with a past conversation — call get_thread on it
        *  FIRST and treat the transcript as prior context (#57/#251). */
-      contextParentId: z.string().optional()
+      contextParentId: z.string().optional(),
+      /** STRANDED (field report 2026-08-28): this request was addressed to ANOTHER agent on
+       *  the account — the name here — which has not been seen since it landed, so nobody
+       *  came for it. Handed to you because you are the session that is here. Take it like
+       *  any request (set_task_state claims it, reply with contact on its parentId), and say
+       *  whose it was, because the user chose that agent on purpose. */
+      stranded: z.string().optional()
     })
   ),
   /** Callbacks you owe the user that are now DUE (you said you'd follow up when done,
    *  if blocked, or at a time that has passed). Re-surfaced every sweep until you
    *  fulfill one by calling contact on its parentId. */
+  /** Ride-alongs (RideAlongSchema): notes assigned to this agent that no wake could
+   *  reach. Same array the contact/await replies carry — one queue, every carrier. */
+  also: z.array(RideAlongSchema).optional(),
   owedCallbacks: z.array(
     z.object({ parentId: z.string(), trigger: CallbackTriggerSchema, note: z.string() })
   ),
@@ -2782,7 +2823,11 @@ var NotifyResponseSchema = z.object({
   status: NotifyStatusSchema,
   createdAt: z.string().datetime(),
   answer: UserAnswerSchema.optional(),
-  answeredAt: z.string().datetime().optional()
+  answeredAt: z.string().datetime().optional(),
+  /** Ride-alongs for THIS agent — pending work it should pick up when it's done with
+   *  what it came for. Present on any reply, because an unwakeable agent's only
+   *  reliable moment is one it initiated. Absent/empty = nothing owed. */
+  also: z.array(RideAlongSchema).optional()
 });
 var NotifyPlanUnitSchema = z.object({
   notificationId: z.string(),
@@ -2834,6 +2879,9 @@ var UserResponseSchema = z.object({
 });
 var VoiceKeySchema = z.enum(["rachel", "george", "jessica", "brian", "lily"]);
 var AgendaTurnSchema = z.object({
+  /** Twin coverage (#1089): sibling claim ids this asking turn's answer ALSO settles —
+   *  the planner declares duplicates instead of asking them twice. */
+  coveredIds: z.array(z.string()).optional(),
   /** At most three short spoken sentences. Capped because a turn is a breath: a 1031-char
    *  line went out on 2026-07-28 and the caller could not answer it at all. */
   info: z.array(z.string().min(1)).max(3).default([]),
@@ -2867,6 +2915,7 @@ var AgendaTurnSchema = z.object({
    *  on, the claim stays pending; blocking:true on context = hold for a reply. */
   blocking: z.boolean().optional()
 });
+var CLAIM_STALE_MS = 30 * 6e4;
 var InboxItemSchema = z.object({
   id: z.string(),
   /** The conversation thread + connection this item lives on. Present on the replied
@@ -2886,6 +2935,15 @@ var InboxItemSchema = z.object({
    *  (live 2026-08-10, D35). The API already orders by it; this lets a reader that
    *  re-sorts (grouping, filtering) put an arrival back in the order it was written. */
   seq: z.number().int().optional(),
+  /** HOW MANY units the arrival was cut into. A device reads a LENS, never the arrival —
+   *  `/api/inbox` serves `open`, so the units already settled are gone from it — and a client
+   *  counting what it can see is counting what is LEFT. Walking a three-unit ask on the answer
+   *  screen read "1 of 3", then "1 of 2", then no chip at all, each answer having removed the
+   *  only evidence of itself. How big an arrival is, is a fact about the arrival, so the
+   *  server that can still see every row states it. Absent on any row with no `askId`: a
+   *  unit knows WHICH ask it came from and WHERE it sat in it, and how many there were is
+   *  the one part of its own arrival a single row cannot answer. */
+  units: z.number().int().positive().optional(),
   tokenId: z.string().optional(),
   status: NotifyStatusSchema,
   context: ContextSchema,
@@ -2906,6 +2964,16 @@ var InboxItemSchema = z.object({
    *  while the party called the same dead claim stalled. Absent = no token/no data,
    *  which must never CLAIM stalled. */
   lastSeenAt: z.string().optional(),
+  /** WHEN THE AGENT LAST SAID ANYTHING ABOUT THIS CLAIM — the newest `agent_state` row in
+   *  the `notification_events` ledger (trigger-written since 20260621010000, so every row a
+   *  user can see has one). The age input for `CLAIM_STALE_MS`, and it has to be this rather
+   *  than `createdAt`: a claim is very often picked up long after the row was born — the
+   *  inbox keeps an ANSWERED row visible while the agent works the follow-up, so a question
+   *  asked this morning and claimed a minute ago is eight hours old and one minute into its
+   *  work. Reading the row's birth as the claim's age brands that "No update in 8h" the
+   *  instant the agent picks it up (#997). Absent = pre-trigger row; fall back to
+   *  `createdAt`. */
+  agentStateAt: z.string().datetime().optional(),
   agenda: z.array(AgendaTurnSchema).optional(),
   /** On a replied detail (#397): the next steps the user attached to the answer
    *  ("call back after lunch") — shown so they can see the commitment was captured. */
@@ -2977,11 +3045,23 @@ var SnoozeRequestSchema = z.object({
   requestId: z.string(),
   until: z.string().datetime()
 });
+var APNS_TOKEN_RE = /^[0-9a-fA-F]{64}$/;
 var PushTokenSchema = z.object({
   voipToken: z.string().min(1).optional(),
   alertToken: z.string().min(1).optional(),
   fcmToken: z.string().min(1).optional(),
   platform: z.enum(["ios", "android"])
+}).superRefine((v, ctx) => {
+  if (v.platform !== "ios") return;
+  for (const field of ["voipToken", "alertToken"]) {
+    const token = v[field];
+    if (token === void 0 || APNS_TOKEN_RE.test(token)) continue;
+    ctx.addIssue({
+      code: z.ZodIssueCode.custom,
+      path: [field],
+      message: `not an APNs device token (want 64 hex chars, got ${token.length})`
+    });
+  }
 });
 var MissedCallSchema = z.enum([
   "retry_10m",
@@ -3032,6 +3112,15 @@ var UserSettingsSchema = z.object({
   /** Opt-in to real-phone (PSTN) calls when the app can't ring. Optional, not
    *  defaulted — an older client PATCHing the full object must not clobber it. */
   pstnCalls: z.boolean().optional(),
+  /** The user's IANA timezone (e.g. "America/Bogota"), recorded by the app — it is the
+   *  only party that knows it. REMINDERS are why it exists: "remind me at ten" becomes
+   *  an absolute `due_at` only if we know whose ten. Optional and never defaulted, for
+   *  the same reason `voiceMode` is (a stale client PATCHing the whole object must not
+   *  clobber it) and one more: a GUESSED timezone schedules reminders hours off, and
+   *  that failure reads as the reminder rail being unreliable rather than as a missing
+   *  setting. Absent = a spoken time can't be landed, so the reminder rides the next
+   *  call — honest about what we know. */
+  timezone: z.string().min(1).max(64).optional(),
   /** Account E2EE state (text lane): 'off' (default) = today's plaintext; 'on' =
    *  content is sealed end-to-end between the local agent and the phone. Like
    *  voiceMode, OPTIONAL and NOT defaulted so a stale client PATCHing the full
@@ -3172,7 +3261,8 @@ var HandoffSchema = z.object({
   recap: z.boolean().optional()
 });
 var NoteSourceSchema = z.enum(["app", "call"]);
-var NoteStatusSchema = z.enum(["open", "assigned", "done"]);
+var NoteStatusSchema = z.enum(["open", "assigned", "in_progress", "done"]);
+var NoteRepeatSchema = z.enum(["once", "until_done"]);
 var DecisionSchema = z.object({
   id: z.string(),
   /** The note this decision refines; null = recorded on a bare thread (the
@@ -3197,11 +3287,29 @@ var NoteSchema = z.object({
   assignee: z.string().nullable(),
   /** The request thread minted at assignment; null until assigned. */
   parentId: z.string().nullable(),
+  /** REMINDERS (reminders-design.md): the NOT-BEFORE this becomes eligible to ride a
+   *  call — never a deadline, and nothing rings when it passes. Null = "the very next
+   *  call", the right reading of "remind me to…" with no time attached. */
+  //  Defaulted, not required: a Note from an API deploy older than the reminders
+  //  migration has none of these, and the defaults ARE what it means — no not-before,
+  //  one ride, never ridden. Parsing must not fail across a rolling deploy.
+  dueAt: z.string().nullable().default(null),
+  repeat: NoteRepeatSchema.default("once"),
+  /** How many calls have already carried it — the fatigue cap counts rides, not days. */
+  rides: z.number().int().default(0),
+  lastRideAt: z.string().nullable().default(null),
   createdAt: z.string()
 });
 var CreateNoteSchema = z.object({
   /** The intent, in the user's own words. Stored verbatim; the broker only titles it. */
-  text: z.string().min(1).max(4e3)
+  text: z.string().min(1).max(4e3),
+  /** Capture it as a REMINDER — a note assigned to the user themselves, which rides
+   *  their next call instead of being handed to an agent. Everything else about the
+   *  note is identical; this is the one parameter that separates the two. */
+  forMe: z.boolean().optional(),
+  /** The not-before, when the user already said one. Absent = the very next call. */
+  dueAt: z.string().datetime().optional(),
+  repeat: NoteRepeatSchema.optional()
 });
 var RecordDecisionSchema = z.object({
   /** An open decision (from /clarify) to answer. */

package/dist/enable.js

@@ -2,8 +2,8 @@
 import {
   PAIGY_TOOL_IDS,
   enablePaigyTools
-} from "./chunk-LKA7UMRZ.js";
-import "./chunk-7SFOTYXZ.js";
+} from "./chunk-G2WR7FCJ.js";
+import "./chunk-X42EUXML.js";
 
 // src/enable.ts
 function main() {

package/dist/index.js

@@ -2,14 +2,14 @@
 import {
   HandoffSchema,
   MISSED_CALL_PLAN
-} from "./chunk-XSHUDPJ3.js";
+} from "./chunk-45CIZLCJ.js";
 import {
   ENABLE_COMMAND,
   PAIGY_TOOL_IDS,
   autoConfigureClients,
   claudeInstallHint,
   paigyToolsAllowlisted
-} from "./chunk-LKA7UMRZ.js";
+} from "./chunk-G2WR7FCJ.js";
 import {
   clearSurface,
   writeSurface
@@ -51,7 +51,7 @@ import {
   startE2ee,
   submitNotification,
   whoAmI
-} from "./chunk-7SFOTYXZ.js";
+} from "./chunk-X42EUXML.js";
 
 // src/index.ts
 import { Server } from "@modelcontextprotocol/sdk/server/index.js";
@@ -140,7 +140,7 @@ var CONTACT_SCHEMA = {
 };
 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. 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.";
+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) {
@@ -468,7 +468,7 @@ server.setRequestHandler(ListToolsRequestSchema, async () => {
     },
     {
       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. 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. 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.",
+      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({}))
     },
     {

package/dist/listen.js

@@ -2,11 +2,11 @@
 import {
   WAKE_EVENT,
   wakeChannel
-} from "./chunk-XSHUDPJ3.js";
+} from "./chunk-45CIZLCJ.js";
 import {
   checkReplies,
   registerDelivery
-} from "./chunk-7SFOTYXZ.js";
+} from "./chunk-X42EUXML.js";
 
 // src/listen.ts
 import { createClient } from "@supabase/supabase-js";

package/dist/onboard.js

@@ -3,7 +3,7 @@ import {
   autoConfigureClients,
   claudeInstallHint,
   openBrowser
-} from "./chunk-LKA7UMRZ.js";
+} from "./chunk-G2WR7FCJ.js";
 import {
   AGENT_NAME,
   TOKEN_PATH,
@@ -17,7 +17,7 @@ import {
   setIdentity,
   sleep,
   whoAmI
-} from "./chunk-7SFOTYXZ.js";
+} from "./chunk-X42EUXML.js";
 
 // src/onboard.ts
 async function main() {

package/dist/statusline.js

@@ -6,7 +6,7 @@ import {
   BACKEND_URL,
   reach,
   readToken
-} from "./chunk-7SFOTYXZ.js";
+} from "./chunk-X42EUXML.js";
 
 // src/statusline.ts
 import { mkdirSync, readFileSync, realpathSync, writeFileSync } from "fs";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@paigy/mcp",
-  "version": "0.32.0",
+  "version": "0.34.0",
   "description": "Paigy MCP server — the AI agent harness that calls you. Lets an agent notify a user and await their reply.",
   "license": "MIT",
   "type": "module",
@@ -23,13 +23,6 @@
     "url": "git+https://github.com/mauurda/paigy.git",
     "directory": "apps/mcp"
   },
-  "scripts": {
-    "build": "tsup",
-    "dev": "tsup --watch",
-    "typecheck": "tsc --noEmit",
-    "test": "vitest run",
-    "prepublishOnly": "pnpm --filter @paigy/schema build && pnpm --filter @paigy/crypto build && pnpm --filter @paigy/sdk build && pnpm build"
-  },
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.0.4",
     "@supabase/supabase-js": "^2.47.10",
@@ -39,13 +32,19 @@
     "zod-to-json-schema": "^3.24.1"
   },
   "devDependencies": {
-    "@paigy/crypto": "workspace:*",
-    "@paigy/schema": "workspace:*",
-    "@paigy/sdk": "workspace:*",
     "@types/node": "^22.0.0",
     "@types/qrcode-generator": "^1.0.6",
     "tsup": "^8.3.5",
     "typescript": "^5.7.2",
-    "vitest": "^2.1.8"
+    "vitest": "^2.1.8",
+    "@paigy/crypto": "0.0.0",
+    "@paigy/schema": "0.0.0",
+    "@paigy/sdk": "0.2.0"
+  },
+  "scripts": {
+    "build": "tsup",
+    "dev": "tsup --watch",
+    "typecheck": "tsc --noEmit",
+    "test": "vitest run"
   }
-}
+}