Codex
1. End-to-end result: inconclusive on the advertised success path, because the IDE server stopped servicing `steroid_execute_code` before I could run the actual recipe. What I did verify: `steroid_list_projects` succeeded once and exposed `ApplyPatchRecipeEvaluation`; `steroid_fetch_resource` returned the full `mcp-steroid://ide/apply-patch` recipe; three read-only `steroid_execute_code` probes ran and showed the evaluation project was empty (`children=0`, `COUNT=0`). I then attempted to create a small in-project fixture so I could exercise a realistic 3-5 hunk patch. Two setup executions, followed by a trivial `println("ping")`, all failed with the same tool-level error: `timed out awaiting tools/call after 120s`. After that, even `steroid_list_windows` and a second `steroid_list_projects` timed out, so I could not complete the success case or the requested runtime failure simulations. The strongest evidence here is not “the patch recipe failed”, but “the surrounding execution path became unusable before the recipe could be executed.”
2. Defaults: mostly sensible on paper. The pre-flight uniqueness check is correctly strict for an atomic literal patcher: it prevents ambiguous edits and guarantees “all or nothing” before entering `WriteCommandAction`. For real-world repeated literals, though, it is ergonomically strict enough that callers will spend time inflating `old_string` context by hand. The descending-offset sort per file is correct and necessary; that part of the recipe is sound. The success message is only moderately useful. `apply-patch: N hunks across M file(s)` plus per-file counts confirms breadth, but it does not identify which literals matched or where, so it is weak as an audit trail after a large batch edit.
3. Ergonomics: the recipe block itself is about 90 lines of Kotlin as published, and roughly 4-5 KB of `code` payload once copied into `steroid_execute_code` with real hunks filled in. A hand-written alternative using `WriteCommandAction`, per-file string replacement, and `VfsUtil.saveText` would likely be shorter in raw code for a one-off task, around 50-65 lines and perhaps 3-4 KB, but it would force the caller to re-derive atomicity, ordering, and validation. So the savings are mostly cognitive and correctness-oriented, not payload-oriented. In other words: good recipe if it runs, but it is not especially compact.
4. Failure modes: I cannot honestly claim to have simulated the two requested runtime failure paths (`old_string` absent`, `old_string` repeated`) because the server stopped executing code before I reached that stage. From the recipe text alone, both should fail cleanly during pre-flight via `require(...)`, before any edit is applied. The error strings are actionable: “verify with Grep first” for absent text, and “expand old_string with surrounding context” for non-unique text. That is good guidance. What I could not verify in this environment was the important part: whether partial state truly remains untouched in practice.
5. Suggested edits to `prompts/src/main/prompts/ide/apply-patch.md`:
- Add a tiny “bootstrap fixture” example for empty projects. Symptom: my evaluation project had no files, so the first substantive work was creating test data rather than exercising `apply-patch`. Expected effect: faster validation in sterile projects and less setup drift.
- Add an adjacent `try/catch { printException(...) }` wrapper variant for evaluation/debug runs. Symptom: once execution started timing out, the recipe gave me no structured diagnostic path to distinguish pre-flight failure, write-action failure, or IDE hang. Expected effect: better observability and faster recovery.
- Expand the success output to include either matched `old_string` snippets or resolved offsets per hunk. Symptom: the current success text would confirm counts, but not enough detail to prove the intended sites were the ones changed. Expected effect: stronger post-run auditability, especially for 4+ hunk edits.
Bottom line: the recipe’s design is credible, but I could not validate it end-to-end in this run because the IntelliJ MCP execution path became unresponsive before the patch scenario could be executed.