@evref-bl/pharo-mcp 3.4.0 → 3.5.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@evref-bl/pharo-mcp",
3
- "version": "3.4.0",
3
+ "version": "3.5.0",
4
4
  "description": "Pharo MCP agent-host templates",
5
5
  "license": "MIT",
6
6
  "type": "module",
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: pharo-image-sync
3
- description: Move code between a live Pharo image and its Tonel files, and tell the two apart. Use before exporting image changes, after a checkout moves under the image, and whenever Iceberg, the image and the files disagree.
3
+ description: Move code between a live Pharo image and its Tonel files, and tell the two apart. Use before exporting image changes, after a checkout moves under the image, before saying what is or is not committed, and whenever Iceberg, the image and the files disagree.
4
4
  ---
5
5
 
6
6
  # Pharo Image Sync
@@ -12,6 +12,27 @@ Iceberg diff does not mean anything was written to disk.
12
12
  Git itself is ordinary shell work. These tools only cross the boundary between
13
13
  the image and the files.
14
14
 
15
+ ## What Is Committed
16
+
17
+ The user may commit through Iceberg at any time, and nothing tells you. What
18
+ you remember changing is not evidence that it is uncommitted, so ask before
19
+ calling anything unsaved or at risk.
20
+
21
+ - `git log` in the checkout says what was committed. Iceberg commits are
22
+ ordinary git commits, so it answers even when the image does not.
23
+ - `repository_search` with `isModified` names the repositories and packages
24
+ Iceberg marks as changed since they were last written. A mark says where to
25
+ look, not that something differs: an edit that was undone, or a test that
26
+ compiled and removed a method, leaves one too.
27
+ - `repository_change_list` compares a repository's marked packages with its
28
+ files and names those that really differ, and the files git sees changed.
29
+ Anything not committed is in one of them.
30
+ - To know whether one change is committed, compare `method_get` with the
31
+ class's file at `HEAD` (`git show HEAD:<path>`).
32
+
33
+ `git status` cannot answer for the image: Iceberg writes files only when it
34
+ commits or exports, so the checkout stays clean while the image holds changes.
35
+
15
36
  ## Out Of The Image
16
37
 
17
38
  1. Verify which repository you are about to write to: `repository_search` for
@@ -11,7 +11,8 @@ standalone image without a safer environment-specific recovery surface.
11
11
  ## Workflow
12
12
 
13
13
  1. Determine whether the failure is the client route, MCP server, image, or
14
- process.
14
+ process. A client that cannot reach the server says nothing yet about the
15
+ image.
15
16
  2. Preserve the image, changes, sources, VM logs, launch command, MCP URL, and
16
17
  repository/Git facts before mutation.
17
18
  3. Restart the same image first. Inspect `isRunning`, `isListening`, and
@@ -19,7 +20,10 @@ standalone image without a safer environment-specific recovery surface.
19
20
  4. Create a replacement image only after preserving the original. Use
20
21
  `pharo-project-load` to restore MCP and the target project.
21
22
  5. Recover changes by inspecting Epicea history before confirmed application.
22
- Use `pharo-image-sync` before repository attachment or Tonel export.
23
+ History lists every change since the image started, committed or not:
24
+ check a change against the checkout's `git log` before naming it as lost,
25
+ as `pharo-image-sync` says. Use it too before repository attachment or
26
+ Tonel export.
23
27
  6. Verify the recovered behavior with focused inspection or tests.
24
28
 
25
29
  ## Stop And Ask
@@ -1,48 +1,40 @@
1
1
  # Pharo MCP Agent Guide
2
2
 
3
- Use the configured `pharo` MCP server whenever a task depends on the running
4
- image. Preserve unrelated changes, and say which live check you could not run
5
- rather than letting source stand in for it.
3
+ Use the `pharo` MCP server whenever a task depends on the running image.
4
+ Preserve unrelated changes, and say which live check you could not run rather
5
+ than letting source stand in for it.
6
6
 
7
7
  ## Read First
8
8
 
9
- - Inspect the tools and schemas exposed by the current client; do not rely on
10
- remembered names. `tool_search` finds what is not advertised, and `tool_get`
11
- answers one tool's schema.
12
- - Prefer the least-mutating dedicated tool. Use `image_evaluate` only when no
13
- dedicated tool fits.
14
- - Treat image, Tonel, Iceberg, and Git state as separate. None of them proves
15
- anything about the others.
16
- - The image is one workspace. It has no branches and no worktrees, so two
17
- agents working in it at once share every edit, and one export writes both
18
- their changes into one diff. One writer at a time.
19
- - Tools change the running image but never save it; use a safe image boundary.
9
+ - Look tools up rather than recall them: `tool_search` finds what the image
10
+ does not advertise, `tool_get` gives a tool's schema.
11
+ - Prefer the least-mutating dedicated tool; `image_evaluate` only when none
12
+ fits.
13
+ - Image, Tonel, Iceberg and Git are separate states; none proves anything
14
+ about another.
15
+ - An image takes one writer: it has no branches, so two agents in it share
16
+ every edit.
17
+ - Tools never save the image.
18
+ - The user may commit through Iceberg unseen: ask the image and the checkout
19
+ before calling any work uncommitted.
20
20
 
21
21
  ## Context Loading
22
22
 
23
- - Before Pharo source changes: read the project's Pharo coding and testing
24
- guidance. If none exists, use the local
25
- [Pharo coding](pharo-references/pharo-coding.md) reference.
26
- - Before reading an answer closely, rewriting methods, or acting on a warning a
27
- call came back with: read
23
+ - Changing Pharo code: the project's coding guidance, or else
24
+ [Pharo coding](pharo-references/pharo-coding.md).
25
+ - Reading an answer closely, rewriting methods, or acting on a warning:
28
26
  [tool reference](pharo-references/tool-reference.md).
29
- - Before loading a project: use `skills/pharo-project-load/SKILL.md`.
30
- - Before moving code between the image and its files: use
27
+ - Loading a project: `skills/pharo-project-load/SKILL.md`.
28
+ - Moving code between the image and its files, or saying what is committed:
31
29
  `skills/pharo-image-sync/SKILL.md`.
32
- - Before reproducing smalltalkCI or GitHub failures: use
33
- `skills/pharo-ci-repro/SKILL.md`.
34
- - Before profiling or optimizing Pharo code: use
35
- `skills/pharo-code-profiling/SKILL.md`.
36
- - Before recovering a stopped standalone image: use
37
- `skills/pharo-mcp-recovery/SKILL.md`.
30
+ - Reproducing smalltalkCI or GitHub failures: `skills/pharo-ci-repro/SKILL.md`.
31
+ - Profiling: `skills/pharo-code-profiling/SKILL.md`.
32
+ - Recovering a stopped standalone image: `skills/pharo-mcp-recovery/SKILL.md`.
38
33
 
39
34
  ## Workflow
40
35
 
41
- 1. Discover the exact tool and inspect the target with read-only calls.
42
- 2. Preview or verify identity before risky mutation.
43
- 3. Make the narrowest image-side change.
44
- 4. Run focused SUnit tests and inspect the result.
45
- 5. Use the image-sync skill before exporting or committing Tonel changes.
46
-
47
- For repository work, verify repository identity before mutation and inspect the
48
- image-side diff before export or commit.
36
+ 1. Inspect with read-only calls.
37
+ 2. Verify identity before a risky change.
38
+ 3. Make the narrowest change in the image.
39
+ 4. Run focused tests.
40
+ 5. Use the image-sync skill before exporting or committing.