v2.6.10

Command analysis can now be extended to shell tools that no integration knows about, so commands run through a plugin's own shell tool are gated like built-in shell commands instead of passing as an unknown tool.

Added

• Added command_tools to rule.json: exact tool names whose command argument is analyzed like a built-in shell tool. A declaration applies only to a tool the integration routed as unknown and only when the input carries a non-empty string command, it is evaluated at your own safety level, and an allowed call is audited with its command and working directory. User and project lists merge, and the user entry wins a name declared in both. (#243, #242)
• Added a per-declaration working-directory argument — { "name": "ops_run_background", "cwd": "cwd" }, or workdir, cwd, or working_directory when unspecified. An omitted argument uses the session workspace; a blank, non-string, conflicting, or nonexistent-directory value is denied.
• Added cc-safety-net rule tool add <name...> [--cwd-arg <name>] [--project], rule tool remove <name...> [--project], and rule tool list to manage declarations without editing rule.json by hand. add and remove default to the user scope and print the scope and file written; list shows each entry's scope and working-directory argument. (#244)
• Added a refusal for declaring a tool that is already analyzed: rule tool add rejects a name that matches any integration's built-in shell tool — naming those integrations — or a built-in file tool, and rule verify reports such a name in either scope's rule.json.
• Added command_tools to the published JSON Schema (assets/cc-safety-net.schema.json) so editors complete and validate the field.