@paigy/harness 0.3.4 → 0.3.5

package/dist/cli.js

@@ -22743,6 +22743,7 @@ var require_undici = __commonJS({
 // ../../packages/sdk/dist/index.js
 import { createRequire as __sdkCreateRequire } from "module";
 import { createHash, randomUUID } from "crypto";
+import { randomUUID as randomUUID2 } from "crypto";
 import { closeSync, existsSync as existsSync2, mkdirSync, openSync, readFileSync, rmSync, statSync, writeFileSync } from "fs";
 import { homedir as homedir2 } from "os";
 import { join as join2 } from "path";
@@ -23656,6 +23657,9 @@ function contactSchemaFrom(fields) {
     workId: fields.workId.describe(
       "The durable Work this contact advances. Pass the workId from check_replies or a prior reply when asking for a decision that blocks that work."
     ),
+    goalId: fields.goalId.describe(
+      "The target Goal this contact advances. Use goalId for the Goal model; do not combine it with workId."
+    ),
     // THE WAIT, CONTINUED (owner, 2026-09-06: "await should have been folded into contact").
     // A contact that rang holds its first window itself; the host caps one tool call at
     // ~60 s, so keeping the line is another contact — with ONLY this field. Nothing is sent.
@@ -24109,6 +24113,32 @@ async function sealForE2ee(req, token, deps = {}) {
 }
 async function submitNotification(req, opts = {}) {
   const token = authToken(opts.token) ?? "";
+  if (req.goalId) {
+    if (req.envelope) throw new Error("Goal-scoped contact does not support E2EE envelopes yet");
+    const shaped = deriveAsk(req);
+    if (!shaped.context || !shaped.select) throw new Error("Goal-scoped contact requires a shaped request or ask");
+    if (shaped.channel === "call" || shaped.urgency === "call") {
+      throw new Error("Goal-scoped call contact is not available yet; use a message contact");
+    }
+    if (shaped.urgency && shaped.urgency !== "inbox") throw new Error("Goal-scoped contact currently supports inbox delivery only");
+    if (shaped.points?.length) throw new Error("Goal-scoped multi-part contact is not available yet; send one decision at a time");
+    const content = [shaped.context.title, ...shaped.context.description].filter(Boolean).join("\n\n");
+    const res2 = ensureAuthed(await reach(`${BACKEND_URL}/api/goals/${encodeURIComponent(req.goalId)}/contact`, {
+      method: "POST",
+      headers: { "content-type": "application/json", authorization: `Bearer ${token}`, "x-paigy-model": "goal-entry-v1" },
+      body: JSON.stringify({
+        operationId: randomUUID2(),
+        threadId: shaped.parentId ?? null,
+        content,
+        select: shaped.select,
+        options: shaped.options ?? [],
+        blocking: shaped.blocking,
+        channel: "message"
+      })
+    }));
+    if (!res2.ok) throw new Error(`goal contact failed: ${res2.status} ${await res2.text()}`);
+    return await res2.json();
+  }
   const body = await sealForE2ee(req, token);
   const res = ensureAuthed(await reach(`${BACKEND_URL}/api/notify`, {
     method: "POST",
@@ -24341,7 +24371,7 @@ async function patchState(path, state, opts, operation) {
 function setTaskState(notificationId, state, opts = {}) {
   return patchState(`/api/notify/${encodeURIComponent(notificationId)}/state`, state, opts, "set_task_state");
 }
-var require2, __create2, __defProp2, __getOwnPropDesc2, __getOwnPropNames2, __getProtoOf2, __hasOwnProp2, __require2, __commonJS2, __copyProps2, __toESM2, require_nacl_fast, BACKEND_URL, NETWORK_MSG, PROXY_ENV, agent, INSTANCE_ID, WORKSPACE_ID, envSession, SESSION_ID, ignoreOverride, defaultOptions, getDefaultOptions, getRefs, getRelativePath, parseCatchDef, integerDateParser, isJsonSchema7AllOfType, emojiRegex2, zodPatterns, ALPHA_NUMERIC, primitiveMappings, asAnyOf, parseOptionalDef, parsePipelineDef, parseReadonlyDef, selectParser, get$ref, addMeta, zodToJsonSchema, OPTIONS_MIN, OPTIONS_MAX, MISSED_CALL_PLAN, CreateGoalSchema, UpdateGoalSchema, fmtMin, STANDARD_MEANS, CONTACT_DESCRIPTION, ContextSchema, ParticipantSchema, TransformSchema, OptionSchema, VisualSchema, NotifyLevelSchema, SelectShapeSchema, ReceiptEventSchema, AttentionSchema, NotifyRequestFields, NotifyRequestSchema, NotifyStatusSchema, AgentStateSchema, SetTaskStateSchema, SetWorkStateSchema, TurnSchema, UserAnswerSchema, IntentSchema, RideAlongSchema, AwaitItemSchema, CallbackTriggerSchema, ScheduleCallbackSchema, PendingRepliesSchema, NotifyResponseSchema, NotifyPlanUnitSchema, NotifyPlanSchema, UserResponseSchema, VoiceKeySchema, AgendaTurnSchema, CLAIM_STALE_MS, InboxItemSchema, SnoozeRequestSchema, APNS_TOKEN_RE, PushTokenSchema, MissedCallSchema, BrokerTuningSchema, UserSettingsSchema, HistoryItemSchema, ACTIVITY_LINES, ACTIVITY_LINE_MAX, AgentActivitySchema, ConnectionSummarySchema, LedgerItemSchema, AgentLedgerSchema, ReassignResultSchema, MoveRingSchema, MoveSchema, CreateRequestSchema, HandoffSchema, NoteSourceSchema, NoteStatusSchema, NoteRepeatSchema, DecisionSchema, NoteSchema, CreateNoteSchema, RecordDecisionSchema, AssignNoteSchema, TriageVerdictSchema, TriageItemSchema, TriageAssignmentSchema, TriageStatusSchema, SubmitTriageSchema, TriageProposalSchema, AcceptTriageSchema, AcceptTriageResultSchema, DeliveryModeSchema, RegisterDeliverySchema, OAuthStartSchema, DeliveryConfigSchema, StatusSchema, EnvelopeRecipientSchema, EnvelopeHeaderSchema, EnvelopeSchema, SealedAnswerSchema, DeviceCredentialSchema, DeviceRosterSchema, WakeNudgeSchema, PairingStatusSchema, PairingRevealSchema, DeviceCodeRequestSchema, DeviceCodeSchema, DeviceInfoSchema, DeviceTokenRequestSchema, DeviceTokenSchema, DeviceCommitRequestSchema, DevicePeerCommitSchema, SupportRequestSchema, NotificationFeedbackKindSchema, NotificationFeedbackSchema, FeedbackResolutionSchema, FeedbackOutcomeSchema, CONTACT_SCHEMA, import_tweetnacl, import_tweetnacl2, import_tweetnacl3, import_tweetnacl4, import_tweetnacl5, B64, ok, ENVELOPE_VERSION, ENVELOPE_ALG, AGENT_NAME, TOKEN_PATH, KEY_PATH, sleep, UnpairedError, tokenOverride, authToken, sleep3, ReplyLeaseExpiredError, ReplyAckError;
+var require2, __create2, __defProp2, __getOwnPropDesc2, __getOwnPropNames2, __getProtoOf2, __hasOwnProp2, __require2, __commonJS2, __copyProps2, __toESM2, require_nacl_fast, BACKEND_URL, NETWORK_MSG, PROXY_ENV, agent, INSTANCE_ID, WORKSPACE_ID, envSession, SESSION_ID, ignoreOverride, defaultOptions, getDefaultOptions, getRefs, getRelativePath, parseCatchDef, integerDateParser, isJsonSchema7AllOfType, emojiRegex2, zodPatterns, ALPHA_NUMERIC, primitiveMappings, asAnyOf, parseOptionalDef, parsePipelineDef, parseReadonlyDef, selectParser, get$ref, addMeta, zodToJsonSchema, OPTIONS_MIN, OPTIONS_MAX, MISSED_CALL_PLAN, CreateGoalSchema, UpdateGoalSchema, UpdateGoalToolSchema, ClaimGoalSchema, fmtMin, STANDARD_MEANS, CONTACT_DESCRIPTION, ContextSchema, ParticipantSchema, TransformSchema, OptionSchema, VisualSchema, NotifyLevelSchema, SelectShapeSchema, ReceiptEventSchema, AttentionSchema, NotifyRequestFields, NotifyRequestSchema, NotifyStatusSchema, AgentStateSchema, SetTaskStateSchema, SetWorkStateSchema, TurnSchema, UserAnswerSchema, IntentSchema, RideAlongSchema, AwaitItemSchema, CallbackTriggerSchema, ScheduleCallbackSchema, PendingRepliesSchema, NotifyResponseSchema, NotifyPlanUnitSchema, NotifyPlanSchema, UserResponseSchema, VoiceKeySchema, AgendaTurnSchema, CLAIM_STALE_MS, InboxItemSchema, SnoozeRequestSchema, APNS_TOKEN_RE, PushTokenSchema, MissedCallSchema, BrokerTuningSchema, UserSettingsSchema, HistoryItemSchema, ACTIVITY_LINES, ACTIVITY_LINE_MAX, AgentActivitySchema, ConnectionSummarySchema, LedgerItemSchema, AgentLedgerSchema, ReassignResultSchema, MoveRingSchema, MoveSchema, CreateRequestSchema, HandoffSchema, NoteSourceSchema, NoteStatusSchema, NoteRepeatSchema, DecisionSchema, NoteSchema, CreateNoteSchema, RecordDecisionSchema, AssignNoteSchema, TriageVerdictSchema, TriageItemSchema, TriageAssignmentSchema, TriageStatusSchema, SubmitTriageSchema, TriageProposalSchema, AcceptTriageSchema, AcceptTriageResultSchema, DeliveryModeSchema, RegisterDeliverySchema, OAuthStartSchema, DeliveryConfigSchema, StatusSchema, EnvelopeRecipientSchema, EnvelopeHeaderSchema, EnvelopeSchema, SealedAnswerSchema, DeviceCredentialSchema, DeviceRosterSchema, WakeNudgeSchema, PairingStatusSchema, PairingRevealSchema, DeviceCodeRequestSchema, DeviceCodeSchema, DeviceInfoSchema, DeviceTokenRequestSchema, DeviceTokenSchema, DeviceCommitRequestSchema, DevicePeerCommitSchema, SupportRequestSchema, NotificationFeedbackKindSchema, NotificationFeedbackSchema, FeedbackResolutionSchema, FeedbackOutcomeSchema, CONTACT_SCHEMA, import_tweetnacl, import_tweetnacl2, import_tweetnacl3, import_tweetnacl4, import_tweetnacl5, B64, ok, ENVELOPE_VERSION, ENVELOPE_ALG, AGENT_NAME, TOKEN_PATH, KEY_PATH, sleep, UnpairedError, tokenOverride, authToken, sleep3, ReplyLeaseExpiredError, ReplyAckError;
 var init_dist = __esm({
   "../../packages/sdk/dist/index.js"() {
     "use strict";
@@ -27003,12 +27033,19 @@ var init_dist = __esm({
       revision: external_exports.number().int().positive(),
       changes: external_exports.object({
         outcome: external_exports.string().trim().min(1).max(1e4).optional(),
-        state: external_exports.enum(["active", "waiting", "done", "cancelled"]).optional(),
+        ownerParticipant: external_exports.string().trim().min(1).optional(),
+        parentGoalId: external_exports.string().uuid().nullable().optional(),
+        dependencies: external_exports.array(external_exports.object({ goalId: external_exports.string().uuid(), gate: external_exports.enum(["start", "finish"]) }).strict()).optional(),
+        children: external_exports.array(external_exports.object({ outcome: external_exports.string().trim().min(1).max(1e4), ownerParticipant: external_exports.string().trim().min(1), gate: external_exports.enum(["start", "finish"]).optional() }).strict()).optional(),
+        state: external_exports.enum(["active", "done", "cancelled"]).optional(),
         progress: external_exports.string().trim().min(1).max(1e4).optional(),
         reviewed: external_exports.literal(true).optional()
-      }).refine((v) => Object.keys(v).length > 0),
-      reason: external_exports.string().trim().min(1).max(2e3)
-    });
+      }).strict().refine((v) => Object.keys(v).length > 0),
+      reason: external_exports.string().trim().min(1).max(2e3),
+      operationId: external_exports.string().uuid().optional()
+    }).strict();
+    UpdateGoalToolSchema = UpdateGoalSchema.extend({ goalId: external_exports.string().uuid() }).strict();
+    ClaimGoalSchema = external_exports.object({ goalId: external_exports.string().uuid().optional() }).strict();
     fmtMin = (m) => m >= 60 ? `${m / 60} hr` : `${m} min`;
     STANDARD_MEANS = (() => {
       const plan = MISSED_CALL_PLAN.backoff_standard;
@@ -27017,7 +27054,7 @@ var init_dist = __esm({
       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`;
     })();
-    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, workId?, decisionId?, wait? }. WHEN IT RANG, contact holds the first ~45 s window ITSELF and \`wait\` carries the outcome: { type:'reply', answer } to act on; { type:'partial', inFlight:true, turn } \u2014 what the user is saying to each turn, provisional: use it to PREPARE (fetch, draft, warm the build), never to act irreversibly, they can still revise it until the final reply (partial = intelligence, settled = authorization; if a partial's acts carry a question aimed at you and you know the answer, contact on the SAME parentId right away \u2014 they hear it on the same call); { type:'remind', remindInSeconds } \u2014 schedule a wake-up; { type:'idle' } \u2014 still waiting. TO KEEP WAITING, call contact again with ONLY { wait: notificationId } \u2014 no ask, nothing new is sent; it holds the next scoped ~45 s window (under the 60 s host cap, so it always returns) and never returns another notification's reply. Keep doing that until the reply \u2014 THAT one is the decision \u2014 so the user steps away and comes back to find you already continued; stop only to do other work and check back, or after an unreasonably long stretch worth telling them about. A message delivery has NO \`wait\`: never poll for it \u2014 the reply arrives through check_replies or your wake. Pass 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. BLOCKED ON A DECISION for existing work? Pass that work's \`workId\`; the reply returns the same workId plus a decisionId, so the answer resumes the right outcome. 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 ${OPTIONS_MIN}-${OPTIONS_MAX} 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. READING A CALL'S REPLY: it 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 question that blocks me'), 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.`;
+    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, workId?, goalId?, entryId?, decisionId?, wait? }. WHEN IT RANG, contact holds the first ~45 s window ITSELF and \`wait\` carries the outcome: { type:'reply', answer } to act on; { type:'partial', inFlight:true, turn } \u2014 what the user is saying to each turn, provisional: use it to PREPARE (fetch, draft, warm the build), never to act irreversibly, they can still revise it until the final reply (partial = intelligence, settled = authorization; if a partial's acts carry a question aimed at you and you know the answer, contact on the SAME parentId right away \u2014 they hear it on the same call); { type:'remind', remindInSeconds } \u2014 schedule a wake-up; { type:'idle' } \u2014 still waiting. TO KEEP WAITING, call contact again with ONLY { wait: notificationId } \u2014 no ask, nothing new is sent; it holds the next scoped ~45 s window (under the 60 s host cap, so it always returns) and never returns another notification's reply. Keep doing that until the reply \u2014 THAT one is the decision \u2014 so the user steps away and comes back to find you already continued; stop only to do other work and check back, or after an unreasonably long stretch worth telling them about. A message delivery has NO \`wait\`: never poll for it \u2014 the reply arrives through check_replies or your wake. Pass parentId to a later contact to continue the conversation. A Goal-targeted contact also returns goalId and entryId for the durable Goal entry. 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. BLOCKED ON A DECISION for existing work? Pass that work's \`workId\`; the reply returns the same workId plus a decisionId, so the answer resumes the right outcome. 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 ${OPTIONS_MIN}-${OPTIONS_MAX} 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. READING A CALL'S REPLY: it 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 question that blocks me'), 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.`;
     ContextSchema = external_exports.object({
       title: external_exports.string().min(1).describe("One-line headline of what you need (required, non-empty)."),
       description: external_exports.array(external_exports.string().min(1)).describe(
@@ -27130,6 +27167,9 @@ var init_dist = __esm({
       /** The durable outcome this contact advances. Optional during the notification-to-Work
        *  migration; when present, a blocking ask creates a DecisionNeed for this Work. */
       workId: external_exports.string().uuid().optional(),
+      /** Target Goal scope. During staged migration this is accepted by the shared contract but
+       * target delivery activation remains model-gated; workId and goalId are mutually exclusive. */
+      goalId: external_exports.string().uuid().optional(),
       urgency: NotifyLevelSchema.default("inbox").describe(
         "The level you're requesting \u2014 the user's account permissions + session mode can lower it. 'inbox' (default) = sits silently in the inbox for the user to get to. 'push' = a quiet passive push (lands in Notification Center, no sound) \u2014 a gentle heads-up. 'banner' = a time-sensitive banner/lock-screen push with sound (a 'paige') they tap to open \u2014 use when you need them soon-ish but it's not worth ringing them. 'call' = rings the user's phone now (a CallKit voice call) \u2014 use only when you genuinely need them in the moment (blocked and waiting, time-sensitive). context.title is what they see on the banner/ring, so make it specific."
       ),
@@ -27207,6 +27247,7 @@ var init_dist = __esm({
       )
     });
     NotifyRequestSchema = NotifyRequestFields.superRefine((r, ctx) => {
+      if (r.workId && r.goalId) ctx.addIssue({ code: external_exports.ZodIssueCode.custom, path: ["goalId"], message: "pass goalId or workId, not both" });
       const sealed = !!r.envelope;
       if (sealed) {
         if (!r.envelope?.context)
@@ -28277,7 +28318,8 @@ var init_dist = __esm({
       options: NotifyRequestFields.shape.options,
       channel: NotifyRequestFields.shape.channel,
       parentId: NotifyRequestFields.shape.parentId,
-      workId: NotifyRequestFields.shape.workId
+      workId: NotifyRequestFields.shape.workId,
+      goalId: NotifyRequestFields.shape.goalId
     });
     import_tweetnacl = __toESM2(require_nacl_fast(), 1);
     import_tweetnacl2 = __toESM2(require_nacl_fast(), 1);
@@ -34895,12 +34937,19 @@ var UpdateGoalSchema2 = external_exports.object({
   revision: external_exports.number().int().positive(),
   changes: external_exports.object({
     outcome: external_exports.string().trim().min(1).max(1e4).optional(),
-    state: external_exports.enum(["active", "waiting", "done", "cancelled"]).optional(),
+    ownerParticipant: external_exports.string().trim().min(1).optional(),
+    parentGoalId: external_exports.string().uuid().nullable().optional(),
+    dependencies: external_exports.array(external_exports.object({ goalId: external_exports.string().uuid(), gate: external_exports.enum(["start", "finish"]) }).strict()).optional(),
+    children: external_exports.array(external_exports.object({ outcome: external_exports.string().trim().min(1).max(1e4), ownerParticipant: external_exports.string().trim().min(1), gate: external_exports.enum(["start", "finish"]).optional() }).strict()).optional(),
+    state: external_exports.enum(["active", "done", "cancelled"]).optional(),
     progress: external_exports.string().trim().min(1).max(1e4).optional(),
     reviewed: external_exports.literal(true).optional()
-  }).refine((v) => Object.keys(v).length > 0),
-  reason: external_exports.string().trim().min(1).max(2e3)
-});
+  }).strict().refine((v) => Object.keys(v).length > 0),
+  reason: external_exports.string().trim().min(1).max(2e3),
+  operationId: external_exports.string().uuid().optional()
+}).strict();
+var UpdateGoalToolSchema2 = UpdateGoalSchema2.extend({ goalId: external_exports.string().uuid() }).strict();
+var ClaimGoalSchema2 = external_exports.object({ goalId: external_exports.string().uuid().optional() }).strict();
 var fmtMin2 = (m) => m >= 60 ? `${m / 60} hr` : `${m} min`;
 var STANDARD_MEANS2 = (() => {
   const plan = MISSED_CALL_PLAN2.backoff_standard;
@@ -34929,6 +34978,9 @@ function contactSchemaFrom2(fields) {
     workId: fields.workId.describe(
       "The durable Work this contact advances. Pass the workId from check_replies or a prior reply when asking for a decision that blocks that work."
     ),
+    goalId: fields.goalId.describe(
+      "The target Goal this contact advances. Use goalId for the Goal model; do not combine it with workId."
+    ),
     // THE WAIT, CONTINUED (owner, 2026-09-06: "await should have been folded into contact").
     // A contact that rang holds its first window itself; the host caps one tool call at
     // ~60 s, so keeping the line is another contact — with ONLY this field. Nothing is sent.
@@ -34941,7 +34993,7 @@ function contactSchemaFrom2(fields) {
   out.anyOf = [{ required: ["ask"] }, { required: ["wait"] }];
   return out;
 }
-var CONTACT_DESCRIPTION2 = `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, workId?, decisionId?, wait? }. WHEN IT RANG, contact holds the first ~45 s window ITSELF and \`wait\` carries the outcome: { type:'reply', answer } to act on; { type:'partial', inFlight:true, turn } \u2014 what the user is saying to each turn, provisional: use it to PREPARE (fetch, draft, warm the build), never to act irreversibly, they can still revise it until the final reply (partial = intelligence, settled = authorization; if a partial's acts carry a question aimed at you and you know the answer, contact on the SAME parentId right away \u2014 they hear it on the same call); { type:'remind', remindInSeconds } \u2014 schedule a wake-up; { type:'idle' } \u2014 still waiting. TO KEEP WAITING, call contact again with ONLY { wait: notificationId } \u2014 no ask, nothing new is sent; it holds the next scoped ~45 s window (under the 60 s host cap, so it always returns) and never returns another notification's reply. Keep doing that until the reply \u2014 THAT one is the decision \u2014 so the user steps away and comes back to find you already continued; stop only to do other work and check back, or after an unreasonably long stretch worth telling them about. A message delivery has NO \`wait\`: never poll for it \u2014 the reply arrives through check_replies or your wake. Pass 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_MEANS2}"), 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. BLOCKED ON A DECISION for existing work? Pass that work's \`workId\`; the reply returns the same workId plus a decisionId, so the answer resumes the right outcome. 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 ${OPTIONS_MIN2}-${OPTIONS_MAX2} 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. READING A CALL'S REPLY: it 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 question that blocks me'), 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.`;
+var CONTACT_DESCRIPTION2 = `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, workId?, goalId?, entryId?, decisionId?, wait? }. WHEN IT RANG, contact holds the first ~45 s window ITSELF and \`wait\` carries the outcome: { type:'reply', answer } to act on; { type:'partial', inFlight:true, turn } \u2014 what the user is saying to each turn, provisional: use it to PREPARE (fetch, draft, warm the build), never to act irreversibly, they can still revise it until the final reply (partial = intelligence, settled = authorization; if a partial's acts carry a question aimed at you and you know the answer, contact on the SAME parentId right away \u2014 they hear it on the same call); { type:'remind', remindInSeconds } \u2014 schedule a wake-up; { type:'idle' } \u2014 still waiting. TO KEEP WAITING, call contact again with ONLY { wait: notificationId } \u2014 no ask, nothing new is sent; it holds the next scoped ~45 s window (under the 60 s host cap, so it always returns) and never returns another notification's reply. Keep doing that until the reply \u2014 THAT one is the decision \u2014 so the user steps away and comes back to find you already continued; stop only to do other work and check back, or after an unreasonably long stretch worth telling them about. A message delivery has NO \`wait\`: never poll for it \u2014 the reply arrives through check_replies or your wake. Pass parentId to a later contact to continue the conversation. A Goal-targeted contact also returns goalId and entryId for the durable Goal entry. 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_MEANS2}"), 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. BLOCKED ON A DECISION for existing work? Pass that work's \`workId\`; the reply returns the same workId plus a decisionId, so the answer resumes the right outcome. 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 ${OPTIONS_MIN2}-${OPTIONS_MAX2} 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. READING A CALL'S REPLY: it 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 question that blocks me'), 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.`;
 var ContextSchema2 = external_exports.object({
   title: external_exports.string().min(1).describe("One-line headline of what you need (required, non-empty)."),
   description: external_exports.array(external_exports.string().min(1)).describe(
@@ -35054,6 +35106,9 @@ var NotifyRequestFields2 = external_exports.object({
   /** The durable outcome this contact advances. Optional during the notification-to-Work
    *  migration; when present, a blocking ask creates a DecisionNeed for this Work. */
   workId: external_exports.string().uuid().optional(),
+  /** Target Goal scope. During staged migration this is accepted by the shared contract but
+   * target delivery activation remains model-gated; workId and goalId are mutually exclusive. */
+  goalId: external_exports.string().uuid().optional(),
   urgency: NotifyLevelSchema2.default("inbox").describe(
     "The level you're requesting \u2014 the user's account permissions + session mode can lower it. 'inbox' (default) = sits silently in the inbox for the user to get to. 'push' = a quiet passive push (lands in Notification Center, no sound) \u2014 a gentle heads-up. 'banner' = a time-sensitive banner/lock-screen push with sound (a 'paige') they tap to open \u2014 use when you need them soon-ish but it's not worth ringing them. 'call' = rings the user's phone now (a CallKit voice call) \u2014 use only when you genuinely need them in the moment (blocked and waiting, time-sensitive). context.title is what they see on the banner/ring, so make it specific."
   ),
@@ -35131,6 +35186,7 @@ var NotifyRequestFields2 = external_exports.object({
   )
 });
 var NotifyRequestSchema2 = NotifyRequestFields2.superRefine((r, ctx) => {
+  if (r.workId && r.goalId) ctx.addIssue({ code: external_exports.ZodIssueCode.custom, path: ["goalId"], message: "pass goalId or workId, not both" });
   const sealed = !!r.envelope;
   if (sealed) {
     if (!r.envelope?.context)
@@ -36218,7 +36274,8 @@ var CONTACT_SCHEMA2 = contactSchemaFrom2({
   options: NotifyRequestFields2.shape.options,
   channel: NotifyRequestFields2.shape.channel,
   parentId: NotifyRequestFields2.shape.parentId,
-  workId: NotifyRequestFields2.shape.workId
+  workId: NotifyRequestFields2.shape.workId,
+  goalId: NotifyRequestFields2.shape.goalId
 });
 
 // src/paigy/conversation.ts
@@ -36965,10 +37022,14 @@ var claimedRun = (sessionId2) => {
 async function slotHasWaitingWork(token) {
   return (await pendingSummary({ token })).unacknowledged > 0;
 }
-function wakeAction(live, seenAt, now) {
-  if (!live) return "spawn";
-  if (seenAt === void 0) return "skip";
-  return now - seenAt >= IDLE_WAKE_MS ? "prompt" : "skip";
+var PRESENCE_FRESH_MS = 3 * 6e4;
+function wakeAction(live, seenAt, now, serverSeenAt) {
+  if (live) {
+    if (seenAt === void 0) return "skip";
+    return now - seenAt >= IDLE_WAKE_MS ? "prompt" : "skip";
+  }
+  if (serverSeenAt !== void 0 && now - serverSeenAt < PRESENCE_FRESH_MS) return "skip";
+  return "spawn";
 }
 function startHost(opts) {
   const runs = /* @__PURE__ */ new Map();
@@ -37028,12 +37089,21 @@ function startHost(opts) {
   const SLOT_HARNESS = { "mcp-agent": "claude", codex: "codex", antigravity: "agy" };
   const wakePrompt = (fresh) => "You were woken because Paigy work is waiting for you. " + (fresh ? "This is a fresh session with your existing identity, so you may already have work in flight that you can't remember. " : "You have been running, so some of this may already be yours \u2014 but not what arrived while you were idle. ") + "Call check_replies FIRST, then get_thread on each conversation it returns and read it before you touch anything: it holds what you were doing, where (a repo or worktree may not be this folder), and what the owner already decided. Then handle what's waiting and follow your paigy instructions to stay in the loop. Speak to the owner at exactly TWO moments: when you are BLOCKED on a decision only they can make (contact with waiting:'hard', the decision as the ask, options if you have real ones), and when you are DONE (one short report: what shipped, how you verified it, anything you flagged). Progress is never a contact \u2014 call set_task_state('in_progress') when you pick work up and the app shows you working; narrate to the terminal, not to the human.";
   async function sweepSlots() {
+    const presence = /* @__PURE__ */ new Map();
+    try {
+      for (const c of (await listConnections(asHost)).items) {
+        if (c.lastSeenAt) presence.set(c.id, Date.parse(c.lastSeenAt));
+      }
+    } catch {
+    }
     for (const slot of listSlots()) {
       const harness = SLOT_HARNESS[slot] ?? (slot === "Desktop" ? void 0 : "claude");
       const key = runKey(slot);
       if (!harness) continue;
       const live = runs.get(key);
-      const action = wakeAction(!!live, published.get(key)?.movedAt, Date.now());
+      const tokenId = slotIdentity(slot).tokenId;
+      const seenByServer = tokenId ? presence.get(tokenId) : void 0;
+      const action = wakeAction(!!live, published.get(key)?.movedAt, Date.now(), seenByServer);
       if (action === "skip") continue;
       const token = readToken(slot);
       if (!token) continue;

package/dist/main.js

@@ -8627,6 +8627,7 @@ var coerce = {
 var NEVER = INVALID;
 
 // ../../packages/sdk/dist/index.js
+import { randomUUID as randomUUID2 } from "crypto";
 import { closeSync, existsSync, mkdirSync, openSync, readFileSync, rmSync, statSync, writeFileSync } from "fs";
 import { homedir } from "os";
 import { join } from "path";
@@ -12174,12 +12175,19 @@ var UpdateGoalSchema = external_exports.object({
   revision: external_exports.number().int().positive(),
   changes: external_exports.object({
     outcome: external_exports.string().trim().min(1).max(1e4).optional(),
-    state: external_exports.enum(["active", "waiting", "done", "cancelled"]).optional(),
+    ownerParticipant: external_exports.string().trim().min(1).optional(),
+    parentGoalId: external_exports.string().uuid().nullable().optional(),
+    dependencies: external_exports.array(external_exports.object({ goalId: external_exports.string().uuid(), gate: external_exports.enum(["start", "finish"]) }).strict()).optional(),
+    children: external_exports.array(external_exports.object({ outcome: external_exports.string().trim().min(1).max(1e4), ownerParticipant: external_exports.string().trim().min(1), gate: external_exports.enum(["start", "finish"]).optional() }).strict()).optional(),
+    state: external_exports.enum(["active", "done", "cancelled"]).optional(),
     progress: external_exports.string().trim().min(1).max(1e4).optional(),
     reviewed: external_exports.literal(true).optional()
-  }).refine((v) => Object.keys(v).length > 0),
-  reason: external_exports.string().trim().min(1).max(2e3)
-});
+  }).strict().refine((v) => Object.keys(v).length > 0),
+  reason: external_exports.string().trim().min(1).max(2e3),
+  operationId: external_exports.string().uuid().optional()
+}).strict();
+var UpdateGoalToolSchema = UpdateGoalSchema.extend({ goalId: external_exports.string().uuid() }).strict();
+var ClaimGoalSchema = external_exports.object({ goalId: external_exports.string().uuid().optional() }).strict();
 var fmtMin = (m) => m >= 60 ? `${m / 60} hr` : `${m} min`;
 var STANDARD_MEANS = (() => {
   const plan = MISSED_CALL_PLAN.backoff_standard;
@@ -12208,6 +12216,9 @@ function contactSchemaFrom(fields) {
     workId: fields.workId.describe(
       "The durable Work this contact advances. Pass the workId from check_replies or a prior reply when asking for a decision that blocks that work."
     ),
+    goalId: fields.goalId.describe(
+      "The target Goal this contact advances. Use goalId for the Goal model; do not combine it with workId."
+    ),
     // THE WAIT, CONTINUED (owner, 2026-09-06: "await should have been folded into contact").
     // A contact that rang holds its first window itself; the host caps one tool call at
     // ~60 s, so keeping the line is another contact — with ONLY this field. Nothing is sent.
@@ -12220,7 +12231,7 @@ function contactSchemaFrom(fields) {
   out.anyOf = [{ required: ["ask"] }, { required: ["wait"] }];
   return out;
 }
-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, workId?, decisionId?, wait? }. WHEN IT RANG, contact holds the first ~45 s window ITSELF and \`wait\` carries the outcome: { type:'reply', answer } to act on; { type:'partial', inFlight:true, turn } \u2014 what the user is saying to each turn, provisional: use it to PREPARE (fetch, draft, warm the build), never to act irreversibly, they can still revise it until the final reply (partial = intelligence, settled = authorization; if a partial's acts carry a question aimed at you and you know the answer, contact on the SAME parentId right away \u2014 they hear it on the same call); { type:'remind', remindInSeconds } \u2014 schedule a wake-up; { type:'idle' } \u2014 still waiting. TO KEEP WAITING, call contact again with ONLY { wait: notificationId } \u2014 no ask, nothing new is sent; it holds the next scoped ~45 s window (under the 60 s host cap, so it always returns) and never returns another notification's reply. Keep doing that until the reply \u2014 THAT one is the decision \u2014 so the user steps away and comes back to find you already continued; stop only to do other work and check back, or after an unreasonably long stretch worth telling them about. A message delivery has NO \`wait\`: never poll for it \u2014 the reply arrives through check_replies or your wake. Pass 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. BLOCKED ON A DECISION for existing work? Pass that work's \`workId\`; the reply returns the same workId plus a decisionId, so the answer resumes the right outcome. 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 ${OPTIONS_MIN}-${OPTIONS_MAX} 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. READING A CALL'S REPLY: it 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 question that blocks me'), 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.`;
+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, workId?, goalId?, entryId?, decisionId?, wait? }. WHEN IT RANG, contact holds the first ~45 s window ITSELF and \`wait\` carries the outcome: { type:'reply', answer } to act on; { type:'partial', inFlight:true, turn } \u2014 what the user is saying to each turn, provisional: use it to PREPARE (fetch, draft, warm the build), never to act irreversibly, they can still revise it until the final reply (partial = intelligence, settled = authorization; if a partial's acts carry a question aimed at you and you know the answer, contact on the SAME parentId right away \u2014 they hear it on the same call); { type:'remind', remindInSeconds } \u2014 schedule a wake-up; { type:'idle' } \u2014 still waiting. TO KEEP WAITING, call contact again with ONLY { wait: notificationId } \u2014 no ask, nothing new is sent; it holds the next scoped ~45 s window (under the 60 s host cap, so it always returns) and never returns another notification's reply. Keep doing that until the reply \u2014 THAT one is the decision \u2014 so the user steps away and comes back to find you already continued; stop only to do other work and check back, or after an unreasonably long stretch worth telling them about. A message delivery has NO \`wait\`: never poll for it \u2014 the reply arrives through check_replies or your wake. Pass parentId to a later contact to continue the conversation. A Goal-targeted contact also returns goalId and entryId for the durable Goal entry. 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. BLOCKED ON A DECISION for existing work? Pass that work's \`workId\`; the reply returns the same workId plus a decisionId, so the answer resumes the right outcome. 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 ${OPTIONS_MIN}-${OPTIONS_MAX} 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. READING A CALL'S REPLY: it 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 question that blocks me'), 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.`;
 var ContextSchema = external_exports.object({
   title: external_exports.string().min(1).describe("One-line headline of what you need (required, non-empty)."),
   description: external_exports.array(external_exports.string().min(1)).describe(
@@ -12333,6 +12344,9 @@ var NotifyRequestFields = external_exports.object({
   /** The durable outcome this contact advances. Optional during the notification-to-Work
    *  migration; when present, a blocking ask creates a DecisionNeed for this Work. */
   workId: external_exports.string().uuid().optional(),
+  /** Target Goal scope. During staged migration this is accepted by the shared contract but
+   * target delivery activation remains model-gated; workId and goalId are mutually exclusive. */
+  goalId: external_exports.string().uuid().optional(),
   urgency: NotifyLevelSchema.default("inbox").describe(
     "The level you're requesting \u2014 the user's account permissions + session mode can lower it. 'inbox' (default) = sits silently in the inbox for the user to get to. 'push' = a quiet passive push (lands in Notification Center, no sound) \u2014 a gentle heads-up. 'banner' = a time-sensitive banner/lock-screen push with sound (a 'paige') they tap to open \u2014 use when you need them soon-ish but it's not worth ringing them. 'call' = rings the user's phone now (a CallKit voice call) \u2014 use only when you genuinely need them in the moment (blocked and waiting, time-sensitive). context.title is what they see on the banner/ring, so make it specific."
   ),
@@ -12410,6 +12424,7 @@ var NotifyRequestFields = external_exports.object({
   )
 });
 var NotifyRequestSchema = NotifyRequestFields.superRefine((r, ctx) => {
+  if (r.workId && r.goalId) ctx.addIssue({ code: external_exports.ZodIssueCode.custom, path: ["goalId"], message: "pass goalId or workId, not both" });
   const sealed = !!r.envelope;
   if (sealed) {
     if (!r.envelope?.context)
@@ -13535,7 +13550,8 @@ var CONTACT_SCHEMA = contactSchemaFrom({
   options: NotifyRequestFields.shape.options,
   channel: NotifyRequestFields.shape.channel,
   parentId: NotifyRequestFields.shape.parentId,
-  workId: NotifyRequestFields.shape.workId
+  workId: NotifyRequestFields.shape.workId,
+  goalId: NotifyRequestFields.shape.goalId
 });
 var import_tweetnacl = __toESM2(require_nacl_fast(), 1);
 var import_tweetnacl2 = __toESM2(require_nacl_fast(), 1);
@@ -13942,6 +13958,32 @@ async function sealForE2ee(req, token, deps = {}) {
 }
 async function submitNotification(req, opts = {}) {
   const token = authToken(opts.token) ?? "";
+  if (req.goalId) {
+    if (req.envelope) throw new Error("Goal-scoped contact does not support E2EE envelopes yet");
+    const shaped = deriveAsk(req);
+    if (!shaped.context || !shaped.select) throw new Error("Goal-scoped contact requires a shaped request or ask");
+    if (shaped.channel === "call" || shaped.urgency === "call") {
+      throw new Error("Goal-scoped call contact is not available yet; use a message contact");
+    }
+    if (shaped.urgency && shaped.urgency !== "inbox") throw new Error("Goal-scoped contact currently supports inbox delivery only");
+    if (shaped.points?.length) throw new Error("Goal-scoped multi-part contact is not available yet; send one decision at a time");
+    const content = [shaped.context.title, ...shaped.context.description].filter(Boolean).join("\n\n");
+    const res2 = ensureAuthed(await reach(`${BACKEND_URL}/api/goals/${encodeURIComponent(req.goalId)}/contact`, {
+      method: "POST",
+      headers: { "content-type": "application/json", authorization: `Bearer ${token}`, "x-paigy-model": "goal-entry-v1" },
+      body: JSON.stringify({
+        operationId: randomUUID2(),
+        threadId: shaped.parentId ?? null,
+        content,
+        select: shaped.select,
+        options: shaped.options ?? [],
+        blocking: shaped.blocking,
+        channel: "message"
+      })
+    }));
+    if (!res2.ok) throw new Error(`goal contact failed: ${res2.status} ${await res2.text()}`);
+    return await res2.json();
+  }
   const body = await sealForE2ee(req, token);
   const res = ensureAuthed(await reach(`${BACKEND_URL}/api/notify`, {
     method: "POST",
@@ -15665,12 +15707,19 @@ var UpdateGoalSchema2 = external_exports.object({
   revision: external_exports.number().int().positive(),
   changes: external_exports.object({
     outcome: external_exports.string().trim().min(1).max(1e4).optional(),
-    state: external_exports.enum(["active", "waiting", "done", "cancelled"]).optional(),
+    ownerParticipant: external_exports.string().trim().min(1).optional(),
+    parentGoalId: external_exports.string().uuid().nullable().optional(),
+    dependencies: external_exports.array(external_exports.object({ goalId: external_exports.string().uuid(), gate: external_exports.enum(["start", "finish"]) }).strict()).optional(),
+    children: external_exports.array(external_exports.object({ outcome: external_exports.string().trim().min(1).max(1e4), ownerParticipant: external_exports.string().trim().min(1), gate: external_exports.enum(["start", "finish"]).optional() }).strict()).optional(),
+    state: external_exports.enum(["active", "done", "cancelled"]).optional(),
     progress: external_exports.string().trim().min(1).max(1e4).optional(),
     reviewed: external_exports.literal(true).optional()
-  }).refine((v) => Object.keys(v).length > 0),
-  reason: external_exports.string().trim().min(1).max(2e3)
-});
+  }).strict().refine((v) => Object.keys(v).length > 0),
+  reason: external_exports.string().trim().min(1).max(2e3),
+  operationId: external_exports.string().uuid().optional()
+}).strict();
+var UpdateGoalToolSchema2 = UpdateGoalSchema2.extend({ goalId: external_exports.string().uuid() }).strict();
+var ClaimGoalSchema2 = external_exports.object({ goalId: external_exports.string().uuid().optional() }).strict();
 var fmtMin2 = (m) => m >= 60 ? `${m / 60} hr` : `${m} min`;
 var STANDARD_MEANS2 = (() => {
   const plan = MISSED_CALL_PLAN2.backoff_standard;
@@ -15699,6 +15748,9 @@ function contactSchemaFrom2(fields) {
     workId: fields.workId.describe(
       "The durable Work this contact advances. Pass the workId from check_replies or a prior reply when asking for a decision that blocks that work."
     ),
+    goalId: fields.goalId.describe(
+      "The target Goal this contact advances. Use goalId for the Goal model; do not combine it with workId."
+    ),
     // THE WAIT, CONTINUED (owner, 2026-09-06: "await should have been folded into contact").
     // A contact that rang holds its first window itself; the host caps one tool call at
     // ~60 s, so keeping the line is another contact — with ONLY this field. Nothing is sent.
@@ -15711,7 +15763,7 @@ function contactSchemaFrom2(fields) {
   out.anyOf = [{ required: ["ask"] }, { required: ["wait"] }];
   return out;
 }
-var CONTACT_DESCRIPTION2 = `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, workId?, decisionId?, wait? }. WHEN IT RANG, contact holds the first ~45 s window ITSELF and \`wait\` carries the outcome: { type:'reply', answer } to act on; { type:'partial', inFlight:true, turn } \u2014 what the user is saying to each turn, provisional: use it to PREPARE (fetch, draft, warm the build), never to act irreversibly, they can still revise it until the final reply (partial = intelligence, settled = authorization; if a partial's acts carry a question aimed at you and you know the answer, contact on the SAME parentId right away \u2014 they hear it on the same call); { type:'remind', remindInSeconds } \u2014 schedule a wake-up; { type:'idle' } \u2014 still waiting. TO KEEP WAITING, call contact again with ONLY { wait: notificationId } \u2014 no ask, nothing new is sent; it holds the next scoped ~45 s window (under the 60 s host cap, so it always returns) and never returns another notification's reply. Keep doing that until the reply \u2014 THAT one is the decision \u2014 so the user steps away and comes back to find you already continued; stop only to do other work and check back, or after an unreasonably long stretch worth telling them about. A message delivery has NO \`wait\`: never poll for it \u2014 the reply arrives through check_replies or your wake. Pass 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_MEANS2}"), 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. BLOCKED ON A DECISION for existing work? Pass that work's \`workId\`; the reply returns the same workId plus a decisionId, so the answer resumes the right outcome. 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 ${OPTIONS_MIN2}-${OPTIONS_MAX2} 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. READING A CALL'S REPLY: it 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 question that blocks me'), 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.`;
+var CONTACT_DESCRIPTION2 = `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, workId?, goalId?, entryId?, decisionId?, wait? }. WHEN IT RANG, contact holds the first ~45 s window ITSELF and \`wait\` carries the outcome: { type:'reply', answer } to act on; { type:'partial', inFlight:true, turn } \u2014 what the user is saying to each turn, provisional: use it to PREPARE (fetch, draft, warm the build), never to act irreversibly, they can still revise it until the final reply (partial = intelligence, settled = authorization; if a partial's acts carry a question aimed at you and you know the answer, contact on the SAME parentId right away \u2014 they hear it on the same call); { type:'remind', remindInSeconds } \u2014 schedule a wake-up; { type:'idle' } \u2014 still waiting. TO KEEP WAITING, call contact again with ONLY { wait: notificationId } \u2014 no ask, nothing new is sent; it holds the next scoped ~45 s window (under the 60 s host cap, so it always returns) and never returns another notification's reply. Keep doing that until the reply \u2014 THAT one is the decision \u2014 so the user steps away and comes back to find you already continued; stop only to do other work and check back, or after an unreasonably long stretch worth telling them about. A message delivery has NO \`wait\`: never poll for it \u2014 the reply arrives through check_replies or your wake. Pass parentId to a later contact to continue the conversation. A Goal-targeted contact also returns goalId and entryId for the durable Goal entry. 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_MEANS2}"), 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. BLOCKED ON A DECISION for existing work? Pass that work's \`workId\`; the reply returns the same workId plus a decisionId, so the answer resumes the right outcome. 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 ${OPTIONS_MIN2}-${OPTIONS_MAX2} 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. READING A CALL'S REPLY: it 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 question that blocks me'), 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.`;
 var ContextSchema2 = external_exports.object({
   title: external_exports.string().min(1).describe("One-line headline of what you need (required, non-empty)."),
   description: external_exports.array(external_exports.string().min(1)).describe(
@@ -15824,6 +15876,9 @@ var NotifyRequestFields2 = external_exports.object({
   /** The durable outcome this contact advances. Optional during the notification-to-Work
    *  migration; when present, a blocking ask creates a DecisionNeed for this Work. */
   workId: external_exports.string().uuid().optional(),
+  /** Target Goal scope. During staged migration this is accepted by the shared contract but
+   * target delivery activation remains model-gated; workId and goalId are mutually exclusive. */
+  goalId: external_exports.string().uuid().optional(),
   urgency: NotifyLevelSchema2.default("inbox").describe(
     "The level you're requesting \u2014 the user's account permissions + session mode can lower it. 'inbox' (default) = sits silently in the inbox for the user to get to. 'push' = a quiet passive push (lands in Notification Center, no sound) \u2014 a gentle heads-up. 'banner' = a time-sensitive banner/lock-screen push with sound (a 'paige') they tap to open \u2014 use when you need them soon-ish but it's not worth ringing them. 'call' = rings the user's phone now (a CallKit voice call) \u2014 use only when you genuinely need them in the moment (blocked and waiting, time-sensitive). context.title is what they see on the banner/ring, so make it specific."
   ),
@@ -15901,6 +15956,7 @@ var NotifyRequestFields2 = external_exports.object({
   )
 });
 var NotifyRequestSchema2 = NotifyRequestFields2.superRefine((r, ctx) => {
+  if (r.workId && r.goalId) ctx.addIssue({ code: external_exports.ZodIssueCode.custom, path: ["goalId"], message: "pass goalId or workId, not both" });
   const sealed = !!r.envelope;
   if (sealed) {
     if (!r.envelope?.context)
@@ -16988,7 +17044,8 @@ var CONTACT_SCHEMA2 = contactSchemaFrom2({
   options: NotifyRequestFields2.shape.options,
   channel: NotifyRequestFields2.shape.channel,
   parentId: NotifyRequestFields2.shape.parentId,
-  workId: NotifyRequestFields2.shape.workId
+  workId: NotifyRequestFields2.shape.workId,
+  goalId: NotifyRequestFields2.shape.goalId
 });
 
 // src/paigy/activity.ts
@@ -17690,10 +17747,14 @@ var claimedRun = (sessionId2) => {
 async function slotHasWaitingWork(token) {
   return (await pendingSummary({ token })).unacknowledged > 0;
 }
-function wakeAction(live, seenAt, now) {
-  if (!live) return "spawn";
-  if (seenAt === void 0) return "skip";
-  return now - seenAt >= IDLE_WAKE_MS ? "prompt" : "skip";
+var PRESENCE_FRESH_MS = 3 * 6e4;
+function wakeAction(live, seenAt, now, serverSeenAt) {
+  if (live) {
+    if (seenAt === void 0) return "skip";
+    return now - seenAt >= IDLE_WAKE_MS ? "prompt" : "skip";
+  }
+  if (serverSeenAt !== void 0 && now - serverSeenAt < PRESENCE_FRESH_MS) return "skip";
+  return "spawn";
 }
 function startHost(opts) {
   const runs = /* @__PURE__ */ new Map();
@@ -17753,12 +17814,21 @@ function startHost(opts) {
   const SLOT_HARNESS = { "mcp-agent": "claude", codex: "codex", antigravity: "agy" };
   const wakePrompt = (fresh) => "You were woken because Paigy work is waiting for you. " + (fresh ? "This is a fresh session with your existing identity, so you may already have work in flight that you can't remember. " : "You have been running, so some of this may already be yours \u2014 but not what arrived while you were idle. ") + "Call check_replies FIRST, then get_thread on each conversation it returns and read it before you touch anything: it holds what you were doing, where (a repo or worktree may not be this folder), and what the owner already decided. Then handle what's waiting and follow your paigy instructions to stay in the loop. Speak to the owner at exactly TWO moments: when you are BLOCKED on a decision only they can make (contact with waiting:'hard', the decision as the ask, options if you have real ones), and when you are DONE (one short report: what shipped, how you verified it, anything you flagged). Progress is never a contact \u2014 call set_task_state('in_progress') when you pick work up and the app shows you working; narrate to the terminal, not to the human.";
   async function sweepSlots() {
+    const presence = /* @__PURE__ */ new Map();
+    try {
+      for (const c of (await listConnections(asHost)).items) {
+        if (c.lastSeenAt) presence.set(c.id, Date.parse(c.lastSeenAt));
+      }
+    } catch {
+    }
     for (const slot of listSlots()) {
       const harness = SLOT_HARNESS[slot] ?? (slot === "Desktop" ? void 0 : "claude");
       const key = runKey(slot);
       if (!harness) continue;
       const live = runs.get(key);
-      const action = wakeAction(!!live, published.get(key)?.movedAt, Date.now());
+      const tokenId = slotIdentity(slot).tokenId;
+      const seenByServer = tokenId ? presence.get(tokenId) : void 0;
+      const action = wakeAction(!!live, published.get(key)?.movedAt, Date.now(), seenByServer);
       if (action === "skip") continue;
       const token = readToken(slot);
       if (!token) continue;
@@ -18523,15 +18593,16 @@ ipcMain.handle("paigy:agent", async (_e, name) => {
   const entry = (host?.roster() ?? readHostState()?.roster ?? []).find((a) => a.name === name);
   if (!entry) return null;
   const token = entry.slot ? readToken(entry.slot) : "";
-  const pending = token ? await checkReplies({ token }).catch(() => null) : null;
+  const pending = token ? await pendingSummary({ token }).catch(() => null) : null;
   return {
     ...entry,
     pending: pending ? {
-      requests: pending.requests.slice(0, 5).map((r) => ({
-        line: (r.text.split("\n").find(Boolean) ?? "").slice(0, 140),
+      // The same two facts, from the counting read: what is waiting, and how much.
+      requests: pending.unacknowledgedItems.slice(0, 5).map((r) => ({
+        line: r.title.slice(0, 140),
         at: r.createdAt
       })),
-      replies: pending.replies.length
+      replies: pending.unacknowledged
     } : null
   };
 });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@paigy/harness",
-  "version": "0.3.4",
+  "version": "0.3.5",
   "description": "Run Claude Code / Codex on this machine, bridged to Paigy — launchable from your phone.",
   "license": "MIT",
   "type": "module",