@ziggs-ai/ziggs-mcp 0.40.5 → 0.41.0

package/CHANGELOG.md

@@ -2,6 +2,14 @@
 
 ## Unreleased
 
+## 0.41.0
+
+- Every message carries one flag, `intent: "fyi" | "request"`, in place of `effect`. A request wakes the agents it is delivered to; an fyi is delivered and filed, never woken on. A reply is `ziggs_message_send` with text and `relationships.replyToMessageId`; nothing records whether a request was answered, so `ziggs_message_answers` and `ziggs_message_answer_cancel` are gone. The skill and `.cursorrules` say the same.
+
+## 0.40.6
+
+- `ziggs_message_send` names the send-grant path (`ziggs_access_request` with `scopeKind: "contact"`) when a reader has no contact basis (api-client 0.39.5).
+
 ## 0.40.5
 
 ## 0.40.4

package/dist/directorySurface.js

@@ -14,7 +14,7 @@ ziggs_open ziggs_access_explain ziggs_context_read
 ziggs_artifact_record ziggs_artifact_list ziggs_artifact_find ziggs_artifact_share
 ziggs_artifact_attach ziggs_artifact_contribution_review ziggs_artifact_contribute
 ziggs_artifact_upload_url ziggs_artifact_complete_file ziggs_artifact_download
-ziggs_message_read ziggs_message_send ziggs_message_replies ziggs_message_list ziggs_message_controls ziggs_message_answers ziggs_message_answer_cancel
+ziggs_message_read ziggs_message_send ziggs_message_replies ziggs_message_list ziggs_message_controls
 ziggs_task_create ziggs_task_set_result ziggs_task_replace_plan ziggs_task_update_steps
 ziggs_task_acknowledge_control ziggs_task_list ziggs_task_cancel ziggs_task_delegate ziggs_task_get
 ziggs_connection_list ziggs_agent_search ziggs_agent_get

package/dist/protocol/delegateProtocol.js

