feat(witan): free-text search for witan projects and witan tasks

[blarghmatey]

What are the relevant tickets?

N/A

Description (What does it do?)

Finding a project or task from the CLI meant paging through the whole list, even though the server already exposes BM25 search as workflow_project_search and task_search. This adds an optional positional query to both listing commands, e.g. witan projects gravitino or witan tasks 'grafana dashboard'. Results come back in relevance order, and the existing flags (--status, --repo, --all-repos, --project, --assignee, --ready, --limit) still apply.

It also fixes witan tasks --ready --status X, which ignored --status because task_ready takes no status (so --ready --status open also listed blocked tasks whose blockers had closed). Both the search and listing paths now filter the same way.

Releases witan-council 0.36.0, so this publishes on merge.

Implementation details

• projects calls workflow_project_search instead of workflow_project_list when a query is given. Both take the same repo/status arguments.
• tasks filters the search hits on the fields they carry (status, project_slug), hiding closed tasks unless --status is passed, the same as the plain listing. --ready and --assignee are checked against task_ready/task_list, because readiness and @me only resolve on the server.
• The first version checked every hit against task_list, and it came back empty for witan tasks --all-repos 'grafana dashboard' against the deployed server while task_search had 20 hits. With no repo in scope, task_list reads list_all_tasks, which ends in limit 50 (read.gq), so any match older than the 50 most recently updated tasks was dropped. test_tasks_query_finds_tasks_older_than_the_recent_window covers this.
• Search rows don't include blocked_by, so search output leaves it out instead of printing it blank, in both the table and --output-format json|yaml|toml (which dumps the row dicts, not the columns). The status column still shows blocked.
• task_ready truncates server-side, so when --status or a query filters its result client-side the CLI asks it for every ready task first.
• The projects and tasks docstrings moved to the indented numpydoc form cyclopts parses. The one-line name: desc form showed only continuation lines in --help. docs/reference/cli.md is regenerated.

How can this be tested?

• uv run --isolated --package witan-council --group test pytest mcp/servers/witan on the rebased head: 1199 passed, 1 skipped. New tests in tests/test_cli.py cover ranking with closed-task elision, --status closed, the no-match message, a match older than 51 newer tasks under --all-repos, --ready --status open with and without a query, JSON search output without blocked_by, and project search.
• ./bin/gen_docs.py --check, just check-versions, just check-core-floor, and uv lock --check pass.
• Run against the deployed server: witan tasks --all-repos 'grafana dashboard' returns the open StarRocks and in-progress ClickHouse observability tasks with closed matches hidden. witan projects omnigraph returns 4 active projects. witan tasks --ready omnigraph returns ready tasks. witan projects gravitino prints "No projects matching 'gravitino'"; workflow_project_search with repo="" and status=None returns 0 rows for that query, so that's correct.

Additional Context

• The server caps each search at 20 hits before --ready, --assignee or --project filter them, so a narrow filter can miss a lower-ranked match.
• --assignee combined with a query and --all-repos is still subject to the 50-row cap, tracked in tk-witan-tasks-all-repos-and-status-listings-are-si-faf47c (comment added with this case).
• Follow-ups filed under wp-witan-service-quality-and-maintenance-f5ad70: tk-witan-projects-has-no-way-to-list-or-search-ever-60471c (--status '' is rejected by the server, so there's no way to ask for every status), tk-most-witan-cli-help-output-drops-parameter-descr-155897 (the docstring format in the rest of the CLI), and tk-structured-cli-output-carries-rich-escaped-title-16403a (a query containing [ shows up Rich-escaped in the JSON/YAML/TOML title).

🤖 Generated with Claude Code

https://claude.ai/code/session_01SFRYTsWVvNq32z75QjgjzC

[Copilot]

🟡 Changes recommended

Both new searches fail in guarded local-fallback mode because their tools are absent from the read allowlist.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds relevance-ranked free-text search to project/task CLI listings and fixes ready-task status filtering.

Changes:

• Adds optional search queries while preserving listing filters.
• Adds CLI coverage and regenerated reference documentation.
• Releases witan-council 0.36.0.

File summaries

File	Description
mcp/servers/witan/witan/cli/tasks.py	Adds task search and status-aware readiness filtering.
mcp/servers/witan/witan/cli/projects.py	Adds project search.
mcp/servers/witan/tests/test_cli.py	Tests search, filtering, ranking, and output.
docs/reference/cli.md	Documents new query arguments.
mcp/servers/witan/CHANGELOG.md	Records the release changes.
mcp/servers/witan/pyproject.toml	Bumps the package to 0.36.0.
uv.lock	Updates the locked workspace version.

Review details

• Files reviewed: 6/7 changed files
• Comments generated: 2
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.