@tickernelz/paperclip-pro-adapter-codex-local 2026.1006.2 → 2026.1006.4

package/package.json

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

package/skills/openwa/SKILL.md

@@ -132,6 +132,15 @@ act beyond the run's facts. Silence never approves anything.
   `quoteDropped: true`. Do not resend.
 - A message steered into a running run names its `Message id`; quote that id
   when you answer it, not the id of an earlier message in the run.
+- A steered message may carry attachments of any type (documents of every
+  file type, images, video, voice notes, stickers, contact cards, locations):
+  the frame then ends with a JSON list of `{messageId, media[], location?,
+  contact?}` in the wake shape (`filename`, `mime`, `size`, `attachmentId`
+  and `localPath` when stored). Read every file before you answer, including
+  ones that arrive while you are already working on earlier files. Never say a
+  file was received without reading it. An item that is `pending`,
+  `unavailable` or has no `localPath` needs `openwa_get_media` with that
+  `messageId`; `too_large` items exceeded `limitBytes` and cannot be fetched.
 
 ## WhatsApp formatting
 
@@ -149,7 +158,8 @@ of the person you answer.
   newest first; continue with `nextCursor`. `source: "live"` reads WhatsApp
   directly; `deep: true` reaches up to 2000 messages. Results stay under 16 KB.
 - Trigger media is already stored as task attachments: each `media[]` item has
-  `attachmentId`, `kind`, `mime`, `size` and, for voice notes, `transcript` or
+  `attachmentId`, `kind`, `filename`, `mime` (`application/octet-stream` when
+  unknown), `size` and, for voice notes, `transcript` or
   `transcriptPending`. A `pending` or `unavailable` item was not stored yet; an
   item `unavailable: "too_large"` carries `limitBytes`, the size cap it exceeded.
 - Files of every type are stored, including executables, scripts and archives.
@@ -218,13 +228,24 @@ of the person you answer.
    first call. You write `messageToOwners`;
    it goes as one WhatsApp bubble to each owner approval chat. Then tell the
    requester you asked.
-2. Owners answer by replying to that bubble (quoting it) or in Paperclip. A
-   quoted owner reply starts an `approval_reply` run of class `owner`: interpret
-   the free text and call `openwa_approval_resolve({requestId, decision, conditions?})`
-   with `decision` `approve`, `reject` or `clarify` (keeps it pending). Only that
-   run may resolve that request. After approve or reject, end the run without a
-   reply: its final output is not published to the owner, and the server reacts
-   to the owner's message with ✅.
+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
+   or wants more detail, answer them in that chat (your final output is sent)
+   and keep the request pending (`decision` `clarify`). Their later messages in
+   the same chat, quoting or not, wake normal owner runs whose wake lists the
+   request under `approvalDiscussions`; those runs may resolve it too. Call
+   `openwa_approval_resolve({requestId, decision, conditions?})` with `approve` or
+   `reject` only once the owner's own words clearly decide. The server answers
+   409 `owner_decision_unclear` unless the owner's latest decisive message about
+   that request opens with an approval word (ok, oke, ya, iya, yes, boleh,
+   setuju, acc, gas, lanjut, silakan, sip, 👍, ✅) or a refusal word (jangan,
+   tidak, nggak, gak, no, tolak, batal, stop, reject, 👎) matching your decision.
+   Later words are conditions ("boleh, tapi jangan sebut harga" approves; pass
+   them in `conditions`). With several requests under discussion, an unquoted
+   "ok" decides none of them. Member messages never count. After approve or reject, end
+   the run without a reply: its final output is not published to the owner, and
+   the server reacts to the owner's message with ✅.
 3. The result arrives as an `approval_resolved` wake in the origin chat. When
    approved, the run is class `grant` and holds the grants: carry out only the
    approved action, respecting any `conditions`, and tell the requester.
@@ -312,8 +333,9 @@ Errors carry a typed `code`:
   `chat_inactive`, `gateway_admin_disabled`, `self_session_requires_confirmation`,
   `secret_issuing_operation`, `ui_only_setting`, `linked_chat_not_allowed`.
   Do not retry without approval.
-- Approvals: `approval_not_authorized`, `approval_not_needed` (owner runs need
-  none), `approval_action_pending` (an `approval_reply` run sent to the
+- Approvals: `approval_not_authorized`, `owner_decision_unclear` (the owner's
+  words did not clearly approve or reject; use `clarify` and keep discussing),
+  `approval_not_needed` (owner runs need none), `approval_action_pending` (an `approval_reply` run sent to the
   request's chat; resolve instead, the `approval_resolved` run acts),
   `already_resolved`, `no_owner_chat`, `message_too_long`,
   `requester_unknown`.