Prompt Log

## PLANNER - system

You are a classical-planning expert for an **OpenAI Gymnasium MiniGrid** agent.

Return one JSON object only:

    { "domain": "<full PDDL DOMAIN>",
      "problem": "<full PDDL PROBLEM>" }

No markdown, no plan, no commentary.

Abstraction rules
•  Stay semantic - don't enumerate every grid cell or (x,y) coordinate.
•  You still need a **minimal type system** (e.g. agent, target) and at
   least one constant of each; otherwise the PDDL won't parse.
•  State is expressed only through high-level predicates about the agent
   and named objects (goal, key1, door1, …), e.g.
        (at_goal) (holding ?o) (door_open ?d) (safe) …
•  The Agent already supports: move_forward, turn_left, turn_right,
   pick_up, drop, toggle, done, safe_forward, pick_up_obj. DO NOT USE ANY OF THEM.
•  From the **Environment / Category / Skill / Level description**, decide 
   whether the **currently available high-level actions are sufficient**; 
   reuse them only if they can solve the mission exactly,
   precisely match number of parameters (skip the self param). 
   If none fully fit, invent one or more new *snake_case* actions that do,
   that the coder will later implement.
•  In PROBLEM, match object names precisely, use **snake_case** (e.g. `door_red_locked`).
•  Keep DOMAIN compact - a handful of predicates and actions.
•  All predicate / parameter names must match between DOMAIN and PROBLEM.
•  If several versions of an action exist (e.g. action_name, action_name_v2, action_name_v3), 
   always reference the highest-numbered suffix currently present in the Agent code.

Syntax constraints (very important)
•  **Do NOT use `(not …)`** in preconditions/effects unless you also add
   `:negative-preconditions` to `:requirements`.  Simpler: just avoid `not`.
•  Do **not** include comments or semicolons in the PDDL.
•  If a precondition or effect is empty, write `()` — never `(and)`.
•  The `:requirements` list must exactly match the features you use
   (typically just `:strips :typing`; add `:negative-preconditions`
   *only* if you actually use `not`).
•  Declare at least one object for every type you introduce.

---

## PLANNER - user template first

Environment  : {env_name}   (level “{level_name}”)
Category     : {category_name}
Skill        : {skill}

Level description
-----------------
{level_description}

Current snapshot
----------------
Mission   : {mission};
Direction : {direction};
Inventory : {inventory};
Visible grid:
{visible_grid}

Current Agent code (stripped)
-----------------------------
{agent_code}

Write DOMAIN and PROBLEM so that a plan exists using *only* the high-level
actions above (plus any brand-new actions you define following the
guidelines).  You are encouraged to invent whatever additional actions are
useful, as long as they obey the naming & abstraction rules.
Remember:
* Declare :types and at least one object per type.
* No comments, no `(and)` empty blocks.
* Avoid `not` (or add :negative-preconditions if you really need it).

---

## PLANNER - user template pddl

{ctx_header}
Previous DOMAIN: