| Age | Commit message (Collapse) | Author |
|
kaakaa reminds too many Europeans of shit. 😅
|
|
It makes little sense for a tool kind to be a function of the tool
call arguments.
|
|
|
|
Incidentally, this refactor fixes a bug whereby agent requests would
be registered even when tool calls were pre-approved/pre-rejected and
no permission requests were sent out.
|
|
|
|
|
|
|
|
This is becoming a hodge-podge of arguments passed in to slash
commands. We need a more principled approach in the future.
|
|
|
|
|
|
We store a list of allowed and rejected tools in the session state,
and pass it on to spec->tool-call so it can set an appropriate tool
call status.
Then, request permission from the client only if the tool call hasn't
been pre-approved or pre-rejected.
|
|
|
|
Refactor permission selection decoding to be less tightly coupled to
the JSON from the client.
|
|
In a tool_call_update, the content field must be a vector of
association lists, not just an association list.
|
|
It is enough to send the tool title, kind and rawInput the first time
when the tool call is created. There is no need to send these fields
repeatedly in subsequent updates. Subsequent updates need only mention
fields that have actually changed.
|
|
A sessionUpdate of "tool_call" must only be sent when the tool call is
created. Further updates must send a sessionUpdate of
"tool_call_update".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Report tool call parse failures immediately to the LLM without
bothering the client with permission requests; only notify the client.
|
|
We process tool calls one at a time using a new function
next-state-tool-call. We refactor next-state-llm-response to use
next-state-tool-call.
|
|
In doing so, we also change state->llm-request to state->llm-requests.
The new function now returns a list of <llm-request> objects rather
than a single one.
|
|
|
|
|