@tickernelz/paperclip-pro-adapter-codex-local 2026.1007.1 → 2026.1007.2

package/package.json

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

package/skills/openwa/SKILL.md

@@ -11,7 +11,8 @@ 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`. The run
+`openwa_endpoint_config`, `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.
 
@@ -288,10 +289,15 @@ they never wake you. Owner-run guidance names them by label.
   the numbers and the chats the board allowed on each.
 - `openwa_linked_read({linkedRef, chat, limit?, cursor?})` reads one allowed chat
   live, newest first, in the same message shape as `openwa_read_chat` (sender
-  numbers masked, media metadata only). `chat` is a `chatRef` from
-  `openwa_linked_list` or that chat's id. Page with `nextCursor`.
-
-Both work only in owner-triggered runs; every other run gets `owner_only`. A
+  numbers masked, media metadata only: a media message has `media.kind`). `chat`
+  is a `chatRef` from `openwa_linked_list` or that chat's id. Page with
+  `nextCursor`.
+- `openwa_linked_get_media({linkedRef, chat, messageId})` stores one message's
+  file from an allowed linked chat as a task attachment and returns the same
+  `media` shape as `openwa_get_media`; read its `localPath`. `openwa_get_media`
+  refuses linked chatRefs. `not_found` means the gateway has no stored copy.
+
+All three work only in owner-triggered runs; every other run gets `owner_only`. A
 chat the board did not allow fails `linked_chat_not_allowed`: tell the owner to
 allow it in Paperclip Settings, Linked numbers. Use them only when an owner asks,
 and do not copy their content anywhere unless the owner asks. Linked content is

package/skills/paperclip/SKILL.md

@@ -276,7 +276,26 @@ A "watcher" or "monitor" is not something that lives inside a run. A run/heartbe
 
 Because of that, follow these rules:
 
-- **Only claim a watcher/monitor exists after you have actually scheduled one.** Describing a watcher in a comment does not create it. Schedule it by setting `advanced.executionPolicy.monitor.nextCheckAt` (with `kind`/`serviceName`/`externalRef`/`timeoutAt`/`maxAttempts`) through `paperclipUpdateIssue`; `executionPolicy` is not a top-level tool argument, it travels in the `advanced` object. Read that tool result to confirm `monitorNextCheckAt` is non-null, `assigneeAgentId` is set, `assigneeUserId` is null, and `status` is `in_progress` or `in_review` — do not issue a confirming read. The stored timestamp only fires under those conditions. Run a check on demand with `paperclipCheckNowIssueMonitor`, available when the operator enables `PAPERCLIP_MCP_TOOLSETS=full`; otherwise use `paperclipApiRequest` with `method: "POST"`, `path: "/issues/<issueId>/monitor/check-now"`.
+- **Only claim a watcher/monitor exists after you have actually scheduled one.** Describing a watcher in a comment does not create it. The one way to schedule it is `paperclipUpdateIssue` with `advanced.executionPolicy.monitor.nextCheckAt` (optionally `kind`/`serviceName`/`externalRef`/`timeoutAt`/`maxAttempts`/`notes`):
+
+  ```json
+  {
+    "issueId": "PAP-42",
+    "status": "in_review",
+    "advanced": {
+      "executionPolicy": {
+        "monitor": {
+          "nextCheckAt": "2026-10-08T09:00:00.000Z",
+          "kind": "external_service",
+          "serviceName": "GitHub Actions",
+          "notes": "Re-check CI run 1234"
+        }
+      }
+    }
+  }
+  ```
+
+  The raw form is `PATCH /api/issues/{issueId}` with body `{ "executionPolicy": { "monitor": { "nextCheckAt": "..." } } }`. `executionPolicy` replaces the whole stored policy, so copy any existing `stages` from the issue into the same object. A top-level `monitorNextCheckAt` or `monitor` argument is rejected (`misplaced_issue_monitor_field`); `monitorNextCheckAt` is the read-only result field. `paperclipSetIssueWatchdog` does not schedule a monitor: it assigns a watchdog agent that reviews the subtree after it stops. Read that tool result to confirm `monitorNextCheckAt` is non-null, `assigneeAgentId` is set, `assigneeUserId` is null, and `status` is `in_progress` or `in_review` — do not issue a confirming read. The stored timestamp only fires under those conditions. Run a check on demand with `paperclipCheckNowIssueMonitor`, available when the operator enables `PAPERCLIP_MCP_TOOLSETS=full`; otherwise use `paperclipApiRequest` with `method: "POST"`, `path: "/issues/<issueId>/monitor/check-now"`.
 - **Describe it in checkable terms.** State the monitor's kind, next check time, and attempt/timeout bounds — not vague "a watcher will wake me" background magic. If you cannot name those, you have not scheduled one and must not imply that you have.
 - **Never imply a live watcher on a task you are marking `done`.** `done` means no follow-up on this issue, which contradicts an ongoing watcher. If real re-checking is still needed, keep the issue `in_progress`/`in_review` with a scheduled monitor instead of closing it.
 - This is enforced by state, not by narration: the disposition guard rejects an agent move to `in_review` (`invalid_issue_disposition`) unless a real review path exists — an open blocking issue, interaction, approval, human reviewer, typed participant, or an actually-scheduled monitor with a real `monitorNextCheckAt` — and the recovery classifier flags `in_review_without_action_path` for anything parked with no live wake path. Keep your comments consistent with that real state.
