hook

The follow-up check-updates.sh defers to is done.

What the comment says today

# (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.)

What shipped

adom-wiki-cli 1.0.39 closes that gap for every caller, not just the hook's own runs (adom/adom-wiki-cli#5):

1. Install lock. All mutating pkg verbs (install / add / uninstall / update / ci / bootstrap) take an exclusive lock on PREFIX/.install.lock, held for the process. It blocks with a "waiting for another install" note rather than failing, since these runs take seconds. This also closes the last-write-wins clobbering of .installed.json / .lock.json.
2. Atomic extract. Each package stages into a sibling <module_dir>.tmp-<pid> and is renamed into place, so no process can observe a half-written module dir even if an installer is killed mid-extract.

Verified against the exact failure this hook was seeing: 30 concurrent installs of adom/adom-ui-design went from 23 failures to 0. The failures included both the reported cp: cannot stat skills/<x>/SKILL.md and tar itself dying ("failed to extract tarball") when its target dir was wiped mid-extract.

Ask

No functional change needed. flock -n 9 is still worth keeping as a cheap "don't stack a second updater" guard; it is now belt-and-suspenders rather than the only thing between a cron tick and a corrupted module dir.

But the comment is now wrong and will mislead the next reader into thinking manual-vs-hook races are still unguarded. Suggest updating it to note the CLI lock covers all callers as of adom-wiki-cli 1.0.39, and that the hook flock remains only to avoid stacking redundant updaters.

Worth knowing for the fleet: containers still on a pre-1.0.39 CLI do not have this fix. As of today the registry's client telemetry still shows CLIs as old as 1.0.2 checking in, i.e. the corruption is still live wherever the core bootstrap was never installed.