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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tickernelz/paperclip-pro-adapter-codex-local",
-  "version": "2026.1012.0",
+  "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.0",
-    "@tickernelz/paperclip-pro-shared": "2026.1012.0",
+    "@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

@@ -270,8 +270,10 @@ anew.
    either put the items in one task with a checklist or ask once with scope
    `requester` and say the count in `proposedAction`; never ask again after the
    first call. You write `messageToOwners`;
-   it goes as one WhatsApp bubble to each owner approval chat. Then tell the
-   requester you asked.
+   it goes as one WhatsApp bubble to each owner approval chat, or to the
+   chat's owner report group when the guidance names one. Then tell the
+   requester you asked. Never ask for approval by writing in a team or project
+   group: this tool is the only way to ask.
 2. Owners answer by replying to that bubble (quoting it) or in the OpenWA
    Approvals tab. A quoted owner reply starts an `approval_reply` run of class
    `owner`. Treat it as a conversation: when the owner asks a question, objects
@@ -315,6 +317,19 @@ anew.
 A gated call without approval fails with `approval_required` and its
 `category`; do not retry it. Live grants are listed in the wake `policy.grants`.
 
+## Reporting to the owner
+
+A chat may have an owner report group (Settings, Chats, **Report to owner
+via**), shown in the guidance as "Owner reports for this chat go to the group
+...". Then approval requests, owner_absent questions, reminders, any
+`openwa_send` to an owner's number and completion reports owed to the owner go
+to that group automatically: keep using the same tools and never pick the
+group or the owner's direct chat yourself. The receipt of a routed send has
+`ownerReportChat: true`. Owners answer there by quoting the bubble or with an
+unquoted ok/ya/jangan for the newest pending request; that starts the
+`approval_reply` run in the group, and the approved action runs in the origin
+chat. Replies meant for the origin chat stay in it.
+
 ## Owner-only configuration
 
 `openwa_endpoint_config` works only in owner-triggered runs; every other run gets
@@ -323,12 +338,17 @@ A gated call without approval fails with `approval_required` and its
 - `senders: {add?: [{list, number, label?}], remove?: [{list, number}]}` with
   `list` `allow` or `deny` and an E.164 `number`. A denylisted number is ignored
   from its next message on.
-- `chat` plus `chatSettings: {activation?, triggers?, absenceSeconds?, replyPolicy?, note?}`
+- `chat` plus `chatSettings: {activation?, triggers?, absenceSeconds?, replyPolicy?, note?, ownerReportChat?}`
   for one chat (default: the origin chat). `activation` is `auto`, `on` or
   `off`; `replyPolicy` is `allowed`, `ask_owner` or `owner_absent_only`; `null`
   clears an override. `triggers` replaces the chat's trigger overrides, so keep
   the ones it has. A dedicated group, where you handle every message without a
   mention, is `chatSettings: {activation: "on", triggers: {allMessages: true}}`.
+  `ownerReportChat` (a group chatRef or id, found with `openwa_find`) sends the
+  chat's owner reports and approval requests to that group, for example when
+  the owner says "laporan grup ini ke [BOT] DCM"; `null` returns to the owner's
+  direct chat. The group must have an owner as member and this number active in
+  it, otherwise the call fails with `invalid_arguments`.
 - `approvals: {createTask?, externalTools?, crossChatSend?, waAdmin?, gatewayAdmin?, reminderMinutes?, maxReminders?, pendingTtlHours?}`:
   approval toggles, reminders and the pending request lifetime in hours (1 to 168).
 - `burstWindowSeconds`: 0 to 10 (default 3, 0 = off); messages of one chat sent
@@ -355,6 +375,45 @@ accepted and audited; questions, verdicts, governed approvals and cards marked
 call `{operation: "close", idempotencyKey}` (optionally with `issues`); `list` shows the
 live windows. Other runs get `owner_only`.
 
+## Paperclip cards for the owner (owner runs 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
+approves, rejects or answers one specific card, call
+`paperclipAnswerDecisionForOwner` with `issueId`, `interactionId`, the answer
+(`decision` approve or reject with `optionIds` or `reason`, `answers` for
+questions, `verdicts` for verdict cards) and `ownerMessageRef` set to that
+message's `id` from this run's `messages`. The server checks that this run was
+started by that owner's own message and records the answer as theirs, relayed by
+you, through the same path as the Paperclip button; the requester wakes as usual.
+Then confirm in the chat exactly what you submitted.
+
+- Never answer a card without the owner's explicit words for that card. A
+  general "ok" answers the one card you just presented; ask when it could mean
+  more than one. One message answers one card unless it names each card
+  (issue identifier or card id).
+- `owner_confirmation_required` (403) means this run was not started by the
+  owner's own message, the owner is not linked to a Paperclip user, or that
+  message was already used; ask the owner to answer here again or in Paperclip.
+  A 409 means the card is already resolved. Items marked not relayable (board
+  approvals, agent decisions, governed tool/secret/connection cards, OpenWA
+  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.
+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.