coding

First reproduce the failure and read the actual output, then locate the code with grep or semantic search, edit with exact-string replacement, and run the full test suite. Never claim a fix works without executing the tests that prove it.

Use grep (search_file_content) when you know an exact string like a function name or error message, since it is instant and exhaustive. Use the semantic code index when you know the behavior but not the name, after running index_codebase once for the repo.

edit_file fails when the target string does not exactly match the file contents, meaning your view of the file is stale or wrong. Re-read the file instead of retrying with guesses, and never rewrite the whole file to bypass a failed edit.

No, the pytest grant is deliberately narrow. Flags like --pdb, -p for plugin loading, and --junitxml are refused because they hang, import arbitrary code, or write outside the run. For npm, go, or make suites, use run_python instead.

The main risks are unverified changes, overly broad diffs, and edits made from memory rather than the actual file. This workflow mitigates them by requiring reproduction before fixes, full-suite runs after changes, and honest reporting when tests cannot be executed.