@tickernelz/paperclip-pro-adapter-codex-local 2026.1017.2 → 2026.1018.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tickernelz/paperclip-pro-adapter-codex-local",
-  "version": "2026.1017.2",
+  "version": "2026.1018.0",
   "license": "MIT",
   "homepage": "https://github.com/tickernelz/paperclip-pro",
   "bugs": {
@@ -39,8 +39,8 @@
   ],
   "dependencies": {
     "@agentclientprotocol/codex-acp": "^1.6.2",
-    "@tickernelz/paperclip-pro-adapter-utils": "2026.1017.2",
-    "@tickernelz/paperclip-pro-shared": "2026.1017.2",
+    "@tickernelz/paperclip-pro-adapter-utils": "2026.1018.0",
+    "@tickernelz/paperclip-pro-shared": "2026.1018.0",
     "picocolors": "^1.1.1"
   },
   "devDependencies": {

package/skills/openwa/SKILL.md

@@ -380,8 +380,14 @@ live windows. Other runs get `owner_only`.
 A Paperclip card that waits for a person (confirmation, plan approval, question,
 checkbox or verdict card, human-only included) is never "only answerable in
 Paperclip" when the owner is talking to you here. When an owner asks what is
-waiting on them, call `paperclipListPendingDecisions` and summarize each item:
-issue, what it asks, its options. When the owner's own message explicitly
+waiting on them, call `paperclipListPendingDecisions` with `scope: "desk"` (the
+same list as the Decisions page; page with `cursor` while `nextCursor` is set)
+and summarize each item: kind, issue, what it asks, age. The default scope is
+partial (answerable cards and approvals only), so never answer "nothing is
+waiting" from it. Items with `relayable: false` (recovery, review, blocked
+dependency, governed approvals) stay in Paperclip; give `relayBlockedReason` and
+`href`. For cards, `scope: "relay"` also carries each card's prompt and options.
+When the owner's own message explicitly
 approves, rejects or answers one specific card, call
 `paperclipAnswerDecisionForOwner` with `issueId`, `interactionId`, the answer
 (`decision` approve or reject with `optionIds` or `reason`, `answers` for

package/skills/paperclip/SKILL.md

@@ -761,7 +761,7 @@ For detailed API tables, JSON response schemas, worked examples (IC and Manager
 
 ### Conversational confirmation answers
 
-When the user answers a pending confirmation in a message, record the answer before acting. Read current cards and comments with `paperclipListIssueInteractions` and `paperclipListComments`, then call `paperclipApiRequest` with `method: "POST"`, `path: "/issues/{issueId}/interactions/{interactionId}/resolve-from-comment"`, and a `jsonBody` carrying `commentId`, `decision: "accept" | "reject"`, and explicit `selectedOptionIds` for checkbox acceptance (native runners use `call_api`). Ambiguous replies among proposals require clarification. Revisions are not acceptance. Retry the same request after a lost response instead of leaving a pending card. Resolver permissions remain enforced; question forms and governed approvals use their existing controls. See the API reference for scope and retry rules. Human-only cards are answered by a person, but that person does not have to open Paperclip. When a board user's own message started your run (an owner WhatsApp message in an OpenWA run, or their comment that woke you) and it explicitly approves, rejects or answers one specific pending card, call `paperclipAnswerDecisionForOwner` with `issueId`, `interactionId`, the answer (`decision` with `optionIds` or `reason`, `answers`, or `verdicts`) and `ownerMessageRef` set to that message's id. The server verifies the message, records the answer as that user's (relayed by you) through the board answer path, and wakes the requester. List what is waiting with `paperclipListPendingDecisions`. Never answer without the person's explicit words for that card, never reuse one message for several cards unless it names each, and confirm back what you submitted. `owner_confirmation_required` (403) means the run lacks that authority; a 409 means the card is already resolved. Board approvals, agent decisions and governed tool, secret or connection cards are listed read-only and keep their own controls. An issue showing "Recovery needed" resumes only on a person's explicit request; an agent comment there only queues. When a board user's own message that started your run explicitly asks to continue such an issue, call `paperclipContinueIssueForOwner` with `issueId` and `ownerMessageRef`: the server posts it as their comment (relayed by you), which resolves the hold and starts a new run without repeating actions whose outcomes are unverified.
+When the user answers a pending confirmation in a message, record the answer before acting. Read current cards and comments with `paperclipListIssueInteractions` and `paperclipListComments`, then call `paperclipApiRequest` with `method: "POST"`, `path: "/issues/{issueId}/interactions/{interactionId}/resolve-from-comment"`, and a `jsonBody` carrying `commentId`, `decision: "accept" | "reject"`, and explicit `selectedOptionIds` for checkbox acceptance (native runners use `call_api`). Ambiguous replies among proposals require clarification. Revisions are not acceptance. Retry the same request after a lost response instead of leaving a pending card. Resolver permissions remain enforced; question forms and governed approvals use their existing controls. See the API reference for scope and retry rules. Human-only cards are answered by a person, but that person does not have to open Paperclip. When a board user's own message started your run (an owner WhatsApp message in an OpenWA run, or their comment that woke you) and it explicitly approves, rejects or answers one specific pending card, call `paperclipAnswerDecisionForOwner` with `issueId`, `interactionId`, the answer (`decision` with `optionIds` or `reason`, `answers`, or `verdicts`) and `ownerMessageRef` set to that message's id. The server verifies the message, records the answer as that user's (relayed by you) through the board answer path, and wakes the requester. List what is waiting with `paperclipListPendingDecisions` (`scope: "desk"` for the whole Decisions page; the default list is partial and an empty one never means nothing is pending). Never answer without the person's explicit words for that card, never reuse one message for several cards unless it names each, and confirm back what you submitted. `owner_confirmation_required` (403) means the run lacks that authority; a 409 means the card is already resolved. Board approvals, agent decisions and governed tool, secret or connection cards are listed read-only and keep their own controls. An issue showing "Recovery needed" resumes only on a person's explicit request; an agent comment there only queues. When a board user's own message that started your run explicitly asks to continue such an issue, call `paperclipContinueIssueForOwner` with `issueId` and `ownerMessageRef`: the server posts it as their comment (relayed by you), which resolves the hold and starts a new run without repeating actions whose outcomes are unverified.
 
 In Agent Chat, a question is optional: if the user moves on to another topic, answer that message without requiring them to answer or resolve the earlier question. Leave its card unanswered so they can reopen it later. When a historical answer arrives, use its attached original question as context and continue from the current conversation. Unrelated messages are never approval.