Why the hybrid CWM does not beat the interpreter: the diagnosis

before the verdict:
[Coding world model] Your command was NOT executed. A reward model graded your current change (git diff) against review criteria. Below: the predicted reward, then every applicable criterion with its reward (1 = satisfied, 0 = violated).

after the last criterion:
Treat each [reward 0] criterion as feedback on your code: locate where it applies in this repository (grep, cat and sed -n run for real) and edit the code to satisfy it, unless it clearly does not apply to this task. Running code again only re-grades the same change; edit first.

[Coding world model] Your command was NOT executed. A reward model graded your current change (git diff) against review criteria. Below: the predicted reward, then every applicable criterion with its reward (1 = satisfied, 0 = violated).

Predicted reward: 0.00 (3 applicable criteria)

[reward 0]
### The change does not implement the behavior the task requires
- **Applies when**: always -- this criterion is derived from the task statement itself.
- **Pattern**: The diff does not make the behavior described in the task actually happen:
  it edits the wrong location, changes something adjacent to the reported symptom, only
  adds tests/scripts/logging, or handles a different case than the one reported. Apply the
  diff mentally and ask whether the exact symptom described in the task would still occur.
- **Detection procedure**:
  1. From the task statement, state the concrete before/after behavior being requested
     (the call that misbehaves and what it should do instead). [reads: task]
  2. Locate the lines in the diff that would change that behavior. If no hunk lies on the
     execution path of the reported call, the criterion fires. [reads: code]
  3. If a hunk is on that path, check that it produces the requested behavior for the
     reported input -- not merely that it removes an exception or renames something.
- **Discriminator**: fires when the reported symptom survives the patch; does not fire when
  the diff demonstrably changes the reported behavior to what the task asks for.
- **Consequence**: the task's own failing test still fails; the submission is scored wrong.

[reward 0]
### Library behavior changed but verified only by throwaway scripts outside the project's test directory
- **Applies when**: `task|code`: the task asks for a source change in a repository whose static facts list a dedicated test directory containing a test module for the source file being modified.
- **Pattern**: The program edits the library source and adds verification as new top-level scripts (print/assert `__main__` runners, patch-applier scripts that rewrite source files by string replacement, summary markdown), while adding no case to the repository's existing test module for the changed code.
- **Detection procedure**:
  1. List the files the program creates or modifies and identify which are under the repository's test directory. [reads: code]
  2. Compare against the static facts repo tree: does a test module exist that corresponds to the modified source module? [reads: static facts — repo tree]
  3. It fires when the modified source file has a corresponding test module in that directory, none of those test files are touched, and the new files are repo-root scripts containing module-level statements or `if __name__ == "__main__":` runners, or scripts that open the source file and `content.replace(...)`/write it back. [reads: code]
- **Counter-example**: a program that adds or extends test functions inside the repository's existing test module (even if it also leaves one scratch script), or a repository whose static facts show no test directory at all.
- **Discriminator**: the new behavior has zero coverage in the collected suite — the only assertions live in files that the project's test discovery configuration does not target, so a green suite proves nothing about the change.
- **Consequence**: regressions introduced by the edit (removed checks, changed types) go undetected and hidden/maintainer tests for the changed behavior fail; additionally, root-level files named `test_*.py` that execute code at import are collected when pytest is run from the repository root, producing collection-time `AssertionError`/`ImportError`/`SyntaxError` and non-zero exit. Explains the discrepancy between a fully passing run and a semantically wrong patch; the remaining risk comes from the substantive defects in the edit itself.
- **Evidence**: the source module was edited while its sibling test module in the project's test directory was left untouched; verification consisted of `fix.py`/`fix2.py`/`fix3.py`/`fix4.py` string-replacement patchers and several root-level `test_*.py` print-and-assert scripts, and the reported `2386 passed` covered none of the new behavior.

[reward 0]
### Bug fix gated on a data-dependent label lookup instead of the declared argument
- **Applies when**: `task`: the task is a bug report with a reproducer in which a library API raises on input the reporter considers valid, and `code`: the patch adds a new conditional in front of the previously failing code path.
- **Pattern**: The repair is implemented as a runtime guess — the new branch inspects the *contents* of the object being operated on (e.g. builds sets of two competing label namespaces and intersects them with the user-supplied keys) to decide which of two incompatible semantics to apply — instead of deciding from the explicit argument that names the semantics. The corrected path therefore fires only for inputs where the two namespaces happen not to overlap; every other input silently falls through to the original faulty code.
- **Detection procedure**:
  1. Locate the conditional block added immediately before the statement that produced the reported failure (the transpose, the re-dispatch, the lookup that raised) [reads: code]
  2. Compare the condition's inputs against the argument the task's reproducer actually passes: does the condition read only the explicit flag/argument, or does it also read runtime containers of the operand (its index labels, column labels, key sets, dtypes) [reads: task statement (the reproducer call and its arguments) + code]
  3. Check the fall-through: is the `else`/unguarded continuation byte-for-byte the original failing path, and can an input of the same shape as the reproducer fail the guard — e.g. one key present in *both* namespaces, or only a subset of keys matching, making the intersection test false [reads: code]
- **Counter-example**: A branch that dispatches on the explicit parameter (`axis`, `how`, a type check on `func`) and keeps the old path only for genuinely different argument kinds, so every input matching the reported scenario takes the new path regardless of what labels the data carries.
- **Discriminator**: In the failing case, whether the fix applies depends on incidental overlap between two label collections in the user's data; in the safe case the dispatch is decided entirely by arguments and types, independent of the data values.
- **Consequence**: The exact reproducer passes while near-identical hidden cases still raise the original exception (`KeyError`, or the library's lookup error) — e.g. a frame whose index labels coincide with its column labels, or a dict covering only some labels. Predict partial credit at best: reproducer-only tests pass, parametrized/edge-case tests for the same API fail.
- **Evidence**: `func_keys = set(func.keys()); ... if len(func_keys) == len(keys_in_columns) and len(keys_in_index) == 0: return self.transform_dict_like(func)` — a guess between "keys are columns" and "keys are row labels" that reverts to the old raising path whenever any key also appears in the other axis.

Treat each [reward 0] criterion as feedback on your code: locate where it applies in this repository (grep, cat and sed -n run for real) and edit the code to satisfy it, unless it clearly does not apply to this task. Running code again only re-grades the same change; edit first.