chore(mops-cli): sync caffeinelabs/mops cli-v2.20.0 (#347)

Author: marc0olo

.claude/upstream.md

@@ -77,8 +77,8 @@ Upstream file paths and the tracking model (release-tag vs commit) are listed pe
 ## mops-cli
 
 - **Upstream:** https://github.com/caffeinelabs/mops
-- **Tag:** cli-v2.19.0
-- **Commit:** be449cbeaf8bd9ce6c929b3ceb41591afe8bedca
-- **Last synced:** 2026-07-28
+- **Tag:** cli-v2.20.0
+- **Commit:** a079cb8c4d752403cc1d68c7bcc04a3be71dadf9
+- **Last synced:** 2026-08-11
 - **Upstream file:** `.agents/skills/mops-cli/SKILL.md`
 - **icskills-owned sections:** none — body is 1:1 with upstream; only frontmatter differs

evaluations/mops-cli.json

@@ -79,10 +79,20 @@
       "expected_behaviors": [
         "Explains the warning is because `pocket-ic` is not pinned in `[toolchain]`, so mops falls back to the deprecated dfx replica",
         "Pins `pocket-ic` in the `[toolchain]` section of mops.toml (e.g. `pocket-ic = \"12.0.0\"`) OR uses `mops toolchain use pocket-ic 12.0.0`",
-        "Pins a specific pocket-ic version rather than `latest` (latest may resolve to a version the bundled pic-js client doesn't support)",
+        "Pins a specific pocket-ic version rather than `latest` (latest may resolve to a version the vendored `@dfinity/pic` client doesn't support)",
         "Notes the same pin also applies to `mops bench` and `mops watch`"
       ]
     },
+    {
+      "name": "Adversarial: mops publish --dry-run scope",
+      "prompt": "Before publishing my package to the mops registry, I ran `mops publish --dry-run` and it passed. Does that mean the real `mops publish` is guaranteed to succeed? Just answer the question.",
+      "expected_behaviors": [
+        "Explains that `--dry-run` runs the same local publish pipeline (packaging checks, docs, changelog, tests, benchmarks) but stops before identity/upload (no registry contact)",
+        "Clarifies it does NOT validate canister config (SPDX/semver/name rules)",
+        "Clarifies it does NOT prove registry acceptance (already published, permissions, missing deps)",
+        "Does NOT claim a passing `--dry-run` guarantees the real publish will succeed"
+      ]
+    },
     {
       "name": "check-stable baseline bootstrap",
       "prompt": "I'm starting a brand-new mops project and want to enable `check-stable`. There's no deployed version yet, so what do I use as the `.most` baseline for `[check-stable].path`? Just the setup, no deploy steps.",
@@ -180,7 +190,8 @@
       "How do I regenerate the candid .did file for my Motoko canister with mops?",
       "How do I keep my check-stable .most baseline in sync after deploying?",
       "How do I enable wasm-opt optimization for my mops build?",
-      "How do I run benchmarks with mops?"
+      "How do I run benchmarks with mops?",
+      "How do I publish my package to the mops registry?"
     ],
     "should_not_trigger": [
       "Write a Motoko persistent actor with a counter",

skills/mops-cli/SKILL.md

@@ -2,7 +2,7 @@
 name: mops-cli
 description: "Manage Motoko projects with the mops CLI — toolchain pinning, dependency management, type-checking, building, and linting. Use when working with mops.toml, mops.lock, running mops commands, adding/removing packages, pinning moc or lintoko versions, checking or building canisters, configuring moc flags, or setting up a new Motoko project."
 license: Apache-2.0
-compatibility: "mops >= 2.19.0"
+compatibility: "mops >= 2.20.0"
 metadata:
   title: Mops CLI
   category: Infrastructure
@@ -86,7 +86,7 @@ mops install --lock update   # regenerate a stale/corrupt mops.lock
 mops install --lock check    # fail if lockfile is missing or stale (CI)
 ```
 
-Run after cloning or after manual `mops.toml` edits. Updates `mops.lock` by default.
+Run after cloning or after manual `mops.toml` edits. Updates `mops.lock` by default. Local path dependencies are stored root-relative in the lockfile (portable across machines). A plain install will not rewrite absolute paths left by older CLIs — use `mops install --lock update`, and ensure every environment has a CLI that understands relative lock paths.
 
 When the `CI` env var is set and `--lock` is omitted, defaults to `--lock check` (deprecated — pass `--lock check` explicitly; auto-detection will be removed in v3). A stale lock fails with a hint to run `mops install --lock update`.
 
@@ -157,7 +157,7 @@ mops generate candid backend -o <path>   # single canister, ad-hoc path
 mops toolchain use moc 1.7.0         # pin specific version
 mops toolchain use moc latest        # pin latest version (non-interactive)
 mops toolchain use lintoko 0.10.0    # pin specific version
-mops toolchain use pocket-ic 12.0.0  # pin for replica tests / benchmarks (pin a specific version; `latest` may resolve to one the bundled pic-js client doesn't support)
+mops toolchain use pocket-ic 12.0.0  # pin for replica tests / benchmarks (pin a specific version; `latest` may resolve to one the vendored `@dfinity/pic` client doesn't support)
 mops toolchain use wasm-opt 131      # Binaryen for [optimize] (or `latest`)
 mops toolchain update moc            # update to latest (requires existing [toolchain] entry)
 mops toolchain update                # update all tools to latest
@@ -167,6 +167,8 @@ mops toolchain info <tool> --versions --all # full stable history (cache warming
 mops toolchain bin moc               # print path to binary
 ```
 
+**`pocket-ic` versions**: `9.0.0` and newer run on the vendored `@dfinity/pic` client. Pins below `9.0.0` still work on the legacy `pic-ic` client but print a deprecation warning and are removed in mops v3 — pin `9.0.0` or newer.
+
 **Agent note**: `toolchain use <tool>` without a version opens an interactive picker — do not use in scripts or agents. Always pass a version or `latest`. `toolchain update` only works when the tool already has a `[toolchain]` entry. `toolchain info <tool> --versions` works without `mops.toml` (first GitHub page by default; pass `--all` for full history).
 
 ### Enhanced migrations
@@ -202,6 +204,17 @@ mops sync                 # add missing / remove unused packages
 
 ## Other Commands
 
+### `mops publish`
+
+```bash
+mops publish              # publish to the registry (runs tests/docs/bench by default)
+mops publish --dry-run    # same local steps as publish; no registry contact / identity
+mops publish --dry-run --no-test --no-docs --no-bench   # packaging checks only
+mops publish --no-test --no-docs --no-bench
+```
+
+`--dry-run` runs the same local publish pipeline (packaging checks, docs, changelog, tests, benchmarks) and prints the final file list, then stops before identity/upload. `--no-*` flags work as usual. It does **not** run canister config validation (SPDX/semver/name rules) or prove registry acceptance (already published, permissions, missing deps).
+
 ### `mops test`
 
 Tests live in `test/*.test.mo`: