The kai tool took kai_url from the call and sent HANZO_API_KEY to it,
with the repository's file names, branches and commit subjects. A
model, or text it read, could name any host. The URL is now
HANZO_API_BASE (or api.hanzo.ai) plus /v1, in the Rust tool and the
TypeScript one alike, and kai_url is gone from the schema.
kai is one action-routed tool (run, plan, list, triggers) over
hanzo-actions. run matches the request to an action or workflow, binds
its inputs, checks the preconditions, runs, and returns the ledger:
outcome done, failed or declined, and a record per step with its source
(rule or kai), preconditions, authorization, cache use, steps, timing and
the verifier's verdict. A declined request is the caller's own agent's.
Authorization is the call's: an action that writes outside the workspace,
reaches a remote or stops a process runs only with approve=true, so the
client's own approval flow decides. An action with no recorded proof
here does not run unless the call says it is proving its workspace.
One schema, schema/kai.json, the same text in rust/schema/ and in
src/tools/kai-action.ts; a test fails if the three differ. The work is
not written twice: the TypeScript tool runs the native binary named by
HANZO_MCP_NATIVE, and `hanzo-mcp kai run|plan|list|triggers` is that
binary's command line (exit 0 done, 2 declined, 3 failed).
The tool's test now proves its workspace and asserts the first refusal
is the approval and that the push reaches the remote only after the
grant; before it passed the proof gate's refusal off as the approval's.
zeekay