[ { "id": "T01", "target": "bestpractice_pdf_to_markdown", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "## Cause\n\nOn Apple Silicon macOS, Docling's **RT-DETR V2 layout-detection model calls `torch.float64`** during the layout detection phase. The **MPS backend does not support `float64`**, so that operation fails and the entire PDF conversion crashes.\n\n## Workaround\n\nPass `--device cpu` to force Docling onto the CPU instead of MPS:\n\n```bash\ndocling input.pdf --to md --device cpu --output output_dir\n```\n\nFor text-only PDFs that don't need OCR, add `--no-ocr` to cut out extra model paths and reduce false recognition:\n\n```bash\ndocling input.pdf --to md --device cpu --no-ocr --output output_dir\n```\n\n## Notes\n\n- **Don't reach for `PYTORCH_ENABLE_MPS_FALLBACK=1` as the first option.** In practice the fallback may still not take effect with certain version combinations; `--device cpu` is more deterministic.\n- If the CPU path still fails, or the PDF is a Chinese-language scan, image PDF, or pitch deck, switch to the **LM Studio VLM OCR** path instead (Docling carries MPS float64 risk for those document types).\n- If you're using the bundled wrapper CLI rather than Docling's official CLI, the equivalent command is:\n ```bash\n python rules/skills/pdf_to_markdown_cli.py docling input.pdf --output output.md --format json\n ```", "error": null, "opened": [ "bestpractice_pdf_to_markdown" ], "requested": [ "bestpractice_pdf_to_markdown" ], "opened_target": true, "prompt_tokens": 29316, "completion_tokens": 627, "sec": 19.542859077453613, "cost": 0.014773600000000001, "web_tools": [], "n_calls": 2, "nudged": false }, { "id": "T02", "target": "mac_universal_clipboard", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "Yes — the item is **`handoff-own-encryption-key`** in Keychain Access. That's the Mac's local Handoff identity key; deleting it forces the Mac to regenerate its own key instead of reusing stale state.\n\nBut note the skill's escalation order puts two cheaper steps ahead of it, and you've already done one:\n\n**Step 1 (done):** Toggle Handoff off/on in System Settings → General → AirDrop & Handoff, and on iOS/iPadOS in Settings → General → AirPlay & Handoff.\n\n**Step 2 (do this first):** Boot the Mac into Safe Mode once, then restart normally. This clears system caches and has historically restored broken Continuity state after macOS updates. Less disruptive than touching Keychain.\n\n**Step 3 — the Keychain reset you asked about:**\n\n1. Open **Keychain Access** (Applications → Utilities, or Spotlight).\n2. Select the **login** keychain in the left sidebar — the Handoff key lives in the local login keychain, not iCloud.\n3. Search for `handoff-own-encryption-key`.\n4. If it doesn't appear, switch the category filter to **All Items** and make sure \"Show expired items\" isn't hiding it.\n5. Right-click the item → **Delete**. Authenticate with your login password when prompted.\n6. Restart Handoff: toggle it off and back on in System Settings → General → AirDrop & Handoff. The Mac will generate a fresh `handoff-own-encryption-key`.\n\n**Step 4 (last resort):** iCloud sign-out/sign-in. This can trigger iCloud Drive, Photos, and Keychain resync, so it's genuinely the heaviest option.\n\nTwo things worth checking before escalating at all, since basic restarts and Handoff toggling didn't help:\n\n- **Confirm the failure pattern.** If iPhone and iPad still sync with each other and only the Mac is isolated, the problem is Mac-side and the steps above are the right track. If *nothing* syncs, the issue is more likely Apple ID / account-level, and the Keychain item won't help.\n- **Run the fast fix first if you haven't.** It's cheaper than the Keychain deletion and often resolves exactly this \"daemons alive but holding stale state\" symptom:\n\n```bash\ndefaults delete ~/Library/Preferences/com.apple.coreservices.useractivityd.plist ClipboardSharingEnabled 2>/dev/null; \\\ndefaults write ~/Library/Preferences/com.apple.coreservices.useractivityd.plist ClipboardSharingEnabled 1; \\\nkillall useractivityd 2>/dev/null; \\\nkillall sharingd 2>/dev/null; \\\nkillall pboard 2>/dev/null; \\\nsleep 2; \\\npgrep -fl 'useractivityd|sharingd|pboard'\n```\n\nYou should see all three processes reappear after launchd restarts them. Then test both directions (iPhone → Mac and Mac → iPhone).\n\nOne caveat: if you're on a **macOS beta build**, treat this as a likely OS regression. The skill explicitly warns against repeatedly applying heavier local changes when symptoms match a beta Continuity bug — in that case the Keychain deletion and iCloud sign-out are unlikely to fix it, and you're better off waiting for the next beta or filing feedback.", "error": null, "opened": [ "mac_universal_clipboard" ], "requested": [ "mac_universal_clipboard" ], "opened_target": true, "prompt_tokens": 27516, "completion_tokens": 1453, "sec": 34.560219049453735, "cost": 0.0149992, "web_tools": [], "n_calls": 2, "nudged": false }, { "id": "T03", "target": "openreview", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "The fix is in the skill's Known Limitations section (item 4):\n\n**Delete the cached token file and retry once:**\n\n```bash\nrm tmp/openreview_token.json\npython tools/openreview_cli.py papers ICLR.cc/2024/Conference\n```\n\nWhy this works: the CLI caches its auth token to `tmp/openreview_token.json` to avoid repeated logins (OpenReview allows only 3 logins per time window). When that cached token expires, the API returns HTTP 403. Removing the file forces the CLI to perform a fresh login using your credentials and write a new token.\n\nA few things to check if the retry still fails:\n\n1. **Credentials are present and correct.** The CLI reads `openreview_email` / `openreview_password` from `.env`, or the `OPENREVIEW_EMAIL` / `OPENREVIEW_PASSWORD` environment variables. A wrong password will also surface as an auth failure.\n2. **Don't loop the retry.** Because of the 3-logins-per-window rate limit, repeatedly deleting the token and retrying can lock you out for the window. Delete once, retry once; if it fails, verify credentials before trying again.\n3. **Run from the project root** so the relative `tmp/` path resolves to the same cache file the CLI uses (and so `.env` is picked up).\n\nThen re-run your original query — e.g. `python tools/openreview_cli.py papers ICLR.cc/2024/Conference -o papers.json` — and it should authenticate cleanly.", "error": null, "opened": [ "openreview" ], "requested": [ "openreview" ], "opened_target": true, "prompt_tokens": 30181, "completion_tokens": 661, "sec": 26.195948123931885, "cost": 0.01492375, "web_tools": [], "n_calls": 2, "nudged": false }, { "id": "T04", "target": "workflow_bilibili_whisper_transcription", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "**2–3 seconds between successive downloads**, with single-threaded (one-at-a-time) downloading.\n\nThat's the specific guidance from the Bilibili batch-download workflow:\n\n> **Single-threaded download** → Download audio one by one, 2-3 second interval between each, to avoid triggering anti-scraping\n\nThe rationale is recorded as a key decision: download concurrency is deliberately **single-threaded** to avoid triggering Bilibili's anti-scraping mechanisms, while transcription is the stage that gets parallelized (4–8 processes, since it's CPU-bound).\n\n### Practical setup for the download phase\n\n- **Concurrency:** 1 (never parallel downloads from the same session/account)\n- **Delay:** 2–3 s between each item\n- **Headers:** send a browser `User-Agent` and a `Referer: https://www.bilibili.com/` header\n- **Format:** audio-only (`-f bestaudio`) to keep requests light\n- **Bookkeeping:** record failed video IDs so you can retry them later rather than re-scanning the whole list\n\n### If you still get blocked\n\nThe 2–3 s interval is the baseline, not a guarantee. Escalation path:\n\n1. **HTTP 352 / 412 errors** → increase the delay, add/refresh User-Agent and Referer headers, or obtain the video IDs manually instead of via the list API.\n2. **412 that persists even with valid browser cookies** → this usually means risk control is blocking the *client fingerprint*, not the cookies. Verify by replaying the same `playurl` call with plain `curl`; if curl gets HTTP 200, switch to the curl-driven HTML5 playurl route (`platform=html5&high_quality=1&fnval=0`) and download the returned CDN URL with the browser UA plus a Bilibili Referer.\n3. **Short links (`b23.tv`)** → resolve them to the canonical `BV...` URL first; passing short links directly can trigger 412 even when the link is valid in a browser.\n4. **404** → video deleted or bad ID; skip and log it.\n\n### Two caveats worth knowing\n\n- The 2–3 s figure is a conservative operator heuristic from this workflow, not a published Bilibili quota. If you're doing a large batch, it's reasonable to pause and inspect failures periodically rather than pushing straight through.\n- Treat any `.info.json` sidecars and expanded Bilibili URLs as private runtime data — they can contain signed CDN URLs, cookies, and `buvid` values. Keep them in ignored runtime directories and never copy them into docs, commits, or public issues.", "error": null, "opened": [ "workflow_bilibili_whisper_transcription", "download_and_transcribe", "source_search" ], "requested": [ "workflow_bilibili_whisper_transcription", "download_and_transcribe", "source_search" ], "opened_target": true, "prompt_tokens": 42552, "completion_tokens": 1175, "sec": 22.175234079360962, "cost": 0.0170878, "web_tools": [], "n_calls": 2, "nudged": false }, { "id": "T05", "target": "playwright_ajax_capture", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "The search results are irrelevant (generic \"reverse engineering\" content). I'll answer from the skill material I have and general API knowledge.\n\n## The core problem\n\nA create response that returns only a `creation_uuid` is almost always an **idempotency/operation handle**, not the resource identity. The real ID is assigned server-side and is usually discoverable in one of a few places. Don't guess — capture the traffic and read the contract.\n\n## Step 1: Capture the full create call and everything after it\n\nUse the `playwright_ajax_capture` approach: intercept **all** fetch/XHR from a logged-in session, not just the create request. Specifically record:\n\n- The create request: method, URL, headers (auth, `Idempotency-Key`, `X-Request-Id`, CSRF), and full body.\n- The create response: status, all headers (especially `Location`, `ETag`, `X-Resource-Id`, `X-Request-Id`), and the full body — including nested objects you may have skimmed past.\n- **Every subsequent request the UI makes** in the seconds after creation. This is the key move: the front end must resolve the ID somehow, so it either calls a follow-up endpoint or reads it from a header.\n\n## Step 2: Look for the ID in these places, in order\n\n1. **Response headers.** `Location: /api/v1/things/` is the classic REST answer. Also check `X-*-Id`, `ETag`, and any `Content-Location`.\n2. **Nested/other fields in the create body.** The ID is often present but not at the top level — e.g. `{\"creation_uuid\": \"...\", \"resource\": {\"id\": 123}}`, or inside `data`, `result`, `item`, `meta`, or an `_links.self.href`.\n3. **A follow-up GET.** Many APIs return a 202-style \"accepted\" envelope with an operation UUID, and the client then polls `GET /operations/` or `GET /things?creation_uuid=` until the resource materializes. Watch the network tab for exactly this.\n4. **A list/search call.** The UI may simply re-fetch the collection and match on a unique field you supplied (name, slug, external key). If so, that's your reliable path — but make the match key genuinely unique.\n5. **The `creation_uuid` itself may be the ID.** Verify before assuming otherwise: try `GET /things/`. Some backends use a UUID as the canonical key and only expose it under that name at creation time.\n\n## Step 3: Make it deterministic, not a race\n\nWhatever you find, wrap it in a resolve step rather than assuming immediacy:\n\n- **Poll with backoff** on the follow-up endpoint until the resource appears (creation is often async). Bound the retries and fail loudly on timeout.\n- **Send your own idempotency key** on the create call if the API supports it, so a retry after a timeout returns the same resource instead of creating a duplicate.\n- **Prefer a server-provided locator** (Location header or operation endpoint) over client-side list matching, which is fragile under pagination and eventual consistency.\n- **Assert the contract**: after resolving, do a `GET` on the real ID and confirm the fields you sent match. That converts \"I think this is the ID\" into a verified fact.\n\n## Step 4: If nothing exposes the ID\n\nThen the create endpoint is genuinely under-specified, and your options are:\n\n- Re-run the capture with the UI's own \"create\" flow and diff the request sequence — the front end is doing *something*, and that something is your answer.\n- Check for a bulk/batch create variant that returns IDs.\n- Fall back to a unique natural key you control (slug, external reference) and use it as the handle for subsequent actions, documenting that the numeric ID is not obtainable from the create response.\n\nThe short version: **capture the whole post-create request sequence, check headers first, then nested fields, then a follow-up GET/poll — and verify the resolved ID with a read-back before using it.**", "error": null, "opened": [], "requested": [], "opened_target": false, "prompt_tokens": 36963, "completion_tokens": 907, "sec": 11.591153860092163, "cost": 0.01608865, "web_tools": [], "n_calls": 1, "nudged": false }, { "id": "T06", "target": "workflow_watchdog", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "**Default: ~30 minutes (1800 seconds).**\n\nThat's the recommended default from the Workflow Watchdog skill: after dispatching a long-running workflow, background agent, or batch sub-agent task, set an inspection wake-up of about 30 minutes rather than waiting in place.\n\n**How to set it, depending on your harness:**\n\n- **Claude Code harness** — use `ScheduleWakeup` with ~1800s.\n- **Other harnesses** — use the corresponding timing mechanism, e.g. Process Launcher's delayed execution (`POST /run` with `delay_seconds: 1800`).\n\n**On each wake-up, check real task state and branch:**\n\n1. **Genuinely busy** — new output is appearing, the agent keeps producing. Leave it alone; wait or set another wake-up.\n2. **Stuck in a loop** — no progress for a long time, the same step retrying repeatedly. Kill it (`TaskStop` in Claude Code), then proceed with partial results or switch methods and redo.\n\n**Two refinements worth knowing:**\n\n- **The 30 minutes is a starting default, not a fixed cron.** The Agentic Patrol pattern prefers a *dynamic* cadence: inspect, decide, then schedule exactly **one** follow-up inspection with a delay appropriate to observed progress. Don't set up a rigid recurring loop.\n- **Judge \"busy vs stuck\" yourself.** Don't ask the user — inspection and kill are technical orchestration decisions you should carry through to the end.\n\n**Practical cautions when scheduling the follow-up:**\n\n- Before scheduling, query for an existing pending job (`GET /scheduled?status=pending&label=