@parall/parall 1.58.2 → 1.60.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@parall/parall",
-  "version": "1.58.2",
+  "version": "1.60.0",
   "description": "OpenClaw channel plugin for Parall IM",
   "license": "MIT",
   "repository": {
@@ -16,8 +16,8 @@
     "openclaw.plugin.json"
   ],
   "dependencies": {
-    "@parall/agent-core": "1.58.2",
-    "@parall/sdk": "1.58.2"
+    "@parall/agent-core": "1.60.0",
+    "@parall/sdk": "1.60.0"
   },
   "devDependencies": {
     "@types/node": "^22.0.0",

package/skills/parall-wiki/SKILL.md

@@ -52,43 +52,65 @@ paths stay open for human review. Follow the returned `next_action` either way.
 
 ## Stale base (server moved since your sync)
 
-If files changed on the server after your last sync, `changeset create` is
-rejected — both by a CLI precheck and by the server (409 `STALE_BASE`) — so
-you can't silently overwrite someone's concurrent edit. Recovery:
+If files changed on the server after your last sync, `changeset create`
+recovers on its own: it re-syncs (a three-way merge that keeps your edits and
+folds non-overlapping upstream changes into your files), then proposes again
+once. When this happened the result says so (`stale_recovery`, and the
+`next_action` text) — re-read any file it names before editing further, since
+your copy now contains the upstream changes too.
 
-```bash
-parall wiki sync          # pull latest; your local edits are preserved
-# if a file conflicts, resolve it (see next section)
-parall wiki changeset create <wiki> --title "..."
-```
+It stops and tells you when the merge could not settle a file on its own. That
+is not a dead end: see **Sync conflicts** — the fix is always "make the file say
+what you want, then propose again".
 
 ## Sync conflicts
 
-`sync` three-way merges. When both you and the server changed the same file,
-your file is left intact and the upstream copy lands under
-`<workspace>/.parall-wiki/conflicts/`:
-
-| Marker | Meaning |
-|--------|---------|
-| `conflicts/<path>.remote` | Server has different content for `<path>` |
-| `conflicts/<path>.remote-deleted` | Server deleted `<path>`; you still have edits |
+`sync` three-way merges at line level (diff3). When both you and the server
+changed the same file and the changed hunks do not overlap — at least one
+unchanged line separates them — the upstream changes are merged into your copy
+and your edits stay pending. When they DO overlap (both sides touched the same
+or adjacent lines), `sync` writes the conflict into your file the way git does:
 
-All paths below are relative to the workspace root. Pick one:
-
-```bash
-# Accept upstream (drop your edit):
-cp <workspace>/.parall-wiki/conflicts/<path>.remote <workspace>/<path>
-
-# Keep yours / hand-merge: edit <workspace>/<path> to final content, then
-parall wiki changeset create <wiki> --title "Reconcile <path>"
-
-# Accept server delete (.remote-deleted only):
-rm <workspace>/<path>
+```
+<<<<<<< mine (parall-merge)
+your version of the lines
+======= (parall-merge)
+the server's version of the lines
+>>>>>>> latest (parall-merge)
 ```
 
-Then re-run `parall wiki sync` and delete the used marker file. Conflicts
-exit 0 (they need your decision); `failed[]` entries (download error,
-shape-conflict) exit 1 and retry on the next sync.
+The `(parall-merge)` tag is what tells a real delimiter from a quoted example:
+if the page itself contains that block verbatim (say, a page documenting this
+feature), the delimiters of a new conflict read `(parall-merge-2)`, then
+`-3`, and so on. `sync` remembers which set it wrote for the file, and only
+that set is live: propose refuses the file while **any** line of that set is
+still in it — a lone opener or closer left from a half-finished hand merge
+counts — and treats every other set (quoted examples) as content. Everything
+outside the blocks is already merged. Your pre-merge copy is kept at
+`<workspace>/.parall-wiki/conflicts/<path>.mine`.
+
+**Your baseline has already moved to the server's version.** There is nothing
+to sync, restore or re-apply: edit each block so the file says what you want
+(keep one side, or combine them), delete the three marker lines, and run
+`parall wiki changeset create` again. A file that still contains any
+`<<<<<<< mine (parall-merge…)` / `======= (parall-merge…)` /
+`>>>>>>> latest (parall-merge…)` line of the set written for it is
+refused at propose, so you cannot ship one by accident.
+
+The other shapes follow the same rule — the working tree already holds what you
+meant, propose sends it:
+
+| The error says | Working tree now | To finish |
+|---|---|---|
+| overlapping block(s) marked in the file | your file with `<<<<<<< mine (parall-merge)` blocks; `.mine` copy aside | edit the blocks away, propose |
+| not merged in place (binary, LFS, too long/repetitive, or markers from an earlier sync still unresolved) | your file untouched; the server's bytes at `conflicts/<path>.remote` | fold what you want from `.remote` into your file, propose |
+| the server changed it and you deleted it | no file (your delete stands); server's bytes at `conflicts/<path>.remote` | propose to delete the server's newer version too, or copy `.remote` back to `<workspace>/<path>` to keep it |
+| the server deleted it and you still have edits | your file, now a new file (it stays on its old baseline while it still carries an unresolved block — edit that away first) | propose to recreate it, or `rm` it to accept the removal |
+
+Conflict artifacts under `.parall-wiki/conflicts/` are removed on their own
+once the path is proposed or back in step with the server. Conflicts exit 0
+(they need your decision); `failed[]` entries (download error, shape-conflict)
+exit 1 and retry on the next sync.
 
 ## Changesets
 
@@ -172,10 +194,16 @@ a `Request approval:` hint — use `parall wiki request-access <path> --reason
 ## Recovery
 
 ```bash
-parall wiki reset <wiki>    # discard ALL local edits, restore last-synced state
+parall wiki reset <wiki>    # discard ALL local edits, restore the synced baseline
 parall wiki status <wiki>   # local changes + your changesets, anytime
 ```
 
+After a conflict the synced baseline IS the server's version, so `reset` gives
+you the server's file; your pre-merge edits are still under
+`.parall-wiki/conflicts/<path>.mine` until that path is proposed, or until a
+later `sync` finds it back in step with the server (clean or fast-forwarded)
+and removes the copy.
+
 ## Changeset Discipline
 
 - Creation is fail-closed — without explicit CLI confirmation of success,

package/src/gateway.ts

@@ -12,6 +12,7 @@ import {
   parseDispatchDeadlineMs,
   identityFromMe,
   initAgentTelemetry,
+  resolveServiceVersion,
   createOtelLogger,
   type DispatchAdapter,
   type ParallEvent,
@@ -442,7 +443,11 @@ export const parallGateway: ChannelGatewayAdapter<ResolvedParallAccount> = {
     setAgentIdentity(identityFromMe(me));
     log?.info(`parall[${ctx.accountId}]: authenticated as ${me.display_name} (${agentUserId})`);
 
-    const telemetry = await initAgentTelemetry('parall-openclaw-agent', 'openclaw');
+    const telemetry = await initAgentTelemetry('parall-openclaw-agent', 'openclaw', {
+      apiUrl: process.env.PRLL_API_URL,
+      apiKey: process.env.PRLL_API_KEY,
+      serviceVersion: resolveServiceVersion(import.meta.url),
+    });
     const otelLog = createOtelLogger('agent', 'openclaw-agent');
     try {
       const stateDir =