@evref-bl/pharo-mcp 1.5.1 → 2.1.0

package/README.md

@@ -1,9 +1,9 @@
-[![Pharo version](https://img.shields.io/badge/Pharo-12%20%7C%2013%20%7C%2014-%23aac9ff.svg)](https://github.com/pharo-project/Pharo)
+# MCP for Pharo
+
+[![Pharo version](https://img.shields.io/badge/Pharo-12%20%7C%2013%20%7C%2014%20%7C%2015-%23aac9ff.svg)](https://github.com/pharo-project/Pharo)
 [![CI](https://github.com/Evref-BL/MCP/actions/workflows/ci.yml/badge.svg?branch=main&event=push)](https://github.com/Evref-BL/MCP/actions/workflows/ci.yml?query=branch%3Amain+event%3Apush)
 [![Coverage Status](https://coveralls.io/repos/github/Evref-BL/MCP/badge.svg?branch=main)](https://coveralls.io/github/Evref-BL/MCP?branch=main)
 
-# MCP for Pharo
-
 MCP is an in-image [Model Context Protocol](https://modelcontextprotocol.io/)
 server for Pharo. It lets MCP clients inspect and change the running image
 through Pharo-aware tools for packages, classes, methods, tests, repositories,
@@ -15,8 +15,10 @@ files as plain text.
 
 ## Supported Versions
 
-Pharo 12, 13, and 14 are supported. Development targets Pharo 14 while CI
-checks the full matrix.
+Pharo 12, 13, 14, and 15 are supported.
+
+Protocol revisions `2025-03-26`, `2025-06-18`, `2025-11-25` and `2026-07-28`
+are supported, each answered in its own shape.
 
 ## Install And Start
 
@@ -26,17 +28,20 @@ Load MCP in a supported image:
 Metacello new
    baseline: 'MCP';
    repository: 'github://Evref-BL/MCP:main/src';
+   onConflictUseIncoming;
    load.
 ```
 
 Start the Streamable HTTP server:
 
 ```smalltalk
-mcp := MCP new.
-mcp port: 4000.
-mcp start.
+MCP startOnPort: 4000.
 ```
 
+That answers the server already on 4000 when the image has one, so running it
+again after a restart is safe. `MCP allServers` lists what the image holds, and
+`Library → MCP Servers` in the world menu shows the same list.
+
 Connect a local MCP client to `http://127.0.0.1:4000`. Client configuration
 formats differ; see [Getting started](templates/pharo-references/getting-started.md) for setup
 and first calls.
@@ -57,10 +62,10 @@ Install the guide, local references, workflow skills, and direct MCP
 configuration for an agent host into the current project:
 
 ```sh
-npx @evref-bl/pharo-mcp install --host codex
+npx @evref-bl/pharo-mcp install --host claude
 ```
 
-Use `--host claude` or `--host opencode` for those hosts. The direct MCP
+Use `--host codex` or `--host opencode` for those hosts. The direct MCP
 configuration expects port `4000`; update it when the image uses another port.
 
 Node integrations that provide their own MCP transport can install only the
@@ -74,7 +79,7 @@ installGuidance({ host: "codex", cwd: process.cwd() });
 
 ## Contributing
 
-Use Pharo 14 for normal development and preserve Pharo 12/13 compatibility.
-Live behavior must be verified in an image; source inspection alone is not
-enough. Start with [AGENTS.md](AGENTS.md) and
+Use Pharo 14 for normal development and preserve Pharo 12, 13 and 15
+compatibility. Live behavior must be verified in an image; source inspection
+alone is not enough. Start with [AGENTS.md](AGENTS.md) and
 [MCP verification](docs/mcp-verification.md).

package/node/installer.js

@@ -44,9 +44,11 @@ function filesIn(directory) {
   });
 }
 
-function directoryPlan(sourceRelativePath, targetRelativePath) {
+function directoryPlan(sourceRelativePath, targetRelativePath, host) {
   const sourceDirectory = path.join(templateDirectory(), sourceRelativePath);
-  return filesIn(sourceDirectory).map((source) => ({
+  return filesIn(sourceDirectory).filter((source) =>
+    host === "codex" || !source.endsWith(`${path.sep}agents${path.sep}openai.yaml`)
+  ).map((source) => ({
     source,
     target: path.join(targetRelativePath, path.relative(sourceDirectory, source)),
   }));
@@ -59,17 +61,17 @@ function filePlan(sourceRelativePath, targetRelativePath) {
   }];
 }
 
-function guidancePlan(configuration) {
+function guidancePlan(configuration, host) {
   return [
     ...filePlan("pharo.AGENTS.md", path.join(configuration.directory, "pharo.AGENTS.md")),
-    ...directoryPlan("pharo-skills", path.join(configuration.directory, "skills")),
+    ...directoryPlan("pharo-skills", path.join(configuration.directory, "skills"), host),
     ...directoryPlan("pharo-references", path.join(configuration.directory, "pharo-references")),
   ];
 }
 
-function fullPlan(configuration) {
+function fullPlan(configuration, host) {
   const [source, target] = configuration.configuration;
-  return [...guidancePlan(configuration), ...filePlan(source, target)];
+  return [...guidancePlan(configuration, host), ...filePlan(source, target)];
 }
 
 function absolutePlan(cwd, plan) {
@@ -129,7 +131,7 @@ function writeGuide({ target, content }) {
 function prepare(options, direct) {
   const cwd = path.resolve(options.cwd ?? process.cwd());
   const configuration = hostConfiguration(options.host);
-  const plan = absolutePlan(cwd, direct ? fullPlan(configuration) : guidancePlan(configuration));
+  const plan = absolutePlan(cwd, direct ? fullPlan(configuration, options.host) : guidancePlan(configuration, options.host));
   const guide = guidePlan(cwd, configuration);
   assertCompatible(plan);
   return { configuration, cwd, guide, plan };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@evref-bl/pharo-mcp",
-  "version": "1.5.1",
+  "version": "2.1.0",
   "description": "Pharo MCP agent-host templates",
   "license": "MIT",
   "type": "module",

package/templates/pharo-references/debugging.md

@@ -1,147 +1,70 @@
 # Debugging Tools
 
-Applies when using MCP-Pharo to capture exceptions, inspect debug sessions,
-control paused execution, manage breakpoints, or repair code from a debugger
-state.
+Applies when using MCP-Pharo to watch values while code runs, or to see what
+debuggers a person has open.
 
 ## Goal
 
-Use debugger tools without guessing from source, driving Morphic debugger UI by
-hand, or issuing stale frame and variable references.
+See what running code is doing without guessing from source and without driving
+the Morphic debugger by hand.
 
 Debugger tools are discoverable, not part of the default static surface.
 
 ## Discovery Flow
 
-1. Use `tool_search` with `group=debugging` to find available debugger
-   tools.
+1. Use `tool_search` with a query such as `watch` or `debugger`.
 2. Use `tool_get` for the exact schema of the tool you plan to call.
 3. If the current client exposes a catalog bridge, use `tool_call` to invoke
-   the selected debugger tool by name. Otherwise use the callable form exposed
-   by the current client.
+   the selected tool by name. Otherwise use the callable form exposed by the
+   current client.
 
-## Must Do
+## Tool Map
 
-- Treat `stateId`, `frameRef`, and `variableRef` values as opaque and
-  state-scoped.
-- Use the newest returned state after every control or edit action.
-- Keep stack and variable limits small first, then expand only what is needed.
-- Clear temporary breakpoints and forget agent-owned sessions when the task is
-  done.
-- Report the exact debugger tool names used and the final session state.
+| Tool | Use |
+| --- | --- |
+| `debug_watch` | Record what variables hold while an expression runs, without stopping it. |
+| `debug_search` | Answer the debuggers open in the image, read-only. |
 
-## Do Not
+Neither tool keeps anything. No session is started, attached or registered, so
+there is no reference to carry between calls and nothing to clean up.
 
-- Do not drive debugger windows or mutate contexts through general `image_evaluate`
-  code.
-- Do not reuse frame or variable references after stepping, restarting,
-  resuming, terminating, or editing.
-- Do not leave breakpoints or captured sessions behind without reporting them.
-- Do not use debugger editing as a substitute for normal source tools when
-  there is no paused debugger state.
+## Watching Values
 
-## Tool Map
+`debug_watch` is print debugging without editing the method. Name the methods to
+probe, the variables to record, and the expression to run. Every assignment to a
+named variable is recorded as it happens, the expression runs to completion, and
+the probes are removed before the call answers.
 
-| Tool | Use |
-| --- | --- |
-| `debug_capture` | Evaluate a Smalltalk expression in a bounded worker process and capture runtime exceptions as tracked debug sessions. |
-| `debug_test_run` | Run one SUnit test method in a bounded worker process and capture failures or errors as tracked debug sessions. |
-| `debug_session_list` | List tracked debug sessions. |
-| `debug_session_get` | Inspect one tracked debug session summary. |
-| `debug_session_remove` | Remove a tracked debug session from the registry. |
-| `debug_candidate_search` | Search unattached open debugger candidates. |
-| `debug_candidate_attach` | Attach an open debugger candidate and return its debug state. |
-| `debug_state_get` | Return the current session snapshot: stack, selected frame, source, scopes, repair actions, and state-scoped refs. |
-| `debug_variable_get` | Expand scope and variable refs returned by `debug_state_get`. |
-| `debug_expression_evaluate` | Evaluate a Smalltalk expression in a selected debug frame. |
-| `debug_session_step_into` | Step into the selected frame of a tracked session. |
-| `debug_session_step_over` | Step over the selected frame of a tracked session. |
-| `debug_session_step_through` | Step through the selected frame of a tracked session. |
-| `debug_session_restart` | Restart the selected frame of a tracked session. |
-| `debug_session_resume` | Resume a tracked session. |
-| `debug_session_terminate` | Terminate a tracked session. |
-| `debug_breakpoint_list` | List tracked transient DebugPoint breakpoints. |
-| `debug_breakpoint_set` | Install a transient method-entry or source-interval DebugPoint breakpoint. |
-| `debug_breakpoint_remove` | Remove one tracked transient DebugPoint breakpoint. |
-| `debug_breakpoint_enable` | Enable one tracked transient DebugPoint breakpoint. |
-| `debug_breakpoint_disable` | Disable one tracked transient DebugPoint breakpoint. |
-| `debug_breakpoint_clear` | Remove all tracked transient DebugPoint breakpoints. |
-| `debug_method_update` | Update the method associated with a paused debug state, then proceed when possible. |
-
-## Session Workflow
-
-Use `debug_capture` when the agent should run code and capture its own
-failure. If execution completes normally, there is no debugger session. If a
-runtime exception is captured, use the returned `sessionId` and `state`.
-
-Use `debug_test_run` when the failure is already expressed as one SUnit test method.
-If the test passes, there is no debugger session. If it fails or errors, use the
-returned `sessionId` and `state`.
-
-Use `debug_candidate_search` when a human already opened a debugger. It returns
-unattached candidates with identifying details. Attach by passing the
-candidate's `candidateRef` to `debug_candidate_attach`.
-
-Use `debug_session_remove` when you are done. Removing an agent-owned captured
-session can terminate its worker process. Removing an attached human debugger
-only removes it from the MCP registry.
-
-## State And References
-
-Treat `stateId`, `frameRef`, and `variableRef` values as state-scoped opaque
-references. After a debug-session control tool or `debug_method_update`, old
-frame and variable refs can be stale. Use the new returned state before
-evaluating, expanding variables, or controlling execution again.
-
-Use `debug_state_get` as the main context-loading tool. Keep stack and variable
-limits small first, then expand details with `debug_variable_get` only when needed.
-
-Use `debug_expression_evaluate` only for expressions that need the selected frame's
-receiver or temporaries. Prefer normal code tools for project edits.
-
-## Control
-
-Use `debug_session_step_into`, `debug_session_step_over`,
-`debug_session_step_through`, `debug_session_restart`,
-`debug_session_resume`, and `debug_session_terminate` for control actions.
-Control tools can return a `debug_state_get` snapshot when execution pauses.
-Set `returnState=true` when the next step needs that snapshot inline;
-otherwise call `debug_state_get` after the control action.
-When the user asks for a bounded action, such as "step into twice", perform
-those control calls and stop.
-
-For externally attached debuggers, control should operate through the attached
-debugger controller so the visible debugger remains the owner of its UI. Do not
-manipulate debugger windows or contexts with general `image_evaluate` code.
-
-## Breakpoints
-
-Use the `debug_breakpoint_*` tools for temporary method-entry or
-source-interval DebugPoint breakpoints. Clear breakpoints when the debugging
-task ends.
-
-File/line breakpoints are intentionally not emulated. Resolve source intervals
-from the relevant method when source-interval precision is needed.
-
-## Debugger-Driven Development
-
-When a debug state offers repair actions, prefer `debug_method_update` over separate
-manual edits. It can create missing methods or recompile stub/selected methods,
-formats the compiled method, reports critiques, and proceeds when the edit is
-accepted.
-
-Read [Debugger-Driven Development](debugger-driven-development.md) before using
-`debug_method_update` for missing methods, `subclassResponsibility`,
-`shouldBeImplemented`, `notYetImplemented`, or iterative repair workflows.
-
-## Reporting
-
-When finishing debugger work, report:
-
-- how the session was obtained: capture, test, discovered debugger, or attached
-  debugger;
-- debugger tools called;
-- final session outcome: completed, paused, running, terminated, forgotten, or
-  still open;
-- breakpoints created, cleared, or left in place;
-- cleanup performed or still needed.
+Name no variable and each method's arguments are recorded as it is entered.
+Both `method` and `variable` take one value or a list, and a probe goes on every
+pair that exists, so a variable a method never assigns simply has no series there.
+
+Reach for it whenever the question is what a value became, rather than where to
+intervene.
+
+## Seeing A Person's Debuggers
+
+`debug_search` answers the debuggers open in the image: each one's name, the
+exception it stopped on, and the frames nearest the stop with what those frames
+hold. Pass a `query` to keep only the debuggers whose name or exception matches.
+
+It is a query and nothing else. It attaches to nothing, changes nothing, and
+remembers nothing, so the picture it gives is whatever is open at that moment.
+Ask again for a fresh one.
+
+Act on what it shows with the ordinary tools: read the method with `method_get`,
+change it with `method_compile`, run something with `image_evaluate`. Stepping,
+resuming and repairing from inside a frame belong to the person at the debugger,
+not to the agent.
+
+## To Debug Your Own Code
+
+Do not open a debugger for it. Call the tool that runs the code and read the
+failure it reports: it names the frames nearest the error and the values they
+held. When that is not enough, `debug_watch` shows how a value got there.
+
+## Do Not
+
+- Do not drive debugger windows or mutate contexts through general
+  `image_evaluate` code.
+- Do not resume, step or terminate a person's debugger. It is theirs.

package/templates/pharo-references/getting-started.md

@@ -5,7 +5,7 @@ connecting a client.
 
 ## Requirements
 
-- Pharo 12, 13, or 14
+- Pharo 12, 13, 14, or 15
 - An MCP client that supports Streamable HTTP directly or through a local bridge
 - Network access from the client to the image host
 
@@ -58,6 +58,14 @@ Dependencies can select the same group with `loads: #( 'Core' )`.
 
 ## Start And Stop
 
+```smalltalk
+mcp := MCP startOnPort: 4000.
+```
+
+That answers the server already on 4000 when the image has one, rather than
+failing on the port it holds. Build one by hand when it needs configuring
+before it starts:
+
 ```smalltalk
 mcp := MCP new.
 mcp port: 4000.
@@ -121,16 +129,16 @@ tool_get
 Then inspect the image with focused read-only tools such as:
 
 ```text
-package_search
 class_search
 class_get
-method_metadata_search
+method_search
 method_source_search
-method_implementor_search
-method_sender_search
+method_reference_search
 method_get
 ```
 
+`package_search` and the specialized tools are found with `tool_search`.
+
 Before mutation, inspect the target and use a copied or disposable image.
 Prefer dedicated tools such as `class_create`, `method_compile`, refactoring
 tools, and `test_run` over `image_evaluate`.

package/templates/pharo-references/pharo-coding-rules.md

@@ -100,7 +100,7 @@ over clients branching on concrete classes or internal fields.
 - Do not use `getName` or `setName:`.
 - Predicates should read as predicates: `isReady`, `hasErrors`,
   `canHandle:`.
-- Action selectors should use verbs: `parseRequest:`, `registerTool:`,
+- Action selectors should use verbs: `parseRequest:`, `addTool:`,
   `writeResponseOn:`.
 - Conversion selectors should start with `as`.
 

package/templates/pharo-references/pharo-coding-style.md

@@ -133,6 +133,8 @@ Scan for:
   `thenDo:` variant would avoid the intermediate collection;
 - sorting through conversion chains instead of sorting a result array directly;
 - defensive type checks in private helpers that hide caller bugs;
+- cascaded stream writes, where `stream << a; << b` says what `stream << a << b`
+  says with more punctuation, since `<<` answers the stream;
 - wrapper methods or extensions that exist only because a collaborator might be
   wrong someday;
 - dense nested expressions that would be clearer with a temporary or extracted

package/templates/pharo-references/safety-and-ecosystem.md

@@ -22,10 +22,22 @@ The execution path is:
 3. The concrete tool parses the request into a typed request or spec object.
 4. The tool dispatches a command or query object.
 5. The command uses Pharo APIs to query or mutate the image.
-6. The tool returns a payload with `status`, `summary`, `warnings`, and either
-   `data` or `error`. By default this payload is serialized into the MCP
-   `content` field; the server can also emit `structuredContent` for clients
-   that need programmatic results.
+6. The tool returns a payload with `summary`, `warnings`, and either `data` or
+   `error`, with a failure flagged by the protocol's own `isError`. By default
+   this payload reaches the MCP `content` field; the server can also emit
+   `structuredContent` for clients that need programmatic results.
+
+### Notifications
+
+A notification is not a failed call. Pharo signals them for remarks rather than
+faults, and every `Warning` is one. The tool boundary resumes them with the
+value the image itself would have produced and the call proceeds, so a
+deprecated send, or an undeclared variable during a package load, does not fail
+it. A deprecated method called from a test does not abort the suite.
+
+Refactoring warnings are the exception. `RBRefactoringWarning` reports a change
+that breaks something, so it reaches the boundary unresumed and stops the call,
+aborting a removal or a rename that `force=true` did not authorize.
 
 ```mermaid
 sequenceDiagram
@@ -104,44 +116,66 @@ Critiques include:
 The method may compile successfully and still return critiques. Treat critiques
 as follow-up review evidence, not as transport failures.
 
-## Rewrite Preview And Confirmation
+## Rewriting Methods
+
+`method_rewrite` uses Smalltalk AST rewrite patterns, not regex. A rule has a
+`match` and a `replacement`, and a scope is required, so rewriting everything is
+something a caller asks for by naming the packages rather than by leaving an
+argument out.
 
-`method_rewrite` uses Smalltalk AST rewrite rules. Patterns use RB AST pattern
-syntax, not regex.
+A metavariable starts with a backquote and stands for whatever is in its place.
+`` `@receiver `` matches one expression, however big: the same rule rewrites
+`anObject notNil` and `(anObject foo) notNil`. **The names must be the same on
+both sides** — a name that appears only in `replacement` is bound to nothing.
 
-The default mode is preview:
+The default mode is preview, which carries the old and new source of every
+change:
 
 ```json
 {
   "rules": [
     {
-      "lhs": "`@receiver ifTrue: [ `@body ]",
-      "rhs": "`@receiver ifTrue: [ `@body ]"
+      "match": "`@receiver notNil",
+      "replacement": "`@receiver isNotNil"
     }
   ],
-  "apply": false
+  "scope": { "packages": ["MyPackage"] }
 }
 ```
 
-Preview mode returns calculated changes and a `changeSetHash`. Applying requires
-the hash from a preview of the same request:
+A metavariable stands for a block just as readily, which is how a rule drops
+one branch of a conditional:
 
 ```json
 {
   "rules": [
     {
-      "lhs": "`@old",
-      "rhs": "`@new"
+      "match": "`@receiver ifTrue: [ `@body ] ifFalse: [ nil ]",
+      "replacement": "`@receiver ifTrue: [ `@body ]"
     }
   ],
-  "packageNames": ["MyPackage"],
-  "apply": true,
-  "expectedChangeSetHash": 123456
+  "scope": { "packages": ["MyPackage"] }
 }
 ```
 
-Applying to the whole image also requires `force=true`. Prefer an explicit
-package, class, hierarchy, or method scope.
+Add `apply` to make the changes. One call is enough; preview first only when
+you want to read them before they land. `history_entry_revert` undoes a rewrite
+that turned out wrong.
+
+Any rewrite rule stands for its own patterns, so its name can be given instead
+of writing them out. That includes Pharo's own, not only MCP's:
+
+```json
+{
+  "ruleClasses": ["MCPCollectionThenDoRule"],
+  "scope": { "packages": ["MyPackage"] },
+  "apply": true
+}
+```
+
+Rules that report a critique are not applied by the tools that compile. A
+compile reports what it would change; changing it is this tool's job, and the
+caller asks.
 
 ## Tests And Coverage
 
@@ -189,39 +223,72 @@ live image back to Tonel/Git.
 
 ## Debugging
 
-Debugger tools are discoverable through the `debugging` group. They work with
-tracked Pharo `DebugSession` records, captured worker-process exceptions,
-SUnit test failures, transient DebugPoint breakpoints, and attached human-opened
-debuggers.
-
-Treat debugger state references as opaque and state-scoped. After stepping,
-resuming, restarting, terminating, or editing from a debug state, use the newly
-returned state before expanding variables or evaluating in a frame again.
+Debugger tools are discoverable through the `debugging` group. They keep no
+state: `debug_watch` installs non-halting probes and removes them before it
+answers, and `debug_search` only reads the debuggers a person has open.
 
-Use `debug_method_update` only from a paused debug state and only after reading the
-offered repair actions. It uses the same critique gate as method editing before
-proceeding a repaired computation.
+A debugger somebody opened belongs to them. Read it, then act with the ordinary
+class and method tools; do not step, resume or terminate it.
 
 ## Evaluation Escape Hatch
 
-`image_evaluate` runs arbitrary Smalltalk and saves the image after a successful
-call. It is useful for short inspection or glue code when no dedicated tool
+`image_evaluate` runs arbitrary Smalltalk in the running image without saving
+it. It is useful for short inspection or glue code when no dedicated tool
 exists.
 
 Prefer a dedicated tool when one exists, because the dedicated tools validate
 input, return structured result data, and often use safer Pharo APIs.
 
+Compiling source is one of those cases. Method source in the image separates
+lines with CR, and `method_compile` normalizes what it is given; a bare
+`compile:` from `image_evaluate` stores whatever it receives, so source written
+with LF compares unequal to every other method in the image. Use
+`method_compile` for a method, and `withInternalLineEndings` if you must compile
+source by hand.
+
 ## Observability And UI
 
-The Spec dashboard is available from an inspected `MCP` object. It shows:
+The servers an image holds are listed under `Library → MCP Servers` in the
+world menu, and on the `Servers` tab of an inspected `MCP` class. From there a
+server can be started, stopped, or opened in its dashboard, and a new one
+created on a port, where 0 asks for a free one. The tool catalog sits beside it
+under `Library → MCP Tool Catalog`, since it describes the image rather than
+any one server. The same list in a script:
 
-- server status and port
+```smalltalk
+MCP allServers
+```
+
+It is taken from the heap rather than from a registry, so a server is never
+kept alive for being listable, and one that is still holding a port after its
+owner forgot it is shown rather than hidden.
+
+To reach the server on a port, whether or not this script is the one that
+started it, ask for the port rather than for a new server:
+
+```smalltalk
+MCP startOnPort: 4000
+```
+
+That answers the server already on 4000, starting it if it was stopped, and
+makes one only when the image has none there. Starting a second server on a
+taken port fails after a couple of seconds, and the error now says when the
+port is held by another MCP in the same image.
+
+An inspected `MCP` object has two Spec tabs. The dashboard runs the server:
+
+- server status, endpoint and port
 - debug mode
-- registered tools and descriptions
-- observability status
+- every tool the server could run, with `Enabled` for whether it has the tool
+  at all and `Listed` for whether `tools/list` shows it; an unlisted tool is
+  still found by `tool_search` and still runs
+
+The observability tab shows what the server recorded about itself:
+
 - per-tool timing metrics
 - traces for errors, outliers, and output overruns
 - recent logs
+- auto-refresh while the tab is displayed
 
 MCP starts with the built-in JSON observability backend enabled. Disable it for
 a specific server when its local metrics, traces, and logs are not wanted:
@@ -251,5 +318,5 @@ mcp useOpenTelemetryObservability
 
 The core baseline loads PharoBackwardCompatibility, JRPC, and PCRE2.
 OpenTelemetry is loaded only by the optional `Telemetry` group. CI covers
-Pharo 12, 13, and 14. Code should target the Pharo 14 API; PharoBackwardCompatibility
-backports supported APIs to older images.
+Pharo 12, 13, 14, and 15. Code should target the Pharo 14 API;
+PharoBackwardCompatibility backports supported APIs to older images.