@parall/parall 1.59.0 → 1.61.0

package/package.json

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

package/skills/parall-wiki/SKILL.md

@@ -59,59 +59,58 @@ 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.
 
-It stops and tells you when the merge could not settle things — changes diff3
-cannot merge on its own (both sides touched the same or adjacent lines), a
-binary, or a server that keeps moving. Then:
-
-Follow the ordered sequence in **Sync conflicts** below for each listed path —
-the error text carries the same steps. Editing the file into a hand-merged
-state and proposing does NOT work: the baseline only advances when your file
-matches the server, so you would loop on the same error.
+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 at line level (diff3): when both you and the server
+`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 diff3 cannot merge them (both sides touched
-the same or adjacent lines), the file is binary, or it is too long or too
-repetitive to merge within the CLI's time budget, 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 |
-
-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>
-parall wiki sync
+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:
 
-# Accept the server's delete (.remote-deleted only):
-rm <workspace>/<path>
-parall wiki sync
-
-# Keep your changes ON TOP of the server's version — this exact order:
-cp <workspace>/<path> <workspace>/<path>.mine                            # 1. save yours
-cp <workspace>/.parall-wiki/conflicts/<path>.remote <workspace>/<path>   # 2. match the server
-parall wiki sync                                                         # 3. baseline advances
-# 4. re-apply your changes to <workspace>/<path> using <path>.mine, then delete <path>.mine
-parall wiki changeset create <wiki> --title "..."                        # 5. propose
+```
+<<<<<<< mine (parall-merge)
+your version of the lines
+======= (parall-merge)
+the server's version of the lines
+>>>>>>> latest (parall-merge)
 ```
 
-**Step 2 + 3 are not optional.** `sync` advances a path's baseline only when
-your file matches the server byte-for-byte. Hand-merging both sides into the
-file and proposing leaves the baseline stale, so propose is rejected, recovery
-re-syncs, and the path conflicts again — the same error every time. (For a
-`.remote-deleted` marker, "keep yours" is the same shape: `rm` the file,
-`sync`, then write your content back — it proposes as a new file.)
-
-Then 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
 
@@ -195,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 =