v1.4.0

Added

• Enum open sets. A plugin's set declared ofEnum is an enum in the bot: its members are the enum's
  constants, and adding one writes a bare constant after the last. Rename, repoint and remove work by binding as
  they do for a class's fields. A missing holder is written as an empty enum carrying the plugin's mark and
  implementing the element type. A reference to a constant reads as the value the plugin makes of its name, and
  a value equal to one is written as that constant (ManagedSets, ManagedConstants, ManagedHolders). A
  marked enum is locked like a marked class (LockResolver).
• Values written as named chains. A type its plugin declares with withers is written as its factory call
  followed by a link for each part that differs from what the factory makes —
  Flow.activity(COLLECT, Collect::body).described("…").goesHome() — and read back with the links in any
  order, a link left out reading as the factory's. A chain setting one part twice, or a link no declaration
  has, stays as written. The Parameters window labels a wither's field by the wither's name.

Changed

• A plugin's typed marker is a managed value's mark, and @Managed is no longer read. Studio reads a
  plugin's own annotation marked @ManagedMarker — @SdkValue(SdkValue.Id.FLOW) — as the value it names, on
  a method or on an open set's class: the plugin's window opens and rewrites it, the canvas locks it, ▶ Try
  names its holder, and its pill reads as a plugin's. A missing holder is written with the plugin's annotation
  and a method named after the constant (flowLayout() for FLOW_LAYOUT). A bot still marked @Managed is
  ordinary code until it moves to its plugin's annotation.
• A file whose open-set constants were read before its plugin was bound is read again once the plugin is, so
  the constants are found.
• Adding a constant to an open set that two classes carry is refused, naming both, instead of going into
  whichever was found first.
• A plugin's toolbar button that shows a run property refreshes when the plugin sets it: Runs.setProperty
  announces the change as every other settings write does. The SDK's 🎮 game button needs this.

Removed

• The unused global list of recent launch targets in the preferences file (recentLaunchTargets). Nothing
  wrote it since the launch-target dialog moved to the SDK plugin, whose game dialog keeps its recents per
  computer in the run properties. An older preferences file still reads.

Added

• Installing Studio installs gamescope and Xephyr too, the two servers a bot's private display runs on. The
  rpm and the deb recommend them (Recommends:), so dnf and apt install them by default and you can remove
  them afterwards.
• Dev mode: try a plugin before it is released. Project ▸ Plugins & Libraries has a Dev mode box, per
  project and only on this computer. While it is on, plugins pinned at a -SNAPSHOT version (the build
  mvn install put in ~/.m2) load. Reload plugins picks up each rebuild, and a banner above the canvas
  names what is loaded. A plugin refused outside dev mode offers Use dev mode on its row. A Studio run from
  source gives a dev-mode project its own unreleased contract. Publish still refuses a -SNAPSHOT pin, and
  turning dev mode off moves the contract entry back to the released one.
• Dev mode offers your local builds. In a dev-mode project, Browse lists every plugin built into
  ~/.m2 at a -SNAPSHOT, marked (local build). That includes your own and, from the umbrella, the SDK,
  plugin-basics and the rest. Each Installed row's version list offers its local build too, the SDK's
  included, through the usual checked pass.
• A plugin declared twice is one row, and Studio loads one copy. A pom naming a plugin under both
  com.github.LiQiyeDev and com.github.BotMakerDev (the SDK pinned before the move, then installed again)
  had both jars on one loader, so Studio ran a mix of the two versions. Studio now loads the new groupId's
  copy and its tree, or the old one's when the new one is a dev build outside dev mode. Installed shows one
  row flagged Declared twice, with Keep for each copy. Browse no longer offers to install a
  plugin the pom already declares under the old groupId.
• Installed says what each plugin loaded. A Loaded column names the jar each plugin came from,
  (dev build) included, or not loaded with the reason. Plugins another plugin brings (plugin-basics with
  the SDK) are listed read-only, comes with another plugin. Browse's Included is now Installed with
  another plugin — view….
• Installed: one button per row. A row opens on its installed version. Its button reads Upgrade to X
  when a newer release is known, or Switch to X once another version is picked in the menu, a downgrade
  included. One click runs that row alone. Upgrade all moves every row that has an upgrade, in one pass.
  The Check button, the report under the table, Snapshot, repair & switch and Pin released versions are
  gone; a pass still saves a version first and repairs the bot's calls. A dev build in a dev-mode project
  shows Dev build and is never offered an upgrade.
