Freshservice workspace_id is silently ignored when combined with filter=new_and_my_open

[krishagel]

Summary

Freshservice's GET /api/v2/tickets endpoint silently ignores the workspace_id query parameter whenever it's combined with filter=new_and_my_open (and likely other predefined filter values) — it returns whatever tickets the predefined view yields regardless of the requested workspace. This affects three places in this repo that use exactly that combination: the psd-triage cloud routine's Step 2 ticket query, the freshservice-manager skill's list_tickets.js script, and that script's documented usage example in SKILL.md.

Discovered during a live triage routine fire (2026-08-28): querying workspace_id=13 (Software Development) with filter=new_and_my_open returned 50 tickets that were all Maintenance-workspace facilities requests (ant bait, water fountains, pole lights) — none of them software bugs. Re-running the identical query with workspace_id=6 (Maintenance) returned the exact same 50 ticket IDs, proving workspace_id had no effect once filter was present. Dropping filter and querying workspace_id=13 alone returned the correct, actual Software Development tickets.

Definition of Done

• routines/triage/routine-prompt.md Step 2 no longer combines workspace_id with filter=new_and_my_open; it either drops filter and filters status client-side, or uses a query mechanism that correctly scopes by workspace
• plugins/psd-productivity/skills/freshservice-manager/scripts/list_tickets.js is fixed so that passing both workspace_id and a predefined filter either works correctly or the script rejects/warns on the combination instead of silently returning results from the wrong workspace
• plugins/psd-productivity/skills/freshservice-manager/SKILL.md no longer documents the broken {"workspace_id": 2, "filter": "new_and_my_open"} example as if it were safe to combine
• Full test suite green; zero lint warnings; typecheck clean (for whichever of these files/scripts have test/lint coverage)
• E2E flow(s) pass — flows: N/A — this is a Freshservice API integration/CLI script and routine-prompt doc, no UI surface to drive with Playwright

Acceptance tests / E2E flows

N/A — no UI surface. Verification should be a manual or scripted call to list_tickets.js (or the fixed routine command) with a real workspace_id + status filter against the live Freshservice API, confirming returned ticket IDs actually belong to the requested workspace (cross-check via GET /api/v2/tickets/{id} → .workspace_id on a sample of results).

Affected areas

• routines/triage/routine-prompt.md (Step 2 ticket-fetch curl command)
• plugins/psd-productivity/skills/freshservice-manager/scripts/list_tickets.js
• plugins/psd-productivity/skills/freshservice-manager/SKILL.md (List Tickets example)

Out of scope

• Any other Freshservice filter values not yet confirmed broken (only new_and_my_open was empirically tested here)
• Broader freshservice-manager script coverage beyond list_tickets.js

Risk & rollback

• Risk: low — this is a query-construction fix in scripts/docs, not a schema or infra change.
• Rollback: revert the commit; no state migration involved.

How this was found

Live run of the psd-triage cloud routine on 2026-08-28. The routine's own Step 2 command (workspace_id=13&filter=new_and_my_open) returned 50 Maintenance-workspace tickets (ants, water fountains, pole lights — nothing software-related). Cross-checking workspace_id=6 with the same filter returned identical ticket IDs, confirming workspace_id was being silently dropped. The routine worked around this in-session by re-querying with workspace_id=13 alone (paginating, then filtering status client-side to Open/Pending), which correctly returned Software Development tickets. That workaround is not yet reflected in the stored routine prompt, so every future fire will repeat the same broken query unless this is fixed.

Filed by the psd-triage routine as a self-diagnosed bug in its own tooling, not from a FreshService ticket — no FS# reference applies.