@paigy/mcp 0.40.1 → 0.40.3

package/README.md

@@ -145,42 +145,48 @@ not a compatibility fallback for target MCP tools.
   no extra setup. Two edges: with `HTTP_PROXY` set, an `http://localhost` backend
   proxies too unless `NO_PROXY=localhost` (hostname entries work; CIDR ranges are
   ignored), and `paigy-listen`'s realtime wake channel is a websocket that doesn't
-  proxy — its REST sweeps do.
+  proxy — its REST reads do.
 
 ## Wake any harness (`paigy-listen`)
 
 `paigy-listen` is the self-hosted push daemon: it subscribes to this connection's
-wake channel and sweeps on every nudge. Keep it alive past the terminal with
-`paigy-listen --install` (launchd on macOS, systemd user unit on Linux; `--uninstall`
-removes it).
+wake channel and reads what is waiting on every nudge. Keep it alive past the terminal
+with `paigy-listen --install` (launchd on macOS, systemd user unit on Linux;
+`--uninstall` removes it).
+
+The read is `check_replies` — the open Deliveries addressed to this agent — and it
+**consumes nothing**: no lease, no acknowledgement, and the same read twice returns the
+same list. So the daemon hands the launcher what it found and stops there; claiming is
+the agent's own first act (`claim_goal`), because the daemon shares this machine's
+token with the agent it launches and a second claimer on one identity eats the first
+one's claim.
 
 To launch an agent — any agent, not just Claude — when work arrives, set
-`PAIGY_ON_WAKE` to a command before `--install`. The sweep has already claimed the
-work, so the launcher reads it from the environment rather than calling
-`check_replies` again:
+`PAIGY_ON_WAKE` to a command before `--install`:
 
 | Variable | What it holds |
 | --- | --- |
-| `PAIGY_WORK` | the whole swept payload as JSON (`replies`, `requests`, `owedCallbacks`, `stalled`, `threads`) |
-| `PAIGY_EVENT` | the wake that caused this run — `boot`, `wake:reply`, `cron:callback`… |
-| `PAIGY_THREAD_ID` | the thread to continue on |
-| `PAIGY_NOTIFICATION_ID` | the notification being answered or acted on (unset for an owed callback) |
-| `PAIGY_CONTEXT_THREAD_ID` | a past conversation the user seeded this with — `get_thread` it **first** |
-| `PAIGY_TEXT` | what the user said (or the callback note you owe them), in prose |
+| `PAIGY_WORK` | everything the wake found, as JSON (`deliveries`, `goal`) |
+| `PAIGY_EVENT` | the wake that caused this run — `boot`, `wake:reply`, `wake:request`… |
+| `PAIGY_PARENT_ID` | the thread to continue on (`PAIGY_THREAD_ID` is the same value, for existing scripts) |
+| `PAIGY_DELIVERY_ID` | the Delivery being acted on — `contact({deliveryId})` rereads it |
+| `PAIGY_GOAL_ID` | the Goal it belongs to — `claim_goal` it **first** |
+| `PAIGY_CONTEXT_THREAD_ID` | a past conversation this Goal names — `get_thread` it **first** |
+| `PAIGY_TEXT` | what the person said, in prose |
 
 Hand `$PAIGY_WORK` to a harness that can read JSON and decide for itself; use the
 scalars for a plain shell launcher that shouldn't need `jq`. They describe **one**
-item — the oldest thread without a turn already in flight — because the queue rail's
-contract is one thread at a time. An absent fact is unset rather than empty, so
-`${PAIGY_CONTEXT_THREAD_ID:-}` distinguishes "no seed" from "seeded with nothing".
+item — the oldest open Delivery — because the contract is one thread at a time. An
+absent fact is unset rather than empty, so `${PAIGY_CONTEXT_THREAD_ID:-}`
+distinguishes "no seed" from "seeded with nothing".
 
 ```sh
 # Claude Code — hand it everything and let it plan:
-PAIGY_ON_WAKE='claude -p "Handle the Paigy work in $PAIGY_WORK — rehydrate threads you do not recognize via get_thread first."' \
+PAIGY_ON_WAKE='claude -p "Handle the Paigy work in $PAIGY_WORK — claim_goal first, and rehydrate threads you do not recognize via get_thread."' \
   npx -y -p @paigy/mcp paigy-listen --install
 
 # Codex (or any CLI harness) — the scalars are enough for a one-liner:
-PAIGY_ON_WAKE='codex exec "Continue Paigy thread $PAIGY_THREAD_ID. The user said: $PAIGY_TEXT. Call get_thread on it first if you do not recognize it, then reply with contact."' \
+PAIGY_ON_WAKE='codex exec "Claim Paigy goal $PAIGY_GOAL_ID and continue thread $PAIGY_THREAD_ID. The user said: $PAIGY_TEXT. Reply with contact."' \
   npx -y -p @paigy/mcp paigy-listen --install
 ```
 
@@ -194,10 +200,7 @@ script and branch on `$PAIGY_EVENT` there:
 seed=""
 [ -n "${PAIGY_CONTEXT_THREAD_ID:-}" ] && seed="It continues thread $PAIGY_CONTEXT_THREAD_ID — get_thread that first."
 
-case "$PAIGY_EVENT" in
-  cron:callback*) codex exec "You owe the user a callback on thread $PAIGY_THREAD_ID: $PAIGY_TEXT. Deliver it with contact." ;;
-  *)              codex exec "Paigy thread $PAIGY_THREAD_ID. The user said: $PAIGY_TEXT. $seed Reply with contact when done." ;;
-esac
+codex exec "Paigy goal $PAIGY_GOAL_ID on thread $PAIGY_THREAD_ID. claim_goal it first. The user said: $PAIGY_TEXT. $seed Reply with contact when done."
 ```
 
 ## Statusline (Claude Code)

package/dist/{chunk-TLASZUJD.js → chunk-4JDG67EF.js}

@@ -2,10 +2,10 @@ import {
   AGENT_TOOLS,
   mcpInputSchema,
   serverInstructions
-} from "./chunk-3QUIB42M.js";
+} from "./chunk-V3VVCML7.js";
 import {
   AGENT_NAME
-} from "./chunk-4UZAPBKK.js";
+} from "./chunk-6QQHTUKJ.js";
 
 // src/toolset.ts
 var ONBOARD_DESCRIPTION = "Get this agent talking to Paigy \u2014 call it FIRST, before contact, 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.";