@sinoia/hubdoc-tools 1.13.0 → 1.13.1

package/cli.js

@@ -735193,7 +735193,7 @@ async function handleTasksReorder(opts) {
 // apps/cli/cli.ts
 var getVersion = () => {
   try {
-    if (true) return "1.13.0";
+    if (true) return "1.13.1";
   } catch {
   }
   for (const candidate of [

package/docs/llm-usage.md

@@ -428,29 +428,32 @@ actions, one HTTP round-trip each:
   content is auto-saved by every write; `save` is just for the explicit
   version snapshot.
 
-**Concurrency & merge — handled server-side, no client state** :
+**Concurrency & merge — server-side, current limitations** :
 
 Each write action executes on the server as a single load-blob → mutate
-→ save-blob → `publish Documents::FileContentUpdated` cycle. Two agents
-running `hubdoc md insert` in parallel serialise at the Rails +
-ActiveStorage level; the second one loads the first one's result before
-applying its own. No client-side coordination or CRDT to maintain.
-
-Cross-modal coordination (agent + human on the web UI): every write
-broadcasts `content_refresh` over `DocumentEditingChannel`, which the
-frontend's Y.js session reloads from server content. Cf. the corex
-design `.claude/context/designs/y-rb-implementation.md`.
-
-**Inter-agent coordination via events** :
-
-```bash
-# Agent B watches for edits on the file, reacts.
-hubdoc events watch \
-    --type Documents::FileContentUpdated \
-    --timeout 900 --json \
-    | jq -r '.items[-1].data.file_id'
-# → returns as soon as another agent (or the human) touches the file.
-```
+→ save-blob → `publish Documents::FileContentUpdated` cycle. Cross-modal
+broadcasts still work: every server-side write broadcasts
+`content_refresh` over `DocumentEditingChannel`, and the web UI's Y.js
+session reloads from server content. Cf. the corex design
+`.claude/context/designs/y-rb-implementation.md`.
+
+> ⚠️ **Known limitation — lost-update race on concurrent writes**
+> (tracked in [corex#595](https://code.plugandwork.net/sinoia/corex/-/issues/595)):
+> two `hubdoc md insert`/`replace`/`write-section` calls firing in
+> parallel on the **same file** may silently drop one of the writes —
+> the load→save cycle is not yet atomic. Until corex ships a PG advisory
+> lock on `MarkdownEditor#execute`, treat writes on any given file as
+> **sequential**: chain your CLI calls with `await`, or coordinate via
+> an out-of-band lock. Writes on *different* files stay safe.
+
+> ⚠️ **Known limitation — `Documents::*` events not yet on `/api/v1/events`**
+> (tracked in [corex#596](https://code.plugandwork.net/sinoia/corex/-/issues/596)):
+> the events API was initially scoped to `Projects::*` types (corex#593).
+> `hubdoc events watch --type Documents::FileContentUpdated` returns
+> nothing today — agent-to-agent coordination on markdown edits is on
+> hold until that scope is opened. In the meantime, coordinate via the
+> ticket the file belongs to (`ticket.updated`, `ticket.comment`) or via
+> an external channel.
 
 **Typical agent workflow — build a section incrementally without racing** :
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sinoia/hubdoc-tools",
-  "version": "1.13.0",
+  "version": "1.13.1",
   "description": "Professional command-line tool for HubDoc document management and bulk import/export",
   "main": "cli.js",
   "bin": {