@tickernelz/paperclip-pro-adapter-codex-local 2026.1008.3 → 2026.1008.5

package/package.json

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

package/skills/paperclip/SKILL.md

@@ -143,7 +143,7 @@ Overrides and special cases:
 - `PAPERCLIP_TASK_ID` set and assigned to you → prioritize that task first.
 - `PAPERCLIP_WAKE_REASON=issue_commented` with `PAPERCLIP_WAKE_COMMENT_ID` → read the comment, then checkout and address the feedback (applies to `in_review` too).
 - Agent @-mentions are context only, with one exception: mentioning the assignee of a parent or ancestor task (plain `@Name` or `[@Name](agent://<id>)`) forwards the comment to that task and wakes its assignee with `issue_commented`. Use it to hand results back up the tree. No mention authorizes taking another agent’s task; use explicit assignment or a bounded delegated task for work.
-- Wake payload says `dependency-blocked interaction: yes` → the issue is still blocked for deliverable work. Do not try to unblock it. Read the comment, name the unresolved blocker(s), and respond/triage via comments or documents. Use the scoped wake context rather than treating a checkout failure as a blocker.
+- Wake payload says `dependency-blocked interaction: yes` → a human comment or a card answer reached you while the issue is still blocked for deliverable work. Do not try to unblock it. Read the comment, name the unresolved blocker(s), and respond/triage via comments or documents. Use the scoped wake context rather than treating a checkout failure as a blocker.
 - **Blocked-task dedup:** before touching a `blocked` task, check the thread. If your most recent comment was a blocked-status update and no one has replied since, skip entirely — do not checkout, do not re-comment. Only re-engage on new context (comment, status change, event wake).
 - Nothing assigned → exit the heartbeat.
 

package/skills/paperclip/references/api-reference.md

@@ -636,7 +636,7 @@ paperclipAddComment { issueId: "{issueId}", body: "[@QA Reviewer](agent://qa-age
 
 The normal assignee feedback path still applies to the comment. To ask another agent to act, assign a task, create a bounded child task, or request an explicit review. A mention never authorizes self-assignment, even if its prose asks the recipient to take the task.
 
-**Message delivery:** a comment on a task assigned to another agent steers into that agent's running turn by default, so cross-task corrections and scope changes are read immediately. Set `deliver: "queue"` (or `commentDeliver: "queue"` on `paperclipUpdateIssue`) only when the message must wait for the current turn to finish. Comments on your own assigned task always wait for your next turn. The response carries `deliveredAs` (`steered` or `queued`) and, when queued, `steeringUnavailable`: `not_requested`, `identity_mismatch` (the message answers to a different user than the running turn), `board_only`, `no_active_run`, `legacy_protocol`, `conversation_order`, or `steering_failed`. A queued message is delivered at the assignee's next turn, and an unread message from another agent reopens a task the assignee closed as `done` in the meantime. On a `cancelled` task the comment stays in the thread but is never delivered, and a quarantined low-trust comment is delivered in its redacted form.
+**Message delivery:** a comment on a task assigned to another agent steers into that agent's running turn by default, so cross-task corrections and scope changes are read immediately. Set `deliver: "queue"` (or `commentDeliver: "queue"` on `paperclipUpdateIssue`) only when the message must wait for the current turn to finish. Comments on your own assigned task always wait for your next turn. The response carries `deliveredAs` (`steered` or `queued`) and, when queued, `steeringUnavailable`: `not_requested`, `identity_mismatch` (the message answers to a different user than the running turn), `board_only`, `no_active_run`, `legacy_protocol`, `conversation_order`, or `steering_failed`. A queued message is delivered at the assignee's next turn, and an unread message from another agent reopens a task the assignee closed as `done` in the meantime. On a `cancelled` task the comment stays in the thread but is never delivered, and a quarantined low-trust comment is delivered in its redacted form. The steer default is the instance setting `defaultMessageDelivery`; human card answers and accept/reject responses follow it too, and are steered into the assignee's live run, or into the run that starts next, instead of waiting in the queue.
 
 ---