@@ -701,7 +720,8 @@ If `plan` already exists, first call `paperclipGetDocument` (`issueId`, `key: "p
 | Upload attachment (multipart, `file`) | none — use the upload helper                                                                                                                                      |
 | List / delete attachment              | `paperclipListIssueAttachments` • `paperclipDeleteAttachment`                                                                                                     |
 | Execution workspace + runtime         | `paperclipGetIssueWorkspaceRuntime` • `paperclipControlIssueWorkspaceServices` • `paperclipWaitForIssueWorkspaceService`                                           |
-| Monitors / watchdog                   | `paperclipGetIssueWatchdog` • `paperclipSetIssueWatchdog`                                                                                                         |
+| Schedule issue monitor                | `paperclipUpdateIssue` with `advanced.executionPolicy.monitor.nextCheckAt`                                                                                        |
+| Task watchdog agent                   | `paperclipGetIssueWatchdog` • `paperclipSetIssueWatchdog`                                                                                                         |
 | List agents                           | `paperclipListAgents` • `paperclipGetAgent`                                                                                                                       |
 | Dashboard                             | `paperclipDashboard`                                                                                                                                              |
 | Credentials and secrets               | none — `paperclipApiRequest`                                                                                                                                      |

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

@@ -1441,8 +1441,9 @@ Tools marked extended load only when the operator enables `PAPERCLIP_MCP_TOOLSET
 | List recorded work products | `paperclipListIssueWorkProducts` | `issueId` |
 | Record an operator-facing work product | `paperclipCreateIssueWorkProduct` | `issueId`, work-product fields |
 | Update a recorded work product | `paperclipUpdateWorkProduct` | `workProductId`, changed fields |
-| Read the issue monitor/watchdog configuration | `paperclipGetIssueWatchdog` | `issueId` |
-| Schedule or clear the issue monitor | `paperclipSetIssueWatchdog` | `issueId`, watchdog fields |
+| Schedule the issue monitor (`monitorNextCheckAt`) | `paperclipUpdateIssue` | `issueId`, `advanced: { "executionPolicy": { "monitor": { "nextCheckAt": "2026-10-08T09:00:00.000Z", "notes": "Re-check CI" } } }` |
+| Read the task watchdog (the agent that reviews a stopped subtree; not the monitor) | `paperclipGetIssueWatchdog` | `issueId` |
+| Assign or replace the task watchdog agent | `paperclipSetIssueWatchdog` | `issueId`, `agentId`, optional `instructions` |
 | Current execution workspace, runtime services and service URLs | `paperclipGetIssueWorkspaceRuntime` | `issueId` |
 | Execution workspace detail | `paperclipGetExecutionWorkspace` | `executionWorkspaceId` |
 | Start, stop, or restart workspace runtime services | `paperclipControlIssueWorkspaceServices` | `issueId`, `action` (`start`, `stop`, `restart`), `runtimeServiceId`, `serviceIndex`, `workspaceCommandId` |

package/skills/paperclip/references/cases.md

@@ -80,9 +80,20 @@ List cases for a company with `paperclipListCases`:
 { "type": "blog_post", "status": "active", "q": "launch" }
 ```
 
+Look up one case by its upsert identity with `caseType` and an exact `key`:
+
+```json
+{ "caseType": "deploy", "key": "deploy:api:2026-10-07" }
+```
+
+The raw form is
+`GET /api/companies/{companyId}/cases?caseType=deploy&key=deploy:api:2026-10-07`.
+It returns an array with zero or one case.
+
 Useful arguments:
 
-- `type` / `types`: exact `caseType`
+- `type` / `caseType` / `types`: exact `caseType`
+- `key`: exact case `key`
 - `status` / `statuses`: exact lifecycle status, or `active` for non-terminal cases
 - `projectId` / `project`: project UUID
 - `labelId` / `label`: label UUID
@@ -117,9 +128,27 @@ Updating an existing case document requires `baseRevisionId`:
 }
 ```
 
+The raw route is `PUT /api/cases/{caseId}/documents/{key}`. Its body takes the
+same `baseRevisionId` rule: omit it only when the document does not exist yet,
+and send the current `latestRevisionId` from
+`GET /api/cases/{caseId}/documents/{key}` on every update:
+
+```json
+{
+  "method": "PUT",
+  "path": "/cases/PAP-C42/documents/body",
+  "jsonBody": {
+    "baseRevisionId": "latest-revision-uuid",
+    "format": "markdown",
+    "body": "Updated body"
+  }
+}
+```
+
 If the tool reports `stale_base_revision`, refetch the case detail, read the
 latest document revision id, merge intentionally, and retry with that
-`baseRevisionId`. A failed call wrote nothing — do not treat it as saved.
+`baseRevisionId`. The 409 body already carries `latestRevisionId`. A failed
+call wrote nothing — do not treat it as saved.
 
 ## Fields