task-listlisted

# List work items A thin, read-only wrapper over `baron_issue_read op=query` that maps everyday words to its normalized filters (`role`, `typeRole`, `assignee`, `limit`). It never mutates anything. ## Token → filter mapping - **Assignee:** `@me` / "mine" / "bana atanan" → `assignee: "@me"`. A bare handle (email/login) → that handle. - **Role:** `in_progress` / "active" / "devam eden" → `role: "in_progress"`; `in_review` / "test" / "review" → `role: "in_review"`; `backlog` / "new" → `role: "backlog"`; `ready` → `role: "ready"`; `done` / "closed" → `role: "done"`. **"blocked" is not a role and not a query filter** — every returned item carries a `blocked` boolean, so answer "what is blocked?" by filtering the results, never by sending `blocked` as a role — the core rejects it. - **Type:** `bugs` → `typeRole: "bug"`; `tasks` → `task`; `stories` → `story`; `epics` → `epic`. - **Sprint:** `sprint` / "this sprint" / "aktif sprint" → `iteration: "@current"` (the active sprint); a literal iteration path → that iteration. On providers without sprints this yields nothing. Filters are AND-combined. `baron_issue_read op=query` returns a lightweight projection (no body); default cap is 50 — pass a higher `limit` only when the user asks for more. ## Steps 1. **Parse** the tokens from the argument (combinable: `@me bugs`, `in_review`, …). 2. **Query.** One `baron_issue_read op=query` call with the mapped filters. `baron_issue_read op=query` takes a single `role`, so if