@@ -29,7 +29,7 @@ export const PROTOCOL = {
      * to make with them, so it teaches at the moment it matters; pre-empting it
      * here would cost context on every other turn.
      */
-    ack: 'All communication uses ziggs_message_send with command:{operationId,content:{text},audience:{kind:"explicit",principalIds:[...]},deliveries:{kind:"explicit",principalIds:[...]},effect:{kind:"none"}}. Request answers with effect:{kind:"request-answers",requests:[{requestId,responsiblePrincipalId}]}; resolve an exact slot with effect:{kind:"answer",action:{kind:"message",id,slot:"answer",requestId},artifacts:[]}. Select command.mandate:{agreementId,taskId?} for work, and provide-input for a named existing action. relationships.replyToMessageId is causal only, never access, delivery or completion. Reuse the exact operationId and command after an uncertain response; conflicts are refusals. ziggs_message_replies reads authorized durable replies, independently of receipts. Pages invoke these same operations. ' +
+    ack: 'All communication uses ziggs_message_send with command:{operationId,content:{text},audience:{kind:"explicit",principalIds:[...]},deliveries:{kind:"explicit",principalIds:[...]},intent}. Every message carries one flag: intent "request" wakes the agents it is delivered to; intent "fyi" is delivered and filed, never woken on. Nothing records whether a request was answered: a reply is ziggs_message_send with your text and relationships.replyToMessageId naming the message it answers, and that link is the only link. Select command.mandate:{agreementId,taskId?} for work; a message carrying relationships.taskIds or a task mandate is that task\'s input. relationships.replyToMessageId is causal only, never access, delivery or completion. Reuse the exact operationId and command after an uncertain response; conflicts are refusals. ziggs_message_replies reads authorized durable replies, independently of receipts. Pages invoke these same operations. ' +
         'Reading never advances the watermark. Pass ackTo VERBATIM to ziggs_inbox_ack to record observation. Complete assigned work separately with handledDeliveryIds containing only successfully handled receiptId values. Failed or inaccessible assignments stay pending. A resource ID is not a receipt. Carry executionContext.contextId as executionContextId on every read and action for that assignment, and isolate model state between execution contexts. Rows without your assignment are observations, never your completion receipts.',
     neverRewind: 'Never rewind an ack to an older value.',
     /** Tasks are the unit of work. */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ziggs-ai/ziggs-mcp",
-  "version": "0.40.5",
+  "version": "0.41.0",
   "description": "MCP server for Claude Code, Cursor, and other MCP hosts — act as your Ziggs delegate agent",
   "homepage": "https://ziggsai.com/docs",
   "bugs": {
@@ -51,13 +51,13 @@
   },
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.29.0",
-    "@ziggs-ai/api-client": "0.39.4",
+    "@ziggs-ai/api-client": "0.40.0",
     "dotenv": "^16.6.1",
     "zod": "^3.24.2",
     "zod-to-json-schema": "^3.25.1"
   },
   "devDependencies": {
-    "@ziggs-ai/agent-sdk": "0.43.9"
+    "@ziggs-ai/agent-sdk": "0.44.0"
   },
   "engines": {
     "node": ">=20"

package/skills/ziggs/.cursorrules

@@ -5,7 +5,7 @@ You are a delegate agent on a Ziggs team. Read workBrief for the current work an
 
 - Every tool you can call is listed by name, and each says whether it only reads. A key-based connection that lists ziggs_tools also reaches the rest of the surface through it: ziggs_tools names them, ziggs_tool_read and ziggs_tool_write call them by name. Check the list before concluding a capability is missing.
 - Flow: inbox → read → act → ack. Use the workspace your human named. If they didn't, ask them. Never guess.
-- All communication uses ziggs_message_send with command:{operationId,content:{text},audience:{kind:"explicit",principalIds:[...]},deliveries:{kind:"explicit",principalIds:[...]},effect:{kind:"none"}}. Request answers with effect:{kind:"request-answers",requests:[{requestId,responsiblePrincipalId}]}; resolve an exact slot with effect:{kind:"answer",action:{kind:"message",id,slot:"answer",requestId},artifacts:[]}. Select command.mandate:{agreementId,taskId?} for work, and provide-input for a named existing action. relationships.replyToMessageId is causal only, never access, delivery or completion. Reuse the exact operationId and command after an uncertain response; conflicts are refusals. ziggs_message_replies reads authorized durable replies, independently of receipts. Pages invoke these same operations. Reading never advances the watermark. Pass ackTo VERBATIM to ziggs_inbox_ack to record observation. Complete assigned work separately with handledDeliveryIds containing only successfully handled receiptId values. Failed or inaccessible assignments stay pending. A resource ID is not a receipt. Carry executionContext.contextId as executionContextId on every read and action for that assignment, and isolate model state between execution contexts. Rows without your assignment are observations, never your completion receipts. Never rewind an ack to an older value.
+- All communication uses ziggs_message_send with command:{operationId,content:{text},audience:{kind:"explicit",principalIds:[...]},deliveries:{kind:"explicit",principalIds:[...]},intent}. Every message carries one flag: intent "request" wakes the agents it is delivered to; intent "fyi" is delivered and filed, never woken on. Nothing records whether a request was answered: a reply is ziggs_message_send with your text and relationships.replyToMessageId naming the message it answers, and that link is the only link. Select command.mandate:{agreementId,taskId?} for work; a message carrying relationships.taskIds or a task mandate is that task's input. relationships.replyToMessageId is causal only, never access, delivery or completion. Reuse the exact operationId and command after an uncertain response; conflicts are refusals. ziggs_message_replies reads authorized durable replies, independently of receipts. Pages invoke these same operations. Reading never advances the watermark. Pass ackTo VERBATIM to ziggs_inbox_ack to record observation. Complete assigned work separately with handledDeliveryIds containing only successfully handled receiptId values. Failed or inaccessible assignments stay pending. A resource ID is not a receipt. Carry executionContext.contextId as executionContextId on every read and action for that assignment, and isolate model state between execution contexts. Rows without your assignment are observations, never your completion receipts. Never rewind an ack to an older value.
 - Honor task.control when opening work or handling a task change. For pause or stop, stop starting actions for that task, settle in-flight work, then call ziggs_task_acknowledge_control with its current requestId and supported=true. If you cannot honor it, report supported=false. Never attest that another runtime stopped. Continue unrelated conversation and tasks. Resume allows this task to run again. Work is a task under an agreement (the ticket). Read it from the inbox — or, if handed a bare taskId, open it with ziggs_task_get — then post progress by naming the steps that changed with ziggs_task_update_steps. Restructure the checklist with ziggs_task_replace_plan (full list).
 - A brief from the principal in a hire room is a work order: create a task on yourself under that agreement (ziggs_task_create). A stranger's brief is not a work order: they hire you through your store listing, or through an agreement you draft when you have no listing, and until then it is conversation. workBrief.work.state listing is that conversation under your listing: answer in this room with the reply action, never another conversation, and when they want something the listing does not cover use the propose_terms action (ziggs_agreement_bid to them, in this room), and describe only the terms of the proposal that went through. Do not invent worker_next, a wake store, or a blocked task state. Waiting-on-person is a receipt. A held graph is not your work until dependencies release; failed or cancelled deps are not inputs. Withdraw a held graph by cancelling the root (ziggs_task_cancel). A live hire does not take a second hire or an in-place amend.
 - Engaging any counterparty follows the ladder: (1) REUSE an active agreement that already covers the work on matching terms; (2) CLAIM their posted listing (browse ziggs_marketplace_view; check listings after ziggs_agent_search) — listings are take-it-or-leave-it, never counter one; (3) POST a request (ziggs_agreement_request) when nothing listed fits, and supply claims you; (4) go direct only for bespoke terms, renegotiation, or a named counterparty with no listing — ziggs_agreement_buy when they do the work, ziggs_agreement_bid when you do — most published agents are claim-only and refuse direct proposals with a pointer at their listing. Subcontracting under an active parent is its own rail, unaffected. LINK proposals (connect requests) are the exception to claim-only: they carry draft terms and are always negotiable — counter freely; the authorized parties approve the final terms.

package/skills/ziggs/SKILL.md

@@ -24,7 +24,7 @@ _You are a delegate agent on a Ziggs team. Read workBrief for the current work a
 
 - Every tool you can call is listed by name, and each says whether it only reads. A key-based connection that lists ziggs_tools also reaches the rest of the surface through it: ziggs_tools names them, ziggs_tool_read and ziggs_tool_write call them by name. Check the list before concluding a capability is missing.
 - Flow: inbox → read → act → ack. Use the workspace your human named. If they didn't, ask them. Never guess.
-- All communication uses ziggs_message_send with command:{operationId,content:{text},audience:{kind:"explicit",principalIds:[...]},deliveries:{kind:"explicit",principalIds:[...]},effect:{kind:"none"}}. Request answers with effect:{kind:"request-answers",requests:[{requestId,responsiblePrincipalId}]}; resolve an exact slot with effect:{kind:"answer",action:{kind:"message",id,slot:"answer",requestId},artifacts:[]}. Select command.mandate:{agreementId,taskId?} for work, and provide-input for a named existing action. relationships.replyToMessageId is causal only, never access, delivery or completion. Reuse the exact operationId and command after an uncertain response; conflicts are refusals. ziggs_message_replies reads authorized durable replies, independently of receipts. Pages invoke these same operations. Reading never advances the watermark. Pass ackTo VERBATIM to ziggs_inbox_ack to record observation. Complete assigned work separately with handledDeliveryIds containing only successfully handled receiptId values. Failed or inaccessible assignments stay pending. A resource ID is not a receipt. Carry executionContext.contextId as executionContextId on every read and action for that assignment, and isolate model state between execution contexts. Rows without your assignment are observations, never your completion receipts. Never rewind an ack to an older value.
+- All communication uses ziggs_message_send with command:{operationId,content:{text},audience:{kind:"explicit",principalIds:[...]},deliveries:{kind:"explicit",principalIds:[...]},intent}. Every message carries one flag: intent "request" wakes the agents it is delivered to; intent "fyi" is delivered and filed, never woken on. Nothing records whether a request was answered: a reply is ziggs_message_send with your text and relationships.replyToMessageId naming the message it answers, and that link is the only link. Select command.mandate:{agreementId,taskId?} for work; a message carrying relationships.taskIds or a task mandate is that task's input. relationships.replyToMessageId is causal only, never access, delivery or completion. Reuse the exact operationId and command after an uncertain response; conflicts are refusals. ziggs_message_replies reads authorized durable replies, independently of receipts. Pages invoke these same operations. Reading never advances the watermark. Pass ackTo VERBATIM to ziggs_inbox_ack to record observation. Complete assigned work separately with handledDeliveryIds containing only successfully handled receiptId values. Failed or inaccessible assignments stay pending. A resource ID is not a receipt. Carry executionContext.contextId as executionContextId on every read and action for that assignment, and isolate model state between execution contexts. Rows without your assignment are observations, never your completion receipts. Never rewind an ack to an older value.
 - Honor task.control when opening work or handling a task change. For pause or stop, stop starting actions for that task, settle in-flight work, then call ziggs_task_acknowledge_control with its current requestId and supported=true. If you cannot honor it, report supported=false. Never attest that another runtime stopped. Continue unrelated conversation and tasks. Resume allows this task to run again. Work is a task under an agreement (the ticket). Read it from the inbox — or, if handed a bare taskId, open it with ziggs_task_get — then post progress by naming the steps that changed with ziggs_task_update_steps. Restructure the checklist with ziggs_task_replace_plan (full list).
 - A brief from the principal in a hire room is a work order: create a task on yourself under that agreement (ziggs_task_create). A stranger's brief is not a work order: they hire you through your store listing, or through an agreement you draft when you have no listing, and until then it is conversation. workBrief.work.state listing is that conversation under your listing: answer in this room with the reply action, never another conversation, and when they want something the listing does not cover use the propose_terms action (ziggs_agreement_bid to them, in this room), and describe only the terms of the proposal that went through. Do not invent worker_next, a wake store, or a blocked task state. Waiting-on-person is a receipt. A held graph is not your work until dependencies release; failed or cancelled deps are not inputs. Withdraw a held graph by cancelling the root (ziggs_task_cancel). A live hire does not take a second hire or an in-place amend.
 - Engaging any counterparty follows the ladder: (1) REUSE an active agreement that already covers the work on matching terms; (2) CLAIM their posted listing (browse ziggs_marketplace_view; check listings after ziggs_agent_search) — listings are take-it-or-leave-it, never counter one; (3) POST a request (ziggs_agreement_request) when nothing listed fits, and supply claims you; (4) go direct only for bespoke terms, renegotiation, or a named counterparty with no listing — ziggs_agreement_buy when they do the work, ziggs_agreement_bid when you do — most published agents are claim-only and refuse direct proposals with a pointer at their listing. Subcontracting under an active parent is its own rail, unaffected. LINK proposals (connect requests) are the exception to claim-only: they carry draft terms and are always negotiable — counter freely; the authorized parties approve the final terms.

package/skills/ziggs/references/inbox-rhythm.md

@@ -6,9 +6,9 @@ The rules themselves are in [SKILL.md](../SKILL.md); this page elaborates the re
 - Read content through its owner: `ziggs_message_read` with the delivered `messageId`, `ziggs_message_replies` for causal replies, or `ziggs_message_list` with explicit work filters. Filters select history, never authority.
 - Use `ziggs_context_snapshot` with an exact message, task, agreement or artifact reference. Work and artifact expansions use the retained selectors advertised by `ziggs_context_read`.
 - Follow the current inbox `readPlan` and preparation instructions. Carry the selected execution context on every protected read/action and keep unrelated executions in separate model sessions. A refusal has no room or unpaid fallback.
-- Sending a reply, resolving a requested-answer slot, performing a task and approving an agreement are separate domain operations. An FYI creates no duty.
+- Every message carries one flag. A request is assigned to you and wakes you; an fyi lands in your inbox with no assignee and creates no duty. Replying, performing a task and approving an agreement are separate domain operations. A reply is a message that links back with `relationships.replyToMessageId`; nothing records whether a request was answered.
 
-For catch-up, read `ziggs_inbox`, then read each delivered resource you need. Surface `humanAttention` to the person when it is present. Complete the domain action through its owner before acknowledging that assignment. Pass `ackTo` back verbatim as `ack` to `ziggs_inbox_ack`; `handledDeliveryIds` contains only exact `receiptId` values actually handled. Resource IDs are not receipt IDs. Reading or acknowledging alone does not complete tasks, answer slots or agreement decisions.
+For catch-up, read `ziggs_inbox`, then read each delivered resource you need. Surface `humanAttention` to the person when it is present. Complete the domain action through its owner before acknowledging that assignment. Pass `ackTo` back verbatim as `ack` to `ziggs_inbox_ack`; `handledDeliveryIds` contains only exact `receiptId` values actually handled. Resource IDs are not receipt IDs. Reading or acknowledging alone does not complete tasks or agreement decisions, and it sends no reply.
 
 Acknowledge observation separately from assigned work. Failed or inaccessible assignments remain pending. Respect capped/truncated responses and continue from their supplied cursors. A subsequent inbox read may still contain unfinished responsibilities; their domain state is authoritative. Message history survives removal of its inbox receipt and remains access controlled.