• An upgrade asks a fix for every place it breaks, before writing anything. When a move breaks calls,
  a list opens with each place in source order and the fixes for it as buttons: Studio's suggestion, each
  member a split one became, a default value marked for review, or deleting the call. A type the bot writes
  that is gone is listed to acknowledge. Picking a fix moves to the next one; Use the suggested fix for the N
  left answers the rest. Upgrade stays disabled until every place has a fix, and Cancel changes nothing.
• Remove asks in a window that fits. One sentence counts the calls and types it changes, the plugin's
  files are a scrolling list with one checkbox, and the buttons stay at the bottom. It replaces an alert that
  could open taller or wider than the screen.
• Libraries points to Installed and marks unneeded editor dependencies. A link says how many plugins are on
  the Installed tab. A library only an absent plugin lists as an editor dependency is marked not needed.
• The overlay editor docks beside the game. ⧉ Overlay opens a panel beside the window your bot watches —
  with the SDK, the one Sdk.captureSource() names — without asking; ⇄ Change picks another. It follows the
  window, drags off to float (⇲ docks it again) and resizes from either edge. Chips across the top are your
  activities: pick one and its file opens in the editor and the caret goes inside it. The script below has one
  ⋮ per row (configure, move, delete); ▲▼ always move the caret. The tabs at the bottom are the plugins' tools —
  with the SDK, Picture cuts a picture off the game and can insert a click on it, Point inserts a click at
  a spot, Flow opens 🔀 Activity Flow — then Actions (the plugins' overlay buttons) and Blocks. While the
  bot runs, its stop, pause and trace sit in the panel's header instead of a second window.
• The overlay editor shows what each row would do now. A row whose call a plugin can check — with the SDK,
  finding, waiting for or clicking a picture — gets ✓, ✗ or ? (hover for found 0.94 at 412,230). The row the
  caret is on is checked twice a second and its match is boxed on the game, orange where a click would land;
  ⟳ checks every row, and so does the end of a run. Nothing is clicked. A bot that watches its private
  display session is checked on the session's own pixels, and the box is drawn on the window showing it.
• ▶ Try one statement, or run one activity. Right-click a block on the canvas, or open an overlay row's ⋮,
  and pick ▶ Try this statement: it runs on its own against the screen as it is now, as a run — Stop, the
  run bar, the Run and Trace tabs — and the Run tab says what it found or returned. Values it reads from earlier
  lines are taken from the last debug pause, computed again when they only look (a picture search), or asked
  for with the type's own editor. A static method that takes nothing — an activity's body — offers ▶ Run …
  on its own, and so does the overlay's ▶ Run ▸ Run this activity. Needs a plugin with a trial entry (the
  SDK's); nothing is written into the bot.
• The assistant works on the whole bot, and runs it. Over MCP, every file tool takes a file, so Claude
  edits the activity it is automating rather than only the open file — an edit to another file opens it in the
  editor first, as one undo step there. apply_edits makes several inserts, slot sets and deletes in one call,
  kept all together as one undo step or not at all. A slot takes one of the bot's constants by name
  (Pictures.ORE). New tools: list_files, list_methods, list_targets, set_target, move_caret and
  show_area (the overlay editor's caret and a box on the game), run_bot, run_activity, try_statement,
  stop, run_state and read_trace. Nothing starts while something runs. The plugins' own tools are served
  too — with the SDK, sdk_screenshot, sdk_crop_picture, sdk_find_picture and the rest, pictures coming
  back as images. The game is still touched only by running the bot's code; there is no click or key tool.
• The assistant shapes the code, not just the blocks. add_method (types Studio offers, by name),
  edit_signature (the file's calls follow; refused when another file's call would break), move_block and
  add_file; find_usages, rename (every file, one undo step) and open, each naming a declaration as
  Collect.body; and the Review list — list_review, mark_reviewed, remove_mark, undo_change.
• The overlay editor sees what the bot sees. With a plugin that grabs its own frames (the SDK), the
  probes, the tool tabs and the assistant's screenshots read the bot's capture source itself: a bot narrowed
  to a regio ...