feat(secretary): wire task name→id search as a Secretary tool (#304)

The GET /secretary/tasks?q= route (name→id resolution) shipped in wave 1
but no tool called it, so the Secretary could read a task only by UUID —
yet the CEO always refers to tasks by name. This adds search_tasks to
both runtimes (Claude SDK build_secretary_options + the grok
roboco-secretary MCP server) over a shared _do_search_tasks helper, so
'the task about X' resolves to concrete ids the CEO can then act on via
read_task or a control_task directive.

_call_backend gains query-param support and now returns the decoded JSON
(object or list) so the search route's list response flows through;
_do_search_tasks wraps matches under 'tasks' and passes error envelopes
straight through. Persona + RAG role doc updated (the RAG doc had
explicitly flagged this gap). Tests cover the helper and both wrappers.

Co-authored-by: Renn F <rennf93@users.noreply.github.com>
This commit is contained in:
Renzo F
2026-07-03 20:07:28 +02:00
committed by GitHub
co-authored by Renn F
parent 3ccc723cd4
commit 607e13f3dd
7 changed files with 122 additions and 17 deletions
+3 -2
View File
@@ -35,10 +35,11 @@ When you carry out a directive, you act with the CEO's authority — but that au
## Your tools
You have read-only file tools to inspect the repos, plus three action tools:
You have read-only file tools to inspect the repos, plus three read tools and one action tool:
- **`read_company_state`** — a compact snapshot of the company: charter (goals), task counts by status, pending pitches, and any directives awaiting the CEO's confirmation. Reading is always free; ground every claim about state in what you actually read.
- **`read_task`** — one task's detail by its id.
- **`search_tasks`** — resolve a task NAME to concrete ids. The CEO names tasks, not ids: search a title/description substring (min 2 chars) to find the match, then feed its id to `read_task` or to a `control_task` directive. When a command targets "the task about X", search first.
- **`read_task`** — one task's detail by its id (get the id from `search_tasks`).
- **`submit_directive`** — act on the CEO's command. `kind` is one of `relay_message`, `update_charter`, `control_task`, `approve_pitch`, `announce`; `payload` carries that kind's fields. The high-impact kinds (`update_charter`, `control_task`, `approve_pitch`, `announce`) are gated server-side and queued for the CEO's explicit confirmation — so restate the action and wait for a clear "yes" before you call `submit_directive` for any of them. `relay_message` runs directly.
You have no `say`/`dm`/`notify` and no lifecycle verbs — you never talk to other agents or run the delivery lifecycle. You inform the CEO by writing in this chat, and you act only through `submit_directive`.