Recognise the Hermes config this installer wrote - #684
Merged
Conversation
Installing v1.0.0 over v0.8.2 failed with "mcp_servers.commitlore already exists but does not point at this CommitLore install" while the entry pointed at exactly the right wrapper. The entry was matched as five exact lines, and the config wrote its args in flow style -- args: [mcp] rather than a block list -- so a formatting difference read as a foreign installation. Two defects from one comparison. Every upgrade was refused, because the version lives in skills.external_dirs and goes stale each release. And the refusal named command, which was correct, sending whoever read it to inspect the one value that was right. The entry is now read field by field. Flow and block args are the same args, a user who deleted enabled: true has not stopped using this install, and the refusal names the key that actually differs with both values in it. Not a YAML parser. It reads the fields this installer writes and treats anything structurally unfamiliar as unreadable rather than foreign -- the same distinction between "I could not tell" and "this is not mine" that the rest of the product makes. Verified by restoring the exact-line match: the flow-style cases fail. Limit: recognition is by field, never by formatting Blast: module Undo: easy Certainty: firm Provenance: authored Record-Id: r-682herm
CommitLore — record lintTrailers: clean — 2 commits in Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR. |
This was referenced Aug 15, 2026
MongLong0214
added a commit
that referenced
this pull request
Aug 15, 2026
installedPath resolves against the bundle that is executing. That is right when the bundle is the installed one, and wrong the moment it is not: running a checkout's dist/ while --data-root pointed at the real installation wrote the checkout's path into a permanent Hermes config. The damage is not a missing file today. It is a config bound to a tree that will be deleted or switched, after which the skills vanish while mcp_servers stays valid -- the half-configured state #684 was about, reached through a different door. The same wrong-name refusal would follow. So when the data root holds this version's skills, that is the answer. The bundle's own location stays as the fallback for the case it was always correct for, an installation invoking itself, and an explicit --skills-dir still wins. Found while verifying #684 against a real Hermes profile, which is the only place it could have been found: every test until now supplied skillsDir explicitly and so never exercised the derivation. Verified by restoring the old resolution -- the data-root case fails. Limit: a permanent config never records a path that belongs to one invocation Blast: module Undo: easy Certainty: firm Provenance: authored Record-Id: r-686skil
Merged
MongLong0214
added a commit
that referenced
this pull request
Aug 15, 2026
Five fixes have been sitting on main since v1.0.0 and none of them has reached
anyone. They are all defects at the install and distribution boundary, and that
boundary has exactly one delivery mechanism: a release.
#683 the release workflow failing on a release that already exists
#684 hermes install refusing the config it wrote
#687 the skills root taken from the running bundle instead of --data-root
#688 an installed plugin treated as a reason to stop rather than upgrade
#690 claude-code wired by nothing, in neither hosts nor notDetected
Measured rather than assumed: re-installing with main's install.sh still left the
plugin cache at 0.8.0 and claude-code out of both lists, because the enumeration
that #690 fixed is compiled into the binary being installed -- and that binary is
v1.0.0.
dist is unchanged and the canonical digest is identical to before the bump. The
version is read from package.json at runtime rather than compiled in. Rebuilt
through the canonical builder and verified rather than assumed, the same as
v1.0.0.
Thirty-eight pins across nine files. The installers and READMEs carry the tag in
URLs that resolve only once the tag exists, so this is one commit and the tag
goes on it.
This is the first release cut under release-gate 6c, which asks for an upgrade
over the previous version rather than a fresh install. The five fixes above are
why that section exists.
Limit: a distribution-boundary fix reaches nobody until it is released
Blast: system
Undo: costly
Certainty: firm
Provenance: authored
Record-Id: r-rel101
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #682.
install.sh v1.0.0exited 1 on a machine that had v0.8.2:The entry pointed at exactly the right wrapper. It was matched as five exact
lines, and the config on disk wrote
args: [mcp]rather than a block list — soa formatting difference read as a foreign installation.
Two defects from one comparison
Every upgrade was refused. The version lives in
skills.external_dirs, whichgoes stale each release, so
hermes installwould fail on every future versiontoo. Five other hosts updated fine; Hermes alone could not recognise its own
work. Worth noting what did survive:
.mcp.jsonfor ACP pins nothing and camethrough the upgrade untouched.
The refusal named the wrong key.
commandwas correct. Anyone following thatmessage inspected the one value that was right and had nowhere to go — a true
observation carrying a false name.
What changed
The entry is read field by field:
argsare the sameargsenabled: truehas not stopped using this installNot a YAML parser. It reads the fields this installer writes and treats
anything structurally unfamiliar as unreadable rather than foreign — the same
distinction between "I could not tell" and "this is not mine" the rest of the
product makes. A blocked entry is still never overwritten.
Verified
test/hermes-upgrade.test.ts, six cases built from the config that actuallyfailed. Negative control: restoring the exact-line match makes the flow-style
cases fail. Existing Hermes tests unchanged and passing — 13 total.
Canonical artifact
b29745c3.