hook

@@ -82,8 +82,22 @@ fi # `pkg install adom/core` re-resolves and pulls any newly added core deps. Both # run regardless (as before), and the status reflects a failure of EITHER, with # the install failure preferred since installing core is the actual goal.+#+# CONCURRENCY: cron (*/30 + @reboot) and UserPromptSubmit can fire within the same+# second, and the STATUS='running' check has a check-then-write gap. Two updaters+# racing into the same package extraction (which is NOT atomic -- it wipes and+# repopulates the module dir in place) makes one see a half-written tree, e.g.+# `cp: cannot stat 'skills/.../SKILL.md'`. The flock below serializes the hook's+# own updaters: the second to arrive skips instead of stacking. It is held for the+# WHOLE background update (inside the subshell), not just the parent launch.+# (It does NOT cover a MANUAL `adom-wiki pkg install` racing the hook -- that needs+# a CLI-level install lock. See adom/hook #1 follow-up.) echo running > "$STATUS" 2>/dev/null (+  if command -v flock >/dev/null 2>&1; then+    exec 9>"${ADOM_DIR}/update.lock" 2>/dev/null || true+    flock -n 9 2>/dev/null || { rm -f "$STATUS" 2>/dev/null; exit 0; }+  fi   adom-wiki pkg update > "$LOG" 2>&1   u=$?   adom-wiki pkg install adom/core >> "$LOG" 2>&1

@@ -1,6 +1,6 @@ {   "slug": "hook",-  "version": "1.1.9",+  "version": "1.2.0",   "type": "app",   "org": "adom",   "bundled": true,

@@ -1,6 +1,6 @@ {   "slug": "hook",-  "version": "1.1.9",+  "version": "1.2.0",   "type": "app",   "org": "adom",   "bundled": true,