### Inputs
You will be given:
- A Python function from a repository
- A specific line within the function
- State differences at that line before and after the patch
- Complete variable states before and after the patch (serialized)

Function:
{code}

Line:
{line}

State Differences:
{diff}

Complete Variable States Before and After the Patch:
Before:
{before}

After:
{after}

### Task
You are designing Python expressions `<expr>` to probe a code change.

Another LLM will later be given several candidate expressions, including your `<expr>` outputs, and asked to choose which ones produce different evaluation outcomes before and after the patch.

These expressions will be used as a multiple-choice question (MCQ):
- Expressions that change between buggy and patched executions are the correct options.
- Expressions that do NOT change act as distractors.

Evaluation context:
- Each `<expr>` is evaluated at the specified line within the function, in that line’s local scope.
- Variable bindings correspond to the runtime local scope at the specified line; the provided “Complete Variable States” are a partial serialization of selected variables for guidance, not an exhaustive list of all locals.
- Expressions must be pure (no mutation or side effects).

Produce exactly {n_total} Python expressions `<expr>`.
First generate more candidate expressions than needed.
Then discard any that are trivial, invariant, or vacuous.
Finally return exactly {n_total} expressions.

You must output two groups, in this exact order:

1) CHANGED group ({n_changed} expressions):
   Expressions that have a different evaluation outcome between the buggy and patched programs:
   - yielding different values, OR
   - raising an exception in one version and returning a value or None in the other, OR
   - raising exceptions of different types or with different messages

2) UNCHANGED group ({n_unchanged} expressions):
   Expressions that have the same evaluation outcome between the buggy and patched programs:
   - Same value (`==`) in both versions, OR
   - Both versions raise an exception of the same type and same message (when message is stable)

### General Rules
1. Each expression must reference at least one variable available in the runtime local scope at the specified line
2. The final value of `<expr>` must be:
   - a primitive (`None`, `int`, `float`, `str`, `bool`), OR
   - a built-in collection (`list`, `tuple`, `set`, `dict`) containing only primitives.
3. Do not use mutation or side-effectful operations.
4. Attribute access and method calls are allowed only if valid for the runtime object’s type.
5. If `__return__` is present, treat it as a special local variable holding the function’s return value.
6. Do not introduce undefined identifiers (avoid `NameError`), except that CHANGED expressions may raise `NameError` when referencing `__return__` in mismatch cases.
7. Handling return vs. exception mismatches:
   - If exactly one version returns and the other raises an exception:
     - CHANGED expressions MUST reference `__return__`.
     - In this mismatch case, do NOT reference `__exception__`.
     - UNCHANGED expressions must be evaluable in both versions without raising `NameError`.
     - In this mismatch case only, UNCHANGED expressions do not need to be structurally similar to CHANGED expressions.
     - If `__return__` is present and equals `None`:
         - Do NOT use `__return__` as the base expression you start from.
         - CHANGED expressions must reference at least one non-`__return__` runtime variable in addition to `__return__`.
         - Prefer generating expressions from variables referenced at the probe line (and their dependencies), especially predicates appearing in assert / if statements.
         - Avoid expressions whose only purpose is checking the existence or value of `__return__`.
     - In case of conflict, the rules in section 7 apply only to the specified mismatch scenario and override Rule 1.
     - In this mismatch case, CHANGED and UNCHANGED expressions should still share the same outer boolean structure; only the discriminating clause (e.g., referencing `__return__`) should differ.
8. If `__return__` does not exist and `__exception__` is present in both versions:
   - Treat `__exception__` as a restricted tuple-like value:
     - `__exception__[0]`: exception type string
     - `__exception__[1]`: exception message string

### Rules to Construct CHANGED Expressions
1. Each CHANGED expression MUST semantically depend on the runtime values of referenced variables.
2. Each CHANGED expression SHOULD be coupled to the patch by targeting:
  - variables referenced at the probe line, OR
  - variables mentioned in State Differences, OR
  - direct dependencies of those variables.
