@tickernelz/paperclip-pro-adapter-codex-local 2026.1007.3 → 2026.1008.1

package/package.json

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

package/skills/openwa/SKILL.md

@@ -11,7 +11,7 @@ Call these tools directly by name; never list, search or catalog tools to find
 them: `openwa_send`, `openwa_read_chat`, `openwa_get_media`, `openwa_find`,
 `openwa_request_approval`, `openwa_approval_resolve`, `openwa_stay_silent`,
 `openwa_handoff`, `openwa_catalog`, `openwa_describe`, `openwa_call`,
-`openwa_endpoint_config`, `openwa_linked_list`, `openwa_linked_read`,
+`openwa_endpoint_config`, `openwa_autonomy_window`, `openwa_linked_list`, `openwa_linked_read`,
 `openwa_linked_get_media`. The run
 guidance already states your trigger class, profile, owners and whether you may
 reply; do not re-read this skill to confirm them.
@@ -185,12 +185,18 @@ of the person you answer.
 
 ## Progress, silence and handoff
 
-- When work takes longer than about a minute and nothing in the chat has
-  acknowledged the request yet, send one short progress update with
-  `openwa_send` (when replying is allowed). Skip it when you are about to reply,
-  and never restate what was already sent. The server may remind you inside the
-  run while a trigger waits unacknowledged; that reminder is never sent to
-  WhatsApp and stops once you send to the chat.
+- Send one progress update with `openwa_send` only to a person whose message
+  is in this run's `messages` and who has had no reply from you yet, and only
+  when your result is still minutes away. Never restate what was already sent,
+  and never post internal status to a group (approval, review, tests, retries,
+  blocked, waiting for a deploy); that belongs on the issue. The server may
+  remind you inside the run while a trigger waits unacknowledged; that reminder
+  is never sent to WhatsApp and stops once you send to the chat.
+- Wakes without a new chat message (empty `messages`: issue comments, child
+  issues completing, other non-chat wakes) post to the chat only a final result
+  that is live or delivered and not yet announced there; otherwise update the
+  issue and send nothing to the chat. An `approval_resolved` wake still tells
+  the requester the outcome as described under Approvals.
 - `openwa_stay_silent({triggerIds?})` marks triggers you deliberately leave
   unanswered (default: every visible pending trigger of this run). Use it when no
   reply is appropriate.
@@ -279,6 +285,19 @@ with before and after values. Credentials, number mode, owners and the gateway
 admin level are changed by a person in Paperclip and fail with
 `ui_only_setting`.
 
+## Autonomy windows (owner runs only)
+
+When an owner hands named work over for autonomous progress ("full otonom",
+"aku approve commit, push, deploy"), call
+`openwa_autonomy_window({operation: "open", issues: ["ZHA-745"], hours?, maxAccepts?, idempotencyKey})`
+for the issues they name; descendants are included. `hours` is 1 to 24 (default
+12). Ask once which issues when their words do not name the work. While the
+window is open, plain confirmation cards created in those trees come back
+accepted and audited; questions, verdicts, governed approvals and cards marked
+`destructive: true` or without `destructive: false` still wait for a person. When the owner says they are back,
+call `{operation: "close", idempotencyKey}` (optionally with `issues`); `list` shows the
+live windows. Other runs get `owner_only`.
+
 ## Linked numbers (owner runs only)
 
 The board may link other WhatsApp numbers on the same gateway, such as an

package/skills/paperclip/SKILL.md

@@ -386,6 +386,7 @@ Key shared semantics:
 - **Resolver audience.** Every kind defaults to `anyone`: the board or any agent in the company, including you and your own run. **Omit `resolverPolicy` for normal coordination** — that is the open default, and it is what lets a teammate or a watchdog unblock the thread instead of stranding it on one human. Ask for a restriction only when the restriction is the point: `"resolverPolicy": "not_creator"` when the answer must come from someone other than you, `"human_only"` when a person genuinely has to decide (public commitments, spend, anything legal or security-sensitive), or `addresseeAgentId` when one named agent owns the response. Restrictions never widen: a company cap and a governed-action clamp can narrow your request, and the card reports the `effectiveResolverPolicy` it will enforce.
 - **Continuation policy.** `request_checkbox_confirmation` and `request_item_verdicts` default to `wake_assignee`, which wakes you after the card is resolved or newly resolved item verdicts are submitted. `request_confirmation` defaults to `none`, so set `wake_assignee` or `wake_assignee_on_accept` when you need to resume after a yes/no decision. `none` never wakes you — only use it when you truly do not need to resume.
 - **Target binding and staleness.** `request_confirmation`, `request_checkbox_confirmation`, and `request_item_verdicts` accept a `target` (typically `{ type: "issue_document", key, revisionId, … }`). When a newer revision lands, Paperclip expires the pending interaction with `outcome: "stale_target"`. Rebuild against the latest revision and create a fresh interaction.
+- **Autonomy windows and destructive steps.** Every `request_confirmation` declares `payload.destructive`: `false` for a routine step (push, merge, deploy, upgrade, restart with a backup and rollback path), `true` for a destructive one (force-push, history rewrite, data loss or a data change without a fresh dump, secrets). While the owner has an autonomy window open on your issue tree, a card with `destructive: false` comes back from create already `accepted`; read the returned `status` and continue instead of waiting. A card with `destructive: true`, a card without the field, and every other kind still wait for a person.
 - **Supersede on user comment.** Request kinds default `supersedeOnUserComment` to `false`, so the pending card stays open while the board/user keeps discussing it in ordinary comments. Set `supersedeOnUserComment: true` when a new comment should replace the pending request; it then expires with `outcome: "superseded_by_comment"`, and on that wake you address the comment and create a new interaction if approval is still required.
 - **Withdraw and terminal expiry.** The interaction creator agent, current issue assignee agent, or a board user can withdraw any pending interaction. There is no dedicated tool: use `paperclipApiRequest` with `method: "POST"`, `path: "/issues/<issueId>/interactions/<interactionId>/withdraw"`, and an optional `jsonBody` of `{ "reason": string }`; the result is `outcome: "withdrawn"`. Closing an issue as `done` or `cancelled` expires all remaining pending interactions with `outcome: "issue_closed"` and never wakes the closed issue.
 - **Idempotency.** Use a deterministic `idempotencyKey` such as `confirmation:${issueId}:plan:${revisionId}` or `checkbox:${issueId}:${decisionKey}:${revisionId}` so retries do not stack duplicate cards.