CoreRasurae
71ef7e44a2
CI / lint (pull_request) Failing after 1m5s
CI / build (pull_request) Successful in 1m0s
CI / typecheck (pull_request) Successful in 1m16s
CI / security (pull_request) Successful in 1m17s
CI / quality (pull_request) Successful in 1m24s
CI / integration_tests (pull_request) Successful in 2m45s
CI / unit_tests (pull_request) Successful in 4m54s
CI / coverage (pull_request) Has been skipped
CI / status-check (pull_request) Failing after 7s
CI / benchmark (pull_request) Failing after 23m5s
The python_exec tool's LLM-facing schema description, and the _execute_python_code NameError guidance message, both still told the model to "use the file_read and file_write tools" for file operations -- stale advice from before read_file/write_file existed in this same sandbox. Since those two callables are now always bound in every inline-code body (including python_exec, which shares the identical _execute_python_code sandbox construction), the hints now point at calling them directly instead of reaching for a separate tool. While updating the docs to match, found that docs/tools/safe-mode.md and docs/tools/built-in-tools.md incorrectly described python_exec as running in a sandbox "distinct" from inline-code tools with its own, smaller builtins list -- ToolAgent._python_exec_tool has always delegated straight to _execute_python_code, the exact method inline-code tools use. Corrected both pages to describe the one shared sandbox and its actual, complete builtins list (including locals, the four error types, and read_file/ write_file), rather than perpetuating two sandboxes that don't exist. Verified with the project-pinned behave==1.3.3: tool_coverage_gaps.feature, inline_sandbox_import_restriction.feature, and inline_code_file_helpers.feature all pass (114 scenarios, 362 steps), including the exact scenario that asserts the NameError message substring. mkdocs build --strict is clean. Refs: #93