v1.1.12

Security

• Floored hono to ^4.12.34, clearing GHSA-8j4g-w8fx-2239 (moderate). This was deferred earlier the same day: the fix release was still inside the repo's 24-hour minimumReleaseAge soak — it missed by under three minutes — and no minimumReleaseAgeExclude carve-out was added, because the soak is the point. It matured at 2026-08-04T02:36:40Z and is floored now. pnpm audit reports no known vulnerabilities.

Added

• version-guard now requires every version bump to be documented under a real ## [X.Y.Z] CHANGELOG heading. The guard already refused a bump to a version that was already on npm, but it never checked that the new version was described anywhere. Notes parked under ## [Unreleased] are orphaned the moment the release ships: nothing in the release path renames that section — the version lifecycle script only syncs the plugin manifests — so the published version goes out undocumented while its release notes sit under a heading still claiming they are unreleased. apple-notes-mcp shipped 2.6.10 and 2.6.11 exactly that way before this check existed. A bump whose version has no matching heading now hard-fails the PR, with an error naming the heading to add. Keep an empty ## [Unreleased] at the top regardless — dependabot-rebuild.yml hard-exits without that marker, and since it already inserts a real heading, bot PRs pass unchanged. The guard file lives in .github/, which does not ship, so this owes no version bump. Matches apple-mail-mcp#124, keeping the guard identical across the four servers. (#50)

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[].

Fixed

• version-guard no longer demands a version bump for byte-neutral src/ changes. The shipped-bytes detector treated every non-test file under src/ as shipped, but TypeScript there reaches users only after esbuild inlines it into build/index.js — so a comment-, formatting- or type-only edit that leaves the committed bundle byte-identical was hard-blocked, leaving only two bad options: publish a release of literally nothing, or do not write the comment. src/**/*.ts is now a first-cause detector that implies a bump only when build/** changed too. The exemption is sound rather than merely convenient: ci.yml's "Verify committed build/ matches source" step rebuilds and requires git diff --quiet build/, and it runs in the test job whose test (22)/test (24) contexts are required by branch protection — so at merge time an unchanged build/ provably matches src/. Everything else under src/ (the verbatim-shipped *_reader.py sidecars), requirements.txt and build/** stay unconditional detectors, and the rule is written fail-safe: only .ts counts as bundle-only, so any new file type under src/ still requires a bump.
• 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.
• 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.

Security

• fast-uri 3.1.4 → 3.1.5, clearing GHSA-7p8r-x3mc-p8w7 (high) — and this one was in the shipped bundle. fast-uri reaches the published package for real: @modelcontextprotocol/sdk → ajv (and ajv-formats) pull it, and esbuild inlines its source into build/index.js, so the committed bundle carried the vulnerable copy and changed by 1,127 bytes when the fix landed — hence the version bump. The floor was already here and was the thing holding the tree back. pnpm-workspace.yaml read fast-uri: 3.1.4, written as an exact pin when 3.1.4 was the newest release; the moment 3.1.5 shipped that pin stopped acting as a floor and became a ceiling, pinning the tree to the vulnerable version so the advisory could never clear no matter how many times Dependabot re-ran. Rewritten as the caret range ^3.1.5, which stays inside ajv's expected major while letting future patch fixes flow in. Every floor in this file is now a caret range for that reason — an exact pin is a security floor that silently expires. Matches apple-mail-mcp 2.10.2 (#128), which hit the identical trap.
• ip-address 10.2.0 → 10.4.0, clearing GHSA-mwp4-54f8-5fhr (high), GHSA-4xrf-jv44-h6hh and GHSA-22jq-vg5j-6vgg. @modelcontextprotocol/sdk → express-rate-limit capped it at 10.2.0, below the 10.3.1 fix; floored at ^10.3.1, which resolves to 10.4.0. Unlike fast-uri this is not in the shipped bundle — the SDK's HTTP transports are tree-shaken out of the stdio-only server, and grep -c ip-address build/index.js returns 0 — so the exposure was to the install tree, not to anything this package runs. Fixed anyway to keep the dependency graph clean and the Dependabot alert list actionable.
• Deferred: hono (GHSA-8j4g-w8fx-2239, moderate), still resolving to 4.12.27. The fix is 4.12.34, published 2026-08-03T02:36:40Z — roughly three minutes inside this repo's 1440-minute minimumReleaseAge window at the time of the change, so pnpm install refused it with ERR_PNPM_NO_MATURE_MATCHING_VERSION. That gate is deliberate supply-chain policy and clearing it by three minutes is exactly the kind of exception it exists to prevent, so no minimumReleaseAgeExclude carve-out was added and the floor was left out rather than forced. hono is not in the shipped bundle either (grep -c returns 0; it arrives via @hono/node-server, whose HTTP transport this stdio server never loads), so the published package is unaffected. pnpm audit will keep reporting this one moderate finding until the floor hono: ^4.12.34 is added in a follow-up, which is now a one-line change.
• Floored all three dev-only brace-expansion majors on their complete fixes for GHSA-mh99-v99m-4gvg / CVE-2026-14257 (high) — 1.1.16 → 1.1.18, 2.1.2 → 2.1.4, and both 5.0.7 and 5.0.8 → 5.0.9. Three separate majors are reachable through the dev toolchain (eslint → minimatch@3 on v1, minimatch@9 on v2, minimatch@10 on v5), and they are not API-compatible — minimatch 3 requires the v1 CommonJS API, so a single floor spanning them fails with expand is not a function. Each major therefore carries its own two-sided floor; the bounds must be two-sided because a bare <5.0.9 also matches 1.1.18 and 2.1.4 under semver and would drag the CommonJS path onto the v5 ESM API. The advisory's own first-patched versions (1.1.17 / 2.1.3 / 5.0.8) are not sufficient: they bound the accumulator in combine but never thread maxLength into expandSequence, so the sequence path ({1..N}, {a..z..k}) stays capped only by item count and a padded sequence still materialises ~100,000 intermediate strings before the outer bound truncates (measured 4,606 ms / 176 MB RSS on 1.1.17 vs 9 ms / 61 MB on 1.1.18, identical final output). Two of the four paths resolved here (1.1.16, 5.0.7) were below even the advisory's floor. Adopted only after every release cleared this repo's 24-hour minimumReleaseAge gate, with no minimumReleaseAgeExclude carve-out and no audit suppression — pnpm audit will keep reporting the advisory until GitHub's metadata (which still lists 5.0.8 as first-patched, and so marks the entire v1 line vulnerable under semver) catches up. Dev toolchain only: brace-expansion is not in the shipped bundle, so the published package is unaffected, the committed bundle is byte-identical, and no version bump is owed. Matches apple-mail-mcp#123 — thanks to @jjoanna2-debug for the original finding.
• postcss 8.5.16 → 8.5.24 (dev-only transitive, via vite/vitest). Clears Dependabot alert #6 (GHSA high): "PostCSS: Path Traversal in Previous Source Map Auto-Loading (sourceMappingURL) leads to Arbitrary .map File Disclosure", whose vulnerable range is <= 8.5.17. postcss is not a runtime dependency and is not inlined into the committed bundle (verified byte-identical after a rebuild), so nothing that ships to npm changes — this was a stale lockfile resolution, not a code defect. The sibling repos were already above the range (mail 8.5.23 behind an explicit ^8.5.15 override floor, notes and photos 8.5.19), which is why the alert fired only here.