mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-09-14 23:22:51 +00:00
fbff6f5774
Tool names were string literals matched in several places, which made renaming a tool for one profile unsafe: `tool_category` falls back to `Shell` for an unrecognized name, so exposing `Read` instead of `read_file` would have silently demanded shell-level approval for every file read. Introduce `NativeTool`, the closed set of tools fabro implements, with strum string conversions per the repo convention. A tool is an identity; a name is one rendering of it. `ToolVocabulary` names the renderings -- fabro's own, and Kimi Code's -- and `NativeTool::from_any_name` resolves a name in any vocabulary back to the identity. Permissions, categories, and telemetry go through that resolution, so behavior no longer depends on which profile is running. `known_tool_category` is now an exhaustive match on the enum rather than a string match, so a new built-in tool has to state its category instead of silently inheriting the unknown-tool default. Tools that are uncategorized today stay uncategorized: giving them a category would change the CLI permission gate, which is a behavior change rather than a cleanup. MCP, skill, and run-scoped tools keep arbitrary string names, so `ToolDefinition.name` and the registry keys stay `String`. The enum covers the closed set only. With that in place, the Kimi profile exposes its tools under Kimi Code's vocabulary -- Read, Write, Edit, Bash, Grep, Glob, WebSearch, FetchURL -- and its prompt and tool descriptions use those names. Tools with no Kimi Code counterpart of the same shape keep fabro's names. Ask Fabro's tool policy resolves through the canonical name so a Kimi-model run is not denied its whole tool set. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| migrations | ||
| src | ||
| tests | ||
| build.rs | ||
| Cargo.toml | ||