3. Prefer expressions that expose the change directly (e.g., equality/inequality, membership, key/attribute presence, length, or a small projection).
4. Do NOT rely on intentionally fragile operations purely to induce an exception difference (e.g., unsafe indexing, unsafe attribute access) Exception differences are allowed only if they are a direct consequence of the patch.
5. Across the CHANGED group, diversify expression forms; do not repeat the same pattern with only superficial edits.
6. Trivial expressions are DISALLOWED.
  - An expression is considered trivial if its value is provably invariant across all possible runtime values of the referenced variables, or if it avoids inspecting those values in a meaningful way.
  - This includes (but is not limited to):
    - Tautologies or contradictions under all executions
    - Self-comparisons (e.g., `x == x`, `id(x) == id(x)`)
    - Empty slices or projections (e.g., `x[:0]`, `x[1:1]`, `list(x)[:0]`)
    - Vacuous iteration (e.g., `any(... for _ in x if False)`)
    - Length or count comparisons that are always true (e.g., `len(x) >= 0`)
    - String predicates with empty literals (e.g., `s.startswith("")`)
    - Type or existence checks that are always true (e.g., `isinstance(x, object)`)
    - Algebraic identities or cancellations (e.g., `x - x`, `x * 0`, `x ^ x`)
    - Boolean normalizations (e.g., `bool(x) in (True, False)`)
7. Expressions that are too simple are DISALLOWED.
8. Before finalizing each CHANGED expression, internally verify that it is not trivially invariant by reasoning about whether its value could change if the runtime variables were different.

### Rules to Construct UNCHANGED Expressions
1. UNCHANGED expressions act as distractors.
2. Each UNCHANGED expression MUST semantically depend on the runtime values of referenced variables.
  Specifically:
  - While the expression must evaluate to the same result in the buggy and patched executions, there must exist at least two other plausible executions (consistent with the provided variable states) for which the expression would evaluate to different values.
  - Expressions whose result is invariant under all value changes are forbidden, even if they reference runtime variables.
3. Each UNCHANGED expression should be a plausible alternative to a CHANGED expression:
  - structurally similar (same variables, access pattern, or expression shape),
  - modified minimally so that it does NOT change across versions,
  - without introducing tautologies, dead branches, or vacuous clauses whose sole purpose is to force invariance.
4. UNCHANGED expressions must also avoid the disallowed trivial patterns listed for CHANGED expressions. 
5. Before finalizing each UNCHANGED expression, internally verify that it is not trivially invariant by reasoning about whether its value could change if the runtime variables were different.

### Notes on the Serialization of the Variable States
- Variable states are serialized to describe runtime objects; expressions must target runtime semantics, not the serialization structure.
- `py/TAG` entries indicate serialization types and are NOT runtime attributes or keys.
- Examples:
    - `{{"py/set": [1, 2, 3]}}` represents a set `{{1, 2, 3}}` at runtime.
    - `{{"py/tuple": [1, 2]}}` represents a tuple `(1, 2)` at runtime.
    - `{{"py/type": "collections.OrderedDict"}}` represents the type `collections.OrderedDict`.
    - `{{"py/object": "module.ClassName", "attr1": val1, "attr2": val2}}` represents an instance
      of `ClassName`.
- Treat serialized types exactly as given; do not reinterpret or coerce values based on their textual appearance. For example, a serialized string "[a, b]" must be treated as a string, not as a list; only explicit structural markers (e.g., lists, tuples, py/TAGs) determine type.

### Output Schema (must follow exactly)
Note: Passing the AST validator does not imply that an expression is non-trivial;
all semantic rules above must still be satisfied.

Your output will be parsed using the following Pydantic models:

class Expression(BaseModel):
    expr: str

    @field_validator('expr')
    @classmethod
    def validate_expr(cls, v: str):
        tree = ast.parse(v, mode='eval')
        assert isinstance(tree, ast.Expression)
        assert not isinstance(tree.body, ast.Constant)
        return v

class ExpressionList(BaseModel):
    expressions: list[Expression]

### Output Format
Return exactly one JSON object:

{{
  "expressions": [
    {{"expr": "<expr_1>"}},
    ...
    {{"expr": "<expr_20>"}}
  ]
}}

Ordering rule:
- expressions[0..{n_changed}-1] MUST be the CHANGED group.
- expressions[{n_changed}..{n_total}-1] MUST be the UNCHANGED group.
