@tickernelz/paperclip-pro-adapter-codex-local 2026.1012.1 → 2026.1012.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tickernelz/paperclip-pro-adapter-codex-local",
-  "version": "2026.1012.1",
+  "version": "2026.1012.2",
   "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.1012.1",
-    "@tickernelz/paperclip-pro-shared": "2026.1012.1",
+    "@tickernelz/paperclip-pro-adapter-utils": "2026.1012.2",
+    "@tickernelz/paperclip-pro-shared": "2026.1012.2",
     "picocolors": "^1.1.1"
   },
   "devDependencies": {

package/skills/openwa/SKILL.md

@@ -403,6 +403,17 @@ Then confirm in the chat exactly what you submitted.
   approval requests) stay with their own controls; say so and link them.
 - Members and non-owner runs cannot relay; tell them the owner must answer.
 
+An issue that shows "Recovery needed" (execution stopped; comments wait behind
+"Waiting for execution recovery") resumes only on a person's explicit request.
+Your own comment there only queues. When the owner's own message explicitly asks
+to continue such an issue, call `paperclipContinueIssueForOwner` with `issueId`
+and `ownerMessageRef` set to that message's `id`. The server posts the owner's
+message as their comment, relayed by you; that resolves the hold and starts a new
+run, and actions with unverified outcomes are not repeated. The message must be
+sent after the run stopped and must not name only other issues; one message
+continues one issue. A 409 `execution_recovery_not_held` means the issue is not
+held: comment normally.
+
 ## Linked numbers (owner runs only)
 
 The board may link other WhatsApp numbers on the same gateway, such as an

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.
+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.
 
 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.