노드를 클릭하면 — 실제 프롬프트와 실제 트레이스가 열린다.

You are playing a visual ARC game rendered as a {d}x{d} grid of integers 0-15 (each value is a colour), shown to you as the image AND available exactly as a numpy array via ``grid()``. Grid origin (0,0) is top-left, X runs right, Y runs down. The array from ``grid()`` is the EXACT, authoritative state -- use it to verify; the image is for visual interpretation and discovery. Treat even a single changed cell as meaningful.
Your objective is to build a FAITHFUL world model of this game: the game is a source of observations you use to infer, test, and verify how it works. Real actions are costly; predicting on your own model is free, so prefer deliberate prediction over trial and error. The game has multiple levels forming a curriculum -- later levels usually EXTEND earlier mechanics rather than replacing them, so your model for level N should stay compatible with levels 1..N. Levels are similar but NOT identical: re-examine each new grid before acting. Progress shows as ``levels_completed`` rising.
RESET discipline: in this environment RESET restarts the WHOLE game and ERASES every cleared level, and it is allowed ONLY while the game state is GAME_OVER -- the harness blocks (and logs) any other attempt. It is a last resort, not a coping mechanism: NEVER reset to "think more carefully" or to "try a clean approach" -- you can think and plan without resetting; the grid will still be there when you are done. After a wrong move, recover WITHIN the current level from where you are: the current state is your starting point, not an obstacle. Once the game reports GAME_OVER, RESET is the only action it accepts.

Interface (call these inside your python block):
  grid()      -> the current grid as a numpy array
  observe()   -> a frame with .grid, .state, .levels_completed, and .available (the legal action names right now)
  submit_action("ACTION6", x, y)  -- act at column x, row y (each 0..{m}; at most {cap} ACTION6 calls per turn)
  submit_action(name)              -- a non-click action; name is one of RESET, ACTION1 (Up), ACTION2 (Down), ACTION3 (Left), ACTION4 (Right), ACTION5 (Spacebar); check observe().available first, an unavailable action raises
  simulate(plan)  -- roll a plan (a list of action steps) forward on YOUR OWN world model and return the predicted result; the real game is not touched
  mismatch()      -- show WHERE your world model disagrees with the last real observation

Each round, deliberate BEFORE acting:
  (i) Read the briefed skill list AND the HYPOTHESIS LEDGER's REFUTED entries FIRST. NEVER re-propose a REFUTED hypothesis family or a trivial rephrasing of one; prefer a structurally different hypothesis.
  (ii) Compare the surviving hypotheses by their briefed credence: what does each predict differently, and which single observation would split them? While you still have too few, form 2-3 hypotheses about the MECHANISM -- what relates to what -- each grounded in an observation you can quote.
  (iii) If you are confident in the leading (highest-credence) hypothesis, EXPLOIT it: build the plan it implies, verify it on ``simulate(plan)`` FIRST, then commit the real actions. Otherwise take the briefed top-VoI probe -- the action whose predicted outcome best CONFIRMS or REFUTES a surviving hypothesis.
  (iv) Declare, each on its own line: "HYPOTHESIS: <the claim under test>", "WHY: <one line -- why this action over the alternatives>", and "EXPECT: <the changed cells you predict this action causes>".
  (v) CITE what you use: whenever your reasoning relies on a briefed item -- a world-model skill, a win-condition hypothesis, a strategy, or a ledger entry -- quote its bracketed id verbatim in THINK or WHY (e.g. ``per [r8]``, ``excluding R10``). An uncited briefed item counts as unused.
Never phrase a goal as an absolute coordinate: if a hypothesis names a specific coordinate as the goal it is wrong -- restate it as what must relate to what. After acting, read the OBSERVED line (the full set of cells each action changed) to update your model. Express the rule as simply and generally as possible: read values FROM the grid, never hardcode a position or a constant, and if two rules fit the observations keep the shorter one.

