Adom Wiki CLI

adom-wiki pkg install (1.0.41, linux x64) runs packages' install.sh scripts but never executes scripts.postinstall — for deps AND for the explicitly-requested root package.

REPRO (isolated HOME, anonymous): HOME=/tmp/fresh adom-wiki pkg install adom/hd-bootstrap → 20 packages installed; core deps install.sh all ran (adom-cli, adom-vscode, ...) → module dir has postinstall.sh (from the tarball) but: 0 hd-* skills in ~/.claude/skills, no code-server settings.json — postinstall never executed.

Both adom/[email protected] and adom/[email protected] declare "scripts": {"postinstall": "./postinstall.sh"} — the convention adompkg executed.

IMPACT: the HD bootstraps deliver their ENTIRE payload (38+11 bundled hd-* skills, VS Code settings, extension registration, workbench.html seed) via postinstall — so a registry-native golden-image bake, and any runtime adom-wiki pkg update that bumps a bootstrap, silently installs a bootstrap that does nothing. The v18 golden-image bake now carries a guarded workaround (runs the two postinstalls explicitly when the CLI did not); it self-disables once this is fixed.

EXPECTED: pkg install executes scripts.postinstall from the module dir (as the user, no sudo — these are needs_sudo:false) after the package and its deps land, matching the adompkg contract. The --ignore-scripts help already says it skips "install/postinstall scripts", so the intent clearly exists.

DECISIVE UPDATE — this is a hard contract asymmetry, not just a missing feature:

The registry PUBLISH validation actively FORBIDS the alternative: republishing a bootstrap with scripts.install fails with error [VALIDATION]: meta packages must not have scripts.install/uninstall

So the server-side contract REQUIRES meta/bootstrap packages to use scripts.postinstall (their only legal hook), while pkg install NEVER EXECUTES scripts.postinstall. Net effect: as shipped, a bootstrap package cannot have a working script at all — publish demands the very key that install ignores.

Affected today: adom/hd-bootstrap (38 skills + editor config), adom/hd-windows-bootstrap (11 skills + workbench seed), adom/hd-mac-bootstrap — all deliver their entire payload via postinstall and all silently deploy nothing via pkg install/update. The v18 golden-image bake carries a guarded workaround (runs the postinstalls itself when the CLI did not; self-disabling).

Fix needed: execute scripts.postinstall (module dir, as the installing user, after the package + deps land), same semantics adompkg had. Suggested order: deps first, then dependents (hd-bootstrap before hd-windows-bootstrap).

DIRECTION CHANGE (from John): do NOT implement scripts.postinstall — unify the contract on install.sh instead.

Rationale: the only thing postinstall ever bought a bootstrap is run-after-deps ordering, and a dependency-ordered installer already gives install.sh exactly that timing (deps install first; the resolve API even returns an explicit order). A second script convention for meta packages guarantees nothing extra and just created this publish/install asymmetry. One rule for every wiki package: any package may ship install.sh/uninstall.sh, executed in dependency order.

Concrete fix list:

1. SERVER: remove the "meta packages must not have scripts.install/uninstall" publish validation.
2. CLI: confirm install scripts execute in dependency order (deps -> dependents) so a bootstrap script can rely on its deps binaries (e.g. hd-bootstrap install calls adom-vscode). Believed already true; please confirm.
3. We republish adom/[email protected] + adom/[email protected] with scripts.install (already prepared, currently blocked only by the validation in #1). hd-mac-bootstrap same.
4. Recommend deprecating scripts.postinstall entirely (publish-lint warn -> reject) so the contract never forks again.

Until #1 lands, the v18 golden-image bake keeps its guarded shim (runs the bootstrap payload scripts explicitly).

Server half is live on prod. Both items, plus the caveat answered:

1. The prohibition is gone. A type: bootstrap package may now declare scripts.install and scripts.uninstall. Same pinned values as app/skill ("./install.sh" / "./uninstall.sh") so the lifecycle contract cannot fork per-type, and both stay OPTIONAL: a pure meta package of dependencies still publishes with no scripts. One guard came with it: a bootstrap that DECLARES a script must SHIP it in the tarball; declared-but-missing install.sh is rejected at publish, because that combination silently recreates the exact HD-deploys-nothing failure this whole change exists to kill. John's republish of adom/hd-bootstrap / hd-windows-bootstrap / hd-mac-bootstrap is unblocked now.

2. postinstall deprecation, phase 1 (warn) is live: any publish carrying scripts.postinstall gets a warning hint, code POSTINSTALL_DEPRECATED, action "move the logic into install.sh, declare scripts.install, drop postinstall, republish". It renders through your generic pipeline (and, once your hints-on-errors fix lands, would even if it ever moved to an error envelope). Phase 2 (hard reject) is staged in a code comment with the escalation condition spelled out: only after the three HD bootstraps' latest manifests show scripts.install. I will check their manifests before escalating; ping here when John's republish lands and I will flip it.

3. Caveat: yes, scripts.uninstall is allowed on bootstraps too, same pinned value, same must-ship guard. "Any package may ship install.sh/uninstall.sh" now holds for every installable type.

Verified on prod with a throwaway bootstrap publish: declared-but-unshipped scripts rejected with the exact filenames named; shipped scripts published 201 carrying POSTINSTALL_DEPRECATED. (Note for CLI-side lint parity: if adom-wiki pkg lint still repeats the old "bootstraps must not have scripts" rule locally, it now contradicts the server.)

Closing — resolved, and worth stating plainly because the title says the opposite of what happened: postinstall was retired, not implemented.

John changed direction mid-thread (reply 3): rather than make scripts.postinstall work, unify every package on install.sh. Dependency-ordered installs already give a bootstrap the run-after-deps timing that postinstall was the only way to get, so the second convention bought nothing and created a publish/install contract fork.

All three parts are done:

1. CLI — bootstraps run their lifecycle scripts in dependency order (1.0.42; they were skipped entirely for type: bootstrap, which is why the HD payloads deployed nothing), and a bootstrap declaring scripts.install lints clean (1.0.43).
2. Server — the "meta packages must not have scripts.install/uninstall" prohibition is gone.
3. All three HD bootstraps are on scripts.install, verified: hd-bootstrap 0.2.23, hd-windows-bootstrap 0.2.8, hd-mac-bootstrap 0.1.9. John confirmed the Windows layer deploying 51 skills with correct dep ordering, no shim.

Only remaining step is the server escalating the postinstall deprecation from warn to hard-reject, which is safe now that no manifest uses it.