Repository navigation
Releases
v0.4.0
v0.3.1
fix(packaging): ship scripts/ so postinstall resolves; linker stands down in consumer trees
Same defect class as fan56/dsh-subagent-registry#2: the postinstall hook
references scripts/link-dsh-closure.mjs, which the files allow-list never
shipped — every non-link install (plugin manager, plain npm install) dies
in the lifecycle step with MODULE_NOT_FOUND. Ship scripts/, and key the
linker's stand-down guard on repo-only markers (tsconfig.json + .git)
instead of the fragile src/ check.
Coverage for the blind spot: new test/packaged-install.test.mjs packs the
tarball and installs it under npm with lifecycle scripts on (the pnpm
boot smoke blocks dependency lifecycle scripts by default, which is how
this class shipped unnoticed), and the boot smoke installs via npm and
asserts the linker stood down in the consumer tree.
v0.3.0
chore: raise dsh host floor to 0.2.0-rc.2
peer floors dsh-agent/dsh-commands/dsh-llm/dsh-user-questions >= 0.2.0-rc.2, dev pins exact rc.2, pnpm-lock re-resolved against registry.npmjs.org; cordis ^4.0.4 unchanged; README floor updated; tests 66 pass / 0 fail
v0.2.0
0.1.7-rc.1 迁移：peer 地板抬 >=rc.1（无需 settings 迁移，数据本就在插件自有 store）；icon/locale 元数据
v0.1.2
docs: TUI pairing floor (tui-pi >= 2.18.1) and no-wiring install note
v0.1.1
0.1.1: make apply() idempotent across mounts (tui-pi auto-mount + bundles)
dsh-tui-pi's bundle patch now mounts this plugin itself so an upgrade
reactivates the commands with zero user action; a profile that ALSO lists
it in bundles produced two tree entries and the second apply crashed the
whole boot on the duplicate command registration. The first apply claims
a root-scope marker synchronously at apply entry — parallel loader fibers
cannot interleave between check and claim — and later mounts no-op.
Verified by unit tests (fake root/plugin contexts) and both mount shapes
on a real dsh host (fresh profile and duplicate-listing profile, both
boot clean).
v0.1.0
Add the triple-contract check: write side ↔ registry read side on real files
scripts/contract-check.mjs closes the deployment-shape gap the unit
suite fakes: it imports @aiwayds/dsh-subagent-registry from a real
profile's node_modules (probing the sibling resolution the deployed
registryDetected() relies on), writes a pin + store through THIS
plugin's own functions in a scratch DSH_HOME, and asserts the
registry's composeAgentRuntime composes it back — override wins,
explicit-inherit empty entry and unlisted-baseline fallback hold, the
pin and store readable by the registry's own readers.
No registry resolvable (CI on this repo) → documented skip, exit 0;
run with --registry-from /node_modules or on any
registry-bearing machine to exercise the full handshake.