v2.1.5

Fixed

• Export progress notifications could be silently dropped — most often the final done === total one. The export tool sent them fire-and-forget (void extra.sendNotification(...)), so the sends raced the tool's own response. That race is not benign: an MCP client deletes the request's progress handler the moment the response arrives (Protocol._onresponse), and Protocol._onprogress discards a notification whose token no longer has a handler (reporting "progress notification for an unknown token"). A notification that lost the race was therefore lost outright, never delivered late — and the terminal notification, being emitted last, was the most exposed, so a client surfacing completion from it could intermittently never see an export finish. The tool now awaits its sends before returning, putting every notification on the wire ahead of the result. Each send still swallows its own failure, so this cannot fail an export; it only orders the writes.
• pnpm version no longer breaks with the .hermes-plugin/ removal. The version lifecycle script listed .hermes-plugin in its git add; git add exits 128 on a pathspec that matches nothing, which would have broken the documented release step (pnpm version <patch|minor|major> --no-git-tag-version) for every subsequent release. The stale path is dropped from the git add list.
• Dependabot auto-bump silently stopped staging its own changes. dependabot-rebuild.yml's bump step writes the patch version, syncs the plugin manifests and prepends a CHANGELOG entry, then staged them with git add package.json CHANGELOG.md build .claude-plugin .agents codex .hermes-plugin .antigravity-plugin. Once .hermes-plugin/ was removed that pathspec matched nothing, and git add is all-or-nothing — it exited 128 and staged none of the others, with 2>/dev/null || true hiding the failure. The following step re-adds only build/, so a Dependabot PR would have committed a rebuilt bundle with no version bump and no changelog entry, failing require-version-bump and blocking the automation that is meant to run without a human. Dropped the stale path, and dropped the error suppression so a future missing path fails loudly instead of silently skipping the bump.
• persistent-sidecar integration flake. The expected 3 to be 4 failure that intermittently blocked unrelated PRs was this dropped notification, not a slow one, and specifically the terminal one. Two earlier attempts were wrong: widening the assertion's poll from 10s to 30s could not help (a discarded message never arrives, and a 30s budget failed identically on main), and the ordering fix above — correct on its own merits — cannot stop the client tearing down its progress handler first. Measured directly: with the synthetic sidecar's inter-photo spacing removed so all four notifications arrive as one burst, the server sent all four and the client delivered one, rejecting the rest with "progress notification for an unknown token". The test now asserts the three per-photo notifications — what the server controls and the client reliably delivers — and no longer asserts the terminal one, with the mechanism and both failed attempts recorded inline so they are not retried.

Removed

• .hermes-plugin/ packaging docs (README.md, config.yaml). Hermes Agent has no plugin/marketplace drop-in, so a directory of manifest-looking files was easy to misread as an installable package. The setup it documented is not lost — the hermes mcp add command, the ~/.hermes/config.yaml mcp_servers: snippet, and the restart note now live inline in the README's "Other Hosts" section. Matches apple-mail-mcp#116, keeping multi-host packaging parity across the four Apple MCP servers. No effect on the published package: .hermes-plugin/ was never in package.json files[].