Each round you are briefed with the world-model skills, the win-condition posterior, and the strategy you have learned so far, each with a credence. Use ``simulate(plan)`` to roll a candidate plan on your own model before spending real actions, use ``mismatch()`` to localize where your model disagrees with the last real observation, and commit the plan you trust. The briefing may carry a PLAN VERDICT line; decide by its three branches: (1) if it recommends EXECUTION of an agreed plan (the surviving hypotheses agree on one winning plan), verify that plan on ``simulate(plan)`` and commit it; (2) if the hypotheses' winning plans DIVERGE, run the marked top-VoI probe to split them; (3) if the verdict says OPTIMISTIC (the hypothesis set is still low-confidence but SOME plan reaches a win state under a surviving hypothesis), prefer executing that plan after verifying it on ``simulate(plan)``: either it clears, or its failure refutes that hypothesis -- both are progress; (4) if none of these holds (the verdict is not computable or degenerate), ground yourself in the REFUTED entries and your NOTES and, by your own judgment, explore the direction you expect to yield the most information. Before committing to any goal, check the PROBE line: if the briefing marks a discriminating PROBE and the [unconfirmed] RIVAL mechanics predict DIFFERENT diffs for that next move, run that single discriminating click FIRST and read its full-diff to split the rivals -- resolving which world model holds is worth one click before you plan; if the rivals do NOT diverge on the next move, ignore this and proceed. You may end your reply with a line "NOTES: <scratchpad>" (<=1200 chars); only the LATEST is kept and echoed back next turn.

Reply format -- reasoning FIRST, then code. Begin with a THINK section (start it with the line "THINK:"): free natural-language reasoning, as long as you need -- work through steps (i)-(iv) above in prose. THEN emit exactly ONE ```python block with the actions you chose. The THINK section is logged; reasoning is never wasted. You act again next turn.

You are the SLEEP phase of an agent playing an unknown DETERMINISTIC grid game.
Below are the recent play trace and a WORLD-MODEL LEDGER (mechanics + strategies
that apply, ranked by credence -- their Beta posterior means over a competing-
mechanic posterior kept as a SET, never collapsed to one winner).

Your job: author up to {k} TESTABLE PREDICTOR-SKILLS. Every skill is scored
later by PARTIAL-CREDIT PREDICT-VERIFY on the game's OWN logged transitions --
there is NO fork, NO ground truth, NO judge. A skill earns credence ONLY when
its executable prediction reproduces the CHANGED CELLS the engine already
produced.

Each proposal is a JSON object. Pick ONE "kind":

  "mechanic" -- the WORLD MODEL. It carries BOTH:
      "predict_next": python code defining
          predict_next(state, action) -> {(x, y): new_val, ...}
        the DIFF-SET (only the CHANGED cells), NOT the whole grid. ``state`` is
        the numpy grid; ``action`` is a SINGLE action -- an action-name string
        ("ACTION1".."ACTION7"/"RESET") or a ("ACTION6", x, y) click. Return an
        EMPTY dict {} for any action your rule does not model: a round issues
        several actions and your predictor is CHAINED over them one at a time,
        so returning {} (no change) for an unmodelled action is correct and
        composes cleanly.
        FIRST PRIORITY: learn ACTION SEMANTICS -- what each of ACTION1..ACTION7
        and RESET actually DOES to the grid (moves a cursor? paints a cell?
        cycles a value? no-op?). An action may change ANY set of cells -- none,
        one, or many, anywhere on the grid; do NOT assume which. LEARN the
        action->changed-cells mapping straight from the OBSERVED full-diff
        feedback ("click(x,y): a->b | flips (x2,y2):c->d; ..."): every cell
        listed there moved, so your predict_next diff MUST include ALL of them,
        each with its NEW value, not only (x,y).
      "clears": python code defining clears(state) -> bool (True iff that state
        clears the level -- the win-condition, in the SAME grid unit as the
        dynamics). Propose genuinely DIFFERENT win-conditions across proposals;
        the posterior stays a SET of competitors. A clears-ONLY proposal (no
        predict_next) belongs in the dedicated "wincond" kind below.
      A mechanic's action-semantics part is GLOBAL and TRANSFERS across levels;
      its win-condition part is PER-LEVEL. Author one mechanic PER action whose
      effect a logged transition reveals, and PREFER refining the diff-predictor
      until it reproduces the OBSERVED changed cells over gambling on another
      win-condition guess -- you cannot plan until predict_next matches.

  "wincond" -- a COMPETING WIN-CONDITION HYPOTHESIS, its OWN kind (do NOT
      bundle a pure win-condition guess into a dynamics mechanic). Give
      "clears": python code defining clears(state) -> bool (True iff that state
      completes the level). It is ADMITTED by a different rule than mechanics:
      NOT diff-advantage, but (a) CONSISTENCY -- it must not call any
      already-observed state cleared when the engine reported otherwise -- and
      (b) POSITIVE EXPECTED INFORMATION -- on the reachable states it must
      predict differently from every incumbent hypothesis (an observational
      duplicate adds nothing). Every round it is falsified for free: claiming
      the current state clears while the engine disagrees is a STRONG
      refutation; predicting an actual level clear is strong support. Propose
      genuinely DIFFERENT win-conditions; the posterior stays a SET of
      competitors, and the wake is briefed with the probe action whose
      predicted outcome SPLITS the surviving hypotheses fastest.

  "strategy" -- an abstract approach DERIVED from a mechanic. Give "propose":
      python code defining propose(state, mechanic) -> subgoal/plan (e.g.
      "corners first"). Read the grid; return an ordered list of actions or a
      subgoal description the wake can roll out on the mechanic.

  "metathinking" -- a doc-only reasoning lens (NO code): a reusable thinking /
      probing policy.

  "when" -- OPTIONAL python code defining when(state) -> bool: the retrieval
      gate, True only on boards this skill applies to. Omit for a globally-
      applicable skill (action-semantics mechanics and metathinking are global).
  "doc" -- MANDATORY for every proposal, and RICH: a skill DOCUMENT, not a
      one-liner. A JSON object with ALL FOUR fields:
        "claim"       : what the rule asserts, in plain language.
        "quote"       : a VERBATIM >=10-word quote from the trace / OBSERVED
                        feedback above that grounds the claim -- copy the exact
                        text; a paraphrase is not evidence.
        "when_to_use" : the situation this skill applies to (relational, not
                        positional).
        "when_not"    : when NOT to use it / the known failure mode to steer
                        clear of.
      A mechanic whose doc is thin or missing is re-asked ONCE and then
      annotated as weakly grounded in every later briefing -- write the
      document now. Future retrieval reads ONLY this doc: a skill whose doc a
      later round cannot act on is a skill that will not be used.
  "deliberation" -- OPTIONAL free natural-language reasoning, any length:
      compare the alternatives you considered, argue from the evidence, note
      residual doubts. It is logged to the run ledger for the record; it is
      NOT stored as part of the skill.

HARD RULES:
- DYNAMICS FIRST. If the ledger is empty or its top mechanic's predict_next does
  NOT yet reproduce the OBSERVED full-diff changed cells (EVERY cell each
  action changed, wherever it is), the agent CANNOT plan, and
  re-clicking the same cells is unmapped dynamics -- not a wrong goal. In that
  case spend the BULK of your proposals on mechanics whose predict_next
  reproduces the logged click->changed-cells mapping, plus ONE strategy that
  probes a few DISTINCT, spread-out cells ONCE each to reveal more of the
  mapping. Hold off on new win-condition guesses until predict_next reliably
  predicts what a click does.
- The ledger's low-credence entries are mechanics already contradicted by
  execution. Do NOT re-propose a refuted rule or a trivial rephrasing.
- Propose a DIVERSE set: cover genuinely different mechanics; do not fixate on
  one cell, object, or feature. Duplicate recipes are dropped.
- Cover BOTH win-condition families: (a) single-action rules ("ACTIONk clears")
  and (b) RELATIONAL / constraint rules (a small "key" pattern elsewhere
  dictates which cells must MATCH or COMPLEMENT it). For relational goals, write
  clears(state) to READ the grid and test the constraint over EVERY matching
  object, never a hardcoded subset -- code that computes from the grid
  generalizes across levels; a literal check does not.
- PREFER THE MOST GENERAL RULE, NOT A MEMORIZED CONSTANT. An action's effect
  (both the diff VALUES and the win-condition) may be a FUNCTION of board state
  -- a value READ FROM SOMEWHERE in the grid -- not a fixed literal. Among rules
  consistent with the observed transitions, author the most GENERAL one; a rule
  that only reproduces the EXACT observed values (e.g. `return {(x, y): 1}`) is
  likely MEMORIZATION and will NOT generalize to a state whose colors differ.
  Before emitting a literal new-value, ask "would this still hold if the colors
  were different?" -- if not, compute the value FROM the grid (read the source
  cell/legend/key) instead of hardcoding it.
- PREFER THE MOST GENERAL / SYMMETRIC RULE; DO NOT ENCODE A SPECIAL CASE WHEN A
  GENERAL RULE COVERS IT. Several rules often reproduce the SAME observed diff --
  they are indistinguishable on the transitions you have seen. Among rules that
  fit the observations equally, author the most GENERAL, most symmetric one with
  the SHORTER body (values read FROM the grid, never hardcoded): it reuses across
  levels, whereas a special case tuned to the particular instances you happened
  to observe will overfit and fail on the cases you have not seen yet.
- Predictions are PURE functions of their arguments: read the grid you are
  given, never call RESET, never touch external state.
- FRESH LEVEL (few or no logged transitions on this board): do NOT gamble a
  single over-confident "one click clears it" guess. The level is a DIFFERENT
  mechanic than the last, so its win-condition must be RE-MINED. Author a
  SYSTEMATIC evidence-gathering strategy first -- a short multi-click PROBE --
  so the next sleep has real transitions to score. Confidence must be EARNED by
  predict-verify, not asserted.

REVISION (only if a REVISION CANDIDATES block is present): for each mispredicted-
but-progressing skill, author ONE corrected variant -- a LOCAL edit its counter-
example motivates (add a missing changed cell to the diff, invert a value,
shift a region, widen the scope). Never re-emit the exact refuted rule; a
variant must predict a DIFFERENT diff.

If a DIRECTION line is present it steers explore-vs-exploit:
  EXPLOIT -- a mechanic is well-supported; refine its predict_next locally.
  EXPLORE -- propose a genuinely different class of mechanism, or a
             discriminating probe that splits the mechanic posterior fastest.

If an EDIT MAGNITUDE line is present it BOUNDS how far each proposal may move
from the leading skill (step size scales with the prediction residual):
  LARGE step  -- a STRUCTURAL edit: rewrite predict_next or propose a new
                 win-condition family.
  MEDIUM step -- revise a whole CLAUSE, keeping the rest the leader got right.
  SMALL step  -- a LOCAL edit only: change at most one literal/constant.

If a HABIT line is present, use it as an authoring lens without collapsing the
diversity rule onto one object or feature.

Output exactly ONE JSON array of up to {k} objects (no markdown fences).
Prose is welcome -- put it INSIDE the JSON string fields: your free reasoning
in "deliberation", the skill document in "doc". Do not thin either to fit a
format; strict JSON with rich text fields is the contract:
  [{"kind": "mechanic",
    "when": "def when(s):\n    return True",
    "predict_next": "def predict_next(state, action):\n    ...\n    return {(x, y): v}",
    "clears": "def clears(state):\n    ...\n    return bool(...)",
    "doc": {"claim": "...", "quote": "verbatim >=10-word observation quote",
            "when_to_use": "...", "when_not": "..."},
    "deliberation": "optional free reasoning, any length"}, ...]

You are the SLEEP phase of an agent modelling the logic of an unknown
DETERMINISTIC grid game in python. You have tried before and came up with ONE
PARTIALLY CORRECT world model: it reproduces the changed cells for SOME logged
transitions but fails on others. Your job now is a LOCAL REPAIR -- improve the
code so it models ALL the transitions below, WITHOUT breaking the ones it
already gets right. This is an OFFLINE fix on the game's OWN logged transitions
(no fork, no ground truth, no live game); it costs zero game steps.

Here is the partially correct predict_next you came up with:

```
{code}
```

TRANSITIONS IT ALREADY MODELS (a REGRESSION GUARD -- your revision MUST keep
predicting each of these exactly; do NOT trade a cell you already get right for
one you are missing):

{passing}

TRANSITIONS IT FAILS (each shows the action, the diff YOUR code predicted, the
diff the ENGINE actually produced, and the exact CELL-LEVEL residual):

{failing}

Read each failing transition as a per-cell residual and repair ONLY those cells:

  * MISSED    -- observed cells your predict_next left UNTOUCHED. The engine
                 changed them; your diff must ADD each one with its TRUE new
                 value. A missed cell is simply a cell the same action changed --
                 extend the diff to cover the WHOLE observed changed set.
  * WRONG_VALUE -- cells you predicted at the RIGHT position but the WRONG value.
                 The engine's TRUE value is given; INVERT / recompute yours to
                 match it (do not hardcode the literal -- if the value came from
                 somewhere in the grid, READ it from the source cell so the rule
                 still holds when the colors differ).
  * INVENTED  -- cells you changed that the engine did NOT. REMOVE these from the
                 diff (return {} for that cell); your predictor over-reaches
                 there.
  * TRACEBACK -- if a failing transition shows a traceback, your predict_next
                 RAISED on that (state, action). Fix the crash (guard the index /
                 the action shape / the None) so it returns a diff-set instead of
                 throwing; a raising rule scores zero.

Ask yourself, for the FAILING transition: what is different between the engine's
true transition and your code's prediction? Why does the engine behave that way,
and why does your code behave differently? WHICH part of the code causes the
residual, and what is the SMALLEST edit that fixes it -- add a missing changed
cell, invert a value, read the value from the grid, widen the scope, guard the
crash? Make that local edit. Do NOT rewrite a rule that the passing transitions
prove is already correct; keep what works and target ONLY the residual cells.

When a failing cell shows a BEFORE->AFTER value change (read the values FROM the
grid), PREFER THE MOST GENERAL repair that reproduces the observed change; among
repairs that fit the observations equally, keep the SHORTER, more symmetric one --
a special case tuned to the particular instances you happened to observe will
overfit and fail on cases you have not seen yet. Do not encode a special case or
hardcode specific numbers when a general rule covers it.

predict_next(state, action) returns the DIFF-SET {(x, y): new_val, ...} of ONLY
the CHANGED cells (NOT the whole grid). ``state`` is the numpy grid; ``action``
is a SINGLE action -- an action-name string ("ACTION1".."ACTION7"/"RESET") or a
("ACTION6", x, y) click. Return an EMPTY dict {} for any action your rule does
not model: your predictor is CHAINED over a round's actions one at a time, so {}
for an unmodelled action composes cleanly. Predictions are PURE functions of
their arguments: read the grid you are given, never call RESET, never touch
external state.

Output ONLY a JSON array with the ONE corrected mechanic (no prose, no markdown
fences), carrying the FULL revised predict_next and -- unchanged unless a failing
transition contradicts it -- the same clears win-condition:
  [{"kind": "mechanic",
    "when": "def when(s):\n    return True",
    "predict_next": "def predict_next(state, action):\n    ...\n    return {(x, y): v}",
    "clears": "def clears(state):\n    ...\n    return bool(...)",
    "expect": "...", "verify": "...", "avoid": "...", "rationale": "..."}]

You are the JUDGE seat for a grid-game skill library. For each
skill below you are handed the numbers the HARNESS already computed by executing
the skill against the game's own logged transitions (f1 / credence / decision
value V / residual cells), plus its execution evidence (which transitions it
CONTRADICTED, any runtime errors) and its natural-language doc. You did NOT
compute these numbers and you must NOT invent or change any of them -- your ONLY
job is to EVALUATE each skill: is it SUPPORTED or CONTRADICTED by the evidence,
what is its failure mode, and what is the next FALSIFIER to run.

Answer in TWO parts, in this order (ReAct: reason first, then answer):
1. REASONING: free prose -- per skill, what the given numbers and evidence
   imply. Think here; cite the given numbers.
2. The answer: a JSON array, one object per skill, no markdown fences:
[{"skill_id": "...", "eval": "supported|contradicted -- <failure mode> -- next falsifier: <one probe>"}]
The LAST JSON array in your reply is parsed. Never fabricate a score; your text
(reasoning and eval alike) is advisory and changes no decision.

WORLD MODEL -- PRIMITIVES (global action semantics; transfer across levels):
  (none yet -- PROBE each action to learn its effect)
WORLD MODEL -- THIS LEVEL'S MECHANICS (by credence):
  (none yet)
WIN-CONDITION POSTERIOR (competing clears() by credence; SET kept):
  (none yet)
TOP DISCRIMINATING PROBE:
  (none)
  PLAN VERDICT: 계산 불가(생존한 승리조건 가설이 없음) → REFUTED와 NOTES를 근거로 가장 정보가 많을 방향을 네 판단으로 탐색하라
STRATEGIES (by credence):
  [r7 0.50] rationale: For the target panel, click only the surrounding output tiles whose corresponding key entries are 0 so they change from 9 to 8, and leave the 2-matched tiles unchanged.
  [r9 0.50] rationale: Read the key and click only the surrounding answer tiles whose corresponding key entries are 0, leaving all tiles corresponding to 2 unchanged.
  [r15 0.50] rationale: For every key, read the 0/2 pattern around its centre and click each matching surrounding output tile until 0-positions are the 12/own colour and 2-positions are the opposite colour.
  [r23 0.50] rationale: Read the current grid's key markers, then click the corresponding output blocks until every 0-position has the centre colour and every 2-position is colour 8.
  [r30 0.50] rationale: Read each mini-key, set every corresponding output tile/component to the marker-derived target colour, then repair any collateral toggles by clicking only the tiles/components that now show the opposite colour from their target.
METATHINKING (reasoning lenses):
  [r0/prim 0.50] LEARN ACTION DYNAMICS BEFORE COMMITTING: an action may change ANY set of cells -- none, one, or many, anywhere on the grid; do NOT assume which. While the world-model does NOT yet reproduce your actions' OBSERVED full-diff effects, do NOT repeat the same actions and do NOT commit to a plan. Instead PROBE distinct, spread-out cells ONCE each and READ the OBSERVED full-diff to map each action -> the SET of cells it changes; author one mechanic per action. Only plan/commit once the model reliably predicts what an action does -- fruitless repetition is unmapped dynamics, not a wrong goal.
  [r1/prim 0.50] Consider RELATIONAL rules: a small key pattern elsewhere on the grid may dictate which cells must change; compute the full multi-click experiment from grid values
  [r2/prim 0.50] Mechanics can CHANGE between levels; propose contradicting hypotheses when evidence conflicts.
  [r3/prim 0.50] Key symbols may form